Samsung keyboard app could let a crook crack your phone

Do you have a Samsung phone?

Ryan Welton, a presenter at BlackHat London, has come up with some bad news for you: the keyboard app built in to your device may leave you open to attack.

According to Welton, many Galaxy models on numerous mobile carriers may be at risk, including the S4, S4 Mini, S5 and S6.

Apparently, Samsung phones include a bundled-and-rebadged version of SwiftKey, a popular keyboard app that claims to be cooler and smarter than your average keyboard, making better predictions of what you are going to type next.

Unfortunately, as Welton spotted when he started digging around, as security researchers like to do, Samsung’s variant of SwitftKey, rather blandly renamed to SamsungIME, includes an auto-update “feature”…

…that doesn’t do authentication or integrity.

This is a similar bug to the hole we recently wrote about in Hospira drug pumps, where a researcher found he could upload a firmware update without worrying about verification.

That sort of vulnerability makes it much easier than it ought to be for a crook to feed fake code or data into your device, and ultimately to reprogram it almost arbitrarily.

Welton noticed that Samsung’s IME (Input Method Editor – the techie name for souped-up keyboard software) updates itself via plain old HTTP, using a web request like this:

GET http://skslm.swiftkey.net/samsung/down.../az_AZ.zip

You’d probably expect an update of this sort to use TLS (Transport Layer Security), and thus to go over HTTPS, because TLS is encrypted, and encryption is good.

But, strictly speaking, it’s not so much confidentiality you’re after in this case, because the contents of the update aren’t secret.

Indeed, you can download an APK (Android package) of the original SwiftKey app straight from Google Play and extract it from your phone to examine at your leisure.

NB. SwiftKey’s own app is not affected by this vulnerability. You get SwiftKey for Android from Google Play, along with its updates, so it’s as secure as Google Play.

What really matters are authentication and integrity, so you can convince yourself that the update came from a trusted source, and wasn’t tampered with along the way.

Done properly, TLS (and therefore HTTPS) can provide both these features, but the absence of TLS wasn’t the evidence Welton needed to satisfy himself there was a problem.

After all, the update package itself could have been digitally signed by Samsung, and verified during the update to establish that it had arrived unmodified from Samsung’s official repository.

Indeed, there was some sort of validation done during the update.

But Welton soon found that the “digital signature” was a simple SHA1 hash, specified in what’s called a manifest file:

{
  "name": "English (US)",
  "language": "en",
  "country": "US",
  "sha1": "3b98ee695b3482bd8128e3bc505b427155aba032",
  "version": 13,
  "archive": "http://skslm.swiftkey.net/samsung/down...
  "live": {
    "sha1": "b846a2433cf5fbfb4f6f9ba6c27b6462bb1a923c",
    "version": 1181,
    "archive": "http://skslm.swiftkey.net/samsung/do...
   }
}

Sadly, that manifest file, including the SHA1 hashes, was itself downloaded in an unauthenticated HTTP request, just before the package itself:

GET http://skslm.swiftkey.net/samsung/down.../languagePacks.json

→ JSON stands for JavaScript Object Notation, a simple, compact, text-based, easily-processed, human-readable file format commonly used for exchanging data between web-based clients and servers. JSON exists so that whenever you find yourself thinking, “I’ll use XML,” you don’t have to.

In other words, if you want to send a modified (or even a totally different) update ZIP file, you don’t have to hack into Samsung first and steal one of its carefully-guarded signing keys.

All you need to do is modify the manifest to match the modifications to your ZIP.

Worse still, Welton noticed that Samsung’s updater runs with the privilege android.uid.system, which means that a hacked ZIP fed in as an update could, in theory, do almost anything, including reading and writing files almost anywhere on the device.

With a bit of work (more accurately, with a more than a bit of clever thinking and quite a lot of work) he was able to package up a Trojanised ZIP that would directly run a program of his choice, making this a full-on RCE, or Remote Code Execution vulnerability.

What to do?

• If you’re a Samsung user…

Assuming your phone is vulnerable (Welton has published a partial list), there isn’t a whole lot you can do except try to steer clear of networks you don’t trust, where a crook might try to intercept and hack your traffic.

A Virtual Private Network (VPN) can help, where all your network traffic is encrypted before it leaves your device, “tunnelled” back to a server at head office or at home, and only sent out onto the open internet from there.

The silver lining, if that’s not too strong a way to describe it, is that a crook can’t exploit this hole just whenever he likes: you have to be on his dodgy network when an IME update happens, and he has to notice in time to jump in as a man-in-the-middle.

Unfortunately, however, it seems that the Samsung IME can’t be uninstalled, and it keeps on updating even if you disable it and use a different keyboard instead.

• If you’re a programmer responsible for coding updates…

Don’t take shortcuts when it comes to authenticity and integrity.

An unsigned SHA1 checksum is fine as an initial check that your update wasn’t accidentally corrupted.

(But use SHA2 or SHA3 instead: the world is moving away from SHA1 because it has some cryptographic weaknesses, so it makes sense to drop it now, before someone finds a way to break it completely.)

However, as well as or instead of a plain hash, you need to use a stricter sort of digital signature based on public-key cryptography to validate that the update came unmodified from where you expected.

And even if you use HTTPS/TLS to encrypt your updates, that alone is not enough.

You also need to do what TLS calls certificate validation to confirm the correctness of what you’re downloading.

Footnote

According to Welton, Samsung coded a fix for this problem early in 2015, but – as often happens in the Android ecosystem – it’s not clear which devices on which mobile networks have been patched yet.

All you can really do is ask, and we suggest that you do.

But please ask nicely: the more people who ask their phone provider pointedly but politely what has been done, the more likely we will collectively get the answers we need!