It finally happened. Apps hosted on Google's Android App Store have been found to contain rootkit malware. At least 21 apps have been removed by Google but not before some 200,000 users had a chance to download the malicious smartphone software.
The attackers downloaded perfectly valid Android apps off the marketplace, injected the rootkit, then re-uploaded the malicious apps under a new app name. Example: One of the removed apps called Super Guitar Solo used to be a legitimate app called Guitar Solo Lite. The attackers simply modified the Guitar Solo Lite software and uploaded under a new name.
Is it really that easy? Android users and enterprise security professionals across the globe hope not.
The guys over at Android Police provide a complete list of the modified apps but the good news is that Google has already used a little known feature of Android to remotely remove these apps from all Android smartphones that have connections to the Internet. Unfortunately any additional software that's already been downloaded by the rootkit (if any) is there to stay. The vulnerability exploited by the rootkit has been patched in Android v2.3 (Gingerbread) but the problem is that few phone providers have upgraded their users to 2.3. As Wired points out, many phones will *never* be upgraded to 2.3 due to hardware requirements that aren't up to snuff. From a security perspective this is one of Apple's greatest advantages over Android. Apple's iOS updates are universal and applied to almost all phones at the time of release. Google has almost no control over how its vendors handle smartphone updates.
Another advantage Apple has is in its attitude toward which apps are allowed to be uploaded to the App Store. While some people complain that it's too difficult to get app approved by Apple, this incident proves that a strict App Store certification policy can prove valuable in long run. Given Google's lackadaisical attitude toward which apps are allowed to be uploaded to the Android App Store, it's no surprise this problem has come up. I'm just surprised it didn't happen sooner. Or perhaps it did and we just don't know? Don't get me wrong, I'm a fan of the Android. I use a Droid X. But unless Google tightens up on the app upload and certification process we should expect more of this in the future now that the world knows that this approach is a viable mechanism for delivering malware to an end-user's smartphone.
Impact on the Enterprise
There is a lot of discussion in the enterprise security community of late around IT Consumerization. The idea is that smartphones and other consumer devices such as iPads are turning up inside the enterprise behind the firewalls, proxy servers, and other perimiter-based defenses. Now that we've seen a workable approach to rooting one of these consumer devices, the thought of a rootkit running inside the enterprise is suddenly very real. Check out this RSA Conference keynote from Cisco's Tom Gillis regarding IT Consumerization. Tom talks about how Cisco's allows their user to select any phone they wish and positive impact this policy has had on their enterprise.
User Education and Internal Monitoring are Key
1. Monitor the internal network where consumer devices live. Now that rooted smartphones may be present on our internal network we must find ways to monitor for malicious internal activity without relying on the traditional perimeter defenses. Flow-based monitoring techniques such as those discussed on this blog are one mechanism. Another includes building internal trust-zones, segregating untrusted internal users from critical assets.
2. Educate users. Here's a few tips you can give users to help them avoid installing rogue apps:
Here are some potentially dangerous permissions you should watch for when an app is being installed...
"Your personal information: read contact data, write contact data"
Few apps really need to read/write information from your contact list. Make sure the app states a specific feature that uses this permission.
"Your personal information: read calendar data, write calendar data"
Consider what reason an app would have for reading/writing your calendar information.
"Storage: modify/delete SD card contents"
This permission allows an app to delete, read, write and otherwise own anything you have saved on your phone's SD card including videos, pictures, and your companies' internal documents.
"Network communication: full Internet access"
For malware to be effective it needs to communicate with the Internet. Many apps need access to the Internet. Games need it to post high scores, social media apps need Internet to upload and download status updates. But consider a keyboard replacement such as iPhone Keyboard Emulator. Giving an app like this access to the Internet is just asking for your keystrokes to be logged and uploaded to the Internet. Internet access in a keyboard replacement should be avoided.
"System tools: automatically start at boot"
This isn't so much a security concern as a drain on the phone's resources. As many seasoned Android users know, a surprisingly large number of apps will try to run constantly. Does a calculator really need to start at boot? How about a game? Consider the app's function and weather or not it should start up and consume memory and resources every time your phone starts.
"Phone: read phone state and identity"
This permission allows the app to read identity information such as IMEI and the phone's number. This permission combined with "full Internet access" can result in your personal information being sent back to the developer or (worse) malware developer.
An excellent example of a suspicious app that asks for all the above permissions is Binary Calculator by author "John Anderson". This app showed up on the Android Marketplace today (March 8th), has zero reviews and less than 50 downloads. The app's feature description is poorly written and just screams of potential malware. Why would a binary calculator app need to modify/delete SD card contents? Why would this app need to read/write contact data? This app asks for far more permissions that it needs and should be avoided.