Smartphone, App Privacy and Security

There’s a thought-provoking post by Carolin Milanesi of Creative Strategies on The Smartphone: Our Most Valued Possession When it Comes to Privacy and Security. Their study showed that security on smartphones matters most to consumers. However, security matters differently depending on the kind of service. For example, people expect tighter security for email clients than for social media apps.

While all this might seem obvious after inspection, it has implications for apps. Apps and hence developers need to apply a level of privacy and security appropriate to the app’s use. What you, as a developer, might think as an acceptable level of security might be different to consumers’ expectations or even the requirements of your business. These things can be important and demand extra consideration.

Malware and Leaky Apps

nowsecureNowSecure has a useful new 2016 Mobile Security Report (pdf) based on their analysis of over 400,000 apps. They found that 24.7 percent of mobile apps include at least one high risk security flaw. 82 percent of Android devices are vulnerable to at least one of 25 OS flaws. iOS had the most vulnerabilities in 2015 at 375 that’s nearly three times more than Android, which had 130.


NowSecure conclude that leaky apps that store or transmit sensitive personal and corporate data in an insecure manner are of far greater concern than malware.

App Security as a Competitive Advantage

arxanAraxan 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.

With Security Comes Liability

thehackernewsTwo 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?

Insecurity of iOS Banking Apps

iosactiveIOActive 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.

  • ioactivebankingsecuritysummary12.5% did not validate SSL certificates
  • 35% contained non-SSL links
  • 30% were vulnerable to JavaScript injections via insecure UIWebView
  • 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.

App Javascript Vulnerabilities

Fireeye has an infographic where they share the results of analysing 7 million Android and iOS apps. 31% of Android apps were found to be vulnerable to Javascript-Binding-Over HTTP (JBOH). iOS was found to be the ‘next frontier’ for cyber criminals with Universal Cross Site Scripting (UXSS) and sideloaded apps via Apple’s Enterprise Program being of particular concern.


So what’s JBOH? I think it’s another name for vulnerabilities in webviews that I have been documenting for a long time now.

Security Vulnerabilities Through Depending on 3rd Party Code

trendmicroTrend 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.

The Latest from Blackhat

blackhateurope15If 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 site provides some recommendations.