# URCHINSEC TANZANIA NATIONAL CTF MMXXIV WRITEUP


Hey there, I'm [**cyb4x**](https://www.linkedin.com/in/said-hussein-53ba8127b/), really into red teaming and all things cybersecurity. Recently, I took part in the **[URCHINSEC TANZANIA NATIONAL CTF MMXXIV](http://ctf.urchinsec.com/challenges)**. It was quite the adventure! Managed to crack some **web security** challenges and even sorted out a **tricky forensic challenge**. But the real highlight? Spent a lot of my time cracking a tough **boot2root** machine and i only ended getting a reverse shell. Couldn't have done it without my awesome teammates, **[haule](https://www.linkedin.com/in/haule-haule-462832276/)** and **[massco99](https://www.linkedin.com/in/cosmas-kalega-315b05249/)**. Together, They nailed all cryptography, forensic, and OSINT challenges. Big shoutout to the organizers, **[URCHINSEC](https://www.linkedin.com/company/urchinsec/)**, especially **[Tahaa Farooq](https://www.linkedin.com/in/tahaa-f-0784901b9/)**, for putting together such an awesome event!.

## WEB SECURITY

### 1. ROBOTS


So, diving into the first challenge named "Robots" was quite interesting. As soon as we hit the link, we were greeted with the welcome message to the CTF competition. Exciting, right?


Given the name "**Robots**," my initial hunch was that there might be a ***robots.txt*** file lurking around. *That's a common place to hide stuff, a commonly used mechanism for website owners to communicate with web crawlers and search engines regarding which pages or files should not be crawled or indexed.*

I started by checking out the **robots.txt** file. Lo and behold, there it was! It contained the flag.

This challenge really reinforced the idea that sometimes the simplest solution is the right one. It's not always about complex **hacks or brute force.** Sometimes, it's just about being observant and using common web security practices.


***`Flag`***
`urchinsec{robots_txt_wh7_N0t_r343d}`

### 2. CONSOLE

So, onto the next challenge titled "Console." This one was a bit trickier but equally exciting.

Upon opening the link, we were greeted with a page displaying a fake flag and a cryptic message asking, "Where is the goddamn console for the flag?" Intriguing, right?


As i said before in CTF no need to hack harder you just need to play smarter, The challenge name "Console" and the mention of a console on the first page got us thinking. Maybe there's a web directory named "console" hiding somewhere. Sure enough, after a bit of exploration, we stumbled upon it. Also you can opt to perform directory fuzzing.


**Understanding the Console**
**The console**, In web development, the console is like a command center, especially in frameworks like Django or Flask. It's where developers debug, test, and manage applications. In Python web projects, the console allows for interactive debugging, testing individual components, and executing commands within the application's environment. However, while invaluable during development, the presence of a console in production environments can introduce significant security risks if not properly secured.


so the next step was to confirm if it is a python console and what version by using a whatweb command and there we found it was a console running Werkzeug Server 3.0.2 Debugger on Python 3.


We couldn't resist the temptation to have a bit of fun, so we ran a simple Python program to print the name of the author, **Tahaa Farooq**. It's the little things that keep us entertained, *Hahahah thats fun, right??*

After confirm its Python, my next move was to try to execute arbitrary code on the server.

We didn't stop there. We wanted the flag. So, we started by enumerating the directory, listing the files, and finally, after some trial and error, we got it! By executing some Python code on the server, we managed to reveal the flag.

**Currently working directory**


**Listing Files in the directory**


**Getting our flag**


***Flag***
`
urchinsec{N1c3_m1sc0NfIGURED_ENV_RCE_Fl45k_br0knn}
`

As we delved deeper into the challenge, we realized that we could potentially take our exploitation to the next level by attempting to establish a connection back to our hacking machine, a technique known as a **Reverse Shell**. However, we decided against it. After all, this is just a CTF, and the goal is to **hack smarter, not harder**. Sometimes, it's important to weigh the risks and rewards and choose the most efficient path to victory.

### 3. GHOST


So, we tackled the "**Ghost**" challenge next, and let me tell you, it was a real brain-teaser. Rated medium, it definitely lived up to its reputation.

This challenge was not for the newbies since it was rated medium, so lets explore it.

Upon opening the link, we were greeted with what seemed like a documentation page detailing the usage of an **API**, with an endpoint `/docs`.


One endpoint, `/api/bak_name/<filename>`, caught my attention as it was used for renaming backup files. This seemed like a good starting point for further investigation.

I began by sending a request to the endpoint, renaming the backup file to `urchinsecBackup.zip`. To our surprise, it worked flawlessly. But the real challenge was yet to come.


I spend a time to think about this challenge tried multiple vulnerabilities tests and then `SSTI` worked by submitting a payload `{{7*7}}`. which returned `49` as a backup name.


**Server-Side Template Injection (SSTI)** is a web application vulnerability that occurs when user input is embedded directly into a template engine without proper sanitization. This vulnerability enables attackers to inject and execute malicious code within the server's context, often leading to severe consequences such as data leaks, server compromise, or remote code execution.

You can [Read More](https://hackmd.io/HWg-RZRqQeOqUwGB_fVyqA?view) about SSTI from this article crafted by my fellow Red Teamer [AlienX](https://www.linkedin.com/in/erick-alex-068480248/)

My next move was to exploit this by trying to excutes comands on server. to achieve this I started at the object’s root — Index [1] and list all available classes with the subclasses keyword using the payload
`

{{ "".__class__.__mro__[1].__subclasses__() }}

`
This payload is crafted to exploit the SSTI vulnerability by leveraging **Python's introspection capabilities**. It initiates by accessing the class of an empty string `("".__class__)`. Following that, it navigates through the class hierarchy to access the method resolution order `(__mro__)`. Index [1] is utilized to select the second item in the tuple, which represents the class itself. Lastly, `__subclasses__()` method is called to list all the subclasses of the selected class. By executing this payload, we gain insight into the available classes within the Python environment, ultimately identifying the subprocess.Popen class, which allows for command execution.

As we see, there is a lot of inherited classes. So, to select the “subprocess.Popen” class, we need to get the index number of the class. We can do that with the index method, in which we pass the class name and returns its position in the array.

Again **hack smarter not harder**, i decided to utilize the find tool in the browser page by clicking **Ctr+F** then searched anything that ends with `>,` which is the end of the subclasses in the array, the page returned **505** **matches** since “subprocess.Popen” class was the lastone so it doesnt contain >, and the array count starts from 0. so the index number of “subprocess.Popen” class will be **505**.


*Again no need of Reverse shell just play smarter its just a CTF bruh.*

I started enumerating the server by checking the currrent working directory,

` {{ "foo".__class__.__base__.__subclasses__( [505].__init__.__globals__['sys'].modules['os'].popen("pwd").read()}}`

This payload is designed to execute the **pwd** command, which prints the current directory. It begins by accessing the class of a string `"foo"`, then traverses to its base class (`__base__`). Subsequently, it explores the subclasses of the base class to pinpoint the **subprocess.Popen class** at **index 505**. Using the `__init__` method, it initializes the subclass and accesses the global namespace to retrieve the os module. Finally, it employs the `popen()` function from the os module to execute the **pwd** command and reads its output. By executing this payload, we ascertain the current directory on the server.


**Then listed the contents**

` {{ "foo".__class__.__base__.__subclasses__( [505].__init__.__globals__['sys'].modules['os'].popen("ls -la").read()}}`


**and finnally read the flag.txt**

` {{ "foo".__class__.__base__.__subclasses__( [505].__init__.__globals__['sys'].modules['os'].popen("cat flag.txt").read()}}`


***`Flag`***
`urchinsec{SSTI_on01_Fjc9ajn_flags_raining}`

In conclusion, the "**Ghost**" challenge presented a formidable test of our skills, requiring a deep understanding of Server-Side Template Injection (**SSTI**) vulnerabilities and creative exploitation techniques. By navigating through Python's class hierarchy and leveraging dynamic capabilities, we successfully executed arbitrary commands on the server and read our flag.

Addition

{{ self.__init__.__globals__.__builtins__.__import__('os').popen('cat flag').read() }}

## FOREINSIC

### 1. PLUGGED


*Comming Tomorrow.....*

## BOOT2ROOT

### 1. BILL SYSTEM


*Comming Tomorrow.....*