# WXMCTF 2024 WRITEUPWXMCTF 2024 WRITEUP

## INTRODUCTION

Hey everyone, cyb4x here! Red teaming is my game, and keeping my web security chops sharp is crucial. Yesterday March 10 2024, wxmctf2024's web challenges were my target. I battled through them, happily solving most! But hey, even hackers hit roadblocks – there was one that stumped me. This quick writeup dives into my web exploits and that one nemesis. Don't worry, it'll be a short read, so jump in and see if you can conquer what I couldn't!


# WEB EXPLOITATION

In this write-up, we'll dive into the exhilarating world of web exploitation, exploring the challenges I cracked and the one that remained stubbornly unsolved.


## 1. Mr. P


Let's jump right in! The first challenge, titled "**Mr. P**," presented a cryptic message: "WATCH OUT WATCH OUT WATCH OUT!!". Intrigued, I fired up the instance and found a link. Clicking it led me to a seemingly ordinary page: a photo of John Cena and a welcome message for John Cena fans. What could this seemingly innocuous page be hiding?


My suspicions led me to inspect the source code of the page. And there it was – the flag, cleverly hidden within the HTML. This was a reminder that sometimes the most obvious places can hold the key!


## 2. Compiler


Moving on from the deceptive greetings of "Mr. P," the next challenge, "compiler," presented a more subtle puzzle. The description was nonchalant: "Come check out this python compiler I made! Just don't look too far into it..." A link led to the supposed compiler, but this time, an attachment caught my eye – source code, most likely.

Launching the instance revealed a web page with a simple compiler interface with just an input and output field. The source code confirmed it was a Python application.

Testing it with basic Python code produced the expected output. But remember, the prompt mentioned "don't look too far into it..." This piqued my curiosity. My next move was to shift gears from using the compiler as intended to exploiting any potential vulnerabilities it might hold.


With a detective's eye, I delved into the code, searching for vulnerabilities.
A critical finding emerged where the application wasn't properly sanitizing or filtering user input! This meant it could be susceptible to **code injection** attacks. An attacker could potentially craft **malicious code** that, when executed by the compiler, wouldn't be just processed as Python instructions, but could manipulate the system in unintended ways.


Armed with this knowledge, I crafted a Python script designed to bypass the intended compiler functionality and reveal hidden files

import os
print(os.listdir('.'))

Submitting this code to the compiler unleashed its power! The application, unaware of the malicious intent, obediently executed it, listing the files within its directory.


But the elusive **flag.txt** file wasn't among them. Undeterred, I delved deeper. Perhaps the flag was concealed within a different file?

Recalling the attached source code, I remembered a common practice in web challenges – hiding flags within **Dockerfiles**. With a confident stroke, I modified my exploit.

with open('Dockerfile', 'r') as file:
  print(file.read())

And as the compiler parsed these lines, the **flag** that was hidden within the **Dockerfile**, was now revealed!


## 3. The Heist


**The "Mr. P"** and **"Compiler"** challenges were just the warmup. Now, buckle up for **"The Heist,"** a challenge that captured my imagination with its quirky description.

Just like the "compiler" challenge, this one provided an instance and, as expected, **source code**. The task was clear – exploit the gem-transferring virus to benefit Eatingfood, not the intended victims

The provided webpage mirrored the description – a one-way gem transfer system, allowing gems to flow only from Eatingfood to others.



Checking the **source code** became my next move. After all, the key to exploiting a system often lies within its own blueprint.

Within **app.py**, two crucial functions stood out:

**check()** function determines whether or not to display the flag. If Eatingfood's balance dips below 0, a flag-less balance page renders. But, if his balance miraculously exceeds **100,000**, the **flag** is revealed alongside the balance information.


**send_data()** This function governs gem **transfers**. It enforces a critical restriction: Eatingfood **cannot receive gems**, only give them.


Furthermore, all these gem-related operations pass through gateway.php, a seemingly innocuous file at first glance.


The challenge was set: somehow, I needed to circumvent the restrictions and either boost Eatingfood's balance beyond 100,000 or forge a balance check that tricked the system into revealing the flag. All this while navigating around gateway.php, whose purpose remained unclear

However, determined to get Eatingfood back to his mindless button mashing, I decided to explore a new approach – **manipulating the communication** between the application and the backend (**gateway.php**).

**Burp Suite**, a powerful web proxy tool, became my weapon of choice. By intercepting the traffic between the web page and the server during a gem transfer attempt, I could potentially observe how the system functioned behind the scenes and identify exploitable weaknesses.


My initial attempt was a straightforward one – changing the recipient to Eatingfood and the amount to a whopping 100,000 gems, hoping to trigger the flag reveal condition. However, this tactic backfired. The modified request resulted in a rejection, likely due to the built-in restriction against crediting Eatingfood directly.


Here's where my understanding of web application vulnerabilities came into play. The concept of parameter pollution emerged as a potential solution.

**Parameter pollution** is a technique where an attacker provides excessive or unexpected data within a request parameter. Some web applications might struggle to handle this overflow, leading to unintended consequences. In this case, I hoped to exploit parameter pollution to manipulate the way the server interpreted the transfer request.

For more explanations about Parametr Pollution check [here](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution) or [another link](https://medium.com/@khaganaydin/http-parameter-pollution-hpp-attacks-examples-and-protection-explained-9235f5c81702)

So, I crafted a new payload in Burp Suite. Instead of simply changing the recipient and amount, I strategically included duplicate recipient fields, each with the recipient set to another user one being **Eatingfood** also added a sender field set to another user apart from Eatigfood and the amount set to a value **100,000**. However, the last recipient field would have the recipient set to Eatingfood and the amount set to a high value (enough to push his balance past 100,000).


With a pounding heart, I fired the modified request through Burp Suite. And then... success! The redirection led me to the /check_balance page, and there it was – the elusive flag, proudly displayed alongside Eatingfood's inflated gem balance.


This concludes the write-up for the **"The Heist"** challenge.

## 4. Nuclear Launch Codes


Our exhilarating journey through the web challenges of wxmctf2024 nears its end. We've conquered "Mr. P," outsmarted the "compiler," and orchestrated a successful heist in "The Heist." But now, we face the final frontier – "Nuclear Launch Codes," a challenge worth a whopping 500 points.

The description sets the stage for a high-stakes scenario: testing the security of a website containing nuclear launch codes. However, a critical roadblock emerges – a lack of login credentials and registration options. Without a proper entry point, how could we possibly access the launch codes?

Intrigued yet frustrated, I fired up the instance, hoping to find a glimmer of hope within the source code (provided as usual).

Just as the description hinted, a login page greeted me. It requested a username but offered no password field. A natural first attempt was to try "admin" as the username. Clicking submit yielded a rather unhelpful message: "Who are you?".



Then i decide to try basic sql injection admin' OR '1'='1';-- - this returned all users found so we found an sql injection here waiting to exploited to reveal hidden stuffs


The vulnerability was also spotted in source code where the username was passed directly with no input validation and sanitization and with no prepared statement. Also we spotted the DBMS used ws **SQLite**


So make this simple i decided to capture the request with burpsuite copy it to file so as i use it with sqlmap


There we go, launched my terminal and typed sqlmap command with several arguments for making our attack successfully.


Goodluck!, our sqlmap gave us coolstuffs here


so then i decided to enumerate tables since we sqlmap cannot enumerate databases for SQLite DBMS.

Then we found a users table and it was a time to dump it to see what is inside


That was an end since a users table dumped contained a flag in password column


# FOREINSIC (Bonus)

To wrap up your web exploitation challenges, I have included a bonus forensic challenge

## 1. Covert Chinchillas



First i used file command to see the filetype of our attachment.Yeap yeap , we found somenthing interesting there which is a comment of our file, seems a base64 encoded string.


Decoding it we get something cool with a name password, but formatted like a flag, trying it by wrapping with flag format we get denied. So i decided to play around to what is this password for....


May be lets try steghide to extract hidden stuffs there, supplying our passphrase. There we go we got our flag.


# CONCLUSION

Thanks for joining me on my red teaming adventure! I'm just starting out, so forgive any bumps along the road. More write-ups are coming your way, including a crack at the HackTheBox Cyber Apocalypse 2024 CTF before it ends in two days! In the meantime, happy hacking everyone!