Hands on Hacking: Initiating a Reverse Shell & Conducting Privilege Escalation with BurpSuite

Buckle up! In this lesson, we’ll use BurpSuite to conduct a privilege escalation attack.

We’ll hack into a machine provided by TryHackMe. This is one of my favorite companies for learning CyberSecurity. They have incredible resources for free (and 100% legal) hacking!

Make sure you’ve completed the BurpSuite Part I and Part II introductory posts before proceeding.

Let’s get started!

Deploying the machine

Click here to access the vulnerable room on TryHackMe. You need to make an account to access it.

When it’s time to access their machine, we will connect to TryHackMe’s network using a VPN.

Once you’ve logged in and accessed the room, download your VPN file from here.

Open a terminal in Kali and run this command:

sudo openvpn Downloads/<name_of_your_vpn_file>

When it connects, you’ll see a log message that says “TUN/TAP device tun0 opened.”

Open another terminal and run ifconfig. You can see the new tun0 connection there.

Let’s activate the machine we’ll hack into. Click “Start Machine”

A pop-up box will appear. It says you must use a VPN or AttackBox to access the machine. We’ve already connected to the VPN, so just click “x” in the top right corner.

The page will change. Above the “Task 1” pane, you will see the “Active Machine Information” section.

“Title” is the machine name. “IP Address” is the IP of the vulnerable machine. “Expires” shows how much time remains until the machine expires.

In the terminal, try to ping the machine with this command:

ping <vulnerable_machine_IP>

It sometimes takes a few minutes for the machine to respond. But if you get a ping back, you’re good to go.

Also, now that we’ve got the machine up and running, we will not be following the list of tasks in TryHackMe. Just follow this guide.

Reconnaissance

Time to find the open ports and services we can exploit.

Let’s scan the machine with Nmap. Run this command:

sudo nmap -A -vvv <vulnerable_machine_IP>

The -A option enables OS detection and version detection, script scanning, and traceroute.
The -vvv option is the highest level of verbosity.

The scan gives us some fantastic information about the target:

We can see 2 open ports on the target: port 22 (running ssh) and port 80 (running http).

The versions of these services are marked by the blue rectangles. Additional information about port 80- the http methods, which indicate what actions can be performed on the http server- are shown in the brown.

Let’s start with port 22. First, we’ll use Searchsploit. This tool will show us known vulnerabilities for a given version of any service. Run this command:

searchsploit <service & version>

According to Searchsploit, there are vulnerabilities in OpenSSH through version 7.7.

Username enumeration is beyond the scope of this lesson, but you can read about it here. This video will walk you through performing the exploit on the OpenSSH server.

If you follow along, you will see that an attacker can use this to determine whether certain usernames exist or not on the server. But that’s it- no further information is disclosed. Red Hat Product Security itself has rated this issue as having low severity.

Let’s move on to port 80.

Navigate to the target’s IP address in your browser. It’s just a simple webpage. Let’s check the source code (hold down ctrl + u if you’re on Firefox.)

Nothing interesting here either.

Let’s try fuzzing the web directories. This technique will help us find paths that might be hidden, which we can potentially exploit. We’ll use BurpSuite.

Fuzzing with BurpSuite

Open BurpSuite and open either:

BurpSuite’s embedded browser
Your preferred browser (if you have FoxyProxy installed. Make sure The BurpSuite Proxy is turned on.)

Navigate to the IP and add any directory. This means to modify the URL so that it heads to any directory, like this:

The request will be intercepted in Burp.

Right click anywhere in the request and send it to Turbo Intruder.

A window like this will appear:

We need to determine:

The request URL that we’ll fuzz (the red box)
The place we’ll insert the wordlist (the orange box)
The button that starts the attack (the green button)

For the wordlist, let’s use common.txt from SecLists. It comes on Kali by default and is in this path:

usr/share/wordlists/seclists/Discovery/Web-Content/common.txt

If you don’t have this file on your computer, you can download it by running this command:

apt -y install seclists

Back to BurpSuite.

Replace the home with %s. This is a placeholder where the directory words list will be fuzzed.

Now change the wordlist path to the SecLists common.txt file path.

Now click the attack button. It will take a few minutes. After it finishes, double-click the status tab.

Most of the directories have a 400 status code, which means that something went wrong with the request. The directory could be forbidden, not found, gone, etc.

4 directories have a status code of 301. This means redirection- when we made a request to the server, we were sent to a new URL.

The css and js are common in all web applications, so that’s not interesting. However, there are 2 new directories: panels and uploads.

Let’s navigate to both and see what’s inside. You can hold down ctrl + r to send the request to the repeater, or directly browse the directories.

It looks like the panel directory has an upload function.

The uploads directory seems to store files uploaded from /panel.

Let’s test this out. Upload an image and check the uploads directory.

Uploading gives a success message (in Portuguese.)

Now check the uploads directory:

There’s the image I uploaded.

This is great news for us. The upload function means we have an entry point into the server. We also know which type of server it is from the nmap scan (Apache.)

Apache often runs PHP applications. Let’s see if we can upload a PHP shell and get initial access to the machine.

Download the php-reverse-shell file here.

Vim that file. Change the IP address on line 49 to your tun0 IP.

Now head to /panel on the website and upload the shell file. Make sure BurpSuite is running, and that you used the browser connected to Burp’s proxy.

We get this error message. It means “PHP is not allowed!”

Let’s try bypassing this. We’ll upload the file, but with a different extension.

You’d be surprised how often this works. Many developers code applications to block a small number of file extensions. PHP runs on several file formats, like php4, php5, phtml, etc. We can use BurpSuite to fuzz different file extensions and see if one is accepted by the target.

Go to BurpSuite → Proxy → Intercept and turn Intercept on. Upload the file again.

It will capture the request.

Send the request to the Intruder.

Clear all preset positions. Then highlight the PHP extension and click add.

Let’s insert the payloads. Head to the payloads tab within Intruder. Type each payload in the list below and click add.

It’s a small list, which is why we’re doing it manually.

Click start attack. The status code of 200 means they’ve all been uploaded!

Let’s set a listener on the port we specified in the php-reverse-shell script (1234.)

Note: The “nc” command stands for Netcat.

Turn off Intercept and navigate to the uploads directory. All the files have been uploaded.

Click one and see if it gives a response back.

It seems that the server doesn’t accept all extensions. However, php5 and phtml are executed.

Now you have a reverse shell!

Escalating Privileges

For the “Escalating Privileges” section of this lesson, I used a different virtual machine (and thus a different IP.)

My new IP address is 10.10.61.160 – not 10.10.16.131, as it was earlier.

Reverse shells often lack key features. Pressing the up and down keys create errors, and you can’t tab complete, use ctrl + c, or clear the screen. “Stabilizing the shell” means to upgrade the shell so that it includes the features we’re used to.

Let’s stabilize the shell. Run this command:

python -c 'import pty; pty.spawn("/bin/bash")'

This gives us what’s called the “TTY Shell,” which is an interactive shell with all the features we want.

Now that we’ve got our stabilized shell, and we can issue commands to the target, let’s go for privilege escalation. This is the process of escalating our privileges on the machine from lower to higher, so we won’t have any issue executing commands.

We’ll use the SUID binary method for privilege escalation.

I recommend reading the hyperlink for a detailed overview. For now, here’s a basic definition (taken from the SUID binary hyperlink.)

Linux has several access attributes that can allow users or groups to perform certain actions against files, such as execute, modify or view files.

SUID (Set User Identification) and GUID (Set Group Identification) are permissions that allow users to execute a binary or script with the permissions of its owner (SUID) or of its group (GUID).

Some binaries have this permission by default as they require to perform certain actions with elevated privileges, for example the passwd binary needs to run as root in order to change a user’s password, although certain binaries can be exploited to escalate privileges if they have the SUID bit set.

We can check for binaries with SUID permissions by using one of these 2 commands.

`find / -perm -4000 -type f -exec ls -la {} 2>/dev/null \;`

… and:

`find / -uid 0 -perm -4000 -type f 2>/dev/null`.

Let’s use the first one and find the executable.

The s means “SUID”, the owner is root, and the executable is Python.

This website has a list of commands that can be used to exploit SUID vulnerabilities and escalate privileges. Visit it and type “python” in the search bar.

Click the “SUID” button under the “Functions” header.

All we need is the second line of the script (in the red rectangle.) Before you run this code, change the “sh” to “bash.” It will give us a direct bash shell, which has more features then the sh shell.

Now we’re root!

Let’s get the user and root flag by executing this command:

echo "The User flag is $(cat /var/www/user.txt) and the root flag is $(cat /root/root.txt)"

Nice work! When you set a root flag in Linux, it allows the user to have root privileges. They can perform any action on the system, regardless of permissions.

Our main objective is finished. Before we close, let’s find out why these vulnerabilities exist.

Discovering the Cause

We’ll start with the vulnerable upload function.

The website is in the /var/www/html directory.

If I recall correctly, the vulnerable web page was in the panel directory. Go ahead and check:

There’s an index.php file. Our shell is not fully stable at this time, so we can’t edit it.

We’ll need to move the index.php file somewhere it can be edited. Let’s send it to our host computer.

Start by copying the index.php file to the uploads directory, since we can access that directory. Remove the .php extension.

Navigate to the /var/www/html directory, then run this command:

Pivot to your host computer. Make a directory to store your file. Then download the file from uploads using wget:

wget http://<vulnerable_machine_ip>/uploads/index

Note: I used a different virtual machine for this section of the lesson, so the IP is different than the previous machine’s IP. You don’t need to change anything.