One-Click-ATO
From Useless Open Redirect and Useless SSRF to Full Account Takeover.
Last updated
Was this helpful?
From Useless Open Redirect and Useless SSRF to Full Account Takeover.
Last updated
Was this helpful?
In modern web applications, vulnerabilities often coexist in a complex ecosystem of features and endpoints. While a single vulnerability might seem harmless, when combined with another, it can lead to severe consequences. This write-up details how I'm, z1x, during a penetration testing engagement @, chained an useless open redirect vulnerability with a server-side request forgery (SSRF) to achieve a full account takeover, bypassing security mechanisms that might otherwise seem robust.
The journey begins with a whitelisted open redirect vulnerability in the login flow of *.example.com. Open redirects are often considered zero-risk, but when improperly implemented, they can be a gateway to more significant exploits.
The application’s login endpoint at account.example.com allows redirection to any subdomain within *.example.com after successful authentication. The vulnerable URL looks like this:
After processing, the application redirects users along with an access token:
This redirection behavior, combined with the inclusion of an access token, sets the stage for a potential attack.
Next, we discovered an SSRF vulnerability within the API subdomain api.example.com. SSRF vulnerabilities allow an attacker to make arbitrary HTTP requests from the server, potentially accessing internal services or even the internet.
The vulnerable API endpoint is designed to reverse file contents and is accessible via the following URL:
Normally, this SSRF might be limited in scope, especially if the server is well-segmented. However, the fact that api.example.com is a whitelisted subdomain in the open redirect functionality adds a critical dimension to this vulnerability.
Here’s where the magic happens. By combining the open redirect vulnerability with the SSRF, we can escalate the situation dramatically.
We can exploit the open redirect by targeting the SSRF endpoint directly:
This crafted URL does the following:
Step 1: The user authenticates at account.example.com, which then attempts to redirect them to a whitelisted subdomain.
Step 2: The redirect targets the SSRF endpoint at api.example.com instead of the intended app.example.com.
Step 3: The SSRF endpoint is tricked into making a request to our server (http://our-httpserver/?token=), effectively leaking the access token.
With the access token in hand, we can craft a legitimate request to app.example.com:
This allows us to impersonate the victim user and take over their account, all from a seemingly innocuous open redirect combined with a simple SSRF.
To prevent such exploits, consider the following strategies:
Tighten Whitelists: Avoid overly broad whitelists for redirects. Only allow specific, necessary domains.
Token Handling: Avoid including sensitive tokens in URLs. Use secure storage mechanisms like cookies with HTTP-only flags.
SSRF Protections: Implement strict input validation and response filtering for SSRF-prone endpoints.
This case illustrates how two vulnerabilities, which might be considered low-risk individually, can be chained to create a critical security breach. It’s a reminder that thorough vulnerability analysis must consider the potential for chaining attacks, and developers should build security mechanisms with this in mind. My experience @ highlights the importance of understanding how different vulnerabilities interact within a system, ultimately helping secure our digital future.
