[ad_1]
Read more on Ivanti vulnerabilities:
Bad news continues to pile up for Utah-based IT software provider Ivanti as a new vulnerability has been discovered in its products.
On February 8, Ivanti disclosed a new authentication bypass vulnerability impacting its Connect Secure, Policy Secure, and ZTA gateways.
This new vulnerability, identified as CVE-2024-22024, is the latest of 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 Ivanti’s gateways’ Security Assertion Markup Language (SAML) component, the part of the gateway software that handles this communication and helps ensure secure authentication.
By exploiting this flaw, remote attackers can gain access to restricted resources on unpatched appliances without requiring any user interaction or authentication.
Although the company claimed the vulnerability was not being actively exploited, it urged its users to implement the mitigation processes the company released in another advisory.
On February 14, content delivery network (CDN) provider Akamai published a report in which it observed malicious activity targeting this new vulnerability.
Akamai said it saw a peak of 240,000 requests and 80 IPs attempting to send payloads on February 11.
Akamai commented: “So far, we have only been seeing payloads similar to the original proof-of-concept (PoC) [exploit] published by watchTowr.”
WatchTowr, a red teaming firm, conducted a proof-of-concept experiment to see how threat actors could exploit CVE-2024-22024. The company published its result on February 9.
On the same day, the Shadowserver Foundation said it observed over 3900 Ivanti endpoints vulnerable to CVE-2024-22024.
Ivanti Denies CVE-2024-22024 Exploitation
In an FAQ blog post also published on February 14, Ivanti insisted that it hasn’t seen any exploitation of the newest vulnerability, CVE-2024-22024.
“It is unfortunate that media reports continue to cover statements and unverified numbers from third parties that are incorrect or inflated,” the company said in the blog post.
Ivanti assessed that there has been 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 the initial vulnerabilities disclosed on 10 January were exploited by threat actors. While the initial impact was very limited, we saw a sharp increase in threat actor activity and security researcher scans following public disclosure of the issue, indicating global customer impact due to CVE-2023-46805, CVE-2024-21888 and CVE-2024-21893,” the Ivanti spokesperson added.
Sean Wright, head of application security at Featurespace, criticized Ivanti’s response on social media.
Wright said on X that Ivanti should have given substantial evidence “backing up how they came to [the] conclusion how the information was incorrect.”
Ivanti Pulse Secure Accused of Running on an Outdated OS
On February 15, supply chain security provider Eclypsiusm shared the result of reverse engineering work it conducted after acquiring an Ivanti Pulse Secure firmware version 9.1.18.2-24467.1.
Eclypsium’s objective was to leverage a PoC exploit for CVE-2024-21893 that was released by Rapid7 on February 2 to obtain a reverse shell to the PSA3000 appliance, subsequently exporting the device image for follow-on analysis using the EMBA firmware security analyzer.
The firm concluded: “Pulse Secure runs an 11-year-old version of Linux which hasn’t been supported since November 2020.”
Concerns Over Legacy Software Running in Critical Infrastructure
Speaking to Infosecurity, Jamie Boote, associate principal software security consultant at the Synopsys Software Integrity Group, commented: “The big scary sounding zero days get the vast majority of the media attention. The reality, however, is that the boring problem of unpatched vulnerabilities and legacy software silently running in critical infrastructure represents a much larger risk waiting to be uncovered by an enterprising attacker.
He explained that security practitioners meet many hurdles when they want to modernize their organization’s technical stack, and these projects can be pushed back for months, if not years.
“Firmware is even more tricky because IT teams and Ops may not have a good view into network appliances like routers, boundary devices, and security appliances, so without proactive investigation into those devices, IT may not even realize that these appliances have silently reached their 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 open source code.
“Ivanti provides protection by developing and releasing patches to make this code secure within the 9.x version of the product. The hardware for the 9.x version does not have enough CPU to run a newer Linux kernel and as such the kernel limitations requires this older open source code to used. The newer 22.x version of Ivanti Connect Secure is built on a new Linux kernel and does not have the older versions of open source code in it. We officially released an End of Life Notification for the 9.x hardware and software product in July 2022.”
Ivanti Denies CISA Takedown Requirement
Finally, Ivanti denied claims that the US Cybersecurity and Infrastructure Agency (CISA) had told US federal agencies to replace Ivanti products.
“CISA’s directive was misinterpreted by media who only reported on the first step of the instructions,” the company said. “CISA made updates to their directive to correct this, and then further updated last week to make absolutely clear that you can turn the product on after patching.”
The CISAs full instructions are consistent with Ivanti’s own instructions and recommendations for its customers from 31 January.
“We support the Emergency Directive issued by CISA on 9 February and worked with CISA to develop the content,” the Ivanti said.
The instructions are as follows:
- Take the solution out of production and look for signs that the threat actor took additional action;
- Factory reset, upgrade and patch;
- Put the appliance back into production.
[ad_2]
Add comment