You will Never Have Complete App Security

When I speak with clients, there always seems to be be the impression, on their part, that things are either secure or not secure. Unfortunately, whether it’s desktops, laptops, servers or smartphones, the principle is the same: You will never have complete application security.

It will always be possible to fool users into installing things or doing things they shouldn’t. There will always be vulnerabilities that allow root and hence allow, for example, memory dumps of decrypted data. There will probably always be NSA backdoors and the possibility to eavesdrop on radio frequency (RF) noise. There will always be some users that root their devices making things considerably easier for attackers.

This doesn’t mean you should give up and not consider security at all. For all apps, simple safeguards, for example, keeping data in the Android sandbox, provide basic protection with negligible extra effort. At the other end of the scale there’s a class of apps, for example banking and payment, that needs to make it algorithmically time consuming (via encryption) or extremely technically difficult (via tamper protection) for attackers to read sensitive data. You will never have complete application security but you can have high security that, for all normal intents and purposes, will keep your sensitive data safe.

Android App Hacking Getting Easier

appsecIn my post on my Thoughts on Google’s Android Security 2014 Year in Review  I mentioned that security isn’t only about potentially harmful applications (PHAs) being installed. It’s also about the ability to easily obtain information from stolen devices and reverse engineer apps.

Today I came across a tool from AppSec Labs, AppUse, that enables easy offline reverse engineering of apps. It brings some well-known command line tools, used to reverse engineer APKs, together with a hooked ROM to allow access to things (e.g. files, communication, database, encryption) you can’t normally see externally. This is all wrapped in an easy to use window UI. This tool will be mainly used for analysis of malware and penetration testing. However, it’s obviously also possible to use it for nefarious purposes.

If you have intellectual property within your app, think your app might be copied or your app needs to be particularly secure, (eg banking, payment, enterprise) you will want to look into obfuscation/packing and tamper detection.

Mobilegeddon WordPress Learnings

wordpressAbout a month ago I wrote about Mobilegeddon.  Changes coming April 21 2015 will result in mobile friendly sites being promoted more, by Google, when searches are from mobile devices.

At first I wasn’t going to do much about it. This site is ten years old and ran a ten year old version of WordPress, patched in places and some unused remote access functionality disabled as I had learnt of vulnerabilities. It used plugins, particularly one for ‘related links’ that I knew wouldn’t work with new version of WordPress. The heavily modified template would also have to be changed to a more modern mobile-responsive template. It all seemed like too much effort for something that isn’t my core work.

More recently I had some spare time so created a copied, separate site to try and attempt the upgrade to see how difficult it would really be. You can’t just upgrade from 1.5 to 4.1.1 and instead you have to upgrade the database in stages, each time for a few WordPress releases at a time. It took some time but was more straightforward than I expected. I ended up dropping the related links plugin I was using and started using a more recent one that dynamically creates the related links rather than me having to select fixed ones for each post. This also now has the advantage that old post’s related links now change, with time, as newer related posts are created. I have also been able to add the latest SEO plugins.

I am pleased with the result. It’s much easier to author posts now. Interestingly, Google is now indexing the whole of this site rather than less than half of the site previously. Presumably, the new template (or SEO plugin) is more Google bot friendly. The site is also now responsive and passes the Google mobile friendly tests. It took a lot less effort than I anticipated and if you are in a similar dilemma as to whether to upgrade I’d recommend you do so.

pagesindexed

One affect I wasn’t expecting has been the huge increase in number of brute force attacks on the admin login page. I noticed this when I saw the WordPress login page getting of a factor of 100 more hits than all (the thousands of) pages on the rest of the site. There are many attackers, every hour, repeatedly trying to access the admin page. I can only think that going from WordPress 1.5 to 4.1.1 the site now looks more like a typical WordPress site than it did! I have since strengthened the login password and have added a lockout plugin that works after 4 failed attempts.

We will have to wait until the 21st April to see if the changes will have any affect on traffic.

Focus on Retention

mobileworldliveMobile World Live quotes some Gartner research into app use that says that ‘Developers need to focus on user retention as app market matures‘.

“App providers will need to focus their development, marketing and branding more intensely toward retention strategies”

Meanwhile, Localytics say ‘App User Engagement and Retention on the Rise‘. The average number of app launches per month is up 5% over the quarter. App stickiness improved in Q1 with engagement growing by 13% and retention by 41%.

localyticsapplaunchespermonth

Read the previous articles below to gain some insights into how to increase app retention.

Complexity Cost

firatroundreviewThere’s an interesting article at First Round Review by Kris Gale, VP Engineering at Yammer, on “The One Cost Engineers and Product Managers Don’t Consider”

“Complexity cost is the debt you accrue by complicating features or technology in order to solve problems”

or put another way…

“The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product”

People tend to ask how long a feature will take to implement but there’s rarely any consideration as to the long term cost.

I believe there’s even more to the problem than complexity cost. The long term cost is also related to how well the feature is implemented. It can sometimes be implemented more than one way with different longer term costs or put it another way, different technical debt.

For example, be wary of using/overloading old mechanisms to support concepts for which they obviously weren’t designed – this is usually a sure sign of adding technical debt and complexity cost. Instead, re-design so it’s clearer and simpler.

So, when thinking about estimates, try to also think about the complexity cost and technical debt.

Thoughts on Google’s Android Security 2014 Year in Review

androidI have finally got round to reading Google’s ‘Android Security 2014 Year in Review’ (pdf). I believe it’s mainly a public relations exercise to assure everyone that Android is safe and that Google is being proactive in improving security. However, having read the report it’s easy to come away with the impression that everything’s ok. There are few places in the report I thought “Yes, but…”.

First an obvious one. Google say they “provided device manufacturers with ongoing support for fixing security vulnerabilities in devices, including development of 79 security patches”. However, what they don’t say is that very few of them made their way onto consumers devices.

Google say “Fewer than 0.15% of devices that download only from Google Play had a Potentially Harmful Application (PHA) installed”. This doesn’t sound many. As an end user you will probably be comforted by such a statistic. However, what if you are a company with say 1000 employees? Statistically, at least one of them might be leaking company information. What if you are a bank with millions of customers using a banking app? If your app doesn’t adequately secure data then a very large number of people could be affected. I think what this means for developers is that just because there’s a low chance of infection, apps should still take exceptional steps to protect their own sensitive data and not solely rely on the fact the platform is secure most of the time. The fact that Android is “secure most of the time” is only of significance for end users.

androidphas

There’s lots of emphasis on Google’s Verify Apps that checks apps at time of install. This won’t catch everything. Attackers are getting good at installing skeleton apps and later downloading extra functionality after Verify Apps has stopped looking.

Also remember, security isn’t only about PHAs being installed. It’s also about the ability to easily obtain information from stolen devices, reverse engineer apps and other such activities that can cause nefarious deeds without even installing an app under Google’s Verify Apps.

GSMA Mobile Economy Report 2015

GSMAThe GSMA has a recent free report (PDF) into The Mobile Economy 2015. The 78 pages are a mine of information for any startup needing a global view of mobile. Here are a few insights I found interesting.

There’s often talk of how much (or little) money there is in devices or apps. However, how do these actually compare to each other and how do they compare to the money made by network operators? The following chart shows the World GDP split by mobile area. It shows the majority of the commerce is actually in network operators…

gsmagdp

 

Another is interesting chart is the one showing commercial NFC-based payment launches over time…

gsmanfcpayments

I didn’t realise there were so many launches outside of Apple Pay.

iOS Mobile App Security

imasI have written a lot about Android security so here’s something on iOS to help redress the balance. iOS has similar challenges with encrypting data, enabling authentication and needs similar techniques such as detecting tampering via jailbroken phones or attached debuggers. This week I came across iMAS that helps developers solve some of these problems.

iMAS is a free set of open source components that “helps developers encrypt app data, prompt for passwords, prevent app tampering, and enforce enterprise policies on iOS devices”. As on Android, it’s often best to use pre-defined components rather than re-invent your own mobile that are more likely to have security flaws.