Feeds

back to article 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 from …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

Well I guess Android really is open.

8
2
Bronze badge
Mushroom

They must have been taking lessons in Open Source development from Sony.....

0
3
Anonymous Coward

Just like a swiss cheese is open :)

1
0
Anonymous Coward

Really like my Android phone..

..but not yet been ready to trust apps.

It reminds me of my previous job where the exchange webmail had the wrong domain in the cert.

At least there the browser will tell you and you can make a decision (if you know what it means)

0
0
Anonymous Coward

Any word of similar research on iOS apps?

Hard to see why the results would be different.

6
2
Bronze badge

Re: Any word of similar research on iOS apps?

Uh, yeah, it's called IOS from Apple.don't believe me? research it. Surprised Reg missed it.

0
5
Stop

its not

But they don't have a product to promote oc the back of this "news" for ios yet

1
0
Anonymous Coward

Re: Any word of similar research on iOS apps?

"Uh, yeah, it's called IOS from Apple.don't believe me? research it. Surprised Reg missed it."

Thank you for your intelligent, informative and constructive contribution

2
0

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.

2
2
Silver badge

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.

0
0
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

0
0
Silver badge
WTF?

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.

7
1
Anonymous Coward

Re: Why in this day and age...

The apps are not using their own implementation, they are using the stack provided by Android.

The programmers of the app have configured their app to accept any certificate. That is the problem.

3
0
Thumb Down

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?

1
0
Silver badge

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.

2
1
Bronze badge

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.

4
9
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.

0
0
Bronze badge
Boffin

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.

1
0
Law
Happy

@ 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!). :)

0
0
Bronze badge

Re: Do no harm?

Haha, downmodding clods. Read this:

http://www.theregister.co.uk/2012/10/23/browser_botnet/

If only you were rational enough to suppress your arrogant, know-better gall just long enough to do no harm to commenter standing.

Sigh.

0
2
Silver badge

Marketplace or in the open?

The article didn't make it very clear how these apps were distributed. If it was through the marketplace then I can't help wonder if this shouldn't have been caught by quality control.

2
0
Anonymous Coward

Re: Marketplace or in the open?

What quality control

2
0

Re: Marketplace or in the open?

"an analysis of 13,500 popular free apps downloaded from Google's Play Market is presented."

2
0
Anonymous Coward

Android Apps with SSL!

For the win!!!

2
1

iOS apps

From my interpretation of this, as well as another colleague's, this is really a problem with not having proper public key pinning. This isn't limited to Android, it's just that the researchers chose to focus on Android.

3
4
Anonymous Coward

Re: iOS apps

Phew! Thank god for that. I thought it was just my bank details that were going to stolen. If it's also some other people that makes it a whole lot better.

1
1
Flame

Re: iOS apps

And if iOS apps turned out worse, Android apps would actually be relatively safe then, would't they?

1
1

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.

0
0
Bronze badge
Mushroom

Re: Android Email

But Exchange email servers won't even accept non SSL connections unless you specifically disable the default security settings...

0
2

Re: Android Email

Most novice users setting up their email themselves aren't going to be using exchange.

1
0
Joke

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

0
0
WTF?

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.

2
3
Silver badge

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.

2
2
Stop

Re: Woah...

Why would a walled garden not give me power and functionality?

You appear to be saying that only Android can handle a smartphone.

0
0

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.

0
0
Meh

Re: Woah...

"If you give developers the opportunity to shortcut, then they'll shortcut " because they have no regard for their users. Developers are greedy, lazy folk? Never!

0
0
Law
Facepalm

Re: Woah...

"If you give developers the opportunity to shortcut, then they'll shortcut regardless if it puts personal data at risk."

Contrary to your belief, most developers like to do their jobs well... I know I do.

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

3
0
Linux

After all this...

...did we end up with a blacklist of Android apps to avoid using at present?

I skimmed over the PDF but apart from the occasional mention of Facebook, Twitter, Google, et al, I found no particular apps named and shamed.

1
0
This topic is closed for new posts.