GoodGames
https://app.hackthebox.com/machines/GoodGames
Summary
The security assessment of the GoodGames infrastructure revealed a critical chain of vulnerabilities starting from an unauthenticated SQL Injection on the public-facing web application. This flaw allowed for the extraction of administrative credentials, leading to a secondary Server-Side Template Injection (SSTI) within an internal management portal. Exploitation of the SSTI resulted in Remote Code Execution (RCE) as a root user within a containerized environment. Finally, a misconfiguration in the Docker volume mounting strategy, combined with credential reuse, allowed for a complete breakout from the container to the host system, resulting in full administrative compromise of the server.
Kill Chain
Reconnaissance
Active Scanning (T1595) was used to identify open ports and service versions.
Initial Access
Exploitation of a Public-Facing Application (T1190) via SQL Injection granted access to the web portal.
Execution
Command and Scripting Interpreter (T1059) was leveraged via SSTI to execute a Python-based reverse shell.
Persistence
Valid Accounts (T1078) were utilized for SSH access to the host after discovering credential reuse.
Discovery
File and Directory Discovery (T1083) identified the shared volume mount points and the augustus user.
Lateral Movement
Remote Services (T1021.004) via SSH allowed movement from the container to the host.
Privilege Escalation
Abuse of SUID/SGID Executables (T1548.001) via the shared Docker volume allowed for the elevation of privileges to root on the host.
Reconnaissance
Initial interaction with the target began with a connectivity check and service discovery to define the attack surface.
Host Discovery
#attack/T1018
An ICMP echo request was dispatched to the target IP 10.10.11.130. The returned TTL of 63 suggests the host is likely a Linux-based system.
attacker> ping -c 1 10.10.11.130
PING 10.10.11.130 (10.10.11.130) 56(84) bytes of data.
64 bytes from 10.10.11.130: icmp_seq=1 ttl=63 time=167 ms
--- 10.10.11.130 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 167.227/167.227/167.227/0.000 msNetwork Enumeration
#attack/T1046 #attack/T1595
A full TCP port scan was conducted using rustscan to identify open ports and service versions.
The scan revealed a single open port (80) running an Apache web server. Notably, the http-server-header indicates the backend is powered by Werkzeug 2.0.2 and Python 3.9.2, which is characteristic of a Flask-based web application. The service also leaked a hostname: goodgames.htb.
The identified hostname was added to the local /etc/hosts file to enable proper virtual host routing.
Web Exploitation
A secondary scan using whatweb confirmed the presence of Python 3.9.2 and the Werkzeug framework. The application employs Bootstrap and JQuery for its frontend.
The landing page presents a gaming community and store interface. A login function was identified, providing a potential entry point for authentication-based attacks.
Authentication Bypass (SQL Injection)
#attack/T1190 #owasp/A05_2025
During the evaluation of the /login endpoint, a vulnerability to SQL Injection (SQLi) was identified in the email parameter. By submitting a tautology, it was possible to bypass the authentication mechanism.
Finding: SQL Injection (Authentication Bypass)
Affected Asset:
http://goodgames.htb/loginSeverity: Critical
Vulnerability Type: Unauthenticated SQL Injection
Reproduction Steps:
Navigate to the login page at
http://goodgames.htb/login.Intercept the login request using a web proxy.
Inject the payload
admin@goodgames.htb' or 1=1-- -into theemailfield.Observe the successful redirection and the issuance of a session cookie.
Remediation: Implement prepared statements with parameterized queries for all database interactions to ensure user input is treated as data, not executable code.
The following POST request demonstrates the exploitation of the vulnerability:
The server responded with a 200 OK and set a session cookie, indicating a successful bypass as the administrative user.
Authenticated Access
The session cookie was imported into the browser, granting access to the internal dashboard.
Upon logging in, an "Admin Panel" icon became visible. Inspecting the link revealed a new internal subdomain: http://internal-administration.goodgames.htb/.
This subdomain was added to the /etc/hosts file for further enumeration.
Internal Admin Enumeration
#attack/T1083 #attack/T1592
Upon gaining authenticated access to the primary site, an administrative interface was discovered at http://internal-administration.goodgames.htb/. This portal appears to be a separate Flask-based application used for backend management.
Database Exfiltration via SQL Injection
#attack/T1190 #owasp/A05_2025
The previously identified SQL Injection vulnerability on the /login endpoint of goodgames.htb was leveraged to perform data exfiltration. Since the application returns different response lengths based on query success, a Union-based approach was utilized to extract sensitive information from the backend database.
Finding: SQL Injection (Data Exfiltration)
Affected Asset:
http://goodgames.htb/loginSeverity: Critical
Vulnerability Type: Union-Based SQL Injection
Reproduction Steps:
Submit a
UNION SELECTpayload to theemailparameter.Determine the number of columns using
ORDER BY.Use the reflected column to display output from database functions (e.g.,
version(),user()).Query the
information_schemato map the database structure and dump theusertable.
Remediation: Implement strict input validation and use parameterized queries. Ensure the database user has the least privilege necessary.
1. Column Enumeration
The number of columns in the current query was determined using the ORDER BY clause. A response indicating a successful login was received with ORDER BY 4, while ORDER BY 5 resulted in an error, confirming a 4-column structure.
2. Identifying Reflection Points
A UNION SELECT statement was used to identify which column reflects data back to the user interface. The fourth column was found to be rendered within the "Welcome" message on the successful login page.
Prior to database dumping, a quick test for Server-Side Template Injection (SSTI) was performed by injecting {{7*7}}. However, the payload was reflected literally, suggesting the input is not being processed by the Jinja2 template engine at this specific reflection point.
3. Database Schema Mapping
With the reflection point confirmed, the database environment was enumerated. The system was identified as MySQL 8.0.27, running with the user main_admin@localhost on a database named main.
Further enumeration of the information_schema.tables and columns identified a user table containing sensitive credentials.
4. Credential Extraction and Cracking
#attack/T1110_002 #attack/T1212
The email, name, and password columns were dumped from the user table, revealing a credential.
The administrative hash (2b22337f218b2d82dfc3b6f77e7cb8ec) was identified as a standard MD5 hash. An offline brute-force attack was performed using John the Ripper and the rockyou.txt wordlist.
Credentials Obtained
The administrative password for admin@goodgames.htb was successfully recovered: superadministrator.
Execution
Server-Side Template Injection (SSTI)
#attack/T1190 #owasp/A05_2025
With the administrative credentials admin:superadministrator recovered from the primary database, access was gained to the internal management interface at http://internal-administration.goodgames.htb.
Upon authenticated access, the "Settings" page was identified as a potential vector for input-based vulnerabilities. Specifically, the field responsible for updating the user's name reflected input back to the user profile header.
Testing for Server-Side Template Injection (SSTI) was performed by submitting the mathematical expression {{7*7}}. The application rendered the result 49 in the profile view, confirming that the backend template engine—identified as Jinja2—was executing code within the double-curly-brace delimiters.
Finding: Server-Side Template Injection (SSTI) to RCE
Affected Asset:
http://internal-administration.goodgames.htb/settingsSeverity: Critical
Vulnerability Type: Remote Code Execution (RCE) via SSTI
Reproduction Steps:
Log in to the internal portal using administrative credentials.
Navigate to the
/settingsendpoint.Inject a Jinja2 payload into the name field (e.g.,
{{ cycler.__init__.__globals__.os.popen('id').read() }}).Save the settings and view the profile page to trigger the execution.
Remediation: Configure the template engine to use a "Sandbox" mode that restricts access to dangerous global objects or, preferably, avoid rendering user-supplied input directly through the template engine.
RCE and Environment Discovery
To confirm Remote Code Execution (RCE), a payload targeting the os.popen method was utilized. The execution of the id command revealed that the application was running with root privileges.
Further inspection using hostname -I indicated that the application was hosted within a Docker container on the 172.19.0.2 network.
Initial Access
#attack/T1059_004
To establish a more stable interactive session, a reverse shell payload was injected through the SSTI vulnerability after verifying outbound connectivity via curl.
A listener on the attacker machine caught the incoming connection:
Root Shell in Container
A fully interactive shell was obtained as the root user within the Docker container.
The shell was stabilized using standard TTY techniques to allow for proper command navigation and signal handling.
Enumeration of the /home directory revealed a user named augustus. Although the current session was root, the user flag was located within this home directory.
Lateral Movement
Container Escape & Host Discovery
#attack/T1611
While operating as root within the Docker container, a discrepancy was noted: the directory /home/augustus existed despite the augustus user not being present in the container's /etc/passwd file. Investigation of the mount points confirmed that this directory is a shared volume mounted from the host's physical partition (/dev/sda1).
The container's network interface (eth0) showed an IP address of 172.19.0.2. Based on standard Docker gateway configurations, the host was assumed to be 172.19.0.1. A connectivity check confirmed this.
An internal port scan was performed from the container to the host using a Bash-native TCP scanning technique, revealing that the host had SSH (Port 22) and HTTP (Port 80) open.
Establishing Host Access (Credential Reuse)
#attack/T1110 #attack/T1078 #attack/T1021_004
A credential reuse attack was attempted using the password superadministrator (previously recovered from the SQL injection) for the augustus user identified via the shared home directory.
Finding: SSH Credential Reuse
Affected Asset:
172.19.0.1(Host Machine)Severity: High
Vulnerability Type: Password Reuse
Reproduction Steps:
Identify the host IP address from within the container.
Use the
augustususername and the passwordsuperadministratorto authenticate via SSH.
Remediation: Implement a unique password policy and ensure that service-level credentials are not shared with system user accounts.
Authentication was successful, providing a shell on the host system.
Privilege Escalation
SUID Abuse via Shared Volume
#attack/T1548_001 #attack/T1611
The shared volume at /home/augustus provides a bridge between the container's root context and the host's augustus context. Because the container's root user has full control over the files in this shared directory, it is possible to create a SUID binary on the host by manipulating the file from the container.
Finding: Privilege Escalation via Shared Volume (SUID)
Affected Asset:
172.19.0.1(Host Machine)Severity: Critical
Vulnerability Type: Insecure Docker Volume Mounting (Container Escape/PrivEsc)
Reproduction Steps:
On the host as
augustus, copy/bin/bashto the shared directory/home/augustus/.In the container as
root, change the owner of the copied bash toroot:root.In the container as
root, set the SUID bit on the binary (chmod 4777).On the host as
augustus, execute the binary with the-pflag.
Remediation: Avoid mounting host sensitive directories into containers. If a mount is necessary, use the ro (read-only) flag or implement User Namespacing (userns-remap) to prevent container root from mapping to host root.
1. Preparing the Binary (Host)
On the host machine, the standard Bash binary was copied to the home directory.
2. Escalating Privileges (Container)
Returning to the container session, the root user modified the permissions of the binary located in the shared volume. By changing the owner to root and applying the SUID bit, the binary became a vector for privilege escalation on the host.
3. Execution (Host)
Back on the host SSH session, the augustus user executed the modified binary with the -p flag to preserve the effective user ID (EUID) of root.
The root flag was retrieved from the administrative home directory:
Last updated