According to the researcher Ryan Welton, the SwiftKey IME keyboard update mechanism can be manipulated by a remote attacker capable of controlling user network traffic, and can then execute code as a privileged system user on the target phone.
The keyboard cannot be disabled or uninstalled, and even if not used as the default keyboard the vulnerability can still be exploited. In his blog entry detailing the vulnerability, Welton explains "the attack vector for this vulnerability requires an attacker capable of modifying upstream traffic. The vulnerability is triggered automatically (no human interaction needed) on reboot as well as randomly when the application decides to update. This can include geographically proximate attacks such as rogue Wi-Fi access points or cellular base stations, or attacks from local users on a network, including ARP poisoning. Fully remote attacks are also feasible via DNS hijacking, packet injection, a rogue router or ISP, etc."
As far as we can tell, the threat itself only actually applies to users of Samsung mobile devices which run a stock keyboard version of the SwiftKey keyboard, rather than the app which is available for download from the Apple or Google Play stores (this appears to be confirmed by the developers). Which begs the question, if the standalone download is secure what went wrong with the Samsung IME keyboard development process?
Jon Christiansen, lead consultant at Context Information Security, suggested to SCMagazineUK.com that "it cannot be said for certain since there are no developer comments so far, but it is likely that they, in the process of adapting SwiftKey into a pre-installed app, had to change how the update mechanism works (as it is no longer through Google Play like most apps) and in creating/expanding their own code, simply re-implemented it in an insecure manner, in this case as an unencrypted HTTP request to a specific server."
For how much of a real world possibility of attack this is, as it does require you to perform a man-in-the-middle (MiTM) attack to get at someone's phone, wide-scale targeting of the “600 million vulnerable Samsung users” that other articles mention seems infeasible.
A possible attack scenario would be where an attacker set up a rogue Wi-Fi hotspot at a popular destination where people connect to a single spot (like a business conference), and wait for the update to trigger before injecting the fake zip and attacking that way. While such an attack could yield a lot of valuable information, general wide-scale attacks seems unlikely with the information available so far.
Given disabling the stock keyboard is not an option, and waiting for a fix could take time, what is the most sensible advice to those 600 million users? SC has seen everything suggested from "root it and remove it" to "buy another phone" and one national newspaper was even running a story online with the advice: "If you own a Samsung phone, turn it off. Now!"
When you step back from the headline hysteria, how much of a real world threat is this vulnerability? Andrew Conway, a research analyst at Cloudmark, was clear when speaking to SC that although this latest bug to hit Samsung has the potential "to create doubts over the company's security for its devices", it is still "not one that is likely to be much of a threat to typical users."
He urged users to stay away from unsecured public Wi-Fi networks until such a time as Samsung ships an update to patch the vulnerability in the SwiftKey IME but said otherwise the chances of you falling victim to this particular threat are fairly limited. That 'stay away from unsecured public Wi-Fi' advice applies to anyone who uses their phone, from whichever manufacturer, to perform online banking, dual factor authentication or any sensitive data transaction task of course.
This particular threat doesn't really change anything much. "The attacker has to control the network in order to be able to take over the victim's phone" Conway explains "and then wait for the Swift Keyboard to decide to update so that they can supply malicious update files tailored to that specific device.”
Now that requires a lot of work for a fairly low rate of compromised devices, and truth be told there's not a huge return on investment in exploiting something like that for your typical cyber-criminal or hacktivist. Conway did suggest that perhaps nation state intelligence services might use such an exploit when going after a particularly high value target, but then again it's pretty much a given they already have the network access necessary to conduct a MiTM attack and the resources to write malware aimed at attacking specific devices.
Tod Beardsley, security engineering manager, Rapid7, while admitting that the attack scenario is not straightforward given the man-in-the-middle update hijack process (and the attacker cannot initiate that update process), said that it is by no means impossible.
The updates happen randomly, according to the researchers who revealed the vulnerability, and upon reboot for example. Which just leaves the problem of being close by and on the same local network (or having some fairly extensive control of the target's upstream provider) which is a lot easier done than said.
Think about it, how many people do you know who happily hop on to whatever wireless network is open and available? "A huge fraction of the Android population automatically connects to open, unauthenticated Wi-Fi networks" Beardsley told us, continuing "and it's trivial for an attacker to pretend to pose as a legitimate access point called attwifi or linksys. While the attacker cannot control when the vulnerable update happens, with enough people connecting to a rogue network in a busy urban area, he's bound to get lucky and get control of a few devices."
The problem here is a triple whammy of trust, ignorance and inability: we trust our service providers/handset manufacturers to sell us secure devices and networks; we don't have a clue about how either the handset, the software that runs upon it or the network that delivers it all works; and we have no ability to change any of it.
So we are left with a situation where the end user has no choice but to accept an update mechanism which uses HTTP and DNS, which is pre-loaded, which comprises unremovable components from the device manufacturer and which has been proven to be inherently insecure.
Worse still, courtesy of the carrier scattergun approach to Android device updates, the patch to fix this vulnerability could well come to some Samsung owners a lot sooner than others.
As Paco Hope, the principal consultant at Cigital told SC "the operating system updates a core component over an HTTP and verifies it with a simple hash also loaded over trivially-hijacked HTTP. It is easy to forge an arbitrary replacement. This Samsung vulnerability is a textbook example of software vulnerability in the design, not the code."