Knox vuln is Android not us, says Samsung Samsung and Google have taken an unusual step, jointly posting an advisory that a security problem revealed last month is not Samsung-specific, but is in fact an Android vulnerability. Late in December, a researcher from Ben Gurion University of the Negev in Israel said there was a gap in the Knox security implementation in …
So insecure crap is still insecure crap, even with the bolt-on security afterthoughts...Who would have thought it...
Glad I use Blackberry and Windows Phone....Both meet military and government security requirements out of the box...no need for an extra layer to try and fix it being broken in the first place like Android!
"Yeah NSA, GCHQ, etc are loving having complete access to your phone while you think it is secure."
According to Mr Snowden, physical access is required to hack a Blackberry, and there is no public record of a hack for a locked Windows Phone.
For Android meanwhile, we know that the NSA can hack the device REMOTELY and activate the camera and microphone....
MiTM attacks typically require a compromise of a network. This is a higher level attack that takes more knowledge. Simply getting malware onto a device isn't that high of a bar, and can be done by people with a fairly low level of knowledge and/or simple social engineering (get them to visit a website, download an app or maybe even open an email with a nasty payload)
In fact, the whole point of Knox is supposed to be that if you use it, you don't have to worry about malware getting on your phone because Knox protects you against that malware. So much that claimed protection! Samsung may be correct that this is an Android problem and not a Knox problem, but unless they can prevent this type of MiTM attack against Knox, it is essentially useless for the purpose for which it was designed.
I wasn't talking about intelligence agencies - they probably have the means to attack Knox directly, as well as many other options for getting at the information "protected by it".
I was talking about your common cyber criminal, who is hoping to get your bank or credit card details, or other sensitive information like SS number. He hasn't compromised any networks, and isn't likely to have the means nor the desire to do so. He just wants to find a weakness in Android and use it to grab what he can. If people using Knox are less likely to worry about this thinking Knox protects them, they're the perfect victims for this attacker.
I'm not quite sure how they can blame Android for a failing on the App developers' part (insofar as communicating in the clear). Nothing short of redirecting traffic transparently through VPNs or some other encrypted tunnel would be able to fix this on Samsung or Google's end. Am I missing something here?
It depends where the network encryption is being carried out.
"the Knox environment provides a virtualised secure container that's meant to protect sensitive data from attack"
Given that this is virtualised will mean that it has to communicate at some point to the underlying OS and then Hardware via the implementation stack.
Keeping anything virtualised secure is a real nightmare as the MITM can be implemented by hacking the environment that provides the virtualisation.
Hardware encryption is usually more secure (as long as there are no bugs) as the encryption and de-encryption are carried out in hardware not in software.
Additionally Java has been a horror show on the security front for many many years now (I hear Java 7 is much much better, but only time will tell) and given that parts of Android's implementation was based on Sun's original implementation (which was a watertight as a tea strainer) there may be some very nasty surprises buried deep (that have not been thoroughly stress tested).
"I hear Java 7 is much much better, but only time will tell"
Time has already told. Java is still the worst ever framework for security - 267 vulnerabilities in the latest 1.7 version already....
http://secunia.com/advisories/product/37734/
To put that in perspective, the whole Windows XP OS has only had about 600 vulnerabilities over 12 years!
From your link:
"PLEASE NOTE: The statistics provided should NOT be used to compare the overall security of products against one another. It is IMPORTANT to understand what the below comments mean when using the statistics, especially when using the statistics to compare the vulnerability aspects of different products."
And also,
"There are no unpatched Secunia advisories affecting this product, when all vendor patches are applied.. "
Of those 267 only 12 are issued by secunia, many of those others are reported by users/devs, how many bugs did MS fail to publically reveal? How many are security bugs?
"The statistics provided should NOT be used to compare the overall security of products against one another"
Comparing it against the same product (other versions of Java) shows that if anything, security is getting worse.
Comparing it to a whole OS that's 12 years old at least gives you a scale of reference of exactly how bad Java is!
"There are no unpatched Secunia advisories affecting this product, when all vendor patches are applied.. "
Because Oracle don't give advance notice of vulnerabilities and we don't have any unpatched zero days - this month at least....
"Of those 267 only 12 are issued by secunia"
Erm, no.
So, we read that “This research did not identify a flaw or bug in Samsung KNOX or Android" and that "... it demonstrated a classic Man in the Middle (MitM) attack ... ", and yet below that we read that "Samsung claims that it collaborated with Google to confirm that the issue is an Android vulnerability."
So, it's not a bug in Android, but it is an Android vulnerability? You're saying Android is designed to work that way, or what?
If what you're trying to say is that it is possible to install a proxy on Android that passes a bogus certificate to KNOX so that KNOX sets up what it thinks is a secure environment but the proxy can actually act as MitM and access the encrypted data then you should say so ... and that would seem to be a fault in KNOX, which ought to have its own private trusted key store with which to validate the VPN certificate(s) it uses ... but perhaps I'm reading too much between the lines?
@Irongut
Can you point out where it says employer supplied devices for me in that following sentence?
"At the time, Samsung disputed the university's characterisation of the security vulnerability as a “category one” problem (that is, high severity), claiming that because the tests were conducted on store-bought phones, the target devices lacked the full enterprise suite of security features.
However, in an announcement published on Thursday, January 9, Samsung says: “Samsung has verified that the exploit uses legitimate Android network functions in an unintended way to intercept unencrypted network connections from/to applications on the mobile device."
This is my understanding of the situation.
1. Apps the send data unencrypted are vulnerable. This is the basic premise that it's an android issue. Apps outside the Knox container are vulnerable. Apps that don't use the Knox VPN are not protected by Knox.
2. Knox can secure this date *if* setup properly.
3. The tests did not setup Knox properly. All data to and from the container can be secured properly. Just installing Knox doesn't automagically make the world perfect.
The notices from Samsung and Google are not every helpful since most of the commenters do not understand the detail as far as I m aware. I know Knox (and competing products) and I have to write customer facing security notices on occasion. You should always clearly define who is at risk and who is not. In this case devices that use Knox, but have not taken the necessary steps to secure important apps will still be at risk from data leakage from said apps.
If there's a way to stop what is being reported by just changing/correcting the configuration then ultimately the issue here is one of documentation and or training.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
