The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
In a nutshell, this is legalized control and spying.
I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
E:V:A said:
The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
In a nutshell, this is legalized control and spying.
Click to expand...
Click to collapse
jcase said:
I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
Click to expand...
Click to collapse
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?
E:V:A said:
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?
Click to expand...
Click to collapse
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
puzzled
I don't get it - I thought "knox" was just that thing that counts how many times you've flashed a custom rom (which can easily be removed and reset).
b
jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
We are not able to see how any closed source security component works, and you investigate it the same way you investigate any closed source feature.
jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone
E:V:A said:
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone
Click to expand...
Click to collapse
I'll make sure to remove such paranoia posts in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.
jcase said:
I'll make sure to remove such paranoia post in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.
Click to expand...
Click to collapse
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.
E:V:A said:
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.
Click to expand...
Click to collapse
It has been removed from the security forum, it is a copy paste of an article reportedly from cnn (no source link to back that), without any citations to the claims made. I will make a better effort to keep the forum accurate, and fud free in the future.
It has factual inaccuracies, and seems to be just a promo piece for a custom Android ROM that indeed has it's own issues.
@E:V:A
I do appreciate your posts, they are welcome here, but some of the posts ive been removing are just FUD, way out there or unsourced.
when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.
explanation
yueyejinghun said:
when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.
Click to expand...
Click to collapse
It's just a feature that counts how many times you've flashed a custom rom to your phone; easily removed and reset.
FIRST Read the OP and then the KNOX whitepaper.
and maybe someone will open this thread again...or remove it.
Is this something we have to worry about? Or, is it just click-bait?
http://www.wired.com/2016/01/hack-brief-years-old-linux-bug/
AN ISRAELI SECURITY research firm has come forward with a troubling discovery. A zero-day vulnerability in the Linux kernel has left “tens of millions” of Linux PCs and servers exposed, along with 66 percent of Android phones and tablets. And it’s been there for nearly three years.
The Hack
In a blog post detailing the issue, Perception Point researchers say that problem stems from the Linux keyring facility, essentially a locker where apps can stash authentication and encryption keys, security data, and other sensitive info. The bug, outlined in more depth here but described as “fairly straightforward,” can ultimately allow an attacker to pose as a local user and gain root access to a device.
This is bad! Root access can allow an attacker to do everything from installing malicious programs to deleting files to reading sensitive information on the device. Gaining access is also a simple enough matter; an attacker could use a simple phishing link to infiltrate the device.
Who’s Affected?
As far as Perception Point can tell, nobody so far. That’s some comfort, but maybe not much given the large number of potential targets.
“While neither us nor the Kernel security team have observed any exploit targeting this vulnerability in the wild,” says the Perception Point post, “we recommend that security teams examine potentially affected devices and implement patches as soon as possible.”
In addition to the “tens of millions” of Linux PCs and servers running Linux Kernel version 3.8 and higher, because Android shares some code with Linux, the vulnerability affects any Android device running version 4.4 or later. As of January 4, that adds up to 69.4 percent of all Android devices, even more than the researchers estimated. Basically, if you’ve bought or upgraded your Android device within the last two years or so, that device is vulnerable.
Update: Google has responded to Perception Point’s claims; in short, the company has prepared a patch and will make it available to partners today, and says that the range of affected devices may be “significantly smaller than initially reported.”
“We believe that no Nexus devices are vulnerable to exploitation by 3rd party applications,” writes Google’s Adrian Ludwig. “Further, devices with Android 5.0 and above are protected, as the Android SELinux policy prevents 3rd party applications from reaching the affected code. Also, many devices running Android 4.4 and earlier do not contain the vulnerable code introduced in linux kernel 3.8, as those newer kernel versions not common on older Android devices.”
How Serious Is This?
That something this potentially devastating went unnoticed for years is absolutely serious, especially given that Perception Point was able to put together a proof of concept exploit. In terms of actual exposure, the answer is mixed.
Things are already looking up on the enterprise side. Red Hat and Ubuntu have released their updates already, so now it’s just up to admins to implement them.
Android’s a slightly tricker story. While Google recently kicked off a monthly security update program, the company hasn’t yet said if a fix for this particular bug will be included in February’s, if not sooner. Even if it is, the update will need to work its way through the labyrinthine processes of the various carriers and hardware manufacturers that customize the operating system to their own liking. In short, there’s no telling how long it might take for all Android devices to be in the clear, if ever.
The good news is that all you really need to do to protect yourself is avoid suspicious links that might give a malicious actor access to your device. And if and when that security update does come through, install it. ASAP.
RAMpage – A Vulnerability Affecting Every Android Device Built Since 2012
We already know about the infamous Rowhammer vulnerability in DRAM (dynamic random access memory). Now, researchers have discovered another hardware vulnerability working similarly. The newly identified RAMpage vulnerability could allow hackers to take complete control of your smartphones. Posing a threat to all Android devices for the past six years.
RAMpage Vulnerability – A Rowhammer Variant
A team of eight researchers have discovered a hardware flaw that puts all Android devices at the risk of hacking. The team calls it RAMpage as it exploits memory pages in RAM. RAMpage primarily makes Android phones vulnerable to hacking attacks as it provides apps unauthorized access to the device.
Researchers have published a research paper (https://vvdveen.com/publications/dimva2018.pdf) in which they have explained about the flaw, and have proposed a solution too. The paper is available online in a separate link. one statement from it states:
“While apps are typically not permitted to read data from other apps, a malicious program can craft a rampage exploit to get administrative control and get hold of secrets stored in the device.”
This vulnerability could leak almost all of your personal data to hackers. This includes everything from saved passwords and emails to messages, business documents, and photos.
Though RAMpage mainly targets Android phones and tablets, the iOS-based gadgets do not remain significantly safe from this flaw.
The Threat Has Been Around Since 2012
The researchers clearly stated that the RAMpage has been around for the past six years. According to them, all android devices with vulnerable memory.
“More technically, every mobile device that is shipped with LPDDR2, LPDDR3, or LPDDR4 memory is potentially affected, which is effectively every mobile phone since 2012.”
Regretfully, no patch is yet available for RAMpage vulnerability. Moreover, one cannot precisely state desktops to be safe from it.
Google has recognized this flaw (CVE-2018-9442). Yet, they do not presently recognize it to be as important as the researchers believe it is.
“We’ve worked closely with the research team and thought this vulnerability isn’t a practical concern for the overwhelming majority of users.”
Google also claims that present Android devices are already safe from this flaw.
“While we recognize the theoretical proof of concept from the researchers, we also recognize that newer devices contain memory with Rowhammer specific protections (for example the researcher proof of concept for this issue does not work on any currently supported Google Android devices).”
As a conclusion, is this a method to get the much desired root in devices with boot loader blocked?
Credits: https://latesthackingnews.com
The first question which comes to mind is: Is acceptable having to rely on exploits to be able to administrate expensive devices for which we paid hundreds of dollars/euros/whatever?
I think it is plainly wrong. The community should stand up and demand vendors to stop closing our devices as they currently do.
Criminals always find ways (they dedicate their time to it), reducing administrative rights affect enthusiasts and even common users instead, crippling our experiences. At the end, our rights are at stake...
There is an app at http://rampageattack.com you could install and run to test your device for the vulnerability.
by sophisticated government attack i mean something with virtualization technologies, several masking and hiding capabilities like FinFishers solutions.
Does:
Updating to the newest version of ios
hard reset the phone
securely remove the spyware?
1) i see more as a bonus question that is not really needed, but might be interesting too.
I would thank you for a careful but practical answer, since this question relates to some "moving parts" like: "Is it possible to load a "real" update from an infected phone, or will a sophisticated attack redirect those requests" and if there is something you can do to prevent this etc. or the question whether a hard reset really deletes everything or if the spyware can somewhat hide in "blocked" or wrongly addressed areas of the storage and so on.
On the other hand i do know that there never is absolute certainty and would be more interested in a "probabilistic view".
Thanks to the Forum!
I think your question is pointing to widespread security problems with most technology. Manufacturers often use closed source software and the same goes for most of the hardware devices. This makes security very difficult and of course these weaknesses are now being exploited by state sponsors.
Stuxnet was a good example and well worth reading about.
https://en.m.wikipedia.org/wiki/Stuxnet
http://itmanager.blogs.com/notes/20...e-protected-the-iranians-against-stuxnet.html
It infects microcontroller chips that do memory management. The introduced code returns modified data, maybe not even on each read.
So if the phone internal memory uses these microcontroller chips then even loading a new rom wouldn't help. You have to be able to have access to the microcontroller firmware and introduce your own access certification. It is very difficult to do this at present as most of the hardware information is not available, both for phone and internal chips.
Unfortunately this means that state sponsors can take the devices apart, inspect chips with an electron microscope, thus obtain a lot of secret information for their hacks.
Having had stuxnet on a laptop I became interested in these problems.
Contaminated updates again depend on the resources available. These rely on https and code signing.
https://arstechnica.com/information...ate-authorities-conspire-to-spy-on-ssl-users/
http://www.crypto-it.net/eng/theory/software-signing.html
A contaminated update requires access to the certificates and a delivery method such as intercepting a request from a known ip address.
Many states have access to the certificates and the means to target downloads. Using tor for updating might give some protection, as would a system to compare your download with that obtained by other people. We don't have this working automatically yet as far as I know.
https://www.torproject.org/docs/verifying-signatures.html.en
Phones have a second operating system where code may not be secure.
http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone
https://www.rsaconference.com/event...ile-apt-how-rogue-base-stations-can-root-your
You can minimize risk by keeping a device in airplane mode and using a separate mifi device.
If you consider yourself an innocent target or just want to minimise risk then perhaps regularly buy second hand or new devices from shops, keep them in airplane mode, keep the necessary software to send by bluetooth and check the md5 sums.
Web browsers could be another security problem if they can run exploits, but this is probably outside the scope of your question.
Secure communications apps will probably work fine as long as they don't require updates. Beyond that, keep it all locked up in a safe you built yourself.