On January 8, 2025, Ivanti published a security advisory for two vulnerabilities, CVE-2025-0282, and CVE-2025-0283, affecting Ivanti Connect Secure, Ivanti Policy Secure, and Ivanti Neurons for ZTA gateways.

Ivanti confirmed that CVE-2025-0282 was exploited in the wild by a threat actor targeting vulnerable instances of Ivanti Connect Secure. On January 8, 2025, Mandiant also published a blog post detailing the observed threat actor behavior, which began around mid December, 2024.

On January 10, 2025, security firm watchTowr published a blog detailing the root cause of CVE-2024-0282, along with a follow up blog post detailing an exploitation strategy to achieve RCE.

CVE-2025-0282 is a remote unauthenticated stack based buffer overflow, affecting the IF-T/TLS protocol handler of the HTTPS web server (TCP port 443 by default). The vulnerability allows an unauthenticated attacker to achieve RCE with the privileges of a non-root user called nr.

Ivanti patched a second vulnerability in the same advisory. CVE-2025-0283 is also a stack based buffer overflow, and allows for a local user to elevate their privileges. While the Ivanti advisory states that they are not aware of any exploitation of CVE-2025-0283, it is a coincidence that a local privilege escalation vulnerability was patched alongside an RCE vulnerability that gets remote code execution with limited privileges.

We reproduced CVE-2025-0282, and the RCE exploitation strategy described by watchTowr, against a Connect Secure appliance running version 22.7r2.4. We confirmed that RCE is possible and is subject to successfully bypassing ASLR, by guessing the correct 32-bit base address of a shared library, specifically /home/lib/libdsplibs.so. We reproduced this ASLR bypass by leveraging the fact that if you guess an incorrect value for the module’s base address, the target /home/bin/web process will crash, and subsequently restart automatically. This allows an attacker to brute force the address by making multiple attempts, and at some point the guessed address will be correct. The target Connect Secure appliance runs an older kernel 4.17.00.35-selinux-jailing-production, and ASLR for a 32-bit process is subject to 9 bits of entropy. Therefore an attacker would need to guess around 512 times (2 to the power of 9), to likely guess the correct address. We measured a single failed exploitation attempt to take approximately 10 seconds, to account for the time it takes for the /home/bin/web process to crash and restart. With this in mind it could take up to 1.5 hours to guess the correct address. In our testing, our exploit succeeded in a little over 30 minutes. As guessing the correct address has a constant 1 in 512 chance of success, the time for a successful guess could be anywhere within the 1.5 hour window. As upon each failed exploit attempt, the target web server process will restart with a new random base address (subject to 9 bits of entropy), this means there is no benefit for the attacker to iterate over the 512 possible addresses, as this will have the same probability of success as if the attacker chooses a single address value and tries that same address value multiple times.

We explored the possibility of generating a suitable info leak primitive, to break ASLR by leaking a pointer value from memory. However we were unable to find such an info leak primitive.

I have rated the attacker value as Very High, as Ivanti Connect Secure is an enterprise SSL VPN appliance, and as such is a high value target for an attacker. I have rated the exploitability as High, as, notwithstanding the potential time it may take to brute force ASLR, RCE is reliable, and not subject to other non-deterministic conditions such as heap layouts, or race conditions. An attacker will need to know in advance the correct library offsets specific to the build version of the target, for their ROP chain to work correctly.

PoC

We can demonstrate successful exploitation of the vulnerability via the Ruby PoC script CVE-2025-0282.rb. We can run this script against a vulnerable Ivanti Connect Secure target, version 22.7r2.4 as follows:

C:\Users\sfewer\Desktop\CVE-2025-0282>ruby CVE-2025-0282.rb -t 192.168.86.111 -p 443
[+] Targeting 192.168.86.111:443
[+] Detected version 22.7.2.3597
[2025-01-16 14:39:56 +0000] Starting...
[2025-01-16 14:39:56 +0000] Triggering #1...
[2025-01-16 14:39:57 +0000] Triggering #2...
[2025-01-16 14:40:08 +0000] Triggering #3...
[2025-01-16 14:40:19 +0000] Triggering #4...
[2025-01-16 14:40:30 +0000] Triggering #5...

...snip...

[2025-01-16 15:13:28 +0000] Triggering #188...
[2025-01-16 15:13:38 +0000] Triggering #189...
[2025-01-16 15:13:49 +0000] Triggering #190...
[2025-01-16 15:14:00 +0000] Triggering #191...

If the exploit succeeds, it will write a new file to the temp directory /var/tmp/, with a number value corresponding to the exploit attempt iteration as part of the file name.

In a separate root shell on the target device (which we established by jail breaking the appliance), we can observe when the exploit has succeeded:

bash-4.2# ls -al /var/tmp/hax*
ls -al /var/tmp/hax*
ls: cannot access /var/tmp/hax*: No such file or directory
bash-4.2# ls -al /var/tmp/hax*
ls -al /var/tmp/hax*
-rw-r--r-- 1 nr nr 0 Jan 16 07:10 /var/tmp/haxor_191
bash-4.2#

We can see from this example, that the exploit made 190 failed attempts, and was successful on the 191th attempt. So in this example, exploitation of this target succeeded in 34 minutes.