Araxan has a new free 5th Annual State of Application Security Report (pdf) where they surveyed consumer attitudes to security and analysed the most popular mobile
health and mobile finance apps for security vulnerabilities.
82% of app users would change providers if apps offered by similar providers were more secure. At the moment, 50% of organisations allocate no budget for mobile app security. If you are in an organisation that ignores app security you have the opportunity to make security a competitive advantage. It’s possible to use security to attract and retain customers.
Two bits of news today related to legal proceedings due to security…
Samsung Get Sued for Failing to Update its Smartphones
Las Vegas Casino firm Affinity Gaming sued Trustwave for allegedly failing a data breach investigation
Both these demonstrate that security involves responsibility and ultimately liability. This makes me wonder how many apps out there with poor security could end up being an expensive and/or reputation-busting liability?
IOActive has an analysis of the security of 40 iOS banking apps. Analysis is usually of Android apps so it’s interesting to see that iOS suffers from similar security problems.
- 12.5% did not validate SSL certificates
- 35% contained non-SSL links
- 40% leaked user information
Usually, I am relatively permissive when I use my phone for personal use but doing banking via mobile is still something I choose not to do.
So what’s JBOH? I think it’s another name for vulnerabilities in webviews that I have been documenting for a long time now.
Trend Micro has an article titled High-Profile Mobile Apps At Risk Due to Three-Year-Old Vulnerability. The problem has come about due to a vulnerability in libupnp that allows a buffer overrun to run arbitrary code on an affected device that can give the attacker the ability to take control of the device.
For Android, the architecture of Java is such that it is immune to buffer overflow problems. However, c/c++ written using the NDK can be vulnerable.
This shows iOS and Android developers need to be more careful when including 3rd party libraries that use c/c++. Being careful means keeping an eye out for security fixes in included c/c++ libraries and updating apps accordingly.
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.