Exploiting the Windows Cryptoapi Vulnerability

  from the_heavy_lifting_crypto_heavy_module import verify_signature

  def is_known_trusted_ca(cert):
    # BOOM
    return cert in root_ca_cache[cert.pubkey]

  def verify_cert(cert, issuer):
    # BOOM
    if verified_cache[(cert.pubkey, issuer.pubkey)]:
      return True
    if not verify_signature(cert, issuer):
      return False
    verified_cache[(cert.pubkey, issuer.pubkey)] = True
    return True

  # This has to be a search instead of simple chain-walking because servers
  # do not send a "chain", they only send several additional certificates and
  # let the client find a trusted path out of them, it is also how cross signing
  # works. This justifies using a cache above.
  def try_to_build_cert_chain(cert, cert_store):
    if is_known_trusted_ca(cert):
      return [cert]
    for possible_issuer in cert_store.find_certs_with_dn(dn=cert.issuer_dn):
      if verify_cert(cert, possible_issuer):
        chain = try_to_build_cert_chain(possible_issuer, cert_store)
        if chain:
          return [cert] + chain

The exact detail does not matter though, you can build up working exploits even if you don't know the details listed above.

In RSA for example there's a public exponent, yours is almost invariably going to be 65537 and most of the time nobody will even mention this parameter, but the "same" key with exponent 3 would actually be a different key than yours.

In code such shorthand becomes a bug.

If you only allow a handful of named algorithms the bug is essentially useless to adversaries. Microsoft's non-standard decision to allow parametrised curves makes it into a huge attack surface.

The right response to this vulnerability is to jettison support for anything but named curves.

This is probably an inside-baseball argument for people who don't pay attention to elliptic curve implementation details. But it's easy to quickly understand.

Go to SAFECURVES.CR.YP.TO; you'll see a big long list of curves, each with their parameters and some implementation details. In reality, only a subset of these curves are commonly used (P-224, P-256, Secp256k1, and Curve25519 probably account for 95% of all curves).

Further, most specific curves are implemented not as parameters plugged into a generic elliptic curve scalar multiplication routine, but rather as curve-specific code (one of the major reasons we have different curves is to allow specific implementation optimizations). A browser that supports Curve25519 certainly uses Curve25519 code, not generic code.

The "explicit curve" feature that blew up on Microsoft is designed to allow people to specify their own parameters, not for well-known curves but for curves they themselves generated. Nobody does that. There was a time, in the long long ago, when people thought that might be a good idea; nobody thinks that anymore; everyone thinks the opposite thing. If anything, we're trying to get rid of a bunch of curves. Certainly we shouldn't be randomly supplying new Weierstrass curves.

So that's the problem here. A lot of cryptography engineers were probably surprised this CryptoAPI feature even worked. We had considered it awhile ago as a cryptopals challenge (and Sean actually did add it as one in Set 8 a few years ago), but we never dreamed anyone would be crazy enough to let this bug happen in the real world.

Even if Firefox/Chrome use their own implementations of cryptographic algorithms, there's a decent chance that they are still using Windows's native API for certificate chain validation in order to plug into the enterprise certificate management features that come baked into Windows, which IT teams sometimes use to distribute internal PKI's. Without having seen how Firefox and Chrome deal with their chain building, I can't say "yes" or "no" definitively.

Please excuse me if I got the origin story wrong.

Edit: Also, from the website:

> Who’s behind this?

> Trail of Bits

That could certainly be (mis)interpreted as taking credit for the vulnerability.

https://bad.whosecurve.com/