Conversation

Notices

1. Embed this notice
   Will Dormann (wdormann@infosec.exchange)'s status on Friday, 04-Apr-2025 03:26:04 JST Will Dormann

   Ivanti CVE-2025-22457 is being exploited ITW.
   https://forums.ivanti.com/s/article/April-Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-22457

   Per Mandiant:

   We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.

   Gee, who could have imagined that attackers are looking at patches? 🤔

   1) This apparently was silently fixed for ICS in 22.7R2.6, as the fix for this was released in February. Per Ivanti, the buffer overflow was considered a "product bug" at that time, as opposed to a vulnerability. Ivanti Policy Secure and ZTA gateways are expected to receive a patch in late April.

   2) The advisory still conveys the magical thinking if if your device shows signs of compromise, then you should perform a "factory reset." This is magical in that the ICT won't catch a compromise nor will the "factory reset" reset to factory condition if the attacker is bothering to try.

   While Mandiant also parrots the magical thinking of running the ICT tool, which I guess is the best advice if you're not going to throw the device in the trash since there isn't an official integrity checking tool that is sound, they do throw out a tidbit of:

   ... and conduct anomaly detection of client TLS certificates presented to the appliance.

   Bets on whether CVE-2025-22457 is an overflow in the handling of a field in a client-provided certificate? 😂

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 04-Apr-2025 04:08:51 JST Will Dormann

     in reply to

     Given that the web server on an ICS runs as the limited nr user, both the Ivanti and the Mandiant advisory are missing any indication whatsoever how the threat actors are gaining root privileges.

     I've reported 4 different ICS LPEs to Ivanti recently, but none of them have been fixed yet.

     Back in the CVE-2025-0282 days, Ivanti made up a CVE-2025-0283 CVE to capture the LPE aspect of attacks happening in the wild. I say "made up" because I've seen no evidence whatsoever that any LPE was fixed between 22.7R2.5 and 22.7R2.6.

     Knowing what's going on in an ICS device is a huge blind spot, but apparently seeing how attackers are LPE'ing is even blind-er.

     Kevin Beaumont repeated this.
   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 04-Apr-2025 04:08:51 JST Will Dormann

     in reply to

     Now, regarding the "silent fix" of CVE-2025-22457, which per Ivanti:

     This vulnerability has been remediated in Ivanti Connect Secure 22.7R2.6 (released February 11, 2025)

     That word remediated...

     Careful readers will see that Ivanti didn't fix the vulnerability in 22.7R2.6.

     What changed in 22.7R2.6? With this version, Ivanti compiled some of the ICS binaries with exploit mitigations that have been around for 20 years. And wouldn't you know it, it paid off already? Everybody's gotta learn sometime...

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Saturday, 12-Apr-2025 01:16:43 JST Will Dormann

     in reply to

     FWIW, I cannot reproduce the Rapid7 PoC. Per the R7 write-up, they can get around the limitation of only addressing things in the 0x30303030 - 0x39393939 address space (including 0x2e2e2e2e) by doing a heap spray.

     But at least in my naive testing on a single VMware VM that I have handy, I cannot get the heap spray to get anywhere near that address range. For me, the spray starts pretty consistently around the 0xcnnnnnnn range.

     As such, while the heap spray is indeed succeeding at placing known bytes at guessable locations, the fact that these allocations happen at higher than reachable memory locations makes the heap spray accomplish nothing.

     ...

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Saturday, 12-Apr-2025 01:16:44 JST Will Dormann

     in reply to

     And per the excellent folks at watchTowr, we can see what the vulnerability is:
     A stack buffer overflow in X-Forwarded-For

     No need to find a specific endpoint or do something clever. Simply make a web request to anywhere on an ICS system with a large X-Forwarded-For HTTP header and you'll get a stack buffer overflow on the system. 🤦♂️

     And due to the fact that the Ivanti web server does a fork() without a corresponding exec(), we get the same memory layout every single time.

     Now, about Ivanti's use of remediated... The function where the overflow happens just happens to have been rewritten in a way that avoids the overflow.

     Did Ivanti recognize the possibility of a stack buffer overflow and not recognize it as a security issue? Or did they just happen to change code to accidentally avoid the overflow (and decide to use exploit mitigations as well).

     You decide...

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Saturday, 12-Apr-2025 01:16:44 JST Will Dormann

     in reply to

     If I look closer at the difference between the vulnerable version and the "remediated" version, it's now clear where the fix is.

     In the vulnerable code, the attacker-provided length of data is strlcopy'd into a 50-byte array. And badness ensues.

     In the "remediated" version, the strlcopy only copies 50 bytes, as the target variable is 50 bytes.

     So I'd consider this an actual fix. But presumably Ivanti didn't realize that a stack buffer overflow could have a security impact? And thus the lack of CVE when it was fixed, or the attempt to also fix their Ivanti Policy Secure and ZTA Gateways products? 🤷♂️

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Saturday, 12-Apr-2025 01:16:44 JST Will Dormann

     in reply to

     If we poke around with various sizes/contents of the buffer that we send, we can conclude that we can indeed control EIP. (Yes, EIP, since web is a 32-bit app 😂).

     However, given that the address space of web has nothing that matches up with ASCII-based number/. addressing, I'm curious what these "sophisticated means" being used ITW are. Maybe something data-based? 🤔

     Also LOL at Ivanti's:

     it was evaluated and determined not to be exploitable

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Saturday, 12-Apr-2025 01:16:44 JST Will Dormann

     in reply to

     Rapid7 has provided details and a PoC for how to exploit this:
     https://attackerkb.com/topics/0ybGQIkHzR/cve-2025-22457

     TL;DR: Since you can't steer EIP to something you control directly, you do a heap spray and go the indirect route of a non-limited EIP subversion.

     scriptjunkie repeated this.
   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 15-Apr-2025 03:46:15 JST Will Dormann

     in reply to

     As I dig deeper into this mystery, I've discovered that I'm (as expected) once again mistaken here.

     Yes, the Rapid7 PoC needs Ruby 3.1 or older for it to work right.
     But no, there isn't a difference between Linux Ruby and Windows Ruby here.

     Why was I steered wrong?
     Heap allocations on Linux (ICS) don't simply start at low addresses and grow higher. The allocations will use low addresses if they need to. Why didn't my allocations hit low addresses in all of my early testing? Because my ICS test systems all have multiple cores. Stephen's did not. Also, even in my single-core VMs, I suppose I didn't wait long enough before giving up after notinc allocations happening at high addresses. After seeing allocations happening at high addresses for a while, I incorrectly assumed that low addresses wouldn't be touched.

     So if I were correcting this Rapid7 PoC, I would:

     1. Have the script itself modify the guessed libdsplibs.so base address. Because the Ivanti web process does a fork() without an exec(), every single re-spawned web process will have the exact same memory layout as its parent. As such, ASLR will only randomize anything in the web process once at boot time, and not per time it crashes.
     2. If the target is multi-core, then the heap spray will need to be larger. With the multi-web-process situation you end up with on multi-core ICS systems, the default Rapid7 PoC will not work because any given web process will not get coerced into allocating at low addresses.
     3. I'd probably update the script to work with modern Ruby versions. No need to crash upon attempting to figure out the target ICS version.

     Just to help you all visualize what's going on here, here's a sped-up animation of the allocations happening in the web process when it receives the Rapid7 heap spray. Note that the low addresses aren't touched until near the end. My impatience to wait for the spray to complete led me to draw the incorrect conclusion that low addresses weren't going to get touched.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 15-Apr-2025 03:46:16 JST Will Dormann

     in reply to

     Well this is hilarious. When looking closer at Stephen's screenshot, I noticed that he was running Ruby from Windows. That couldn't make a difference, could it??

     YES. If you run the PoC exploit from Windows, heap allocations will start at a low address and the exploit will work just fine. If you run the PoC exploit from Linux (I used Ubuntu), then the heap allocations will happen at a memory range that is too high to work.

     I truly have less understanding of how computers work than I could ever have imagined.

     Note that if you target an ICS system that has one CPU, you get one web process and ASLR will load libdsplibs.so at a different location every time. So you can guess a fixed address and it'll eventually be correct. But if your target ICS has multiple CPU cores, you'll get a fork()'d (but not exec()'d web process, so the memory layout will be the exact same every time. So the PoC would need to vary the guessed load address of libdsplibs.so for each attempt, rather than relying on the changes of the guess to happen server-side.

     Edit: No, as per usual, I've fallen victim to another red herring here.

     scriptjunkie repeated this.
   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 15-Apr-2025 03:46:17 JST Will Dormann

     in reply to

     Why am I seeing a difference with my heap allocation addresses vs. what Stephen is seeing?

     "Easy"

     I'm using VMware, and Stephen is using Hyper-V.

     Looking at the e820 info when the VM boots, we can see that with a VMware VM, we have a couple of ACPI entries, and then the usable section after that starts at 0xbff00000. With Hyper-V, there is no ACPI section, and the usable section merely starts at 0x00100000. Also looking at the /proc/iomem output, we can see a clear difference between memory layout in a Hyper-V VM vs. a VMware VM.

     What are the consequences of this?
     An ICS VM that is running on a default VMware configuration will presumably not be exploitable using the Rapid7 technique. However one running on Hyper-V will be. 🤔

     Edit All of the above is a red herring, as I don't know how computers work.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 15-Apr-2025 03:46:17 JST Will Dormann

     in reply to

     Upon further investigation, because that's how I am, I've confirmed that Hyper-V (on a completely different host system) behaves the same as VMware for me. The heap spray ends up at addresses to high to allow exploitation.

     But for Stephen, both VMware- and Hyper-V-based ICS systems start heap spraying low enough to allow exploitation.

     Neither one of us can figure out why this is the case.