6 ms·
This story has been widely under-reported and the impact is potentially huge. My beef with MS is this: the keys were leaked in 2021 and were still signing authe
by ggeorgovassilis 3y ago
This story has been widely under-reported and the impact is potentially huge. My beef with MS is this: the keys were leaked in 2021 and were still signing authentication tokens in 2023, but there's not a single Azure service that allows me to enter credentials with a 2 years duration. It's a classic case of "do as I say, not as I do".
- ahoka 3y agoThis. They don’t even use a HSM if I understood correctly and using one is not part of the mitigation plan. Not OK.
- lazide 3y agoHSM’s are super inconvenient obviously, and as Mr. Robot showed not perfect. So why bother? /s
- jnsaff2 3y agoApparently they might also be backdoored by the NSA: https://news.ycombinator.com/item?id=37571014 https://news.ycombinator.com/item?id=37571014
- lazide 3y agoStill probably better than having the private key part of a random core dump from a random developer. :s That’s just embarrassing.
- jnsaff2 3y agoNo doubt. My expectations to MS engineering are really low so I'm unfortunately not shocked.
- grotorea 3y agoFrankly is this important? If the NSA is a threat to you do you have any business trusting MS?
- lazide 3y agoNo one has any business trusting Microsoft, apparently? I’m under no delusions that an intelligence agency with ‘home team advantage’ wouldn’t already have the keys to the kingdom. If they are in the apparent habit of leaving the keys sitting around in random Cafes, the odds that other non-home team intelligence agencies have a copy increases dramatically too. Or even random miscreants. As to if that matters? Eh.
- reilly3000 3y agoThey sure sell HSM on Azure.
- Muromec 3y agoThe worst part of the story to me is —- those were not even the right keys, those were something issued to a client and scoped, but scoping check was broken. It’s unbelievably bad all around
- ShadowRegent 3y agoClose, but not quite. The keys were for consumer Microsoft accounts, but accepted for organization accounts as well.
- deleted 3y ago[deleted]
- yrro 3y agoImagine what the CA/Browser Forum would do if they discovered that a PKIX CA had lost control of its signing keys, didn't revoke them and in fact carried on using them for 2 years without telling anyone...
- inetknght 3y agoHave you checked if you have a Microsoft CA installed to your system?
- yrro 3y agoI simply assume Microsoft have already compromised my systems already. :)
- yrro 3y agoMore seriously, on my Debian stable system: $ dpkg -l ca-certificates Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===============-============-============-================================= ii ca-certificates 20230311 all Common CA certificates $ trust list | grep Microsoft label: Microsoft ECC Root Certificate Authority 2017 label: Microsoft RSA Root Certificate Authority 2017 On RHEL 9: $ rpm -q ca-certificates ca-certificates-2023.2.60_v7.0.306-90.1.el9_2.noarch $ trust list | grep Microsoft label: Microsoft ECC Product Root Certificate Authority 2018 label: Microsoft ECC Root Certificate Authority 2017 label: Microsoft ECC TS Root Certificate Authority 2018 label: Microsoft Identity Verification Root Certificate Authority 2020 label: Microsoft RSA Root Certificate Authority 2017 label: Microsoft Root Authority label: Microsoft Root Certificate Authority label: Microsoft Root Certificate Authority 2010 label: Microsoft Root Certificate Authority 2011 label: Symantec Enterprise Mobile Root for Microsoft Interesting that RHEL has many more certificates, when both packages take whatever's bundled into NSS. According to 'rpm -q --changelog ca-certificates' RHEL take their certs from "CKBI 2.60_v7.0.306 from NSS 3.91" and according to /usr/share/doc/ca-certificates/changelog.Debian.gz, Debian take theirs from "Mozilla certificate authority bundle" 2.60.
- vladvasiliu 3y agoYou can still create "app registration secrets" that last for up to two years. Until recently, you could create essentially unlimited-duration secrets.
- bluemax 3y agoIt's only a limitation in the UI. Using powershell you can still create client secrets that are valid for hundreds of years.
- deleted 3y ago[deleted]