In continuation with first part of blog post on vulnerabilities identified on Ivanti VPN products, that shook IT infra of many large organizations towards at the end of 2023, we will be looking at three more vulnerabilities that Ivanti further disclosed on 31st January and 21st February in this second and conclusive part of this blog post series.
As stated on previous post, on 31st January when Ivanti successfully released patch for top two vulnerabilities after long delay, they also disclosed two more vulnerabilities which were identified as CVE-2024-21888 (CVSS v3: 8.8, Critical) and CVE-2024-21893 (CVSS v3: 8.2, Critical). Ivanti also stated in their vulnerability disclosure that they were already aware of small number of customers who had been impacted by CVE-2024-21893, which makes this SSRF (server-side request forgery) vulnerability third one in the list to have zero-day exploit. However, this time Ivanti published patches also along with vulnerability disclosure.
Later on 31st January itself CISA also released a Supplemental Direction V1 mandating all agencies running affected products to disconnect all instances of Ivanti Connect Secure and Ivanti Policy Secure solution products from agency networks no later than 11:59 PM of 2nd February, 2024, while their earlier published Emergency Directive ED 24-01 had asked agencies only to check their Ivanti connect secure VPN devices and get them to factory default state if found compromised.
On 8th February Ivanti disclosed yet another vulnerability impacting Ivanti Connect Secure product with id CVE-2024-22024 (CVSS v3: 8.3, Critical) and this was an XML external entity or XXE vulnerability in their SAML Component which allowed an attacker to access certain restricted resources without authentication.
Privilege Escalation Vulnerability (CVE-2024-21888):
On 31st January 2024, Ivanti in a blog post had published which had high level information about this vulnerability, which upon successful exploitation could lead to escalation or privileges of threat actor. As per the post, the vulnerability was discovered in Web component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure (9.x, 22.x). While this vulnerability was proactively discovered by Ivanti during their ongoing investigation into previous vulnerabilities. However, they had also stated that till the time of publishing their post, they were not aware of any known abuse of this vulnerability by any threat actor.
However, the good part of this vulnerability announcement is unlike previous vulnerability disclosures, Ivanti had also published patch for fixing this vulnerability which greatly minimized its impact on IT industry.
Server Side Request Forgery (CVE-2024-21893):
This is yet another vulnerability that was also declared by Ivanti on 31st January 2024. But unlike previous vulnerability for this vulnerability declaration, Ivanti had also stated that they were aware of small number of customers who had been impacted by this vulnerability, and a successful exploitation of this vulnerability could give threat actors to access certain restricted resources without authentication. More information about exploitability of this vulnerability can be found in a blog post by Rapid7. As per the post, the API endpoint "/dana-ws/saml20.ws" is vulnerable to this attack. This vulnerability when combined with previously known vulnerability with id CVE-2024-21887, leads to unauthenticated remote code execution and could provide complete shell access to threat actor.
Popular penetration testing framework Metasploit has also provided a ready to use module to exploit this vulnerability and same can be found at "exploit/linux/http/ivanti_connect_secure_rce_cve_2024_21893", on other hand other security researchers also published standalone exploit codes for this vulnerability and one such code can be found in here in public GitHub page of h4x0r-dz
XML eXternal Entity (XXE) Vulnerability (CVE-2024-22024):
This was the last critical vulnerability that got published in that set of vulnerabilities till February 2024. Successful exploitation of this vulnerability also gave threat actors access to certain restricted resources without authentication, and there was no indication given by Ivanti if this vulnerability was exploited prior to disclosure and release of the patch. However, later an exploit for this vulnerability was published by 0dteam in a GitHub page.
Mitigations:
While patches for all the critical vulnerabilities disclosed earlier were released by 8th February, but still newer version of some patches were released again on 14th February which provided necessary protection from known ways in which the bugs can be exploited, and a blog post was released by Ivanti providing comprehensive information about vulnerabilities and patch.
More Vulnerabilities:
After a break of about one and half months, Ivanti again published a set of 4 vulnerabilities for same products i.e., Ivanti Connect Secure (ICS), and Ivanti Policy Secure gateways on 2nd April 2024. This time the majority of vulnerabilities resulted in Denial of Service when exploited.
| CVE | Type | Impacted Technology | Potential Impact | CVSS Score |
| CVE-2024-21894 | Heap overflow vulnerability | IPSec component of Ivanti Connect Secure | Execution of arbitrary code | 8.2 |
| CVE-2024-22052 | Null pointers de-reference vulnerability | IPSec component of Ivanti Connect Secure | DoS attack | 7.5 |
| CVE-2024-22053 | Heap overflow vulnerability | IPSec component of Ivanti Connect Secure | DoS attack or read contents from memory | 8.2 |
| CVE-2024-22023 | XML entity expansion or XEE vulnerability | SAML component of Ivanti Connect Secure and Ivanti Policy Secure | Limited-time DoS | 5.3 |
Ivanti also clarified in their post that as of disclosing these vulnerabilities, they were not aware of any active exploitation of this vulnerability, and they had also released patches for it at the same time.
Criticism towards Ivanti:
Other than massive criticism that Ivanti received for releasing delayed patches in case of first set of disclosed vulnerabilities, they also received criticism from security community for hiding multiple vulnerabilities under one CVE id.
According to Section 7.2 of the CNA's rules, the authority clearly sets out its expectations of vendors when reporting vulnerabilities.
"The CVE Program expects separate CVE IDs to be assigned to independently fixable vulnerabilities. If one vulnerability can be fixed without fixing the other, then the vulnerabilities should receive separate CVE IDs."
However, a security researcher identified more than 5 vulnerabilities that were hidden under one id CVE-2024-21887 as per the post by the researcher.
When The Registrar asked clarification for such behavior from Ivanti, they said
"In this instance, to avoid confusion, we chose not to have multiple CVE numbers reserved for vulnerabilities with the same description, same CVSS score, and same fix in the same part of the code.
Instead, the CVE description noted that there were multiple vulnerabilities in that section of the code. These vulnerable endpoints are all successfully blocked by the mitigation and will all be resolved in the patches that we are releasing soon."