Cross Platform Tools and Security

blackhatasia15If you follow this site you will know I am not a great fan of cross platform tools. They tend to sacrifice performance and ‘look and feel’ for faster development. In cases where you can refine the look and feel, it usually becomes increasingly difficult to get screens with the correct UI idioms because most tools are based on generating html/javascript. Enterprise apps seem to be the most suitable use for cross platform tools as the look and feel of the UI tends to be less important. However, is this true?

I have recently written how anyone using app creating tools based on WebViews or using WebViews in their app needs to be aware of security vulnerabilities. Taking this further, there has been a recent presentation at BlackHat Asia 15 on ‘The nightmare behind the cross platform mobile apps dream‘.

The problem with cross platform is that it provides a uniform environment that offers up a large number of apps that can be hacked in the same way and, as it turns out, can also be more easily hacked. The presentation gives some sobering problems with Cordova, Adobe AIR and Titanium. For example, Adobe AIR’s EncryptedStorage API doesn’t do much and only stores data as Base64 encoded. Titanium’s default https is broken, doesn’t validate the SSL certificate and hence is vulnerable to Man in the Middle (MiTM) attacks.

If you are using cross platform tools then you are passing some responsibility for security to the framework. I am beginning to think platform tools are actually less suitable for Enterprise because that’s where there are usually increased security concerns.

Connection Quality Specific Downloading

Thinking about app download speeds, have you worked on a project where, having completed an app, a few people with what I call ‘intermediate quality’ connections, neither good nor bad, complain it downloads data slowly? The problem with intermediate quality connections is that they don’t complete fast and also don’t fail quickly due to not hitting timeouts. If you are downloading lots of things, slowly, the consequence of ‘only just’ not hitting http timeouts can result in the user perceiving downloads as slow.

The question then often becomes can we download different quantities or types of data for different users? Users on high end phones and good connections might be served richer data or more data at once while those with poorer connections might be served minimal or indeed no data. The problem is that it’s very hard to quantify all this and base your functionality on quantitative data.

Facebook has just made this problem a lot easier on Android because they have open sourced their Year and Connection classes. These can provide insights on how use varies with network performance and can allow you to vary functionality based on that performance.

Incidentally, Facebook have also just open sourced Fresco, a new image library for Android. Interestingly, it uses NDK (c native) memory techniques to store bitmaps, a technique I also happen to have used on a past project. I used this technique on a ‘kiosk’ single use device where it wouldn’t affect the memory available to other apps (because there weren’t any others). I am not so sure whether it’s right to use it on a general purpose device unless you carefully limit how much native memory you actually use. Jumping back to quality of connections, Fresco also provides for lazy loading of images from the network in a fast and smooth way.

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.

Android for Embedded Projects

linuxdotcom.pngThe use of Android as an embedded platform interests me as I have worked on three such projects and those projects seem to have the most potential. Embedded projects are those that use Android to power a single-purpose device where the user interacts with just one app. According to VDC Research

“Embedded products running Android will gain share over the next few years. Over the last three years, Android shipments that did not include smartphones, tablets, and E-readers grew at a CAGR of 149.2 percent, culminating in about 15 million units shipped in 2014.”

VDC say that Android is currently eating into the share of Windows Embedded rather than Linux in areas such as automotive infotainment, medical devices, military handhelds, retail and signage. However, Android isn’t currently being used in areas more typically labeled IoT such as connected home and industrial automation.

Smartphone Shipments Cause Mobilegeddon

idc.gifIDC have some new research that shows how smartphone shipments are already much larger than for desktops and laptops and how the difference is likely to become even larger in the near future.


Expect more and more companies to develop for mobile first. It also explains Google’s “Mobilegeddon” changes coming April 21 when Google will have a great search engine result shuffle based on mobile-friendliness. However, the end goal for Google is probably to be able to target mobile and non-mobile ads more effectively.

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.

Tablet Growth Has Flatlined

idc.gifIDC has new research into tablet shipments and as a result has now reduced the forecast up to 2019. Android currently remains the leader with an expected 67.4% share this year while iOS is expected to have 25.6% share. Windows trails at 7%. The following chart shows how growth has flatlined…


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.