https://portal.msrc.microsoft.com/en-US/security-guidance/ad...
So what happens is, you're supposed to fill out a bunch of bytes as proof of who you are, and then a bunch of bytes that represent stuff like seconds since the start of the Unix epoch. If you can't do this, NetLogon figures you aren't really who you say you are.
And the exploit is: Fill everything out with all zeroes. This will succeed one time in 256 on average.
The reason why is complicated and somewhat interesting, but this stupidest possible exploit is what you get at the end of that complicated rationale.
I've written previously on HN that it stands out how terrible Microsoft is at cryptographic design. If there's an opportunity to roll your own and do it badly, in a Microsoft product that's what you should expect. Google has good people (it doesn't always use them, but most often it does) for this stuff, and Apple most often seems to accept that it doesn't have good people so it'll not roll its own but just use things that already exist; but Microsoft does this over and over.
In this particular case they took AES (seems fine) and an inappropriate but in principle secure cipher mode (CFB8) and then they... fixed the IV as all zeroes even though the definition of CFB is clear that you need to use a random IV.
Do they? Wasn't "goto fail" a bug in their SSL code? That one wasn't even a bug that a reviewer would need to reason about the logic of the code to see.
This Microsoft vulnerability isn't a bug in the code, it's a design mistake, if you implement exactly what Microsoft's design document says for NetLogon, one time in 256 all zeroes lets you in. By design. Stupid stupid design.
If Microsoft had specified that the IV has to be set to 0102030405060708090A0B0C0D0E0F00 this vulnerability doesn't exist. Is there a different vulnerability? Maybe, it's hard to see how to attack it. But with all zeroes, just send all zeroes, what could be easier?
A bit more detail on what happens next: "So with an all-zero IV and plaintext plus a randomly chosen key, you will end up with an all-zero ciphertext 1 in 256 times on average. [In other words] roughly once in every 256 times the server would randomly concoct a session key for which the correctly-encrypted version of their all-zero ClientChallenge would itself be all zeros."[1] Quoted from a detailed and nicely illustrated article about the bug.
[1] https://nakedsecurity.sophos.com/2020/09/17/zerologon-hackin...
It would take a lot to convince me that my position is false.
Think about what that would take: You'd have to explain to me, at length, that no-no-no, Microsoft cares deeply about the security of their customers, they hire professional cryptographers, and that they keep up with the best practices in ciphers, protocols, and configuration defaults.
So let us see what kind of uphill battle that would be:
In 2020, Microsoft products have all of the following current cryptographic problems.
- There is no support for TLS 1.3, either on the server or client.
- HSTS is very hit & miss, with only Windows Server 2019 adding partial support here and there.
- Until very recently, you'd have to jump through hoops to enable TLS 1.1 and 1.2. The operating system had the capability for years, but... Microsoft chose not to enable it. Explain that one without resorting to: "This helps the NSA hack everyone that doesn't know what they are doing."
- Across a forest trust, RC4 is the default cipher.
- If you try to enforce AES ciphers for Active Directory, you'll break some forms of single-sign-on from Azure AD!
- If you use ECC certificates, you're stuck with the handful of now very thoroughly legacy curves. Don't even dream of support for elegant, modern, secure ciphers like Curve25519!
- Keep in mind that Microsoft first implemented ECC ciphers and the associated "modern" Key Storage Provider (KSP) in 2006 for Vista. So you would think that only 2003-era software would still require the legacy CryptoAPI system, right... right? You'd be wrong: Notably, you can't have elliptic curve certificates with: NDES, AD FS, SQL Server, SCCM until very recently, and in fact just about every Microsoft product except for IIS. Which I remind you still can't do TLS 1.3. In Windows Server v2004.
- Azure Key Vault can't issue anything but RSA certificates from third-party CAs.
- Azure's disk encryption similarly refuses to use ECC, and has to use RSA for disk encryption.
- You can't get free certificates in Azure from Let's Encrypt or Microsoft themselves. Because a 1KB file in 2020 should still cost $50 a year, am I right? Otherwise how would VeriSign make their billions!?
- Certificate Services has had nearly zero new features in like a decade. Microsoft could have revamped the web interface, added certificate transparency support, SQL Server database support, PowerShell commands that... do... things, or anything really. Anything at all.
- There's no replacement for AD CS for that matter. It's clearly legacy, but Azure AD or Intune have no replacement. Enjoy your 2000-era interfaces and methodologies. You seriously have to write an INI file and put it into C:\Windows before installation to configure it!
Prove me wrong.
But you have no reason to believe a teapot orbits the sun somewhere. There is no reasonable way to believe that a teapot could have "gotten there". No space programs launching teapots just for laughs. Space programs in general being far too expensive for someone to launch something without government oversight.
Etc, etc...
My point is that the NSA does exist. They do degrade cryptographic algorithms, either through national security letters or simply bribery. The Dual_EC_DRBG fiasco happened. It really happened. Private United States based organisations do cooperate with these programs, either willingly or because they are forced to.
Now, ask yourself: What would it look like if Microsoft was -- hypothetically -- cooperating with the NSA?
Since Windows is so widely used, any weakness in its crypto would be a problem for the US itself! There's no separate "export version" any more.
(Which reminds me: "Export-grade crypto". Remember that? That happened too. That was not a "conspiracy"! That was law! Recently.)
Back to my point: how would you degrade the crypto but protect US interests?
Well, one method would be to have strong crypto in the software, disable it by default, and mandate that all US government organisations turn the strong crypto on. Simply rely on IT administrator lazyness and tight budgets of most organisations to ensure that 99% of the world outside of US Government remains on the weak sauce.
Exhibit A: FIPS mode.
Exhibit B: TLS 1.1 and 1.2 available but off by default.
Exhibit C: AES for Active Directory available but off by default.
Now do you get it? It looks suspicious.
It's one thing to accuse a neighbour randomly of murder. It's entirely another thing if you see them putting a shockingly large and heavy rolled up carpet in the boot of their car at three o'clock in the morning.
We have some 2008r2 hosts that are in the process of shutting down I had to gulag off.