Well I guess Android really is open.
Android apps get SSL wrong, expose personal data
More than 1,000 out of a sample of 13,000 Android applications analysed by German researchers contained serious flaws in their SSL implementations. In this paper (PDF), the researchers from Leibniz University in Hannover and Philipps University of Marburg found that 17 percent of the SSL-using apps in their sample suffered …
-
-
Monday 22nd October 2012 11:41 GMT Phil Endecott
Re: Any word of similar research on iOS apps?
> Any word of similar research on iOS apps?
> Hard to see why the results would be different.
iOS doesn't provide apps with an API where they can set options like "don't check the domain" or "accept all certs". You get Apple's choice of settings. If you really wanted to do that, you'd need to roll your own version of OpenSSL into your app. As a result, I suspect that iOS really is more secure in this respect.
-
Monday 22nd October 2012 12:25 GMT Mark .
Re: Any word of similar research on iOS apps?
Any old feature phone doesn't provide apps with an API with these options either - I suspect that they really are more secure too, by that logic. It's not really an argument to be comparing platforms though, when one offers something in the first place the other doesn't.
-
Monday 22nd October 2012 12:49 GMT Anonymous Coward
Re: Any word of similar research on iOS apps?
All I could find on a brief look were these 2 stories:
http://money.cnn.com/2012/07/27/technology/iPhone-apps-iOS-hack/index.htm
http://www.msnbc.msn.com/id/47866280/ns/technology_and_science-security/t/apple-ios-tightens-iphone-ipad-app-security/
Swings
Roundabouts
-
-
-
Sunday 21st October 2012 23:46 GMT Steve Knox
Why in this day and age...
are the apps even using their own SSL implementations? Surely the OS should own that entire stack?
If the cert is expired, or there's a hostname mismatch, or the cert is not from a trusted authority, the OS could report that to the user directly, and send an error and no connection back to the app if the user doesn't accept accept the risk.
Then instead of thousands of potentially flawed implementations, there would be dozens -- the owners of which would have a much higher motivation to fix any flaws that are found.
-
-
Monday 22nd October 2012 14:42 GMT Steve Knox
Re: Why in this day and age...
The programmers of the app have configured their app to accept any certificate.
Which proves my point -- there's a setting in the Android stack that cedes control of a significant security setting to the app without informing the user and allowing them to prevent it. This effectively negates OS (and hence user) ownership of the stack.
-
-
Monday 22nd October 2012 10:11 GMT Rich 2
Re: Why in this day and age...
The last time I looked, Android did not implement client certificates in its SSL stack - the functionality just wasn't there. It's why I eventually gave up trying to get IMAP email working on it.
No idea if client cert support is included now, but if now, this (and maybe other omissions) could explain why at least some of the apps use their own libraries?
-
-
Monday 22nd October 2012 03:03 GMT dssf
Do no harm?
Omission is harm. I wonder why google did not vet all aps for basic security checks and the force the developers to fingerprint the app so the publuc would know whether a failed or fatally-flawed app was in the wild. I realize that google does SOME checks, but google should have long ago have the talent to have uncovered the same info described in this story, and should have empowered the user. A good deal of empowerment would have come from giving users an option and an easier way to rot the phone no matter WHAT the fucking phone companies want.
See, for all the morons who in the past who viciously downmodded me for demanding that google provide IDS, firewall, blocking, you were WRONG. And, since google so desperately wants its OS to be in top billing, they looked the other way, leaving it up to an uninformed public unwilling or unable to pay for comprhehensive security, securit that itself may have been cheating the system and users, too. Maybe more security flaws will wake google up, and enrage just enough consumers. I never did trust that Android was as secure as we were told, yet, i drank just enough of the KoolAid to quite possibly have exposed losts of personal info to newspaper sites, magazines, and even to malware-hosting countries.
Do no harm, yeh, right.
-
Monday 22nd October 2012 12:39 GMT Law
Re: Do no harm?
So you're saying lazy devs buggering up their security settings is Googles fault.
Riiiiiiiight.... you know Google is a business right, it's just not going to be cost effective code-reviewing every single app submitted to the play store - I'm sure they can automate some of the tests, but then why would they?
Even Apple don't do this, and they have the tightest iron-grip I've ever seen for an app store.
-
Monday 22nd October 2012 14:13 GMT dajames
Re: Do no harm?
So you're saying lazy devs buggering up their security settings is Googles fault.
The problem, as I understand it, is that it's an all or nothing choice. If you try to establish an SSL connection with a server that the Android stack can't verify using its store of root certificates you won't be allowed to. In some cases you can fix the problem by importing the appropriate root certificate, but in others (where a single certificate is used for *.domain.tld type addresses, for example, and Android doesn't like it) you can't. The only way, then, to achieve an even half-secure (that is: encrypted but vulnerable to MITM attacks) is to set the "accept any certificate" setting.
There is nothing in Android's SSL implementation that allows you to say "I trust this SSL certificate, regardless of its signature so please store it and remember it for next time -- in the way that Firefox on the desktop allows you to by creating an exception.
I think it's generally accepted that some such facility is needed, so the lack is Google's fault and they must accept some of the blame ... though it's true that an app developer could eschew Google's SSL stack and grow their own.
-
Monday 22nd October 2012 23:02 GMT Law
@ dajamesRe: Do no harm?
Ah okay - I must admit I didn't get all that from the original article (read very quickly at lunch!).
Now, it's getting close to midnight so probably not the best time for me to reply, but I thought I'd google the ssl stuff a little and it looks like people are misusing this:
http://developer.android.com/reference/org/apache/http/conn/ssl/AllowAllHostnameVerifier.html ... probably thanks to the helpful people on places like stack overflow and codeproject answering "I can't get this to work" posts.
I did see this though as part of ssl stuff which sounds like what is being said to be missing in android (they suggest it's firefox-esc in approach in the notes/comments):
http://developer.android.com/reference/org/apache/http/conn/ssl/BrowserCompatHostnameVerifier.html
I'm a dev, but not web based, and not android based either - so not really knowledgable on any of this, just curious now. It looks to me like the tools are there (been there since v1 of android) to have single-certs for wildcarded domains, but it's just easier to accept all and most of the google searches I made pointed to an "accept all" solution. This is all assuming I've not got the complete wrong end of the stick with this verifier stuff... in which case feel free to give me a good kicking (but show me the error of my ways so I can learn from this!). :)
-
-
-
-
-
Monday 22nd October 2012 09:23 GMT Paul 135
Android Email
On another similar topic, it has always concerned me that the Android Email client does not use SSL by default when auto-adding a new email account using the wizard. There is no way that a novice user is going to know that their email and password are not secure. Really, in this day and age SSL should be the default.
-
Monday 22nd October 2012 09:49 GMT Anonymous Coward
Oh noes.... someone could find the credentials for my twitter/facebook account.....
and post stuff that makes my life more interesting than it really is.
Imagine if they posted some pictures of food on FB with a caption of 'Hmmmm Dinner', without my knowledge. How could I live with the shame?
#lamejokealert
-
Monday 22nd October 2012 10:44 GMT the-it-slayer
Woah...
Are fandroids here still going to put their hands up and say there's no problem here? If you give developers the opportunity to shortcut, then they'll shortcut regardless if it puts personal data at risk. That's the problem with open source as much as I admire the open source community.
I'll keep my walled garden product thanks.
-
Monday 22nd October 2012 12:30 GMT Mark .
Re: Woah...
Ah, I wondered how long it would be before someone tried to make this as something to rant about Android with.
The survey just happened to pick Android, not unreasonably as it is what most people use. Yes there are other niche platforms like WP and iphone and other feature phones, but most people use Android, so it's reasonable to focus the survey on that.
But don't let that stop you taking it as Yet Another Handpicked Stat to claim your walled garden is better (whilst conveniently ignoring all the stats where other platforms are better). The walled garden you get with feature phones may well be more secure, but then you don't have the power and functionality of a smartphone.
-
Monday 22nd October 2012 13:07 GMT the-it-slayer
Re: Woah...
> The walled garden you get with feature phones may well be more secure, but then you don't have the power and functionality of a smartphone.
That's a good thing right of the walled garden? I don't want unsecure apps snooping and passing back my phone calls, texts, messages etc to dodgy servers thanks very much. I'd be more than happy to see some evidence on how secure iOS really is. Unfortunately, I can't pluck facts and figures from thin-air and can only comment what's been presented here. Android.
-
-
Monday 22nd October 2012 11:46 GMT Anonymous Coward
SSL Fail
SSL was in the past difficult to implement in Android, they have made steps to improve this but for the likes of 2.3 (the most targeted platform) SSL was terrible, the in built Android libraries were useless and clumsy. There are numerous work arounds, some more difficult than others, i have no sympathy for the big players being scorned over this, they should know better and do whatever is needed for a proper SSL implementation (it is possible, but difficult), i do however feel sorry for little larry the android app developer sat in his room having his app tested for this but i suppose if your being trusted with data then you should do what you can.
Maybe it is just down to a lack of understanding when implementing other peoples work around from stack overflow....i don't know. Google SSL Android 2.3 and prepare for the hell that will ensue.