Full Report
I’ve come to realise that I wasn’t the only one that has never actually exploited an HTTP Request Smuggling vulnerability, three years after James Kettle reminded the world of it. Like many, I’ve seen the buzz, read it all, thought I understood it, but honestly, I didn’t. While the potential impact sounds great from an attacker perspective, I’ve been mostly confused by a lot of it. That was until the 2022 HackTheBox Business CTF challenge called PhishTale in the web category came around. Focussing less on the overall solving of the challenge and more on the request smuggling, in this post I’ll tell you about my journey of how I finally got to exploit an HTTP desync attack (specifically HTTP2 request smuggling).
Analysis Summary
# Tool/Technique: HTTP Request Smuggling (Specifically HTTP/2 Request Smuggling)
## Overview
HTTP Request Smuggling, also known as HTTP Desync Attack, is a web security vulnerability that occurs when a front-end server and a back-end server disagree on how to interpret the boundaries of a single HTTP request. This discrepancy can lead to request confusion, allowing an attacker to smuggle an additional, unseen HTTP request to the back-end server, potentially bypassing security controls or leading to cache poisoning or session hijacking. This specific analysis focuses on the exploitation of HTTP/2 Request Smuggling within the context of the PhishTale CTF challenge.
## Technical Details
- Type: Technique
- Platform: Web Applications (involving multi-tiered architectures, often with a reverse proxy/cache like Varnish in front of an origin server like Apache/Symfony).
- Capabilities: Allows an attacker to bypass access controls (like ACLs enforced by a proxy) by making a smuggled request that the front-end proxy processes normally, but the back-end server interprets as a separate request.
- First Seen: The general concept has been known for years, with a major resurgence in awareness in 2019/2022 regarding HTTP/2 variations.
## MITRE ATT&CK Mapping
Since HTTP Request Smuggling is an exploitation technique targeting web infrastructure interaction, the most relevant mappings relate to initial access or bypassing security controls:
- **TA0001 - Initial Access**
- **T1190 - Exploit Public-Facing Application**
- While commonly used for remote code execution, this applies to using application-layer vulnerabilities (like desync) to gain unauthorized access.
- **TA0005 - Defense Evasion**
- **T1569 - Inter-Process Communication** (Less direct, but relates to manipulating boundaries between components)
(Note: Specific, precise mappings depend on the ultimate goal of the smuggling. Bypassing an ACL points heavily toward Defense Evasion or Unauthorized Access.)
## Functionality
### Core Capabilities
- **Boundary Discrepancy Exploitation:** Exploiting differences in how front-end (e.g., Varnish, TLS Proxy) and back-end (e.g., Apache) servers interpret HTTP request boundaries, often relying on conflicting `Content-Length` or `Transfer-Encoding` headers, or, in this case, HTTP/2 framing mechanisms.
- **Request Tunneling:** Using the protocol difference (e.g., HTTP/2 framing) to encapsulate and then deliver a second, malformed request to the back-end.
### Advanced Features
- **Bypassing Proxies/ACLs:** Successfully demonstrating exploitation when the front-end proxy has specific access restrictions (like an ACL limiting `/admin/export` access to `localhost`) that the smuggled request can circumvent because it is processed directly by the back-end server.
- **Chaining Vulnerabilities:** The technique was successfully chained with **Server-Side Template Injection (SSTI)** in a Twig template engine (used in the application built via Symfony/PHP) to achieve Remote Code Execution (RCE) and leak the flag via a generated asset file.
- **Protocol Negotiation:** Successfully transitioning from an initial HTTP/2 confusion to using HTTP/1.1 for the smuggled request in testing to ensure the back-end successfully processed the request boundary, leading to successful exploitation in the specific challenge environment.
## Indicators of Compromise
As the input describes learning and exploitation techniques within a CTF environment, the indicators listed here are highly contextual to the challenge structure:
- File Hashes: N/A (Source files provided or self-compiled)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: N/A (The exploit relies on manipulating the request flow between defined application components, not external C2 infrastructure.)
- Behavioral Indicators:
- Front-end server receiving a request that does not conform to expected HTTP/2 behavior resulting in a back-end receiving an additional, unexpected request payload.
- Successful POST request to `/admin/export` that should have been blocked by a `localhost` ACL, indicating successful request smuggling bypass.
- Unusual application behavior indicating successful SSTI execution (`/readflag` command execution reflected in output).
## Associated Threat Actors
This vulnerability/technique is general and not attributed to a specific threat actor. However, **HTTP Request Smuggling** is a known offensive security technique frequently leveraged by penetration testers and threat groups against complex web deployments. The context here is specifically related to exploiting the **PhishTale CTF Challenge (2022 HackTheBox Business CTF)**.
## Detection Methods
Detection relies heavily on inspecting request headers and protocol adherence between proxies.
- Signature-based detection: Detection rules sensitive to unusual HTTP header combinations or sequences that indicate desynchronization attempts (e.g., presence of conflicting length indicators, or unexpected protocol negotiation sequences).
- Behavioral detection: Monitoring for requests that successfully reach restricted back-end paths (`/admin/export` in this case) when initiated from non-localhost sources, suggesting a proxy bypass.
- YARA rules: Not applicable for protocol-level attacks unless specific payload structures are used within the smuggled request.
- Configuration Enforcement: Ensuring front-end and back-end servers are strictly configured to adhere to the same, unambiguous HTTP protocol version and specification (e.g., strictly enforcing HTTP/2 adherence or clearly defining how HTTP/1.1 headers are translated).
## Mitigation Strategies
- Use the same standard HTTP specification (e.g., HTTP/2) for both the front-end and back-end, ensuring negotiation doesn't result in protocol mismatches.
- Strictly enforce the use of a single, trusted mechanism for defining request length/boundaries (e.g., favouring one header over another if both exist).
- Do not pipeline responses, especially when chaining proxies.
- Patch vulnerable components (as indicated by the specific Varnish 6.6.0 usage hint in the article, implying patching known vulnerabilities is key).
- Implement strict input validation for all request components passed between proxies.
## Related Tools/Techniques
- **HTTP Request Smuggling (CL.TE, TE.CL, TE.TE):** Other variations of HTTP Desync attacks relying on `Content-Length` (CL) and `Transfer-Encoding` (TE) headers.
- **HTTP/1.1 Request Smuggling:** The classic form of the attack.
- **Server-Side Template Injection (SSTI):** The vulnerability chained with the smuggling technique to achieve code execution.
- **Varnish Cache:** Used as the front-end proxy component that enforces local access control, which the attack sought to bypass.
- **Burp Suite:** Used by the author for intercepting and modifying/crafting the smuggled requests for testing.