CVE-2020-15505

What is MobileIron Core?

MobileIron Core (now Ivanti Endpoint Manager Mobile, or EPMM) is an on-premises Unified Endpoint Management (UEM) platform deployed as a virtual or physical appliance. Organizations use it to enroll, configure, and manage iOS, Android, macOS, and Windows devices across their workforce — enforcing mobile security policies, distributing enterprise applications, and controlling access to corporate resources. MobileIron held approximately 9–12% of the global enterprise mobility management market at time of disclosure, with its on-premises Core product widely deployed in government agencies, healthcare organizations, and defense-sector enterprises.

The vulnerability affects four product components:

• MobileIron Core / Connector — the central management server (policy engine, device registry, admin console) and its directory-bridge component
• MobileIron Sentry — the inline mobile security gateway that proxies all managed device traffic to backend enterprise systems (Exchange, SharePoint, per-app tunnels)
• Monitor and Reporting Database (RDB) — the reporting component aggregating device compliance and audit data

MDM servers are internet-accessible by design — enrolled devices check in from anywhere — and are highly privileged, holding enterprise certificates, VPN credentials, and the ability to push arbitrary configuration to every managed device. Compromising one server effectively compromises every endpoint in the managed fleet.

Overview

CVE-2020-15505 is an unauthenticated remote code execution vulnerability in MobileIron Core and related products. The attack exploits a differential between how Apache httpd and Apache Tomcat parse URI paths containing /.;/ sequences. Apache's rewrite rules block unauthenticated access to /mifs/services/ paths — but a request to /mifs/.;/services/LogService passes through Apache (no rule match) and is received by Tomcat as /mifs/services/LogService. The LogService Hessian RPC endpoint deserializes the request body using a Groovy MethodClosure gadget chain, executing an attacker-controlled command as the Tomcat service user.

The vulnerability was discovered by Orange Tsai (DEVCORE) and patched in June 2020. Following full public disclosure in September 2020, Chinese and Iranian nation-state actors began exploiting it against US government and defense targets. NSA, CISA, and the UK NCSC all issued specific advisories about active exploitation. The CISA KEV catalog was launched on November 3, 2021 with CVE-2020-15505 among its first batch — a reflection of the well-documented, sustained exploitation that had occurred over the preceding year.

Affected Versions

Patches were released June 15, 2020.

Technical Details

The root cause is a URI parsing differential between Apache httpd and Apache Tomcat, a class of bypass documented generically by Orange Tsai in his "Breaking Parser Logic" talk at Black Hat USA 2018 and applied specifically to MobileIron in this disclosure.

The ACL bypass (/.;/ trick):

Apache httpd's rewrite rules check for /mifs/services/ in the request URI path and block unauthenticated access. Apache normalizes /.;/ as part of the path and does not match it against the rule. Tomcat parses the semicolon as the start of query parameters and strips it during path resolution, effectively treating /mifs/.;/services/LogService as /mifs/services/LogService. The request reaches the protected Hessian RPC endpoint without triggering any Apache ACL.

The Hessian deserialization gadget chain:

The LogService endpoint accepts POST requests with Content-Type: x-application/hessian. It deserializes the request body without adequate type checking. The exploit gadget chain:

1. Outbound JNDI injection — blocked in restricted-network environments since Java 2018 (trustURLCodebase restrictions)
2. Fallback: Tomcat BeanFactory + GroovyShell — MobileIron shipped with Groovy 1.5.6, which lacks the readResolve() fix from CVE-2015-3253
3. A Groovy MethodClosure gadget executes the attacker's command string when the deserialized object graph is constructed
4. Commands execute as the tomcat user (uid=101) on the host Linux system (typically CentOS 7)

The Facebook bug bounty incident demonstrated that even in environments blocking outbound JNDI lookups, the local BeanFactory + GroovyShell path achieves RCE without any outbound connectivity — hardening the exploit for restricted enterprise networks.

CWE-706 (Use of Incorrectly-Resolved Name or Reference): The application relies on a name resolution mechanism (URI path parsing) that is handled differently by two components in the stack (Apache vs. Tomcat), allowing an attacker to reach resources that should be restricted.

Attack characteristics:

• Authentication required: None
• Network reach: Remote, HTTPS (port 443 / 8443)
• Complexity: Low — one GET-like bypass followed by one POST with crafted Hessian body
• Interaction required: None
• Execution context: tomcat user — sufficient for full MDM server access and pivoting to managed device credentials

Discovery

Cheng-Da Tsai ("Orange Tsai"), Principal Security Researcher at DEVCORE (戴夫寇爾), Taiwan, discovered and reported all three MobileIron vulnerabilities (CVE-2020-15505, CVE-2020-15506, and CVE-2020-15507) to MobileIron on April 3, 2020. MobileIron patched and disclosed on June 15, 2020.

On July 2, 2020 — just 17 days after patch release — Orange Tsai found Facebook's production MobileIron Core server still unpatched and exploited it under Facebook's bug bounty program. The exploitation popped a shell as tomcat and demonstrated pivot access to Facebook's internal network. On September 12, 2020, Orange Tsai published the full technical write-up, "How I Hacked Facebook Again! Unauthenticated RCE on MobileIron MDM," covering the /.;/ bypass, the Hessian gadget chain, and the Facebook intrusion chain in detail. Public PoC exploits appeared on GitHub within days of the write-up.

The Metasploit module exploit/linux/http/mobileiron_mdm_hessian_rce (by wvu-r7, crediting Orange Tsai, iamnoooob, and rootxharsh) was merged to the public framework on January 29, 2021.

Exploitation Context

Scale of exposure: Approximately 5,000 MobileIron Core servers were publicly internet-exposed at time of disclosure. Roughly 40% — approximately 2,000 servers — remained unpatched as of late October 2020, four months after patches were available.

Nation-state targeting:

• CISA/FBI Advisory AA20-283A (October 9, 2020): Documented APT actors chaining CVE-2020-15505 with Zerologon (CVE-2020-1472) to attack US federal agencies and state/local/tribal/territorial (SLTT) government networks. At least one intrusion reached election support systems. The attack chain: MobileIron RCE for initial access → Zerologon for domain privilege escalation → full Active Directory compromise.
• NSA Advisory (October 20, 2020): Listed CVE-2020-15505 among 25 vulnerabilities known to be actively exploited by Chinese state-sponsored actors targeting US Department of Defense networks, national security systems, and the defense industrial base.
• UK NCSC Alert (November 23, 2020): Public warning that APT nation-state groups and cybercriminals were actively exploiting CVE-2020-15505, naming targeted sectors as healthcare, local government, logistics, and legal.
• CISA AA21-209A (July 28, 2021): Listed CVE-2020-15505 in the top routinely exploited vulnerabilities of 2020–2021.

No specific threat group designations (APT10, APT41) are attributed in public reporting for this CVE specifically, but the NSA advisory contextualizes it within Chinese Ministry of State Security-attributed campaigns.

First exploitation: Active exploitation was first observed September 24, 2020, originating from an Azure IP using the Nuclei scanning tool — approximately 12 days after Orange Tsai's public write-up. The gap between patch release (June 15) and first observed exploitation (September 24) reflects the time needed to develop weaponized tooling from the public write-up rather than any lack of attacker interest.

Remediation

1. Patch to the fixed versions listed in the Affected Versions table above; apply the MobileIron Core, Connector, Sentry, and RDB patches as a set — all four components are affected
2. Restrict the management interface — place the MobileIron admin portal (port 8443) behind a VPN or restrict it to authorized management IP ranges; the enrollment interface (port 443) should be proxied through a WAF configured to block URI paths containing /.;/
3. Network isolation — MobileIron servers should not have unrestricted outbound internet access; limit outbound connections to known device management endpoints only
4. Deploy IDS signatures — alert on HTTP requests containing /.;/ in the URI path to MobileIron hosts (Emerging Threats signature targets hex |2f 2e 3b 2f|)
5. Review access logs — look for HTTP POST requests to /mifs/.;/services/LogService or /mics/.;/services/ with Content-Type: x-application/hessian; unexpected tomcat-context process spawns (sh, bash, curl, wget) are indicators of exploitation
6. Audit managed device credentials — if the server may have been compromised, treat all managed device certificates, VPN credentials, and ActiveSync tokens distributed via MDM profiles as potentially exfiltrated; rotate all secrets and review Active Directory for unauthorized accounts or privilege escalation
7. MobileIron Cloud customers required no action — the SaaS platform was patched by MobileIron before public disclosure