There’s an extremely long, sometimes entertaining, sometimes boring article The Kernel of the Argument at the Washington Post on insecurity of the Linux Kernel.
The gist of the article is that Linus Torvalds has personally managed the Linux kernel since its creation in 1991 and has had little interest in making it more secure at the cost of poorer performance. Instead, he argues it’s the responsibility of the components surrounding/using the kernel to enforce security. Linus has also said “I personally consider security bugs to be just ‘normal bugs.’”
If you don’t already know, Android is based on Linux. What does this mean for Android Developers? Well, it demonstrates, as with Android itself (or iOS), there will almost certainly always be vulnerabilities. YOU, not the OS, have ultimate responsibility to ensure your apps’ data is secure. YOU need to protect data to the level appropriate for your app. Don’t necessarily just rely on the OS.
Engadget posted an interesting article today on ‘BlackBerry reveals the lengths it went to make Android Secure’. This is after BlackBerry CEO John Chen previously revealed that BlackBerry could quit the handset business next year if it doesn’t sell enough handsets.
With the new Android Priv device, BlackBerry is trying to use its reputation as a secure device vendor to differentiate itself from the very many other Android vendors.
Security researchers will, no doubt, be eager to test the security claims and hence it remains to be seen if BlackBerry championing a secure Android handset is a wise or foolish endeavour.
This got me thinking about security as a differentiator. This might equally be applied to apps as well as handsets. Consumers are becoming ever wiser to privacy and security concerns and in the right circumstances this might be able to be used to tip the balance in favour of the app you are creating. However, as with BlackBerry (and indeed Snapchat), it really depends on how secure your solution really is.
University of Cambridge’s latest research into Security Metrics for the Android Ecosystem (pdf) has had the technical (and non-technical) media writing about Android security over the last few days.
Most of the research findings were already known. That is, the security of Android “depends on the timely delivery of updates to fix critical vulnerabilities” and “the bottleneck for the delivery of updates in the Android ecosystem rests with the manufacturers”. However, one interesting fact is that, ignoring Nexus devices, LG is the best manufacturer when it comes to updates.
So what are the vulnerabilities? The most serious ones are privilege escalation that allow code to gain more capabilities than were originally granted by the OS. For more information on this, take a look at a recent presentation from HITB GSEC by Ryan Welton and Marco Grassi on the Current State of Android Privilege Escalation (pdf).
Frederic Jacobs has an interesting article on Medium where he says the problem has come about due to manufacturers having no financial incentives to provide updates.
However, we probably need to put this into perspective. As Markus Vervier said today, “100% of Android and 100% of iOS devices are insecure. We just did not find all the bugs yet (and we never will).”
Here are a few recent mobile security related items that don’t seem to have made the mainstream media yet…
- FireEye have found that a mobile app company is taking control of Android Phones. They have a detailed breakdown and have observed re-packaged apps such as Amazon, Memory Booster, Clean Master, PopBird, YTD Video Downloader, and Flashlight.
- Hacker News has a story claiming XCodeGhost is similar to that developed by Central Intelligence Agency (CIA).
- Google have been relatively quiet about their SafetyNet anti-tamper detection, masquerading as a CTS compatibility test. koz.io has a detailed breakdown of what it does and how it works. The article also explains how to call the test from your app. However, as the higher levels of SafetyNet are Java calls, it’s likely that it can be hooked (bypassed) using something like XposedBridge.
If you are interested in Android app security you should take a look at the Android Security Symposium that took place earlier this month. It was run by Josef Ressel Center u’smile at the University of Applied Sciences Upper Austria in cooperation with SBA Research and the Institute of Networks and Security (INS) at Johannes Kepler University Linz. The program gives links to the video presentations and slides.
Of particular interest are:
See the program for 14 further presentations.
When I created ActiveVault, one of the thoughts was to also try to protect Java code. However, whatever way I looked at it, it wasn’t possible. You can encrypt code but as soon as you decrypt and load the Java, it becomes visible in two ways:
The first is that, since ART and Android 4.4, it’s not possible to dynamically load (decrypted) Java code without it appearing in storage. Previously, with Dalvik, it was possible to dynamically load extra code to memory. For devices with the ART runtime, an OAT file containing the DEX file has to exist in the file store, in the dalvik-cache directory. This is world readable even on un-rooted, unmodified devices. The technical reason why the file has to be in storage is so that it can be paged out by the OS. There’s DexExtractor available to extract such files on the emulator.
The second, more involved way, that involves tampering with the OS, is via hooked functions. This is where attackers can intercept function calls to do extra things such as read files/data. Utilities such as DexHook and DexHunter (research paper pdf) can intercept the code as it is dynamically loaded.
Yes, there are some code protection utilities or packers that claim to encrypt code or classes. These do what they say, they encrypt code, but they are of not much use if the code is easily readable later on when processed by the OS. There’s no way to fully protect Java code. It can only be obfuscated.
Blackhat USA 2015 finished yesterday and some interesting Android and iOS related papers are now available. The sessions included Josha Drake’s much anticipated ‘Stagefight:Scary Code in the Heart of Android’ but papers for that session aren’t currently available. However, the fallout of Stagefright is of more consequence with Google, LG and Samsung to be pushing more security updates. This might prevent Android armageddon predicted by ars technica or less dramatically by myself a year ago.
Back to Blackhat, there are interesting papers on Exploiting Heap Corruption in libcutils (pdf), Yet another Universal Root (pdf) and Front Door Access to Android Devices (pdf) via poorly thought out phone OEM software.
The growing list of vulnerabilities is a reminder to developers to better secure their app data. Hence, of more direct interest to developer’s is NNC Group’s paper on Faux Disk Encryption:Realities of Secure Storage On Mobile Devices (pdf). It gives a great summary of the challenges mobile app developers face in securing data stored on iOS and Android devices.
Two days ago I repeated my advice on having to be careful when using WebViews in security sensitive applications. Yesterday, I happened to come across a research paper (pdf) (and presentation) “Insecurity of Mobile Banking… and of other apps” by Eric Filiol and Paul Irolla of ESIEA Operational Cryptology and Virology Lab that recently became available at blackhat Asia 2015. In the research paper it says…
The authors are French so we can excuse them that the above doesn’t read that well but I think what they are saying is that because banks already have a secure web site accessible via the browser most are re-using it for use within their mobile apps.
I guess the assumption banks are making is that any checking such as login, intrusion detection etc is already there and proven it’s best to re-use these mechanisms as they are considered to be secure. Unfortunately, that assumption is very wrong. In using WebViews to render server side screens they have opened themselves up to the area of the phone software that has the most (and most complex) vulnerabilities. For example, the login might be on a web page on some server but by rendering a remote page there’s the possibility of extra unwanted things being loaded that might do literally anything such as log keys and read data in files or memory. I have also yet to see a reliable implementation of certificate pinning that works with webviews.
The authors also claim…
“Furthermore, there is at least one vulnerability affecting webview. This vulnerability has not been disclosed by Google and consequently Google will not publish any security patch to correct it for version 4.3 and prior versions. It is therefore a major vulnerability which allows a third party to take control over the phone.”
You can read the paper (pdf), slides (pdf) and a similar presentation (video) from December that analyses some well-known banking apps to show they aren’t that secure. If you really must use WebViews, you might also read my guidelines on how to be careful with WebViews on Android. If you are concerned using a banking app yourself then you can read my basic advice of consumers.