Forgot your password?
typodupeerror
Android Cellphones Encryption Handhelds Networking Privacy Security Software IT

Poor SSL Implementations Leave Many Android Apps Vulnerable 141

Posted by timothy
from the that's-why-they-buy-guns dept.
Trailrunner7 writes "There are thousands of apps in the Google Play mobile market that contain serious mistakes in the way that SSL/TLS is implemented, leaving them vulnerable to man-in-the-middle attacks that could compromise sensitive user data such as banking credentials, credit card numbers and other information. Researchers from a pair of German universities conducted a detailed analysis of thousands of Android apps and found that better than 15 percent of those apps had weak or bad SSL implementations. The researchers conducted a detailed study of 13,500 of the more popular free apps on Google Play, the official Android app store, looking at the SSL/TLS implementations in them and trying to determine how complete and effective those implementations are. What they found is that more than 1,000 of the apps have serious problems with their SSL implementations that make them vulnerable to MITM attacks, a common technique used by attackers to intercept wireless data traffic. In its research, the team was able to intercept sensitive user data from these apps, including credit card numbers, bank account information, PayPal credentials and social network credentials."
This discussion has been archived. No new comments can be posted.

Poor SSL Implementations Leave Many Android Apps Vulnerable

Comments Filter:
  • A question (Score:5, Interesting)

    by Chrisq (894406) on Saturday October 20, 2012 @08:31AM (#41714011)
    The article says:

    Researchers from a pair of German universities conducted a detailed analysis of thousands of Android apps and found that better than 15 percent of those apps had weak or bad SSL implementations.

    I would have thought that an SSL implementation, complete with certificate chain validation would be provided by the OS, and that apps would use that. Only apps that had special requirements should have to implement SSL. Does anyone know if android does provide a TLS interface, and if so are the apps ignoring the platform service?

    • by Kagetsuki (1620613) on Saturday October 20, 2012 @08:44AM (#41714049)

      I myself have implemented them for shopping apps (SSL for anything dealing with user details, payment, etc.). When you're communicating with an external service that requires (or where you want to use) encrypted connections and that service only offers SSL (this is probably 90% of the time) you need to use it. Now the catch here is that the standard SSL handlers available to you in Android provide an "ideal" setup, where servers and certs are exactly as they "should" be. The problem is unless you are paying rediculous ammounts for dedicated SSL services and high quality certs your setup will not be the "ideal", and you'll have to make exceptions by overriding code.

      As an example, in the shopping system I set up there were two sets of certs, one set was signed [payment gateway] the other wasn't [user control pannel]. I had to jump through a few hoops, and the app would be open for man-in-the-middle if set up right - but luckilly all they'd get would be user login details, address and phone number - billing is all external and requires a separate authorization.

      • by Anonymous Coward on Saturday October 20, 2012 @08:46AM (#41714063)
        If one can't afford a certificate for from a typically trusted CA (and it's not much for one for ordinary e-commerce use cases) then one probably shouldn't be handling PII.
        • by dbIII (701233) on Saturday October 20, 2012 @09:13AM (#41714163)
          Tell that to what seems like 9/10 of the sites on the net, expired certs seem to be more common than current ones.
          • Re: (Score:2, Insightful)

            by Anonymous Coward

            expired certs seem to be more common than current ones.

            That's because cert expiry is a money-making scam by the CAs.

            There is no reason a cert should expire. It should be revoked if compromised, but there is no reason for it to "expire" other than generating annual subscriptions.

            • There is no reason a cert should expire. It should be revoked if compromised

              As with most perceived fallacies, certificate expiry and password expiry arise from a heuristic. An older certificate or password is more likely to have been silently compromised than a newer certificate or password.

              • by the_B0fh (208483)

                and that's why my password is a 2048 character password that changes every other second, because, SECURITY!!!!

          • Funny, I almost never see an expired cert in my day to day browsing. I pay for a cert every year for my mail server, its not expensive and its well worth it.

        • by Anonymous Coward

          You are correct on common use cases. But what if you need a cert from an atypical CA (EG government approved CA within your own country - this is an actual issue), or what if you need a special cert like: wildcards, shared-cert, multi-domain, special schemes, certs certified by external bodies or specific organizations.

          And f* if I WANT to be handling security, I wish I could just set some flag on the server and on the client to true and it would magically be secure. I don't want to mess with certificates. I

          • by Alan Shutko (5101)

            Programming is HARD! Let's go shopping!

        • by tepples (727027) <tepples AT gmail DOT com> on Saturday October 20, 2012 @12:03PM (#41714813) Homepage Journal
          The problem does not always lie in the certificate. It also lies in the fact that the SSL clients built into Windows NT 5.1 (XP) Android 2.3 (Gingerbread) does not support Server Name Indication (SNI), which allows multiple certificates on one IP address. This lack of support for SNI was not corrected until Windows NT 6 (Vista) on PCs, Android 3.0 (Honeycomb) on tablets, or Android 4.0 (ICS) on phones and pocket tablets. Without SNI and without DNSSEC, each site using SSL needs its own IP address.
          • by KZigurs (638781)

            What does it matter if 70% of android phones sold doesn't include even current root CAs of the recognised authorities. Not even touching on the subject of what makes them 'trusted'

          • Hm. I have not played with certificates and such for a while; however, I am pretty sure that IP addresses are irrelevant. IIRC, the DNS needs to match the CN (CN == Common Name field in the certificate). If an otherwise valid certificate is used on a site with a DNS CN mismatch, then there is an error. The IP address can change randomly as long as the DNS resolves correctly.

            • by cmdrbuzz (681767)

              Without SNI you can only have one certificate per IP address as the certificate is sent to the client before the client can send the Host: header to indicate which site he is trying to access.

              The only way around this (apart from using SNI) is either wildcard certs or SAN attributes.

              Once the server has sent the certificate the client will check to see if the certificate matches the DNS name it is attempting to access (either CN or SAN), however this is done by the client without the server knowing which DNS

        • by KZigurs (638781)

          With android a common problem is which CAs are recognised, which versions of their root certs and which operators have decided to fuck up the cert chain due to political reasons.

          Also - whether webview in applications support the same cert chains that browsers do or subset at mercy of 3 year old out of date build.

          So yeah, as far as I'm concerned the SSL on android is generally useless. Due to SSL being unusable in real world more so than due to 'lazy devs'.

      • by Anonymous Coward

        And note that this isn't an Android vulnerability. Those MITM attacks are possible because of poor coding! Developers can use own-signed certificates and that's fine, the problem is that when they override code to make SSL checks more permissive they allow ANY self signed certificates and not only the one they are using!

        • by dgatwood (11270) on Saturday October 20, 2012 @01:43PM (#41715539) Journal

          Yes, it is a common mistake. That's why Apple has told people not to do what you're describing at pretty much every WWDC networking talk for as far back as I can remember, and devoted an entire chapter [apple.com] in their networking documentation to that subject.

          I'm not seeing anything like the above in the Android documentation, which may explain why this is a much more common problem on that platform. And pretty much all the sample code I see on places like Stack Overflow and GitHub are wrong, which further compounds the problem. Want this problem to go away? Go to all those Stack Overflow pages and GitHub pages and flag them as inappropriate. Then convince someone to document how to do it the *right* way.

          • by KZigurs (638781)

            Fix the way Android threats CA's first, then speak.*

            *subject to whims of operator, out-of-date root CA's, sets of devices support one CA, sets - somebody else (and I'm talking here about the support of first name operators).

            • by dgatwood (11270)

              That problem can be fixed with the same technique that you *should* be using if you're working with self-signed certs—either hard-code your CA cert into your app and override the method that returns the list of trusted anchors to return the system set plus your own or set up a trust store that indicates trust for that anchor.

              Or if you're really paranoid, hard-code a list of CA certs that you trust, which may only partially overlap with the system-provided set.

      • Re: (Score:1, Insightful)

        by Anonymous Coward

        Is it me or does that post make it sound like parent poster shouldn't be allowed to use secure communications, much less code them?

        I wish there was a "scary as fuck" mod but I don't know if it should count +1 or -1.

        • by Xugumad (39311)

          It scares me, anyway.

          At the same time, I'm aware from a practical point of view very few people understand these tools, and that very very few companies using SSL have done so through anyone who understands how to ensure it's done correctly (understanding entropy sources, ensuring keys are created with the correct access permissions where applicable, etc.), so it's not really a new scary thing.

          • Well put, and in my own defense at least I knew the setup was not how it should be and I made that clear, and that in the future if the app was to be worked on that is one thing that should be focused on. Particularly when it comes to testing I'd bet the vast majority of developers [to be honest, myself included] really know how to test for all common threat scenarios.

          • Let me tell you the story about the guy who wanted to use oauth2 bearer tokens over an unsecured connection.
        • Hey I'm totally aware it's "wrong" and I would have loved to have done it properly, but this was a little shop with few users, limited cash (including to pay for implementation of the app) and an irregular setup. I just wanted to be done, the owner didn't care, so I kludged it and went on my way. The thing is a lot of setups end up like this and the fact that so many setups aren't the "ideal" and SSL is in a way complex by design (though setup now on things like nginx is cake!) I think a lot of things just

          • by tqk (413719)

            I just wanted to be done, the owner didn't care, so I kludged it and went on my way. The thing is a lot of setups end up like this and the fact that so many setups aren't the "ideal" and SSL is in a way complex by design ... I think a lot of things just end up being kludged and will remain broken [until] something bad happens.

            That methodology is giving the rest of us a bad name. That sort of execution is why I left Windows. It would be better not to do it if the only way you can get it done is to kludge it. Your employer/client is not the only one whose dick will be hanging out in the wind if you get it wrong. His customers' will be too.

            Thanks a lot.

          • Translation: I just wanted to take the money and run. Making money, that was the important thing. Yeah, money. Did I mention I needed the money?
            • Actually I didn't want to deal with the client. It was a job nobody else was taking, but a friend of a friend, and when I made it clear there was an SSL issue he just said to make it work and he didn't care. In order to make it work their in-house dev would have had to set things up serverside to do so and I don't think I could have ever gotten him to do it right anyway.

              And the pay was awful, I pretty much lost money on it.

              • Next time say, "I'm sorry, I'm a professional software developer, and I have to follow certain principles, same as a doctor or lawyer must follow their respective professional codes. Please contact me when your server side is properly configured and I will be able to complete the work."
      • by sithlord2 (261932) on Saturday October 20, 2012 @08:56AM (#41714109)
        What do you define as rediculous amount of money? I pay 50 USD/year for a signed ssl certificate. My SSL setup scores an "A" on the SSLLab test.

        With those prices today, I cannot find one argument in favor of a self-signed certificate. Especially not if you are using it in a commercial product. Get a cheap signed certificate and use the SSL framework on your platform in the way it is intended.

        I do hope the example you mentioned occured somewhere in the nineties or so, when ssl certs were indeed still expensive.
        • by Kagetsuki (1620613) on Saturday October 20, 2012 @09:21AM (#41714187)

          Cert price all depends on the type of cert. You're talking about a standard SSL cert, which in the case I outlined would have actually been OK but it would have required some extra setup (dynamic subdomains) and the client just didn't want to deal with it. Justa heads up in certain situations (eg: corporate certs + internationalized domains + multiple sub domains + weird proprietary auth crap for odd protocols + a badge that says the cert passes some standards body tests....) the cheapest possible cert will run well over $1,000.

          BTW I really recommend StartSSL https://www.startssl.com/ [startssl.com] if you are using standard certs. The prices (free for personal certs/low end schemes, unlimited plans for more robust and corporate certs). Service and support is also pretty good.

          • by Anonymous Coward

            Cert price all depends on the type of cert. You're talking about a standard SSL cert, which in the case I outlined would have actually been OK but it would have required some extra setup (dynamic subdomains) and the client just didn't want to deal with it. Justa heads up in certain situations (eg: corporate certs + internationalized domains + multiple sub domains + weird proprietary auth crap for odd protocols + a badge that says the cert passes some standards body tests....) the cheapest possible cert will run well over $1,000.

            BTW I really recommend StartSSL https://www.startssl.com/ [startssl.com] if you are using standard certs. The prices (free for personal certs/low end schemes, unlimited plans for more robust and corporate certs). Service and support is also pretty good.

            $1000?

            That's what? Somewhere between 5 and 10 hours of developer time in the US and Europe - counting all overhead costs? And 10 hours is a CHEAP and presumably not very good developer, FWIW....

            What the fuck is it with companies not willing to spend a few thousand dollars on buying an industry-standard solution that works, but are willing to throw hundreds of man-hours that cost a helluva lot more money at creating their own crappy solution?

            • What the fuck is it with companies not willing to spend a few thousand dollars on buying an industry-standard solution that works

              Might some of these companies be micro-ISVs, built with sweat equity and run out of a residence until they grow large enough to become able to afford a dedicated office, employees, and all the other overheads of a "proper company"?

              • They might be, but then who in their right mind would trust that kind of party with their money and PII? In choosing how to spend their limited cash, they forgo proper security precautions, and they want users to trust them not to misuse or misplace sensitive information?
                • by tepples (727027)
                  Without customers who provide money, how else is a micro-ISV supposed to grow into a proper established business? I need the answer for my own business plan.
            • It slightly above what a developer makes per month in some countries. US/Europe isn't the entire world, you know.

        • by DarkOx (621550) on Saturday October 20, 2012 @09:40AM (#41714233) Journal

          I am not sure I agree. There is nothing stronger than self signed certificates, with the public certificate distributed out of band.

          For b2b sites, corporate client vpns, personal remote access and such this is ideal, it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise. If A wants an encrypted channel with B, if A and B can swap usb keys with each other containing their self signed certs; and they then go back and put those certs in their trust stores there is no way anyone can impersonate B to A or A to B without A or B being responsible for leaking a private key.

          Obviously this only works for entities with long lived relationships, and enough value in what is being secured to make the effort worth while. Still its actually a much more secure route than a third party CA for any situation where its reasonable.

          • it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise

            Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".

            If Alice and Bob trust each other, this is OK, but what if Bob is bumbling idiot? What about when Alice and Bob, who trust each other, tell Mallory to trust them to trust each other, and Carol mistakenly trusts Mallory?

            • by Pieroxy (222434)

              it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise

              Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".

              If Alice and Bob trust each other, this is OK, but what if Bob is bumbling idiot? What about when Alice and Bob, who trust each other, tell Mallory to trust them to trust each other, and Carol mistakenly trusts Mallory?

              I don't know about that, but can you tell me if Bob makes out with Carol in the end?

            • by dkf (304284)

              Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".

              Operationally, a private CA works at least as well and provides an equivalent level of trust. The advantage is that the CA's private credentials can be kept offline in a safe most of the time, so they're much harder to lose, yet you don't need to futz around with adjusting clients so much when you create a new server certificate for operational use.

              • That's not wrong, but it still doesn't explain to me why I, as a user, should trust both application A and site B that have agreed to trust each other with a self-signed certificate. The reason was have the CA model is to introduce a trusted third-party* that can verify for us that everything is on the up-and-up. The user should not be in the position of having to trust unknown parties.

                *Yes I know the CA companies have problems. Maybe the model is so broken by nature that it doesn't matter, but it's still

        • by multi io (640409)

          What do you define as rediculous amount of money? I pay 50 USD/year for a signed ssl certificate.

          ...and the great thing is: Someone else probably wouldn't pay much more for a signed SSL certificate that says it's yours. :-P

          • by sithlord2 (261932)

            Really? I had to verify by e-mail, sms, and phone for my cheap cert. If you can get a valid signed certificate for my domain at that price without my approval, please contact me. I'm eager to test this. But somehow I doubt that any cheap ssl registrar will issue a signed certificate without at least an email verification of the domain-holder himself. But feel free to prove me wrong.

            Nevertheless a signed certificate protects you against 95% of all MTM attacks.
        • I pay 50 USD/year for a signed ssl certificate.

          How much on top of this do you pay for the dedicated IPv4 address to host the site on which you use the certificate? Or is your Android application exclusive to Android 3 and 4, whose native SSL stack supports Server Name Indication, as opposed to Android 2.x, whose native SSL stack does not?

          I do hope the example you mentioned occured somewhere in the nineties or so, when ssl certs were indeed still expensive.

          In the 1990s, SSL certificates were expensive and IPv4 addresses cheap. In the 2010s, it's the other way around.

        • With those prices today, I cannot find one argument in favor of a self-signed certificate.

          I can. Trust. I do not trust -any- of the commercial registrars and neither should you. We have seen all sorts of crazy antics where they delegate trust and shenanigans happen. Of course, you are welcome to trust them if you wish. :)

          I use SSL as if it were PGP. I like the encryption and I like the non-repudiation. I also appreciate the capability to set up an infrastructure of trust but I have not seriously set up any such infrastructure yet.

      • by DarkOx (621550)

        To me it still sounds like you are doing it wrong. I assume the control panel is something that only a limited number of people need? Why can't those folks just add the self signed certificate to the trust store?

        • It was a control panel for customer managment and the root of the problem was the server setup which I wasn't responsible for. Their in-house dev was an idiot who wasted his time writing an overly complex system and the client was a disagreeable cheepskate with a stupid shop that sold crap. I only took the job as a favor, it ate more time then I could bill hours, and I made it clear it was broken and they should do something about it.

      • à_à [asciifacepalm.com]
        This is why we can't have nice things.
      • The problem is unless you are paying rediculous ammounts for dedicated SSL services and high quality certs your setup will not be the "ideal", and you'll have to make exceptions by overriding code.

        Oh bullshit you are just trying to justify your own laziness.

        If you don't want to pay for an SSL cert there is nothing stopping you from using a self signed cert and embedding the public key in your application..also see RFC 2817 for virtual hosts.

        I will say overall it does sound like more of a case of giving developers copious amounts of rope to hang themselves in much the same way PHP encouraged certain behaviors leading to rampant SQL injection vulnerabilities.

        I know technically it may not be the platfor

        • I wasn't the only factor here (the serverside deve was a different person unrelated to me) and in this case it was an internationalized domain that needed subdomain wildcards and a corporate cert. Find me one of those for $50 and I'll love you forever.

          But you are damn right about SSL giving devs rope to hang themselves with. There are so many places to create holes in the system, and if your implementation scenario has one exception you need to make [not a "common usage scenario"] things get real messy real

    • by Chrisq (894406) on Saturday October 20, 2012 @08:53AM (#41714083)

      I have now read the article and it is apps misuse the APIS. They search for apps that either don't use the TLS APIs but have ssl addresses encoded, or which use a non-default trust manager. When you establish an SSL connection via the normal Java APIs the default trust manager does check the validity of the certificates (i.e. that tey are signed by a trusted CA) and that the URL requested matches the hostname in the certificate's subject DN. There can be valid reasons for overriding this, including using your own specific certificate rather than any signed by a CA, or for development to allow self-signed certificates - though this should be put in production.

      They found that a lot of apps had overridden the rust manager in a dangerous way, allowing self-signed certificates in production or allowing any certificate even if id didn't match the host.

      Though this is a problem it is not an "android issue". You can write apps that use self-signed certificates, bypass host checking etc. on Windows and any platform that allows you to customise certificate trust checking.

      • Presumably you can write them for iOS, and I have no doubt that there are plenty of apps on the AppStore that are playing fast and loose with SSL trust managers.

        True fact: I have written Java code to allow for self-signed or any old cert over SSL, or even none. It's not hard to find plenty of sample code [stackoverflow.com]. In the course of my employment the code was used for testing only and either not part of a production build or disabled by default in production, but I cannot say what other developers or teams may have

    • by cfriedt (1189527)
      The OpenSSL libraries in Android are in the /system partition, and hence, can be patched via OTA update. So yes, they are provided by the OS. And unless the API has changed for OpenSSL (likely not), all Android apps require no modification to be considered secure after said OTA update. Rather than attempting to discourage Android app developers, the linked article really should just be putting pressure on Google, OHA members, and carriers to release OTA updates that include a patch to OpenSSL.
    • by Anonymous Coward

      You should read the following paper. It covers exactly your question and is from the same ACM CCS conference that just ended in Raleigh, NC. Personally, having listened to both talks, this was in my opinion more alarming:

      http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

    • While I'm no expert on Android, I am a developer and I have worked on a pretty major Android app. We found that Android 2.2 and earlier had some bugs in the version of HTTPClient that Android uses, and this bug caused certs from one particular root authority (Verisign, IIRC) to fail. It was a major problem. It was a while ago now, but I think the work-around we went for was to effectively enable untrusted CAs on 2.2 clients. I can happily believe that the apps being talked about here, those with weak SSL, w

  • Do Android users have confidence in their security? Do they even think about it?

    • Re: (Score:2, Insightful)

      by amiga3D (567632)

      I would never consider using an Android phone for any banking access. Never.

      • I would not use $RANDOM_SHOPPING_BANKING_APP, but I would visit a bank website using chrome, firefox, or the built-in android browsers. Those three programs, while undoubtedly not flawless, at least have enough respectability and history for me to trust them as well as anything on the internet. Admittedly, that's not much trust, but it's something.
      • by tepples (727027)
        Do you consider paying for paid applications through Google Play Store or Amazon Appstore to constitute "banking access"?
        • by the_B0fh (208483)

          Please don't make the punters think too hard. Their heads may explode.

        • by amiga3D (567632)

          frankly I haven't seen anything in google playstore enough better than the free stuff to actually pay money for.

          • So what free music and free movies do you recommend as substitutes for those from Google? Or do you happen to live in a country where record labels and movie studios have chosen not to license their works to Google, and your version of the store has only apps or only apps and books?
  • The thing I love about this industry is that with every new platform, every generation of programmers manages to make errors that were made - and fixed - by a previous generation or on a previous platform. And it's an industry that aggressively weeds out experience - which is uniquely dysfunctional.

    Credit card issuers and processors need to come down on this like a ton of bricks. Losing your access to a card network or losing your merchant agreement would probably be a powerful incentive.

  • One of the reasons this problem exists is there are no guidelines as to exactly how to present this problem to the user.

    The user can't do anything about the problem - but they have to be told that their transaction (whatever it is) has failed or cannot be completed.

    I suspect that on a PC, most people have no idea what that "certificate problem" dialog box means. As far as they're concerned, it's a useless error that happened on the way to their online banking session.

    On mobile, it's even worse. You're using

    • by mveloso (325617)

      And another thing: why don't browsers show you the problem on the screen? They just have a "show certificate" button, and they let you figure out what the heck is wrong. Most people won't have any idea why a given certificate didn't pass validation. Here's a short list that browser makers can use:

      1. The server name doesn't match the name on the certificate (common).
      Insecurity risk: low.
      Action: Highlight the hostname in the URL and the hostname on the destination server.
      User Suggestion: contact the server ad

  • a good 'how to use ssl safely' tutorial? I guess that's the real question. It seems to me something as common as this should be well documented/implemented. I mean, google wrapped SQL for me. Heck, google's code let me get a rudimentary spend tracker [glimmersoft.com] written in under 6 hours and my silly little mirroring app [google.com] in under 4. Their APIs are so simple and well organized that it brings computing back to the age when I write the apps I want, like coding Basic for my C64.

    Probably the problem is google can't imple
  • Hi techie guys, 'normal' non-super techie guy here, and I've been reading all your posts about certificates & the lack of security and all, and I do have a question....

    Can you guys all get together on this and FIX IT??!!! WTF??! I thought you all were SUPPOSED TO KNOW how to make financial transactions secure! Sounds like everyone's passing the buck (no pun intended) here, blaming it all on somebody else's bad coding. That's not a reasonable excuse for a user's banking activity to be left so open.

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Working...