jgeurten
commented
6 months ago Great suggestion, @SebCT!
Open SebCT opened 6 months ago
jgeurten
commented
6 months ago Great suggestion, @SebCT!
HotCakeX
commented
6 months ago @SebCT Hi
Correct me if I'm wrong but WHQL doesn't mean more security, it only means more compatibility with the OS as in more tests have been done with the driver. So if your intention for strictly enforcing WHQL drivers is to boost security then it just won't do it.
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/whql-release-signature
That's why for more security, we need to actually have a zero-trust strategy.
You can use WDAC Wizard and WDACConfig module which also reveals that driver you're referring to when you deploy a strict kernel-mode policy in audit mode, offers the native PowerShell GUI for selecting individual logs, I happen to have the same hardware as you. The combination of both the Wizard and module offer so many features and capabilities and they just keep getting better 🙂
SebCT
commented
6 months ago @SebCT Hi
Correct me if I'm wrong but WHQL doesn't mean more security, it only means more compatibility with the OS as in more tests have been done with the driver. So if your intention for strictly enforcing WHQL drivers is to boost security then it just won't do it.
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/whql-release-signature
That's why for more security, we need to actually have a zero-trust strategy.
You can use WDAC Wizard and WDACConfig module which also reveals that driver you're referring to when you deploy a strict kernel-mode policy in audit mode, offers the native PowerShell GUI for selecting individual logs, I happen to have the same hardware as you. The combination of both the Wizard and module offer so many features and capabilities and they just keep getting better 🙂
@HotCakeX Hello!
Thanks for your reply, i know your WDAC-module a little bit and it's really an amazing work, will get to know it better the next time and will try it out :-)
Concerning the strict WHQL enforcement: is important for denying cross-signed WHQL drivers and it should be the norm since Win10 1607 to sign kernel drivers striclty WHQL - here are some links, one is from Matt Graeber, i learned a lot from his blogs and online material since 2016 (i started with the former device guard in 2016, it was very difficult, WDAC is a lot better now), and another one from Geoff Chappell concerning the danger behind cross-signed drivers:
Adventures in Extremely Strict Device Guard Policy Configuration Part 1 — Device Drivers:
-> "I also applied the “Required: WHQL” option as well because I wanted to apply as many rules as possible where WHQL co-signing validation was also performed."
Back doors for cross signed drivers:
https://www.geoffchappell.com/notes/security/whqlsettings/index.htm
-> "For Windows 10, Microsoft took the opportunity to draw a line and make it significantly more difficult for anyone outside Microsoft to sign drivers that Windows will load in anything like ordinary use. Microsoft’s first-known public statement of motivation for Driver Signing changes in Windows 10 was: We’re making these changes to help make Windows more secure. These changes limit the risk of a driver publisher’s signing keys being lost or stolen and also ensures that driver publishers are strongly authenticated. For most practical effect, all new drivers must be signed directly by Microsoft.The days of Windows users being exposed to cross-signed drivers that can have been signed by just about anyone, possibly for mischief, possibly without being traceable, are numbered. Though this goal surely could be met securely without going so far as requiring that drivers can load only if signed by Microsoft, there doesn’t look to be any reasonable dispute that the goal is worthy or even that cross-signed drivers would better be gone."
Some Links from MS:
HotCakeX
commented
6 months ago @SebCT Well, the thing is, those articles aren't up to date, the threats they were trying to mitigate have changed significantly since then. We're in the era of BYOVDs, where totally-legit Microsoft-signed drivers are being used maliciously because they have vulnerabilities.
WHQL enforcement won't help it at all, one step further than that is enforcing EV Certificates for drivers but even that won't help with today's threat model as I explained in my article.
If you really want to vet your drivers and lock down your kernel, you need to follow that scenario and remove the blind trust to any entity whatsoever (except for the 3 root certificates used by the Windows itself) and that is the only way to stay protected against BYOVD scenarios and much more.
Nowadays, threat actors don't care if a driver is WHQL signed or not and that's the point I was trying to explain in my comment, WHQL certification does not include vulnerability scanning of drivers, it only guarantees that the hardware driver is compatible with the OS.
I just like when I decide to do something, do it once and right, now on my systems, when I install some random app such as OBS, its kernel-mode virtual webcam driver doesn't automatically load because I didn't allow it.
When I install system informer or WireShark, its kernel-mode driver doesn't run even though it's WHQL signed and so on, it just doesn't matter anymore.
Even if the whole world says something is trustworthy, as long as your personalized policy on your computer doesn't allow a kernel-mode file to run, it shouldn't run, that's really powerful stuff that Windows has got since many years ago!
P.S you can use WDAC Wizard and its GUI to achieve the scenario i explained in my article as well. Just follow it and use the Wizard to remove the unnecessary signers from the default Windows template.
SebCT
commented
6 months ago @SebCT Well, the thing is, those articles aren't up to date, the threats they were trying to mitigate have changed significantly since then. We're in the era of BYOVDs, where totally-legit Microsoft-signed drivers are being used maliciously because they have vulnerabilities.
WHQL enforcement won't help it at all, one step further than that is enforcing EV Certificates for drivers but even that won't help with today's threat model as I explained in my article.
If you really want to vet your drivers and lock down your kernel, you need to follow that scenario and remove the blind trust to any entity whatsoever (except for the 3 root certificates used by the Windows itself) and that is the only way to stay protected against BYOVD scenarios and much more.
Nowadays, threat actors don't care if a driver is WHQL signed or not and that's the point I was trying to explain in my comment, WHQL certification does not include vulnerability scanning of drivers, it only guarantees that the hardware driver is compatible with the OS.
I just like when I decide to do something, do it once and right, now on my systems, when I install some random app such as OBS, its kernel-mode virtual webcam driver doesn't automatically load because I didn't allow it.
When I install system informer or WireShark, its kernel-mode driver doesn't run even though it's WHQL signed and so on, it just doesn't matter anymore.
Even if the whole world says something is trustworthy, as long as your personalized policy on your computer doesn't allow a kernel-mode file to run, it shouldn't run, that's really powerful stuff that Windows has got since many years ago!
P.S you can use WDAC Wizard and its GUI to achieve the scenario i explained in my article as well. Just follow it and use the Wizard to remove the unnecessary signers from the default Windows template.
@HotCakeX I know the BYOVD scenario, so i always used a strict allowlist on my systems and i only use the few EKU's you mentioned on my systems (i also do not want flight signing EKUs). Of course it's something not everyone wants to do because it can be painful - but strict driver allowlisting (in combination with the recommended driver block list from MS) is the configuration i really like.
And as i meant with those articles, even if they are older now, i want to block those legacy cross-signed or badly signed drivers, so i use the WHQL setting only for this particular scenario. Wireshark still works for me by the way with WHQL enforced, and i have to say i didn't have much problems with this settings - it was the first time since several years that i saw such a block now with this logitech driver (which i don't need anyway, GHUB doesn't use it).
Hello,
One question concerning kernel mode drivers (*.sys), that have failed the WHQL check with Application control event tag 15 "Failed WHQL check." - as it is listed here from Microsoft:
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/operations/event-tag-explanations
Is it possible to parse this for creating a policy with the "Convert Event Log to WDAC policy" function in the Wizard? Actually it doesn't show this, but it is in the event logs defined and will be created if an SYS Driver fails WHQL check.
As an example: the new "logi_lamparray.sys" driver from the new dynamic lighting feature in Windows 11 with Logitech devices fails with event tag 15, but you can't see this in the wizard - so i still use the very nice WDAC Toolkit PS Module from Matt Graeber (see https://github.com/mattifestation/WDACTools/blob/master/WDACAuditing.psm1) which can show this tag as you can see in this screenshot:
Would be amazing if this could be added in a future version of the wizard, it would help a lot if you have a WDAC policy with strict WHQL enforcement - thanks in advance!