SSL on Mobile is Still a Problem

securityintelligenceSecurity Intelligence has an article on ‘Cracks in the Digital Foundation of the Internet Crumbling the Core‘ based on IBM’s X-Force Threat Intelligence Quarterly.

The mobile part of the article mentions the CERT Tapioca tool that allows investigation of man-in-the-middle (MITM) attacks due to apps not correctly validating SSL certificates. This has produced 9,200 new app security vulnerabilities affecting over 2,600 unique vendors.

The article mentions “the unusual apathy mobile app developers seem to be displaying, leaving important banking applications vulnerable to critical disclosures” and “Despite warnings, 10 of the 17 banking applications tracked (59 percent) were still vulnerable four months later”.

Read more technical information on how to check for security exceptions, verify the SSL Certificate Hostname and SSL pinning.

CERT Vulnerable Android App Naming and Shaming

cert.pngI have previously written (here, here, here, and here) about Android apps that fail to validate SSL certificates. CERT has started to name and shame libraries and apps that their Tapioca tool has detected to be vulnerable to Man In The Middle (MITM) SSL attacks. There’s a blog post on how they have automated the analysis, a vulnerability note explaining the problem and a large spreadsheet of vulnerable libraries and apps.

Libraries that have been found to be vulnerable are Flurry, Chartboost, Adcolony, MoMinis, Inmobi, Tapjoy, Appsflyer, Gameloft, Zopim, Fiksu and Batch of which only the first two, Flurry and Chartboost are noted as fixed.

CERT are testing one app at a time so progress is slow. Nevertheless, over 1000 apps are listed as having failed. However, some of these failed because of the included vulnerable libraries.

If you think this is just an Android specific problem then you might like to consider that Veracode previously found 7% of Android apps and 33% of iOS apps had cryptographic problems. Developers can be inexperienced or lazy on both platforms.

Listening in on Android Apps

fireeye.pngFireEye has a new post on Android man in the middle (MITM) vulnerabilities on Android. While it covers Android, the coding flaws are just as applicable to iOS. FireEye found that 68% of 1000 most downloaded apps had one of three SSL vulnerabilities. For the avoidance of doubt, these are vulnerabilities introduced through app coding, not vulnerabilities in the Android OS. FireEye also found that of a random sample of 10,000 free apps, 40% used trust managers that didn’t check server certificates.

androidsslvulnerabilities.png

Even if you have coded your own app correctly, there’s the possibility that an included library has a vulnerability. For example, Flurry, up to v3.4, had such a vulnerability.

If you need further guidance, take a look at my security site:

There’s also a follow up FireEye article on why these issues are also applicable to enterprises, even when they are using a mobile device management (MDM) solution that silos apps.

Secure Apps

penrillian.gifSecurity is becoming more and more important. What with the latest SSL vulnerabilities, NSA/Snowden/GCHQ, user privacy concerns and more sophisticated malware, mobile app developers continually need to put more effort into app security. There’s a particular class of apps, for example banking and payment, that must be as secure as possible. I recently came across a great white paper, Secure Development Process (pdf), by Penrillian that nicely defines these ‘secure projects’ as…
“Projects where someone could get significant benefit illegitimately from a security weakness in the deliverables”

If you are developing an app such as this then you would do well to take a deep look at Penrillian’s recommendations.

penrilliansecureprojects.png

I suspect as mobile becomes ever more pervasive, some of these process areas might become standard for a greater proportion of apps and not just ‘secure apps’.

Android SSL Certificate Pinning

android.gifI have previously written about SSL and man in the middle (MITM) attacks and Banking Apps Leaking Information. A common theme is not properly checking SSL authenticity.

Secure (e.g. banking) apps can implement SSL Pinning that restricts what certificate(s) the app considers valid. This involves hard coding one or more specific certificate chains into the app. There’s a working Android library by moxie and example project by ikust. As an aside, as well as being more secure, this also allows you to use a self-signed SSL cert that costs nothing and avoids the considerable red tape associated with applying for a non-self-signed certificate.

Android also introduced system wide pinning in 4.2 but this isn’t suitable for most apps that need to support earlier Android versions.

You also need to be aware that it’s possible to bypass SSL Pinning (pdf). However, this requires the app to be reverse engineered, re-constructed and re-run that’s very unlikely to ever be possible ‘on the fly’ (at least on unlocked devices) as a random user gets hit by a MITM attack.

Banking Apps Leaking Information

ioactive.pngThere’s a new informative article at IOActive on how personal banking apps leak information. While the article concentrates on banking apps and iOS, the information is just as applicable to other types of apps and other mobile operating systems such as Android.

Ariel Sanchez of IOActive Labs took a look at 40 banking apps from the top banks in the world. Tests included SSL (session handling, valid certs), compiler protection, use of webviews, use of SQLite as well as anti-tampering analysis.

ioactivebankingvulnerabilities.png

The analysis is very alarming. Put simply, banking apps, that should be more secure than most other apps, can’t be trusted.

However, security isn’t just for banking apps. Snapchat is a very recent example of an app exposing 4.6 million users’ usernames and phone numbers. Poor security can damage your reputation. So what can you do? IOActive gives some pointers…

  • Ensure that all connections are performed using secure transfer protocols
  • Enforce SSL certificate checks by the client application
  • Protect sensitive data stored on the client-side by encrypting it using the iOS data protection API
  • Improve additional checks to detect jailbroken devices
  • Obfuscate the assembly code and use anti-debugging tricks to slow the progress of attackers when they try to reverse engineer the binary
  • Remove all debugging statements and symbols
  • Remove all development information from the production application
I have covered many of these areas in previous posts…

SSL Apps Vulnerable to Attack

padlockicon.pngResearchers from two German Universities have examined 13,500 popular free apps downloaded from Google’s Play Market and have found that 1,074 (8.0%) have sensitive information such as log-in credentials and personal information/files that are vulnerable to attack.

Apps such as those from American Express, Diners Club, Paypal, bank accounts, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, remote control servers, arbitrary email accounts, and IBM Sametime have been singled out as being vulnerable.

The paper (pdf) explains how poor coding, when using the SSL protocol, has allowed apps to become susceptible to Man-in-the-Middle (MITM) attacks.

MITM is where, for example, a rogue WiFi access point seems to provide access to a remote secure server but instead, reads the data before passing it on to the legitimate server. The paper explains various ways how apps have allowed connection to secure servers without properly checking their authenticity.

This is yet another example of security vulnerabilities brought on by poor coding. However, in many cases it’s not just the developers’ fault. Only last week I was in a workshop where I commented how mobile apps seem to bypass traditional company processes. Software processes, procedures and safeguards seem to get forgotten when it comes to mobile. This, together with the relative lack of experience of many new mobile developers is lowering not just the security but also the quality of apps.

For example, who would believe that large financial organisations would release consumer apps without a deep security code review? It’s happening.

 A few more things…
  • This isn’t just an Android issue. It’s how SSL is being used that is at fault and I expect this is as much an issue on other platforms.
  • Validating SSL certificates has always been tricky on mobile due to the variation of root certificates installed on different devices. Instead of ignoring non-validation, apps should warn the user in the cases where a connection is potentially insecure.
  • This has absolutely nothing to do with Android in-built browser which researchers found is exemplary in its use of SSL.