Trolls are still present!

I enjoy a good a challenge, and I thoroughly enjoyed getting through Maleus’
(@maleus) Tr0ll: 1 boot2root VM. I submitted my Tr0ll:1 walkthrough to vulnhub and shortly after gloating about my success on twitter, I am presented with the following reply:

Challenge accepted (@maleus)! Bring on Tr0ll: 2!

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! :)

Let’s get this troll party started. First up as always, let’s find our host with netdiscover.

With our target host (172.16.66.134) found, let’s enumerate which ports are open with nmap.

Familiar friends; FTP (21), SSH (22), HTTP (80). Surely there has to be a troll to greet us straight up? Let’s check port 80.

Good stuff! We haven’t been let down and Maleus has kept the theme the same. Nice. Let’s take a look at the page source.

Dodgy use of comment tags, but that’s about it. Let’s continue to hunt down these trolls. wfuzz, what can we find?

Nothing overly exciting here just yet. When we performed our nmap we noticed there is a robots.txt file present. Perhaps it will have something exciting for us?

You dirty troll. I might be a noob in the great scheme of things, but there is no way I’m going to type those out manually in a browser to see if they exist. wfuzz, help me out please.

Much nicer. After browsing to each of the directories I am presented with the same image:

Hmm. What about the page source, let’s take a look there:

Taking a look at the other 3 URL we are presented with the same commentary. Let’s continue to follow the troll and see if the images are different. It’s not pretty, but I run the following bash one-liner to get 4 different versions of the JPG:

I run exiftool on each of the files to see if there is any code or any other presents hidden in the file. Nothing out of the ordinary apart from cat_the_troll.jpg.2 being 16 kB in size, and the other 3 images being 15 kB in size.

So, exiftool didn’t help us out. If you have read any of my other posts, you would know that strings is one of my favourite binaries to run first up. Let’s run strings against the larger image file.

Look Deep within y0ur_self for the answer. Sure, why not. Keeping with our Tr0ll: 1 tradition, let’s go back to our webserver troll friends:

I’m a big fan of finding answers. Tell me your secrets:

Nice. 1.4M of guff. Does the guff look familiar to you? Correct… base64 encoded by the look of it. Let’s decode and see what we have:

Excellent. Our hunch was correct. Looks to be some sort of dictionary file. This next phase of the attack took me quite some time. I tried wfuzz’ing the webserver and bruteforcing SSH/FTP credentials using the answer_decoded.txt dictionary file. Nothing, Nada, Zilch. I was certain that this was a useful file for bruteforcing a connection, however I felt like I was searching for a needle in haystack not knowing what username to use. I exited each bruteforce attempt after an hour or so out of frustration and impatience. Surely Maleus wouldn’t be heartless enough to make us wait for ncrack, hydra, or medusa to attempt 99,157 different login attempts? It is a tr0ll box; but come on!

Enter stage left a lightbulb moment! Do you recall the source code from the default webpage?

Author: Tr0ll. This could be a username, couldn’t it? And what’s the first password you try when authenticating as a user? Correct… use the username as the password.

We’re in with Tr0ll:Tr0ll! … or … we were. Damn trolls have kicked us out.

At least we now have some credentials and can stop wasting time bruteforcing. I’m embarrassed to say this, but I tried again and again and again, getting a disconnect each time. I felt like a user who keeps hitting print screen each time a print job doesn’t come out of a printer. I have credentials; what can I do? Surely the dictionary file was just the trolls having fun and messing around with us? Let’s give FTP a go before resorting back to bruteforce attempts?

Voila! FTP works, and we have a file called lmao.zip. Not trusting the trolls I confirm that file is actually a Zip archive.

Looks good. Obviously next step, unzip.

Urghh. I hate passwords but this must be where our dictionary file comes in handy. Let’s use fcrackzip to make short work of this dictionary file.

What I enjoy about this challenge and it’s predecessor is it’s ability to live up to the Tr0ll tag. Nicely done. Time to grab the contents and have a look inside.

A nice reward. Looks like we have an SSH RSA private key. Interesting, we already have creds for the user Tr0ll, so who could this RSA key belong to? This was easy and stood out quite easily. Did you notice when we went to unzip the lmao.zip file we were prompted with ‘noob’ password? Thought you did. Let’s try SSH’ing as noob with this RSA key:

Oh come on! The RSA key works, but once again we’re kicked out of our SSH session. Maleus… all throughout my OSCP and OSWP courses I got plenty of “TRY HARDER” responses; I don’t need it from your trolls too! ;)

So we have two possible ways in at this stage. The first way is SSHing in with the credentials Tr0ll:Tr0ll. The second way is SSHing in as noob using the RSA key. We’ll spend some time with option 2 at this stage. Why? Simple. Notice that when we attempt to log in we get a message of TRY HARDER LOL!? This makes me believe that we get a shell, and then ‘something’ echoes those strings and then kicks our session. With the Tr0ll login, it looks more like we have no shell or something else unhelpful is happening. Having an RSA key we should be able to execute code prior to the string echo and logoff. Let’s have a crack!

Do you recall the recent CVE-2014-6271 vulnerability affecting Bash up to version 4.3? Being the flavour of the month in pen-testing circles, we have to use this as our starting point. (Side note: If you are new to pen-testing, make sure you include this bug in your reports. It is likely you will be able to use it as a page filler in your report.) Being a network centric person, I always like to start my checks by pinging my own host. For this, I simply open a tcpdump session listening for ICMP traffic. Let’s test if we can leverage from this bug:

Nice. Looks like we can leverage from this. Sorry? Why didn’t we just try a reverse shell straight away? As I said, I’m network centric, and enjoy the simple things in life. Moving on, obviously let’s get a reverse shell:

Sigh. These trolls are starting to annoy me a little. No netcat hey. Hmm…. how about an old school Bash reverse shell?

Finally! We have a limited shell! Onwards and upwards as they say. As per my usual process, let’s look for setuid binaries:

And the trolls continue. Looks like we’re going to have a good old classic game of “I’ll take what’s behind door number X Larry!”

OK. Choose wisely. I have nothing.. this is going to be hit or miss. Let’s start with door number 1 Larry!

Door 1 is a fail and kicks our session. Nicely played troll. I’m not going to follow the bouncing ball, so I’ll take what’s behind door number 3 Larry!

Hang on a second! Same outcome. Door 2? Exactly the same again!

Door 1 again? Something different…

Ok.. this is just a little annoying…. our ./r00t binaries are copying/moving between doors. Time to check if the binaries are different sizes and if we can nail down the one which allows some input.

It’s a boot2root, and we get to provide input to a binary. This screams buffer overflow to me… let’s test it out:

Bam! Segfault. Next step is to find where we are overwriting EIP, so we can point it at ESP. There are many ways to do this, however my favourite is to use metasploits pattern_create.rb and pattern_offset.rb scripts. First up, let’s create a pattern of 666 characters:

Next, let’s use our random pattern to find the exact location we start to overwrite EIP:

According to our debugger we crashed at address 0x6a413969, so let’s find our exact offset using the pattern_offset.rb script:

Nice. Our offset is at 268. So let’s add a little padding for good luck and find the address of ESP with our gdb session:

Thank you gdb… as you can see our ESP is at 0xbffffb80. We’re getting closer, and our buffer overflow currently looks like this:

$(python -c 'print "A" * 268 + "\x80\xfb\xff\xbf" + "\x90" * 13')

Are you following where we are at? The reason I do these write-ups is to help people learn if I can. Skip to the next paragraph if you’re all over it so far. Right… We have found that 268 bytes will get us to EIP, which is a pointer to our next instruction. We then give EIP our 4 byte value of ESP (0xbffffbe0), which means we have control of our exploit buffer and should be able to divert the execution of the program to our choosing. It is always nice to ‘pad’ our upcoming shellcode, and for that we provide some more NOPs (No Operation instructions) in the form of “x90”.

Time to exploit. For this exercise I will be using the Tiny Execve sh Shellcode. Our exploit now looks as follows:

$(python -c 'print "A" * 268 + "\x80\xfb\xff\xbf" + "\x90" * 13 + "\x31\xc9\xf7\xe1\xb0\x0b\x51\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\xcd\x80"')


Let’s cross our toes, fingers, and any other appendages you may have and give it a crack. Drum roll please!

ARGHHHH! You #$#@@#@! troll! I was feeling confident, and perhaps somewhat cocky. I forgot to check if we were still playing with the same binary. GRRRR! Nicely played Maleus… nicely played. Note to self… du -h and find the larger binary before executing exploit code.

Ahem. Take 2. Let’s cross our toes, fingers, and any other appendages you may have and give it a crack. Drum roll please!

BAM! Gotcha Tr0ll!

Thank you so much Maleus for the challenge; it was a cracker! The next time you question whether I’m brave enough to take on another troll I will take my time before answering ;) Thanks also to vulnhub for making the challenges available.

Until next time, tight lines and may you pop shells often.