- 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:
- Andrew Hoog, of NowSecure on Improving mobile security with forensics, app analysis and big data. Andrew talked about app security risks, risks via ad networks, mobile app analysis and concluded old models such as malware signature checking don’t scale. Instead we need to look to automation, crowd sourcing and analytics.
- Nikolay Elenkov, author of the excellent Android Security Internals book, on the Android security architecture gave a great technical overview of Android security.
- Nick Kralevich from Google on Lessons from the trenches: An inside look at Android security talked at a higher level about Android Security and how it has evolved over time.
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.
About a year ago, I created AndroidSecurity.guru with the dual aims of teaching myself more about Android security while sharing insights and guidelines with developers and those people commissioning apps. The article on WebViews as been the most popular and it turns out most banking apps rely on them which is a bit disconcerting.
While working for clients, I have often been asked how to better secure data and my answer has usually been along the lines of ‘it’s difficult and it’s probably a project in itself to do it well’. And that’s really the problem. More background to the security problem itself can be found in the Android Insecurity document (pdf).
This year I have been working on a solution to this problem in the form of a native c++ library. While the premise of being able to have encrypted values bundled with an app and see/add to these values at runtime is very simple, actually doing it well is a lot more complex.
The resulting solution stores the decryption key at the server and only loads it when the device has no security problems. There are measures to authenticate the server, authenticate the client (app), detect app tampering, detect OS tampering, detect root (essential for security), detect c++ debugging, thwart memory dump analysis, bypass OS hooking and also anti-decompile features to make unpicking of the binary very difficult.
It’s an extreme solution to a simple problem and I am therefore currently targeting it at my existing customers and organisations working on security sensitive apps such as banking, payment and health. There are also UK export implications as it uses strong encryption. ActiveVault is currently undergoing trials and should be available October 2015. Contact me to enquire about early access, further information or for access to the current demo version (under NDA). You can also learn more at AndroidActiveVault.com.
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.
In the past I have mentioned the need to be careful about using WebViews in apps, particularly apps that are security sensitive. The number and complexity of WebView vulnerabilities are such that a pragmatic approach might be to not use WebViews in security sensitive apps. Recent news has shown that the same vulnerabilities can be a security problem for the Chrome web browser app itself.
If you have been following the IT news, particularly the security news, you will know that the Italian spyware company Hacking Team recently got hacked themselves and their source code was posted on the Internet.
It turns out they developed an Android ‘remote2local‘ exploit that cleverly combines three known Chrome vulnerabilities and the root-enabling put_user or TowelRoot vulnerabilities to allow pre-defined code to be executed as root from the user simply clicking on a link in the browser. The details are on the Tancent blog (Google translated).
How bad is this? The Hacking Team have a compatibility file that says it covers Android 4.0 to 4.3 and lists some tested devices…
One of the vulnerabilities, CVE-2012-2825 Arbitrary memory read, was fixed in June 2012 and another, CVE-2012-2871 Heap-buffer-overflow was fixed in August 2012 so end users allowing Chrome and WebView to update via the Play Store will have had these vulnerabilities fixed a long time ago.
However, this demonstrates how vulnerabilities can be combined to run code as root without the user even knowing. The Hacking Team compatibility file and subsequent vulnerability fixes show that in some ways, Android’s fragmentation aids security. It’s difficult for exploits to cover all types of Android OS and device and they usually only work on smaller subset of devices. As I previously mentioned, this won’t be much consolation to large companies with thousands of employees or customers which greatly factor up the chances of encountering exploits that might end up accessing sensitive company information.
Yesterday I wrote about how we shouldn’t necessarily ignore malware. GDATA has new research into current Android malware. They also have a free report (pdf). There are about 4900 new malware samples every day – that’s a new malware sample every 18 seconds.
About 50% of the malware is financially motivated and is attempting to steal financial details, send premium SMS or locks the device (ransomware).