taktale yitzak lateanah
Magdalena Liendo
ESET researchers discovered a zero-day exploit that targets Telegram for Android, which appeared for sale for an unspecified price in an underground forum post from June 6th, 2024. Using the exploit to abuse a vulnerability that we named EvilVideo, attackers could share malicious Android payloads via Telegram channels, groups, and chat, and make them appear as multimedia files.
We were able to locate an example of the exploit, allowing us to analyze it further, and report it to Telegram on June 26th, 2024. On July 11th, they released an update that fixes the vulnerability in Telegram versions 10.14.5 and above.
In the post, the seller shows screenshots and a video of testing the exploit in a public Telegram channel. We were able to identify the channel in question, with the exploit still available. That allowed us to get our hands on the payload and test it ourselves.
Our analysis of the exploit revealed that it works on Telegram versions 10.14.4 and older. We speculate that the specific payload is most likely crafted using the Telegram API, since it allows developers to upload specifically crafted multimedia files to Telegram chats or channels programmatically.
The exploit seems to rely on the threat actor being able to create a payload that displays an Android app as a multimedia preview and not as a binary attachment. Once shared in chat, the malicious payload appears as a 30-second video (Figure 3).
However, if the user taps the Open button in the displayed message, they will be requested to install a malicious app disguised as the aforementioned external player. As seen in Figure 5, before installation, Telegram will ask the user to enable the installation of unknown apps.
A very similar thing happened with the Telegram Desktop client for Windows: the downloaded file was named Teating.apk.mp4, so it was once again an APK binary file with a .mp4 extension. This suggests that even if an attacker crafted a Windows executable to be used instead of the Android APK, it would still be treated as a multimedia file and the exploit would not work.
While we do not know much about the threat actor, we managed to find another shady service they are providing based on the Telegram handle the seller shared in their forum post. In addition to the exploit, they have been using the same underground forum to advertise an Android cryptor-as-a-service that they claim is fully undetectable (FUD) since January 11th, 2024. The forum post can be seen in Figure 8.
After discovering the EvilVideo vulnerability on June 26th, 2024, we followed our coordinated disclosure policy and reported it to Telegram, but received no response at the time. We reported the vulnerability again on July 4th, and that time, Telegram reached out to us the same day to confirm its team was investigating EvilVideo. They fixed the issue, shipping version 10.14.5 on July 11th, and informed us via email.
The vulnerability affected all versions of Telegram for Android up to 10.14.4, but has been patched as of version 10.14.5. As we verified, the chat multimedia preview now correctly displays that the shared file is an application (Figure 9) and not a video.
We discovered a zero-day Telegram for Android exploit for sale on an underground forum. The vulnerability it exploits allows sending malicious payloads that look like multimedia files via Telegram chat. If a user tries to play the apparent video, they will receive a request to install an external app, which actually installs the malicious payload. Luckily, the vulnerability has been fixed as of July 11th, 2024, after we reported it to Telegram.
The most severe of these flaws is a vulnerability in the System component that could lead to remote code execution (RCE) without any additional execution privileges required. User interaction is not needed for exploitation.
A critical security vulnerability was discovered in reCAPTCHA Enterprise for Mobile. The vulnerability has been patched in the latest SDK release. Customers will need to update their Android application with the reCAPTCHA Enterprise for Mobile SDK, version 18.4.0 or above. We strongly recommend you update to the latest version as soon as possible.
How can I fix this problem? I am already using the latest version of flutter and firebase auth. My flutter doctor is coming back all healthy. My build.gradle files don't contain any references to reCAPTCHA. From what I can tell, the entire reCAPTCHA setup is handled by firebase?
As answered by Martin Reindl, you can override reCaptcha version by adding recaptcha_enterprise_flutter: ^18.4.0 or implementation 'com.google.android.recaptcha:recaptcha:18.4.0' in dependencies section of your app-level build.gradle file.
I would still appreciate a more complete answer of why this is happening? It seems incredibly odd that I have to patch security issues in firebase auth manually (when the service is used by tens of millions of users every day).
As the quickest and simplest solution I added implement com.google.android.recaptcha:recaptcha:18.4.0 to build.gradle although I am not using recaptcha in my app. This method worked and the warning was gone
The APVI covers Google-discovered issues that could potentially affect the security posture of an Android device or its user and is aligned to ISO/IEC 29147:2018 Information technology -- Security techniques -- Vulnerability disclosure recommendations. The initiative covers a wide range of issues impacting device code that is not serviced or maintained by Google (these are handled by the Android Security Bulletins).
The checkUidPermission method in the PackageManagerService class was modified in the framework code for some devices to allow special permissions access to some apps. In one version, the method granted apps with the shared user ID com.google.uid.shared any permission they requested and apps signed with the same key as the com.google.android.gsf package any permission in their manifest. Another version of the modification allowed apps matching a list of package names and signatures to pass runtime permission checks even if the permission was not in their manifest. These issues have been fixed by the OEMs.More informationKeep an eye out at for future disclosures of Google-discovered security issues under this program, or find more information there on issues that have already been disclosed.
In our example, the code below demonstrates how a JavaScript interface is used, an instance of the JsObject class is injected into WebView (line 8) and it is referenced by the injectObject variable within the JavaScript code, which is loaded via the loadUrl API method (line 10):
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].bridge.* package. This bridge exposes the method depicted below:
The func attribute corresponds to the name of the Java method that is invoked from the JavaScript code, while the params attribute sets arguments that this method takes. For example, to call the Java method with signature String foo(String arg1, String arg2) from the JavaScript code, the following statement must be used:
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.
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 [.]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:
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.
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.
c01484d022