Android SSL Vulnerabilities: Lessons for CISOs
We recently published a blog reporting a variety of issues with a set of security capabilities found in commonly used Android applications in the Google Play store. These capabilities frequently come from security configurations baked into the ad libraries that developers use to display ads in their apps and don't want to develop themselves. This is a laudable practice (implementing things like encryption protocols is hard and should be avoided by most software engineers), but it means that a flaw in a single library can impact thousands of apps downloaded by billions of users.
So what? Well, for starters, the most common flaws we found expose users of vulnerable applications to man-in-the-middle attacks. Basically, that boils down to this: if you're using a vulnerable application on a network where someone can intercept your communications (use the wireless at your favorite coffee shop recently?) you could be exposed. If you want the gory details you can get them in this post /content/fireeye-www/global/en/www/blog/threat-research/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html.
The exec-level view boils down to the below:
- Any data you receive or send via these vulnerable applications could be intercepted, such as usernames, passwords or other data you might want to keep private.
- An attacker could use their ability to intercept these communications to exploit other vulnerabilities and potentially attempt to steal *other* data from you or gain control of the device.
- We did a random sampling and found a plethora of these vulnerabilities – vulnerabilities that would be fairly trivial to exploit. In some cases fundamentally simple aspects of security protocols designed to protect data in transit have been ignored. The likelihood someone can...and is...using these vulnerabilities to attack mobile users is high. That means the likelihood your corporate IT users have devices that are exposed is also high.
Again, so what? Perhaps you're using an MDM (or other security solution) that implements containers for your enterprise sensitive data for exactly this reason. You understand the mobile ecosystem and anticipated this exposure – particularly if your enterprise lets employees bring their own mobile device. A few parting thoughts on why you should still care:
- Critical apps you use for your enterprise *may also be vulnerable.* You want to know if that's the case. If they are vulnerable a 'containerization' solution won't prevent an attack.
- While you may have applications that are 'blessed' as mobile enterprise apps, the reality is your users are probably using other non-enterprise apps to get work functions done (Evernote anyone? How about Dropbox?). If one of those applications has issues you similarly are going to want to know. Having risks is a reality...it's the unknown risks that kill you. Oh - a quick note, I am *not* implying we found Evernote or Dropbox issues...I'm just making the point that 'Shadow IT' is out there and likely here to stay. You need to manage this exposure.
- Lastly, if you are using a mobile enterprise 'container' solution, there is the possibility that given sufficient access to a device, an attacker could exploit some vulnerability in the container to get at critical enterprise data. You are increasing this risk if you have other non-enterprise applications that are vulnerable to main-in-the-middle attacks on your users' devices.
My recommendation is simple: via a process, technology, or both, identify mechanisms to rate this risk so you *at least* have awareness, if not a complete remediation plan.