Anatomy of a Chrome for Android bug – the mixed-up world of mobile browsers

Security researchers at Kaspersky recently wrote about various Android attacks featuring malware known as Svpeng.

Svpeng is a whole family of data-stealing and banking-related threats, so this is more than just what Google might glibly try to label Potentially Harmful Software: it’s malware, and you definitely don’t want it near your phone.

(Sophos products block samples from this family with the names Andr/Svpeng-A to Andr/Svpeng-H.)

Amongst the malware, Kaspersky researchers also noticed a bug – a vulnerability, in fact, albeit a modest one – in the mobile version of Google Chrome, which is Android’s default, pre-installed browser.

The bug isn’t especially dangerous, and it’s been reported to Google in the hope of having it fixed, so just being aware of it is enough to be going on with.

Nevertheless, we think that this bug tells a number of fascinating stories, touching on how cybercriminals think their way around security warnings, how developers sometimes think their way into security confusion, and how adding complexity can be the enemy of consistency.

As the old adage goes, the devil’s in the details, so here they are.

Assuming you’ve turned on Android’s Unknown sources option under Settings | Security, you can install apps from anywhere, not just from Google Play:

Even though the Play Store is far from a malware-free walled garden, Google does actively curate it, malicious apps are kicked out once they’re noticed, and it’s generally far safer than many of the free-for-all alternative markets out there.

Nevertheless, many people like the freedom that Unknown sources gives them, and for some, this freedom is an important part of choosing Android over Apple’s firmly closed iOS ecosystem.

Downloading APKs directly

Once you’ve opened yourself up to alternative app markets, acquiring new apps is as simple as clicking on a web link that references an APK file, like this one does:

Chrome actively tries to warn you when the file you’re about to save poses a risk, and even though popup warnings get a bad name because they’re easy to ignore, you can’t say you weren’t told:

Of course, if you know you clicked on an APK link, this warning probably wouldn’t deter you, but if the download happened in the background, you might be very grateful for the alert.

Indeed, given that background downloads and click-the-link-yourself downloads amount to exactly the same thing in the end, and given that it’s reasonable to assume that the same program code inside the browser is used whenever a URL is saved to your Downloads folder…

…we’d certainly expect you to be shown the APK warning no matter how the process of saving the file was initiated.

But in the case reported to Google by Kaspersky, the crooks grabbed an open source code snippet that demonstrated how to implement a File | Save As... feature in a multi-browser way, and used it to save their malware.

We’re guessing that the crooks’ original intention was to find an easy way to download their malicious APK indirectly.

That means they could fetch the malware as an innocent-looking, scrambled blob of data, rearrange it into APK format using JavaScript, and then save it as though it had been an APK all along:

In the code above, the function URL.createObjectURL() is provided by your browser so that you can take data that’s already inside the browser’s memory, and convert it into a programming object that pretends to be a URL.

If that sounds like a case of complexity introducing risk, it certainly is, but it also makes it easier for web programmers to adapt web apps to deal with new sources of data without having to rewrite all the URL-based parts of the software.

The rest of the code above converts the in-memory pseudo-URL into a link inside the document, and simulates the act of clicking it, all behind your back.

This time, however, Chrome skips over the APK warning, and the file is therefore saved to your Downloads folder both quietly and automatically – technically speaking, what’s called a drive-by download.

All you see is this:

If you click OPEN, you jump straight into the installation process; if you don’t notice the message, or choose to ignore it, then the dialog will dismiss itself after a few seconds, but the downloaded file will still be there, ready for installation:

You can still bail out at this point, of course, so the risk is much lower than a true drive-by install, where both the download and the installation happen automatically.

Nevertheless, the crooks got two for the price of one here: code that not only made it easier to obfuscate their malicious download in the first place, but also enabled them to bypass the warning that an informed user might be looking out for.

If you’re an app developer, watch out for this sort of dichotomy in user experience: behind the scenes, the pseudo-URL was saved in just the same way as it would have been from a real URL, so the app ought to have behaved in a consistent way.

What about other browsers?

While we were writing up this article, we wondered, “How do other popular mobile browsers deal with this?”

So we tried Firefox, Opera, Rocket, Dolphin and UC Browser, too.

The results, in a word, were mixed.

None of the other browsers behaved quite like Chrome, but they all left something to be desired in terms of presentation, clarity or consistency.

Firefox, for example, correctly produced an identical dialog for both the direct download from a regular URL and the JavaScript-initiated pseudo-download

Nevertheless, we didn’t find this dialog very informative, given that it could easily have shown us the filename and the filetype to give a better indication of what was being saved to our SD card:

We also felt forced into the download, given the lack of a cancel button in the dialog. (Tapping outside the dialog makes it disappear without making a choice, but a bit more clarity would have been nice.)

Dolphin probably produced the most desirable result: the regular download gave reasonable feedback about the file being fetched, but the sneaky pseudo-download was prevented altogether:

There’s still room for improvement, though, in our opinion, given that the right-hand error message didn’t include any explanation of what “the URL” meant, or what was prevented, or why.

UC Browser and Opera popped up regular-looking but basic download dialogs, and produced consistent behaviour for each sort of download:

Last up was Rocket.

This browser prevented the inadvertent installation of the sneaky download, but more by accident than by design, apparently because it was unable to figure out the right filename to use:

The downloaded APK ends up in your Downloads folder, but the extension .bin has the handy side-effect of preventing Android from recognising it as an installable app: tapping on it does nothing.

What to do?

• Developers. Aim for consistency and clarity. If ever a non-technical user tells you a dialog is confusing or a warning message unclear, it is.
• Users. Stick to Google Play if you can. It’s not perfect, but it does corral your risk, and it stops your browser from introducing unexpected APKs.
• Everyone. Watch out for the next Chrome update. Google is keen on fast patches, so you can probably expect this to be fixed in next month’s updates.

Also, consider an anti-virus on your device that can block risky apps before you run them for the first time, and head you off from dodgy websites before you get there in the first place.