Archive for August 12th, 2014

Security researchers from Bluebox Labs recently uncovered a vulnerability that may allow malicious apps to impersonate legitimate ones. This vulnerability, dubbed as “FakeID,” is involved with the checking of certificate signatures to prove the legitimacy of applications. What makes this highly notable is that all Android devices running on platforms starting from Android 2.1 (“Éclair”) to 4.4 (“KitKat”) are affected by this vulnerability.

Certificates and Signatures

Android applications must be “signed” before they are published and released for installation. Signing apps involves the use of certificates. Like the HTTP/SSL certificate model, app certificates are issued by trusted certificate authorities. The certificates are used to ensure the integrity of the application after its release, to avoid any tampering from attackers. These certificates are used by the app as its “package signature.” These signatures are used by Android to identify applications.

How does Android go about assigning these signatures? For every app installed on the device, a class called PackageInfo is created to profile the app. PackageInfo contains a property, called “signatures,” which plays an important role for apps. With the same signatures, one application can work as another app’s update package, or two apps can share their data with each other (as some form of shared mechanism). In some special cases, Android can decide if it will grant privileges to an application by comparing if the app has the same signatures in its “signatures” property as the signatures hardcoded in the Android source code.

Bluebox Labs cited two examples of how this works. One example is payment-related apps being allowed to access the NFC SE hardware of a mobile device because these have the signatures specified in the device’s NFC-related file. Another is an app being allowed to act as a webview plugin (for example, Adobe Flash plugin) for other apps because the app has the signature of Adobe Systems.

Flaws in the Certificate Chain

Once an app is installed in a device, the Android platform creates its PackageInfo signatures by creating a certificate chain using the app’s certificate file. However, because of the vulnerability, Android does not verify the authenticity of the certificate chain. It will only rely on the correspondence between the signer certificate’s “Subject” and the signed certificate’s “Issuer.” Unfortunately, these two are clear text string type, which can be easily forged by malicious individuals.

Exploiting the Vulnerability

Because the vulnerability deals with the “authenticity” of apps, cybercriminals can create malicious apps that will be able to access sensitive data without arousing any suspicion. For example, NFC-related payments often use Google Wallet. If a malicious app is granted NFC privilege, it will be able to steal the user’s Google Wallet account information, replace designated payment accounts, and steal the user’s money.

A malicious app can also take advantage of the Webkit plugin privilege, provided it has the associated permission and the required signature. The app will automatically run as a Webkit plugin process whenever the victim browses a site using a browser app or uses other applications that require a webview component. Because the malware is running as a component process inside the browser (or other applications using webview), the malware has almost complete control over the application’s data. All related data such as user credentials, bank account, and email details can be accessed, leaked, or tampered.

Majority of Android Users Affected

As we stated earlier, all Android devices without patches from OEM vendors are affected by this vulnerability. Current data from Google shows that the devices running on the affected platforms represent around 82% of all Android devices. The large number of affected Android users echoes that of the master key vulnerability discovered last year.

Google has released a fix for this bug. However, the fragmentation of the Android ecosystem means that not all users might be able to have their devices protected against this vulnerability. Should the update become available, we advise users to immediately update their devices.

Google has issued a statement saying that they have “scanned all applications submitted to Google Play as well as those Google has reviewed from outside of Google Play, and…have seen no evidence of attempted exploitation of this vulnerability.”

To protect our users, we are watching out for possible threats and attacks that may take advantage of this vulnerability. Apps that take advantage of this vulnerability are detected as ANDROIDOS_FAKEID.A.

The incidents that cropped up in the months of April to June 2014—from the data breaches, DDoS attacks, to malware improvements and threats to privacy—highlighted the need for enterprises to craft a more strategic response against and in anticipation of security threats.

There were plenty of threats to be found in the quarter. There was the major vulnerability, Heartbleed, in the widely used cryptographic library OpenSSL. We saw both tech companies and restaurant chains fall victim to data breaches. We saw Windows XP patched one last time by Microsoft post-EOS. We saw major decisions in the judicial systems of the United States and Europe that could affect how data is handled and protected for years to come.

Other parts of the threat landscape continued to become a bigger problem. Both online banking malware and mobile malware continued to affect many users:

Figure 1. Online banking malware detection volume

Figure 2. Cumulative mobile malware threat volume

Some organizations will deal with these incidents in an exemplary manner. Others will fail. Most will be somewhere in between. Part of this quarter’s roundup discusses how several organizations dealt with various online threats that affected them, and what others can learn from these examples.

Of course, cybercrime and targeted attacks are not the only perceived “threats” in the world. Increasingly, large Internet companies and government surveillance are perceived as “threats” as well. Here, too, we see how these threats are being addressed: both the EU’s “right to be forgotten” and Riley v. California, a US Supreme Court decision that held that searching the information on a cellphone requires a warrant, can be viewed as responses of the American and European legal systems to the situations in both regions. As digital problems intrude more on the daily lives of users, it is nearly certain that courts will have to weigh in moving forward.

More details about the threats found in the second quarter—as well as how these threats were dealt with—can be found in TrendLabs report entitled Turning the Tables on Cyber Attacks.