On July 29th, security firm Bluebox made public a vulnerability in Android that has actually been around for quite some time. According to the company the bug, which they’ve dubbed the “Fake ID Vulnerability” has been lurking inside of Android since version 2.1 (back in January of 2010). While this problem doesn’t presently pose a threat to anyone, it has the potential to do some serious harm.
To appreciate what this vulnerability is, and how a hacker might make use of it to hurt you personally, you need to get understand how Google protects you from malicious apps in the first place. We’ll begin by looking to the past to see how this used to be done.
In the past, mobile operating systems were divided up into functionality categories that were either deemed “safe” or “unsafe”. Any part of the API that was safe could be used by any programmer, and apps that limited themselves to these parts of the API could be freely distributed. If a programmer wanted to use one of the “unsafe” parts of the API, then he or she needed to have their app APPROVED by someone before the app would be granted electronic approval to run on phones other than those the programmer tested them on.
Needless to say, this process was often complex and costly, plus the programmer was at the whim of the companies that handed out approval and could easily see months or work go out the window. And to make matters worse, there were also parts of the API that were deemed “off limits” to anyone who wasn’t a service provider.
While Apple uses a somewhat streamlined version of the above, the iPhone development process still more-or-less follows this pattern. When Google came along and introduced Android they made their operating system “open”, which meant that programmers did not need to get anyone’s approval to publish an app. However, that didn’t meant there were no protections in place, only that those protections took a different form.
Android apps still have to be “signed” to appear in the Play Store, but this signature is used solely to identify the entity that created the app. This approach ensures that someone else can’t take a published app, modify it, and then get unsuspecting users to believe that the changes were made by the original author. Android won’t allow a straight UPDATE unless the...
signature of the new app matches the signature of the already-installed app. However, if you were installing the malicious app for the first time, you wouldn’t necessarily know it was a fake.
It seems on the surface therefore that simply being able to fake an ID would only mean that you’d need to be careful when updating an app you already trust, and thus it isn’t a big deal. However, it’s not this part of the security that the new vulnerability puts at risk. Baked into Android is the assumption that apps carrying certain signatures have seriously unrestricted access to the operating system. An example cited by Bluebox is Adobe. Apps carrying the Adobe signature are allowed to run WEBVIEW plug-ins inside of any app on the phone. This was presumably done to support Adobe Flash.
There are other cases similar to this where simply having the correct credentials gives an app virtually unrestricted access to anything in the phone. If a malicious app were to fake these credentials it would be able to do pretty much anything it wanted with your data.
Bluebox has actually known about this bug since March, but they passed the information along to Google so that manufacturers had time to implement a fix. Now that a reasonable amount of time has passed, Bluebox felt that it was time to make this information public.
But how much of a problem is this vulnerability RIGHT NOW? Google has scanned all of the apps in the Play store, as well as a number of well-known apps that are not in Google Play, and it hasn’t found any uses of this exploit. That’s good news, but it doesn’t mean that a hacker won’t take advantage of it, especially now that it is widely publicized. Even if Google fixes the problem in the next release of Android, hackers know that older versions of the O/S will be around for years.
The best advice is simply to be cautious of what you install on your phone. Restrict your choices to apps in Google Play, because so long as Google scans apps in Play for this vulnerability, you should be safe from it by only installing apps from there. Even then, always check the permissions that app requests to ensure they match what you expect the app to do.
To see the full press release from Bluebox, follow this link: http://bluebox.com/technical/android-fake-id-vulnerability