Beep Writeup w/o Metasploit
Last updated
Last updated
First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.
-sC: run default nmap scripts
-sV: detect service version
-O: detect OS
-oA: output all formats and store in file initial
We get back the following result showing that 12 ports are open:
Port 22: running OpenSSH 4.3
Port 25: running Postfix smtpd
Port 80: running Apache httpd 2.2.3
Port 110: running Cyrus pop3d 2.3.7-Invoca-RPM-2.3.7–7.el5_6.4
Port 111: running rpcbind
Port 143: running Cyrus imapd 2.3.7-Invoca-RPM-2.3.7–7.el5_6.4
Port 443: running HTTPS
Port 993: running Cyrus imapd
Port 995: running Cyrus pop3d
Port 3306: running MySQL
Port 4445: running upnotifyp
Port 10000: running MiniServ 1.570 (Webmin httpd)
Before we start investigating these ports, let’s run more comprehensive nmap scans in the background to make sure we cover all bases.
Let’s run an nmap scan that covers all ports.
We get back the following results.
Four other ports are open.
Port 878: running status
Port 4190: running Cyrus timsieved 2.3.7-Invoca-RPM-2.3.7–7.el5_6.4
Port 4559: running HylaFAX 4.3.10
Port 5038: running Asterisk Call Manager 1.1
Similarly, we run an nmap scan with the -sU flag enabled to run a UDP scan.
I managed to root the box and write this blog, while this UDP scan still did not terminate. So for this blog, I don’t have the UDP scan results.
Before we move on to enumeration, let’s make a few mental notes about the nmap scan results.
The OpenSSH version that is running on port 22 is pretty old. We’re used to seeing OpenSSH version 7.2. So it would be a good idea to check searchsploit to see if any critical vulnerabilities are associated with this version.
Ports 25, 110, 143, 995 are running mail protocols. We might need to find a valid email address to further enumerate these services. Port 4190 running Cyrus timsieved 2.3.7 seems to be associated to imapd.
Port 111 is running RPCbind. I don’t know much about this service but we can start enumerating it using the rpcinfo command that makes a call to the RPC server and reports what it finds. I think port 878 running the status service is associated to this.
Ports 80, 443 and 10000 are running web servers. Port 80 seems to redirect to port 443 so we only have two web servers to enumerate.
Port 3306 is running MySQL database. There is a lot of enumeration potential for this service.
Port 4559 is running HylaFAX 4.3.10. According to this, HylaFAX is running an open source fax server which allows sharing of fax equipment among computers by offering its service to clients by a protocol similar to FTP. We’ll have to check the version number to see if it is associated with any critical exploits.
Port 5038 is running running Asterisk Call Manager 1.1. Again, we’ll have to check the version number to see if it is associated with any critical exploits.
I’m not sure what the upnotifyp service on port 4445 does.
As usual, I always start with enumerating HTTP first. In this case we have two web servers running on ports 443 and 10000.
Port 443
Visit the application.
It’s an off the shelf software running Elastix, which is a unified communications server software that brings together IP PBX, email, IM, faxing and collaboration functionality. The page does not have the version number of the software being used so right click on the site and click on View Page source. We don’t find anything there. Perhaps we can get the version number from one of its directories. Let’s run gobuster on the application.
dir: uses directory/file brute forcing mode
-w: path to the wordlist
-u: target URL or Domain
-k: skip SSL certificate verification
We get back the following result.
The directories leak the version of FreePBX (2.8.1.4) being used but not the Elastix version number. I also tried common and default credentials on all the login forms I found in the directories and didn’t get anywhere.
Since this is an off the shelf software, the next step would be to run searchsploit to determine if it is associated with any vulnerabilities.
We get back the following result.
Cross-site scripting exploits are not very useful since they are client side attacks and therefore require end user interaction. The remote code execution (Solution #1) and local file inclusion (Solution #2) vulnerabilities are definitely interesting. The Blind SQL Injection is on the iridium_threed.php script that the server doesn’t seem to load. Plus it seems like it requires a customer to authenticate, so I’m going to avoid this exploit unless I get valid authentication credentials. The PHP Code Injection exploit is in the vtigercrm directory where the LFI vulnerability exists as well. So we’ll only look into that if the LFI vulnerability does not pan out.
Port 10000
Visit the application.
This also seems to be an off the shelf software and therefore the first thing I’m going to do is run searchsploit on it.
We get back a lot of vulnerabilities!
One thing to notice is that several of the vulnerabilities mention cgi scripts, which if you read my Shocker writeup, you should know that the first thing you should try is the ShellShock vulnerability. This vulnerability affected web servers utilizing CGI (Common Gateway Interface), which is a system for generating dynamic web content. If it turns out to be not vulnerable to ShellShock, searchsploit returned a bunch of other exploits we can try.
Based on the results of the enumeration I have done so far, I believe I have enough information to attempt exploiting the machine. If not, we’ll go back and enumerate the other services.
This solution involves attacking port 443.
First, transfer the RCE exploit to the attack machine.
Looking at the code, we need to change the lhost, lport, and rhost.
Before we run the script, let’s URL decode the url parameter to see what it’s doing.
It seems like a command injection that sends a reverse shell back to our attack machine. Let’s setup a netcat listener on the configured lhost & lport to receive the reverse shell.
Run the script.
I get an SSL unsupported protocol error. I tried fixing the error by changing the python code, however, I couldn’t get it to work. Therefore, the next best solution is to have it go through Burp.
First, change the url parameter from “https” to “http” and the rhost to “localhost”. Next, in Burp go to Proxy > Options > Proxy Listeners > Add. In the Binding tab, set the port to 80. In the Request handling tab set the Redirect to host parameter to 10.10.10.7, Redirect to port parameter to 443 and check the option Force use of SSL.
What that does is it redirects localhost to https://10.10.10.7 while passing all the requests and responses through Burp. This way the python script doesn’t have to handle HTTPS and therefore we avoid the SSL error we are getting.
Let’s try running it again.
It runs but we don’t get a shell back. The nice thing about doing this with Burp is that we can see the request & response. In Burp go to Proxy > HTTP history and click on the request. In the Request tab, right click and send it to repeater. As can be seen, the error message we get is as follows.
This might have to do with the default extension value in the script. We don’t actually know if the value 1000 is a valid extension. To figure that out, we’ll have to use the SIPVicious security tools. In particular, the svwar tool identifies working extension lines on a PBX. Let’s run that tool to enumerate valid extensions.
-m: specifies a request method
-e: specifies an extension or extension range
We get back the following result.
233 is a valid extension number. Change the extension in the script and run it again.
We have a shell! Let’s first upgrade the shell to a partially interactive bash shell.
To get a fully interactive shell, background the session (CTRL+ Z) and run the following in your terminal which tells your terminal to pass keyboard shortcuts to the shell.
Once that is done, run the command “fg” to bring netcat back to the foreground. Then use the following command to give the shell the ability to clear the screen.
Now that we have a fully interactive shell, let’s grab the user.txt flag.
Next, we need to escalate our privileges to root. Run the following command to view the list of allowed sudo commands the user can run.
We get back the following result.
Oh boy, so many security misconfigurations! For this solution, let’s exploit the chmod command.
Run the following command to give everyone rwx permissions on the /root directory.
Now we can view the root.txt flag.
This solution involves attacking port 443.
First, transfer the LFI exploit to the attack machine.
Looking at the exploit, it seems that the LFI vulnerability is in the current_language parameter. Let’s see if our application is vulnerable to it.
We get back the following page.
The application is definitely vulnerable. Right click on the page and select View Page Source to format the page.
The file seems to have a bunch of usernames and passwords of which one is particularly interesting.
Let’s try to use the above credentials to SSH into the admin account.
It doesn’t work. To narrow down the number of things we should try, let’s use the LFI vulnerability to get the list of users on the machine.
After filtering through the results, these are the ones I can use.
Let’s try SSH-ing into the root account with the credentials we found above.
It worked!
For this solution, we don’t have to escalate privileges since we’re already root.
This solution involves attacking port 10000.
First, visit the webmin application.
Then intercept the request in Burp and send it to Repeater. Change the User Agent field to the following string.
What that does is it exploits the ShellShock vulnerability and sends a reverse shell back to our attack machine. If you’re not familiar with ShellShock, the following image explains it really well.
Set up a listener to receive the reverse shell.
Send the request and we get a shell!
For this solution we also don’t need to escalate privileges since we’re already root!
I presented three ways of rooting the machine. I know of at least two other way (not presented in this writeup) to root the machine including a neat solution by ippsec that involves sending a malicious email to a user of the machine and then executing that email using the LFI vulnerability we exploited in solution #2. I’m sure there are also many other ways that I didn’t think of.
