And here we have it.
CVE-2025-0282 and CVE-2025-0283
https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-0282-CVE-2025-0283
CVE-2025-0282 (CVSS 9.0 stack buffer overflow) is being exploited in the wild.
Without even knowing the details of the exploit, can we make some guesses about the feasibility of such attacks?
The vulnerability is a stack buffer overflow. What are the chances of being able to successfully exploit such bugs without needing to chain with a second bug? You know, since ASLR has been around on the Linux platform for about 20 years now.
Let's look at just the binaries in /home/bin on a recent Ivanti ICS device.
11 out of 241 executables have PIE enabled, and therefore are randomized with ASLR.
A job done, folks.
As we're pondering software excellence, let's look at how you can tell if your device is compromised.
You ask it, and hope it doesn't lie to you.
Sure, you "can" identify a bank robber by asking them if they robbed a bank. And if they're really bad at what they do, they might say yes.
The Ivanti ICT is the same concept. You ask your maybe-compromised device to pretty please run a scanner, and then tell you the results. This is the official company-sanctioned (and only official) way of checking the integrity of your ICS product.
More info from Mandiant:
https://cloud.google.com/blog/topics/threat-intelligence/ivanti-connect-secure-vpn-zero-day
I'll say that Ivanti customers are lucky that the attackers aren't trying very hard here. Mandiant admits that the attackers are *already* attempting (poorly) to bypass the ICT. But they did such a bad job that their faked ICT results had only 3 steps instead of 10.
It's trivial to modify an ICS so that the ICT fakes the 10 steps of the ICT, without including the rickroll step of 11.
It's only safe to assume here that only the the B Team of Ivanti attackers were detected anywhere. And that anybody with a touch more skills are still in your boxes if you're only relying on the ICT as Ivanti recommends running it for detection of badness. But I suppose that's the case with just about anything... you only notice the folks that are bad enough to get caught. 🤦♂️
As per usual, watchTowr has an excellent writeup on the vulnerability.
https://labs.watchtowr.com/do-secure-by-design-pledges-come-with-stickers-ivanti-connect-secure-rce-cve-2025-0282/
As they mention, the clear thing that has changed is the web binary, which indeed is ASLR'd via PIE.
If "web" is the process that's being exploited, we should be protected with ASLR, right? Well, sorta.
First, let's look at the most recent builds (22.7R2.4 or R2.5) of ICS. As it turns out, they are getting better with enabling PIE. It's now over 50% of the executables in /home/bin. My prior screenshot was from a 22.6 version of the appliance. Baby steps?
While the ICS has a 64-bit kernel (that is over 6 years old), this web server binary (as well as every other binary in /home/bin) is 32-bit. What does this mean for ASLR? Well, by my calculation, that gets us about 9 bits of entropy. Which, depending on what the exploit does, could be able to be brute forced.
There's no use of pesky stack canaries either, so Ivanti has made it easier for those looking to exploit stack buffer overflows.
Did you have a good break? Have you had a chance to breathe? Wake up. It’s 2025, and the chaos continues. Haha, see what we did? We wrote the exact same thing in 2024 because 2024 was exactly the same. As an industry, we are on GroundHog day -
Since this vulnerability is being successfully exploited in the wild, it probably is worth knowing if your system has been compromised, right?
A compromised box can easily fake (internal AND external) ICT results, and it can also fake the factory reset process as well. So is all hope lost?
Well, in the vast sea of bits on VirusTotal, apparently some good samaritan has uploaded a bootable ISO that can both decrypt an Ivanti ICS filesystem, as well as run the stand-alone ICT in a way that is truly stand-alone. i.e. it doesn't rely on your maybe-compromised running system not lying to you.
With some brief testing, it seems to work. And perhaps can be trustable as much as you trust a computer to boot from the media you specify.
https://www.virustotal.com/gui/file/2d76293e1639152e4871fba67cb5bdb010e444a3cd66bdf943503c48bba412c0/details
Using a 1-line change of the BishopFox PoC for CVE-2025-0282, we can easily see the vulnerable Ivanti web server crash.
https://github.com/BishopFox/CVE-2025-0282-check
Given that there's no stack canary, and there's only 9 bits of ASLR entropy, we can probably successfully brute force a successful exploit if we want to.
watchTowr has published details on their strategy for exploiting this vulnerability:
https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/
However, since we're not as smart as the people at watchTowr, is there anything else we might be able to accomplish?
Well, depending on how much we overflow our buffer, we might be able to take advantage of the fact that the Ivanti web binary has a fork() in it without a corresponding execve(). Forked processes are clones of the parent, and as such, you can crash the forked process and each time it will have the same process/library/stack/heap memory layout.
What this means is that each forked child will behave identically to the parent with respect to memory locations. So if we have some way to figure out a way to get control of EIP, it will do that every single time.
In this case I cheated because I knew the address of the web binary AND the stack. And in the end, I didn't need to do anything clever at all like a faked vtable. If we need to brute force both the 32-bit ASLR'd address of the web server binary AND the stack, that could be several days worth of requests before a successful exploitation happens.
If I have some spare time, I may try achieving what watchTowr has outlined to get a more elegant solution.
But either way that you approach the problem, attackers benefit from the fact that the Ivanti ICS web server is a 32-bit process that doesn't use stack canaries, here in the year 2025.
If you're using a security product that has its origins in something made in 2010, and has only patched specific security bugs, as opposed to having had received a full refresh, make sure that you're aware of the security consequences of such behavior. Sure people make mistakes. And code written in C/C++ is going to have memory safety issues due to such mistakes. HOWEVER, if you're using a C/C++ product that doesn't bother with modern exploit mitigations (e.g. only partial adoption of PIE, no stack canaries, is 32-bit, etc.), well, have fun with that.
As we saw in our previous blogpost, we fully analyzed Ivanti’s most recent unauthenticated Remote Code Execution vulnerability in their Connect Secure (VPN) appliance. Specifically, we analyzed CVE-2025-0282. Today, we’re going to walk through exploitation. Once again, however, stopping short of providing the world with a Detection Artifact
Note that the watchTowr PoC for CVE-2025-0282 is out:
https://github.com/watchtowrlabs/CVE-2025-0282
Worth noting that this exploit admittedly leverages prior knowledge of memory offsets to properly function. Which either this is an exploit that was neutered to avoid use by the masses, or watchTowr never got a viable exploit that doesn't figure this out on its own.
I'm curious what the ITW exploits look like... 🤔
In fact, the watchTowr PoC on GitHub actually just AV's on AAAA with an ICS 22.7R2.4 or even 22.7R2.3 (which is what the watchTowr screenshot is of) system.
So presumably what's on gitHub was just an early test PoC that wasn't quite yet viable, hard-coded addresses aside.
And from @Rapid7Official 's @stephenfewer we have a (mostly) working exploit:
https://github.com/sfewer-r7/CVE-2025-0282
While my naive attempt to get control of EIP leveraged both a known heap address and a known stack address, I wasn't pretty pleased with it due to the combined entropy of the heap (14 bits) and the stack (12 bits).
Had I tried a bit harder, I could have found the bits that I needed all in a single loaded library (libdsplibs.so). And since it's a 32-bit app, we'll expect to see about 9 bits of entropy, which is very easily brute-forceable in a listening service that re-spawns itself when it crashes.
Tweaks necessary to get this to RCE properly (at least with my VMs):
1. Set keep-alive header
2. Set TLS version 1.2
3. Auto-increment the libdsplibs_base value with each attempt, as at least with my VM, the crashing web server is forked from a parent that does not crash, and as such the ICS web server will have the same memory layout every single time. As such, you can't keep a fixed address and re-try until the server matches what you're guessing. You need to guess a different value each time.
With these tweaks, I can pop my 22.7R2.4 ICS box in seconds. 🎉
The fact that a 2025 Ivanti ICS box has 32-bit binaries, no stack canaries (which is a mitigation that has been around for 20 years), and no official way to determine if a box is compromised that is sound makes it seem that Ivanti does not REALLY care about security. But please, draw your own conclusions here.
PoC for CVE-2025-0282: A remote unauthenticated stack based buffer overflow affecting Ivanti Connect Secure, Ivanti Policy Secure, and Ivanti Neurons for ZTA gateways - sfewer-r7/CVE-2025-0282
In a simple world, our CALL [ EAX + 0x48 ] (as outlined by watchTowr) would call to an address that's under our control and we get control of EIP. However I didn't find something so easy. I even poked around at partial overwrites, which would make ASLR *completey* irrelevant. But no such luck there.
But Stephen does something clever here where this CALL goes a location in libdsplibs.so. The bytes at this address happen to decode to an x86 PUSHF instruction, but that's a red herring. This gadget is in a non-executable segment of memory, which will trigger a SIGSEGV. And normally this would be game over.
HOWEVER, at this point even after the access violation in our gadget, the program flow continues at a massive jump table postamble. Why? The Ivanti code sets up a signal handler to handle SIGSEGVs and attempt to keep on chugging, which is quite courteous to attackers.
At the point of the RET at the end of a jump table postamble, our specially-crafted buffer controls exactly where we go next. At this point, we have full control of EIP, so we're good to ROP away as usual!
Since some kind soul uploaded the V22725-b3819 ICT to VirusTotal, we can actually kick the tires of the thing to see how it fares on the ICS VMs that we have handy.
Each one is a fresh install, so they should all come up clean, right? You clearly haven't been paying attention here if that's what you think. 😂 We all know that an ICS admin's job is meant to be as unpleasant as possible.
In each of the recent ICS 22.7 versions, the ICT reports 2 newly detected files. In an older ICS 22.6 version, the ICT reports that there are 18 new files.
Does this mean that the device should be investigated for compromise? No, aside from being fundamentally flawed in design, the ICT also has bugs that show up as false positives. These are all clean VMs that have been untouched in any way.
Are ICS admins to know that the ICT reporting newly detected files is expected on a clean device, and is not necessarily an indicator of compromise?
So what if we run the Ivanti ICT on a machine that *was* modified? In my test case, I placed 2 new files:
1 in the system root partition
1 in the data-backup-tgz file, which is a known persistence technique being used by attackers in the wild.
I also modified two files:
1 in the system root partition
1 in the data partition
Luckily, in 2024 Ivanti changed the ICT so that it no longer encrypts the output file to ease the load on their support team. When you download it, it has no file extension. But clever ICS admins will just know in their hearts that it's a .tgz.gz file. (Yes, they gzip a tgz file, because if you compress something once and it gets smaller, it's clear that compressing it a second time will make it even smaller!)
The web UI for the ICT shows us that we have 4 new files, and 4 newly-detected files. Knowing that the ICT by default has 2 false positives, that does match up with our 2-new-file, 2-modified-file test. So all is good, right?
Well, sorta. Although the web UI for the ICT tells you the count of the modified and new files, it does not tell you what the files are. And the no-longer-encrypted tarball that you can download does have actual files, it does not indicate which files are there because they're new and which are there because they're modified.
But even more glaring of a problem is that while the ICT does check for a couple of file types that might have been added to data-backup.tgz, you don't get a copy of the file, nor will you even be told what the filename was. But if you do the math of subtracting the 2 false positives from the combined new and modified files count and then compare it to the number of non-/tmp files in your tarball, you might be able to tell that you have a hijacked data-backup.tgz file on your ICS device. Easy peasy, right?
One of the things that nobody (that I know of) is talking about with this ITW Ivanti exploitation is how the attackers are getting root privileges to do their stuff.
EDIT: The Ivanti advisory says that CVE-2025-0283 is a buffer overflow to achieve privilege escalation. But nobody is talking about what this actually is.
Knowing that the Ivanti web server runs as "nr" instead of root, then why does the CVSS score for CVE-2025-0282 say that the CIA losses are all High? Is the CVSS score for CVE-2025-0282 wrong?
IMO, yes. The CVSS score is wrong.
The exploit was scored (as opposed to the vulnerability), it's fine. It allows full appliance compromise. However, that's not *just* CVE-2025-0282. If we want to be pedantic, when we assign a CVSS score to CVE-2025-0282, that score is for the single vulnerability captured as CVE-2025-0282 and nothing else.
However, the consumers of CVSS scores don't care about vulnerability-level precision. They don't care about what exploitation of an individual vulnerability can achieve. What's important is the complete exploit (chain). The days of single vulnerability exploits are mostly long gone by now. They are chains.
And if you're scoring individual links in a chain (i.e. CVEs), then good luck in knowing what the score of the chain as a whole is!
We know that CVE-2025-0282 isn't enough to compromise a system on its own.
And although they throw out this mystery CVE-2025-0283 as a privilege escalation that could fit that need, they are crystal clear that they have no evidence that CVE-2025-0283 is being used in the wild.
What can we conclude using simple logic here?
Ivanti doesn't know how attackers in the wild are compromising their systems. They only know part of the picture (CVE-2025-0282). 🤔
@wdormann Excellent find! TIL about LD_AUDIT, LD_SHOW_AUXV, and "secure-execution mode".
Interestingly, that latter does not seem to apply here... maybe because of how old Linux / ld is? https://www.man7.org/linux/man-pages/man8/ld.so.8.html
@stephen0x2dfox
Yeah, I haven't really sifted through it too closely, but I think the dsrunpriv program explicitly avoids any protections that AT_SECURE might provide.
Specifically, at run time it sets the uid to match the euid. And at this point, the process will no longer receive the AT_SECURE protections, since there's no longer a difference between the two. My understanding is that when the values match, ld.so is hands off with AT_SECURE.
Does that sound about right?
@stephen0x2dfox
Correct. dsrunpriv is setuid root and spawns child processes with user-settable environment variables.
However, even in such a case, I think that one might get benefits from AT_SECURE if dsrunpriv did not take steps to ensure that the euid is equal to the uid at the time of the child process spawn. My understanding is that AT_SECURE is hands-off at that point, as those values being equal is an indicator that it's not just a standard invocation of a setuid root executable.
As we saw in our previous blogpost, we fully analyzed Ivanti’s most recent unauthenticated Remote Code Execution vulnerability in their Connect Secure (VPN) appliance. Specifically, we analyzed CVE-2025-0282. Today, we’re going to walk through exploitation. Once again, however, stopping short of providing the world with a Detection Artifact
@timb_machine
Yeah, I saw the general gist of the exploitation. But what's not clear to me is the whole getting past ASLR.
Yeah, it's only a 32-bit app, but if the exploitation requires 3 different independently randomized things (heap: 14 bits, stack: 12 bits, and binary: 9 bits), that adds up pretty quickly. 🤔
@timb_machine
As it turns out, exploitation can happen with only guessing the base address of a single loaded library.
Attached: 4 images And from @Rapid7Official 's @stephenfewer we have a (mostly) working exploit: https://github.com/sfewer-r7/CVE-2025-0282 While my naive attempt to get control of EIP leveraged both a known heap address and a known stack address, I wasn't pretty pleased with it due to the combined entropy of the heap (14 bits) and the stack (12 bits). Had I tried a bit harder, I could have found the bits that I needed all in a single loaded library (libdsplibs.so). And since it's a 32-bit app, we'll expect to see about 9 bits of entropy, which is very easily brute-forceable in a listening service that re-spawns itself when it crashes. Tweaks necessary to get this to RCE properly (at least with my VMs): 1. Set keep-alive header 2. Set TLS version 1.2 3. Auto-increment the libdsplibs_base value with each attempt, as at least with my VM, the crashing web server is forked from a parent that does not crash, and as such the ICS web server will have the same memory layout every single time. As such, you can't keep a fixed address and re-try until the server matches what you're guessing. You need to guess a different value each time. With these tweaks, I can pop my 22.7R2.4 ICS box in seconds. 🎉 The fact that a 2025 Ivanti ICS box has 32-bit binaries, no stack canaries (which is a mitigation that has been around for 20 years), and no official way to determine if a box is compromised that is sound makes it seem that Ivanti does not REALLY care about security. But please, draw your own conclusions here.
Mr. Bitterness
stephen-fox
pejacoby
cesarb
Tim (Wadhwa-)Brown 