Slashdot Mirror

← Back to Stories (view on slashdot.org)

Poor SSL Implementations Leave Many Android Apps Vulnerable

Posted by timothy on 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."

11 of 141 comments (clear)

  1. A question by Chrisq · · Score: 5, Interesting
    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?

  2. A lot of apps use SSL by Kagetsuki · · Score: 5, Insightful

    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.

    1. Re:A lot of apps use SSL by Anonymous Coward · · Score: 4, Insightful

      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.

    2. Re:A lot of apps use SSL by sithlord2 · · Score: 5, Insightful

      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.

      --
      ...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
    3. Re:A lot of apps use SSL by dbIII · · Score: 3, Interesting

      Tell that to what seems like 9/10 of the sites on the net, expired certs seem to be more common than current ones.

    4. Re:A lot of apps use SSL by Kagetsuki · · Score: 3, Informative

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

    5. Re:A lot of apps use SSL by DarkOx · · Score: 3, Insightful

      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.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    6. Re:A lot of apps use SSL by dgatwood · · Score: 3, Insightful

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

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

  3. Re:Android continues to be security disaster by Anonymous Coward · · Score: 4, Insightful

    This is not a platform problem, this is a matter of the choices made by application developers. I can guarantee this same sort of analysis would fail a similar number of apps across the board for Windows, OSX, or *any* platform with a sufficient number of applications making use of SSL sockets. I know the sort of developers that do this and they'll do it *everywhere*, because of some mix of not quite understanding the point of the CA and the hassle they perceive in trying to find a way to do it right (admittedly, the logistics of doing it right in certain scenarios is daunting and necessarily puts work on the enduser if you want to be truly secure).

  4. I have now read the article and it is apps misuse by Chrisq · · Score: 4, Informative

    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.

  5. The certificate is not the problem; IPv4 is by tepples · · Score: 4, Informative

    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.