KeyChest Blog

Massive MS Windows bug - by NSA - how it works (maybe)

Jan 14, 2020 10:33:36 PM / by Dan

I have just skimmed a looong discussion at Hacker News - - about a vulnerability so big that NSA was happy to be accredited. (I only wonder whether they spotted someone else using it.)


What does the bug do? It basically allows a random, malicious, server to pretend to be a legitimate server so long as the the latter uses ECC certificate. That completely breaks all the protection provided by HTTPS / TLS. Imagine there is no internet encryption. ... got it? Now imagine what you can do with DNS poisoning, MITM, etc.

There's a lot of maths and complicated equations, but not really a hint of how the attacker can make MS Crypto API fall for the trap.


Update 16 Jan 10:20am UTC: while the general principle below remains the same, it appears that the bug is related to a validation of certificates in MS Crypto API - rather than TLS handshake. You still need to de-couple the signature and EC parameters and the public key itself. The attack includes tweaking the root CA certificate. There was also an initial hint that CT logs can catch the attack but that is not the case.

Saleem Rashid did a PoC of the attack and it works on all browsers except Firefox that uses own crypto library.

Initial PoC results -

A Chrome follow-up -


What is clear - the attacker has to create a new ECC key that has the same public key as in a certificate of the server they want to impersonate. They do it by adjusting the parameters of the elliptic curve. In other words, the public key is the same, but the private key and the elliptic curve is different.

What does it mean to change the parameters of an ECC? The school maths works with numbers as if they were on a straight line - multiplying by 2 = moving along the line twice the distance from zero. Changing ECC is like bending that line to get numbers next to each other, instead of calculating equations properly.

OK - so the attacker has:

  1. a valid certificate from a legitimate server
  2. own key pair - its public key is the same as the public key in the certificate
  3. ECC parameters used to calculate the own key pair (private key)


All the preps are useless, if we can't make clients (our prey) to cooperate. There aren't many options for the server to force a remote computer to co-operate. It will only "talk" TLS, so the leverage has to be found there.

One of the TLS algorithms is a combination of ECDHE (Diffie-Hellman) and ECDSA. It should provide "perfect - forward - security". The crypto standards say that both algorithms have to use the same ECC parameters. But each of the algorithms is defined in a different standard, which caused redundancy - the same information - the ECC parameters are sent twice within each TLS/HTTPS handshake.

ECDHE parameters are sent as part of the ServerKeyExchange message, ECDSA parameters are in the certificate. Validation order should be:

  1. validate the certificate - verified against a list of trusted root CAs
  2. extract ECC parameters from the certificate - verified by the cert
  3. check the signature on TLS message with ECDHE - using the public key of the server
  4. check the params in the message are the same as ECC parameters
  5. use the ECDHE with its ECC params

It seems that MS Crypto API has done it differently:

  1. validate the certificate - verified against a list of trusted root CAs
  2. get ECDHE and ECC params - NOT verified
  3. check the signature on TLS message with ECDHE - using ECC params from (2) and the public key from the certificate
  4. use the ECDH with its ECC params

The problem is step (2), which breaks the chain of trust and allows the server to force clients into trusting malicious servers. It's like skipping a few transactions in a blockchain.


Anyway, that's my take. It looks feasible but maybe the bug was somewhere completely different :)


As you're here, why don't you have a look at our KeyChest HTTPS expiry management and test your domain for free?


Tags: https, attack


Written by Dan