I made a comment recently that was subsequently quoted in a recent ESET blog – Android “master key” leaves 900 million devices vulnerable, researchers claim – and it appears that comment may have confused one or two people. What I actually said was this: “Security based on application whitelisting relies on an accurate identification of
I made a comment recently that was subsequently quoted in a recent ESET blog – Android “master key” leaves 900 million devices vulnerable, researchers claim – and it appears that comment may have confused one or two people.
What I actually said was this:
“Security based on application whitelisting relies on an accurate identification of whitelisted (approved) applications using a cryptographic signature: a sort of electronic fingerprint that represents various identifying characteristics in a brief and hopefully unique form. For instance, this SHA1 hash represents a malicious program that ESET detects as Darkleech: 8f20fb5a1ce55a7ec8c50c0e8ed11bf775138223.”
So, just to clarify, Darkleech is a Linux program, a malicious Apache module, and Apache is a component of Linux-hosted web server software. Darkleech has nothing to do with the so-called Android Master Key vulnerability that Bluebox is talking about and can’t take advantage of that vulnerability because it’s specific to Android. (In any case, ESET detection is a bit more complex than checking a cryptographic signature, but I’ll come back to that.)
So why did I mention it? I thought it might be useful to demonstrate what form a hash might take in order to uniquely identify a malicious file, using a real cryptographic signature. I couldn’t very well use a hash value (SHA1 is just one form of hash) for a malicious file that exemplifies the kind of Android attack Bluebox envisages, since – as far as we know – there aren’t any such attacks yet, so I used one that I could easily lay hands on, one that our Canadian research team has written about recently.
So that’s a SHA1 hash: a string of characters that’s meant to uniquely identify a file. But Bluebox seem to have found a way of modifying the code without changing the file hash.
Which sounds a bit like having someone knocking the head off a statue and no-one noticing that it’s happened because its weight hasn’t changed. I can’t think of any circumstances under which this disfigurement wouldn’t reduce the absolute weight of a statue. (Dieters, don’t try this at home.) However, if you chose, for whatever unlikely reason, to monitor the integrity of a statue only by monitoring its weight, an attacker could conceal the decapitation by interfering the set of scales on which the statue happened to be sitting. I imagine that the Bluebox attack will turn out to be something like this: the code has been changed, and the cryptographic signature no longer matches, but some way has been found to prevent the Android verification system from noticing the discrepancy. If you like, it looks at the scales instead of the statue.
Specialist security software, however, has more than one way of checking that an object isn’t malicious. In fact, we learned decades ago that malware – rootkits for example – try to hide from anti-malware scanning by fooling the operating system so that it gives the wrong information to an investigator (human or programmatic). Decades? Yep. Brain, often assumed to be the earliest example of a PC virus, intercepts calls to view the boot sector of an infected diskette and displays the original boot sector, not the actual (infected) boot sector.
We were asked last week whether we can protect against the Android ‘master key’ attack. Well, when Bluebox tells us what the vulnerability is, we may be able to detect it generically, rather than waiting for specific malware to identify. I’d like to say that it may not be necessary by then, but as Righard pointed out in the earlier blog, fragmentation of the platform means that whatever patching Google introduces will probably never be applied to many Android devices. However, ESET’s range of detection techniques goes far beyond simple whitelisting, so not changing the cryptographic signature that Google uses doesn’t have anything to do with whether ESET detects it. Even anti-malware that takes the lazy route by making extensive use of hashes of known malicious programs as signatures won’t be thrown by this unless it happens to be using the same cryptographic signature as Google and believes the signature reported to it by the operating system. I can’t guarantee that any Android security program will detect any and all malware that attempts to use the vulnerability, but it’s incorrect to assume that security software will be fooled by the same breach that Bluebox claims compromises the operating system’s own security.
ESET Senior Research Fellow
Photograph: headless statues at the castle in Bratislava. I think the absence of heads is deliberate, not an oversight. Photo courtesy of Small Blue-Green World.