Remember that Android mobile "master key" vulnerability that was patched last month? It turns out there are other opportunities within the Google operating system to perform similar attacks against Android mobile apps, a Black Hat conference speaker said this week.
"Realistically, there's more than one," says Jeff Forristal, the CTO of Blue Box who discovered the initial master key about six months ago. "There are multiple master keys."
BACKGROUND:Alternative fixes released for Android 'master key' vulnerability BLACK HAT:Showing its quirky side
The threat is that, as with the original master key, attackers could alter legitimate apps without being detected, giving the apps code to carry out malicious activities. A separate Black Hat briefing demonstrated how to alter code in Angry Birds to turn an Android phone into a spy phone that could record calls, take photos with the phone's camera and send personal data to a command and control server.
Forristal detailed during his Black Hat briefing how he came across the vulnerability in the first place. He was playing with an application that included delivering GPS coordinates for the phone running the app. He thought it would be fun to have the app display, for example, Antarctica for a phone in the U.S.
He employed a standard Android assembler/disassembler tool to do the work, but found that while it gave phony GPS information, it didn't display the location on a Google map like the unaltered app did.
Use of Google Maps is licensed and tied to a digital signature, and he needed to figure out how to alter the app without the changes resulting in the signature being rejected. Components of the app are hashed and those hashes are used to verify that each one is as it should be. Altering the code results in a new hash that doesn't match with the original hash, resulting in the altered code being rejected.
This procedure goes on among many layers of the code, but different procedures for checking the hashes are used between different layers, he says. He found a way that allowed the modifications he made to the app to fall between the cracks. "The evil file is outside the verification process," he says.
He listed some other Android faults that have been fixed but that allowed similar tinkering with applications. "These are the public disclosures," Forristal says, and there may be others.
He says that obtaining Android apps only from Google Play offers some level of assurance that the apps have been properly vetted for authenticity. But it's also possible to obtain perfectly legitimate apps outside Google Play.
For example, Amazon's ebook apps aren't malicious, but downloading them requires users to OK downloading apps from what Android calls unknown sources. That's fine, Forristal says, but many users don't bother to go back after the downloads to again ban unknown sources.
The situation is similar for enterprise apps which would be classified as coming from unknown sources, he says.
The speed with which attackers jumped on the initial Android master key flaw was impressive, he says. It took 17 days between the details being released publicly to finding an exploit in the wild. That's pretty fast, but the attackers may have known the details earlier and been working on their exploit ahead of the public announcement.
It took only seven days between when details of the original exploit were revealed and when other, similar bugs were discovered in different places, he says.
An obstacle to clearing up these problems is that service providers who sell Android phones to customers must issue patches to the operating systems and how quickly that is done and whether it is done at all varies from carrier to carrier.
Tim Greene covers Microsoft and unified communications for Network World and writes the Mostly Microsoft blog. Reach him at firstname.lastname@example.org and follow him on Twitter@Tim_Greene. Read more about wide area network in Network World's Wide Area Network section.