Ivanti warns of critical vulnerability in its popular line of endpoint protection software

RCE STANDS FOR REMOTE CODE EXECUTION —

Customers of the Ivanti Endpoint Protection Manager should patch or mitigate ASAP.

Dan Goodin
– Jan 5, 2024 10:33 pm UTC

Software maker Ivanti is urging users of its end-point security product to patch a critical vulnerability that makes it possible for unauthenticated attackers to execute malicious code inside affected networks.

The vulnerability, in a class known as a SQL injection, resides in all supported versions of the Ivanti Endpoint Manager. Also known as the Ivanti EPM, the software runs on a variety of platforms, including Windows, macOS, Linux, Chrome OS, and Internet of Things devices such as routers. SQL injection vulnerabilities stem from faulty code that interprets user input as database commands or, in more technical terms, from concatenating data with SQL code without quoting the data in accordance with the SQL syntax. CVE-2023-39336, as the Ivanti vulnerability is tracked, carries a severity rating of 9.6 out of a possible 10.

“If exploited, an attacker with access to the internal network can leverage an unspecified SQL injection to execute arbitrary SQL queries and retrieve output without the need for authentication,” Ivanti officials wrote Friday in a post announcing the patch availability. “This can then allow the attacker control over machines running the EPM agent. When the core server is configured to use SQL express, this might lead to RCE on the core server.”

RCE is short for remote code execution, or the ability for off-premises attackers to run code of their choice. Currently, there’s no known evidence the vulnerability is under active exploitation.

Ivanti has also published a disclosure that is restricted only to registered users. A copy obtained by Ars said Ivanti learned of the vulnerability in October. The private disclosure in full is:

It’s unclear what “attacker with access to the internal network” means. Under the official explanation of the Common Vulnerability Scoring System, the code Ivanti used in the disclosure, AV:A, is short for “Attack Vector: Adjacent.” The scoring system defined it as:

The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical or logical (e.g. local IP subnet) network…

In a thread on Mastodon, several security experts offered interpretations. One person who asked not to be identified by name, wrote:

Everything else about the vulnerability [besides the requirement of access to the network] is severe:

Attack complexity is low
Privileges not required
No user interaction necessary
Scope of the subsequent impact to other systems is changed
Impact to Confidentiality, Integrity and Availability is High

Reid Wightman, a researcher specializing in the security of industrial control systems at Dragos, provided this analysis:

Speculation but it appears that Ivanti is mis-applying CVSS and the score should possibly be 10.0.

They say AV:A (meaning, “adjacent network access required”). Usually this means that one of the following is true: 1) the vulnerable network protocol is not routable (this usually means it is not an IP-based protocol that is vulnerable), or 2) the vulnerability is really a person-in-the-middle attack (although this usually also has AC:H, since a person-in-the-middle requires some existing access to the network in order to actually launch the attack) or 3) (what I think), the vendor is mis-applying CVSS because they think their vulnerable service should not be exposed aka “end users should have a firewall in place”.

The assumption that the attacker must be an insider would have a CVSS modifier of PR:L or PR:H (privileges required on the system), or UI:R (tricking a legitimate user into doing something that they shouldn’t). The assumption that the attacker has some other existing access to the network should add AC:H (attack complexity high) to the score. Both would reduce the numeric score.

I’ve had many an argument with vendors who argue (3), specifically, “nobody should have the service exposed so it’s not really AV:N”. But CVSS does not account for “good network architecture”. It only cares about default configuration, and whether the attack can be launched from a remote network…it does not consider firewall rules that most organizations should have in place, in part because you always find counterexamples where the service is exposed to the Internet. You can almost always find counterexamples on Shodan and similar. Plenty of “Ivanti Service Managers” exposed on Shodan for example, though, I’m not sure if this is the actual vulnerable service.

A third participant, Ron Bowes of Skull Security, wrote: “Vendors—especially Ivanti—have a habit of underplaying security issues. They think that making it sound like the vuln is less bad makes them look better, when in reality it just makes their customers less safe. That’s a huge pet peeve. I’m not gonna judge vendors for having a vuln, but I am going to judge them for handling it badly.”

Ivanti representatives didn’t respond to emailed questions.

Putting devices running Ivanti EDM behind a firewall is a best practice and will go a long way to mitigating the severity of CVE-2023-39336, but it would likely do nothing to prevent an attacker who has gained limited access to an employee workstation from exploiting the critical vulnerability. It’s unclear if the vulnerability will come under active exploitation, but the best course of action is for all Ivanti EDM users to install the patch as soon as possible.