Many organizations use multi-factor authentication (MFA) to mitigate the impact of credential compromise, especially when Internet-exposed authentication is required. This has been a positive industry trend, as credential access to an organization has limited success in these security architectures. However, the increased complexity of implementing MFA, combined with convenience demands of large user bases can lead to unforeseen access paths through MFA solutions. Security research of VMWare’s AirWatch Mobile Device Management (MDM) product suite has identified MFA is only implemented during the registration process. Furthermore, prior to and/or in parallel of this registration single-factor authentication (SFA) attacks can be carried out against the solution, allowing for the compromise of user credentials and/or the registration of malicious devices. The focus of this article is to examine the SFA attack surface exposed throughout the AirWatch MDM product suite.

 

AirWatch, like many MDM solutions, provides organizations containerized access management across untrusted or unmanaged devices, providing a secure mechanism to connect to internal corporate resources. This is facilitated by deploying a localized or cloud-based appliance, which communicates back to a global infrastructure maintained by AirWatch through the domain awmdm.com. Mobile users would then establish communications to this environment through the installation of a mobile package. These are commonly known as Android Packages (APK) or iOS Application Archives (IPA), which are publicly accessible through the Android and Apple marketplaces.

 

Once installed, the AirWatch application will request one of two things from the user: an email address or a server endpoint.

 

 

Submitting an email address will initiate an API request to the URI of discovery.awmdm.com:

 

Figure 2: AirWatch MDM Client Discovery Request

 

This request is triggered against the following RESTful API:

 

 

The domain variable is leveraged to perform search functionality with AirWatch’s discovery service and return the AirWatch authentication endpoint and activation GroupID associated with the requested domain. The GroupID, or ActivationCode, is a required value when attempting to authenticate against the AirWatch solution. However, this information is considered public knowledge and is not protected or sensitive information. VMWare’s security response to the sensitivity of these values is as follows:

 

GroupIDs (ActivationCode) are used for the following and we do not consider them sensitive information:

 

"Group ID - public customer/org identifier used to associate a public device enrollment with the customer. Typically used to map email domain to a product specific identifier."

 

The request that is generated from the MDM application contains an authorization header and some additional validation checks. However, none of this information is server-side validated and the request header can be condensed to the following:

 

Figure 3: AirWatch MDM Discovery Request – Condensed

 

Discovery services have been observed through three different endpoints. Two are publicly documented APIs and the third is server-side content derived from the discovery process.

 

 

Requests generated against the v1/v2 API return a JSON response body detailing the domain’s authentication endpoint and GroupID values.

 

 

Unlike these two API requests, the third discovery interface requires knowledge of the authentication endpoint URL and returns the appropriate GroupID value. Additionally, communication with validate-userCredentials requires submission of a SessionID (SID). However, this value is easily recoverable by following the standard MDM registration process. Submitting a POST request to /DeviceManagement/Enrollment/EmailDiscovery returns a validation SID that can be used in the validate-userCredentials request.

 

Figure 5: VMware EmailDiscovery API

 

Two critical values need to be submitted in this POST for proper registration of the request:

 

 

The remaining values were just defaulted to False to allow processing of the request. Upon submission, the API will respond with a 302 redirecting clients to their device’s app store for installation of the AirWatch Intelligence HUB application. However, this response also contains the authorization SID to continue communication with the API once the package is installed.

 

Figure 6: EmailDiscovery Server Response Body

 

This SID value can then be passed as part of the parametrized request to validate-userCredentials.

 

Figure 7: AirWatch validate-userCredentials API Request

 

This request generates an HTML-formatted server response. Hidden within the content body are localized JavaScript code blocks. A substring query against this content returns the GroupID, within the second occurrence of else if statements.

 

 

Again, VMware does not consider this information to be sensitive. So, it does not represent a vulnerability on its own. However, to perform any further attacks against the environment, this information is critical. All AirWatch authentication interfaces require the submission of a GroupID value; without this information it would not be possible to carry out an authentication attack against the environment.

 

Upon recovering the endpoint and GroupID values, AirWatch discloses the configuration settings of the MDM environment. This further allows an unauthenticated attacker to identify sub-groups, authentication integrations and numerous additional configuration settings of the environment. This is all made possible through the following API endpoint:

 

 

Figure 9: AirWatch validategroupidentifier API Request

 

Similar to the v1/v2 API discovery endpoints, validategroupidentifier does not require authorization. Communication with this endpoint requires the submission of a JSON formatted message body and is directed towards an organization’s authentication endpoint. Within this message body, there are a few variables of note:

 

 

Successful submission of this request, returns the following response:

 

Figure 10: AirWatch validategroupidentifier API Response

 

The response body of this request is variable to an extent depending on how the endpoint is configured. However, the high-level JSON objects of Header / Status / NextStep remain constant. Within this request body, there are a few returned variables of note:

 

 

At the time of composing this whitepaper the following five Type values have been enumerated:

 

 

If the environment has a third-party integration for authentication services, the ServiceUrl / GreenBoxUrl / VidmServerUrl variables would then be populated by these values indicating the authentication endpoint where the MDM client would be directed for authentication services. In the above response, the specific configuration of Type 18 reflects the environment is configured to support SAML based authentication. As a result, the ServiceUrl variable is populated with the SAML based authenticator URL. Navigating to this URL, it is possible to attempt authentication within the context of the integrator.

 

 

Based on the configuration of AirWatch, different endpoints will be referenced to enforce the variable integrators. If SFA is enabled or the user is required to submit values to the airwatchenroll.aws API, CAPTCHA protection is enabled to limit brute-force authentication attempts.

 

 

Although these security protections appear to protect the authentication interface from abuse, research identified that CAPTCHA enforcement and MFA are protection mechanisms that are only enforced during user registration and SFA is solely leveraged post completion of this process. Many of the API functions within AirWatch rely on SFA. Furthermore, previous registration of a user is not required to establish an SFA attack surface. All the vulnerable API endpoints are publicly accessible to an unauthenticated attacker, allowing for password attacks. Specifically, the following two API endpoints can be abused for SFA, and they also provide limited user enumeration of valid domain accounts.

 

 

During AirWatch user registration, the Intelligence HUB application will communicate with validatelogincredentials and pass the authentication credentials to the endpoint. Surprisingly, even if a third-party authentication is configured within the environment, this API is still provided as a communication interface. A HUB generated request to this endpoint would contain the following message body:

 

Figure 13: Original validatelogincredentials Request

 

Again, this can be compressed down to only the following required values:

 

Figure 14: validatelogincredentials Compressed Request

 

Submitting the authentication request to the endpoint allows for a verbose response to be returned in the JSON Status object. The content in this response is read by the HUB agent and is typically reflected directly within the app.

 

Figure 15: validatelogincredentials Status Response

 

Depending on the environment's configuration, this response could allow for user enumeration. During research of this vulnerability, it was discovered that the ability to enumerate users is dependent on the authentication integrator and configuration of the endpoint. If functional, user enumeration would contain the following indicators:

 

Figure 16: validatelogincredentials - Valid User Response

 

Figure 17: validatelogincredentials - Invalid User Response

 

At the time of writing, not all authentication types have been enumerated and the full extent of user enumeration is unknown.

 

Also, the CAPTCHA validator (of consecutive authentication requests) was discovered to be linked to the InternalIdentifier or the Universal Device ID (UDID) value and the active SID. By resetting these values for each request, it is possible to successfully execute authentication attempts against this endpoint without any identity protections.

 

The secondary authentication endpoint of authenticationendpoint.aws is leveraged within two functions for the Boxer email agent: registration and authentication. As part of the AirWatch configuration, it is possible to bypass the Intelligence HUB application altogether and directly register users through the Boxer application. AirWatch has indicated the Boxer application only supports SFA and is incapable of supporting MFA in its current form. Based on this understanding, Boxer represents a perpetual SFA attack interface and can be leveraged to bypass all MFA protections implemented within the AirWatch product suite.

 

 

Figure 18: Boxer Registration Authentication Request

 

Both the Boxer registration and authentication API functions leverage the same API endpoint of authetnicationendpoint.aws. The variable factor in this request is the Request Header Content-Type value. During the registration process, this value is populated as UTF-8, allowing for the submission of an XML formatted message body. This communication is a transactional request and does not require any prior authorization to being performed.

 

The Boxer authentication endpoint contains the following request message body:

 

Figure 19: Boxer Authentication Request

 

The Boxer authentication request is triggered by modifying the Request Header Content-Type to be application/json and submitting a JSON object in the request. Both the registration and authentication endpoints contain the following submission variables:

 

 

Additionally, in both instances, the server responds back with a JSON message body:

 

 

Examining the response StatusCode, it is possible to perform limited user enumeration and/or SFA. Research against this API has identified the following StatusCode values:

 

 

This API is publicly accessible and at the time of writing, AirWatch does not provide any functionality to disable access to this communication endpoint and/or disable the Boxer service all together. It may be possible to disable Boxer registration services; however, AirWatch was unable to provide a test environment to confirm this.

 

Based on these response codes, it is possible for an attacker to enumerate through a list of values containing random GroupID or Username values and successfully execute a SFA attack. To fully weaponize this attack surface, Optiv has created airCross as a PoC toolkit for performing GroupID and SFA attempts against an AirWatch environment.

 

Upon discovering these deficiencies, we reported them to VMWare’s security team. During conversations of the vulnerability, VMWare security personnel indicated it did not represent a deficiency with the product's functionality and was not considered a security issue that would be remediated. Instead, VMWare provided several mitigation steps that could be introduced into the environment:

 

 

 

Mitigations

My research on this issue has been unable to validate if any of the suggested mitigation steps would reduce or eliminate the SFA / MFA bypass attack surface. Based on this understanding, the following recommendations can be implemented to reduce the MDM attack vector:

 

 

 

Vulnerability Disclosure Timeline

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

 

 

References

airCross