Notices by Will Dormann (wdormann@infosec.exchange)

Apparently the CVE system is for bickering. 🤷♂️
https://www.securityweek.com/details-emerge-on-cve-controversy-around-exploited-crushftp-vulnerability/

In today's episode of drama in the CVE ecosystem:

The Canonical CNA created CVE-2025-0927 and an associated advisory for a heap overflow in HFS+ in the Linux kernel.

The Linux kernel CNA stripped out the information (like the reporter of Attila Szász, useful references, etc) from the CVE entry and added the passive-aggressive:

The Linux kernel CVE team has been assigned CVE-2025-0927 as it was incorrectly created by a different CNA that really should have known better to not have done this.to this issue. [sic]

Also TIL: If you look only at the assignerShortName in a cvelistV5 CVE entry, you might not get the whole picture of whose CVE it technically is. While the Linux kernel rewrote history to claim that they assigned the CVE, that was only done via the cna container's ProviderMetadata shortName value. The top-level [assignerShortName](https://github.com/CVEProject/cvelistV5/blob/main/cves/2025/0xxx/CVE-2025-0927.json#L7) for the entry still shows canonical.

Good times...

There's this magical thinking that the CVE ID is what gives attackers the ability to compromise systems.

If you say that your software is vulnerable but fail to assign CVEs, you're only helping the attackers.

I remember the time that Microsoft got mad at me for "leaking" one of their CVEs to the public before the update was available. As in their world, CVE IDs were for Microsoft updates. Not for identifying vulnerabilities. 🤦♂️

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

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.

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

Edit for those looking for the TL;DR version of this thread:
There are 3 flaws related to vulnerable driver blocking / WDAC:
1) If HVCI is off, then WDAC blocks via file signer that have a FileAttrib qualifier (e.g. all by-signer entries in the MS vulnerable driver blocklist) will not be blocked
2) The driver block list that's pushed to endpoints is not the same list as the public driver blocklist. The on-endpoint blocklist is missing numerous hashes.
3) HVCI systems do not obey the FilePath qualifier for WDAC rules

MSRC has indicated that they don't consider any of these issues to be vulnerabilities, so they will not fix.

----- Original thread as follows -----

I recently deleted a thread here as my tests were not valid. What was wrong? The driver I was using as an example of "blocked via signer" was indeed in the Microsoft recommended driver block rules list for TWO YEARS (It's present in a March 2023 version of the list). Given that the blocklist is updated on Windows endpoints "1-2 times per year", this should be present in the blocklist on a Win11 machine in 2025, right? Get real. It's bugs all the way down. No, I haven't (yet?) investigated which drivers are in the official list online, but are missing on Windows endpoints. But the fact that the first viable-for-testing driver that I chose was NOT in the list on endpoints... let's just say that this isn't a good sniff test.

Anyway, the problem that came to my attention on the Bad Place was that a user complained that that a driver that was expected to be blocked was being allowed to run if HVCI ("Memory integrity") wasn't enabled. This can't be right, can it?

Yes, it's true. The drivers listed in the Microsoft recommended driver block rules list by way of their signing certificate do NOT result in the driver being blocked (via WDAC). So just as a test, I created my own WDAC block list (with App Control Wizard and applying it with ApplyWDAC) for an arbitrary driver.

Let's compare 3 drivers that should be blocked, on a system with HVCI off, and on a system with HVCI on.

• Blocked via Authentihash in the MS vulnerable driver blocklist
• Blocked via Signer Cert in the MS vulnerable driver blocklist
• Blocked via Signer Cert via WDAC manually

If you do not have HVCI enabled, you are likely missing driver blocks that you are supposed to be getting.

So, based on our BSOD, we can conclude that non-HVCI WDAC driver blocking based on signer does work. But didn't I say earlier that it does not?

I'm glad you're paying attention. Yes, based on this test we can conclude that WDAC driver blocking based on signer does indeed work. But blocking based solely on signer never really happens in the real world, since it's important for Windows to be able to boot. So in the real world we have blocking by signer with FileAttrib qualifiers.

This is what's broken with non-HVCI attempts to block things based on signer. (Publisher and friends)

Without a FileAttrib qualifier, Windows will BSOD, thus proving that WDAC is effective in blocking drivers by signer. However, with a FileAttrib qualifier, Windows without HVCI won't bother blocking anything by signer.

If we think that WDAC individual block list rules work OK, but the Microsoft recommended driver block rules do not work on HVCI-disabled system, how can that be?

The MS list, despite listing blocked signers, also uses a FileAttrib qualifier for the signer being blocked. In the case of the Truesight driver I'm using for testing, the MS blocklist specifies a "FileNameand aMaximumFileVersion` property that is required for the block to take place.

Why is this done? If you simply use WDAC to block a file by it's signer, you'll have a lot of collateral damage.

That nasty driver you want to block? It also has signers that are legit. For example, Microsoft Windows Hardware Compatibility Publisher. 😀

What happens if we just attempt to block this Truesight driver based on its signer without using such qualifiers? Windows won't boot. Why? Well, this vsock.sys driver shares a signer with the bad Truesight driver. Therefore, without a precise block list, the driver will fail to load because the important driver is blocked.

Further investigation of the endpoint's driver blocklist being out of sync with the online one:

If count Authentihash, filename/version, and code signer entries, a February-2025-patched Win11 box has 1818 entries, while the online Microsoft recommended driver block rules list has 1906. The fact that the online list is more up to date than a thing that gets pushed out on Patch Tuesday is expected, right?

Wouldn't we be so lucky.

If we compare the online driver blocklist vs. the blocklist on fully patched Win11 endpoints and ignore the entries added in December 2024 (which are presumably not present because they're too new) we can break down the missing hashes:
Authentihash:
9 are 2 years old
3 are 1.8 years old
Signer:
3 are 2.4 years old

I'm only comfortable with one of those entries not (yet) being on Windows endpoints. What is the excuse for the rest? If Microsoft is going to maintain two different driver block lists (why?), perhaps it would be wise to do a good job of it? You know, to maybe check that they're in sync? 🤦♂️

If we test with our own custom WDAC rules, we can confirm that all of the allowed properties to block by are indeed obeyed by Windows. Specifically:
Hash, FileName, FilePath, SignedVersion, PFN, Publisher, FilePublisher, LeafCertificate, PcaCertificate, RootCertificate, WHQL, WHQLPublisher, WHQLFilePublisher

When we test these blocking techniques individually, they all seem to work fine. Including blocking by signing cert (FilePublisher). So this suggests that WDAC blocking by signing cert is not broken, but rather there's something broken about the Microsoft recommended driver block rules list when it's not enforced by HVCI.

However, in the process of testing individual blocking techniques, I've discovered a third vulnerability. On a system that is successfully using the FilePath WDAC blocking directive, if I enable HVCI, that block will suddenly stop blocking.

That is, while turning on HVCI is a wise move across the board, this is a specific case where having HVCI enabled is ironically less secure than having it off. The Microsoft recommended driver block rules doesn't have any entries based on FilePath, so this block list is unaffected by this problem. But surely there's somebody out there with FilePath block rules that is unknowingly missing protection on systems with HVCI enabled.

To eliminate variables, I got these screenshots by starting with a system that has a working FilePath WDAC block enabled, and simply enabled HVCI on that same system. The mere act of enabling HVCI on a system causes a working FilePath rule to stop working.

It truly is bugs all the way down, but just to summarize what we've discovered after pulling a thread about blocked drivers not being blocked:

1. If HVCI is off, then the Microsoft recommended driver block rules list will not block any entries that are present based on signing certificate (FilePublisher)
2. The driver block list that you get by enabling the "Microsoft Vulnerable Driver Blocklist" feature in windows is not merely delayed (Microsoft reports that it's updated 1-2 times per year) from the public list, but more importantly it's a different list that you get. (Further investigation in how it differs is required)
3. If HVCI is on, any FilePath-based blocks will be ignored.

LOL. Just got a response from MSRC, and they don't consider any of the 3 vulnerabilities I reported to them (outlined earlier in this thread) to be security issues, and therefore will not be servicing any of them.

CWE-693: Protection Mechanism Failure is not a thing in Microsoft's minds, apparently.

Even recently, there are folks talking about how the Microsoft recommended driver block rules list protects against BYOVD attacks.

This is a lie. Or at best misinformation, which seems to unfortunately gets repeated by those who don't really understand how things work.

Yes, you can prevent an attacker from bringing their own driver ("vulnerable" or not) by using a signed (e.g. enforced by SecureBoot) WDAC policy. I hope you don't mind extra work, as this isn't easy/free.

If you want to dig deeper into the thought experiment about what constitutes a "vulnerable" driver vs. one that isn't vulnerable, feel free to read up on BYOVD Protection is a Lie (Part 2)

TL;DR: Anybody suggesting that the Microsoft recommended driver block rules protects against BYOVD is wrong. An attacker bringing their own driver is already an admin, and on default Windows configurations, an admin can do what they want on a system. They don't need vulnerabilities. Heck, an admin attacker can install arbitrary homemade drivers that have never even had a valid signature if they wanted to.

The Microsoft recommended driver block rules is fine for preventing vulnerable drivers that might be already present on your system from being exploited. But don't fool yourself into thinking that it will help protect against attackers bringing your own driver.

Once Microsoft fixes the blocking capabilities of the Microsoft recommended driver block rules on non-HVCI systems, then the ability for attackers to target already-present drivers will be further hampered. But the flaws that I've outlined in this thread won't affect attackers bringing their own drivers. They already own your system.

But what about with HVCI on? Does turning HVCI on now make FileAttrib qualifiers work for block lists?

Wouldn't it be so easy? On the upside, blocking by signer with FileAttrib qualifiers works.

On the confusing side, the FileName qualifier is seemingly not enforced in a way that makes sense.

That is, I can make a copy of the Truesight driver and give it a completely different name (bysigner in my case), and it's still blocked by "Device Guard". I cannot fathom why/how this is the case. Other than HVCI-enabled systems having an altogether different blocklist than non-HVCI systems?

But as it is, DeniedSigner blocking with an associated FileAttrib qualifier is currently broken in Windows. In the case of non-HVCI systems, drivers are allowed that should be blocked. And in the case of HVCI systems, drivers are blocked that should probably be allowed.

I think I've reached my limit as to what my poor brain can grok with all of this. But all 3 bugs (vulnerabilities, IMO) are in Microsoft's hands, so we'll see how they sort it out.

@cR0w
I mean, when they refused to accept my video on YouTube, they did tell me to upload the video to OneDrive, which could end up costing me money depending on my quota. 😂

One of the 3 vulnerabilities that I've outlined is that the on-endpoint driver blocklist is a differently-maintained list than the online list.
Am I being pedantic and nit-picking here?

Per MSRC, the discrepancy is intentional:

Lastly, regarding the Online Driver Blocklist, the online list is supposed to be a superset

Let's say that theoretically this is not a lie...
1) How well known is it that the online Microsoft recommended driver block rules list is intentionally a superset of what endpoints see? The language in the online blocklist clearly says that the blocklist gets put on endpoints via Windows Update. 🤔

2) Let's pick a sample driver used by the years-old exploit KDU. Driver number 1 provided by this tool is RTCore64.sys
This driver is definitely in the online Microsoft recommended driver block rules list. Let's test it out in a Windows 11 with the "Microsoft Vulnerable Driver Blocklist" option enabled.
Oh... it loads? And it allows us to disable driver signature verification?
This seems less than ideal.

Tell me, oh internet public, why might Microsoft intentionally choose to allow a years-old public exploit to continue to work?

Oh, right. It's easier to blow off a researcher with a "this is intentional" as opposed to actually read the report that they submitted and address the problem. 🤦♂️

@cR0w
I did have an AV vendor recently request my EICAR-containing PoC in a password-protected ZIP file in my already-PGP-encrypted email.
Presumably their workflow for handling encrypted emails automatically deleted my PoC. 😂

@buherator @cR0w
Yeah, even with a number of different ZIP passwords, I found that Gmail's SMTP server still found the evil inside if I didn't use PGP encryption at the higher layer.

@cR0w @buherator
I didn't investigate much further, but I suspect that Gmail's SMTP server will attempt a list of known passwords, plus each word that exists in the email itself to decrypt encrypted ZIP files that are attached.

@GossiTheDog
Apple seemingly has an intermittent bug on OS updates that causes the device to go through the first-time welcome screen, which includes the ask about Apple Intelligence.

When I did the update to iOS 18.3.1, I got the welcome screen and Apple Intelligence step on two devices that were already opted out.

Those same devices both updated to 18.4 today without said screens. 🤷♂️