CVSSv3 10.0 (AV:N/PR:H/../../../../etc/passwd)

#directorytraversalmemes

One Bug to Rule Them All: Stably Exploiting a Preauth RCE Vulnerability on Windows Server 2025
https://i.blackhat.com/Asia-25/Asia-25-Peng-One-Bug-to-Rule-Them-All.pdf

@edwardzpeng @ver0759

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...

Probably the highlight of all the varieties, meet its holiness the god-tier inductor.

I would really love to hear the rationale behind (hehe) this design.

The reason I get so annoyed about people pitching LLMs as a way to 'democratise programming' or as end-user programming tools is that they solve the wrong problem.

The hard part of programming is not writing code. It's unambiguously expressing your problem and desired solution. Imagine if LLMs were perfect programmers. All you have to do is write a requirements document and they turn it into a working program. Amazing, right? Well, not if you've ever seen what most people write in a requirements document or seen the output when a team of good programmers works from a requirements document.

The most popular end-user programming language in the world (and, by extension, the most popular programming language), with over a billion users, is the Calc language that is embedded in Excel. It is not popular because it's a good language. Calc is a terrible programming language by pretty much any metric. It's popular because Excel (which is also a terrible spreadsheet, but that's a different rant) is basically a visual debugger and a reactive programming environment. Every temporary value in an Excel program is inspectable and it's trivial to write additional debug expressions that are automatically updated when the values that they're observing change.

Much as I detest it as a spreadsheet, Excel is probably the best debugger that I have ever used, including Lisp and Smalltalk.

The thing that makes end-user programming easy in Excel is not that it's easy to write code, it's that it's easy to see what the code is doing and understand why it's doing the wrong thing. If you replace this with an LLM that generates Python, and the Python program is wrong, how does a normal non-Python-programming human debug it? They try asking the LLM, but it doesn't actually understand the Python so it will often send them down odd rabbit holes. In contrast, every intermediate step in an Excel / Calc program is visible. Every single intermediate value is introspectable. Adding extra sanity checks (such as 'does money leaving the account equal the money paid to suppliers?') is trivial.

If you want to democratise programming, build better debuggers, don't build tools that rapidly generate code that's hard to debug.

This thread you guys 🤔 my vote goes to UD2
https://www.quora.com/What-are-the-5-most-absurd-x86-assembly-instructions

Are you FUCKING KIDDING ME

About 10% of Apple's $3T market cap got wiped out today.

That $1M inauguration investment currently has a return of -$300B.

Project: openssl-static-gcc-dwarf 3.4.0
File: openssl
Address: 0063a0a0

rsa_ossl_private_encrypt

SVG:
dark https://tmr232.github.io/function-graph-overview/render/?graph=https%3A%2F%2Fraw.githubusercontent.com%2Fv-p-b%2Fghidra-function-graph-datasets%2Frefs%2Fheads%2Fmain%2F%2Fopenssl-static-gcc-dwarf%2F0063a0a0.json&colors=dark
light https://tmr232.github.io/function-graph-overview/render/?graph=https%3A%2F%2Fraw.githubusercontent.com%2Fv-p-b%2Fghidra-function-graph-datasets%2Frefs%2Fheads%2Fmain%2F%2Fopenssl-static-gcc-dwarf%2F0063a0a0.json&colors=light

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. And the CVSS score for CVE-2025-22457 is definitely wrong, as it has S:C (scope changed). The LPE is what will change the scope, but the April Ivanti advisory lacks any mention at all about any LPE. But I suppose it's common practice to assign CVSS scores to a single CVE that's used in a multiple-vulnerability attack chain. 😕

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.

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? 😂

Suspected China-Nexus Threat Actor Actively Exploiting Critical Ivanti Connect Secure Vulnerability (CVE-2025-22457) https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-exploiting-critical-ivanti-vulnerability/

66 weeks in a row...whatchu know about it 📰 THE vuln research newsletter out NOW

MCPGhidra from @lauriewired

@u1f383 talks DirtyCOW

Mitigations galore with @standa_t and @slowerzs

XSS -> RCE with @chudypb and @watchtowrcyber

+ Jobs and MORE 👇

https://blog.exploits.club/exploits-club-weekly-newsletter-66-mitigations-galore-dirtycow-revisited-program-analysis-for-uafs-and-more/

If I am looking at steampunk stuff you bet your ass I'm checking to make sure they haven't just gone 'fuck it, who cares if cogs can turn anyway'

I DO, KEVIN. I CARE.