Ancestors

Written by Will Dormann on 2025-01-08 at 18:06

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

Written by Will Dormann on 2025-01-08 at 18:41

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.

=> View attached media

=> More informations about this toot | More toots from wdormann@infosec.exchange

Written by Will Dormann on 2025-01-08 at 18:58

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

Written by Will Dormann on 2025-01-09 at 00:55

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

Written by Will Dormann on 2025-01-10 at 16:56

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

Written by Will Dormann on 2025-01-10 at 17:32

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

Written by Will Dormann on 2025-01-11 at 17:48

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.

=> View attached media

=> More informations about this toot | More toots from wdormann@infosec.exchange

Written by Will Dormann on 2025-01-11 at 18:15

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.

=> View attached media

=> More informations about this toot | More toots from wdormann@infosec.exchange

Written by Will Dormann on 2025-01-12 at 16:02

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.

=> View attached media

=> More informations about this toot | More toots from wdormann@infosec.exchange