If you are a mobile developer, you should take a look at the white papers and presentations that have become available following the recent blackhat Europe 2015.
Of particular interest to Android developers is (In)Security of Backend-as-a-Service (pdf) that shows how hard-coding service credentials for services such as Parse, Cloudmine and Amazon AWS not only puts particular user’s data at risk but the whole platform at risk. The easily-obtained credentials can be used to access huge amounts of sensitive data. The apparent ease of using BaaS has caused mobile developers to cut and paste sample code without thinking of the security implications.
Wondering what else your app might be doing wrong? The AndroBugs framework presentation allows you to scan APKs for known coding mistakes. It decompiles the app and looks for bytecode patterns that signify vulnerabilities in the code. Androbugs has recently become open source on GitHub.
Another way your app data might become visible is if it’s stored in the OS sandbox and subsequently backed up either on a rooted device or via ADB. The presentation on Authenticator Leakage Through Backup Channels on Android (pdf) goes into a lot more detail.
As usual, black hat activities look into the problems but don’t give many ‘white hat’ recommendations how to fix apps. It’s easier and more fun to find problems than it is to provide fixes. If you are looking for some answers then my AndroidSecurity.guru site provides some recommendations.
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.