mod%log

We identified a security weakness in Android's approach of handling UI elements, circumventing parts of Android's sandboxing approach. While this attack is simple from a technical point of view, the impact of exploiting such a vulnerability is significant. It affects Android based devices as well as Blackberry mobile devices running the Android runtime environment.

By using standard Android APIs (in particular those offered via permissions SYSTEM_ALERT_WINDOW and GET_TASKS) a malicious application could monitor the current activities and launch target-specific overlay attacks. The malicious application is completely independent from the target application and could vary its attack targets based on the applications on the Android based device. If the overlaid dialog is convincingly similar, the user is fooled and will enter sensitive information such as account credentials. This is not limited to text or password fields as an attacker could also overlay a camera activity to steal images and interfere with electronic banking applications such as common for two-factor authentication schemes, where the activation letter is photographed and the mobile serves as the second factor. Additionally, the attack is not limited to inputs, a malicious app can overlay information displayed to the user. One scenario is a malicious app that overlays the transaction information (like amount and IBAN) shown when the two-factor authentication banking app prompts to verify the transaction (transaction signing).

Overlaying and redressing attacks on Android are known for several years now [1]. 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.

We created several screen recordings to demonstrate the issue. They show the simplest form of the attack, where an attacker would steal the login credentials of Skype by overlaying the login form with his own at the correct moment. The Skype application serves as an example victim app. The app called "a very cool app" on the screen is our malicious application. You can try to identify when the overlay appears in our screen recording (USB debugging was enabled because it was necessary for the screen recording).

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 for example by using these layout parameters:

WindowManager.LayoutParams lp = new WindowManager.LayoutParams(
  WindowManager.LayoutParams.__MATCH_PARENT,
  WindowManager.LayoutParams.__MATCH_PARENT,
  WindowManager.LayoutParams.__TYPE_SYSTEM_ALERT,
  WindowManager.LayoutParams.__FLAG_NOT_TOUCH_MODAL,
  PixelFormat.TRANSLUCENT);

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 user enters his credentials again and can use the Skype app as usual. Because an attacker is able to inspect the class name of front activities, he can often precisely place the faked activity on top of the user interface.

To further demonstrate the issue, we also attacked the process of adding a new Google account in the Android Settings. While it would be possible to time the overlay better, we display the overlay a little bit too early for demonstration purposes. You should be able to spot the exact moment when the overlay occurs in the following screen recording

In this case we took a different approach and only overlaid the two input fields (email and password) as well as the buttons on the bottom of the screen. For this attack we used other layout parameters:

WindowManager.LayoutParams lp = WindowManager.LayoutParams(
  WindowManager.LayoutParams.MATCH_PARENT,
  WindowManager.LayoutParams.MATCH_PARENT,
  WindowManager.LayoutParams.TYPE_TOAST,
  0,
  PixelFormat.TRANSLUCENT);

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. modzero was able to reproduce the Skype attack on Android 5. The overlay is taking place whenever the Skype app is in the foreground. Other demonstrations on Android 5 involved checking the usage of the Camera by the victim application and triggering the overlay depending on such indicators. Therefore the API change does not fix the root issue.

Moreover, an application using only WebViews (HTML5 apps) are usually using only one Activity in the entire application. Therefore these apps have the same mitigation already in place prior to Android 5.

Additionally, the Android Security Team points out that a user has to willingly install such an app and give it the appropriate permissions. However, there are several reasons we consider the Android permission system to be broken. Due to the missing opt-in or opt-out feature for Android permission, a user can only chose between installation (and granting all permissions) or not using the application. This is especially problematic if the user needs the app, but an app update asks for more permission. Again, the user can only chose between updating (and granting all permissions), uninstalling (and losing the functionality of the app) or not installing the update. However, not installing the update is usually problematic, as the user will miss future security updates in the app and might have server-compatibility issues and such in the future.

Another argument is the involvement of the user in the decision of granting permissions. As Edward Felten used to say: "Given a choice between dancing pigs and security, users will pick dancing pigs every time." Usually users do not check app permissions thoroughly.

The Android Security Team also mentioned, that apps will be analyzed for harmful behavior before they are published in the app store. To show that this countermeasure is not effective, we built an app called "Dancing Pigs" (a homage to the above quote of Edward Felten). We uploaded it to the Google Play Store [4].

The legitimate functionality of the app is to show a pig picture whenever the user has no app open. The app will download a configuration file from a remote server and will do overlays depending on the configuration file. At the moment this app demonstrates the attack for the Google account settings dialogue for LG g3 devices, no further configurations were added on the server so far.

The described vulnerabilty in this blog post is a feature as well as a security issue. While every security expert acknowledges that malware on a Windows operating system is fatal, mobile security people will often argue with the sandboxing approach for Android. This issue shows that the Android sandboxing approach is fundamentally broken. Sandboxing has to be applied on all levels, otherwise it will fail.

*UPDATE*

During our research we missed a related work from 2011 by Riley Hassell and Shane Macaulay. We are sorry for that and want to correctly give credit where credit is due. The Android issue they call App Phishing is briefly described in a Forbes article and starting on slide 14 in the related talk from Hack in the Box 2011 and the corresponding video at 10:52. We independently discovered the issues, but this work already describes the fundamental technique that we used as far as we can tell from the available information. However, we cover the attack in-depth and demonstrated variations for Android 5 and Blackberry devices. Our proof of concept app that we put into the Google Play store is now published as source code https://github.com/floyd-fuh/AndroidOverlayPoc to reproduce the attacks as well as the slides of Tobias' presentation.

• [1] https://www.blackhat.com/docs/asia-14/materials/Niemietz/Asia-14-Niemietz-UI-Redressing-Attacks-On-Android-Devices-Revisited.pdf
• [2] https://android.googlesource.com/platform/frameworks/base/+/09233289624a85093b1d99e4a6a149bf09059d8d
• [3] http://developer.android.com/about/versions/android-5.0-changes.html#BehaviorGetRecentTasks
• [4] https://play.google.com/store/apps/details?id=ch.example.dancingpigs