Forgot your password?
typodupeerror
Cellphones Security

Android Data Stealing App Downloaded By Millions 335

Posted by CmdrTaco
from the nobody-is-safe dept.
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 discussion has been archived. No new comments can be posted.

Android Data Stealing App Downloaded By Millions

Comments Filter:
  • Thats it! (Score:4, Funny)

    by socz (1057222) <socrates@gh e t t o b s d.org> on Thursday July 29, 2010 @11:06AM (#33070346) Homepage Journal
    I'm going back to winmo where it's "Safe!"
  • I'm confused... (Score:5, Insightful)

    by mcgrew (92797) * on Thursday July 29, 2010 @11:07AM (#33070376) Homepage Journal

    A wallpaper APP? Why would you need an app? It can't just display a jpg as wallpaper?

    • by jsnipy (913480)
      it can
    • Re:I'm confused... (Score:4, Informative)

      by socz (1057222) <socrates@gh e t t o b s d.org> on Thursday July 29, 2010 @11:11AM (#33070464) Homepage Journal
      This is what confuses me:

      The wallpaper app asks for permission to access your “phone calls,” but that isn’t necessarily a clear warning.

      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.

      • 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.
        • Re:I'm confused... (Score:5, Informative)

          by jeffmeden (135043) on Thursday July 29, 2010 @11:49AM (#33071152) Homepage Journal

          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: (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.

      • This is probably something that google needs to explain better, or I need to learn better, or things need to be changed.

        I think Option 2. Blackberry does something similar - an app can't ever do anything you don't explicitly give permissions for. When in doubt, *always* choose "Deny"; and don't check "don't ask again" since if it turns out that the app legitimately needed the permission, it will make it easier to correct later.

        • Re:I'm confused... (Score:4, Insightful)

          by socz (1057222) <socrates@gh e t t o b s d.org> on Thursday July 29, 2010 @12:04PM (#33071506) Homepage Journal
          Well, what was interesting *to me* was that when I sent the program to the emulator, i left it blank! So I hadn't even made any changes to the default and it was asking for permission. In my mind, if it does nothing, why does it need access?
      • Re:I'm confused... (Score:5, Informative)

        by brainboyz (114458) on Thursday July 29, 2010 @11:46AM (#33071072) Homepage

        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.

        • by socz (1057222)
          Yeah that's what I figured. It's the default though, but like I said in another post, it's odd to me that something that does nothing is forced to request access to anything.
          • Re: (Score:3, Informative)

            by beakerMeep (716990)
            IIRC this has to do with the API change from 1.5 and earlier to 1.6 and later. Because that permission never existed in 1.6, any app targeting that platform will show as requesting the permission on 2.0+

            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: (Score:3, Insightful)

      by Vintermann (400722)

      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:I'm confused... (Score:4, Interesting)

      by arth1 (260657) on Thursday July 29, 2010 @12:23PM (#33071932) Homepage Journal

      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.

  • by mlts (1038732) * on Thursday July 29, 2010 @11:07AM (#33070378)

    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)

      by jsnipy (913480)
      this is a job for common sense. Whenever you install an app it shows you what it is requesting accessing to. If you see a 'wallpaper of the day' app wants access every aspect of your phone, you might reconsider installing it.
      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Common sense is the worst possible defense for the average user. If you want Android phones to have a tiny amount of market share among technically skilled users, that's fine. If you want a large number of Android phones available to, used by and recommended by the average user then showing such warnings is near completely useless.

        Dancing bunnies, man. Dancing bunnies.

      • by mlts (1038732) * on Thursday July 29, 2010 @11:55AM (#33071266)

        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.

  • by mdm-adph (1030332) <mdmadphNO@SPAMgmail.com> on Thursday July 29, 2010 @11:07AM (#33070380) Homepage

    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)

    by geminidomino (614729) on Thursday July 29, 2010 @11:08AM (#33070382) Journal

    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.

  • Face off? (Score:4, Funny)

    by notaspunkymonkey (984275) on Thursday July 29, 2010 @11:08AM (#33070388)
    God help anybody who used facebook and this app... there's every chance they will get home tonight and find an imposter in bed with their wife.
  • 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)

    by wraithguard01 (1159479) on Thursday July 29, 2010 @11:08AM (#33070394) Homepage
    This is one good reason to have a unified app service, where all the apps are first vetted before they are released. I think mozilla's addon collection is a good model to follow.
    • Re: (Score:2, Informative)

      by Pojut (1027544)

      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.

      • Right. Because that's worked so well. Keep in mind that these refer to apps that made it through the vetting process.

        Knees jerking much? The parent mentioned Mozilla's add-ons, not Apple's App Store.

        Also, you should note that the stories you're linking to are about the hacking of iTMS accounts for the abuse of a community rating system, rather than rogue spyware apps stealing personal data.

        I personally don't know whether Apple's approval process or Mozilla's add-on review process has a better or worse reco

      • Re:Unfortunately (Score:5, Insightful)

        by diamondsw (685967) on Thursday July 29, 2010 @12:30PM (#33072066)

        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.

    • Although the Geek In me hates the Apple iStore Model. However its strict app approval process really does help remove most of the bad stuff for the phone...

      • by jedidiah (1196)

        > Although the Geek In me hates the Apple iStore Model. However its strict app approval process really does help remove most of the bad stuff for the phone...

        Ok then...

        Where is the non-curated version of this problem in Windows? In MacOS? In Linux? In FreeBSD?

        Trojans are a considerably different problem from the autoexecution of random binaries and files that are supposed to be "just data".

        Some people are trying to conflate one problem with another in order to excuse Apple's fascist policies.

    • by dfranks (180507)
      Probably makes more sense to have a logo program and the ability to filter for "logo/approved" apps in the Android store. Turning on the filter by default and explicitly prompting users to turn it off the first time (with a decent warning page with guideline for what permissions apps should be asking for) would protect/inform the masses. That way Google could approve apps (and charge a nominal fee), but users with a clue can turn off the approved apps filter and avoid the Apple appstore issues.
  • by darkmeridian (119044) <william@chuang.gmail@com> on Thursday July 29, 2010 @11:11AM (#33070440) Homepage

    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.

  • by Coopjust (872796) on Thursday July 29, 2010 @11:13AM (#33070492)
    Even if they're told exactly what the app will have access to [wordpress.com], people will click through anything.
    • by Nerdfest (867930)
      Sadly there are reasons a wallpaper application would actually require full internet access, such as loading new pictures, etc. The fact it's a wallpaper application is not really that relevant, it could have been anything. I'm not sure of the depth of review at Apple, but I'm fairly sure the same thing could be slipped through without too much trouble. Poorly behaved applications are going to appear from time to time on any platform.
      • Sadly there are reasons a wallpaper application would actually require full internet access, such as loading new pictures, etc. The fact it's a wallpaper application is not really that relevant, it could have been anything. I'm not sure of the depth of review at Apple, but I'm fairly sure the same thing could be slipped through without too much trouble. Poorly behaved applications are going to appear from time to time on any platform.

        Internet? Sure. Phone, google account, location, and contact data? C'mon. Why would anyone grant these permissions?

      • by duranaki (776224)
        It wasn't the internet access that was suspicious, it was the access to your google accounts and your personal information. The app is relevant because it at least lets you identify absurd permission requirements. I've avoided installing some things because there is a clear mismatch between what it says it does and what it asks permission to do. But I do agree it's easy to make malicious apps that can justify their permission requests. If a wallpaper app claimed to make wallpapers using your contacts ic
  • by miknix (1047580) on Thursday July 29, 2010 @11:13AM (#33070502) Homepage

    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.

    • From the actual article linked by the OP:

      Specifically, the app does collect data from your phone, but only the device's phone number, subscriber identifier, and voicemail number fields are retrieved.

      I understand that this is newsworthy, but the Summary is blatantly wrong when it was posted, yet alone with future information...

      Besides, the app requested this info from when it was installed. If you just clicked "ok" when it asked for permission to access your personal data and the internet, then it is n

  • by Xaedalus (1192463) <Xaedalys AT yahoo DOT com> on Thursday July 29, 2010 @11:16AM (#33070562)

    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.

  • by yog (19073) * on Thursday July 29, 2010 @11:17AM (#33070574) Homepage Journal
    This is sort of like the early days of MS-DOS, back when everyone trusted everything they downloaded.

    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.
    • You mean like the much aligned method used in iOS.

      The end result is users and developers complaining they are walled in.

      • should have been maligned...

        And no I'm not saying it's bad, I agree that's how it should be, but the stupid users clamor for things they don't understand.

    • Its actually very similar to Windows now. Every single infected machine that ends up on my desk was because of some wallpaper/cursor pack/toolbar app that ran amuck because it was actually malware.

      Users really need to get into the habit of not downloading frivolous apps. If you want a cool wallpaper - download the picture and use the included gallery to crop the picture the way you want it.

    • 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.

      That's a bad habit to be in - why would you get into it? Deny first - go back and approve only after you see what doesn't work.

      This isn't an Android issue, it's common sense for any platform.

    • by AndrewNeo (979708)

      See, there's the thing. They -can't- access this information unless you give them permission. Trying to read it without throws an exception. And it's been said plenty of times before, this app, like all others, had to ASK for permission at install time, and the users hit Install nonetheless.

  • It's too bad that malicious people have to ruin an open-source forum like the Android with crap like this. I can see why Apple scrutinizes over the application approval process because I'm sure this is one concern on top of just being plain difficult about the whole matter.

    I guess don't have a criminal mindset and have put my tomfoolery hat away, it's bad enough having hack and malicious threats on the computer level, now my phone? I miss the days of my 2x10 backlit serial display analog cell phone that d

  • The platforms may vary but at the end of the day, this is just yet another stupid article about stupid people giving away their private data because they did something stupid. Since we, or at least anyone in IT, engineer and support alike already know that stupid people do stupid things why are these articles considered "news worthy" here? Is it meant to inspire us to come up with our own interesting ways to dupe stupid people? Surely we get enough reminders in our day to day that we don't need them for
  • Looking at one of these apps ("Dark World Wallpapers") the app asks for the following permissions:

    - Storage - modify/delete SD card contents
    - Your location - coarse (network-based) location
    - Network Communication - full Internet access
    - Phone calls - read phone state and identity

    It's nice android warns what permissions an app needs, but some of them (especially the "Phone calls" section) could be worded better to make it clearer what an app can potentially do.

  • (Deep voice): Hahahahahahaha we got them my minions

  • It's Shenzhen, not Shenzen. And note to gweilos: 'zh' is pronounced roughly like a 'j' in 'Benjamin'.
  • someone named "Job Stevens"
  • Seems like a good reason for a repository of open source apps for android, these can be built by an independent team - ie not the author. Then, hopefully, 'many eyeballs' would spot issues such as this.

    OK: there is still an opportunity for new apps, or recent 'urgent' patches, to do evil before they have been looked at, but the risk is greatly reduced.

  • by gotpoetry (1185519) on Thursday July 29, 2010 @03:14PM (#33075206)
    These wallpaper apps cannot access your contact's phone numbers, SMS messages or personal information.

    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.

Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Working...