This post is regarding the Samsung IME Keyboard / language pack update vulnerability CVE-2015-4640, CVE-2015-4641 discovered by security researcher Ryan Welton at NowSecure. HereUs RyanUs technical writeup.
ItUs non-trivial to detect the active exploitation of the Samsung IME Keyboard / SwiftKey language-pack update vulnerability particularly if carried out by a somewhat cautious adversary. Further itUs arguably even harder to 100% prevent the exploit on a non-rooted device. Note that, if rooted, youUd probably just remove the keyboard!
In particular there exists a race condition or Time of check to time of use (TOCTOU) challenge. An attacker can tune the MITM attack to be very cautious about when the attack is executed and thus evade many detection mechanisms. Obviously, the Proof of Concept Ryan shared does not make any attempt to evade detection.
In the end, the best fix, and thus not just a bandage, is for the language-pack update mechanism to be properly implemented or removed. In particular, the Samsung IME Keyboard shouldnUt have been signed with system privileges by Samsung, and zip directory traversals need to be fixed on Android.
WeUve heard rumors of solutions to detect and prevent the threat and we believe those claims provide, at best, trivial detection and can be easily circumvented
IUll present some clarifying points as well as a general discussion of the fundamental challenges in detecting and/or preventing this vulnerability.
1) The SwiftKey Keyboard application (as of version 126.96.36.199) on the Play Store, based on our research, has the same underlying language pack update mechanism that Ryan found in the pre-installed Samsung IME Keyboard application . However, the application from the store does not run as system user (uid 1000) and therefore cannot be exploited in the same way. The zip traversal can be exploited by feeding the application zip files and updating the SHA1 values. It cannot be exploited to overwrite Dalvik cache in order to gain code exec.
2) The vulnerable code in Samsung IME Keyboard is triggered when the device reboots, when the user opens the keyboard for the first time, and on a presently unknown schedule, but appears to be every 8 hours while the device is fully booted.
3) WeUve not yet seen a patched device.
4) The PoC Ryan released shows an exemplar proxy server as an adversary might employ. It waits for the vulnerable user to transit the proxy and request the vulnerable language pack update. Based on RyanUs technical writeup we know that the adversary can do many things using a file-write primitive, including overwriting Dalvik cache files to achieve code execution. A file write, in the face of lax security policy, is ultimately an extremely leveraged position for an adversary.
Here are some techniques that might find exist in a security solution advertising protection from the vulnerability:
One could install a specialized application on vulnerable and non-vulnerable devices alike, and periodically make HTTP requests to the SwiftKey language update servers. Basically weUd be the canary in the coal mine, pretending to be a vulnerable device and seeing if weUre being attacked on the network.
One might ask, how does one know that the attacker is manipulating the connection? Good question! One could either have a record of what the RcorrectS response is in the special application, or make a TLS connection to SwiftKeyUs servers (now much harder for the attacker to MITM) and compare the HTTP and HTTPS connection response results to each other. We assume we can trust the result of the HTTPS request. Therefore, if the HTTP and HTTPS requests differ in response body, we may call this a detection event and warn the user.
However, what if the adversary doesnUt always perform the attack. If the adversary sees both requests then they know someone is trying to detect and can thus remain silent.
Therefore in adopting this approach, one must be very careful about emulating the characteristics of a real vulnerable device or risk the adversary detecting the canary.
Similar to A, but we use a consensus algorithm whereby we make a connection to a backend service that aggregates the SwiftKey responses for a number of device models. The one aggregated the most frequently per device is the winner and the trusted response. If the canary app ever sees something else then we assume that network is malicious.
Like B except instead of consensus we assume a connection between the backend and SwiftKeyUs server is done over HTTPS and thus we assume our serverUs result is taken as the correct result.
Backhaul all web traffic from the device via VPN and use traditional network based detection/prevention to observe and prevent requests to the wrong SwiftKey backend.
The downside here is if you ever stop using the VPN and the attacker takes advantage then there is a window of opportunity for the attacker. This is a necessary condition, the VPN should be used consistently and the network hosting the VPN must not itself be attacked by the adversary.
All approaches (except if Approach CUs conditions are always met) presented are vulnerable to the race condition of checking if the adversary is active perhaps at a different time than when the vulnerable language update occurs. Therefore, instead of blindly accepting what a vendor advertises as a fix, IUd suggest asking what approach has been taken.
Thanks to Ryan, Jake, Marco, Erik, Paolo, Andrew, and Phil (and team) for help and reviewing this post!