Malicious App In Android Market

dumbnose writes to let us know that a fraudulent app that attempts to steal bank information has made it to the Android app store. From the alert: "NOTICE: Users of mobile devices with Android software may have noticed several applications available for download in the Android Marketplace. If you see any applications provided by the user Droid09, please do not download these applications. Android applications provided by Droid09 are fraudulent. Please remove any applications by Droid09 from your mobile device and contact your mobile provider to evaluate whether any other applications or information stored on your mobile device have been compromised." Multiple marketplaces are possible in the open Android ecosystem. Might we see the emergence of a marketplace distinguished by an iPhone-like app vetting process?

Comments

Use an Outbound Firewall

[slifox]

One great app I use is DroidWall, which is a simple GUI for iptables.
I set the default outbound policy to DROP, then specifically whitelist the apps that should reasonably have access to the internet.

Since Android apps have to specifically declare the privileges they require before installation (such as ability to read contact data, internet access, etc), then it's easy to make sure that all apps that read personal data are not whitelisted, unless they come from a reputable developer (e.g. Google-made apps). Any app that can read my contacts data, my calendar, my email, etc, is sure as hell not getting internet access for "usage statistics" or whatever other lame excuse they give.

I wish this functionality was built into the OS, rather than having to do it manually (for example, a way to disallow internet access during installation) -- but at least it's doable on Android. I don't think any other phone platforms give this level of permission separation or control. I'm not so sure that app review would really fix the overall problem; it might catch the obviously-malicious phishing apps like in this story, but I bet that the app auditors' opinion on what is a privacy violation differs greatly from my own.

I still wouldn't use my banking info on my phone regardless, since a phone is so easily losable, and locking/unlocking the data everytime with a secure passphrase would probably be too inconvenient. At very most, I would only allow read access to transactions from my phone (if banks offered this), thereby limiting the amount of useful information or control a would-be attacker could gain from compromising my phone.

Re:Use an Outbound Firewall

[Anonymous Coward]

Any app that can read my contacts data, my calendar, my email, etc, is sure as hell not getting internet access for "usage statistics" or whatever other lame excuse they give.

Usage statistics are the only reliable way to get real feedback about how actual users interact with the software (short of having a horde of QA testers that we can't afford). Some of the more useful things that my apps track (anonymized and with the terms stated clearly on install with an opt-out):

(1) Which settings are most often changed, and to what. This helps us put the most-changed settings near the top and set better defaults. If a setting is changed back and forth a lot, that usually tells that the UI needs widget to control that behavior.

(2) Which functions are used most or used most together. This helps organize the UI in accord with the most common usage patterns. Many times, we will see that users do the same clusters of things over and over and that lets us combine those into a single task in some fashion.

(3) What functions/options are almost never used, especially ones we had imagined would be useful. This is usually a sign that we have either totally dropped the ball on implementation or interface or that we don't understand the user's workflow.

I will admit that this is largely a matter of trust between the developer and the user -- I really can't blame users that opt-out or firewall us because they really don't have a reason to trust us. That said, such distrust does deprive us of very important data that we use to improve our products. I just want to express my deep appreciation for all the users that have let us have their usage statistics -- we really do read and act on them!

Re:Use an Outbound Firewall

[Miamicanes]

> Like any GSM/UMTS network in the world?

You're forgetting that GSM/UMTS phones won't do 3G on any network in America unless they happen to support 850/850 or 1700/2200 uplink/downlink. AFAIK, the US is the only country on earth that does 850/850 and 1700/2200 UMTS. I don't even think *Canada* uses those frequencies. For all intents and purposes, the only phones that support 850/850 UMTS are sold by AT&T Wireless, and the only phones that support 1700/2200 are sold by T-Mobile. So much for interoperability. A "global" phone that supports only 1900/2100 UMTS will give you blazingly-fast 19.2kbit/sec GPRS in America (or serve a more useful purpose as a paperweight in windy weather).

It's sad, but right now, Verizon is ironically the most interoperable carrier in America, just because you can theoretically reflash the Sprint twin of a Verizon phone with Verizon firmware and they'll let you use it if you can figure out how to do it on your own, without any help from them. It's a piss poor, sad excuse for interoperability, but just goes to show how dire the wireless situation *is* in the United States.

Re:No sandboxing?

[dumbnose]

Sandboxing wouldn't help here. The app looks like your bank app. So, it just collects the information from you.

Re:An iPhone-like process?

[mounthood]

An iPhone-like vetting process would be "we'll reject it if we don't like the look of it". How about "Linux-distro style vetting process"?

Multiple repositories solve part of the problem, but more then just vetting the repository as a whole we need to score/rank/blacklist/require individual applications and authors. What friends think of an application is much more important than the "average" score of everyone. IT departments need to add/update/remove applications for workers phones, but also let the end user manage applications. Ban lists need to be available in a form that lets the end user (or their tech. support) decide what to trust.

It's amazing that such a big industry has such crappy tools to manage applications. Making things "just work" for the end user does not need to mean a monopoly or tyrant controlling the (only) store.

Re:Check for the signed label!

[sznupi]

This is why we can't have nice things.

And I'm sure US cellphone carriers can't wait for more malicious apps.

Separate passcode locked to a verified device

[beakerMeep]

One of the things my bank does for their mobile banking application (which is contracted out to another company) is to give you a special code that is akin to a extra "mobile password." You get this code from the bank's website after putting in your mobile phone number. You then must enter it on your phone and "activate" that phone to access your account. At any time also, you can go into the website and "deactivate" the device. At no time do you ever enter your banking login details into your phone, only this special code which is tied to you phone number, mobile OS, and carrier (that you can deactivate at any time) is entered into your phone.

It's not perfect security, but it certainly puts up a few more decent hurdles against phishing.

Re:Check for the signed label!

[LostCluster]

And that's why certificates can be revoked, and apps can be pulled from the app store after the fact.

Why bother?

[MikeFM]

If you really want to steal people's info just throw up a quick Magento site pretending to sell things at unlikely prices and submit a Froogle feed. Soon you'll be getting lots of orders and you can collect credit card numbers, addresses, etc to your hearts content and then disappear and repeat the process next week. Lots of people will give you their info without thinking about it.

Re:Check for the signed label!

[BronsCon]

Do the Underhanded C Contest and Obfuscated C Contest ring any bells?

Even review of every line isn't enough. But it's better than what closed source can offer.

Re:Check for the signed label!

[SQLGuru]

The very same argument has been made as to why the XBox online experience is better than the PS3 or Wii. With MS, the control is in place. To participate, you have to accept the control (ask those banned due to hacked boxes). It's also why the PS network is getting some level of premium status to help curtail some of the problems related to that.

Apple's control is great in terms of keeping the store "clean", but the process they put in place didn't anticipate the number of submissions, overwhelming them. Resulting in slow acceptance times, bogus rejections, etc. Someone will need to figure out a happy medium in terms of control and flexibility.

Re:Check for the signed label!

[brit74]

Open source is another way to stop malware... not every user looks at the source, but enough curious ones will put out the warning should anything not be as its marked.

Out of curiosity, what's to stop this situation: I build a "custom" version of an opensource application that includes a trojan. Maybe I use the application's original name, or maybe I add a few features/artwork and call it something different? People are just grabbing the exe's, afterall, and not building their own copy from the source.

Re:Check for the signed label!

[LostCluster]

Suddenly your .exe doesn't match the MD5 hash of the real program. People will notice.

Is this itself a scam?

[ibsteve2u]

I note that searches of Secunia, SANS.org, and CERT don't return any mention of it, which is curious given that the...alert...began spreading on or about the 3rd of December, 2009 according to a date-sorted Google search (who is Jeremy Allexon?). Said search likewise fails to turn up any sources which I would call "authoritative".

Given the nature of corporate competition...

Re:Check for the signed label!

[mjwx]

And that's why certificates can be revoked, and apps can be pulled from the app store after the fact.

And applications can be pulled from the Android Market after the fact, which frankly is terrible security.

Apple's security model is still far inferior to Androids. Apple have a gateway only approach, Apples decides what does and does not run on Iphones remotely and forgo any local security, Android has a limited gateway and local security approach, Google can revoke malicious applications and make them go through some kind of testing before hand (probably what Google will end up doing, limited semi/completely automated testing to check for obvious problems) and then you have local security on the device. The idea is that no program is trusted. Now with Apple you have a single point of failure, if a self replicating virus/trojan gets past apple then its over unless apple uses the kill switch, if the kill switch works. With Android if a virus/trojan can replicate you still need each user to authorise install on each device.

You will also have more people watching android applications, Google are quite open to security being questioned where as it is tantamount to heresy to even suggest that Apple has insecurities (and I'm certain some fanboys are frothing at the mouth reading this and typing an incoherent rant). The false sense of security that surrounds Apple is far more dangerous then the open nature of Android or the Android marketplace.