Our Professional and Humble Response to Samsung
Three weeks ago on the 23rd of December 2013, a story was published in the Wall Street Journal (WSJ) regarding a vulnerability we uncovered on Samsung KNOX devices. We’ll begin with a little background about the vulnerability. We found that a malicious app (without ROOT) running in the non-secure area of a KNOX based device (for example, Samsung S4) can affect the network configuration (important settings) of the secure container. Such vulnerability can help an attacker intercept and potentially block and alter data communication originating from the secure area. The vulnerability is available in the wild on Android 4.3, and we made an assessment that this puts users with Samsung devices (with KNOX) who use their phone for secure and private matters at serious and immediate risk. To make a long story short, eventually Samsung (in collaboration with Google) published a response in which they dismissed our finding.
What Happened after the Response from Samsung:
We carefully contemplated the actions to take following Samsung’s public response. We envisioned the vulnerability going into “limbo” – on one hand, we believe that the vulnerability possesses great risk to Samsung KNOX users, and more broadly to Android users in general, yet on the other hand, the owners of the software (Google and Samsung) have publicly dismissed it. We had the opportunity to disclose it with full code details and videos just to prove our argument, but that would only put innocent users at risk, since the published code could fall into the wrong hands and be used for malicious purposes. However, users’ safety is a number one priority for us – much higher than our professional egos, so we decided on other actions. In this post we provide full disclosure about our actions, as well as our professional response to other things that happened on the way.
23 Dec 2013 – Public and non-detailed disclosure of the issue was reported in the WSJ together with our official statement.
25 Dec 2013 – We received an email from Samsung following the WSJ news report requesting more information. We immediately sent them an encrypted package which included the vulnerability details and received confirmation that they received the package. We also assisted them multiple times during their investigation of the matter.
9 Jan 2014 – Samsung released a public response, together with Google, in which they denied that it is a bug or flaw in Samsung KNOX or Android. In the same report Samsung acknowledged that it is a MitM attack and suggested, among other recommendations, to use Android VPN as a countermeasure for such attacks.
14 Jan 2014 – We sent an encrypted package with the vulnerability details to the Google security team and received confirmation that they received the package.
17 Jan 2014 – We received an email update from the Google security team that the matter was still under investigation.
17 Jan 2014 – We published our second vulnerability report – the VPN bypass.
Questions and Answers:
Q: Why did we point the finger at Samsung from the beginning? Isn’t it an Android issue?
A: We decided initially to disclose the vulnerability to Samsung, because we assessed that the KNOX scenario posed the highest immediate risk. Specifically, the use case consisting of interfering with, or eavesdropping on, secure communications taking place on a secure phone is of the highest risk. The vulnerability does pose a risk for any Android user (where the vulnerability exists); however the risk is more serious on devices which are perceived as secure by their users and are therefore used for private and sensitive communications. We believe that users perceive Samsung KNOX based devices as secure phones.
Q: So is there a bug to be fixed or not?
A: The main message coming from Samsung’s public response was: “This research did not identify a flaw or bug in Samsung KNOX or Android.” This meant for us (and the media and public following the story) that the issue is a non-issue and as such it does not merit even a software fix. However, as you can see from the disclosure log, we are now still waiting for Google’s official response. Currently the vulnerability is still under investigation, so perhaps it is a bug after all. We certainly believe so and hope for a fix. We will, of course, update Google’s responses here in the blog. Furthermore, within the same response the next line appears: “… it demonstrated a classic Man in the Middle (MitM) attack, which is possible at any point on the network to see unencrypted application data. The research specifically showed this is also possible via a user-installed program…” This leaves us a bit confused – So now it does pose a risk for attack which can take place on the phone? But still it’s not a bug or flaw? One technical note, regarding the term MitM – we think that it is a term that logically can describe the nature of the attack but using it in this context, in which it runs on a phone serves to minimize the perceived level of risk posed – read more here.
Q: But it says in the response that it uses legitimate Android functions?
A: We were also a bit surprised by the following choice of words in their response: “… the exploit uses legitimate Android network functions in an unintended way to intercept …” As far as we know, attackers love the unintended way.
Q: Did we configure the test devices properly?
A: In Samsung’s response the word configuration appears multiple times, such as in the sentence “Proper configuration of mechanisms available within KNOX appears to be able to address the previously published issue.” where it implies that our test devices were either not configured properly or even worse, were configured intentionally wrong to enable the vulnerability. This is, of course, completely unfounded; we used multiple S4 devices, straight out of the box, like any other user of such a device. We wonder how many Samsung KNOX device users, pleased with their phone’s built-in security capabilities, know what extra configuration is needed in order to be totally secure.
The response included also this statement: “Android development practices encourage that this be done by each application using SSL/TLS. Where that’s not possible (for example, to support standards-based unencrypted protocols, such as HTTP), Android provides built-in VPN and support for third-party VPN solutions to protect data. Use of either of those standard security technologies would have prevented an attack based on a user-installed local application.” Regarding SSL/TLS, it is up to the service provider you are communicating with (it may be enabled or not) and not up to you, and if SSL/TLS is not available, the vulnerability can intercept everything in clear text. Regarding the VPN as a countermeasure, below you will see that even if a user goes the extra mile and buys a VPN service and configures it properly, the risk remains.
Q: Is this vulnerability related to the VPN bypass you have uncovered?
A: Yes. The hole (vulnerability) is the same, while the attack target is different, and I will explain: Vulnerabilities usually present a weakness in a built-in mechanism which provides a “hole” for an attacker to get into and do certain things. Some vulnerabilities expose the whole operating system, and once an attacker is inside, everything is possible. Other vulnerabilities provide access but limit your ability and only enable you to do specific things. In the first finding we reported to Samsung the vulnerability details and an example exploit where an attacker can intercept, block, and alter data communications (non SSL/TLS and non VPN). We also stressed the point that other kind of attacks can take place via the same vulnerability. In our continued investigation of the vulnerability we found that an attacker can, in fact, do much more harm. This finding revealed that an attacker can bypass the VPN (even if configured properly) and again, the secure communications can be intercepted in clear text. Clear text refers to no encryption. We reported the second exploit several days ago here.
Q: What is the impact of your new finding on the risk level posed by the vulnerability?
A: Because the vulnerability impacts every Android user which uses VPN for private and sensitive matters, it poses a much greater risk than previously believed. With regard to Samsung KNOX, it means that the recommendation to use the VPN as described in Samsung’s response can be problematic.
Q: So what’s next?
A: We now wait patiently for Google to report on their investigation, and we sincerely hope that a fix will be applied to cover the hole. As for us, we are actively working on mobile security, and every new interesting finding will be reported here. We are also investigating whether the vulnerability exists on KitKat, Android 4.4.
Technical Notes Regarding the Vulnerability:
1. We tested the vulnerability on multiple Samsung S4 devices and other Android devices from different vendors. We did not test the vulnerability on Samsung S4 devices configured to work in an enterprise as we don’t own such as well as due to the fact an enteprise setup depends also on specific 3rd party MDM integrated.
2. We tested the vulnerability on Wi-Fi connections alone.
3. The vulnerability was demonstrated on Android 4.3. Existence of the vulnerability on KitKat 4.4 is still under investigation.
On a personal note, we are security researchers, and vulnerabilities, and mobile security in general, are not pure mathematics, which means we may be wrong here and there. Being wrong (and humble) is ok as long as we are responsible enough to tell the truth as soon as possible. All of our efforts are meant to advance the topic of cyber security, as well as to increase the safety of users and organizations and being open is the only way to go.
And to all software vendors out there – security researchers around the world work hard to improve security and, by the way, to improve your products – for free. So please do not “shoot the messenger.” If there is an issue, a quick fix and public explanation will be much more appreciated by your partners and customers, and also by us.
Cyber Security Labs Team – Follow us via @cyberlabsbgu