Information stored in glass houses won’t be protected by Samsung locks

Samsung is a powerhouse. Driven by an endless list of new technology and features, it has consistently dominated the consumer electronics market. Where once it was no more than a footnote in the mobile industry, Samsung is now the number one player (by volume) for smartphones. Particularly impressive about Samsung’s success in the mobile device market is the fact that it has built its business on Google’s Android software. The company’s real strength remains its ability to create compelling consumer hardware, but, as we know, consumer mobile devices are increasingly finding their way into the enterprise, which is a critical market for Samsung.

Not quite a year ago, in its first real attempt at being considered an enterprise-level mobile solution, Samsung announced "Samsung KNOX, an end-to-end secure Android solution that provides security hardening from the hardware through to the application layer".

Less than a year later, researchers at Cyber Security Labs of Ben-Gurion University of the Negev (BGU) claim to be able to obtain information secured in a Samsung KNOX environment simply by redirecting the network connection of the underlying Android software. This technique consists of intercepting traffic as it flows out of the secure container and before it is encrypted by the network stack.

Full details have yet to be released on the specifics of the attack in question, but it is already recognized as a man-in-the-middle (MITM) attack against the Android network stack rather than the Samsung KNOX environment.

While weaknesses can be found in any technology, this flaw in particular has been addressed by many of Samsung’s competitors in the application container space, and Samsung should not have trusted any part of the native Android implementation, as was implied by its initial press release on KNOX. Samsung provided the following response to the research that has been published by the BGU Cyber Security Labs team:

After discussing the research with the original researchers, 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 research did not identify a flaw or bug in Samsung KNOX or Android; 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, reaffirming the importance of encrypting application data before sending it to the Internet. 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.

KNOX offers additional protections against MitM attacks. Below is a more detailed description of the mechanisms that can be configured on Samsung KNOX devices to protect against them:

1.    Mobile Device Management -- MDM is a feature that ensures that a device containing sensitive information is set up correctly according to an enterprise-specified policy and is available in the standard Android platform. KNOX enhances the platform by adding many additional policy settings, including the ability to lock down security-sensitive device settings. With an MDM configured device, when the attack tries to change these settings, the MDM agent running on the device would have blocked them. In that case, the exploit would not have worked.

2.    Per-App VPN -- The per-app VPN feature of KNOX allows traffic only from a designated and secured application to be sent through the VPN tunnel. This feature can be selectively applied to applications in containers, allowing fine-grained control over the tradeoff between communication overhead and security.

3.    FIPS 140-2 -- KNOX implements a FIPS 140-2 Level 1 certified VPN client, a NIST standard for data-in-transit protection along with NSA suite B cryptography. The FIPS 140-2 standard applies to all federal agencies that use cryptographically strong security systems to protect sensitive information in computer and telecommunication systems.  Many enterprises today deploy this cryptographically strong VPN support to protect against data-in-transit attacks.

Hey Samsung, implementation is as important as features. An MITM attack is one of the oldest tricks in the book. Although simple, these attacks are most effective at obtaining information, and they highlight the need for a secure communication channel. By their very nature, mobile apps are designed for online connectivity. A secure container alone is not effective enough nor is a device-based virtual private network (VPN). Every application requires its own independent secure communication channel, particularly on mobile devices.

Within the findings, Secure Sockets Layer (SSL) encryption is recommended. Unfortunately, SSL implementation in mobile apps depends on developer implementation. It also lacks any visible way to notify a user when SSL is in use on a mobile app. Errors can occur during SSL implementation that may leave the app exposed to compromise on Android. These errors can occur within the configuration of a device’s trusting certificates, during the use of mixed mode communication, with improper management of hostnames, or even in the number of certificate authorities permitted. In general, developers are not security experts. Isn’t part of the value of a secure mobile infrastructure the ability to remove this dependence on third-party implementation of security controls?

Mobile device management is recommended; however, this does not address a user’s ability to install personal apps, nor should it. The premise of a secure workspace and personal space is that users maintain control of their own personal spaces. However, it is within these open personal workspaces that the risk to the system resides; thus, it is necessary to completely segregate the personal and enterprise space at all points of the application workflow.

Per-App VPN appears to be the solution, but it seems the implementation of the VPN connection as provided by Samsung KNOX is just a configuration profile of a device-level VPN connection (where the problem exists) and not an actual secure communication channel that terminates with the application and a known entity at the other end. Device-level VPN connections are susceptible to third-party interception as encryption key negotiation is not controlled by the application. A security provider must assume that the uncontrolled parts of the system are not secure and therefore are subject to exploitation through unknown variables.

FIPS 140-2 might sound great, but as has been repeatedly shown, attacks against encryption key ownership or MITM attacks don’t care about the strength of the encryption as the communication channel will be unencrypted legitimately anyway. These attacks are a form of interception; they aren’t hacking. For enterprise customers, however, there is no distinction between the two.

If Samsung is looking to provide a secure environment for the enterprise, it must take responsibility for all aspects of the information flow and the application architecture. Enterprises require security that does not rely on the native operating system of mobile devices. For the enterprise, a personal device is a glass house, not a fortress. Adding locks won’t change this.

Photo Credit: Michelangelus/Shutterstock

Chris Morales, NSS Labs' Practice Manager, Architecture and Infrastructure, has over 17 years of IT and information security experience and joins NSS from 451 Research where he was Senior Analyst, Enterprise Security. At NSS, his areas of research include mobile security, data security, vulnerability management, malware detection and host protection. Prior to 451, Morales was the Technical Partner Manager at Accuvant, where he developed position strategies for new offering areas such as mobile device security, data security and malware threat analysis. He developed integration strategies for security products in key client accounts in his role as a Security Architect at McAfee, and he also served as a Security Architect with IBM Internet Security Systems.