A July 2024 bulletin from multiple U.S. government agencies indicates that North Korean state-sponsored attackers have demonstrated interest in this vulnerability — not immediately clear whether it was exploited or just used in reconnaissance/target selection: https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-207a

Analysis

We analyzed an older unsupported version of MobileIron Core version 11.2.0.0-31 which is vulnerable to CVE-2023-35078. The vulnerability allows for remote unauthenticated API access due to an access control bypass vulnerability.

The server leverages an Apache reverse proxy to forward requests to a Tomcat server running a Java web application which is built on top of the Spring framework. For an incoming API request, Apache will pass-through requests for /api/v2/ to /mifs/rs/api/v2/ in the “MI File Service” (mifs) web application:

  RewriteRule         ^/api/v2/(.*)$                      /mifs/rs/api/v2/$1                [PT]

The mifs web application has the following in its security.xml configuration file:

  <sec:http pattern="/aad/**" security="none" create-session="stateless"/>

  <!-- ...snip... -->

  <!-- For web service API -->
  <sec:http pattern="/rs/api/v2/**" create-session="stateless" use-expressions="false" disable-url-rewriting="false">
    <sec:http-basic/>
    <sec:csrf disabled="true"/>
  </sec:http>

This enforces HTTP Basic authentication on API requests. We can note that requests to the url pattern "/aad/**" are set to security="none", which disables the security filter chain for the request, if the request is handled. As this appears before the security filter for the API paths, it appears a subtle vulnerability is then introduced by how the Azure Active Directory (aaddispatcher) servlet handles requests. The web application’s web.xml file contains a servlet mapping that will process all requests that match the URL pattern "/aad/*" (which will be "/mifs/aad/*" before it is passed to the Tomcat server):

  <servlet>
    <servlet-name>aaddispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>
        WEB-INF/aadenrollment-servlet.xml
      </param-value>
    </init-param>
    <load-on-startup>101</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>aaddispatcher</servlet-name>
    <url-pattern>/aad/*</url-pattern>
  </servlet-mapping>

If an attacker sends a request to an API endpoint such as /mifs/aad/api/v2/ping, then the API can be called successfully without authentication.

It appears that the aaddispatcher servlet processes the request, which disables the security filter chain from processing any more filters and no authentication is performed. For reasons currently unknown, the request is then serviced by the servlet that handles API requests (CXFServlet).

For example, if an attacker attempts to access the endpoint /api/v2/ping unauthenticated, the request fails with a 401 unauthorized response.

C:\>curl -k https://192.168.86.103/api/v2/ping
{"messages":[{"type":"Error","messageKey":"com.mobileiron.vsp.messages.http.401","localizedMessage":"Unauthorized"}]}

However if an attacker attempts to access the endpoint /mifs/aad/api/v2/ping the request succeeds.

C:\>curl -k https://192.168.86.103/mifs/aad/api/v2/ping
{"results":{"apiVersion":2.0,"vspVersion":"VSP 11.2.0.0 Build 31 "}}

Indicators of Compromise

The following indicators of compromise are present in the Apache HTTP logs stored on the appliance.

The log file /var/log/httpd/https-access_log will have an entry showing a request to a targeted API endpoint, containing /mifs/aad/api/v2/ in the path and showing a HTTP response code of 200. Blocked exploitation attempts will show a HTTP response code of either 401 or 403. For example:

192.168.86.34:58482 - - 2023-07-27--13-01-39 "GET /mifs/aad/api/v2/ping HTTP/1.1" 200 68 "-" "curl/8.0.1" 2509

Remediation

Ivanti has released the following patches to address the issue:

• 11.10.0.2
  
• 11.9.1.1
  
• 11.8.1.1
  

Product versions no longer receiving support are also affected, and Ivanti has released a workaround as part of their response.