Uncovering Android Master Key That Makes 99% of Devices Vulnerable

[djohnston]

Source

Written By Jeff Forristal, Bluebox  CTO

The Bluebox Security research team – Bluebox Labs – recently discovered a vulnerability in Android’s security model that allows a hacker to modify APK code without breaking an application’s cryptographic signature, to turn any legitimate application into a malicious Trojan, completely unnoticed by the app store, the phone, or the end user. The implications are huge! This vulnerability, around at least since the release of Android 1.6 (codename: “Donut” ), could affect any Android phone released in the last 4 years1 – or nearly 900 million devices2– and depending on the type of application, a hacker can exploit the vulnerability for anything from data theft to creation of a mobile botnet.

While the risk to the individual and the enterprise is great (a malicious app can access individual data, or gain entry into an enterprise), this risk is compounded when you consider applications developed by the device manufacturers (e.g. HTC, Samsung, Motorola, LG) or third-parties that work in cooperation with the device manufacturer (e.g. Cisco with AnyConnect VPN) – that are granted special elevated privileges within Android – specifically System UID access.

Installation of a Trojan application from the device manufacturer can grant the application full access to Android system and all applications (and their data) currently installed. The application then not only has the ability to read arbitrary application data on the device (email, SMS messages, documents, etc.), retrieve all stored account & service passwords, it can essentially take over the normal functioning of the phone and control any function thereof (make arbitrary phone calls, send arbitrary SMS messages, turn on the camera, and record calls). Finally, and most unsettling, is the potential for a hacker to take advantage of the always-on, always-connected, and always-moving (therefore hard-to-detect) nature of these “zombie” mobile devices to create a botnet.

How it works:

The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature.

All Android applications contain cryptographic signatures, which Android uses to determine if the app is legitimate and to verify that the app hasn’t been tampered with or modified. This vulnerability makes it possible to change an application’s code without affecting the cryptographic signature of the application – essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been.

Details of Android security bug 8219321 were responsibly disclosed through Bluebox Security’s close relationship with Google in February 2013. It’s up to device manufacturers to produce and release firmware updates for mobile devices (and furthermore for users to install these updates). The availability of these updates will widely vary depending upon the manufacturer and model in question.

The screenshot below demonstrates that Bluebox Security has been able to modify an Android device manufacturer’s application to the level that we now have access to any (and all) permissions on the device. In this case, we have modified the system-level software information about this device to include the name “Bluebox” in the Baseband Version string (a value normally controlled & configured by the system firmware).



How to get more details:

Technical details of the issue, and related tools/material, will be released as part of my Black Hat USA 2013 talk. During the talk, I will review the bug, including how it was found, and how it works. After the talk, we will post a follow-up post to our blog with a link to materials from the talk and you can track this information via @BlueboxSec

Recommendations

    Device owners should be extra cautious in identifying the publisher of the app they want to download.
    Enterprises with BYOD implementations should use this news to prompt all users to update their devices, and to highlight the importance of keeping their devices updated.
    IT should see this vulnerability as another driver to move beyond just device management to focus on deep device integrity checking and securing corporate data.

1. http://developer.android.com/about/dashboards/index.html

2. http://venturebeat.com/2013/05/15/900m-android-activations-to-date-google-says/

[djohnston]

Bluebox's Android "masterkey" hole identified

Since Bluebox announced that it had found a "masterkey" hole in Android, various security researchers have been looking into what the problem could be. It appears that the problem is a simple implementation bug in how Android verifies JAR/ZIP/APK files. An issue on the CyanogenMod developers' tracker sheds more light on the problem. It is possible to take an Android archive file and add a modified version of a Java class file before the original file in the archive. When the Android operating system goes to verify the signature on the file, it examines the latter, original file and, as this is unchanged, will pass the archive as valid. But when the archive is actually used, it is the first, modified version of the file in the archive that is used.

CyanogenMod project lead, Steve Kondik, has already committed a patch by Geremy Condra of Google, which adds a check for duplicate names and throws an exception when one occurs. Examining the current Android Open Source Project source tree shows that this fix has not been applied to the relevant file, which is in line with what Jeff Forristal, CTO of Bluebox said in interviews.

The appearance of two files with identical names in a JAR/ZIP/APK archive will provide application scanners with a simple signature for detecting modified archives and, presumably, it is this that Google scanned for when checking the content of the Google Play Store. An attacker would still need to introduce a modified APK into the delivery chain somehow. It is still unclear how Bluebox's claim that manipulating system packages could give attacks arbitrary privileges as, in order to install or replace a system package, an attacker would already need system privileges.

The big problem for Google now though, is to ensure that the tens of millions of Android devices that have been sold do get updated with fixed firmware. A first step would at least be to apply the fix to the open source version of Android officially. Although the threat can be mitigated by better app store hygiene.