Learn more about Ivanti vulnerabilities:
The bad news continues to pile up for Utah-based computer software provider Ivanti as a new vulnerability has been discovered in its products.
February 8, Ivanti disclosed a new authentication bypass vulnerability affecting its Connect Secure, Policy Secure and ZTA gateways.
This new vulnerability, identified as CVE-2024-22024is the latest in a series of vulnerabilities discovered in several Ivanti products since mid-January 2024 – namely, in order of discovery, CVE-2023-46805, CVE-2024-21887, CVE-2024-21888 And CVE-2024-21893.
The vulnerability is due to a flaw in the SAML (Security Assertion Markup Language) component of Ivanti gateways, the part of the gateway software that manages this communication and helps ensure secure authentication.
By exploiting this flaw, remote attackers can access restricted resources on unpatched appliances without requiring any user interaction or authentication.
Although the company claimed that the vulnerability was not actively exploited, it urged its users to implement the mitigation processes published by the company in another opinion.
On February 14, content delivery network (CDN) provider Akamai released a report in which he observed malicious activity targeting this new vulnerability.
Akamai said it saw a spike of 240,000 requests and 80 IPs attempting to send payloads on February 11.
Akamai commented: “So far, we have only seen payloads similar to the original proof of concept (PoC) (exploit) released by watchTowr. »
WatchTowr, a red teaming company, conducted a proof-of-concept experiment to see how bad actors could exploit CVE-2024-22024. The company published its result on February 9.
The same day, the Shadowserver Foundation said it observed more than 3,900 Ivanti endpoints vulnerable to CVE-2024-22024.
Ivanti denies exploitation of CVE-2024-22024
Also in an FAQ blog post published on February 14, Ivanti insisted that it had not seen any exploitation of the latest vulnerability, CVE-2024-22024.
“It is unfortunate that the media continues to cover unverified third-party statements and figures that are incorrect or inflated,” the company said in its blog.
Ivanti felt there was confusion between the exploitation of CVE-2024-21893 and CVE-2024-22024 because both vulnerabilities are “in the same section of code.”
“We previously confirmed that the first vulnerabilities revealed on January 10 were exploited by malicious actors. Although the initial impact was very limited, we saw a sharp increase in threat actor activity and security researcher analysis following the public disclosure of the issue, indicating a global impact on customers due to CVE- 2023-46805, CVE-2024-21888 and CVE-2024-. 21893,” added the Ivanti spokesperson.
Sean Wright, application security manager at Featurespace, criticized Ivanti’s response on social media.
Wright said on that Ivanti should have provided substantial evidence “supporting how they reached the conclusion that the information was incorrect.”
Ivanti Pulse Secure accused of running on outdated operating system
On February 15, supply chain security provider Eclypsiusm shared the result of the reverse engineering work he performed after acquiring Ivanti Pulse Secure firmware version 9.1.18.2-24467.1.
Eclypsium’s goal was to exploit a PoC exploit for CVE-2024-21893 which was released by Rapid7 on February 2 to obtain a reverse shell for the PSA3000 appliance, subsequently exporting the device image for follow-up analysis using the EMBA Firmware Security Analyzer.
The company concluded: “Pulse Secure runs an 11-year-old version of Linux that has been unsupported since November 2020.”
Concerns about legacy software running in critical infrastructure
Talk to Information securityJamie Boote, Associate Principal Software Security Consultant at Synopsys Software Integrity Group, commented: “The big scary zero days attract the vast majority of media attention. The reality, however, is that the annoying problem of unpatched vulnerabilities and legacy software running silently in critical infrastructure represents a much greater risk waiting to be discovered by an enterprising attacker.
He explained that security professionals face many obstacles when they want to modernize their organization’s technical stack, and that these projects can be pushed back by months or even years.
“Firmware is even trickier because IT and operations teams may not have a good view of network devices such as routers, boundary devices and security appliances. So, without proactively investigating these devices, IT may not even realize that these devices have silently served their purpose. end of life.”
In its FAQ blog post, Ivanti denied this claim: “The Ivanti Connect Secure product is not vulnerable due to older versions of the open source code.
“Ivanti is providing protection by developing and releasing fixes to secure this code in version 9.x of the product. The 9.x hardware does not have enough CPU to run a newer Linux kernel, and as such the kernel’s limitations necessitate the use of this older open source code. The most recent version 22.x of Ivanti Connect Secure is based on a new Linux kernel and does not contain older versions of open source code. We have officially issued an end-of-life notification for the 9.x hardware and software product in July 2022.”
Ivanti refuses CISA withdrawal demand
Finally, Ivanti denied claims that the US Cybersecurity and Infrastructure Agency (CISA) had asked US federal agencies to replace Ivanti products.
“The CISA directive was misinterpreted by the media who only reported on the first step of the instructions,” the company said. “CISA updated their guidance to correct this, and then updated it last week to make it absolutely clear that you can activate the product after the patch is applied.”
The full CISA instructions are consistent with Ivanti’s own instructions and recommendations to its customers as of January 31.
“We support the emergency directive issued by CISA on February 9 and have worked with CISA to develop the content,” Ivanti said.
The instructions are as follows:
- Remove the solution from production and look for signs that the threat actor has taken additional action;
- Factory reset, upgrade and fix;
- Return the device to production.