MobileIrony backdoor allows complete takeover of mobile security product and endpoints.
MobileIron aka EPMM, a widely used Mobile Device Management product from Ivanti, has a crucial flaw — it has an API endpoint which requires no authentication whatsoever. Ivanti customers should patch this zero day now.
It became clear this was being exploited in the wild a few days ago, after the Norwegian government disclosed 12 of their ministries were hacked using this MobileIron zero day, and they had to tell Ivanti about the issue.
In this blog we take a look at MobileIrony, aka CVE-2023–35078.
Where the issue began
Many years ago, MobileIron aka Ivanti Endpoint Manager Mobile (EPMM) gained support for AzureAD integration in a product update, allowing the device is be Azure AD domain joined. It appears this code introduced the vulnerability, as it allowed unrestricted remote access to the entire MobileIron API as an admin user — without suppling any credentials.
It is unclear to me how this code was added and the consequences not realised in later security audits, code reviews and security testing. Unless there weren’t any. I think it is fair to say it may have been a backdoor or bugdoor.
The scope of the issue
Thousands of large organisations — including governments worldwide and critical infrastructure- use MobileIron. It is incredibly popular in the West. This includes double digit numbers of government organisations in the UK and US each… and apparently much of Germany.
Identifying your systems to patch
My suggestion is look on Shodan for the query “Path=/mifs”, then pivot with additional terms such as org:YourASN or ssl:YourCompanyName
For example, “Path=/mifs” ssl:.gov
I saw a favicon search doing the rounds on Twitter, but that is not complete.
Identifying version numbers remotely
How we got here with disclosure
In a slightly weird bit of disclosure, Ivanti only documented the vulnerability behind a paid support forum — opting not to use their security advisory blog.
It took somebody called collysucker/fthy to mention the issue online for the community to wake up:
Vendors — this is a very bad idea. Security teams at many organisations — the type of organisations who are Ivanti customers — are not MDM sysadmins. But they need to know about security vulnerabilities.
Additionally, MDM sysadmins are generally not sat on product support forums — nor are they usually responsible for processing security advisories. Ivanti effectively placed a PR timebomb under themselves here (or somebody else did).
Additionally, Ivanti have tried to lock technical information on how to check if you’ve been exploited behind a non-disclosure agreement. This may have been an attempt to stop people getting technical details to slow exploitation — but in reality, the already botched disclosure drew so much attention this is out of the window.
Ivanti didn’t mention the words “zero day” — but it’s a vulnerability being exploited without the product vendor knowing about the vulnerability. It’s a zero day.
If you fail to act transparently when disclosing a wide impact event, people will dig and you lose control of the messaging, too. Additionally, customers caught in the middle aren’t usually impressed.
To media they said they were “practicing responsible disclosure protocols”.. This is true, if the protocols have been rewritten to say ‘yolo, shush!’ instead of transparently communicate the risk and actions.
Since being criticised for this, Ivanti have disclosed the existence of the issue publicly:
They also released a public security advisory on their blog — but backdated it (it wasn’t there on Monday).
Ivanti describe the issue as being allowing threat actors to “make limited changes to the server.”
This contrasts with the US government’s advisory — which appears to be based on information sharing with Ivanti — who say: “An attacker can also make other configuration changes, including creating an EPMM administrative account that can make further changes to a vulnerable system”
These are wildly different statements with wildly different impacts to Ivanti’s customers. Being able to remotely, for example, create administrative accounts is bad. Customers should not be learning the true scope of issues from governments.
The vulnerability details
Because the entire API surface is opened without credential validation, it allows any of the MobileIron API to be used remotely. All you have to do is change the API path by a few characters. The API is publicly documented, the different endpoint path is all you need for exploitation.
For example, this allows you run LDAP queries, list user information including potential PII, add administrative users, replace system configuration and change the config of managed mobile devices — including software deployment, device locks and wiping.
All of this can be done with a curl request, or even using a web browser. This is an incredibly easy to exploit vulnerability.
For example, you can call /admins/users to list all admin users. You can call /devices to search all devices, and then /devices/wipe to wipe any device managed by MobileIron. You can use /admins/ldap_entities to search Active Directory inside the organisation.
It is a fundamental product defect that shoots apart the point of the product existing, and Ivanti’s customers should patch as soon as possible.
How wide is the public exploitation?
The reason I was able to find the API path is because my honeypot infrastructure was targeted.
The Norwegian government claim they were the first victim, but checking logs suggests this vulnerability has been used throughout 2023. Additionally, the vulnerable path is even documented on MobileIron’s support forum in multiple posts over prior years in AzureAD documentation. Ivanti themselves claim less than 10 organisations were impacted — but given the Norwegian government say 12 of their ministries were impacted, it tends to suggests the scope may be unclear.
As far as I can see, Ivanti have no telemetry on every API endpoint request — so simply may well not know how many customers were impacted. The vulnerability itself is extremely easy to find — I’m an idiot and I found it — so my verdict would be, again, patch now.
Currently this one is being played for secrecy by all involved, which is having the impact of minimizing the severity and discussion of vulnerability. I understand why; but I ponder if people trying to run around passing secret notes is really securing customers, or security industry theatre. I had a quick sample scan myself, and I found most organisations simply haven’t patched still.
What can vendors learn?
Transparency. If you have a big problem, pivot to transparency. I know every part of the corporate machine will pivot towards minimizing — but the road to minimizing a security vulnerability or incident is different to other types of corporate issues. If you can credibly place customer interests first, the long term outcome is almost always better in my experience. This should have been front and center on the public Ivanti blog, in my opinion.
What can customers learn?
Nothing is bulletproof — and sometimes the car you are driving doesn’t even have windows. There is irony that a product former called MobileIron apparently had a massive hole that nobody noticed. Hence the name MobileIrony. Drive vendors hard to say issues like this need clear and open comms. And always keep in mind that when the chips are down, security vendors will protect themselves first during security incidents in their own backyard.
