Android developers – just how much can we trust them to do web security properly?

Six German academics have just published a very detailed and systematic paper about web security on Android.

Catchily entitled Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security, the paper sets out, amongst other things, to answer the question, “Just how well-informed are Android developers, and how much can we trust them to do web security properly?”

As you can imagine from the title, the answer is, “Not enough.”

By the way, in cryptographic documentation, Alice and Bob are always the two parties who want to communicate (longhand for A and B), while Eve is the eavesdropper, and Mallory (who is sometimes known as Mallet) is the malicious man-in-the-middler.

→ A man-in-the-middle (MITM) attack is devious but simple. I trick you into connecting to me, instead of, say, to your bank. You do a transaction, but I suck up all the data: username, account number, token code, the lot. I then immediately use this data, while it’s still valid, to transact with your bank. Except that I pay the money to myself.

So, if the Eves and Mallories of the world really love Android, as the authors claim, that’s bad news.

I won’t try to encapsulate the intricacies of the whole paper here – it’s worth reading in its entirety, not in some newsily abbreviated form – but I am going to discuss some of its findings.

Here’s what interested me: the authors downloaded 13,500 apps from the Google Play Store. They looked at apps that used HTTPS (HTTP over SSL, or secure HTTP), with a view to finding out how many apps that bothered with encryption actually bothered to do it properly.

→ Just to remind you: SSL is intended to deliver a security trifecta of confidentiality (the data transmitted is encrypted), integrity (the data hasn’t been tampered with) and, through a system of digital certificates, authenticity (you really are talking to the right server). It’s the digital certificates that stop MITM attacks: used correctly, the certificates mean that Mallory can’t pretend to be your bank. He can get in the middle, but you’ll notice.

What the authors discovered was bemusing. 790 of the apps went to all the trouble of using SSL, but accepted any certificate at all. For all you could tell, your data might be perfectly secure all the way to a crook’s website.

284 of the apps did slightly better: they insisted on an approved certificate (one that was issued by an approved Certification Authority, or CA), but didn’t care which site it had been issued for.

→ SSL certificates deliberately have a website name knitted into them, precisely so that a crook can’t create one for his own site and then use it as if it belonged to someone else. You’re supposed to check that the site and its certificate match to prevent this sort of masquerading.

There were lots of other problems, too, notably that most apps using HTTPS didn’t provide any signal that they were doing so.

With nothing to differentiate between an encrypted connection and an insecure one, there’s nothing for security-savvy users to watch out for.

For years we’ve been trying to teach ourselves to watch out for signals such as the browser padlock, and to wean ourselves of the habit of clicking past certificate warnings.

Then – a cynic might conclude – along comes a raft of non-browser apps on Android to set us back a decade or so.

The authors suggest a number of remedies, including:

1. Expecting developers to learn from what browser makers are doing, and to spend time and effort finding and clearly informing users about security problems.
2. Expecting Google (and other app market providers) to raise the bar for Play Store apps by vetting apps for weak web security coding.
3. Using an automatic verification tool to help with both of the above.

In good, salesy style, the authors just happen to have written a software product for point (3): MalloDroid.

The good news is that they’re planning to release it as an online service, and it sounds as though it’ll be free. Presumably you’ll upload an app of interest to their server and it will tell you whether it contains any cryptographically inept web functionality.

That’ll be a good starting point.

I like the fact that on Android, the barrier of entry to software developers is lower (and the freedom and variety for users higher) than on Apple’s iOS. It feels more egalitarian and less controllingly commercial.

But I don’t like the fact that the barrier of entry – even in the official market, Play Store – is as low as this paper suggests. You can be open and egalitarian without being sloppy.