The Troll 1 Vulnhub Walkthrough

There are moments that are satisfying in that they validate the reason for doing this site. The Troll 1 Vulnhub Walkthrough is one of those. Nearly all of the other tutorials on various sites with names like hack3rbl0g.io, etc leave out critical details that leave you clueless and frustrated! They were able to move from step A to step B, but as to how (let alone why in most cases) they leave you in the dark.

The Troll 1 Vulnhub Walkthrough is one of the finer Vulnhub VMs to practice with for passing the OSCP exam. It is very realistic and a way to practice Linux privilege escalation which is a weak area for many.

Here are the areas and skills we will touch on in this walkthrough:

• Information Gathering
  • Using Nmap
  • Using AutoRecon
• FTP Exploitation
  • Logging into FTP server using the anonymous account
• Linux Privilege Escalation
  • SUID File Exploitation
  • Cronjob Exploitation

Think it was too easy or too f$%@#@! difficult? Let me know on Twitter @ehgehgehg

Information Gathering

nmap -sV -sC -sT 10.0.0.18 -oA scan

Running an AutoRecon scan against the target returns the same results.

From the Nmap and AutoRecon scans we can tell there are some running services.

• SSH
• FTP
• HTTP

Let’s take a look at the running web service. This is always an easy first step that is to navigate to the remote site in a browser to see what is running.

This is the latest version of gobuster by the way so it may be different than what you are used to.

robuster dir -w /usr/share/seclists/Discover/Web-Content/common.txt -u http://10.0.0.18

Look at the new directory named ‘secret’.

Let’s try the FTP service and since the nmap scan determined that anonymous logins are enabled, that is where we will start.

Upon logging in as anonymous it is clear there is a file named ‘lol.pcap’.

Opening the file in Wireshark reveals some antagonizing text. This text actually holds the location name of a hidden web directory.

Assuming that this secret is going to be like the others, plug in the string into the URL for a possible match. And just like that another directory is revealed. This one contains a binary named “roflmao”.

The file is a 32-bit executable and running it does not lead to anything so a static analysis is the next step.

Using strings we see that there is an unusual message.

Going off of the same idea, find a clue then put it in the URL, we see that there is a username list.

Along with the password to use.

Use hydra to test the possible user pass combination.

 hydra -L Users -p Pass.txt ssh://10.0.0.18

SSH into the target.

After logging into the remote target it seems an automated timed script is killing the session, troll!

Always Have a Backup Plan

One of the first things to do always is to check the kernel version. Once that is found available exploits can be used on the target.

I’ll now explain why it’s important to always have a backup plan for compiling exploits.

Here’s How I Solved It

sudo apt-get install gcc-multilib g++-multilib
gcc -m32 37292.c -o ofs

Running the uname -a command on the target system shows that it is i686 arch. i686 means 32bit.

And even when compiled on the target architecture it does not run correctly.

That Didn’t Work

Since that did not work it is now necessary to run regular searches for common misconfigurations of the system.

find / -name cronlog 2>/dev/null

cat /var/log/cronlog

find / -name cleaner.py 2>/dev/null

It appears that a script is run at regular 2 minute intervals, named ‘cleaner.py’. The script does a seemingly unimportant task of removing the tmp folder ( another troll move undoubtedly ) of which we are unaffected by because we are not running from the tmp folder. I chose to download the exploit compiled earlier into /tmp/var.

Create a SUID Binary

The aim of this step is to create a binary, get it to be owned by root, and have its sticky bit set so it can *drumroll* execute.

Compile the suidbin file.

gcc -m32 -o suidbin suidbin.c

Now that the exploit is successfully compiled it is ready to be hosted and executed on the victim machine.

#!/usr/bin/env python
import os
import sys
try:
    os.system('chown root:root /var/tmp/suidbin; chmod u+x /var/tmp/suidbin')
except:
    sys.exit()

• chown root:root /tmp/suidbin
• chmod 4755 /tmp/suidbin

The first command to get the script to run is ‘chown root:root /var/tmp/suidbin”. This command effectively changes the ownership of the suid bin file we created to be owned by [user]root and [group]root. Why? So that when it executes it will execute with the permissions of root.

The second command to work into this exploitation is ‘chmod 4755 /var/tmp/suidbin’. This command changes the permissions of the suid bin file made earlier to be world-executable. That means that any use, including overflow, can execute it and since it is owned by root then it will run with those permissions.

Upon waiting a few minutes the cleaner.py script executes and grants the permissions our overflow user needs to be able to execute it. By running the suid bin file we have just spawned a new bash shell with root privileges. After this you are able to navigate to the home folder of root, which is /root and gather the final flag.

To Review:

Linux privilege escalation is not always so simple as a compiling and executing a kernel exploit. In reality it is more difficult and that is why this vulnhub VM is so realistic. The kernel exploit would not compile correctly even when compiling it on an older Ubuntu OS. Therefore it was necessary to escalate privileges to root by good old fashioned Linux privilege escalation techniques.