Today, we’ll be continuing with our walkthrough series on interesting Vulnhub machines. In this article, we will see a walkthrough of the Tr0ll: 2 virtual machine.
Note: For all these machines, I have used VMware workstation to provision the VMs. Kali Linux VM will be my attacking box. Also, remember the techniques used are solely for educational purposes’ I am not responsible if the listed techniques are used against any other targets.
Tr0ll: 2 Overview
Download it here.
- The next machine in the Tr0ll series of VMs. This one is a step up in difficulty from the original Tr0ll but the time required to solve is approximately the same, and make no mistake, trolls are still present! :)
- Difficulty is beginner++ to intermediate.
- The VM should pull a valid IP from DHCP. This VM has been verified to work on VMware workstation 5, VMware player 5, VMware Fusion, and Virtual box. Virtual box users may need to enable the additional network card for it to pull a valid IP address.
- Download the Vulnix VM from the above link and provision it as a VM.
- Following the routine from this series, let’s try to find the IP of this machine using Netdiscover. From below, we can see that the IP address is found as 192.168.213.130.
- As is the norm, we ran Nmap scans on all ports (since this is a troll, so not taking any chances). We got hits on 21, 22 and 80 (and robots.txt as well).
- Let’s start collecting more information around the discovered ports.
Below, we can see that we are welcomed by a troll.
- Since we also got a hit on robots.txt, let’s examine its contents as well. Below, we can see that there are lot of directories mentioned here, some of them being .jpgs.
- Browsing all of them and downloading all the images, I found an interesting thing about their size. Most of them are of same size except one, as we can see below.
- Let’s perform some static analysis on the .jpg file. Running strings on the file shows an interesting text which is telling us to go to y0ur_self.
- Following the lead, it is a successful hit with a .txt file.
- Below are the contents of the answers.txt file. This looks full of base64-encoded strings.
- Below is how we are decoding the contents of the answers.txt file.
- Below are the contents of the base64-decoded file.
- Now let’s remove the duplicates from the file. Okay, but now what? What are these strings? If they are passwords, then where are the usernames to try with? We’re completely stuck at this point, so let’s revert back to the enumeration phase.
- With Nmap scans, we found port 21 open also. Let’s try to enumerate that. The username is guessed from the source code on the port 80 landing page.
- We can see that there is a lmao.zip file. We collected that file and tried opening it, but it looks like it needs a password.
- Let’s use fcrackzip (excellent utility) and pass it the unique .txt file generated earlier and the zip file. Below, we can see that we got a hit.
- Unzipping the contents reveals an RSA private key. Woohoo!
- Let’s try to login with this key as user noob… annnnnndddd we got a TRY HARDER LOL!
- Repeating the process with verbose mode on, we see that a COMMANDS has been set up for authorized keys for user noob. So the question is, how can we bypass this?
- After a bit of research it was discovered that Shellshock can be used here. Below, we can see that we have used the Shellshock vector.
- And we are in! First thing I always do is to upgrade my shell.
- Checking for files where SUID bit is set, we got lot of hits. Interesting ones are like nothing_to_see_here/choose_wisely.
Mobile Device Penetration Testing
- Navigating to the abovementioned directory we see three doors, and each of them has an executable. INTERESTING. To add to that, these files are changing folders after a certain time.
- Opening the file in door 1, I got a file r00t and executing it restarts the system.
- Executing another file (r00t) in door 3 locks me out for two minutes. You can look at my struggle below.
- In the meantime, the files changed directories and the only file which was left moved to door 1. This file requires some input.
- Providing some input (As) displays them back.(Dr00lling.)
- Testing it with 500 As shows a seg fault. (Oh yeah!)
- Following the buffer overflow steps, we’re creating a pattern of 500 random characters with pattern_create in Kali.
- Debugging the application within GDB shows that the EIP is overwritten by a value (possibly some part of our random characters).
- Checking the position of the identified value using pattern_offset shows that the position is located at 268.
- Redoing the same exercise again, we now inserted 268 As and four Bs. We got the EIP replaced without Bs, which means that we can control our EIP and thus can use it to point to out shellcode.
So now we’ll make EIP point to the ESP value where our shellcode will reside. But before we do that, we need to find a reliable ESP address. It’s very important to note that OS loader places the environment variable before stack areas that vary, so it will directly affect the ESP address. Also, how the program is invoked is very important.
Below we try invocation with env and unsetting LINES and COLUMNS. We got the ESP address below:
- Grabbing the shellcode from here.
- Invoking the script in same way (env –) we can see that we are root and got Proof.txt. We win!
Awesome box! Some interesting things to know, like the COMMAND setting with keys and the importance of program invocation. This box has less trolls than the original one and offers greater learning.
We will continue this series with more Vulnhub machines. Thanks for reading!