./wlk/htb/ret/beep :: HTB Beep
Two posts in one day? That's right! I've been up all night playing with HackTheBox, and I'm here to present my second write-up. As before, I'm working my way through the OSCP-Like HTB machines. This time, I chose to try my hand at the system called “Beep.” I wanted to go in order, but many of the boxes weren't online. “Beep” was the first live machine I found as I went down the list.
Enumeration
Once again, I began with enumeration. I started with a nmap scan of the target system:
root@kali:~# nmap -A 10.10.10.7
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-19 06:32 EDT
Nmap scan report for 10.10.10.7
Host is up (0.067s latency).
Not shown: 988 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
|_http-server-header: Apache/2.2.3 (CentOS)
|_http-title: Did not follow redirect to https://10.10.10.7/
110/tcp open pop3 Cyrus pop3d 2.3.7-Invoca-RPM-2.3.7-7.el5_6.4
[...]
111/tcp open rpcbind 2 (RPC #100000)
[...]
143/tcp open imap Cyrus imapd 2.3.7-Invoca-RPM-2.3.7-7.el5_6.4
[...]
443/tcp open ssl/https?
|_ssl-date: 2019-04-19T07:25:27+00:00; -3h10m09s from scanner time.
993/tcp open ssl/imap Cyrus imapd
|_imap-capabilities: CAPABILITY
995/tcp open pop3 Cyrus pop3d
3306/tcp open mysql MySQL (unauthorized)
4445/tcp open upnotifyp?
10000/tcp open http MiniServ 1.570 (Webmin httpd)
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
[...]
Nmap done: 1 IP address (1 host up) scanned in 355.20 seconds
With 12 open ports, this system looked a lot more active than the last one! I had a lot to investigate. I took note of the version numbers supplied for Apache and Cyrus, and noticed that there was an interesting HTTPd that I'd never seen before (MiniServ). However, the first thing I wanted to look at was the website running on port 80.
Upon browsing to the target system, I was immediately redirected from port 80 to port 443 (https). I had to click through the self-signed certificate (since this is a CTF box and not a live machine), but afterwards I was greeted with the Elastix login page:
On a whim, I decided to try visiting the admin directory, to see if it existed. I went to https://10.10.10.7/admin/ and was greeted with a login prompt. I tried the default admin:admin credentials, but those didn't work, so I just hit escape and was greeted by a FreePBX page:
I noted that the FreePBX page listed its version number: 2.8.1.4, and wrote that down for later reference. While I was thinking about version numbers, I decided to check the homepage HTML source to see if Elastix included any kind of version information – it didn't.
Finally, I decided to check out the MiniServ server running on port 10000. Once again, I was greeted with a login page:
Searching for Sploits
My first instinct was to check to see if there were any vulnerabilities in any of the services running on the machine. Using the searchsploit tool, I checked Apache and Cyrus without any luck. I checked on Postfix, and saw some interesting options (such as a remote command injection), but without knowing the software version I couldn't be sure what would work. (I made a note to return to this if I couldn't find another avenue for attack.) I also checked on MiniServ with no luck, and rpcbind and mysql returned so many results that I knew I'd need to enumerate further in order to make any headway.
Everything I was finding felt like a long-shot, so I decided to see if there were any exploits for the Elastix or FreePBX services running on Apache. I couldn't find any results for the FreePBX version I'd discovered, so I turned my attention to Elastix. I didn't know the version number for that service, but I figured it would be worth a shot to see what was available.
The results included a bunch of cross-site scripting (XSS) attacks, but those wouldn't be useful to me in the CTF. However, the local file inclusion and remote code execution vulnerabilities looked promising, and I figured I might be able to do something with the PHP code injection if I needed to. (Perhaps inject a PHP shell?)
A Little Bit of Failure
The RCE bug included a python script, so I decided to try that one out first. I copied the exploit code to my local directory using searchsploit -m exploits/php/webapps/18650.py and opened the file with vi to ensure that everything was set up properly. I had to replace the IP addresses of the local and remote hosts, but that didn't take long. Finally, I ran the script:
root@kali:~# python 18650.py
Traceback (most recent call last):
[...]
File "/usr/lib/python2.7/ssl.py", line 828, in do_handshake
self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol
Well, that was anticlimactic. I tried a number of methods to fix the error, but nothing seemed to work. It might have had something to do with the self-signed certificates, but I searched for an hour without any success, trying different libraries and language features. In the end, I decided to set the exploit aside and see if I could find anything else that might work. If I needed, I could come back to that script, perhaps even re-write it from scratch. But I wasn't going to waste more time on it.
Success!
I moved on to the local file inclusion vulnerability. I copied the exploit to my local folder and opened it up in vi. Reading more about it, I found that it exploited a file called graph.php in the vtigercrm folder, and included a simple Proof of Concept (PoC) in the form of a one-line URL that could be pasted into the URL bar. So I copied the URL (which pointed to the /etc/amportal.conf file) and gave it a shot. Sure enough, it worked! The data returned was a steaming mess, but this was because the browser was not respecting newlines. By viewing the source, I could see the original file, in all its glory. And right there, midway down the page, I saw the FreePBX database configuration information… including usernames and passwords:
I scrolled through the rest of the config file, searching for additional passwords, and found the same one used repeatedly throughout the file: jEhdIekWmdjE.
I also found that the admin username was simply admin, so I decided to see if I could log in with this information on the website. Sure enough, I was able to log in to the Elastix page and the FreePBX page (on /admin/), but it didn't work on the Webmin page (on port 10000).
It seemed apparent that this password was used frequently, and considering that there was an SSH service open on this system, I thought it might be a good idea to see if the password would work for any of the user accounts on the system. But how could I get the usernames? Perhaps the same local file inclusion exploit would work for the /etc/passwd file, and even /etc/shadow as well!
First I tried /etc/passwd, and sure enough I had a list of all the usernames on the machine:
Next I tried /etc/shadow, thinking that if the password I'd found didn't work, perhaps I could try to crack the passwords I found in the shadow file. Unfortunately, I wasn't able to access that file. However, knowing that people tend to use the same password for multiple things, I decided to give jEhdIekWmdjE a shot.
I considered working on the list of usernames to narrow it down to likely candidates, but I thought I might just try the password on root first… just in case. After all, it had been the admin password for both Elastix and FreePBX, so why wouldn't they use it for root too?
root@kali:~# ssh root@10.10.10.7
root@10.10.10.7's password:
Last login: Fri Aug 25 18:05:54 2017
Welcome to Elastix
----------------------------------------------------
To access your Elastix System, using a separate workstation (PC/MAC/Linux)
Open the Internet Browser using the following URL:
http://10.10.10.7
[root@beep ~]#
It worked! I had root access! Now all I needed to do was find the root.txt and user.txt files.
[root@beep ~]# pwd
/root
[root@beep ~]# cat root.txt
d88e006123842106982acce0aaf453f0
Finding the root flag was easy enough. Next I needed the user flag…
[root@beep ~]# cat /home/*/user.txt
aeff3def0c765c2677b94715cffa73ac
As before, simply using cat /home/*/user.txt worked as expected. I had both flags!
Conclusion
While I stumbled around in the dark for a bit looking for valid exploits to run on the system, and failing to get some Python code to fly, I eventually managed to get into the system and get root, again without using Metasploit. I was fortunate that the required exploits were on my Kali system already – if I'd had to search online for the exploits, I might have wound up chasing even more dead-ends than I did already! Still, I'm learning, and nabbing two wins in a day feels good.
Well, I'm exhausted. I think I'll call it a day. Maybe kick back with a brew and watch some cartoons. I need to catch up on Adventure Time…
Read other posts
Two posts in one day? That's right! I've been up all night playing with HackTheBox, and I'm here to present my second write-up. As before, I'm working my way through the OSCP-Like HTB machines. This time, I chose to try my hand at the system called “Beep.” I wanted to go in order, but many of the boxes weren't online. “Beep” was the first live machine I found as I went down the list.
Enumeration
Once again, I began with enumeration. I started with a nmap scan of the target system:
root@kali:~# nmap -A 10.10.10.7
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-19 06:32 EDT
Nmap scan report for 10.10.10.7
Host is up (0.067s latency).
Not shown: 988 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
|_http-server-header: Apache/2.2.3 (CentOS)
|_http-title: Did not follow redirect to https://10.10.10.7/
110/tcp open pop3 Cyrus pop3d 2.3.7-Invoca-RPM-2.3.7-7.el5_6.4
[...]
111/tcp open rpcbind 2 (RPC #100000)
[...]
143/tcp open imap Cyrus imapd 2.3.7-Invoca-RPM-2.3.7-7.el5_6.4
[...]
443/tcp open ssl/https?
|_ssl-date: 2019-04-19T07:25:27+00:00; -3h10m09s from scanner time.
993/tcp open ssl/imap Cyrus imapd
|_imap-capabilities: CAPABILITY
995/tcp open pop3 Cyrus pop3d
3306/tcp open mysql MySQL (unauthorized)
4445/tcp open upnotifyp?
10000/tcp open http MiniServ 1.570 (Webmin httpd)
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
[...]
Nmap done: 1 IP address (1 host up) scanned in 355.20 seconds
With 12 open ports, this system looked a lot more active than the last one! I had a lot to investigate. I took note of the version numbers supplied for Apache and Cyrus, and noticed that there was an interesting HTTPd that I'd never seen before (MiniServ). However, the first thing I wanted to look at was the website running on port 80.
Upon browsing to the target system, I was immediately redirected from port 80 to port 443 (https). I had to click through the self-signed certificate (since this is a CTF box and not a live machine), but afterwards I was greeted with the Elastix login page:
On a whim, I decided to try visiting the admin directory, to see if it existed. I went to https://10.10.10.7/admin/ and was greeted with a login prompt. I tried the default admin:admin credentials, but those didn't work, so I just hit escape and was greeted by a FreePBX page:
I noted that the FreePBX page listed its version number: 2.8.1.4, and wrote that down for later reference. While I was thinking about version numbers, I decided to check the homepage HTML source to see if Elastix included any kind of version information – it didn't.
Finally, I decided to check out the MiniServ server running on port 10000. Once again, I was greeted with a login page:
Searching for Sploits
My first instinct was to check to see if there were any vulnerabilities in any of the services running on the machine. Using the searchsploit tool, I checked Apache and Cyrus without any luck. I checked on Postfix, and saw some interesting options (such as a remote command injection), but without knowing the software version I couldn't be sure what would work. (I made a note to return to this if I couldn't find another avenue for attack.) I also checked on MiniServ with no luck, and rpcbind and mysql returned so many results that I knew I'd need to enumerate further in order to make any headway.
Everything I was finding felt like a long-shot, so I decided to see if there were any exploits for the Elastix or FreePBX services running on Apache. I couldn't find any results for the FreePBX version I'd discovered, so I turned my attention to Elastix. I didn't know the version number for that service, but I figured it would be worth a shot to see what was available.
The results included a bunch of cross-site scripting (XSS) attacks, but those wouldn't be useful to me in the CTF. However, the local file inclusion and remote code execution vulnerabilities looked promising, and I figured I might be able to do something with the PHP code injection if I needed to. (Perhaps inject a PHP shell?)
A Little Bit of Failure
The RCE bug included a python script, so I decided to try that one out first. I copied the exploit code to my local directory using searchsploit -m exploits/php/webapps/18650.py and opened the file with vi to ensure that everything was set up properly. I had to replace the IP addresses of the local and remote hosts, but that didn't take long. Finally, I ran the script:
root@kali:~# python 18650.py
Traceback (most recent call last):
[...]
File "/usr/lib/python2.7/ssl.py", line 828, in do_handshake
self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol
Well, that was anticlimactic. I tried a number of methods to fix the error, but nothing seemed to work. It might have had something to do with the self-signed certificates, but I searched for an hour without any success, trying different libraries and language features. In the end, I decided to set the exploit aside and see if I could find anything else that might work. If I needed, I could come back to that script, perhaps even re-write it from scratch. But I wasn't going to waste more time on it.
Success!
I moved on to the local file inclusion vulnerability. I copied the exploit to my local folder and opened it up in vi. Reading more about it, I found that it exploited a file called graph.php in the vtigercrm folder, and included a simple Proof of Concept (PoC) in the form of a one-line URL that could be pasted into the URL bar. So I copied the URL (which pointed to the /etc/amportal.conf file) and gave it a shot. Sure enough, it worked! The data returned was a steaming mess, but this was because the browser was not respecting newlines. By viewing the source, I could see the original file, in all its glory. And right there, midway down the page, I saw the FreePBX database configuration information… including usernames and passwords:
I scrolled through the rest of the config file, searching for additional passwords, and found the same one used repeatedly throughout the file: jEhdIekWmdjE.
I also found that the admin username was simply admin, so I decided to see if I could log in with this information on the website. Sure enough, I was able to log in to the Elastix page and the FreePBX page (on /admin/), but it didn't work on the Webmin page (on port 10000).
It seemed apparent that this password was used frequently, and considering that there was an SSH service open on this system, I thought it might be a good idea to see if the password would work for any of the user accounts on the system. But how could I get the usernames? Perhaps the same local file inclusion exploit would work for the /etc/passwd file, and even /etc/shadow as well!
First I tried /etc/passwd, and sure enough I had a list of all the usernames on the machine:
Next I tried /etc/shadow, thinking that if the password I'd found didn't work, perhaps I could try to crack the passwords I found in the shadow file. Unfortunately, I wasn't able to access that file. However, knowing that people tend to use the same password for multiple things, I decided to give jEhdIekWmdjE a shot.
I considered working on the list of usernames to narrow it down to likely candidates, but I thought I might just try the password on root first… just in case. After all, it had been the admin password for both Elastix and FreePBX, so why wouldn't they use it for root too?
root@kali:~# ssh root@10.10.10.7
root@10.10.10.7's password:
Last login: Fri Aug 25 18:05:54 2017
Welcome to Elastix
----------------------------------------------------
To access your Elastix System, using a separate workstation (PC/MAC/Linux)
Open the Internet Browser using the following URL:
http://10.10.10.7
[root@beep ~]#
It worked! I had root access! Now all I needed to do was find the root.txt and user.txt files.
[root@beep ~]# pwd
/root
[root@beep ~]# cat root.txt
d88e006123842106982acce0aaf453f0
Finding the root flag was easy enough. Next I needed the user flag…
[root@beep ~]# cat /home/*/user.txt
aeff3def0c765c2677b94715cffa73ac
As before, simply using cat /home/*/user.txt worked as expected. I had both flags!
Conclusion
While I stumbled around in the dark for a bit looking for valid exploits to run on the system, and failing to get some Python code to fly, I eventually managed to get into the system and get root, again without using Metasploit. I was fortunate that the required exploits were on my Kali system already – if I'd had to search online for the exploits, I might have wound up chasing even more dead-ends than I did already! Still, I'm learning, and nabbing two wins in a day feels good.
Well, I'm exhausted. I think I'll call it a day. Maybe kick back with a brew and watch some cartoons. I need to catch up on Adventure Time…