14679792
story
Comments: 335 + - Mobile: Android Data Stealing App Downloaded By Millions on Thursday July 29, @12:04PM
background: url(//a.fsdn.com/sd/topics/topiccellphone.gif); width:75px; height:74px;
cellphones
background: url(//a.fsdn.com/sd/topics/topicsecurity.gif); width:59px; height:78px;
security
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.'"
Related Stories
I like work; it fascinates me; I can sit and look at it for hours.
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
Thats it! (Score:4, Funny)
Re:Thats it! (Score:5, Funny)
Parent
Re:Thats it! (Score:5, Funny)
Parent
Re: (Score:3, Funny)
and run it on hardware you designed and manufactured yourself
Re: (Score:3, Insightful)
and write your own compiler.
Your compiler can't compile itself!
Personally I prefer to tap the bits into the hard drive platter with a magnetized sewing needle, that way I know it's safe... oh wait... what about the HDD's firmware?
Re: (Score:3, Interesting)
There's absolutely no reason that this should be the case. I can't speak for Windows Mobile, but the Symbian kernel has a capability model that makes it relatively easy to protect against this kind of thing. Applications, by default, can only read a few system locations (shared libraries and so forth) and can only write into their own directory. Each shared library and each application has a set of capability bits. A shared library can only be loaded by processes that have all of the capability bits tha
Re:Thats it! (Score:5, Funny)
Parent
I'm confused... (Score:5, Insightful)
A wallpaper APP? Why would you need an app? It can't just display a jpg as wallpaper?
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.
Parent
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.
Parent
Re: (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: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.
Parent
Re: (Score:3, Insightful)
This is what Apple figured out : KISS, keep it simple and stupid. The user (even the ones that understand it) shouldn't be bothered with this shit, if you're going to sell apps through a store you might as well do quality control at that point by a third party. Of course that approach comes with its own set of well publicized drawbacks and no approach has a 100% success rate.
Re:I'm confused... (Score:4, Insightful)
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
Never mind that, why would you need a wallpaper app that requests permission to make phone calls?
Really, there's no helping some people.
Re: (Score:3, Interesting)
Android allows you to do more, but at the cost of a little extra complexity. I think an average user can handle it, I know a lot of people with average intelligence that have no problem with it. It's the users that aren't so smart that may have a hard time with it. Those users may want to consider an iPhone.
It's not about smartness but intuitiveness. Apple doesn't want the user to have to learn a new OS (the different types of permissions, etc.) to be able to use his/her phone. The user should just be able to pick it up and do a task with as little interference as possible. We used to call this KISS and it's actually a lot harder to do correctly than to just offer up a bunch of options and configurations to the user. I picked up an android phone in a store the other day and my first thought was how busy the us
Re:I'm confused... (Score:4, Interesting)
Wallpapers aren't just static images.
The wallpaper I have here, changes colour depending on the time of day.
You can even show a view adjusted for the weather where you are.
Parent
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.
Re: (Score:3, Insightful)
Re:This is a job for Droidwall (Score:5, Insightful)
There is the problem: People like you, me, and almost all Slashdot readers would click "no" if a generic fart app requires a slew of security privs (power, Net, access to SMS, access to contacts, ability to kill other apps, etc.), or even worse, prompted for root privs via su.
However, the dancing bunny problem strikes here. Joe Sixpack will click "Install" to install a cool app, only to find all his contacts being spammed with "I need $900 ransom" notices, a sky high SMS bill because the app grabs a list of phone numbers and starts sending out text messages with ads on it, maybe even drained bank accounts if he left his banking info and passwords in the Web browser.
I think Google made one mistake with Android, and that was assuming all users would be clued Linux types who know basic UNIX sanitation. I worry though, if there are more bad apples in the bunch that Android would be start being known as a hive for malware just because there is nothing stopping Joe Sixpack from installing a "pr0n viewer app" that reams his phone.
I like the walled garden idea, with a way to hop out, that is foreboding to a nontechnical person, but for someone with half a clue, wouldn't pose a problem. For example, the "oem unlock" command with the N1 phones and the warning staying to say buh-bye to the phone's warranty if the user wants to continue. Something to make Joe Sixpack not want to do it and actually pass on watching the dancing bunnies.
Parent
Re:This is a job for Droidwall (Score:5, Insightful)
You mean they'd have to wait for approval by the App Store? An interesting proposal!
Parent
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:WHAT app? (Score:5, Informative)
http://www.androidzoom.com/android_developer/jackeeywallpaper_bofz.html [androidzoom.com]
Parent
Re: (Score:3, Insightful)
No, you don't need the name in order to avoid it, but it might be useful, I dunno, to see if one already HAS it.
Just sayin'.
Re: (Score:3, Funny)
Instead, I have to say 'the droid is known to have data stealing apps and no I can't tell you which ones suck ass, just get yourself an iPhone so apple can protect you, its far easier on all of us'
What the fuck is wrong with you?
You imply that you're tech-savvy and then in the same post assume Apple will protect them? Sneaking code by Apple is completely impossible! Oh wait... [wired.com]
Face off? (Score:4, Funny)
Re:Face off? (Score:4, Funny)
Parent
Wallpaper app, lol (Score:2)
Reminds me of advertisements in magazines where you text a code to a phone number, and they send you a wallpaper and sign you up for a subscription. Nope, they won't be sending you any text spam. Not a single piece. ::wink wink nudge nudge shank shank::
Unfortunately (Score:4, Insightful)
Re:Unfortunately (Score:5, Insightful)
Excuse me? I somehow doubt you've ever submitted an addon to Mozilla before. I have, and a real person does indeed check your code.
From the Editor's Guide [mozilla.org]:
Every line of add-on code must be reviewed. The code validator can't detect all possible security or code quality issues, so we must always be in the lookout for bad code.
Parent
Re:Unfortunately (Score:5, Insightful)
Amazing what a gets a +5 Informative these days. Adding links?
The first example was due to a developer "hacking" accounts (i.e., guessing passwords).
The second example is the same story as the first, from a different source.
The final example is the only one that holds any water. And that allowing crap apps through, not malicious ones.
Parent
Re: (Score:3, Insightful)
I've come nowhere near Mr. Job's ass. I am no Apple fan by a long shot (I've never purchased an Apple product in my life) and have no interest in going where the (reality distorted) sun does not shine.
Your evidence is that malicious apps can exist in an environment where vetting takes place. You have not demonstrated that vetting has no effect on the number of malicious apps a person is exposed to. Nor have you demonstrated that the vetting was effective in your example. You might have demonstrated that
Implied Racism! (Score:5, Funny)
I am surprised, shocked, and dismayed to see a fine journalistic source such as Slashdot stoop to yellow journalism, as it were. There is absolutely nothing suspicious about the origin of the website being being in Shenzen, China and the summary's implication of this is absolutely untoward. I expect a full apology posted immediately, then duped again tomorrow.
People will click through anything (Score:5, Insightful)
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.
I was going to troll, but... (Score:4, Insightful)
When I read TFA, I saw the part where 47% of Droid apps use third party coding, and 23% of Apple apps also use it. Then I realized, there's no safe place to hide. I like my walled garden, but even that has leaks.
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.
There is a lot of FUD in these stories (Score:3, Interesting)
Check out the manifest permissions [macrumors.com] on the apps in question. It is the last item that is the problem.
!Storage
modify Delete
!Your location
coarse (network-based) location
!Network communication
full Internet access
!Phone calls
read phone state and identity
The permission only allow the app to read the IMEI number of your phone (your hardware's unique identifying number), your phone number, and your currently programmed voice-mail number. If you hard coded your voice-mail password as part of your voice-mail number, then they have that too.
They shouldn't be stealing this info, and Google should separate "read phone state" from "read identity", but the stories on this app stating that your SMS's, contacts and grandmother's girdle being stolen and sent to China just plain wrong.
Re: (Score:3, Insightful)
As we've seen from the "colored flashlight app that's really a tethering app," I don't know why people are still putting their trust in Apple's "approval" process as far as safety is concerned. They obviously don't check the code behind an app -- today it's a tethering app, tomorrow it's one that's sending your data to China (if it doesn't already exist, and I'd be surprised if it didn't).
Re: (Score:3, Interesting)
The tethering app wasn't discovered because it was extremely difficult to trigger - it required very specific network settings, a multi-step setup process, and tapping different colors in a specific pattern just to enable the tether. Very different from discovering an app is sending your data off wholesale.
The hidden tethering app is only going to be discovered via thorough code decompilation and analysis. Sending chunks of data to a random server for no appreciable purpose can be found easily via tcpdump.
Re: (Score:3, Insightful)
The approval process didn't do any good when data was stolen from Apple users a month or two ago. A bunch of people were charged for apps they never bought, and several apps were removed from the app store, but a full explanation from Apple was never offered.
So I guess you think that it's totally irrelevant that a) the stolen data had nothing to do with the app approval process, and b) the data was not stolen by the approved apps?
Yeah, let's blame the approval process for something to which it is completely unrelated. *eye roll*
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.
Parent
Re:Developers Bitch (Score:4, Insightful)
Such reporting wasn't disallowed until very recently. There was a very good reason for it as well - developers then got that data back so they could tell how many people were still on old OS versions, what the uptake was on a new OS, and could plan their features and releases accordingly.
The only reason Apple got upset is it revealed prototype OS versions in their lab as a side effect.
Parent
Re: (Score:3, Informative)
Re: (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: (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: (Score:3, Insightful)
What malicious apps have gotten through Apple's approval process? I'm open to any links you may have. Don't bother linking to the guy who hacked into iTunes accounts and used them to buy his otherwise legitimate app -- the app itself was not malicious, so there's no reason to blame the approval process for the incident.
You say "tethering apps" as if that's a bad thing. The app didn't steal any data, or use any APIs that could reveal the user's personal data. Apple checks all submissions against their li
Re: (Score:3, Insightful)
from user -kyz:
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-an [blogspot.com]