Full Report
Blind SSRF bugs are difficult to exploit. Just because you have a Server-Side Request Forgery bug, doesn't mean that the data is being returned back to you properly. The article explains a technique that the author used to turn a Invalid JSON exception with no data to get the full response data. Notably, they wanted to get the AWS metadata information. They tested a lot of the handling of responses in the application by sending the request to their website via the SSRF and seeing how it reacted to different things. 300s, 400s, 500s, etc. They noticed that a 500 error returned all of the data. Of course, making a request to the AWS cloud metadata service will respond with a 200 so this wouldn't work for returning the data. Their goal was to trigger a 500 error but get the response from the server. Since this was black box, they had no idea what to do next. The application was following redirects for 3xx status codes so they were curious what would happen if they reached the maximum amount of redirects. This led to a NetworkException and wasn't very useful. So, they decided to do some fuzzing around the types of 3xx status codes and their handling. Their fuzzing was simply using each 3xx status code once and incrementing to the next one. To their surprise, on the application returned the full chain of redirects and the entire response to the metadata request from the final redirect. But, wait, why!? They made some guesses on why this may have worked. The application was happy to follow a few redirects. However, if it followed more than 5 redirects not handled by libcurl then their was another error state. Surprisingly, this technique has worked in several situations for the author of the post. I'm always amazed by how successful people are with this blackbox fuzzing to understand applications. For every instance of a blog post like this, there are likely several hundred cases that were not exploitable though. Interesting read!
Analysis Summary
# Tool/Technique: Redirect Chain Fuzzing for Blind SSRF Exfiltration
## Overview
This technique is an advanced exploitation method for **Blind Server-Side Request Forgery (SSRF)**. It leverages improper error handling and redirect-limit logic within an application’s backend (often involving `libcurl` or similar libraries) to force the application to leak the full HTTP response body of a requested internal resource—such as AWS Metadata—that would otherwise be hidden from the attacker.
## Technical Details
- **Type:** Technique / Exploitation Maneuver
- **Platform:** Web Applications, Cloud Infrastructure (AWS, Azure, GCP)
- **Capabilities:** Data exfiltration from internal services, bypassing blind SSRF limitations, and triggering verbose error states via redirect exhaustion.
- **First Seen:** Unknown (Documented in recent security research regarding black-box fuzzing).
## MITRE ATT&CK Mapping
- **TA0010 - Exfiltration**
- **T1041 - Exfiltration Over C2 Channel** (In this context, using the SSRF response as the channel)
- **TA0007 - Discovery**
- **T1082 - System Information Discovery**
- **T1580 - Cloud Infrastructure Discovery**
- **TA0001 - Initial Access**
- **T1190 - Exploit Public-Facing Application**
## Functionality
### Core Capabilities
- **Blind SSRF Transformation:** Converts a "blind" vulnerability (where no data is returned) into a "partial" or "full" SSRF by forcing the application to reveal the internal response.
- **Redirect Fuzzing:** Systematically testing different 3xx status codes to observe how the backend library handles state transitions.
- **Error State Manipulation:** Inducing a specific 500 Internal Server Error or Exception state that includes the response buffer of the last successful hop in the redirect chain.
### Advanced Features
- **Chain Exhaustion:** Bypassing standard `libcurl` redirect limits to trigger an unhandled exception.
- **AWS Metadata Acquisition:** Specifically targeted at the Instance Metadata Service (IMDS) at `http://169.254.169.254/latest/meta-data/` to retrieve IAM credentials or sensitive configuration.
## Indicators of Compromise
- **File Hashes:** N/A (Technique-based)
- **File Names:** N/A
- **Registry Keys:** N/A
- **Network Indicators:**
- Unusual requests to `169[.]254[.]169[.]254`
- High frequency of `3xx` redirect chains originating from the application server to an attacker-controlled domain (e.g., `attacker[.]com/redir1` -> `attacker[.]com/redir2`).
- **Behavioral Indicators:**
- An increase in `500 Internal Server Error` responses containing large JSON blobs or raw HTTP headers.
- Application logs showing `NetworkException` or `RedirectLimitExceeded` errors.
## Associated Threat Actors
- While not attributed to a specific named group (APT), this technique is commonly utilized by:
- Bug Bounty Hunters
- Penetration Testers
- Advanced Persistent Threat (APT) actors targeting cloud-native environments.
## Detection Methods
- **Behavioral Detection:** Monitor for outbound web requests from application servers that follow an abnormal number of redirects (e.g., >3).
- **Log Analysis:** Scrutinize application logs for "Invalid JSON" or "NetworkException" errors that coincide with SSRF-prone parameters (URLs in query strings).
- **WAF Rules:** Implement signatures to detect access attempts to metadata IP addresses (`169.254.169.254`) within URL parameters.
## Mitigation Strategies
- **Input Validation:** Implement strict allow-lists for protocols (allow only `https`), domains, and IP ranges.
- **Disable Redirects:** Configure backend HTTP clients (like `libcurl`) to disable following redirects if not strictly necessary.
- **IMDSv2 Migration:** On AWS, enforce Instance Metadata Service Version 2 (IMDSv2), which requires a session-oriented token, effectively neutralizing most SSRF attacks.
- **Response Sanitization:** Ensure that 500 error messages are generic and do not return the raw output of backend network requests to the end-user.
## Related Tools/Techniques
- **DNS Rebinding:** Another method used to bypass SSRF filters.
- **Gopher Protocol Smuggling:** Used to interact with internal services like Redis or Memcached via SSRF.
- **Collaborator/Interaction Servers:** (e.g., Burp Collaborator, interact.sh) used to host the redirect chain during fuzzing.