Malware hits the Android Market [updated]

July 29, 2010

In the news right now are a set of Android wallpaper apps by Jackeey Wallpaper, that are alleged to steal user data and send it to a web site operated by someone in China. Many people are taking this as some sort of proof that Apple’s jailed developer approach is the only one that can work.

A lot of the people writing about the situation don’t seem to know anything about how Android security permissions actually work, and apparently think that users just downloaded and ran the app with no warning that their information might be stolen.

I went to one of the many sites that indexes Android apps, and located the Jackee Wallpapers apps. I picked the “Sexy Asian Women” app as a typical example, and pulled up its info page. Like most of the app indices, this one lists all the permissions the app requests on the info page. Since the page had been updated 20 days ago, I’m pretty confident this list represents the malware’s actual permissions. The list is:

android.permission.ACCESS_COARSE_LOCATION
android.permission.ACCESS_NETWORK_STATE
android.permission.INTERNET
android.permission.READ_PHONE_STATE
android.permission.SET_WALLPAPER
android.permission.WRITE_EXTERNAL_STORAGE

I then took a “Hello World” app, and set it to request the exact same permissions. I uploaded it to the web, and then triggered a download to an Android virtual machine running in my development environment. This allowed me to take a quick screen capture of exactly what was displayed to everyone who downloaded the malware app:

The problematic permission is the last one. It allows access to the phone’s IMEI, serial number, and SIM card information. That’s all the information necessary to clone your phone, and hence make phone calls on your account. That’s why it appears under the heading of “Phone calls”.

So the problem here is not a technical one, but a social engineering one: typical phone users probably don’t understand that if someone can read the complete identity of your phone, they can pretend to be your phone on the network and make phone calls. Thousands of people apparently went ahead and explicitly allowed the app to access information it had no business accessing.

So, does this spell doom for the open app development model? I don’t think so, because there are a number of possible solutions which do not require throwing all your developers in a software jail.

First off, Google could run their app store more like Apple’s. They could employ people to test and scrutinize apps, and only allow ones that meet whatever criteria they decide are appropriate. In fact, anyone could do this–there’s nothing stopping anyone from setting up a “Guaranteed Safe Family-Friendly Android Apps” store, if they think the users really want that.

A second approach requiring fewer warm bodies would involve flagging certain permissions as particularly risky, and subjecting just the applications requesting those permissions to additional scrutiny. Google could require, for example, that you justify why you need to be able to read the phone’s identity.

A more rigorous approach would be to follow BlackBerry’s example. If you wanted to write similar malware for BlackBerry, you would have to get RIM to digitally sign the code, because sensitive hardware information permissions are only available to RIM-signed code.

The ultimate problem here is that with freedom comes responsibility. Perhaps Steve Jobs is right, and most users can’t be trusted to decide for themselves what software they should be allowed to run. However, speaking personally, I demand the right to decide for myself. I accept the responsibility of reading warning messages, and I also accept the risk that if I do something stupid, I may suffer consequences.

In fact, for the sophisticated user, Android arguably has better security than the iPhone. On the iPhone, if Apple decides it’s appropriate for an app to be on the store, and that app accesses your contact details and phone serial number, you’ll probably never know–there’s no dialog on install. This isn’t a hypothetical risk either–the iPhone has already seen spyware approved and made available in the app store. When you hand the problem off to Apple, you hand off pretty much all control over access to your phone’s data, and trust them and anyone they choose to trust completely; so it’s not a cost-free tradeoff. The iPhone store has already seen data-stealing malware, too. Plus one iPhone app had the hidden undesirable functionality of tethering…

So I think that the best approach isn’t a free-for-all, and neither is it trusting a single vendor to control all access. Rather, app stores should enforce certain quality standards, and the operating systems should warn users of what apps are allowed to do.

Of course, the story is getting coverage because Lookout are using it to promote their security software. If you go to the Android Market and try to install Lookout, you’ll find that it demands access to:

Your personal information: read Browser’s history and bookmarks, read contact data, read owner data, read user defined dictionary, write Browser’s history and bookmarks, write calendar data, write contact data, write to user defined dictionary.

Your location: coarse (network-based) location, fine (GPS) location.

Your messages: edit SMS or MMS, read SMS or MMS, receive SMS.

Network communication: full Internet access, view network state.

Your accounts: manage the accounts list, discover known accounts.

Phone calls: read phone state and identity.

Hardware controls: change your audio settings, control vibrator.

System tools: delete all application cache data, make application always run, modify global system settings, prevent phone from sleeping, read system log files, write sync settings, automatically start at boot, disable keylock, read sync settings.

Apparently over 250,000 people have downloaded it, and doubtless many of them approved the above list of permissions. Lookout, indeed…

Filed under: Android | Comments (1)