Slashdot Mirror
Code Released To Exploit Android App Signature Vulnerability
chicksdaddy writes with news of a Proof-of-Concept exploit for the recent Android APK signature vulnerability. From the article: "Pau Oliva Fora, a security researcher for the firm Via Forensics, published a small, proof of concept module on GitHub 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. ... The simple program leverages APKTool, an open source tool for reverse engineering Android applications — decompiling and then recompiling their contents. His script allows a user to select and then 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. In an e-mail statement, Google said that a patch for Forristal's vulnerability was provided to Google's OEM and carrier partners in March, and that some (Samsung) have already shipping a patched version of Android to customers. However, that response hasn't been universal — a reflection of Android's fragmented install base."
This simplifies the generation of a hostile patch but, unless I'm mistaken, this still requires injecting the hostile patch into the Play Store via a trusted account or by convincing some sap to side load it.
Gee, 3rd party stores in China and Russia being completely lax on security matters? Go figure.
There's only one solution for a malicious APK.
We need a custom HOSTS file ...
The 'get' is very true, the 'be able to run' is less true.
If you look at some of the current 'budget' phones running 4.x, the specs are equivalent to previous phones which have ended with support for 2.2 or 2.3.
Also, many phones have quite functional CyanogenMod releases based on 4.x when the most recent official release is 2.2 (Motorola Defy for example) or 2.3. This reflects a problem of desire on the part of manufacturers. (Perhaps also a problem of a lack of legal obligation to provide at least security updates for a period of time, depending on your perspective).
Add your exploit code to an existing apk without removing the original items, creating a zip file with duplicate entries. The original files match the signature, the duplicates are executed after installing.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
If by "lurk in the shadows" you mean "write a little Python script for a Raspberry Pi tucked behind a chair at your local Starbucks", and by "with a complete set of compromised copies of everything in the Google PlayStore" you mean "have the script be able to inject malicious code dynamically into an any APK in a few milliseconds", and by "sniffing in hopes of intercepting someone's traffic" you mean "running a persistent ARP spoofing attack that routes all external traffic across the network through said RaPi 24/7", and by "quickly to insert a compromised copy of something midstream with a man-in-the-middle attack" you mean "implement basic automated intercepting proxy functionality such as is common in dozens of existing tools"... then yes.
I don't think you realize how easy this kind of thing would be. Computers are tiny, silent, wireless, innocuous, and cheap these days. They are more than capable of modifying a typical APK in flight without introducing a human-noteworthy amount of latency. They can gain a MitM position easily an hold it for as long as the network stays up.
Yeah, those who stick to their cellular networks for app downloading are better off (unless there's a femtocell on that network and the attacker has access to it...) but for a few hours of hacking and less than $50 per location counting WiFi adaptor, you could catch a lot of people using WiFi on their phones.
There's no place I could be, since I've found Serenity...
Google said that a patch for Forristal's vulnerability was provided to Google's OEM and carrier partners in March, and that some (Samsung) have already shipping a patched version of Android to customers. However, that response hasn't been universal — a reflection of Android's fragmented install base."
It's nice that Google's OEM and carrier parters are getting a patch but what's their mechanism for distributing the patch to the installed base of Donut, Eclair, Froyo, Gingerbread, Ice Cream Sandwich and Jelly Bean users in the field who would like their phones to not be infected with malware? And does it affect Kindles and other systems running on Android forks?
One method is Google Play Services. I've noticed that even on a 2.2 device, the app formerly known as Android Market installed a new application called "Google Settings" and an .apk file handler called "Verify and Install". Apparently app verification, introduced alongside Android 4.2, is some subset of the "bouncer" that Google uses to reject applications exhibiting the most common malicious behaviors, and Google could easily update it to reject .apk files that include two files with the same name.