The current White House:
Of course you can tell if a single-cell zygote is a male or not. We know what dudes are.
I can see what this is leading to, and it looks real grim.
=> More informations about this toot | View the thread
I ordered this the day before the announcement of David Lynch's death.
You will be missed.
=> More informations about this toot | View the thread
I suspect that some people think I'm exaggerating when I call Twitter "The Nazi site"
I mean...
=> More informations about this toot | View the thread
Despite having words that state that existing installations of Microsoft Defender Application Guard will not be affected by its deprecation, I can confirm that a system that was successfully using Application Guard in the past will find those features are REMOVED upon upgrading to Windows 11 24H2.
I always thought that it was pretty slick that Windows could transparently provide hypervisor protection for dangerous things like opening Office documents or web pages.
But alas, Microsoft has decided that merely dropping support for a technology wasn't enough. They've taken it away from us. 😕
=> View attached media | View attached media | View attached media
=> More informations about this toot | View the thread
In poking around at what the difference might be between Windows 11 "Device Encryption" and "BitLocker Drive Encryption", I had a VM that would never ever finish enabling Device Encryption. No amount of reboots or idle time would let it complete.
However, ONLY upon attempting to manually add a TPM key protector did Windows tell me that it cannot proceed because there's bootable media (CD or DVD) detected, and that I must eject the media to proceed.
I get it that users can get overwhelmed with excessive detail in errors, but maybe, just MAYBE Windows could be a little more helpful than "Have you tried rebooting?" if it knows EXACTLY what the problem is?
=> View attached media | View attached media
=> More informations about this toot | View the thread
I don't like that I know that 82oz of art epoxy costs not all that much more than 8.5oz of structural epoxy.
Shouldn't they have vaguely similar manufacturing costs? 🤔
=> View attached media | View attached media
=> More informations about this toot | View the thread
Snyk publishes malicious packages to the public NPM registry.
I'm no expert on ethics, but I believe that this is... frowned upon?
https://sourcecodered.com/snyk-malicious-npm-package/
https://news.ycombinator.com/item?id=42690473
https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
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 | View the thread
=> More informations about this toot | View the thread
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 | View the thread
=> More informations about this toot | View the thread
=> More informations about this toot | View the thread
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 | View the thread
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 | View the thread
FWIW, this is addressed in Sequoia 15.2
=> More informations about this toot | View the thread
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 | View the thread
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 | View the thread
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 | View the thread
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 | View the thread
=> This profile with reblog | Go to wdormann@infosec.exchange account This content has been proxied by September (ba2dc).Proxy Information
text/gemini
