Initial nmap scan:
22 is ssh (surprisingly):
80 is a website (again, what a surprise):
A broken image? Let's check it's src attribute:
no wonder the link doesn't work, it is trying to access the internet, which I usually don't allow for my vulnerable boxes. And boy, does that link reek of a rfi/lfi vulnerability :)
Confirmed LFI:
RFI works, but php code isn't executed:
We can view the source of PHP-files, no wonder the php-code isn't executed:
Let's check the code from the other php files we've found this far...
The checkpromo.php has an SQLi:
You see? The GET-parameter promocode is just concatenated to the SQL query, classic SQLi. The select clause fetches 2 columns from the database and the 2nd has to be 1 for the values to be printed out, this helps us with the SQLi exploitation.
Additionally we see some credentials:
When I try to exploit the SQLi, I get blocked by the Rashomon IPS:
The port 80 is probably the WAF and it forwards the requests via the local loopback to 8080, which is the actual web server.
Let's check what exists in the 127.0.0.1:8080 on the target:
It seems we guessed right! Perhaps we can use this to bypass the WAF.
Further testing shows us that double encoding bypasses the WAF and that we can use the image.php to pass the SQL injections to the web server without the IPS noticing!
I jumped to ipython shell and created 2 helper functions:
Then we can use the run-function to more easily exploit the SQL injection vulnerability instead of manually encoding each request:
So we have a table called users and in it columns id, username and password. Time to get the gold:
andrea? we had andrea in the passwd-file too! And sure enough, Andrea has recycled her password, it works for the ssh login too!
nothing seems to work though! We are in rbash-shell, that's why nothing works!
But since we can run python, we can bypass rbash restrictions pretty easily!
humm, creating a new bash prompt doesn't work directly
I created a python payload with msfvenom and set up a simple nc listener on my box, and sure enough, we get an unrestricted interactive shell. There is a single suid file in the home directory:
There are some dev tools installed such as ltrace:
The application obviously checks for file permissions on the 1st command line argument, let's see what happens if we have permissions (bar is just a simple file I created with "foo" in it):
So, we have a suid cat, which checks the file permissions before outputting the file contents. Sounds like a TOCTOU issue to me! :)
There probably are some more elegant ways to do this, but I created a couple of scripts:
After a couple of tries:
and:
I then fired up my trusty john and while waiting for results, digged further...
remember, the target was to execute the file /flag?
would you call this cheating? :D
But since this was a boot2root challenge, we can't stop here...
Let's check the usual things:
Ubuntu 12.04 with kernel 3.13.0, eh? This calls for the overlayfs exploit (https://www.exploit-db.com/exploits/37292/)!
Just download, compile and run:
and that's it! we have rooted the box and obtained the flag! Just to be sure, let's re-run the flag as root:
It appears that I'm root before john had cracked any passwords and I decided not to wait for the results...
Thanks @1ce7ea for creating the challenge and g0tmi1k for hosting vulnhub!
Your good... That was really good. I was dead stuck and you taught me some pretty rad stuff. Thanks.
ReplyDeleteThanks for the feedback. I appreciate it!
ReplyDeleteThanks for the feedback. I appreciate it!
ReplyDeleteIt is indeed brilliant! I loved the way you explainded each and every step.
ReplyDeleteLearned a lot this day from you, THX :)
I'm glad you enjoyed it! Thanks
DeleteCan you explain how you used dog? i created same sh scripts, runned them but the shadow.out is empty
ReplyDeleteHey,
DeleteYou did have them running simultaneously, right? The purpose is to exploit a TOCTOU issue (https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use), where you have to quickly have the system switching between an allowed and disallowed file (the symbolic links). It's possible that you won't be lucky when running the scripts for the first time, because the window, where the symbolic link has to be changed, is quite small.