Slashdot Mirror
Soundminder Android Trojan Hears Credit Cards
Blacklaw writes "A team of security researchers has created a proof-of-concept Trojan for Android handsets that is capable of listening out for credit card numbers — typed or spoken — and relaying them back to the application's creator. Once installed, Soundminder sits in the background and waits for a call to be placed — hence the access to the 'Phone calls' category. When triggered by a call, the application listens out for the user entering credit card information or a PIN and silently records the information, performing the necessary analysis to turn it from a sound recording into a number."
When my cards expire my bank mails me a new card, with a phone number to call in order to activate it. The process involves telling the machine what card is being activated.
... so you better start making smarter phones and more rigorous guidelines for app store approval. Problem solved.
Do people actually still give credit card numbers over the phone? I can't think of one time in the last 8 years that I've had a credit card that I've ever given it out over the phone. And not out of fear, either. The situation has just never come up.
I suspect they're talking about strings of touch-tone numbers that are dialed during a phone call. If the string is long enough, an application can infer that it's a credit card number.
This happens all the time with over-the-phone payment systems. True, many of these systems are being supplanted by online payment methods, but many niche services (debt collection, carry-out order, etc.) still use smaller automated phone-based systems.
This is just one practical application. *Puts on tin foil hat* What about a comparable government system mining for certain terrorism related keywords? I can think of 100's of more dangerous applications to this type of software, and I don’t even have to be the person who has it installed. I find that particularly frightening.
I'm thinking this through and thinking of my android-based device. For anything to gain access like this wouldn't the user need to be root? Or can the app simply request permission? (Disclaimer: I'm root and have cyanogen on my phone.)
The article says the application requests the following permissions:
There's an additional app that requests Network Capabilities; it's used to relay the data. Since the original application doesn't request those capabilities, it's less obvious (although now a second application has to be installed).
Basically, the application masquerades as an overly-permissive "voice recorder". It registers to receive notifications when the "phone state" changes, and when you place a call it starts recording. It processes the audio and pulls out voice and touch-tone number sounds. It then passes that information to the "Deliverer" application, which forwards it to the bad guy. Two applications written by the same developer can share data, so they probably use that channel.
The scenario is that a user will install the recorder app because they want a voice recorder, and will install the "Deliverer" app for some unrelated reason. Neither app's permissions set off any warning bells, but, together, they can steal your data.
So no, no rooting necessary. Goes to underline the general idea - given any security fence and enough time to understand it, someone will find a way around it. It's not particularly creative or innovative - just one of those proofs-of-concept of the obvious that will get media attention. Android's permissions are a nice heads-up to the user, but you really need to know and trust the publisher before you give any of the more deadly set of permissions (e.g., hardware controls, network communication) to an app.
Article and summary say "typed or spoken" - so it is not simply looking for a sequence of tones - which broadens the impact significantly even from official over-the-phone payment systems.
Still, the fact that CC companies have to eat fraudulent transactions over $50 means that even if this were in the wild, it probably would not have major impact. CC companies are pretty good at detecting fraud. Debit cards/banks, however, are not held to the same standard - highly recommend never, ever, using a debit card under any circumstances regardless of this kind of exploit.
So it could be bundled in with a "voice changer" app or, probably more successfully, one that randomly inserts background noise (train station, jungle, room-o-farts) into your call. For freez!
You're special forces then? That's great! I just love your olympics!
While "Hardware Controls" seems intuitive for the stated purpose, "Read Phone State and Identity" is fairly common, too. Almost every application will do things differently - whether operating in the foreground or background - depending on whether you are using the phone at the time. E.g. whether to play a sound or ring an alarm. This is one permission I (and I hate to admit it) would barely think twice before granting to just about any app.
----
Not to be confused with Col.
Perhaps one solution to consider would be the ability to put the device into a state where nothing but the phone is running - i.e. all other apps are just blocked until the call is released. Alternatively, the phone data in / out could be sandboxed from the rest of the OS. This would be a special mode since there are legitimate uses for this (tone dialing, call recording, etc.), but should be available to switch on when needed (or take the reverse approach and have it on by default, switched off when desired).
I'm not sure if the Android API would allow building an app for this, or if something at a lower-level would be required.... Anyway, feel free to implement this and send me the royalty cheques if you can. Just google for my banking info.
----
Not to be confused with Col.
That $50 limit was extended to debit cards some time ago
"That $50 liability limit also applies to ATM and debit cards, though holders of these cards might be liable for up to $500 if they fail to report the card's disappearance within two business days after they learn of the loss or theft of the card. (Debit and ATM card owners can be held responsible for all losses if they fail to report the theft within 60 days of when a bank statement showing unauthorized charges is mailed.) " -- http://www.scambusters.org/creditcard3.html
Once again being unintelligibly Scottish comes in useful.
Is there really insecurity when the user has to click "accept" when prompted with a list of everything that application has access to?
To be honest, I'm pretty sure Google can pull trojans off its Market. The victim would have to be stupid enough to (a) download an app from an untrusted source, and (b) click through the "This app has access to this stuff" warning without reading it.
In other words, it's not much more different than PCs.
"We are Microsoft. You shall be assimilated. Competition is futile."
How is this insecure? The behavior is "as designed".
If it isn't the behavior you thought it should be, well, perhaps you shouldn't install unsigned applications from sketchy websites that want to both access your mic and your phone log.
In fairness to Linux, it still requires a moron somewhere in the equation to accomplish this feat.
Tiger Blooded Bi-Winning Machine
In the team's research paper (PDF), they suggest a defence mechanism against Soundminer: an intermediary layer that analyses input from the microphone before passing it to an application, able to detect credit card numbers and prevent their transmission to Soundminer-like Trojans.
This is possible, but why not take it one step farther (and simpler) and just make an event handler that lets you know what is going on when. These apps all work WITHIN the security construct of the Android OS. They don't even have to exploit code defects or undermine system permissions for this to work; they ask the user if the app is allowed to record (possibly during phone calls) and if its also allowed to send data (possibly right after a phone call). The user doesn't put two and two together, allows the activity and doesn't give it a second thought.
Interlude: This isn't a problem just with "ok-mashing lusers" who blindly accept permissions on anything that comes along. You might want an app with the ability to record voice calls (for security, quality assurance, etc.) and you might want that app to also be able to send data to the internet so it can upload the audio, or something similarly useful. What even the smartest of the smart users don't have any visibility over is the actual source code of all of these apps, to make sure that the app is *only* doing what you want it to. Even astute users, who do everything right except for misplacing their trust in the app developer, can fall for this attack.
Solution: Introduce an event handling feature that can be set up to notify users of possibly malicious activity. If you are paranoid, you will check all the boxes off and be notified when "a third party app is recording while the phone is active", "a third party app is backgrounded and sending data to an internet service and is not on the whitelist", etc. etc. etc. This way you can tell if some random app you didnt even think you were using at the time happened to get ahold of some data you didnt want it to have, and sent it off to a collection server. Is it going to stop the activity? No. Is it going to give the average user who pays attention to their phone but doesn't have the time/wherewithal to do code audits on every app they have installed? YES.
If we can teach people to steer a heavy metal vehicle down a highway at speed we can certainly teach them to understand how software trust works.
We're doomed.
Faster! Faster! Faster would be better!
I'm pretty sure everyone likely to read your post already knew that. I have my credit card set up to be paid by direct debit automatically, so 14 days after the end of the billing period (i.e. before they would start charging interest) they take the money. Because it's Direct Debit, it's covered by the Direct Debit guarantee, so my bank can reverse it for me easily. They send me an email each month to remind me to check the bill online (they don't send paper ones).
In effect, I have something that functions like a debit card, but for which I get 1% back and between 14 and 45 days of interest-free loan on every purchase. Since I have an offset mortgage, the money on every purchase I make on my credit card sits in my current account for 14-45 days after I've spent it, reducing the interest that I pay on my mortgage (this saves less than the price of a pint of beer each month, but it's still nice to have for no effort).
I am TheRaven on Soylent News