eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
At last year’s Black Hat USA conference, Jeff Forristal revealed the Master Key vulnerability impacting millions of Android users. For the upcoming Black Hat 2014 event, Forristal is back with another deep flaw within Android, this time a Fake ID vulnerability that could enable attackers to impersonate valid app developers.
Forristal plans on providing full details of the Fake ID flaw, identified as Google bug 13678484, in a session at Black Hat USA 2014, which runs Aug. 4-7 in Las Vegas.
Forristal is CTO of Bluebox Security, a company that focuses on mobile security.
“Bluebox discovered a vulnerability in how Android processes the digital signature identities that are attached to Android apps,” Forristal told eWEEK.
Forristal explained that his team was able to find a way different from the Master Key vulnerability he exposed in 2013 to exploit Android. With Master Key, Bluebox found a family of bugs that allow an attacker to bypass Android’s signature verification process. By enabling that bypass, a malicious Android app could potentially be enabled to run on a user’s device.
With the new Fake ID vulnerability, applications are able to fraudulently use the identification of a legitimate app author.
“So an attacker can create malware and use the Fake ID to claim that they are Adobe, for example,” Forristal said. “So now when a user installs the attacker’s app, Android gives the app special access.”
Android is actually hard-coded to give apps from Adobe special permissions, such that Adobe is allowed to be a plug-in for other apps, Forristal explained. In the case of the Fake ID vulnerability, a malicious app can then be enabled to inject malicious code into any other app.
There are other identities beyond just the Adobe one that can potentially be abused by the Fake ID vulnerability. An attacker could, for example, leverage the Google Wallet identity, Forristal said. Google Wallet is a payment system that is integrated with Android and can enable near-field communications (NFC) for transactions.
“Normally Android provides a firewall that does not allow anything other than Google Wallet to manage the credit card operations of the secure NFC element,” he said. “By having the Google Wallet identity, our malware can bypass the firewall and talk to the hardware.”
From a security model perspective, the ability to validate identities is a well-understood process in the Web browser world. With any standard Web browser, secured sites have Secure Sockets Layer (SSL) certificates that can be validated via a certificate authority (CA). Every Web browser has mechanisms by which SSL certificate authenticity can be checked with the CA, including the use of the Online Certificate Status Protocol (OCSP). Google’s Android, however, does not follow the same model for security verification as the browser world has for the past decade.
Fake ID Flaw Puts Android Users at Risk
Forristal explained that in the Fake ID vulnerability, the attacker creates a certificate saying it is issued by Adobe, for example, and Android accepts it. The fake certificate is chained to the legitimate Adobe certificate, though the fake certificate is never in fact issued by Adobe.
“If you were to cryptographically verify that Adobe issued the certificate, the verification would fail,” he said. “But Android doesn’t do that verification, so the vulnerability is the fact that we can get an arbitrary third-party certificate shoved into our certificate chain and be accepted as valid.”
So why doesn’t Android simply follow the same model as Web browsers? According to Forristal, it’s all about developer convenience. Most Android apps are self-signed and don’t actually use a third-party CA, he said.
“If Google had the same certificate verification as browsers do, it might have solved this [Fake ID] issue, but it might have prevented the entire Android ecosystem from starting,” Forristal said. “If a developer had to go out and buy a security certificate before they could put their app in the Android marketplace, it would extremely impact the openness and the time-to-market concept of Android.”
That said, the Fake ID problem can be fixed in other ways. Forristal first reported the Fake ID flaw to Google back in April. That same month, Google produced a patch, and it is in the process of pushing out the fix to its handset partners.
However, just because Google has a patch doesn’t mean that all Android device manufacturers have made that patch available to users.
“Of the 40 or so devices we use in our lab environment, the only one we’ve witnessed patched at present is certain Motorola devices,” Forristal said. “It is relatively unknown to us what the current patch status is for those other 6,260-plus Android devices at this time—perhaps more of them are patched.”
For users, Bluebox has its Bluebox Scanner app, which was originally released in 2013 to help Android users determine if their devices were at risk from the Master Key vulnerability. The Bluebox Scanner app has now been updated to identify the potential risk for the Fake ID vulnerability.
There is likely one additional mitigating factor for the Fake ID vulnerability: Google’s own scanning of apps in the Google Play store.
“Google is known to scan apps, but to what extent and how they scan apps are details we don’t have,” Forristal said. “Certainly there are no guarantees that something can’t slip through the Google Play store.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.