there are active forks, and active mitigations for redsun undefend and bluehammer.

so far as i can tell yellowkey is problematic, as the exploit takes advantage of a backdoor that ms needs, to "manage" your computer.

only recently has a OOB mitigation been offered

https://www.techspot.com/news/112410-security-researcher-mic...

▲

mittensc 4 hours ago | parent | next [-]

> so far as i can tell yellowkey is problematic, as the exploit takes advantage of a backdoor that ms needs, to "manage" your computer.

It does look like an intentional backdoor. The way ms is responding to it is even more suspicious.

Pretty funny since this defeats security on most corporate laptops, so impact is huge. You'd expect them to treat the reporter better and fix the issue fast...

I'm curious why they put it in, I'm not sure I understand the 'to "manage" your computer' note.

Microsoft should have no reason to put something like this in. So either they were forced or they had some engineers that did this on their own without any oversight.

▲

jeroenhd 3 hours ago | parent | next [-]

The backdoor could be a bug, but I don't really understand how it happened.

The attack works by having an NTFS log get replayed against another partition than the one the log is stored on.

Sending the right signals to unlock Bitlocker in TPM-only mode is a necessity for recovery operations. Managing to replace the executable launched post verification is a plausible attack vector.

The weird thing is why it's possible to put the corrupting transactions on a different disk than the one being updated.

In theory I think it would be possible that it's a combination of "all recovery partitions share the same FS identifier and are verified before transaction playback" (it is a pre-packaged WIM file after all) and "the transaction log stores the FS identifier of the partition the changes are meant for", but in my opinion the latter part is a very weird architecture to choose.

If this is a backdoor, I appreciate how clever they were hiding it. If this is a bug, the person who discovered it probably has a whole lot more ready to publish.

	▲	Shank an hour ago \| parent [-]
		The thing that made Nightmare think it was a backdoor is that the bug is only present in the recovery version of the DLLs, not the one built into the system, and not prior versions of Windows. It’s also for a file system feature that Microsoft hasn’t “touched” in ages and they consider fairly esoteric.

▲

rolph 4 hours ago | parent | prev [-]

manage- meaning remove or disable your stuff and reinstate slopware.

i dont know how much fiddling around you may have done to make a win11 install local and secure, but but if you dont get it right the first time, most often the next update will involve re-installation of bloatkrapp.

the in house usage is apparently to allow bypass of bitlocker by the winRE recovery environment.

this has been exploited for some time already, allowing malicious uses of trustedinstaller ACL.

ive had to deal with persistent installs using exactly this route, and a really nasty one will brick your machine if you dont knock out its components in proper sequence pwning the trusted installer account, and disabling the viral recovery mechanism.

▲

ranger_danger 4 hours ago | parent | prev [-]

> backdoor that ms needs

source: