Google Android UI Handler Overlay authentication spoofing ⚔ [Disputed]

Summaryinfo

A vulnerability identified as critical has been detected in Google Android. Affected is an unknown function of the component UI Handler. Performing a manipulation results in authentication spoofing (Overlay). Additionally, an exploit exists. The existence of this vulnerability is still disputed at present.

Detailsinfo

A vulnerability classified as critical has been found in Google Android (Smartphone Operating System). This affects some unknown functionality of the component UI Handler. The manipulation with an unknown input leads to a authentication spoofing vulnerability (Overlay). CWE is classifying the issue as CWE-290. This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. This is going to have an impact on confidentiality, integrity, and availability.

The weakness was released 04/01/2015 by Tobias Ospelt with modzero AG as Android apps in sheep's clothing as confirmed advisory (Website). The advisory is shared at modzero.ch. The public release happened without involvement of Google. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are unknown but a public exploit is available. The advisory points out:

Overlaying and redressing attacks on Android are known for several years now. In the past, attackers abused toast messages to overlay user interface elements to pass touch events to hidden activities while the user is handling the interface of the malicious app on top. This is known as tap-jacking. Toast messages do not require special permissions. Android mitigated some of these issues with the filterTouchesWhenObscured attribute. However, our overlay attack, while still stealing information, uses different mechanisms. Therefore filterTouchesWhenObscured is no effective mitigation.

A public exploit has been developed in Java and been published even before and not after the advisory. The exploit is shared for download at play.google.com. It is declared as highly functional. The vulnerability was handled as a non-public zero-day exploit for at least 1 days. During that time the estimated underground price was around $25k-$100k. The real existence of this vulnerability is still doubted at the moment. The advisory illustrates:

The attack is implemented in a malicious app, which may be distributed over any channel and it mimics a useful app (for example a torch app). The software registers a background service on boot and continuously monitors foreground applications. In this scenario, the attacker wants to collect account credentials of services, for example Skype, Amazon, and PayPal. If a foreground app’s package/class name matches the target name (for example “com.skype.android.app.signin.SignInActivity"), the malicious app overlays the login activity by rendering the faked login view (...) The original activity can be overlaid completely or partially, whatever is simpler for the attacker. For the Skype attack we chose to overlay the entire Activity. The attack may use the original app resources from its unpacked apk file (layout xml files) to get exactly the same look and feel of the original app. Once the user submits account credentials, the attacker hides the overlay and a home button press is activated to simulate an application crash. The malicious application diverts the stolen account credential to an external server (in the above demonstration the credentials are shown in the malicious app). From this point on no overlay is taking place anymore and the Skype app is working as expected.

The advisory contains the following remark:

The Android Security Team has been informed in spring 2014, but they don't consider this behavior an issue. According to an apparently completely independent issue (privacy reasons) Android 5 changed its tasks API (GET_TASKS), there are no credits are reference to our work [2][3]. This somewhat mitigates the issue that malicious apps are able to figure out precisely which Activity is in the foreground. However, by using a different API (ActivityManager.getRunningAppProcesses and comparing the importance to ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND) it is still possible to figure out which app is currently in the foreground on Android 5.

Further details are available at nzz.ch. Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Google Android
• RIM BlackBerry

Productinfo

Type

• Smartphone Operating System

Vendor

• Google

Name

• Android

License

• free

Website

• Vendor: https://www.google.com/

CPE 2.3info

• 🔍

CPE 2.2info

• 🔍

Screenshot

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion