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?
Check for the signed label! (Score:5, Insightful)
This is something that is far more unlikely to happen on the iPhone because of Apple's strict control and testing of all apps. Even the "jailbreak" stores will reject things that aren't as advertised.
Allow open development, and you've basically got a platform that the bad guys can target. There's already standards for signing code to prove that an app came from who you thought it did.
Re: (Score:3, Insightful)
Wow, second post and already we've got the "iPhone vs Android" debate started! Kudos!
That aside, or the apps Apple has had to remove aside... I'm happy with 99% of the quality control on the Android Apps.
Re: (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:5, Interesting)
The very same argument has been made as to why the XBox online experience is better than the PS3 or Wii. With MS, the control is in place. To participate, you have to accept the control (ask those banned due to hacked boxes). It's also why the PS network is getting some level of premium status to help curtail some of the problems related to that.
Apple's control is great in terms of keeping the store "clean", but the process they put in place didn't anticipate the number of submissions, overwhelming them. Resulting in slow acceptance times, bogus rejections, etc. Someone will need to figure out a happy medium in terms of control and flexibility.
Re:Check for the signed label! (Score:4, Insightful)
phone providers/google could set up a "safe mode" in android that only allows signed apps to run. if the user wants to leave safe mode to install an unknown app they can but be shown a warning of the consequences. That way people who want to be safe can be safe and people who want to run what they like can run what they like. Kind of like apple putting a jailbreak button on the iphone. That way people can choose between safety or freedom.
given time as more apps get checked and signed, people would have less and less reason to leave safe mode.
it reminds me of the software repositories on ubuntu - for about 2 or 3 years there was essential stuff missing that forced you to manually install dodgy software that potentially broke your system, but now that it's matured there often no reason whatsoever for a home user to stray outside the repos
Re: (Score:3, Insightful)
The freedom of the droid is nice; but at the same time it requires more responsibility on the owner.
This made it to the App Store too! (Score:3, Interesting)
I think people are missing the point here - this isn't about a malicious app on some random website, with people saying "Well it wouldn't happen with Apple, because you can only run what they allow you", it's about a product on Google's App Store.
AFAIK, they can and do control what goes on here - the problem was they failed to spot it.
So what this shows is that relying on app stores isn't necessarily safe after all - personally I prefer the freedom to download from where I like, as offered by Android, Symbi
Re: (Score:3, Interesting)
would you care to elaborate on PSN vs Live ??? Live has nothing more to give than PSN except the cost (I don't see the added value to justify that) Frankly I fail to see a relation between the matter at hand and that.
On Live, if you get banned for violating their ToS (for example, hacking your box, cheating, sufficient complaints of racism) then you are banned from all online play. On the PS3, Sony does not (to my knowledge) participate in the ban process except for their own services. So, if you get banned from Home for racism you can still play all your other games online. Each game needs to ban you individually, thus fewer asshats will be banned for any particular game.
Even the cost itself helps here. If someone
Re: (Score:3, Interesting)
You are blaming sony for a lack of control of their hardware ? that should be a first here.
No, control on their network. MS only has control over their hardware in as much as they can limit access to their network capabilities. However, more importantly, they can use this same control to limit any ToS violation, particularly cheating, while any mechanism on PSN can be easily circumvented with a new account.
Re: (Score:3, Interesting)
I think it is natural to make the comparison, one of the only reasons that Apple has an advantage is because of the quality control it offers on its app store. Of course, until recently Apple didn't do any in app checking, to find out what exactly the app was doing.
"Until recently"? So, inotherwords, it took them years, while Google has been at this for a lot less time? I am sure they will learn from their mistakes.
Yet it seems apps that Apple think are bad have slipped through from time to time. That was my point. The comparison would be great if it didnt cover the fact that until recently, such protections werent in place, and things still slip through now and then.
And of course you are happy, until you get your information stolen. You might not even realise it, and even when you do, it would be hard to link it to a phone application rather than one of the usual methods.
I use a very small list of apps, because I am aware of the dangers. The vast majority of those apps
Re:Check for the signed label! (Score:4, Interesting)
This is why we can't have nice things.
And I'm sure US cellphone carriers can't wait for more malicious apps.
Re:Check for the signed label! (Score:5, Insightful)
Re: (Score:3, Insightful)
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.
Nice feature, but most software houses see the downside.
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:Check for the signed label! (Score:5, Interesting)
Do the Underhanded C Contest and Obfuscated C Contest ring any bells?
Even review of every line isn't enough. But it's better than what closed source can offer.
Re: (Score:3, Insightful)
That's because it's an easy target, in spite of all it's "security measures".
Re:Check for the signed label! (Score:5, Interesting)
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.
Out of curiosity, what's to stop this situation: I build a "custom" version of an opensource application that includes a trojan. Maybe I use the application's original name, or maybe I add a few features/artwork and call it something different? People are just grabbing the exe's, afterall, and not building their own copy from the source.
Re:Check for the signed label! (Score:5, Interesting)
Suddenly your .exe doesn't match the MD5 hash of the real program. People will notice.
Re:Check for the signed label! (Score:5, Insightful)
Re: (Score:3, Funny)
The sort of people who check MD5 hashes, of course.
Re: (Score:3, Insightful)
People which use software installation systems that check MD5s by default. Even Windows does something like this, but so many applications don't bother with signatures that "warning unsigned application" is pretty much meaningless.
Re: (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 reposi
Re: (Score:3, Insightful)
How do you know the binary you install is the same as the source?
MD5 hash for the win! If your hash doesn't match the published hash, something's up.
Unless you propose that all software be compiled and signed by a trusted authority or be compiled on the end user's device...
Already happening on several platforms. MS Office VBA, MacOS, etc. Unsigned code is allowed, but requires a user's approval to a warning that the publisher is unknown.
And if someone introduces the ability to download and execute arbitrary code, perhaps via a clever and well-hidden exploit?
Would require an app that asks for rights to contact the network, and network traffic can be monitored. Somebody will notice.
Re: (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 al
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:4, Interesting)
Re:Check for the signed label! (Score:5, Interesting)
And applications can be pulled from the Android Market after the fact, which frankly is terrible security.
Apple's security model is still far inferior to Androids. Apple have a gateway only approach, Apples decides what does and does not run on Iphones remotely and forgo any local security, Android has a limited gateway and local security approach, Google can revoke malicious applications and make them go through some kind of testing before hand (probably what Google will end up doing, limited semi/completely automated testing to check for obvious problems) and then you have local security on the device. The idea is that no program is trusted. Now with Apple you have a single point of failure, if a self replicating virus/trojan gets past apple then its over unless apple uses the kill switch, if the kill switch works. With Android if a virus/trojan can replicate you still need each user to authorise install on each device.
You will also have more people watching android applications, Google are quite open to security being questioned where as it is tantamount to heresy to even suggest that Apple has insecurities (and I'm certain some fanboys are frothing at the mouth reading this and typing an incoherent rant). The false sense of security that surrounds Apple is far more dangerous then the open nature of Android or the Android marketplace.
Re: (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.
Then the developer is screwed (Score:3, Interesting)
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.
And then what do you do about the fact that you have given Apple and address they have verified, and paid for a $99 developer account via some means they can tract back to you, along with probably given them your bank accou
Re:Then the developer is screwed (Score:5, Insightful)
Quite easy to give and verify a fake address, especially if it's in a foreign country.
Once again, easy to do with a foreign bank.
There are plenty of easy ways to prove addresses that can be easily faked, bank statements, utility bills. Plus there is the idea of using someone else's identity entirely.
Let me put it this way, anyone smart enough to develop a scheme like this is smart enough to defeat Apple's rudimentary address/credit checks.
You seem to have a lot of faith in Apple's ability to detect a hidden scam once it has already penetrated their security (the app store). It's entirely plausible that this kind of phishing go on for weeks or months without anyone noticing, especially seeing as Apple are the only watchman and considering what the average iphone user understands about information security.
Re: (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 a
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.
So trivial it's never been done (Score:4, Insightful)
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.
Hey, what was that old saw about Macs not having any viruses? Wasn't it something like, the platform is not popular and that's why they do not have viruses?
Well here we have a wildly popular mobile platform. Yet the most egregious exploit in an app to date is something that sent your address book somewhere without permission (something that's explicitly allowed by the API).
So given the number of apps there are, perhaps the lack of problems like this is an indicator it is not as "trivial" as you claim to put a malicious app in the store.
What would a malicious app really do anyway? It couldn't delete user data. It can't send passwords not entered in the app (passwords are not stored in the keystroke cache). And what makes you think Apple would not give extra scrutiny to an application that asked for something like your banking details? What makes you think they don't roll the date forward a month or two when testing apps just to see what kind of extra activity might be triggered?
Furthermore, because you have to go through some paperwork to be a registered developer in the first place, you have a lot more exposure to liability if you try something. Apple the has valid bank account details for you (if you registered to sell paid apps), along with your address and other things. So if something like this exploit were found, you'd be pretty screwed.
There are more aspects of protection in a closed system than just the review cycle...
Why bother? (Score:5, Interesting)
Re: (Score:3, Interesting)
Sorry, stores need crypto signatures or you get browser warnings.
So what? It's not hard to get an SSL certificate.
Re: (Score:3, Interesting)
Uh... NO.
This alone says a bit.
This is a bit more disturbing.
But the ability to generate a rogue CA cert [win.tue.nl] kind of nukes the claims you just made from orbit- just to be sure.
In short, it's NOT hard to get an SSL cert of that nature- just not as easy as snapping one's fingers.
Re: (Score:2)
likewise, thanks to apple's strict control having useful applications is also far unlikely to happen. How are those google apps going on your iphone? Oh right, you started a flamebait discussion and tried to literally equate that open development equals a lack of security. goood job. Meanwhile, open development also equates to actual security, not falsely believing that apple is magically secure or likewise with windows. Security through obscurity is called delusion.
Re:Check for the signed label! (Score:4, Funny)
Anyone want to bet that "Droid09" has an address somewhere near Cupertino?
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]
In another time... (Score:3, Funny)
Allow open development, and you've basically got a platform that the bad guys can target. There's already standards for signing code to prove that an app came from who you thought it did.
Steve? Is that you?
-B. Gates
Use an Outbound Firewall (Score:5, Interesting)
I set the default outbound policy to DROP, then specifically whitelist the apps that should reasonably have access to the internet.
Since Android apps have to specifically declare the privileges they require before installation (such as ability to read contact data, internet access, etc), then it's easy to make sure that all apps that read personal data are not whitelisted, unless they come from a reputable developer (e.g. Google-made apps). Any app that can read my contacts data, my calendar, my email, etc, is sure as hell not getting internet access for "usage statistics" or whatever other lame excuse they give.
I wish this functionality was built into the OS, rather than having to do it manually (for example, a way to disallow internet access during installation) -- but at least it's doable on Android. I don't think any other phone platforms give this level of permission separation or control. I'm not so sure that app review would really fix the overall problem; it might catch the obviously-malicious phishing apps like in this story, but I bet that the app auditors' opinion on what is a privacy violation differs greatly from my own.
I still wouldn't use my banking info on my phone regardless, since a phone is so easily losable, and locking/unlocking the data everytime with a secure passphrase would probably be too inconvenient. At very most, I would only allow read access to transactions from my phone (if banks offered this), thereby limiting the amount of useful information or control a would-be attacker could gain from compromising my phone.
Re:Use an Outbound Firewall (Score:5, Insightful)
Sounds like a really easy way for your standard user to administer their phone. My mom would totally get that....no wait....I think I meant the opposite of that. Yeah.
Seriously, though, how do you communicate this to your standard, non-techie user?
Re:Use an Outbound Firewall (Score:5, Insightful)
The problem isn't technical, but rather lack of user training
The internet is not a safe place. If you want to use it openly, you better not be gullible and hand out your info to anyone who asks.
One solution would be to setup the phone for your non-techie friend, and whitelist all the apps that they'll need that should have internet access. Yes, this means they'll have limited use of new apps, but if they can't figure out when not to give out her bank details, they aren't sufficiently trained to safely use the internet.
Re: (Score:2)
This happens enough, the carriers will quickly move to take back control of the handsets with their own "software" in the guise of consumer protection just like they have been. I can see a day where the, the new Verzion "SafeDroid" runs a firewall that blocks everything by default, for user safety of course. Oh, want to run turn by turn navigation, that will be $15 a month please. Want to unlock this app, $5 a month please.
It may be based on android, but I'll be the carriers will move to lock it down.
Re: (Score:2)
Want to unlock this app, $5 a month please.
If Verizon does that, AT&T will be quick to point it out in the ads. Somehow, I don't think Verizon is quite that stupid, although I could be totally wrong.
Re: (Score:3, Interesting)
Want to unlock this app, $5 a month please.
If Verizon does that, AT&T will be quick to point it out in the ads. Somehow, I don't think Verizon is quite that stupid, although I could be totally wrong.
Yes, they are that stupid, but like the other response said, there is no real competition between providers. Verizon has been doing this with their BREW system for years. Some apps have both a "permanent" subscription option and a monthly subscription option, but there are others that are monthly only, such as the navigation application. I bought a permanent license for Tetris for $6 years ago, on my previous phone, instead of paying $1.99/month for it. (Of course, Tetris didn't carry over to my new pho
Re: (Score:2)
If you want full control, then treat your phone like a laptop and buy it yourself.
I agree, but unfortunately that's only viable if carriers allow phones on their network that they don't provide.
Re: (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:Use an Outbound Firewall (Score:4, Interesting)
> Like any GSM/UMTS network in the world?
You're forgetting that GSM/UMTS phones won't do 3G on any network in America unless they happen to support 850/850 or 1700/2200 uplink/downlink. AFAIK, the US is the only country on earth that does 850/850 and 1700/2200 UMTS. I don't even think *Canada* uses those frequencies. For all intents and purposes, the only phones that support 850/850 UMTS are sold by AT&T Wireless, and the only phones that support 1700/2200 are sold by T-Mobile. So much for interoperability. A "global" phone that supports only 1900/2100 UMTS will give you blazingly-fast 19.2kbit/sec GPRS in America (or serve a more useful purpose as a paperweight in windy weather).
It's sad, but right now, Verizon is ironically the most interoperable carrier in America, just because you can theoretically reflash the Sprint twin of a Verizon phone with Verizon firmware and they'll let you use it if you can figure out how to do it on your own, without any help from them. It's a piss poor, sad excuse for interoperability, but just goes to show how dire the wireless situation *is* in the United States.
Re: (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 2100
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:Use an Outbound Firewall (Score:4, Insightful)
This explains the explosive spread of viruses on the Apple platform!
Re: (Score:3, Insightful)
Seriously, though, how do you communicate this to your standard, non-techie user?
You don't. This is NOT A PHONE. This is a little computer with a phone IN IT. The same level of knowledge required to use a computer and install apps safely, etc is necessary here.
Re: (Score:3, Insightful)
You make a good point, but that doesn't really do anything to the OP point. Most people who use computers are not techie users. They fall for scams all the time.
Re: (Score:2)
I'm sure you know this, but for other readers of your post -- just as there is a permission to read contacts and such, there is a permission apps have to request to gain access to the Internet. So, at install time, you can read through the list of requested permissions and take appropriate action. For example, I rarely install ones that ask for my contacts
Re:Use an Outbound Firewall (Score:4, Interesting)
Any app that can read my contacts data, my calendar, my email, etc, is sure as hell not getting internet access for "usage statistics" or whatever other lame excuse they give.
Usage statistics are the only reliable way to get real feedback about how actual users interact with the software (short of having a horde of QA testers that we can't afford). Some of the more useful things that my apps track (anonymized and with the terms stated clearly on install with an opt-out):
(1) Which settings are most often changed, and to what. This helps us put the most-changed settings near the top and set better defaults. If a setting is changed back and forth a lot, that usually tells that the UI needs widget to control that behavior.
(2) Which functions are used most or used most together. This helps organize the UI in accord with the most common usage patterns. Many times, we will see that users do the same clusters of things over and over and that lets us combine those into a single task in some fashion.
(3) What functions/options are almost never used, especially ones we had imagined would be useful. This is usually a sign that we have either totally dropped the ball on implementation or interface or that we don't understand the user's workflow.
I will admit that this is largely a matter of trust between the developer and the user -- I really can't blame users that opt-out or firewall us because they really don't have a reason to trust us. That said, such distrust does deprive us of very important data that we use to improve our products. I just want to express my deep appreciation for all the users that have let us have their usage statistics -- we really do read and act on them!
Re: (Score:2)
in this case, if you downloaded an app that you thought was a legit banking app, you would have just added it to the whitelist.
An iPhone-like process? (Score:2, Insightful)
Re: (Score:3, Insightful)
How about "Linux-distro style vetting process"?
Impossible, unless all apps are required to be open source (which would not be popular with many commercial developers). I'd even bet a large number of commercial developers would even be annoyed enough to stop developing for Android's app store if required to turn over their complete source code only to Google employees for review -- Apple doesn't even require this for their app store.
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: (Score:3, Insightful)
Re: (Score:3, Informative)
Re: (Score:2)
Then what is a "Linux-distro style vetting process", if not relating to the hundreds of eyes on the source of most programs?
Re:An iPhone-like process? (Score:5, Insightful)
iPhone's vetting process has a "AT&T doesn't like it, so Apple will deny" clause that the jailbreak stores don't. Apple then claims that jailbroken apps could be trojans that will overload AT&T's network.
Google seems to be taking a "we'll do what we want and carriers can't stop us" attitude. Good luck with that.
Re:An iPhone-like process? (Score:4, Insightful)
iPhone has youtube and pandora among many other apps that have very high network usage. sort of shoots a hole into the theory that AT&T is rejecting based on potential network overload.
Re:An iPhone-like process? (Score:5, Interesting)
An iPhone-like vetting process would be "we'll reject it if we don't like the look of it". How about "Linux-distro style vetting process"?
Multiple repositories solve part of the problem, but more then just vetting the repository as a whole we need to score/rank/blacklist/require individual applications and authors. What friends think of an application is much more important than the "average" score of everyone. IT departments need to add/update/remove applications for workers phones, but also let the end user manage applications. Ban lists need to be available in a form that lets the end user (or their tech. support) decide what to trust.
It's amazing that such a big industry has such crappy tools to manage applications. Making things "just work" for the end user does not need to mean a monopoly or tyrant controlling the (only) store.
Re: (Score:3, Insightful)
No, the iPhone vetting process is unashamedly "that competes with us, denied!"
Re:An iPhone-like process? (Score:4, Insightful)
An iPhone-like vetting process would be "we'll reject it if we don't like the look of it". How about "Linux-distro style vetting process"?
The iPhone vetting process is closer to Slifox's "error on the side of caution" method on his outbound firewall, with the default being set to DROP (deny the app), followed by a specific whitelist (approved apps subject to continuous monitor for "good behaviour").
Quite a number of approved apps in the iPhone App Store have been caught out doing naughty things like accessing and sending "home" users' Contacts - email addresses, phone numbers and home/work addresses - where they really had no business requiring such information for their function (battery charge display apps, games etc) and have promptly been expelled from the app store - quite rightly in my opinion.
The price of true freedom is eternal vigilance, not laissez-faire do-what-you-please laxity...
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: (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 o
Re: (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: (Score:3, Interesting)
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.
What about the "we may reject your application for any reason whatsoever" clause of Apple's policy?
Nothing new here (Score:2, Interesting)
From time immemorial, bazaars have had pickpockets.
How will app vetting help? (Score:2)
Apple's app store is already full of apps that require the creation of an account with a username and password. That's part of the value proposition of the technology platform: always-on synchronization between device and cloud.
In a significant portion of cases I imagine this means that users have a single username/password pair that they have used to create dozens of accounts with services around the web. The fact that the app has been vetted and functions exactly as promised does not mean that there is no
Re: (Score:2)
Because Apple's vetting has a step in it where they verify the identity of the author. Pull that trick, and people will wonder why their accounts were compromised, and surveys of the users will find that everybody affected used your app. Go to jail, go directly to jail, do not pass go, do not collect $20.
Re: (Score:2)
Because Apple's vetting has a step in it where they verify the identity of the author. Pull that trick, and people will wonder why their accounts were compromised, and surveys of the users will find that everybody affected used your app. Go to jail, go directly to jail, do not pass go, do not collect $200.
FTFY. I don't believe that the great recession has been quite that bad.
If you want to be free (Score:2)
If you want to be free, be free. But then get checked every three months and you probably shouldn't give out your real address and phone number to anyone you're being free with.
Re:If you want to be free (Score:4, Insightful)
Tragedy of the Commons comes to mind here. People around here like to bitch about Apple's policies with their app store, but I understood the reasoning behind it from the beginning. The average consumer doesn't know better. A cute app that is malicious can spread to millions of users before someone wises up. And it only takes one or two to make people fearful of the platform.
It will be fun to see if the carriers take advantage of this and try to get control over the handsets back in their court as opposed to that of Google. If it happens a couple more times, I can the Verizon App store popping up and a Verizon UI required on all android phones that only allow users to use their store. And I'm sure a lot of the apps will require extra "monthly" fees.
Re: (Score:3, Interesting)
What I can see is that carriers would have their own Android app stores, similar to how one carrier in the US used to require not just Microsoft code certificates on signed executables, but the carrier's as well. If the app wasn't signed by a certificate either from the carrier, or a key allowed by the carrier, the app won't install on the phone. Of course, the certs can be yanked at a moment's notice.
Re: (Score:3, Interesting)
What makes "mobile" so different from the desktop?
Reserved words? (Score:3, Insightful)
Re:Reserved words? (Score:4, Insightful)
"Bank of America" is already a reserved word under trademark law. You could say that "bank" is a reserved word, but then you'll accidentally block "iBank" and such. Such problems.
Re: (Score:2)
Nintendo, Sony, Apple, Microsoft, Facebook, Philips, HP, AMD, Intel, Final Fantasy, Square-Enix, Wii, Pepsi, Coke, Compaq, Logitec, Halo,
Now, when someone would search for these, my post might come up (yeah, unlikely, but I suppose its possible) same with the Android marketplace. If I put on a description "This app lets you use Twitter" its no different than an app that says "This app lets you s
Separate passcode locked to a verified device (Score:5, Interesting)
It's not perfect security, but it certainly puts up a few more decent hurdles against phishing.
Re: (Score:3, Insightful)
That prevents the problem of somebody bringing in a mobile device and claiming to be you... but doesn't stop you from giving your main password to a false app that asks for it.
Precedented (Score:2)
Re: (Score:2)
CNET is a good fact-checking group, but they've fallen for tricks in the past. They're quick to put out a loud warning when they get tricked and figure it out, but they aren't perfect.
old problem new platform (Score:4, Insightful)
The fault here lies primarily with the user, but seeing as we cant force the users to be smarter the onus for defeating this attack relies on the bank. Banks can do a variety of things to prevent such phishing attacks from working such as using 2 factor authentication and One Time Passwords. OTP works best when being used for transactions rather then logins, my bank will SMS me a code when I want to make a transaction to another account so even if a phisher has my password, they need my phone to do anything (plus this is a dead give-away that a phisher has gained my password). Banks could also issue a private key to official applications and block any application that does not have the key (granted this is less useful and may be easily defeated)
Iphone style lock downs will not work as they do not address the real problem of phishing and only serve to limit the platform. This isn't a fault with Android, this requires the user to initiate the attack, nor is it self replicating.
My vetting process is simple. . . (Score:5, Insightful)
Why on Earth would you download a 'bank' app from anyone other than *YOUR BANK*? I'm only gonna do online banking from the website or apps provided to me directly from my bank. I'm not gonna download anything from the Android market, from some random user, and do banking with it. Who thinks that it's a good idea to do 'banking' with an app by a random developer? I mean, *maybe*, maybe if it was someone large and established, like IBM, Google, Microsoft, or Apple, I *might* consider using third party software, but certainly not anyone I've never heard of before.
Ask Mint.com (Score:3, Insightful)
Why on Earth would you download a 'bank' app from anyone other than *YOUR BANK*?
Actually there's a very good reason (for the user) - banks cannot write user interfaces to save their lives.
In fact they are so horrible at it, that Mint.com flourished with tens (hundreds?) of thousands of users, despite you needing to give Mint the passwords to EVERY SINGLE BANK you do businesses with.
Would you or I ever, ever do that? Nope. No reasonable person would you would think. Yet many have (and continue to), just b
Where is the evil DRM protection when you need it? (Score:3, Funny)
on any other platform, you wouldn't need to remove software from "Droid09", your overlord would remove it for you, along with any other subversive material that might be on the device that you're borrowing from them
Is this itself a scam? (Score:4, Interesting)
I note that searches of Secunia, SANS.org, and CERT don't return any mention of it, which is curious given that the...alert...began spreading on or about the 3rd of December, 2009 according to a date-sorted Google search (who is Jeremy Allexon?) [google.com]. Said search likewise fails to turn up any sources which I would call "authoritative".
Given the nature of corporate competition...
Re:No sandboxing? (Score:4, Interesting)
Sandboxing wouldn't help here. The app looks like your bank app. So, it just collects the information from you.
Re:No sandboxing? (Score:5, Insightful)
Sandboxing is an "always deny" tech that keeps legit applications from working easily. Effective, yes. Going to catch on with the average user, no.
Re: (Score:2)
Well, the original idea of the TPM was exactly that: Sandbox everything, manage every trust relationship in your system, hardware, software, whatever, and make it possible for the average user.
Of course we know what that was turned into.
But a good example is SElinux, which is not much different, except that is entirely software. Here on Gentoo, there are SElinux policy packages for every important software. Which are kept proper for me. (Yes, it is far from prefect, but it is a start, that if extended to ev
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...
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: (Score:2)
Paranoid much?
And anyway, what difference does it make? Do you think it is only Apple shills who can do bad stuff here? How ignorant are you?
Re: (Score:3, Interesting)
It's prudent to note that Avira anti-virus used to be called "AntiVir"...but I'm pretty certain you're not talking about the same people..
Right. There's a rogue called AntiVir as well.
Nowhere near as annoying as the "heck with it, just backup and OSRI"-worthy "Internet Security 2010", however.
Re:HERE'S HOW ANYONE CAN BEAT ANY Vetting !! (Score:5, Insightful)