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.

Google’s Android for Work is Insecure

androidsecuritylogo.pngThere’s a very interesting article on "Android for Work: Demystified" that dissects Android for Work and concludes it isn’t that secure. The repercussions provide some important learnings for all apps that need to handle sensitive data.

Android for Work and Android disk encryption in general, suffer from a similar expectation and affliction. The expectation is that encrypted drives protect data which isn’t fully true. The affliction is that they only protect data ‘at rest’ while the phone isn’t running. Once the phone is running the drives are seen decrypted from software and can be accessed via root or via exploits that provide access as root.

The solution to the problem is, as the article hints, to encrypt the data itself and not just rely on the drive encryption. This is the crux of the message on my Android security web site. You need to define what data needs to be kept secure and protect it appropriately. Assume your app can and will be attacked and do your best to secure only the data that has to be secured. Don’t solely rely on mobile device management (MDM), drive encryption, apk re-packaging or any other higher level wrapper.

App Security Requirements

androidsecuritylogo.pngI believe that many Android (and iOS) developers have a blind spot for app security. Clients, product owners, product managers or whoever is responsible for the app rarely have security requirements and time-starved developers tend to ignore the problem.

What’s the problem? Well, on Android (see later for iOS) there are so many ways attackers can attack your app. Whether it’s re-packaging your app with malware, repackaging to circumvent functionality, stealing ip or stealing secure data an attacker has many choices of ways to attack. Methods include:

  • Unzipping, decompilation, recompilation and re-packaging of your code
  • Patching Android OS calls at runtime to intercept data
  • Examining runtime memory to see data
  • Taking a backup of app data and reading it offline

Some of these things are possible on unrooted devices and all these things are possible via a rooted device or, more seriously, via exploits that allow temporary access as root. Determined attackers can also create custom ROMs or emulator images that can intercept your app at given points in its lifecycle.

I encourage all Android developers to do some background reading. The droidsec Wiki is a great place to start to see the scale of the problem and the tools available. Unfortunately, there’s a lot more information on how to hack than there is on how to prevent hacking presumably because it’s more fun to break things than fix them. My Android Security site offers a ‘coding first’, guideline-based approach to prevent, as opposed to detect, security problems.

If you are a product owner or product manager I suggest you also research this area, define your secure data and, if necessary, uncover security requirements for your app.

For those iOS developers thinking, "Oh that’s Android, we are safe on iOS", you might like to take a look at Lookout’s latest assessment of iOS security and my previous post on Android vs iOS security.

Cryptographic Vulnerabilities in Android Applications

fireeye.pngFireEye has some new research that has found that of the free apps with over a million downloads, 88% use some cryptographic functionality provided by the Android platform and 62% of these have cryptographic vulnerabilities. What this means is that while the authors and the end users of these apps might think data is secure, it’s easier to decrypt the data that they would expect.

There seems to be trend at the moment for researchers to spot vulnerabilities, on all platforms, but not really explain how developers can prevent or fix such problems. Many of the cryptographic concepts are beyond all but the most experienced (or highly curious) developers. While developers of highly secure apps might have the time to look deeply into encryption, the average casual developer needs examples or libraries on which they can base their work.

As it happens, a library java-aes-crypto became available this week that’s a simple Android class for encrypting and decrypting strings, aiming to avoid the classic mistakes. There are also more libraries mentioned in my article on Encrypting Your Sensitive Data. I also have tips on Taking Care with Encryption. You might also like to read Tozny’s post on Making Better Mistakes 

Security Incentive For Device Upgrade

android.gifTwo Android security problems have hit the news over the last few days. The first is a problem with java.io.ObjectInputStream on ALL devices prior to Lollipop. It’s not a problem in itself in that the user needs to somehow accidentally install a malicious app. The second is one such app, NotCompatible, that has been around a long time but has recently made the news due to some posts on popular sites.

The thing is, the user has to actually say yes to downloading and installing an app when they are web browsing. A bigger question is why Android’s anti-malware tool, Bouncer, hasn’t detected this side-loaded app. I suspect it has. Bouncer has only worked on side-loaded apps since Android 4.2 and I suspect the majority of infected devices use earlier versions of Android.

The best defence is probably to only use devices running Lollipop. As I have previously observed, in some ways it’s odd that one of Android’s failings, that of slow or non-existent OEM OS upgrades, might cause more people to buy a new device to be on a more secure Android version, which, in turn, will reduce OS fragmentation to the benefit of the platform.

WebView Unbundling

arstechnica.gifThere’s an interesting post on ars technica on "Unwrapping Lollipop" talking to "high ranking members of the Android team" about changes to the OS. It includes a very useful breakdown of what’s now in the Android OS, what’s in Play services and what’s distributed via the Play Store.

lollipopunbundling.png 

Of particular interest is that WebView has been unbundled and now comes from the Play Store. The idea is to be able to more-easily (auto) update WebView for performance and security reasons. However, this won’t be for pre-Lollipop devices. In the near-term, there will still be a large number of old devices on old and varied versions of WebView. Also, unbundling has the side-effect that, going forward, non-Google sanctioned, AOSP-derived devices won’t have the latest WebView. Google will obviously care less about this but it will affect the 20% of developers on those platforms.

Android Binder Subversion

androidsecuritylogo.pngSome of the vulnerabilities in Android allow code to be run as root. Alternatively, if users root their device malware can already run as root. However, what can such code then do?

Nitay Artenstein and Idan Revivo of Checkpoint Research have a new presentation and white paper on how intercepting IPC, via the Android Binder, can be used to provide for keylogging, location tracking and intercepting SMS. Indeed, even sending data from one Activity to the next uses IPC and this can be intercepted.

What can Android developers do about this? Well, if you are handling sensitive information you should consider encrypting data before sending it, to/from, for example, a Service or another Activity. The paper also describes how Android’s keyboard also uses Binder and security sensitive apps should have their own keyboard implemented within the app. I have updated my Android Security site to reflect this information.