Bypassing Signature Validation: The EKU Field Vulnerability

TLDR: Many applications fail to validate the Extended Key Usage (EKU) field in digital signatures, allowing attackers to sign malicious code with non-code-signing certificates. By patching signature verification tools like signtool or MAGE, researchers demonstrated that arbitrary payloads can bypass these checks. Developers must enforce strict EKU validation to prevent attackers from masquerading as trusted software publishers.

Digital signatures are the bedrock of software trust. When a user executes a binary, the operating system checks the signature to ensure the code hasn't been tampered with and that it originates from a known, trusted source. We assume that if a signature is valid, the code is safe. This assumption is dangerous because it ignores the implementation details of how that signature is validated. Recent research presented at Black Hat 2023 exposes a critical flaw in how many applications handle the Extended Key Usage (EKU) field, turning a simple validation check into a massive security bypass.

The Mechanics of the EKU Bypass

The EKU field in a digital certificate defines the intended purpose of that certificate. For example, a certificate might be restricted to "Server Authentication" or "Client Authentication." A code-signing certificate, by contrast, includes an EKU specifically for "Code Signing." The vulnerability arises when an application verifies the cryptographic signature of a file but fails to check if the certificate used to sign that file actually possesses the required EKU for code signing.

If an application only verifies that the signature is cryptographically sound, an attacker can use a low-cost certificate—such as a standard SSL/TLS certificate—to sign a malicious binary. Because the application doesn't verify the EKU, it sees a valid signature and assumes the binary is legitimate. This is a classic Broken Access Control scenario where the application fails to enforce the intended security policy.

Reproducing the Flaw

During the research, the speaker demonstrated how to bypass these checks in common tools like signtool and MAGE. These tools perform a client-side sanity check to ensure the certificate has the correct EKU. However, because this check happens in the application logic rather than the kernel, it can be bypassed by patching the binary.

Using a tool like dnSpy, an attacker can decompile the application, locate the method responsible for the EKU check, and modify the return value to always indicate success. For instance, in the CanSignWith method, simply forcing the function to return true effectively disables the EKU validation.

// Original logic:
// if (EKU_Check_Failed) return false;

// Patched logic:
return true;

Once the tool is patched, it will happily sign any malicious executable with an SSL certificate. The resulting binary will appear "digitally signed" to any system that relies on the same flawed verification logic.

Real-World Impact and Testing

For a pentester, this vulnerability is a goldmine for post-exploitation. If you are performing a red team engagement and need to bypass application whitelisting or endpoint detection systems that rely on signature verification, this technique is highly effective. You don't need a stolen code-signing certificate from a major vendor. You only need to identify an application or library that performs signature verification without enforcing EKU constraints.

The research identified vulnerabilities in several implementations, including the Mono Project and the uthenticode library. These are not obscure tools; they are used in cross-platform development and CI/CD pipelines. If a build server uses a vulnerable library to verify dependencies, an attacker could inject malicious code into the pipeline, and the build server would validate it as legitimate.

Defensive Strategies

Defending against this requires moving beyond simple signature verification. If your application processes untrusted binaries, you must implement strict EKU validation. Do not rely on the default behavior of third-party libraries unless you have verified that they enforce EKU checks. When using libraries like OpenSSL, explicitly configure the verification context to require the appropriate EKU.

Furthermore, treat signature verification as a high-risk component. If you are using a library that handles cryptography, it should be part of your regular security testing and fuzzing efforts. The research resulted in several CVEs, CVE-2023-36873, CVE-2023-36897, CVE-2023-39969, and CVE-2023-40012, proving that even widely used implementations are susceptible to these logic flaws.

Security researchers should look for similar patterns in other signature verification implementations. If you find a tool that claims to verify signatures, check if it actually validates the certificate's purpose. If it doesn't, you have found a bypass that can be used to sign arbitrary code. Always verify the assumptions your security tools make, because those assumptions are often where the most critical vulnerabilities hide.