Android Data Stealing App Downloaded By Millions 335
wisebabo writes "A wallpaper utility (that presents purloined copyrighted material) 'quietly collects personal information such as SIM card numbers, text messages, subscriber identification, and voicemail passwords. The data is then sent to www.imnet.us, a site that hails from Shenzen, China.'"
This is a job for Droidwall (Score:3, Informative)
This is a very good reason to run Droidwall. However, the bad news is that Android apps are going to a model where they ping one of Google's servers to check if they are licensed for that user. Of course, Droidwall can be updated to allow any apps to connect to that server farm's IP address range even if they are disallowed from anywhere else, but that may take some programming.
Droidwall also requires root access.
Not SMS history or voicemail passwords (Score:4, Informative)
According to this [http://phandroid.com/2010/07/29/another-app-stealing-data/ [phandroid.com]].
"Your voicemail's password is also not transmitted unless you included the password in your phone's voicemail number field."
WHAT app? (Score:5, Informative)
What was the NAME of this evil app? Neither TFS nor TFA bother to tell us that. We got the Dev Name which is almost as good, but geez.
Re:Unfortunately (Score:2, Informative)
Right. Because that's worked [independent.co.uk] so [thenextweb.com] well [cnn.com]. Keep in mind that these refer to apps that made it through the vetting process.
Re:I'm confused... (Score:4, Informative)
When I started learning android, one of the first programs I made was literally just text and a color background right... and it still asked for permission for calls! I was like hrm, maybe I got a tampered with version of the SDK? But that is why I'm just like *shrugs it off* when I see wall paper apps request phone call access. Now, I don't download wall paper apps lol but, I can see why those who did shrugged it off as well. This is probably something that google needs to explain better, or I need to learn better, or things need to be changed.
Re:WHAT app? (Score:2, Informative)
Update from TFA - No capture of text messages (Score:3, Informative)
Update from TFA:
Update: Lookout notes it does not capture browsing history and text messages: It collects your browsing history, text messages, your phone’s SIM card number, subscriber identification, and even your voicemail password, as long as it is programmed automatically into your phone.
Looks like it doesn't collect browsing history and text messages after all.
Re:I'm not (Score:1, Informative)
I'm not convinced that such an app would necessarily be caught by Apple's model. Apple doesn't even really review the source code; there was a tethering app disguised as a flashlight app that made it to the app store and stayed there until the media brought attention to it.
Android needs a sandbox. (Score:5, Informative)
Although Android apps do run in a security "sandbox" whereby they can't access the user space of other apps (see http://developer.android.com/guide/topics/security/security.html [android.com] for more information), they can and do access the general configuration information of the phone such as personal data, phone calls, and SIM information, and some apps obviously need to use the phone's dialup or networking capabilities.
At install time, the user is shown a list of resources the app will access, but since most apps need at least some resources on the device to be useful, we are all in the habit of just clicking past this screen and installing, and then hoping the app is not malevolent in some way.
I think there needs to be some sort of sandbox where apps can reside prior to full release into the wild. Probably, most users won't understand how to use such a feature, but knowledgeable users would make use of it, and ultimately it would help promulgate security concepts into the general consciousness. Power users who write reviews and prominent blog pieces on Android will be able to help guide the masses to safer use of apps.
Re:Developers Bitch (Score:2, Informative)
Yet this happened to Apple (according to Steve Jobs interview with Walt Mossberg at All Things D) - there was an app that shipped that was reporting prototype OS versions back to a marketing company - and it was an approved application.
Re:News flash! (Score:3, Informative)
None of those apps stole data from people's phones. Instead, they artificially voted one another up to generate sales, and users' iTunes accounts were hacked. That's obviously still a grievous security failure, but it's server-side, and has nothing to do with the app store's approval process.
Re:WHAT app? (Score:5, Informative)
http://www.androidzoom.com/android_developer/jackeeywallpaper_bofz.html [androidzoom.com]
Re:Middle Ground (Score:3, Informative)
The apps (or rather, the Android Market) told you at install-time that they wanted access to your Google accounts. Anyone who didn't back out on seeing that... well, I wouldn't say "deserves what they get", but I will say "was adequately forewarned".
Re:Developers Bitch (Score:5, Informative)
Apple is doing an equally bad job of protecting its ecosystem.
There have been several customer-data-grabbing iPhone apps, and these have only been yanked after members of the public alerted Apple to them.
Pinchmedia: http://i-phone-home.blogspot.com/2009/07/pinchmedia-anatomy-of-spyware-vendor.html [blogspot.com]
Storm8: http://www.sfgate.com/cgi-bin/blogs/ybenjamin/detail??blogid=150&entry_id=51077 [sfgate.com]
MogoRoad: http://www.theregister.co.uk/2009/09/30/iphone_security/ [theregister.co.uk]
Smuggling tethering past the censors: http://top10.com/mobilephones/news/2010/07/app_smuggles_tethering_onto_iphone/ [top10.com]
Apple don't look at the source code of apps, they just test the binary and scan it for badness.
Provided the binary encrypts its strings, and does nothing dodgy during the short testing window (less than two weeks), Apple approve it.
Apple's custodianship doesn't protect you from determined data thieves, only the incompetent ones.
Android market, while just as bad as Apple, at least gives you the opportunity to decide if you want an app based on what permissions it demands. If it demands too much, you reject it. Once you give it the "OK", it can't turn around and demand more. I'd prefer that Apple added that (telling you what permissions the code has, not letting it have more), even if they keep their approval process.
Re:I'm confused... (Score:5, Informative)
Your manifest file is wrong. You request a list of permissions that your app is then allowed to use, but requesting them does not mean you used it. You probably have PROCESS_OUTGOING_CALLS or CALL_PHONE listed unnecessarily.
Re:I'm confused... (Score:5, Informative)
honestly, i think that you did something wrong with your test app. there are tons of highly intricate apps that do not request permission to make calls. now, if your app wanted to go to the background when a call came and relaunch when the call is over that's something different. however, that permission is "read phone state" which does not sound the same at all.
Yes, "read phone state" sounds totally different than "make phone calls" or whatever the exact verbage is... /sarcasm
Cellphones went mainstream about 10 years ago, and even smartphones like those based on Android are very common. This means they are in the market where you need it to be so simple that someone with a barely functioning grasp of English could figure it out.
To software engineers, there might be a difference between "read phone state" and "make phone calls" but to a layperson there really isn't. You really need to look at it with the "would it work in a car" mentality: is it simple enough to be put into a car and be figured out by anyone with a mild amount of training in "not crashing"? Hint: "turn key to start" is good, an arrow indicating which way to turn it is better, and "please select from the available options: Activate engine controls. Activate engine starter motor. Activate seat belt latch." is NOT going to go over well.
All this nonsense about "well the user was advised that SIM activity could be perturbed by the inclusion of application permission" as an excuse for a poorly implemented security platform needs to be thrown out the window unless you want Android to turn into Windows Mobile 6 in a matter of months while security and usability problems fly out of the woodwork and people flock to a different platform without such headaches.
Re:WHAT app? (Score:2, Informative)
Re:Thats it! (Score:2, Informative)
Re:I'm confused... (Score:0, Informative)
one of the first programs I made was literally just text and a color background right... and it still asked for permission for calls!
So.. you told it to ask for permission to make calls, then are surprised when it says it needs permission to make calls?
You wrote the program, you're responsible for the requests. The SDK doesn't give it anything you don't ask for.
You don't understand development, and it shows. This is clearly a "Layer 8" problem.
Re:News flash! (Score:3, Informative)
Re:I'm confused... (Score:3, Informative)
See the second comment here: stack overflow [stackoverflow.com]
The problem is that it comes up for any dev targeting 1.5 and earlier, so it comes up pretty often. Google probably could have handled the permissions differently but I cant think of any better ways off the top of my head at the moment.
Re:I'm confused... (Score:2, Informative)