Cyber Apocalypse 2025 - Cyber Attack
Table of Contents
Cyber attack (web)
For this challenge we are given an IP and presumably the source code for the website on that IP
Looking at the code, we see several locations of potential injection. The site is using cgi python scripts to handle requests, and a basic index.php with no server-side exploits popping out. The first thing that comes to mind is CRLF injection, since we see no regex validation or sanitization on the name param, as well as it being printed verbosely as a header.
which we can verify like so:
This works because while it is printing the header, we inject \r\n
, which we can then inject arbitrary headers into
Furthermore, we see a seemingly protected other script in cgi-bin, implying that we need to first exploit attack-domain
before we attack attack-ip
This is the code for
attack-ip
:
Here we see the same command injection with
os.popen
, but this time it's not protected by a regex, which means this should be our final goal.
So we need to:
- Exploit an SSRF in
attack-domain
- Have the server call out to
127.0.0.1/cgi-bin/attack-ip
to bypass the apache config - Inject a payload into the
os.popen
When looking at the dockerfile that came with the challenge, we see several apache addons deliberately enabled, which makes me curious:
I spent a long time trying alternative exploit paths and going down rabbit holes, but I eventually stumbled upon this in the documentation for
mod_proxy_fcgi
. You'll notice that it has a peculiar proxy:
notation.
Before testing I set up a publicly accessible tunnel so I don't need to rely on ngrok or burp collaborator, I'll host a simple python web server here to catch replies
So now we send a blind payload to ping our tunnel. Note we need to double encode the proxy request, since it is a second request nested within the first
Sending the payload validates our SSRF suspicions
SSRF achieved. now we move to exploit. Remember, we already saw the code for
attack-ip
, so we know it is easily vulnerable to command injection since there is no regex protecting it. I'll create index.html on my tunnel containing a script to exfiltrate the flag
And change the payload to pipe into bash so it actually executes:
Then we get a callback with the base64 encoded flag!