> “It confusingly claims their program ‘ensures researchers are compensated and publicly acknowledged’ in a statement answering a researcher who says he got neither,”
Well said.
Feeling consequences are how they are kept in line. Maybe next time they will think twice before (allegedly) treating a person like they did here, as well as the creative reasoning I recall them using in the past to reduce payouts.
That said, I feel bad for the inevitable victims of exploitation and also I am certain he will end up criminalized or as per usual the law will enforce a large corps will against him.
Yes. Definitely a Friday night after a hard week take.
The denial of Microsoft is just as harmful as the exploits of these flaws.
But nobody can buy PUTs at 2am on a saturday morning? You should buy PUTs on a friday before close then dump the exploits no?
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...
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.
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.
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.
source:
the concept is to shield the TPM its bus, and any keys whith the CPU chip.
https://pulsesecurity.co.nz/articles/TPM-sniffing
The best way would be to arguably keep the key completely off the TPM and use remote attestation. There's some preboot products out there like WinMagic SecureDoc* that use a little Linux partition, spin up just enough to get a network connection up to a remote server, provide authentication services, and then send the Bitlocker key down, unlock the partition, and chainload onwards to Windows.
* I acquired an enterprise device on eBay and was VERY surprised to find this product on it as the preboot protector. Zero way to crack in from my end, so I applaud it. There's even some MFA solutions they offer around this! https://winmagic.com/en/solutions/mfa-windows-login/
Maybe Microsoft should spend less energy threatening researchers and more on not shipping the slop code in the first place.
Precisely. /Your/ customers. I have no obligation to them and you profit handsomely from them. I'm not sure you can use "opposition" as a strategy to ameliorate your own negligence followed by inaction.
GitHub bans security researcher who posted zero-day Windows exploits
I hope the promise of a July 14th threat goes as planned. They need to hurt. And everyone needs to see the risks they are taking by using their products.
Microsoft is making all indications that it is behaving like a colossal dick. It’s not a good look. As always: if you find yourself in a deep hole, stop digging.
Usually, when an individual is that upset, the group or corporation is wrong and tries to shape public perception by lying.
Since when is publishing zero days a crime anyway? Shame on Microslop for these intimidation tactics. The real crime is vibe coding operating systems.
You can create a key or similar attribute which has an unlock policy based on those PCR values. If you play back the log of PCR write events from first principles (the log can be captured for debug purposes), you'll put the TPM into the same state and should be able to use anything protected by the respective policy.
For attestation, I presume you're thinking about sending an attested PCR quote - in that case, the TPM uses a non-extractable key to sign the current PCR states. As you can put the PCRs into the "correct" state, you'd be able to get a signed attestation the system is in that state.