Container Findings

Data Leakage Outside Secure Container¶

• Clipboard
• Long press keys with menu
• Screenshots
• Through User Interaction data leakage

Overview¶

The secure container does not have the necessary controls in place to prevent application data from being leaked to applications not managed by . Malicious applications can capture the data that is leaked by Suite applications. This may also allow users to exfiltrate data outside of the secure container.

The clipboard and IPC mechanisms are some common methods for data leakage.

Remediation Procedure¶

The secure container should not allow data to be accessed by unmanaged applications. Clipboard functionality and IPC calls should be restricted to applications within the secure container solution. When the secure container loses focus on the device, the clipboard contents should also be cleared.

As a defense in depth mechanism, developers can consider disabling the ‘Long Touch’ functionality within TextViews and WebViews in the application. This will prevent a user from being able to select text within the application and therefore discourage/prevent sharing of data to external applications.

Incomplete Secure Container Implementation¶

• Files that are not encrypted but not by user interaction
• Unencrypted container files stored in any location
• Snapshots when device locks
• AirDrop
• Media Playback

Overview¶

The secure container implementation is incomplete. Not all data accessible within the framework is properly encrypted or stored within the secure container. Refer to the Issue Listing below for specific instances of unencrypted data stored on the device outside the container.

Remediation Procedure¶

The security framework should implement encryption on all data that could be written by the application.

Insecure Application Logging Mechanism¶

• Can log be viewed in application

Overview¶

The Suite applications implement a custom logging interface that exposes debug-level logging details to the end-user. Depending on the sensitivity of the data being logged, attackers may be able to infer details about the application's behavior, obtain sensitive data being passed between the mobile application and the server (e.g. cookies or personal data), etc.

Remediation Procedure¶

The development team should remove the application logging interface from the user interface. This functionality should never be exposed to the end-user. If such functionality must exist, consider storing sensitive debug information encrypted within the secure container. This will ensure that the data cannot be accessed by attackers who gain access to the device.

Incomplete Data Wipe of Secure Container¶

• Preform a wipe of the data and look for things that were not deleted

Overview¶

When a user exceeds the configured number of incorrect password attempts to cause an account lockout, the data associated with the application is removed from the secure container. It was observed that, after 10 incorrect password attempts, files were deleted from the application container; however, not all files/data were removed. See the Issue Listing below for further details.

Remediation Procedure¶

A more complete wipe of the and application container should be implemented to remove any data that leaks information related to the user or the container solution. This includes all data stored within the application container as well as data written outside of the container (intentionally or accidentally).

iOS Keyboard Caches Data¶

Overview¶

To enhance the results of the iOS auto-correct functionality, iOS stores words typed into textboxes to the keyboard cache file. The contents of this file are not encrypted, which could result in the disclosure of sensitive application data entered into text fields in the event of unauthorized access to the device.

Remediation Procedure¶

Consider the following recommendations to prevent keyboard caching:
- Set the autocorrectType property to UITextAutocorrectionNo on the UITextField control in order to prevent the information from being stored in the keyboard cache.
- When requesting credentials or any other sensitive data that should not be view-able, set the secureTextEntry property to YES on the UITextField control. In addition to disabling keyboard caching, the typed letters will be hidden.

Android Keyboard Caches Data¶

• Create a word in a textbox in the application and save it by clicking on it. Then navigate outside of the application and see if that word has been saved in the system dictionary.

Overview¶

Mobile keyboards cache items typed by users in order to provide features such as customized auto-correct and form completion. In the case of Android, the user dictionary is available to any application without special permissions. Both the Japanese and English keyboards used by the applications cache user keystrokes/words in the dictionary files. Caching of keystrokes/words may facilitate in the ex-filtration of sensitive data from the container.

Remediation Procedure¶

The development team should disable any features that could potentially lead to the caching of sensitive data through keyboard entry within the Suite of applications.

Sensitive Data Visible in Application Switching Window¶

• When on the application click the switch app button and see if the application

Overview¶

When the application is backgrounded and the user double-clicks the home button (iOS) or Windows button (Android), the OS will display the list of running applications along with a preview of each application. The application does not remove data from the application screen before the context is switched to another application. Since the data is not cleared from the screen prior to entering the background, it is possible to see application data in the preview of the application during context switching.

Remediation Procedure¶

When switching applications remove sensitive data from the screen when the application is not on the main screen.

Crash Report Stored Outside Secure Container¶

Overview¶

Detailed error messages often result from unhandled or unexpected exceptions within application code. These messages are often the stepping-stone to more complex attacks because they typically provide information that indicates why an error occurred which can be further leveraged to refine successful attacks. Suite applications leak such information in a crash report file on the device inside the application's data container but outside of the secure container.

Remediation Procedure¶

Applications should not store the crash logs on the device in plaintext and the contents of the logs should be encrypted.

Traffic Leakage Outside Secure Tunnel¶

Overview¶

Application sends HTTP(S) traffic directly to the server endpoints requested by the users instead of directing the traffic through the secure tunnel between Application and Gateway. This along with the following two issues could allow an attacker to intercept and potentially modify the traffic during transit.

• Application relies on the device's or user's certificate store to ensure the authenticity of the connection while establishing the connection. The Device/User Certificate Store contains information about the trusted digital certificates of trusted publishers and Certificate Authorities. This helps the device and the applications on the device use it to ensure the security of the connection between the communicating parties. This also can be used by an attacker to install their own Certificates into the device's certificate store and force applications, using the device certificate store, to trust it and potentially provide a false sense of security to the application while attacker middles the connection between the application and the server.

• Application respects the device's proxy settings while communicating with the remote server. This could potentially allow one to setup proxy settings on the device to forward traffic to the intermediate proxy server that an attacker controls and allow the attacker to view the traffic.

Remediation Procedure¶

Application should always route the application traffic through gateway and should not make direct connections to the remote servers.
The application should also use its own proxy settings that are separate from the system's HTTP proxy settings to prevent one from setting system wide proxy and hijacking the traffic between the application and the server.

Authorization Not Re-Validated At Service Layer¶

Overview¶

By default, Services such as Proxy Server, Forward Proxy, etc., do not verify whether a user is authorized to use that particular Service. Instead, the current implementation depends on the Gateway to perform the appropriate authorization checks to determine what services the user is allowed to access. As a result, it is possible for an attacker with a valid Authentication Token for a specific service to connect to other services directly without out the access control of the Gateway Proxy.

By not verifying that the User with the Authentication Token has access the Service, an attacker that is already positioned on the internal network can communicate with Services directly. Although this attack requires a position in the Near DMZ and a valid Authentication Token, this authorization flow still presents a considerable risk to 's customers.

Remediation Procedure¶

By default, all Services should perform authorization checks to ensure that the Authentication Token presented is permitted to access the Service rather than relying on assumptions about the security of a customer’s deployment and network architecture.

Insecure Lock Screen Protection Policy¶

Overview¶

does not set the most stringent lock screen protection policy for iOS. If the power button is pressed on the device while the user is logged into a application and is unlocked by an attacker before the timeout period, the solution does not prompt the user for their container password.

Remediation Procedure¶

Device Policy should force reauthentication when the device is put into a locked state and require a password on application launch or when power button is pressed. This will display the lock screen whenever the application is run.

Sensitive Data Remains in Memory after Application Timeout¶

Overview¶

Sensitive Data including secret keys, passwords, and other sensitive data is still stored in memory when the application has timed out and asked the user to re-authenticate. A malicious user who gains access to the device and is able to get root access without requiring a reboot, would be able to dump the application’s heap contents and extract the sensitive data. Although, most modern exploits require a reboot due to performing modifications to the firmware of the device, should assume that a similar piece of malware may appear in the future.

Remediation Procedure¶

Data written to the heap using the String object will only be wiped from memory when garbage collection is performed by the JVM. It is recommended that sensitive data is not stored using the String object and instead char arrays should be utilized. The data in memory should also be overwritten with random data when the application timeout is reached.

Inadequate Browser SSL/TLS Checks¶

Overview¶

When the application attempts to load pages with weak SSL/TLS configurations, it was observed that in some instances no error was presented and the page was successfully loaded. In other instances, no error was presented, but the page failed to load due to proxy blocking the outbound connection. In either case, the browser does not adequately protect the user. Tests were performed by navigating to test pages on the website ‘badssl.com’. Results were compared to the behavior exhibited by major browsers such as Chrome and Firefox, which display warnings to the user when a connection to pages with poor SSL/TLS configurations are attempted.

Remediation Procedure¶

should ensure that at a minimum the items listed in the Issue Listing are remediated to warn the user. As an overall best practice, since appears to be largely built on top of Chromium, should ensure that the underlying Chromium build used by is always up-to-date. Further, should continually test the browser against weak SSL/TLS configurations, and if possible, align the browser behavior with the major browsers.

Inadequate Client-Side Controls and Policies¶

Overview¶

Due to the nature of client-side controls, it should be understood that client-side controls and policies can always be bypassed given enough time and effort. As a result, the goal of implementing such controls is to increase the work factor required by an attacker to bypass such controls.

The application employs client-side controls in the following major areas, which were bypassed during the course of the assessment.

• Jailbreak/Root Detection - A strong jailbreak/root detection policy is the foundation of any MAM/MDM solution. This is especially true for other security controls within the solution. The bypass of jailbreak / root detection policies can help facilitate the bypass of all other client-side policies more easily. This is also recommended practice due to rooted devices having less stringent security controls than stock devices and an increased exposure to privilege escalation scenarios. Ultimately, this increases the risk that application data is leaked to an unauthorized party via physical interaction with the phone or through a malicious application installed on the device.

• Certificate Pinning - Mobile applications have the ability to perform their own validation of certificates sent by the server. Therefore, mobile applications no longer have to rely on Certificate Authorities (CA) for validating SSL certificates. It is a best practice to implement client-side certificate pinning within mobile applications in order to avoid any security issues that may arise with Certificate Authorities (e.g. in situations where a "rogue" or compromised CA issues an unauthorized certificate for the affected domain), which could then expose the application to man-in-the-middle attacks against TLS/SSL communications.

Further, the application does not employ any client-side controls with respect to binary integrity checks or runtime integrity checks. Integrity checks help to ensure that an attacker has not tampered with the application binary or tamper with the application at runtime.

Remediation Procedure¶

Due to client-side controls being inherently bypassable given enough time and effort, must employ a defense-in-depth strategy where security is implemented in layers, so that if a primary defense is defeated, secondary and tertiary defenses reduce risk and/or increase the work factor required to exploit.

To increase the work factor required to bypass the policies, the Android and iOS root detection and certificate pinning code (as well as other sensitive application functionality) should be moved into the native code layer if possible. This will force an attacker to review disassembled code rather than review decompiled Java level code or construct hooks at the Java or Objective C/C++ layer. Further, should introduce both static and runtime integrity checking code to help ensure that the solution is not tampered with. For both Android and iOS, code obfuscation techniques should also be employed so that class names, method names, argument types, and program flow are not easily discerned via decompilation and/or disassembly of the application binary and library files.