Microsoft discovered a high-severity vulnerability in the TikTok Android application, which could have allowed attackers to compromise users’ accounts with a single click. The vulnerability, which would have required several issues to be chained together to exploit, has been fixed and we did not locate any evidence of in-the-wild exploitation. Attackers could have leveraged the vulnerability to hijack an account without users’ awareness if a targeted user simply clicked a specially crafted link. Attackers could have then accessed and modified users’ TikTok profiles and sensitive information, such as by publicizing private videos, sending messages, and uploading videos on behalf of users.
TikTok has two flavors of its Android app: one for East and Southeast Asia under the package name com.ss.android.ugc.trill, and another for the remaining countries under the package name com.zhiliaoapp.musically. Performing a vulnerability assessment of TikTok, we determined that the issues were affecting both flavors of the app for Android, which have over 1.5 billion installations combined via the Google Play Store. After carefully reviewing the implications, a Microsoft security researcher notified TikTok of the issues in February 2022, as part of our responsible disclosure policy through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). TikTok quickly responded by releasing a fix to address the reported vulnerability, now identified as CVE-2022-28799, and users can refer to the CVE entry for more information. We commend the efficient and professional resolution from the TikTok security team. TikTok users are encouraged to ensure they’re using the latest version of the app.
In this blog post, we share information on the issues we discovered, examine how they could have been leveraged in an attack to quickly and quietly take over targeted users’ accounts, and walk-through best practices and protections. As threats across platforms continue to grow, we also share details of our research, disclosure, and collaboration with the larger security community in the effort to continually improve security for all, regardless of the platform or device in use.
The arg1 corresponds to a JSON string that consists of several attributes, with the func and params attributes as the most relevant.
The above figure visualizes the concept and depicts the following steps:
- The application loads the website example.com to its WebView
- The method is executed
- The result is returned as a parameter to the callback function
Finally, the handler method can process the result locally or send it to an external server using an XMLHttpRequest, a built-in browser object that can also be leveraged during an attack to send stolen data to an attacker’s server.
Diving into deeplinks
The vulnerability itself was ultimately found to reside in the app’s handling of a particular deeplink. In the context of the Android operating system, a deeplink is a special hyperlink that links to a specific component within a mobile app and consists of a scheme and (usually) a host part. When a deeplink is clicked, the Android package manager queries all the installed applications to see which one can handle the deeplink and then routes it to the component declared as its handler. A deeplink must be declared in the application’s manifest to be used by components outside of the application’s context:
In the example above in Figure 5,
- The user clicks the link http://www.example[.]com/gizmos. Since more than one application can handle the scheme, the system then presents a dialog box, also known as ambiguity dialog, similar to the one depicted below in Figure 6.
- A deeplink in the form of example://gizmos is routed directly to the activity GizmosActivity, the component declared as the deeplink handler in this case.
To avoid the ambiguity dialog for http and https schemes, an application may declare an Android App Link by using the autoVerify attribute in its intent filter to signal the system to verify the association between the app and the declared URL domain. Additionally, a JSON file that contains the application’s package name and its certificate’s SHA256 fingerprint must be published under https://domain.name/.well-known/directory. TikTok for Android uses this feature for the domain m.tiktok.com, meaning all the links matching to the specific domain will be routed to the application without presenting the ambiguity dialog.
Besides deeplinks that are exported in the Android manifest, an application can also exchange data between its components using internal deeplinks. Trying to open an internal deeplink from outside the application, like in a web browser, will return an “unable to resolve Intent” error message as the system can’t route it to the appropriate handler.
What follows is a technical description of the vulnerability, which we analyzed using the TikTok Android application with the package name com.zhiliaoapp.musically. The same description applies for the TikTok Android application com.ss.android.ugc.trill, as the vulnerabilities were found in common SDKs.
Triggering the app’s internal deeplinks
TikTok for Android uses multiple deeplink schemes, some of which are exported via the manifest, while some are used only internally by the application. Among the exported ones, the https://m.tiktok[.]com/redirect link is handled by the [redacted] class and is used to redirect URIs to various components of the application via a query parameter:
We determined that it’s possible to trigger internal deeplinks via the query parameter and call non-exported activities, expanding the attack surface of the application. According to TikTok, this redirection to internal deeplinks doesn’t raise any additional concerns.
As a proof of concept, we crafted a URL that uses a particular non-exported scheme to load https://www.tiktok[.]com to the application’s WebView, as displayed below in Figure 8:
Although the [redacted-internal-scheme]://webview?url=<website> deeplink can be used to load URLs to the CrossPlatformActivity’s WebView via a query parameter, the application imposes filters to reject untrusted hosts. In contrast to the Tiktok.com domain successfully loading, as shown in Figure 8 above, Figure 9 below displays the domain Example.com being rejected by the application filters:
The filtering takes place on the server-side and the decision to load or reject a URL is based on the reply received from a particular HTTP GET request. Our static analysis indicated that it is possible to bypass the server-side check by adding two additional parameters to the deeplink.
By invoking such methods, an attacker can:
- Retrieve the user’s authentication tokens by triggering a request to a controlled server and logging the cookie and the request headers.
In short, by controlling any of the methods able to perform authenticated HTTP requests, a malicious actor could have compromised a TikTok user account.
Proof of concept
In the following proof of concept, the attacker sends a crafted link to a targeted TikTok user. Once the user clicks the link, the video uploading authentication tokens are sent back to the attacker and, subsequently, the script modifies the user’s biography information to read “!! SECURITY BREACH !!”:
The video uploading authentication tokens are sent back to the attacker via an XMLHttpRequest. The attacker also receives the reply body and the header, depicted in Figure 10 and 11 below:
Finally, the message “!! SECURITY BREACH !!!” is set in the user profile’s biography:
- Use the default browser to open URLs that don’t belong to the application’s approved list.
- Keep the approved list up to date and track the expiration dates of the included domains. This can prevent attackers from hijacking WebView by claiming an expired domain on the approved list.
- Avoid using partial string comparison methods to compare and verify a URL with the approved list of trusted domains.
- Avoid adding stage or internal network domains to the approved list as these domains could be spoofed by an attacker to hijack WebView.
Responsible disclosure and industry collaboration improves security for all
Leveraging new threats, techniques, and attacker capabilities, adversaries continue to focus on identifying and taking advantage of unpatched vulnerabilities and misconfigurations as a vector to access systems and sensitive information for malicious purposes. Responding to the changing threat landscape requires us to expand our knowledge and expertise into other devices and platforms as part of our commitment to continuously improve security from Microsoft, not just for Microsoft.
We use collaborative research such as this to improve our protection technologies across platforms, ensuring Microsoft Defender Vulnerability Management detects and alerts on installed applications with known vulnerabilities—including those affecting non-Windows devices. While we’re not aware of any active exploitation of this vulnerability in the wild, users can further follow the security guidelines below to defend against this and similar types of issues:
- Avoid clicking links from untrusted sources
- Always keep the device and the installed applications updated
- Never install applications from untrusted sources
- Immediately report any strange application behavior to the vendor, such as setting changes triggered without user interaction.
As part of our responsible disclosure policy through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR), we disclosed the vulnerability to TikTok in February 2022 as directed on its website. The vulnerability, CVE-2022-28799, was quickly rated as high severity with a score of 8.3, and a fix for the issue was included in an updated version of the app released less than a month after the initial disclosure. We wish to thank the TikTok security team for collaborating quickly and efficiently in resolving these issues.
This case displays how the ability to coordinate research and threat intelligence sharing via expert, cross-industry collaboration is necessary to effectively mitigate issues. As threats across platforms continue to grow in numbers and sophistication, vulnerability disclosures, coordinated response, and other forms of threat intelligence sharing are needed to help secure users’ computing experience, regardless of the platform or device in use. We will continue to work with the larger security community to share research and intelligence about threats in the effort to build better protection for all.
Microsoft 365 Defender Research Team