Ivanti Server-Side Request Forgery to Auth-Bypass
Overview
Ivanti disclosed a couple more vulnerabilities — server-side request forgery (CVE-2024-21893) and a privilege escalation (CVE-2024-21888) vulnerability. This disclosure comes only a few weeks after confirming an exploit chain impacting Ivanti Connect Secure and Ivanti Policy Secure. Ivanti has acknowledged that CVE-2024-21893 has impacted certain customers in targeted instances.
The SonicWall Capture Labs threat research team became aware of a server-side request forgery (SSRF) in Ivanti Connect Secure, Ivanti Policy Secure and ZTA gateways affecting all supported versions, including 9.x and 22.x. We assessed its impact and developed mitigation measures for the vulnerability. Since the previously disclosed vulnerabilities (CVE-2023-46805 and CVE-2024-21887) are already being exploited in the wild and under the scrutiny of threat actors, this SSRF vulnerability – a bypass to the previous mitigation – demands immediate action by upgrading the instances to the latest versions. The official patches have been released by Ivanti for all the vulnerabilities.
CVE Details
This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2024-21893.
The CVSS score is 8.2 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N), based on the following metrics:
• Attack vector is network.
• Attack complexity is low.
• Privileges required is none.
• User interaction is none.
• Scope is unchanged.
• Impact of this vulnerability on data confidentiality is high.
• Impact of this vulnerability on data integrity is low.
• Impact of this vulnerability on data availability is none.
Technical Overview
This vulnerability, an SSRF in the Security Assertion Markup Language (SAML) component of Ivanti products, is essentially a bypass of the mitigation for the original exploit chain. The threat actors can leverage CVE-2024-21893 to execute the original exploit chain involving CVE-2023-46805 and CVE-2024-21887 by circumventing the fix.
To understand the root cause, it is important to check the SAML endpoints, which do not require authentication as the vulnerability details indicate the privilege requirement is none. It is worth noting that the endpoint /dana-ws/saml20.ws can be accessed without authentication by examining the web server code provided by rapid7 as seen in Figure 1.
Figure 1: Web Server Code indicating unauthenticated endpoints, source: rapid7
Another piece of code, as seen in Figure 2, defining the function doDispatchRequest reveals that the unauthenticated http POST request targeting SAML endpoints /dana-ws/saml.ws, /dana-ws/saml20.ws, and /dana-ws/samlecp.ws are being sent to a service saml-server by doDispatchRequest. This request contains SOAP-based SAML components which are processed by saml-server and further transformed into an XML object by the function SoapHandler. Interestingly, the XML processing is being carried out by an outdated version 3.0.2 of external library called xmltooling, which in this context is vulnerable to the SSRF via a crafted KeyInfo element as mentioned in the CVE-2023-36661 description. This flaw can be leveraged to post an unauthenticated HTTP request containing malformed XML data to exploit underlying SSRF vulnerability in xmltooling as a means to circumvent the mitigation.
Figure 2: Code to process SAML requests, source: rapid7
Triggering the Vulnerability
Triggering this SSRF vulnerability requires a SOAP envelope to be sent to a SAML endpoint, preferably /dana-ws/saml20.ws which does not need authentication. The envelope includes a signature element which will be processed by the vulnerable xmltooling library. Furthermore, the signature contains a KeyInfo element, which can be exploited to SSRF according to an advisory published by the vendor Shibboleth. Additionally, the child element RetrievalMethod of KeyInfo let us access a remote resource using an HTTP GET request by specifying a URI in an attribute called URI, allowing a threat actor to insert an attack vector to exploit SSRF. For instance, the sample request in Figure 3 below can be used to send a request on behalf of the appliance.
Figure 3: Sample request to trigger SSRF
Exploitation
The HTTP request illustrated in Figure 3 can be converted into the pre-auth RCE by leveraging the command injection vulnerability (CVE-2024-21887) from the original exploit chain. The endpoint /api/v1/license/keys-status is one of the vulnerable endpoints which allows an attacker to inject commands using a simple GET request as illustrated in our previous blog post. Since the request is going to be originated from the same appliance, we can use localhost as a target IP to avoid the need for authentication. The plain request will look like the request below to yield a reverse shell back to an attacker’s machine.
Figure 4: Request
The above line needs to be URI decoded to get processed by the web server and replaced with the “Target URI” in the request shown in Figure 3, making the final request with the RCE payload look like Figure 5 below.
Figure 5: Request to trigger RCE using SSRF
SonicWall Protections
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signature has been released:
- IPS:4266 Ivanti Connect Secure Server-Side Request Forgery
- IPS:4268 Ivanti Connect Secure Server-Side Request Forgery 2
Remediation Recommendations
Considering the severe consequences of this vulnerability, the users of affected products are strongly encouraged to apply the patches as published in the vendor advisory.
Relevant Links
- Rapid7 Blog
- Exploitation analysis by mandiant
- SonicWall’s blog on initial exploit chain
- Shibboleth’s advisory on SSRF vulnerability in xmltooling library
- Advisory by Ivanti
