# Do Secure-By-Design Pledges Come With Stickers? – Ivanti Connect Secure RCE (CVE-2025-0282)
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 – but let’s call it GroundHog Year, and pretend this isn’t just incredibly depressing.
Like clockwork, though, we have vulnerabilities in Ivanti Connect Secure that have all the hallmarks of APT using a zero-day against a mission-critical appliance.
The similarity and resemblance to the issues and drama that circulated Ivanti products in January 2024 is—frankly—incredible, and we were hoping that Ivanti would have learnt from that experience regarding effective response.
We mean, they signed a pledge and had an amazing photo opportunity, and we do not believe that any company who builds appliances whose foundational purpose is some sort of security function, would’ve been allowed to sign a non-binding pledge by their army of corporate lawyers for fun.
Luckily though, this allows for images like:
This time, in fairness, Ivanti Connect Secure users have a patch available a little earlier (for those who have traumatic flashbacks of the patching saga last year – stop reading here), but once again – users of other affected appliances like Ivanti’s Policy Secure and Neurons for ZTA gateways are left waiting until Jan 21st 2025 for a patch.
Same drill – we have active exploitation, seemingly by the same threat actor – but technical details about the vulnerability themselves are thin on the ground. Something about making sure the attackers that are already using the vulnerability, can’t reproduce it and keep using it? Spielberg would be proud of the level of theatre we as an industry go through sometimes, truly.
> Editor: For many reasons, the amount of work, effort and pure talent that regularly goes into our research is not accurately portrayed here. Skill is not shown in how complex and overwhelming a topic can be made while explaining it, but how understandable and accessible a process or topic can be walked through.
All we know from the advisory is that Ivanti Connect Secure versions It’s 2l8, b4by.
This is promising – it suggests, somewhat weakly, that we’re in code that’s running before authentication – and it gives us a valuable clue as to where in the codebase we are.
Although sophisticated research techniques (Google) give us no results for the constant `IFT_PREAUTH_INIT`, we soon found out that `IFT` (or rather, `IF-T`) is an open standard for VPN interoperability. Also known as IFTTLS, it runs over TLS, providing an alternate means to connect to the VPN.
Thanks to Mandiant’s how-to guide on reproducing this vulnerability, we can see that threat actors are removing a log file pertaining to `IF-T` – more material to support our suspicion that this is our bug.
Our hearts sank – does this mean we’d now be forced to install more software, namely Ivanti’s VPN client, to figure this out? Thankfully, due to `IF-T` being an open standard, we didn’t have to as this protocol is supported by OpenConnect, the open-source VPN client.
Reading OpenConnect’s comments on the protocol fills us with a sense of dread:
> Some Pulse VPNs may _request_ a client certificate but not actually _require_ one. If you are trying to authenticate to such a VPN, and running into strange errors about unrecognized packet types, then mimicking a _very old_ version of the official Pulse client software may help resolve the issue:
This.. this is possibly the worst ‘code smell’ we have encountered yet.
### IF-T[his then hax]
Let’s pretend we didn’t see that, because the attacker probably didn’t see this opensource, freely available code on the Internet as well, and instead pretend to be the laser-focussed security researchers we aspire to be (and not the oh-look-a-shiny-thing bounce-from-one-project-to-another hackers we actually are).
Back in the room, back to `IF-T`.
As you’ll recall, the patched version of the Ivanti Connect Secure firmware brought with it a new error message, warning about ”over-sized client capabilities”. Come on…..
Looking for ‘capabilities’ in the OpenConnect client doesn’t show anything particularly helpful, so it must be something that OpenConnect doesn’t support (but our exploit does).
Fortunately, the `pulse.c` file, which handles `IF-T`, is pretty easy to extend. It’s pretty obvious how the `IF-T` packet is constructed – here’s an excerpt:
“`
buf_append_ift_hdr(reqbuf, VENDOR_JUNIPER, 0x88); buf_append(reqbuf, “clientHostName=%s”, vpninfo->localname); bytes = ; if (bytes[0]) buf_append(reqbuf, " clientIp=%s", bytes); buf_append(reqbuf, "\n%c", 0); ret = send_ift_packet(vpninfo, reqbuf);
```
We can see the packet is ASCII-based, and has some key-value pairs, with key and value separated by an `=`. We can also see that there are multiple pairs in a packet, separated by a space (here, the `clientHostName` and the `clientIp`).
Should we try adding a `clientCapabilities` key with a really long value, and see what happens?
Play along at home – do you reckon we should?
Let’s add a little bit of mischief to the `pulse.c` file and rebuild.
“`
if (bytes[0]) buf_append(reqbuf, ” clientIp=%s”, bytes); + buf_append(reqbuf, ” clientCapabilities=%s”, bytes); + for(unsigned int n=0; nclientCapabilities = clientCapabilities; } } memset(dest, 0, sizeof(dest)); strncpy(dest, connInfo->clientCapabilities, clientCapabilitiesLength);
“`
Oof! The developer has (rightly) used `strncpy`, instead of the unsafe `strcpy`, but has mistakenly passed in the size of the input string – _not_ the size of the destination buffer – as the size limit.
This means that if an attacker sends a `clientCapabilities` block with more than 256 bytes, they’ll spill over into other stack variables (omitted above for clarity), and eventually into the return address, where RCE awaits.
Exploitation is somewhat “complicated” by two factors:
– Firstly, the ASLR and PIE mitigations are enabled (meaning that it is difficult to know which addresses to overflow the buffer with),
– Secondly, there are a number of other function calls (not shown above) after the call to `strncpy` which depend on the state of other stack variables, which are inevitably corrupted, and so any exploit must be careful to avoid crashing.
For avoidance of doubt, nerds, we decided this was the time to take some advice. As always, we looked to watchTowr team members who have given us steady advice – our dogs.
> “Should we release the exploit for this new vulnerability, given it’s already exploited in-the-wild?”
> “No, imagine what the nerds would say in the Tweet replies about arming the criminals that are already armed – let’s keep everything secret and live in a world of mystery, especially because there has only really been one day to patch.”
Well, there we have it, our feline-counsel has advised we hold off on the Detection Artifact Generator for now. Maybe in a week (timer starts now, **go**).
### Summary
Well, it looks like this one is the Real Deal – a legit pre-authentication stack-based buffer overflow, present in the default configuration.
There are exploit mitigations in place, which is nice (read: ‘things are slightly less bad than they could have been’). These will slow down exploit development for a few days, but brace yourselves – it’s coming!
We also point out that we’ve only searched for one of the two vulnerabilities – the more severe, unauthenticated bug.
All we can do at this point is urge you to patch your devices ASAP. This isn’t a “wait for a maintenance window” kind of patch, I’m afraid, it’s as urgent as “in the wild exploited” implies. We would expect to see widespread exploitation once an exploit surfaces in the public domain.
At watchTowr, we passionately believe that continuous security testing is the future and that rapid reaction to emerging threats single-handedly prevents inevitable breaches.
With the watchTowr Platform, we deliver this capability to our clients every single day – it is our job to understand how emerging threats, vulnerabilities, and TTPs could impact their organizations, with precision.
If you’d like to learn more about the **watchTowr Platform** **, our Attack Surface Management and Continuous Automated Red Teaming solution,** please get in touch.”