Google bug 13678484, aka Android ‘Fake ID’, was just disclosed. What is this vulnerability all about?
In a nutshell, this vulnerability enables a threat actor to compromise specific applications or sensitive device data by falsifying its identity. As a result, a threat actor can either access app data, access private NFC payment data or obtain device management capabilities.
Customers of Lacoon Mobile Security are secure against the threat of exploiting this vulnerability. Lacoon has been aware of this vulnerability and has had a solution for it for some time now.
Threat Walk-Through
What would an attack exploiting this vulnerability look like?
- The threat actor builds a malicious Android app and signs the app with a malformed chain-of-trust such that the malicious app impersonates Adobe’s Flash Plugin, Google Wallet or a 3LM device management extensions.
- The threat actor lures the victim to install the app. This could be performed by sending a phishing link to the Android app installation (APK) within an email or a text message.
- When the victim installs the app, Android mistakenly considers the app as signed by Adobe/ Google/ 3LM. Consequently, Android allows code to either run in the permission-context of an attacked app (in the case of Adobe Flash) or grants the app with elevated privileges.
- Depending on the app and the fake signature that is used (Adobe, Google or 3LM), the malicious app can perform a variety of nefarious actions, such as: access sensitive app data, access NFC payment data or take full control of the 3LM management software.
Fake ID – Threat Walk Through
Affected Devices
According to the researchers who found the mobile security vulnerability, all devices from Android 2.1 to Android 4.4 are affected.
The Impact
By exploiting the Android ‘Fake ID’ vulnerability, a threat actor can perform any of these three nefarious activities:
- Infect specific apps with malicious code. These specific apps are those that use Web view (i.e. the app’s embedded browser window) with the Adobe Flash plug-in. The malicious code can access the victim’s app data and even device data if the targeted app has the required privileges to access device data.
- Access the private NFC payment data. NFC enables mobile payment and this vulnerability enables the threat actor to access the sensitive payment and financial data.
- Undermine the 3LM device management software in order to obtain device information. 3LM appears in specific handset vendors such as Motorola, HTC, Sony-Ericsson. It is an Android component for device management and its extensions can be abused by the vulnerability.
The Chain-of-Trust Concept – 101
Each time an app is installed, the Android device first verifies that the app is a legitimate one that has not been modified by threat actors. The verification mechanism works by comparing the app’s signer certificate with the details of the issuer’s certificate – both are included in each Android app.
The certificate itself is a sort of validation that the app has been authorized to run by the app’s developer, or by a trusted third party. Typically, the certificate used by Android developers to sign their app is self-signed (meaning, the signer is actually the one who also issued the certificate). However, a certificate can also contain a separate issuer than the actual signer of the certificate. This can be done multiple time to create of chain of certificates each one signing the next. This chain of certificates is called the chain-of-trust.
Within the certificate, there also is a ‘subject’ – text that describes the signer of each of the certificates. The certificate also contains the app’s public key which Android uses as a form of ID.
The Vulnerability: Android incorrectly builds the chain-of-trust
The problem is that when Android builds the chain-of-trust, the verification process only compares the ‘subject’ rather than comparing the actual key with the one provided within the details of the certificate’s signer. As a result, an attacker can tinker with the chain-of-trust and claim to be signed by a party – without the party actually signing.
Due to this bug a wrong certificate chain is generated, and might include legitimate certificates, which are embedded in APK but weren’t been used to actually sign the application.
The Irony: the vulnerability that should not have been
The underlying Android app framework uses Java’s standard libraries, and as such it has also migrated Java’s chain-of-trust concept – along with its set of implementation vulnerabilities. Ironically, Android currently does not even require the usage of the chain-of-trust concept for its regular app verification process: during application installation or updates, the Android Package Manager compares the entire certificate chain structure as opposed to its content. The only place where the chain-of-trust is examined is for select apps which allow escape hatches out of the standard Android permission model. This is used as a quick-and-dirty solution by WebView’s plugin manager, NFC’s access control, and the 3LM management extensions.
Threat Mitigation
Customers of Lacoon Mobile Security are secure against the threat of exploiting Android ‘Fake ID’ vulnerability.
By performing app analysis, Lacoon is able to identify apps containing a malformed chain-of-trust and alerts the security team.
Currently, Android incorrectly examines the chain-of-trust by comparing the subjects of the certificate and its issuer – and does not validate the cryptographic validity of the issuer and signer chain. Android needs to check also the keys to close this vulnerability (and this is what the Google Bug 13678484 fixes).
Although the following mitigation controls do not provide comprehensive coverage against the exploit of this vulnerability, we still recommend enterprises adopt these as to minimize the threat of exposure:
- Enforce that applications are installed only from reputable sources, i.e. from the official Google Play.
- Advise employees to read app reviews and the developer’s popularity scores.
- Instruct employees not to open suspicious/ unknown links sent to the device.