Malicious App In Android Market 340
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?
Re:No sandboxing? (Score:5, Informative)
Each app has its own user and group ID, and filesystem permissions are used to determine what data an app can access.
Additionally, apps have to declare the special permissions they require before installation, such as internet access, read contacts data, etc...
Android is way ahead in this department -- this story is simply a case of phishing: the users thought the app was a legit bank app, and they willingly gave their sensitive information to it. It's hard to prevent against that without user training, and the success of normal email/website phishing has shown that very few users are "trained" in this sense...
Apple's store ain't much better (Score:2, Informative)
Apple's policy ain't foolproof either. I found an app designed for validating stolen credit cards, marketed to Romanian hackers:
http://rationalitate.blogspot.com/2009/12/credit-card-stealing-app-in-apples.html
Re:No sandboxing? (Score:4, Informative)
Android already has sandboxing. Every app installs under its own user ID by default, and if it wants more permissions, it will ask the user on install, and the user can deny it.
Even if this app had no permissions whatsoever except to display on the screen and send info back to a server, it would be successful, as it made for social engineering, as opposed to having the primary function as being compromise of the Android device.
Re:An iPhone-like process? (Score:5, Informative)
How about "Linux-distro style vetting process"?
Impossible, unless all apps are required to be open source ...
Not true. You can have binary only repositories. Ubuntu 9.10 has a "partner" repository from which you can install Flash, and interestingly, you can add it to your sources list by clicking a link in Firefox.
Re:Check for the signed label! (Score:5, Informative)
Um, no.
Apple's certification process is unlikely to uncover an app like this. Assuming the app appears to do something 'real' [which I assume it does, as people download and use it], you can have the app access a web page that tells the app if it should harvest data or not. You simply don't enable the harvesting until after Apple has accepted it into the App Store. Black box testing won't uncover it, and static program analysis is unlikely to either [short of the app obviously using restricted APIs]. And apps can poke around the system, and I think even other apps data without even needing to hardcode in paths.
Now, it might be easier to Apple to be able to trace where exactly the app came from than it is for Google...
Re:Check for the signed label! (Score:5, Informative)
This is not the case. Apple don't perform in-depth testing in this manner; they don't have access to the source code and some developers have already successfully bypassed the rules of the App Store by hiding functionality as easter eggs. It is trivial to put malicious code in an iPhone app that won't be triggered until after the application is already in the App Store. The security restrictions on what the iPhone OS lets you do doesn't save you from this kind of attack either; it sounds like all an equivalent iPhone app would have to do is embed a UIWebView and wait for people to enter their information.
Re:An iPhone-like process? (Score:3, Informative)
Re:Apple's store ain't much better (Score:3, Informative)
The app by itself is not illegal -- it uses publicly available information to "parse" a credit card number, and the algorithms which determine the validity of a set of 16 credit card digits are pretty well-known by now. What the app probably cannot tell you is whether the card actually belongs to someone.
The description also doesn't outwardly suggest that the app was "marketed to Romanian hackers". Basically, there's nothing in the app description or screenshots to suggest that the application, which uses only publicly available knowledge, violates any of the terms of Apple's app policy.
Re:Apple's store ain't much better (Score:2, Informative)
Knowing the number-crunching formula for credit card validation is a one-way result. A "reject" is 100% certainty that the card can't be valid. A "pass" simply means the number could be valid, but doesn't give you any clue that the number will work when you try to use it. Pass too many bad account numbers to be processed, and you'll be noticed.
Re:Check for the signed label! (Score:5, Informative)
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
That's commonly claimed, but there is not much evidence to back it. There just aren't enough people interested in looking at source to cover all the apps if the Android market gets as big as the iPhone market.
Re:Use an Outbound Firewall (Score:4, Informative)
Yes, but it's not just that.. it's also that Apple redefines the terms as they go along.
"It's impossible to write a virus for our platform!"
"Ok, here's one I wrote."
"That's not a virus."
"Oh really? How do you figure?"
"It requires user help to move from machine to machine."
"Uhhhh... yes, that's what a virus is."
"No, it has to move from machine to machine without user intervention to be a virus."
"No.. that's a worm.. as has been clearly defined since the Morris worm."
"We call it a virus."
"You're idiots. This is a virus and it is trivial to write them for your platform. In fact, it's easier to write viruses for OS X than any other platform, as there's literally dozens of ways to load code into every running process simultaneously."
"We disagree."
and so on.
Apple, they believe their own hype and they're willing to deny reality to maintain that belief.
Re:Check for the signed label! (Score:4, Informative)
http://www.readwriteweb.com/archives/dear_iphone_users_your_apps_are_spying_on_you.php [readwriteweb.com]
Re:Use an Outbound Firewall (Score:3, Informative)
Like any GSM/UMTS network in the world?
Insert your SIM, and you're on. Only phones that won't work is those that have their IMEI reported as stolen.
Re:Check for the signed label! (Score:0, Informative)
Not only can they be pulled from the app store, but they can be remotely pulled from user's iPhones themselves.
Re:Check for the signed label! (Score:3, Informative)
MD5 hash of what? The software author's published binary?
In order to verify that the published source code is the same as the published binary, the compilation environment would always need to produce the same binary given the same input.
Certificate signing already works. But this doesn't solve the problem of knowing a binary you download was created using the published source code - unless the binary was compiled by someone you trust. In the case of all software being compiled and signed by the same organization (as is the case for the applications in a typical Linux distribution), this isn't an issue.
Many applications have legitimate reasons to access the network. And if one day the server responds with something triggering a backdoor...
Network traffic can be monitored, but is it? How many people actually pay attention, if the application has a legitimate reason to connect to the network? How many people go through the effort of intercepting encrypted traffic?
Re:Check for the signed label! (Score:3, Informative)
It's nice to see the other side of the coin though. The App Store, this would never have made it through.
Malware is only going to grow on Android.
Don't get me wrong, I think Apple are TOO controlling, but Android phones become more ubiquitous, malware is going to get worse.
This is only the beginning. (Ominous music)
Re:Check for the signed label! (Score:3, Informative)
Not really, if a person is organised enough to make and release this application, they are organised enough to defeat basic tracking. Apple wont have any more information on the attacker then google via their developer programs, pretty much all they'll have is an IP address of where an application was uploaded (defeated by proxies) and a credit card number (defeated by a foreign bank account), all details can be faked.
This is unless Apple has some spying program with their SDK, which of course is illegal.
Re:Check for the signed label! (Score:3, Informative)
Then the people grabbing the binaries will get a trojan (assuming they have permission to execute the binary, which 99% of normal Linux PCs do allow).
We discussed it last month [slashdot.org].
However, most people download all their software from a signed software repository (maintained by Ubuntu, Debian, Red Hat etc) which should go a long way to prevent this. The package manager verifies the signatures of the files downloaded (preventing a mirror maintainer changing the files), so you are putting your trust in the repository maintainers. Hence, Debian (for example) has some strict requirements [debian.org] before giving people access -- I would think someone having verified your ID would be a strong deterrent, as (I think) anything you sign for release would be linked to that ID.
Re:Use an Outbound Firewall (Score:2, Informative)
I hate to disagree with you, but Apple has been offering 'free' virus scanners with their .mac accounts since the times of MacOSX.1. I use the word free, even though its 70euros / year to be a member.
Re:Check for the signed label! (Score:3, Informative)
Uh, you don't know much about iPhone development, hey?
The phone does not trust every app that comes out of the app store. Each app has to be individually signed for the phone it's operating on and apps are very well sandboxed. So well sandboxed that people complain about it constantly.
App store vetting is an additional level of security on top of the phone itself being pathologically paranoid.
Re:Use an Outbound Firewall (Score:3, Informative)
The basic "quad-band" designation for GSM phones is for 2G stuff only, not HSPA. So you have 900MHz and 1800MHz in Europe, 850MHz and 1900MHz in the USA. But that's not 3G... usually. And that's because there just wasn't enough bandwidth... a proper G3 HSPA connection requires at least 10MHz of bandwidth, versus the 2.5MHz any carrier has guaranteed for 2G links. For HSPA+ speeds, they want two bonded cells... 20MHz total.
The preferred configuration, then, for US UMTS/HPSA was the AWS band, 1700MHz and 2100MHz (split between uplink and downlink), but AT&T didn't want to wait for this auction. In most of the US, AT&T had enough bandwidth on both 850Mhz and 1900MHz to offer full HPSA, so they just went that way. T-Mobile didn't, so they had to wait for the AWS auction before they could expand with 3G services. This was not a CDMA issues, since EvDO doesn't require additional spectrum (this is also why HSPA+ can be faster, and also why every CDMA cell is already 3G, versus some small fraction of those for GSM systems here in the USA).
Europe also went with 2100MHz, as did the rest of the GSM world. Except in some countries, which had larger than normal 900MHz bands. Or other weird local standards.
In short, the "universality" of GSM is only guaranteed with a quad band phone, and never for 3G services.