Passcode bypass vulnerability VMware Workspace ONE Content App

The VMware Workspace ONE Content app, referred to as the Content App hereafter, is a mobile application developed and maintained by VMware. This app is designed to provide seamless and secure file management on mobile devices, allowing users to securely open and edit sensitive files in their workspace. The application is targeted towards highly sensitive and confidential data. With encryption and a passcode system, the Content App is meant to ensure that all sensitive information remains protected at all times.

During a security assessment REQON has discovered a security vulnerability in the Android version of the Content app that made it possible for a malicious actor with root access to a device to decrypt the files stored the Content App without the need of the configured pincode. This issue was reported to VMWare and they assigned CVE-2023-20857 to this vulnerability and a CVSS3.1 score of 6.8 Medium.

After being notified of the vulnerability, VMWare has released a security update to mitigate the discovered finding.

Vulnerability description

To gain a comprehensive understanding of this vulnerability, it is essential to grasp the purpose of file encryption on mobile devices. While most modern phones are encrypted by default, file-level encryption is necessary for apps like the Content App to ensure the confidentiality of files, even in the event of mobile device getting compromised.

However, the vulnerability identified by REQON indicates that this encryption was not securely implemented and could be bypassed. The vulnerability involves two weaknesses in the design of the Content App, which enable a malicious actor with root access to a Android device to decrypt all files without knowing the configured pincode.

The first weakness lies in the app’s crypto design. Through reverse engineering, it has been revealed that files stored within the Content App are encrypted with a symmetrical key derived from a single asymmetric private key stored in the app container on the device, as well as some parameters that can be derived from the encrypted file itself.

The second vulnerability stems from the pincode implementation. The pincode is not utilised in the encryption and decryption process, and it is not validated against a backend, making it very easy to bypass.

Impact

With this vulnerability a malicious attacker, with full access to the file system of a mobile Android device, is able to decrypt the files stored inside the Content App. This forms a risk for organisations that want to ensure the confidentiality of files with a bring-your-own-device policy.

Proof of concept

Below a proof of concept that shows that the pincode is not related to the encryption and decryption of files. Please note that when a pincode is not checked against a remote backend or secured/used with encryption an attacker with root-privileges is always able to bypass it.

To reproduce this vulnerability the script below can be injected in the Content App’s proces using Frida.

The script will overwrite the maximum allowed pincode attempts with the value: 1000000000. This corrupts the pincode value and now whenever the app restart a prompt is given to configure a new pincode. When a new pincode is configured, it is still possible to access all files stored in the app.

Below a video demonstrating the result after the script is injected in the Content App’s process:

Reverse engineering the crypto process

First, we tried to reverse engineer the workings of the Content app via a tool called Jadx. But it became clear that the library responsible for the encryption and decryption of files in the Content App (com.airwatch.crypto.openssl.OpenSSLWrapper) is heavily obfuscated and therefor it was not possible to easily reverse engineer its contents.

We then moved to another tactic which was to hook all the functions inside the heavily obfuscated OpenSSLWrapper library with Frida and log their argument types and values. When a file is opened via the Content App it calls several functions in the same order. Below is an outlining of these functions, their return values, and their arguments.

1. aesUnwrapKey: This is the first relevant functions that is called when opening a file. This method always returns the same value, the symmetric key, starting with 10,76,71 and ending with: -10,-97.
2. awFileReturnKeyAndIV: This method is called after the “aesUnwrapKey” method and requires the following arguments:
   • String -> The static private key, stored inside the app container, with the name “fipesOpenSSlRSA.enc”
   • String -> Path to the file that is going to be decrypted.
   • Byte array -> The static key that is returned from the “aesUnwrapKey” method.
   • Byte array -> No entirely sure about this one but it seems like some padding.

3. awFileChunckDecryptV2: is called to decrypt a chunk of the file stored on the device. It requires the following arguments:

• • Int -> A random int that is stored in the first 4 bytes of the file. See the image below.
  • Byte array -> The first return value of the “awFileReturnKeyAndIV” (120,124 till -99,-74) and some padding (0,0,0)
  • Byte array -> The second return value of the “awFileReturnKeyAndIV” (-23,55 till -44,57)
  • Long -> Always seems to be a 0 for every file.
  • Int -> Something regarding the length of the decrypted chunk

The screenshot makes clear that the “aesUnwrapKey” method returns the exact same value as with the other file (10,76 till -10 -97). The method “awFileReturnKeyAndIV” returns different values but is using the same inputs as with the decryption of file 856.txt. Therefor it can be stated than an attacker with access to the filesystem of the Content app can easily hook the app, call the awFileReturnKeyAndIV, and retrieve the random int from the first 4 bytes of the file, and then call the awFileChunkDecryptV2 method to decrypt a part of the file.

Remediation

When securing files within a mobile app it is important to understand that storing the encryption keys on the device is in most situations a suboptimal measure.

To mitigate this risk a part of the key could be stored in the back-end on a remote server and the other part on the device. This will however remove the possibility for offline access to files. Alternatively, biometric authentication methods could be used to safely store encryption keys. This way, attackers with access to the filesystem of a device will no longer be able to decrypt files in the app or reset the pincode.

VMWare decided to not alter the encryption design of the Content App but instead decided to enhance the root-detection on Android devices. While the update is effective in decreasing the likelihood of exploitation, it does not fully mitigate the risks described in this article.