Vulnhub has been raining VMs lately, a good mix of challenges which keep me on my toes constantly. 6Days lab was an enjoyable VM with a unique twist which had me pulling my hair out late at night.

You can grab the VM here: https://www.vulnhub.com/entry/6days-lab-11,156/

Let’s go!

As always, I started off with an nmap scan. Standard ports 22 and 80 open with a proxy service on port 8080.

Browsing to the web application I was greeted with a page touting the new Rashomon IPS service which would prove to be the bane of my existence for a few days.

Browsing around I noticed the ‘src’ parameter on the image.php page which is attempting to call an image from an external site. I first thought RFI but no, it could not be that easy. Firing up Burp I passed the request to repeater and saw that we were working with an LFI.

I started off by checking out the source of each of the PHP pages I knew existed.

Checkpromo.php was clearly vulnerable to SQL injection on the ‘promocode’ parameter, but we know there is an IDS in place. More on that later.

The index.php and image.php pages were not particularly exciting. Config.php gave me a glimmer of hope but, aside from the dbname, the credentials were not useful.

From the /etc/passwd file I knew that we had 2 users on the system “user” and “andrea”. Andrea’s shell was set to /bin/andrea. Using our LFI I had a look at this shell script. The readme for the VM mentions sandbox escapes so here is our “sandbox”. Andrea’s shell is set to rbash and all command input is directed to /dev/null, meaning that she can likely run most commands but even if they are successful there will be no feedback on the screen, evil 🙂 .

Back to the web app, we know we are likely dealing with some sort of SQL injection. Flopping around for some time I realized that we can evade the IPS utilizing SSRF to call the checkpromo.php page directly and that we are dealing with a time-based blind SQLi. SQLmap confirmed a time-based blind SQLi for the ‘promocode’ parameter. This was confirmed after attempting all upper and lowercase characters and receiving a 5 second delayed response on “S”, meaning that a password likely started with an “S”. All initial attempts with SQLmap and tamper scripts would not return any data. This was likely due to the size of the payloads being used as well as the proxy.

 

At this point we needed to be able to exploit the SSRF + SQLi with SQLmap (time-based blind SQLi by hand is something I need to work on).

With Burp to the rescue, we are able to set up a match/replace rule to automatically call the vulnerable URL via SSRF.

Chatting with @GKNSB for quite some time we realized that double URL encoding was needed, but only for certain special characters. While I tried to achieve this with some crazy Burp rules (unsuccessfully) @GKNSB whipped up this awesome custom SQLmap tamper script which worked flawlessly.

Armed with this tamper script and knowledge of the database name I was quickly able to pull out Andrea’s password.

And our password.

Armed with the goods I was able to SSH in, directly into the rbash shell 🙂 .

There are other ways to do this but I just took the opportunity to throw myself another shell as www-data to be able to look around the file system freely.

There was a custom binary ‘dog’ in Andrea’s home directory.

I pulled it down with netcat and had a look.

I was not able to fully exploit it as reversing is an area that I am still working on but did find that the dog file expected to be fed a file owned by a user with UID 1001 and would print the contents, otherwise an “Access Denied” message is printed (with some assistance and prodding from @sizzop who always keeps me on my toes).

Main makes a call to stat() (which checks the status of a file, including UID, dates, owner, etc.). When calling stat main checks 2 fields back to back to make sure they are both ‘3E9H”. Highlighting and pressing the ‘H’ key in IDA converts the hex to ‘1001’, confirming that the call to stat() is checking for a file with the UID and GUID 1001:1001 and if the file is owned by that user is will print out “Access Granted” and make a call to readfile() which prints the contents of the file.

To test this I created a test file owned by a user locally with UID and GUID 1001.

Running the dog binary against this confirmed what we have found.

At this point I went back to the VM, thinking that this binary would be useful in reading a file such as /etc/shadow. This did not work which made me think there is a missing piece in using this binary for privilege escalation that I will have to dig into further. I was able to obtain root privileges using a kernel exploit, which is my least favorite method but still got the job done.

And we have our flag.

Shout-out to @1ce7ea for an awesome challenge, @GKNSB for the tamper script which saved me lots of pain, @sizzop for another quick lesson in reversing, and @g0tmi1k for continuing to keep the vulnhub community going.