Thanks to Rowland Yu of SophosLabs in Sydney for the technical work he put in behind the scenes of this article.
Researchers at SophosLabs have come across yet more samples of Android malware exploiting the so-called "Master Key" vulnerability.
These samples are different from the ones announced about two weeks ago by our comrades-in-arms over at Symantec.
So, although this vulnerability is not being widely used yet, there does seem to be more than just a passing interest from the cybercrooks in exploiting it.
As we discussed last month, the exploit doesn't actually crack any cryptographic keys, despite its name.
The "MasterKey" hole
The way it works is annoyingly simple.
Android apps are delivered in ZIP-format files with the extension APK (Android Package).
APK files have a specially named subdirctory that contains a digitally signed list of checksums for the rest of the archive; before installation, the files in the APK are extracted and compared with this list, called MANIFEST.MF.
If there's a mismatch, the APK has failed verification and is rejected.
But if you put two files with the same name into the APK, which is not normally a useful thing to do in a ZIP-format file, Android verifies the first, but installs and uses the second.
So it's like having a master key, because you can effectively "borrow" some third party's package, program files, data, product name, icons, and digital signature...
...yet install and run something that the third party has never even seen, let alone tested or approved for use.
A bad bug - and although it's fixed in the Android open source codebase, Google simply isn't saying anything about how long it's prepared to wait for its handset partners to get the fix out to Android users around the world.
The "Master Key" malware
The Labs guys found three files that piqued their interest.
Two of them contained multiple copies of a file named AndroidManifest.xml.
Every app is supposed to have one, but only one, of these: it declares a bunch of important information, such as the name of the app; the system libraries it uses; and the Android security permissions it requires when it runs.
Modifying this file without re-signing the app ought to cause an error, not least because it means that the app might no longer have the security limitations claimed by its creator.
Fortunately, the modifications in this case have invalidated the APK, apparently because the crooks didn't reconstitute their hacked versions of the original files correctly.
There doesn't seem to be a lot of doubt, however, that malware infection was what they intended, since the executable code in the offending files has a range of functions, including:
- Collecting data such as your installed applications, SMSes from your inbox, and the IMSI number (International Mobile Subscriber Identity) of your SIM card.
- Connecting to a server at apkshopping.com. (That domain is registered but doesn't currently lead anywhere.)
- Sending SMSes to a list of numbers in China.
The third malware sample did work.
It started life as an add-on pack called Fashion for a picture-based messaging app called Lexin.
But fitted out with imposter files for AndroidManifest.xml and classes.dex (the actual compiled Java code that runs the app), it turned into malware with the side-effects described above.
The original classes.dex and AndroidManifest.xml files make the cryptographic verifier see what it expects.
The cryptographic process during verification isn't cracked, it's merely deceived.
But the imposter files are what actually give the installed app its malevolent code and security permissions.
What to do?
You can greatly reduce the risk of infection by Android malware, of this or any sort, by:
- Taking apps only from the Google Play Store.
- Running anti-malware software on your device.
You might also want to try emailing your phone or tablet vendor and asking them, "Do you guys have a fix for the 'Master Key' hole, and if not, can you tell me when to expect it?"