DEV Community: Al Amrikasir

CTF Write-Up: 2024 Haunted Brewery - Brew4u Challenge

Al Amrikasir — Wed, 06 Nov 2024 04:22:42 +0000

Introduction

After tackling the “Raise the Dead” challenge, I was ready for the next spooky adventure. This time, I found myself diving into the mysterious Brew4u challenge. With the Haunted Brewery’s annual contest in full swing, this challenge hinted at secrets hidden within the brewery’s system. The goal? Submit a custom brew description while staying alert for any clues that might lead to the legendary BrewMaster’s secret recipe. Let’s see what mysteries lie behind this web exploit!

Challenge Description and Clues:

The Haunted Brewery Brew4u Contest is open to patrons who can design the best custom brew! Participants submit descriptions of their dream beer to the BrewMaster for a chance to have it featured in the taproom.

However, this year, something feels off. Rumors suggest the brewery's submission system is hiding a secret. Some say the legendary BrewMaster's secret-ingredient recipe is buried within the system, accessible only to those with a keen eye for detail.

Your mission: Submit a description for your custom brew, but be on the lookout—hidden within the system’s responses could be the clues you need to uncover the BrewMaster's secret recipe. The right approach might reveal more than just a drinkable masterpiece.

Connect to the challenge: https://hackersnhops-stop-changing-the-flag.chals.io/

Investigating

First, I started by investigating where the “secret ingredients” could be hiding. It turns out there’s a flag text file located within the app or brewery files, holding the information we need.

Next, I decided to test the example brew submission. After entering it, the page redirected me to:

https://hackersnhops-stop-changing-the-flag.chals.io/ssti

This endpoint responded by returning the description of the recipe I had just submitted.

Understanding SSTI (Server-Side Template Injection)

The URL endpoint I was redirected to, /ssti, gave me a clear hint that the challenge involves a Server-Side Template Injection (SSTI). SSTI occurs when user input is improperly handled by a template engine on the server side. This allows attackers to inject malicious code into the template, which can then be executed by the server.

In this case, the page was returning the description I submitted, but there’s a possibility that we can manipulate the input field to execute code on the server and extract sensitive data, like the hidden flag. By exploiting SSTI, attackers could potentially access environment variables, files, or even execute arbitrary code if the template engine is vulnerable.

Knowing this, I decided to test different payloads to see if I could inject something that would reveal more than just the description.

Investigating the Response Header

Next, I focused on analyzing the response headers received after submitting my brew recipe. One detail that caught my attention was the Server header:

Server: Werkzeug/2.0.3 Python/3.9.19

This indicated that the application was running on Werkzeug, a WSGI utility library for Python, and specifically, version 2.0.3 with Python 3.9.19.

Werkzeug is often used in web frameworks like Flask, which could give me an insight into the underlying framework and help me identify potential weaknesses or misconfigurations. Knowing the server version could also help me in finding specific exploits related to this software.

Template Injection Attempt with `{{ config }}`

I decided to try injecting a simple payload into the template engine to see if I could access any useful server-side information. I used the {{ config }} payload, which is commonly used in Flask (since it’s powered by Werkzeug) to access the application’s configuration settings.

To my surprise, the response returned a detailed dictionary of the app’s configuration, which included various settings like:

<Config {'ENV': 'production', 'DEBUG': False, 'TESTING': False, 'PROPAGATE_EXCEPTIONS': None, 'SECRET_KEY': None, 'PERMANENT_SESSION_LIFETIME': datetime.timedelta(days=31), 'SESSION_COOKIE_NAME': 'session', ...}>

This exposed a range of useful information about the server environment, including the environment mode (production), session settings, and more. Notably, the SECRET_KEY field was None, which could be a potential weak spot for further exploitation.

At this point, I realized that the app might not be handling user input properly, making it vulnerable to further SSTI attacks.

More Exploit

Encouraged by the results of injecting {{ config }}, I decided to push further by trying additional payloads to see what else I could uncover. I started by injecting {{ request }} to check for any information about the current HTTP request. This returned useful details about the request object.

Next, I attempted {{ request.application }}, which is another common payload used in Flask applications to access more specific server-side details. The result was:
<bound method Request.application of <class 'flask.wrappers.Request'>>

This output indicated that the request.application method was exposed. Although it wasn’t directly revealing any immediate sensitive data, it did show that the Flask request object had exposed server-side methods that could potentially be leveraged in further attacks.

At this point, it was clear that the app was highly vulnerable to Server-Side Template Injection (SSTI), and it was possible to continue exploring for ways to extract more critical information or trigger further vulnerabilities.

As I was looking for ways to access more sensitive information, I realized that I might be able to view the contents of the current working directory. To achieve this, I injected the following payload:

{{ request.application.__globals__.__builtins__.__import__('os').listdir('.') }}

This payload exploited the os module (which is part of Python’s standard library) by accessing it through the import function. The result was an array containing the names of files and directories in the current working directory.

This allowed me to see what files were present on the server, which could be useful for further exploration. This step confirmed that the server’s security was severely compromised, as I had full access to potentially sensitive directories and files on the system.

['flag.txt', 'app.py', 'requirements.txt', 'Dockerfile', 'static', 'templates']

Among these files, flag.txt immediately stood out as a potential candidate for containing the flag. This was a crucial find, as it directly pointed to a file that likely held the secret flag we were hunting for.

With this discovery, my next step was clear: investigate the flag.txt file to uncover the hidden flag and complete the challenge.

Finisher

Since I had already located flag.txt in the directory, I decided to take the next step and try to read its contents. Using another injection, I attempted to open and read the file directly from the server by injecting the following payload:

{{ request.application.__globals__.__builtins__.open('flag.txt').read() }}

This payload used Python’s built-in open() function to access the file and read() to get its content. The result returned the contents of flag.txt, revealing the hidden flag:

HnH{j1njA2_t3mpl4t3_1nj3cT}

With this, I had successfully retrieved the flag and completed the challenge.

Conclusion

In this challenge, I was able to exploit a Server-Side Template Injection (SSTI) vulnerability to access sensitive server-side information, ultimately leading to the discovery of the hidden flag. By systematically exploring the application’s configuration, performing directory listing, and reading the contents of the flag.txt file, I was able to complete the challenge successfully. This exercise reinforced the importance of carefully handling user input and the potential risks of exposing internal application components in web applications.

A big thank you to my colleague @sulthanullah_haqqihidaya for the valuable explanation about SSTI, which greatly helped in solving this challenge.

CTF Write-Up: 2024 Haunted Brewery - Raise the Dead Challenge

Al Amrikasir — Mon, 04 Nov 2024 11:22:49 +0000

Introduction

I recently joined my first CTF event, “The Haunted Brewery,” hosted by Hackers N’ Hops and sponsored by Tac 9 Security and the National Cybersecurity Center. This event has been an exciting way to dive into the world of cybersecurity, especially with spooky challenges like “Raise the Dead”

Challenge Description and Clues:

When I entered the crypt, I could barely see anything. The only light came from a small flame near a large steel coffin. Suddenly, a ghostly voice whispered, “Release me… and I will help chase off these amateur ghosts ruining your beer… release meeee.” This immediately set the scene for an interesting (and creepy) puzzle.
I was given a file called coffin.txt that I suspected held the key to solving this spooky puzzle.

On the coffin, there was a sign that read:

Within we have buried the count. We are sure he will never get out. Do not make the mistake of releasing him!

Should you encounter another vampire, do as we did! We put a giant STAKE into the heart of him... rolled him facedown and then put him in the coffin backwards!

Investigating the coffin.txt File:

The file contents were strange at first glance. Here’s what I found:

Hexadecimal Pattern: The file mainly consisted of hexadecimal-looking sequences, but something was off. The first line appeared incomplete, as if missing a chunk, which raised my curiosity about hidden information.

00000000000000000000000000000010000000000000000000000000
000010c20000000000006644000000000000000000000000000000000000
003000000011000000000000000000000000000000100000000000000000
000000000000e045000000000000750f0000000000000000000000000000
000000000030000000900000000000000081000000000000008000000051
000000e1000000000000700b000000000000050400000000000000000000
000000000000000000200000001000000000000000100000000000000010
000000000000000000000000000000620000000000000581000000000000
000000000000000000030000001000001032000000000000000000000000

“EKATS” Pattern: Scrolling down, I encountered repeated sequences of “EKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATS.” This sequence seemed unusual until I realized that “EKATS” was simply “STAKE” spelled backward, aligning with the clue about the vampire being “staked” in reverse.

EKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATS
EKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATS
EKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATS
EKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATS
EKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATSEKATS

ELF Header at the End: Near the end of the file, I found a hexadecimal sequence resembling an ELF header, 64C454F7. When reversed, it read 7F454C46, which is the standard ELF file magic number (\x7FELF). This hinted that the file might contain a hidden ELF executable embedded in reverse.

000400d00083000400000000000000000000760700000000000000040000
00000000220c0000001000e3003000000000000000000010102064c454f7

Solution Steps:

After recognizing the hints, I realized that the entire file was likely encoded backward. Here’s how I approached the solution:

Reversing the File Content: I used a command-line tool to reverse the contents of coffin.txt from end to start. This allowed me to see if any coherent data appeared when the file was read in reverse order.

➜ tac coffin.txt | rev > reversed_coffin.txt

Remove STAKE from Count Heart: I edited reversed_coffin.txt manualy to remove STAKE. This left me with a cleaner hexadecimal sequence that appeared to be the hex representation of a binary file.
Converting Hexadecimal to Binary:
I took the remaining hexadecimal data and converted it into binary format. Here’s the command I used:

➜ xxd -r -p reversed_coffin.txt > opened_coffin

Identifying the Binary as an ELF File: After converting, I checked the file type:

➜ file opened_coffin

after execute the ELF file, I got the flag HnH{BackFromTheDead}

Conclusion:

This challenge was a fantastic exercise in recognizing patterns, reversing data, and converting hex to binary to reveal a hidden executable file. Removing the “STAKE” pattern was key to extracting the ELF file and ultimately finding the flag. This experience not only improved my technical skills but also reminded me to pay close attention to story-based hints in CTFs.

A big thank you to Hackers N’ Hops, Tac 9 Security, and the National Cybersecurity Center for organizing this event. It’s been a great learning experience and a fun way to practice Forensic (or RE ????)

nah, I just hate RE.

DEV Community: Al Amrikasir

CTF Write-Up: 2024 Haunted Brewery - Brew4u Challenge

Introduction

Challenge Description and Clues:

Investigating

Understanding SSTI (Server-Side Template Injection)

Investigating the Response Header

Template Injection Attempt with {{ config }}

More Exploit

Finisher

Conclusion

CTF Write-Up: 2024 Haunted Brewery - Raise the Dead Challenge

Introduction

Challenge Description and Clues:

Investigating the coffin.txt File:

Solution Steps:

Conclusion:

Template Injection Attempt with `{{ config }}`