Wonderland TryHackMe Walkthrough

Musyoka Ian
10 min readJun 8, 2020

Hello guys back again with another walkthrough this time am going to be showing you how i exploited wonderland a virtual machine on TryHackMe. First of all thanks to the creator of the box NinjaJc01 the box was a real fun for me because the exploitation path is so realistic and it’s something any pentester should know. The creator really does a nice job on the box and what i love it even more about the box is that after logging into the box via ssh the creator gives you a road map of what need to be done to escalate privileges to other users BUT make it hard for you to spot the last exploit needed to grant you root access to the box. Am going to be showing of some OSCP techniques that have been implemented on this box and also on some active boxes on HackTheBox platform. Basically we start of doing some directory bruteforcing on a website that leads us to a page that has ssh login credentials for a user. We log into the box via ssh and we find a python script that import random.py libraty and we exploit that import function and escalate our privileges to the second users. The second users home directory he has a binary file called teaparty and it calls other system programs and using path variable manipulation we fool the program to execute our script instead of the legit binary escalating our privileges to the next user and using perl capabilities we escalate our privileges to root. For me the box is best rated as a medium box because the privilege escalation techniques will be quite hard to notice and exploit for someone who doesn’t have prior experience with them. Without much say let’s jump in

As always we are going to start off with a nmap scan of the box this gives us a good idea of the services that are running on the box if we get lucky we might find one that is outdated and probably has a 1 day exploit. And use it to get a shell on the box

And we get 2 port are open ssh and HTTP. ssh requires credentials which we don’t have and so I’ll start by enumerating HTTP which has a big attack vector. On opening the webpage we get a standard webpage

I decided to view the source code but found nothing interesting and decided to see if common files like robots.txt existed on the web server but nothing meaningful came up. So i decided to run gobuster a web directory bruteforcing tool

And one unique directory came up /r

i opened the webpage and really found nothing interesting just a message saying keep going

I decided to do another directory bruteforcing with gobuster and found another web page /a

I opened the webpage and still got nothing interesting just a message saying keep going

I did another directory bruteforcing with gobuster and found a web page /b

On opening the web page i still got nothing interesting just a message saying keep going

And i started seeing a pattern the homepage said follow the white rabbit

So i decided to gamble and see if the other directories would spell rabbit and to my surprise it did

But still i got nothing interesting so i decided to view the page source

And to my surprise i got ssh logging credentials

While i was looking at the box later on i found that there was some bit of stenography involves. The homepage had an image

i downloaded it to my local box using wget . I decided to see if i could extract information using steghide. Steghide is steganography program which hides bits of a data file in some of the least significant bits of another file in such a way that the existence of the data file is not visible and cannot be proven.

And i found a text file called hint.txt was hidden in the image which just said

“follow the r a b b i t”

It really wasn’t a necessity for someone to complete the box but it sure helped someone

But we got login credentials i tested them to see if they work on ssh

And voila we have a shell on the box that was easy. Alice’s home directory has two files named root.txt which we don’t have read access to ( no surprises there) and a python script called walrus_and_the_carpenter.py.

I decided to run sudo -l to see what files i could run with sudo command and found i could ran walrus_and_the_carpenter.py as the rabbit user which means that probably this is the attack vector we should be looking at

On opening the python script

I found it had a module called random and a variable called poem

What the script basically does is pick 10 random lines from the poem and outputs them on the screen

What ensures that the lines outputted are random is a python library called random. When we execute the script it fetches the library needed to randomize those lines. This libraries have been stored in predefined locations(directories). And you can use the command below to know those directories

python3 -c 'import sys; print (sys.path)'

So what what the python script does when it is executed is that it goes through all those directories in order to find the one with the random library and when it find it then the python script imports the library and uses it to randomize the output. Like in our case the library is in /usr/lib/python3.6 as seen below

If any of these search paths are world writable, it will impose a risk of privilege escalation, as placing a file in one of these directories with a name that matches the requested library will load that file, assuming it’s the first occurrence. The order at which it loads those path is beginning with our current directory where the python script was executed from

So if i place a malicious python file called random.py in the current directory where the python script resides from we can cause the program to execute what we want and not what the program was intended to do. Lets put that theory to test

I wrote a simple script that executes bash and put it in the same directory as the walrus_and_the_carpenter.py python script since it is going to check the current working directory first for the library

And executed the python script

And voila we have escalated our privileges to the second user. And we have access to rabbit’s home directory

On navigating to his home directory we find an elf binary called teaParty which has a suid bit

I decided to execute it

And got a Segmentation fault (core dumped) printed in the output of the program

Buffer overflow ???????

Probably but i decided to copy the binary into my box and analyze with ghidra

I copied the binary with netcat and did a md5sum on both of the files to ensure that the two binaries were similar

Then decompiled the binary on my box with ghidra and analyzed the main function and what the binary does is just to echo “Segmentation fault (core dumped)” on the screen so no buffer overflows there

But what the binary does is that it calls other system programs like echo and date. Sometimes if the full path of the program is not specified and the program just uses relative path and due to this we can hijack the they way this binary “teaParty” calls these system programs and cause it to execute something we want and now what it is intended to execute

Example is the echo and date command (used in the teaParty binary)

Where the echo binary resides is in /bin/ directory and where date resides is also in /bin/ directory. So what the binary uses is Linux PATH to know where to look for these binaries

If i echo Linux PATH on the box we find it’s the second last one on the PATH

But remember the binary looks for those PATHS in order as listed above when calling the programs so if we can create a malicious script in a directory that we have write access to and add that directory to path (AND THE PATH SHOULD BE BEFORE /BIN/) we can fool the program to execute our script rather than the real program as I’ll show below

Seeing the ghidra output below it show’s a relative path that calls ‘date’ has been specified in the main function of the binary(teaParty)

When the program gets executed date is called which in turn prints the date as shown below

I have write access to /tmp since it is world writable and therefore i can create a malicious bash script called date that just executes bash

Then i added /tmp to my PATH using the command below

export PATH=/tmp:$PATH

Now when i echo my PATH as seen below we see that /tmp has been added to my PATH and it is before /bin

Now i executed the binary teaParty. Now we are the hatter user on the box.

Because instead of it calling the real date system program it executed the one in /tmp since it’s in the beginning of our path

Looking at hatter’s home directory we get his password

But that password works for hatter alone so no quick wins there (no credential reuse is seen in the box). So i decided to ssh into the box as hatter

Since i didn’t find any simple privilege escalation paths i decided to download linpeas on the box so that it can run all checks

And i found something interesting from the linpeas output perl has the following capability set: cap_setuid+ep set

Basically what perl capabilities does is It can manipulate its process UID and can be used on Linux as a backdoor to maintain elevated privileges with the CAP_SETUID capability set. This also works when executed by another binary with the capability set.

By using GTFOBins we get a way to exploit that misconfiguration and escalate our privileges to root

By using the command below i was able to get root on the box

perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/sh";'

And we are root on the box

Now we can submit our flags and get the points

That’s it for now guys till next time take care and if you liked the walkthrough you can clap for me below


Linux privilege escalation cheat sheet

Perl Capabilities