Building from my previous research of VMware Airwatch, I have continued to review industry-recognized mobile device management (MDM) solutions. Previously, I detailed how VMWare’s Airwatch authentication workflow could be abused to bypass multi-factor authentication (MFA). A similar attack surface exists for MobileIron, a 2019 industry leader. This article details MobileIron’s authentication workflow release of rustyIron, a framework for testing MobileIron security issues.

MobileIron, like many MDM solutions, affords organizations containerized access management across untrusted or unmanaged devices, providing a secure mechanism to connect to internal corporate resources. This is facilitated through pushing a provisioning profile to the device and validating the operating system, security patch level and manufacturer as well as determining if the device has been compromised, jailbroken or unlocked. Upon successfully passing a security check and providing valid authentication credentials, an organization can push applications and services to the device. These would typically include access to email, VPN services and/or other organization-specific services.

Summary

This article will walk through three issues that, when chained together, could lead to account compromise.

In partnership with MobileIron, Optiv has provided detailed mitigation strategies at the bottom of this document.

Technical Analysis

Hardcoded Mobile@Work API Key
MobileIron implements MDM through the installation of the Mobile@Work Android/iOS agent application. Upon launching the app, users are prompted for their email address or the authentication endpoint of the MobileIron MDM environment.

Image

Figure 1: MobileIron Initial Registration UI

Like VMWare’s Airwatch, submitting an email address will initiate a discovery process to identify the authentication endpoint attributed to the email address’ FQDN. This discovery process is triggered against a MobileIron hosted API. However, unlike Airwatch, MobileIron attempts to restrict access to only authorized requests through the implementation of an API key at the following URL:

Communication with this API takes two user-supplied input values:

As expected, API requests that do not contain the proper API value are denied access to the resource and receive an HTTP 403 error.

Image

Figure 3: MobileIron Discovery - Invalid API Key

API keys are generally regarded as sensitive information equivalent to credentials and are protected as such. However, MobileIron has hardcoded an API key in the Mobile@Work agent.

Android packages (APK) files are zip archives containing an application’s code, resources, assets, certificates and the Java manifest file. The application code is represented in a binary executable file known as a Dalvik Executable (DEX). Depending on how these applications were compiled and/or designed, the binary content can be decompiled to return most, if not all, of the original application’s source code.

Unlike APK files, Apple’s iOS Application Archives (IPA) files are encrypted with a unique key associated to each individual iOS device. Using a jailbroken iOS device, these files can be decrypted. Unlike APK files, IPA files are XCode compiled applications. Ultimately, IPA static/dynamic analysis is possible with an appropriate debugging framework, but recovery of the original source code, or decompilation, is not.

I will not address the context or process to recover an APK/IPA file and decompile the application to obtain the original source code here. This preamble is meant to provide context for the findings detailed within this post. The Mobile@Work agent was recovered from an Android environment and then decompiled to derive the original Java source. Examination of this content revealed the MobileIron API key was hardcoded in the following Java file:

Image

Figure 4: MobileIron Hardcoded API Key

Recovering this API key allows any unauthenticated attacker the ability to locate an organization’s MobileIron authentication endpoint.

Image

Figure 5: MobileIron Discovery - Valid API Key

Upon validation, this issue was reported and acknowledged by MobileIron. MobileIron identified this functionality as a critical component to the Mobile@Work workflow and will be reviewing alternative solutions going forward:

“The static key is used during the registration process and allows the mobile client to find a customer’s Core based on the user’s email address. Removing this functionally means the user would need to provide the host name of the Core which would likely be impactful on our customers’ workflow. The Engineering team is looking at additional options though there is currently no timeline for remediation.”

Based on CWE-798, MITRE has assigned CVE-2020-35137 to this observation. Validation of this attack surface can be performed with rustyIron.

Hardcoded Mobile@Work Encryption Key
Upon identifying the authentication endpoint, the Mobile@Work agent would begin the authentication process using port 9997/TCP. This application service is a TLS encrypted raw TCP socket utilizing a proprietary MobileIron protocol. Mobile@Work does not validate the TLS certificate chain by default and relies on the mobile device’s authority trust. Mobile@Work can be enabled to perform TLS validation checks of the MobileIron endpoint through the activation of the non-reversible, Mutual Certificate Authentication functionality. Enablement of this feature does not change the client/server communication process and only instructs the Mobile@Work client to validate the endpoint certificate chain. The reliance on TLS as a transport mechanism does protect transit communications in most circumstances. However, if a device were to be compromised or a malicious certificate chain to be trusted, visibility would then be possible. Furthermore, having access to this encryption key allows an attacker to build and/or automate authentication requests without any reliance on Mobile@Work or a compromised device, thus providing an Internet-accessible SFA authentication interface.

I found that adding a self-signed certificate to a device’s trusted authority allowed decryption of the Mobile@Work communication channel. Mobile@Work sends raw binary data to the MobileIron endpoint, which appears to contain a variable 38-byte payload header. Through examination and submission of various authentication requests, I have identified the following packet layout:

Image

Figure 6: MobileIron Protocol Request - Packet Layout

An example Mobile@Work to MobileIron packet header would be represented as follows:

Figure 7: MIPR TCP Header- Hexdump

Communication between Mobile@Work and the MobileIron endpoint is initialized with an 0x1C message. The additional parameters 0x03790376 were observed to have an affinity with the model, OS and manufacturer details of the mobile device. To eliminate the randomization of this communication exchange, application testing of MIPR was standardized to represent a Google Pixel 2 (walleye) running Android 11. This resulted in the following initialization request:

During the research of this registration process, MobileIron was observed to contain some level of device indexing to match model, manufacturer, OS and build information. Depending on how this data was submitted, the MIPR Type Parameters would change for the request and/or MobileIron would deny the authorization attempt. Due to this limitation, research against the MobileIron environment was standardized to the device details listed above and the Packet Type Detail of 0X001C034D034A.

A successful MIPR initialization request would result in the MobileIron endpoint providing details around the provisioning of the environment.

Figure 9: MIPR 0x1D Response Packet

The MIPR response is an 0x1D message, containing the following ASCII content.

This MIPR response contains the provisioning details and authentication requirements of the MobileIron endpoint. During this research effort, the following MobileIron authentication strategies have been reviewed: standard user-password authentication, PIN authentication, PIN-password authentication and mutual certificate authentication. These various authentication strategies contain the following 0x1D configuration details.

The authentication details of username, password and PIN values are all submitted in the previously discussed 0x1C ASCII message body, with the exception of the following additional fields:

Each of these values are represented as masked ASCII HEX and do not directly reflect the plaintext input.

In the above example, the following values were submitted as part of the request:

The masked value content was represented as a 16-byte or 128-bit ASCII HEX value. Hashing mechanisms, such as md5sum, output a fixed 128-bit hash, with sha1sum returning a 160-bit value. The unique characteristic of a hashing mechanism is that the output value is of a fixed length, regardless of the input content. Increasing the username from a 10 to 16 character value (mobileiron123456) resulted in the following output:

A base input of 15 characters is represented as a 16-byte ASCII HEX value. Once the input is increased to 16 characters, the output value also increases by another 16 bytes. This observation identified a 128-bit block cipher encryption mechanism was leveraged.

In order to allow the MobileIron endpoint to decrypt the Mobile@Work content, a shared encryption key would need to be exchanged. To locate this value, I returned to the decompiled Android APK. Quickly searching the Java source for the string “auth_username=” identified the Java file:

Image

Figure 15: Mobile@Work C4944v.java - Function m20994d

This function appended the input cipher variable str to the ASCII string “auth_username=”. As this function was not a response for encrypting the content but was where the content was passed, I searched for all calls to m20994d(). This effort brought me to:

Image

Figure 16: Mobile@Work - RegisterActivity.java m20994d Function Call

The Java function m33760C0() was not completely decompiled. However, enough of the original content could be deciphered to identify the logic flow. Based on the m20994d() source, r7, r8 and r9 should contain the output ciphertext - so how are these values assigned?

Image

Figure 17: Mobile@Work - m33760C0 Assignment of r7, r8, and r9

Through m20857f() of course!

Image

Figure 18: Mobile@Work - m20857f()

m20857f() is located in sources/com/mobileiron/common/utils/C4928m.java and contains the encryption function along with a hardcoded encryption key.

MobileIron has acknowledged awareness of this configuration deficiency. However, MobileIron indicated the attack vector is minimal due to the multi-layered encryption strategy through TLS.

“The static key is used to encrypt the user’s username and password during the registration process. The encrypted credentials are then encrypted again using TLS as they’re sent to the MobileIron Core. While the first layer of encryption provides little value (if the key is discovered), an attacker would still need to conduct a MitM attack (and break TLS) in order to obtain the credentials during the registration process. Core customers have the ability to enable two-factor authentication for device registration to mitigate the risk of an authentication attack. Customers can also enable Mutual Certificate Authentication to secure subsequent device check-ins. Finally, the product team is looking into certificate pinning which would mitigate the risk of MitM attacks.”

Furthermore, MobileIron addresses the ability to perform two-factor authentication. This authentication strategy is not a typical implementation of MFA, but a proprietary authentication mechanism through PIN and/or PIN-Password authentication methods. In validating MobileIron’s suggested mitigation options, PIN values were observed to be single-use. However, MobileIron doesn’t appear to contain a protection mechanism for brute-force enumeration of these values, allowing for an unregistered PIN to be intercepted by an unauthenticated attacker. Additionally, PIN values are registered to a single user, so compromising a PIN registration only allows authentication attacks against a single user.

This issue was also reported to MITRE and has been assigned CVE-2020-35138. The exploitation of this attack vector can be performed with rustyIron.

Armed with the AES encryption key, I had the ability to encrypt and decrypt MIPR data. With this information, it would be possible to launch man-in-the-middle attacks against MIPR communications, although not very opportunistic. A successful execution would require coercion of the device owner to accept and authorize a malicious TLS certificate. The Mobile@Work agent does not natively conduct TLS verification checks and inherits the mobile device’s trust authorities. With this understanding, if an attacker was able to inject and/or coerce a user to install a malicious certificate, MitM of the communication would be possible.

Although the MitM risk itself is reduced by TLS, this is only a small vector due to this exposure. An attacker who is armed with the MobileIron encryption key would be able to construct authentication requests against a MobileIron endpoint without any requirements on the device or the Mobile@Work agent, extending an Internet accessible SFA interface. This resource could then be leveraged in an authentication attack to compromise an organization’s user credentials and, if successful, obtain access to internal corporate resources, VPN and employee email through registration of an attacker controlled mobile device.

Account Enumeration
A standard implementation of MobileIron would be integrated with an environment’s user-identity source – traditionally, Microsoft Active Directory (AD). This identity source would then be linked through LDAP using some filter criteria, thus enabling MobileIron to view the contents of the user repository. MobileIron does not allow registration for all visible users by default and requires the account to be enabled in the solution prior to allowing registration of a device. However, once a user account is visible, an attacker can successfully perform authentication attacks. To aid in this initiative, MobileIron provides the following variable MIPR responses:

Aside from these targets, the following ancillary responses were also observed – depending on the submitted MIPR content:

A successful authentication attempt is determined based on two criteria results. First, if a client is enabled in MobileIron and allowed to register a mobile device, MobileIron will respond with a zLib compressed payload containing the MobileIron MDM profile. This profile would contain a number of interesting details, including the associated username, SenderGUID, UUID and cookie value. If an authentication is successful, the following 0x1D response is received (0X001D006400000193).

The following interesting items have been highlighted inside this provisioning packet:

A failed authentication attempt is determined based on the following 0x1D message (0X001D003200000193). Failed authentication attempts are implemented in a unique manner within MIPR – the lockout condition is local, meaning that failed authentication attempts do not result in AD account lockout.

Research of this observation indicates that the MobileIron lockout threshold is about five failed authentication attempts, which is not directly inherited from LDAP/AD but appears to be a MobileIron configuration design. Once the lockout threshold has been reached, subsequent authentication requests will be presented with a lockout message. However, the lockout duration is about 30 seconds and has not been observed to affect the upstream identity source.

The lockout event is determined by the following 0x1D response (0X001D004C0000019300). A full lockout MIPR message body will be formatted as follows:

Perpetual authentication attacks can be executed against a MobileIron environment with negligible impact.

Additionally, based on 0x1D variable Type Parameters, it is possible to perform user enumeration. Successful authentication obviously identifies a valid account. However, enumeration is possible when we examine the authentication process across multiple attempts with the same user:

Based on CWE-204, MITRE has assigned CVE-2021-3391 to this observation. Validation of this attack surface can be performed with rustyIron.

Mitigation Strategies

MobileIron has provided the following configuration recommendations to remediate the disclosed attack surface and vulnerabilities:

In addition to these suggestions, MobileIron customers should also implement the following best practices:

Vulnerability Disclosure Timeline

Upon discovering this issue, Optiv initiated responsible disclosure to MobileIron for issue remediation. The following is the timeline for this disclosure:

References