rolling or trying to manage your own cryptography can be flawed

Zerologon: Why You Should Never “Roll Your Own” Cryptography



Image credit: Unsplash

The cryptographic algorithms commonly used and recommended by standards organizations like the Advanced Encryption Standard (AES) hold that status for a reason. They have undergone extensive review by professional cryptographers attempting to identify any potentially exploitable vulnerabilities. Only after intensive analysis are these algorithms approved for use.

Cryptographic algorithms undergo such intense scrutiny because cryptography is very easy to mess up. A single, even minor modification in a secure algorithm can render it defenseless to a cryptography attack.

The recent Zerologon vulnerability demonstrated the importance of never “rolling your own cryptography.” A custom cryptographic protocol and violation of basic cryptographic rules made Netlogon—and the Domain Controllers and other Windows servers running it—susceptible to exploitation.

How the Zerologon Vulnerability Works

To understand Zerologon, it’s essential to first understand the Netlogon authentication process. The goal of this process is to establish a shared, unique session key between the client and the server. While these systems both have a shared secret (the domain password), they don’t want to reveal or use it for their communications.

Session Key Generation

The Netlogon session key is established via the following process:

  1. The client and server each select an eight-byte random challenge and publicly exchange these values.
  2. The client and server independently generate the session key through the following steps:
    1. Concatenate the two challenges together to form a single challenge
    2. Hash the shared domain password with MD4 and concatenate it to the challenge
    3. Hash the resulting value using SHA256
    4. Use the first 16 bytes of the hash as the encryption key for AES

After establishing the shared session key, the client demonstrates that it has generated the same value as the server. This is accomplished by encrypting the eight-byte challenge it created at the beginning of the process using the new AES session key and sending the result to the server.

Netlogon’s Broken Cryptography

The problem with Netlogon’s authentication process is that it uses custom cryptography that was not properly vetted and eventually discovered to be broken. Netlogon uses cipher feedback (CFB) mode with AES. However, instead of using the standard version of CFB—which encrypts 16 bytes at a time—Netlogon uses a custom variant that encrypts one byte at a time.

Diagram 1

The image above (from Secura) shows how this custom CFB (called CFB8) works. The initialization vector (IV), shown in yellow, is encrypted with AES as it is in the normal CFB. However, only the first byte of the result is retained and XORed with the first byte of the plaintext (in blue). The result (pink) is appended to the end of the IV and the first byte of the IV is discarded (so the combination of IV and ciphertext is the same length as the original IV). This process is repeated until all of the plaintext is encrypted.

The modified protocol on its own may not have been enough to undermine the security of Netlogon. But Netlogon contained another critical error. The IV, which should always be unique and random, was hardcoded to a value of zero.

Diagram 2

Reusing IVs is a problem in and of itself, but it was exacerbated by the custom implementation and structure of CFB8. A plaintext consisting of all zeros will cause the algorithm to get “stuck” and produce a ciphertext of all zeros (as shown above) with 1/256 probability.

In this protocol, only the first byte of the output of AES encryption matters—all the rest are dropped. This byte is XORed with the next byte of plaintext and the result is appended to the IV and ciphertext.

In the case where an all zero plaintext produces an output with a zero in the first byte (which happens in 1/256 cases), then the XOR is 0 XOR 0 = 0. The value going into the AES algorithm (and the key) remain unchanged, so encryption will always produce a zero in the first byte (which is XORed with a zero to produce a zero that is appended to the IV, etc.). As a result, the ciphertext is all zeros as well.

This becomes a problem because, in one case, the attacker can guess the output of encrypting a certain plaintext without knowing the encryption key. This is useful in two places in the Netlogon protocol:

  • Authentication: Netlogon authentication succeeds if the user can encrypt a user-selected challenge value. By repeatedly authenticating until the shared session key creates the all-zero case, an attacker can successfully authenticate without knowing the session key (which requires knowledge of the domain password).
  • Password reset: Netlogon has a password reset function where an all-zero input sets the server key to an empty password. While the arguments in this function call are encrypted, the attacker knows that an all-zero ciphertext will decrypt to an all-zero plaintext.

The impacts of these two attacks are significant because a user can reset the server password without knowledge of the domain key. This enables them to dump all of the password hashes stored in a Domain Controller for offline cracking or, via a pass-the-hash attack, gain Domain Administrator access and full control over the network maintained by the attacked Domain Controller.

Never Roll Your Own Cryptography

The Zerologon vulnerability was caused by two errors in the Netlogon protocol:

  • The use of a custom version of CFB
  • Failing to use a unique and random IV for encryption

Either of these mistakes on their own could have degraded the security of the application. The combination made it trivially easy to exploit and placed the security of an organization’s entire domain at risk.

Unfortunately, these kinds of mistakes are easy to make. To ensure your organization is safe, it’s important to ask a few key questions, including:

  • If you're an enterprise relying on your dev team to implement encryption, how do you know they're using a standard implementation in a secure way?
  • If you're a developer, how do you know which algorithm to use? Which ones are custom?
  • If you’re an executive who needs to defend your company’s use of encryption to regulators or customers, are you sure your encryption is compliant?

In any case, Ubiq can help keep your data safe with our standard encryption platform, which can be used for all your applications. We make sure that a standard best practice implementation of an algorithm is used and when an algorithm is deprecated or disallowed by AES, you can easily transition to the next best standard. Our encryption platform can be used centrally across all languages and applications.