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.
=> More informations about this toot | More toots from wdormann@infosec.exchange
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.
=> More informations about this toot | More toots from wdormann@infosec.exchange
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.
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
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. 🤦♂️
=> View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
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.
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
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
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
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.
=> More informations about this toot | More toots from wdormann@infosec.exchange
Since Ivanti graciously provided a copy of gdb on ICS devices, we can see the stack trace of the crash quite easily right on the ICS device itself.
=> More informations about this toot | More toots from wdormann@infosec.exchange
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.
=> More informations about this toot | More toots from wdormann@infosec.exchange
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... 🤔
=> More informations about this toot | More toots from wdormann@infosec.exchange
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.
=> View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
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):
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.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
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!
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann …shouldn’t that read ‚might identify‘ instead of ‚can identify‘…
=> More informations about this toot | More toots from nobrainnopain@social.tchncs.de
@nobrainnopain
Yes, that would indeed be more accurate.
But to use those words would require that the vendor acknowledge the flaws in their software. 😂
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann Can we give the attackers credit here for writing Perl that looks obfuscated but probably isn't?
=> More informations about this toot | More toots from jsmall@infosec.exchange
@wdormann Security nerds: Hey cR0w, why do you bother with x86 exploits still? Shouldn't you be teaching more advanced shit in this the year of our Sasquatch 202*?
Me:
=> More informations about this toot | More toots from cR0w@infosec.exchange
@wdormann wow, that is a great "feature" of forks to give a consistent memory layout for a fresh copy.
=> More informations about this toot | More toots from merospit@infosec.exchange
@merospit @wdormann This is also the reason Android got problems with randomisation. All app executions are forks of a single process.
=> More informations about this toot | More toots from waldi@chaos.social
@waldi @merospit
Used to, I think.
I think it finally got working ASLR as of 4.1
https://copperhead.co/blog/aslr-android-zygote/
With further improvements in 8.0
https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann They neutered it: https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/. There's a more reasoned & detailed description of why that Ben (I think) shared elsewhere but the last paragraph of the blog covers the neutering also.
=> More informations about this toot | More toots from timb_machine@infosec.exchange
@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. 🤔
=> View attached media | View attached media
=> More informations about this toot | More toots from wdormann@infosec.exchange
@timb_machine
As it turns out, exploitation can happen with only guessing the base address of a single loaded library.
https://infosec.exchange/@wdormann/113844874136359186
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann Strong oof-factor.
=> More informations about this toot | More toots from timb_machine@infosec.exchange
@wdormann wait what, they couldn't figure out how to stop segfaults in their apps, so they just decided to have their own handler to prevent their apps from exiting???
Is this real life?
=> More informations about this toot | More toots from chort@infosec.exchange
@chort
It's 1997 all over again. 😂
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann ewwwwwwwwwwwwwwww
=> More informations about this toot | More toots from chort@infosec.exchange
@wdormann Wait a moment... you mean they did the equivalent of "ON ERROR RESUME NEXT"? Wow.
=> More informations about this toot | More toots from cesarb@mastodon.social
@wdormann Could be a fun challenge / learning experience to exploit it.
=> More informations about this toot | More toots from stephen0x2dfox@hachyderm.io
@stephen0x2dfox
Yeah, this is definitely one of those things where I could choose to race the rest of the internet. And then see that once I get it done discover that somebody else had published their copy hours before I finished mine. 😂. (Yes, this is the voice of experience)
But yeah, assuming nobody else steps up, I may have a hack at it if I have time.
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann I saw Bishop Fox's blog post hit my RSS feed on Friday but decided not to mention the "CVE-2025-0282-check" on their GitHub since they took down the blog. I assumed there was probably a reason for revoking/unpublishing it.
=> More informations about this toot | More toots from screaminggoat@infosec.exchange
@wdormann How did you get a working VA of the vulnerable target? I used the v-22.7r2.3-b3431 original .OVA to deploy a VA in WMWare Workstation and do the initial setup. But when I launch the attack, nothing happens. No crash in the terminal. I think trere's something else that has to be done in order to exploit the vuln... Any ideas/suggestions?
=> More informations about this toot | More toots from mcksysar@infosec.exchange
@mcksysar
I used the python PoC from BishopFox and just added 1 line to get it to crash:
payload += b" clientCapabilities=" + b"A" * 1000
You can do something similar with the Rapid7 PoC, but I had to do a couple of tweaks to get that to work (outlined earlier in my thread here). There's nothing else that needs to be done. Just negotiating the IF-T TLS with a large clientCapabilities value is enough to trigger it.
You should see the "web" binary crash in dmesg output. R2.3 as well.
To get to R2.4 I installed an update PKG, as I couldn't find an R2.4 VM. I suspect Ivanti didn't build one for that version.
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann I did that change in BishopFox's PoC, and got nothing on the terminal. I have several version of the software (2 from OVA's) and 2 more from upgrading from pkg's. But the attack shows nothing on the terminal (the handshake seems to work fine, since I got the 101 HTTP code and the version requests response; but when the overflow is sent, nothing happens in the terminal). That's why I asked you if there's is some extra config that must be done in ordere to exploit this...
=> More informations about this toot | More toots from mcksysar@infosec.exchange
@mcksysar
No, I didn't do any config other than answering the initial questions to get it to boot (certificate info and whatnot).
Anything larger than 256 bytes provided will trigger the crash. The properties of the crash will vary based on the size of the buffer.
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann Damn! I'll keep trying... Do you know if there is any menu option in the terminal that I can use to see if the crash is happening? I found nothing in the log section...
=> More informations about this toot | More toots from mcksysar@infosec.exchange
@mcksysar
Ah, you're using the default terminal? I'm not sure you'd see any evidence of a crash there. Or even in the system logs for that matter.
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann Yeah. I didn't figured out a way to get a shell in the VA (I spend a lot of time trying to create the target and get a crash)
=> More informations about this toot | More toots from mcksysar@infosec.exchange
@mcksysar
If you're running in VMware:
If you're using some other virtualization platform, you may have to do your own homework to see how you might be able to edit memory of a paused VM.
Oh, and my prior comment about not seeing anything in the logs was partly untrue. You can see the crash in the debug logs. But such debug logs are 3DES encrypted, because Ivanti doesn't want people to know what's happening with their devices. 😂
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann WOW!!! I'll try that!! Thanks you very much!
=> More informations about this toot | More toots from mcksysar@infosec.exchange
@mcksysar
If you know what to look for, it's a somewhat universal way of rooting a locally-running VM. 😀
=> More informations about this toot | More toots from wdormann@infosec.exchange
@wdormann Didn't they also recommend ICT previously for another CVE, and then it turned out attackers had manipulated it so they backtracked? Or was that another vendor with a similar tool?
=> More informations about this toot | More toots from AlesandroOrtiz@infosec.exchange
@AlesandroOrtiz
Hm, I don't think that Ivanti has ever backtracked from advising that the ICT is the best bet, as that's all that they have.
=> More informations about this toot | More toots from wdormann@infosec.exchange This content has been proxied by September (ba2dc).Proxy Information
text/gemini
