Subject: [CVE-2016-1920] VPN Man-in-the-Middle due to shared certificate store on KNOX 1.0 / Android 4.3

Vulnerability Description
=========================
The vulnerability allows disclosure of Data-in-Motion of Samsung KNOX 1.0 containers. 

In KNOX 1.0.0 the applications inside the container use the same certificate store as the outside Android environment. 
Android supports installing 3rd party certificates (following user authorization). Another useful feature in Android is the ability to create a VPN connection through which all traffic will be routed. 

Combining the above facts leads to a vulnerability allowing an attacker to perform a MITM attack on VPN traffic originating from within the KNOX container 

The attack sequence is as follows (all can be done without the user's knowledge for example when asking to make a phone call from his device): 
1. Install the malicious application requiring VPN-related permissions 
2. Install a 3rd party certificate 
3. Run the malicious application which starts a VPN connection. This will cause a notification to appear with the icon of the malicious application and name of the VPN connection. 

The ``red flag'' in form of the notification can be easily mitigated by the attacker. 
By using the KNOX icon and a benign name for the VPN connection such as ``KNOX Connectivity'' a non-tech-savvy will surely be persuaded that the notification is a legitimate part of KNOX and continue using the device normally. 

Affected System Configurations
==============================
We have tested and verified the vulnerability on the following devices, however, we believe that ALL Samsung devices running KNOX 1.0.0 are vulnerable 
1. Samsung Galaxy S3 
- Model Number: GT-I9305 
- Android Version: 4.3 
- Kernel Version: 3.0.31-2051278 dpi@DELL323 #1 
- Build Number: JSS15J.I9305XXUEML8 
- KNOX Version: 1.0.0 
- State: Rooted, via flashing a custom recovery and kernel. KNOX warranty bit tripped, technically disabling KNOX. KNOX was re-enabled (fully functional) using root capabilities 

2. Samsung Galaxy S4 
- Model Number: GT-I9505 
- Android Version: 4.3 
- Kernel Version: 3.4.0-1869009 se.infra@SEP-106 #1 
- Build Number: XXUEMJ5.CCOM 
- KNOX Version: 1.0.0 
- State: Rooted using SafeRoot. KNOX warranty bit not tripped, KNOX fully functional

Vulnerability Impact
====================
Prerequisite: 
- One-time access to an unlocked device allowing an attacker to install an application of his choosing 

Impact: 
- For as long as the VPN connection is active, all device traffic outside and inside KNOX will be routed through the VPN connection, 
allowing the malicious application to serve fake SSL/TLS certificates signed with its perviously installed 3rd-party certificate. 
Due to the shared certificate store, any application relying on a chain-of-trust verification will believe the certificate to be authentic and continue operating as normal, allowing the user to disclose his secret data to the attacker. 
- This attack will not persist after reboot as there is a need to manually start the VPN connection. 
- The attack doesn't involve any exploits and does not require knowing the user's KNOX password. 

Mitigation: 
- This attack was mitigated in KNOX 2.3.0 by introducing a separate certificate store for the KNOX environment. 
- The vulnerable code is in the system_server's code (services.odex) which can only be replaced by a full system update, potentially upgrading KNOX to 2.x.

Vendor Contact
==============
We contacted Samsung on December 9th, 2015 and have had detailed email exchanges with the vendor regarding this vulnerability. 
The highlights of the vendor's responses are: 

- "KNOX 1.0 is different than KNOX 2.3 in many significant ways". 
- This vulnerability was "directly identified and addressed during past internal security reviews" 
- "Devices that are KNOX capable can be updated via the Maintenance Release process. KNOX 1.0 containers will automatically upgrade to the newer KNOX 2.x 
technology when the update is applied" 
- "upgrading to Android 4.4 on a KNOX-enabled device implies upgrading to KNOX 2.x. No additional steps should be necessary from the users perspective"

Vulnerability Discovery Method
==============================
We utilized dynamic analysis of KNOX 1.0.0 to find this vulnerability. 

The dynamic analysis was performed using the Xposed framework by inserting hooks in the code flow requesting Android system services. 
We came to the conclusion that KNOX shares the system_server with the normal Android environment and attempted to "manipulate" a service externally to impact KNOX internally. We assumed that the certificate verification in SSL must be performed using a system service and if we could convince that service to trust our own certificate it would translate to KNOX trusting it as well. 
To do this we used the Packet Capture application by Grey Shirts (https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture&hl=en). 
The application installs a custom certificate and creates a VPN connection allowing it to capture all traffic. 
Then we surfed to an https URL from within the KNOX browser, in our case the Yahoo login page. We entered a username and password and afterwards saw it in the captured packets in Packet Capture. 

To install the Xposed framework we had to root the devices. 
- The Galaxy S4 was rooted using a modified version of SafeRoot. We downloaded the source code of SafeRoot, removed any KNOX-disabling features from it, recompiled it and used the modified binary to install "SuperSU" on the device. Using SuperSU we installed Xposed. 
- The Galaxy S3 was rooted to begin with by flashing a custom recovery and kernel, tripping the warranty bit in the process, thus preventing us from running KNOX. Due to the device being already rooted we installed Xposed on it and used Xposed to "re-enable" KNOX. We did this by adding hooks to the TIMA service running in the system_server. We hooked keystoreInstallKey to always return 0 and keystoreRetrieveKey to always return [0] + [key], with [key] always being the same 32 bytes. This convinced KNOX that the device isn't rooted and made it fully functional allowing us to verify the vulnerability on it as well.

Timeline
========
2015-12-09 Vendor notified
2015-12-28 Vendor permitted vulnerability publication
2016-01-12 CVE number requested
2016-01-16 CVE number assigned
2016-01-16 Public disclosure