TikTok has two flavors of its Android app: one for East and Southeast Asia under the package name com.ss.android.ugc.trill<\/em><\/a>, and another for the remaining countries under the package name com.zhiliaoapp.musically<\/em><\/a>. 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 <\/strong>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<\/a> (CVD) via Microsoft Security Vulnerability Research<\/a> (MSVR). TikTok quickly responded by releasing a fix to address the reported vulnerability, now identified as CVE-2022-28799<\/a>, 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\u2019re using the latest version of the app.<\/p>\n\n\n\n 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\u2019 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.<\/p>\n\n\n\n Exploitation of the vulnerability relies on the app\u2019s implementation of JavaScript interfaces, which are provided by a component of the Android operating system called WebView. WebView allows applications to load and display web pages and, using the addJavascriptInterface<\/em> API call, can also provide bridge functionality that allows JavaScript code in the web page to invoke specific Java methods of a particular class in the app. Loading untrusted web content to WebView with application-level objects accessible via JavaScript code renders the application vulnerable to JavaScript interface injection, which may lead to data leakage, data corruption, or, in some cases, arbitrary code execution. <\/p>\n\n\n\n In our example, the code below demonstrates how a JavaScript interface is used, an instance of the JsObject<\/em> class is injected into WebView (line 8) and it is referenced by the injectObject<\/em> variable within the JavaScript code, which is loaded via the loadUrl<\/em> API method (line 10):<\/p>\n\n\n\n Prior to Android API level 18 (released in 2013 with Android 4.3), any method of the injected class was exposed to this JavaScript code. From API level 18 onwards, only class methods with the \u201c@JavascriptInterface\u201d annotation can be invoked (depicted above in line 2).<\/p>\n\n\n\n TikTok for Android uses JavaScript interfaces extensively, enhancing WebView capabilities that are used within the app. We identified a class of interest that makes use of such a WebView. It registers a JavaScript bridge that has access to every type of functionality implemented by the classes of the [redacted<\/strong>].bridge.*<\/em> package. This bridge exposes the method depicted below:<\/p>\n\n\n\n The arg1<\/em> corresponds to a JSON string that consists of several attributes, with the func<\/em> and params<\/em> attributes as the most relevant.<\/p>\n\n\n\n The func<\/em> attribute corresponds to the name of the Java method that is invoked from the JavaScript code, while the params<\/em> attribute sets arguments that this method takes. For example, to call the Java method with signature String foo(String arg1, String arg2)<\/em> from the JavaScript code, the following statement must be used:<\/p>\n\n\n\n The result is returned as a JSON string to a callback defined in the JavaScript code, which takes a single string as an argument.<\/p>\n\n\n\n The above figure visualizes the concept and depicts the following steps:<\/p>\n\n\n\n Finally, the handler<\/em> method can process the result locally or send it to an external server using an XMLHttpRequest<\/em>, a built-in browser object that can also be leveraged during an attack to send stolen data to an attacker\u2019s server.<\/p>\n\n\n\n The vulnerability itself was ultimately found to reside in the app\u2019s 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<\/em> and (usually) a host<\/em> 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\u2019s manifest to be used by components outside of the application\u2019s context:<\/p>\n\n\n\n In the example above in Figure 5,<\/p>\n\n\n\n To avoid the ambiguity dialog for http<\/em> and https<\/em> schemes, an application may declare an Android App Link<\/a> by using the autoVerify<\/em> 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\u2019s package name and its certificate\u2019s SHA256 fingerprint must be published under https:\/\/domain.name\/.well-known\/directory. <\/em>TikTok for Android uses this feature for the domain m.tiktok.com<\/em>, meaning all the links matching to the specific domain will be routed to the application without presenting the ambiguity dialog.<\/p>\n\n\n\n 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 \u201cunable to resolve Intent\u201d error message as the system can\u2019t route it to the appropriate handler.<\/p>\n\n\n\n It\u2019s important to understand the various components at play that allow the vulnerability to be exploited, such as the app\u2019s implementation of JavaScript interfaces, since they determine the impact of the vulnerability itself. While reviewing the app\u2019s handling of a specific deeplink, we discovered several issues that, when chained together, could have been used to force the application to load an arbitrary URL to the application\u2019s WebView. By crafting this URL with additional query parameters, it was possible to inject an instance of the JavaScript bridge that provides full access to the functionality implemented by the [redacted]<\/strong>.bridge.*<\/em> package.<\/p>\n\n\n\n What follows is a technical description of the vulnerability, which we analyzed using the TikTok Android application with the package name com.zhiliaoapp.musically<\/em>. The same description applies for the TikTok Android application com.ss.android.ugc.trill<\/em>, as the vulnerabilities were found in common SDKs.<\/p>\n\n\n\n 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<\/em> link is handled by the [redacted]<\/strong> class and is used to redirect URIs to various components of the application via a query parameter:<\/p>\n\n\n\n We determined that it\u2019s 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\u2019t raise any additional concerns.<\/p>\n\n\n\n As a proof of concept, we crafted a URL that uses a particular non-exported scheme to load https:\/\/www.tiktok[.]com<\/em> to the application\u2019s WebView, as displayed below in Figure 8: <\/p>\n\n\n\n Although the [redacted-internal-scheme]<\/strong>:\/\/webview?url=<website><\/em> deeplink can be used to load URLs to the CrossPlatformActivity\u2019s<\/em> WebView via a query parameter, the application imposes filters to reject untrusted hosts. In contrast to the Tiktok.com<\/em> domain successfully loading, as shown in Figure 8 above, Figure 9 below displays the domain Example.com<\/em> being rejected by the application filters:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The WebView attached to the activity creates instances of the JavaScript bridge, which we verified dynamically using Medusa\u2019s<\/a> WebView module. From this point on, the website assigned to the query parameter of the [redacted-scheme]<\/strong>:\/\/webview<\/em> scheme has full access to the JavaScript bridge, meaning the website\u2019s JavaScript code can now access and invoke any exposed functionality found under the [redacted]<\/strong>.bridge.*<\/em> package.<\/p>\n\n\n\n Reviewing the functionality accessible to the JavaScript code in web pages loaded to WebView, we identified more than 70 exposed methods. When paired with an exploit to hijack WebView, such as the vulnerability we discovered, these methods can be invoked to grant functionality to attackers. Some of the exposed methods can access or modify users\u2019 private information, while others can perform authenticated HTTP requests to any URL given as a parameter. Moreover, the method accepts a set of parameters in the form of a JSON string that can be used to form the body of a POST request and returns the server\u2019s reply, including the headers. <\/strong><\/p>\n\n\n\n By invoking such methods, an attacker can:<\/p>\n\n\n\n In short, by controlling any of the methods able to perform authenticated HTTP requests, a malicious actor could have compromised a TikTok user account.<\/strong><\/p>\n\n\n\n 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\u2019s biography information to read \u201c!! SECURITY BREACH !!\u201d:<\/p>\n\n\n\n Once the attacker\u2019s specially crafted malicious link is clicked by the targeted TikTok user, the attacker\u2019s server, https:\/\/www.attacker[.]com\/poc,<\/em> is granted full access to the JavaScript bridge and can invoke any exposed functionality. The attacker\u2019s server returns an HTML page containing JavaScript code to send video upload tokens back to the attacker as well as change the user\u2019s profile biography.<\/p>\n\n\n\n The video uploading authentication tokens are sent back to the attacker via an XMLHttpRequest<\/em>. The attacker also receives the reply body and the header, depicted in Figure 10 and 11 below:<\/p>\n\n\n\n Finally, the message \u201c!! SECURITY BREACH !!!\u201d is set in the user profile\u2019s biography:<\/p>\n\n\n\n As this case and our prior research<\/a> has shown, from a programming perspective, using JavaScript interfaces poses significant risks. A compromised JavaScript interface can potentially allow attackers to execute code using the application\u2019s ID and privileges. Thus, we recommend that the developer community be aware of the risks and take extra precautions to secure WebView.<\/p>\n\n\n\n In cases where using JavaScript interfaces cannot be avoided, we suggest using an approved list of trusted domains to be loaded to the application\u2019s WebView to prevent loading malicious or untrusted web content. Additionally, we suggest the following secure coding practices:<\/p>\n\n\n\n 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<\/em> Microsoft, not just for<\/em> Microsoft.<\/p>\n\n\n\n We use collaborative research such as this to improve our protection technologies across platforms, ensuring Microsoft Defender Vulnerability Management<\/a> detects and alerts on installed applications with known vulnerabilities\u2014including those affecting non-Windows devices. While we\u2019re 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:<\/p>\n\n\n\n As part of our responsible disclosure policy through Coordinated Vulnerability Disclosure<\/a> (CVD) via Microsoft Security Vulnerability Research<\/a> (MSVR), we disclosed the vulnerability<\/a> to TikTok in February 2022 as directed on its website<\/a>. The vulnerability, CVE-2022-28799<\/a>, 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.<\/p>\n\n\n\n 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\u2019 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.<\/p>\n\n\n\n Dimitrios Valsamaras <\/em><\/strong> Microsoft discovered a high-severity vulnerability in the TikTok Android application, now identified as CVE-2022-28799 and fixed by TikTok, which could have allowed attackers to compromise users’ accounts with a single click.<\/p>\n","protected":false},"author":153,"featured_media":121178,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ms_queue_id":[],"ep_exclude_from_search":false,"_classifai_error":"","_classifai_text_to_speech_error":"","_alt_title":"","ms-ems-related-posts":[],"footnotes":""},"post_tag":[3741],"threat-intelligence":[3739],"content-type":[3663],"job-role":[],"product":[],"topic":[3687],"coauthors":[3380],"class_list":["post-121109","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-android","threat-intelligence-vulnerabilities-and-exploits","content-type-research","topic-threat-intelligence","review-flag-1694638265-576","review-flag-1-1694638265-354","review-flag-2-1694638266-864","review-flag-3-1694638266-241","review-flag-4-1694638266-512","review-flag-5-1694638266-171","review-flag-6-1694638266-691","review-flag-7-1694638266-851","review-flag-8-1694638266-352","review-flag-9-1694638266-118","review-flag-alway-1694638263-571","review-flag-never-1694638263-791","review-flag-new-1694638263-340"],"yoast_head":"\nJavaScript interfaces<\/h2>\n\n\n\n
![\"Code](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-1.-Adding-a-JavaScript-interface-to-a-WebView-object.png\")
JavaScript bridge<\/h2>\n\n\n\n
![\"Code](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-2.-Rendering-the-method-callable-via-the-JavaScript-code.png\")
![\"Code](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-3.-Example-code-invoking-a-Java-method-via-the-JavaScript-interface..png\")
![\"Diagram](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-4.-Interaction-between-Java-and-web-components-using-the-JavaScript-interface.png\")
\n
Diving into deeplinks<\/h2>\n\n\n\n
![\"Code](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-5.-An-example-of-adding-an-intent-filter-in-the-apps-manifest-for-deep-linking..png\")
\n
\n
![\"Image](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-6-FULL.png\")
Vulnerability findings<\/h2>\n\n\n\n
Triggering the app\u2019s internal deeplinks<\/h3>\n\n\n\n
![\"Code](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-7.-Identifying-deeplinks-and-their-targeted-activities-using-Medusa.png\")
![\"An](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-8.-Using-a-link-to-trigger-an-internally-used-scheme-and-load-Tiktok.com_..png\")
![\"An](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-9.-The-applications-filters-rejecting-the-deeplink.png\")
Exposed functionality<\/h2>\n\n\n\n
\n
Proof of concept<\/h2>\n\n\n\n
![\"Code](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-10.-The-request-headers-retrieved-by-the-attack.png\")
![\"Code](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-11.-The-servers-reply-including-the-headers.png\")
![\"An](\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/wp-content\/uploads\/2022\/08\/Figure-12.-Compromising-the-users-profile-integrity.png\")
JavaScript interface best practices<\/h2>\n\n\n\n
\n
Responsible disclosure and industry collaboration improves security for all<\/h2>\n\n\n\n
\n
Microsoft 365 Defender Research Team<\/em><\/p>\n\n\n\nReferences<\/h2>\n\n\n\n
\n