Feeds

back to article 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 …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

FIPS 140-2

So they mention FIPS 140-2. A MITM attack can still be carried out if Dual Elliptic Curve Deterministic Random Bit Generator was used which is part of FIP140-2.

2
0
Anonymous Coward

Re: FIPS 140-2

that really sounds like you are from Futurama.

oh wait....

1
0
Anonymous Coward

Re: FIPS 140-2

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!

0
12
Silver badge

Re: FIPS 140-2

"Glad I use Blackberry and Windows Phone....Both meet military and government security requirements"

Yeah NSA, GCHQ, etc are loving having complete access to your phone while you think it is secure.

4
0
Anonymous Coward

Re: FIPS 140-2

"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....

0
2
Silver badge

Just because it is MiTM doesn't mean this isn't a serious issue

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.

3
3
Anonymous Coward

Re: Just because it is MiTM doesn't mean this isn't a serious issue

"MiTM attacks typically require a compromise of a network"

Erm, but the networks were already compromised several years ago: http://www.infosecurity-magazine.com/view/6394/

Probably even longer ago for the NSA....

0
0
Silver badge

Re: Just because it is MiTM doesn't mean this isn't a serious issue

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.

0
0

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?

1
1
Byz

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).

1
0
Anonymous Coward

"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!

0
0
Bronze badge

RE: To put that in perspective, the whole Windows XP OS has only ...

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?

1
1
Bronze badge
Headmaster

Re: de-encryption

"decryption"

0
0
Bronze badge

Re: RE: To put that in perspective, the whole Windows XP OS has only ...

"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.

0
0
Anonymous Coward

RE: @TheVogon

"Erm, no."

Erm yes, 1 in 2011, 4 in 2012 and 7 in 2013, 1 + 4 + 7 = 12

0
0
Boffin

Make up your mind!

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?

1
0
Anonymous Coward

"...because the tests were conducted on store-bought phones..."

As opposed to what? Most users have a phone they bought as opposed to a developer handset.

0
3
Silver badge

As opposed to phones supplied by your employer who have all the enterprise security and device management add ons installed and activated. Pretty obvious if you read the next sentence.

1
1
Anonymous Coward

@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."

0
0

The only place for a CC number is on the card. No where else. Unless you like memorizing CC numbers

0
0
Joke

Whats in a name

They really should not call it KNOX (acronym or otherwise) unless:

1) There are aliens buried in its basement.

2) People believe there is no gold in it (see #1).

3) A soldier comes out and shoots you in the face if you violate its security

Anything less is just a poor imitation.

0
0
Anonymous Coward

Based on the publically posted info so far...

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.

0
0
This topic is closed for new posts.