Pau Oliva Fora, a security researcher for the firm Via Forensics, published a small, proof of concept module that exploits the flaw in the way Android verifies the authenticity of signed mobile applications. The flaw was first disclosed last week by Jeff Forristal, the Chief Technology Officer at Bluebox Security, ahead of a presentation at the Black Hat Briefings in August.
Oliva Fora posted his “quick and dirty” proof of concept on GitHub, a code sharing website, on Monday. The simple program leverages APKTool, a common, open source tool for reverse engineering Android applications – decompiling and then recompiling their contents. APKTool is widely used for analyzing and making modifications to closed binaries.
His script allows a user to select an Android application, use APKTool to decompile a legitimate Android application and then recompile it, creating an altered, “malicious” APK that will have the same, cryptographic signature as the original file, according to Zach Lanier (@quine) of Accuvant.
In an e-mail to The Security Ledger, Oliva Fora said his tool is modest in scope, and adds
junk new files with duplicate file names to the compiled binary. “The extra files that we add to the APK will not be checked for signature at install time, but will end up being installed on the device,” he said.
In the hands of a malicious actor, the vulnerability would allow the attacker to “impersonate the original signer of the APK by injecting malicious code into a valid updated APK,” he wrote. “If the attack is performed against a system application, it might be quite easy to create an APK that can execute code as the ‘system’ user (UID 1000 on Android), and escalate privileges to get root.”
“The bug is simple: Android will verify the signature against the 2nd one (original) which is properly signed, but will install the 1st one (the malicious one, which is not signed),” he wrote.
In an e-mail statement, Google said that a patch for Forristal’s vulnerability was provided to Google’s OEM (original equipment manufacturer) and carrier partners in March.
“Some OEMs (like Samsung) are already shipping the fix to their Android devices and Nexus devices will receive the fix in an upcoming software update,” the statement read. “We have not seen any evidence of exploitation in Google Play or other app stores via our security scanning tools. “
The delay in getting the patch to Android users underscores the fragmented ecosystem of OEMs, carriers and other device makers. Recent data suggest that only small percentage of Android users are on the most recent version of that mobile operating system, compared to over 90 percent of iOS users.
Bluebox (@BlueboxSec) notified Google of the issue in February, but Forristal wrote that updates to the mobile OS that repair the hole are dependent on firmware updates from the many handset makers that use Android and, then, on users to download and install those updates.
Forristal said the implications of the flaw are huge. A malicious application installed on a vulnerable Android device could access any data stored on the device, limited only by the application permissions. However, Lanier wonderS if reports about the threat posed by the security hole are overblown.
“I think it’s unlikely to get into (Google) Play,” he said. “There is Bouncer and there are other checks that are done, as well.” Still, he said third-party application stores – especially loosely regulated Android markets in the former Soviet republics and China could be fooled into hosting a malicious application that exploits the APK vulnerability he said.=
Oliva Fora agreed that the low-tech attack embedded in his tool would be trivial to spot. However, he said that in his tests, Google’s “Verify Apps” protection has not been effective in spotting the corrupted applications. “I have been able to install potentially malicious files that exploit this vulnerability without problems,” he wrote.
Oliva Fora does not appear to have consulted with Forristal in designing the proof of concept. Instead, he seems to have gotten the impetus to do it from discussions of the hole in IRC groups connected to Cyanogenmod, a customized, aftermarket firmware distribution for several Android devices, said Lanier.
In his e-mail, Oliva Fora said he learned about the specifics of the vulnerability reading information that was publicly available on Cyanogenmod’s bug CYAN-1602 and used that to implement a proof-of-concept attack. He expressed regret for spoiling the planned unveiling of the details at the Black Hat Briefings in August.
“I find it a bit sad that the details have been disclosed before the BH talk, but I’m sure Jeff will be able to impress the audience anyway, it’s a very nice bug that he found.”
(*) Updated to add comment from Pau Oliva Fora. PFR 7/8/2013 21:00.