One of the most notable vulnerabilities patched during Microsoft's first Patch Tuesday of 2020 was a spoofing vulnerability in the Windows CryptoAPI. This has been issued CVE-2020-0601 and has also been referred to as the "Curveball" or "Chain of Fools" vulnerability.
The root of the vulnerability is in how Windows handles and validates Public encryption keys using specific ECC (Elliptic Curve Cryptography) algorithms. An ECC key has two parts to it; the actual bytes that define the encryption key itself and then metadata in the form of ECC parameters. When Windows validates these keys, it only does so by checking the key bytes and not the parameters. This would allow an attacker to generate a false key that would be validated as long as the key bytes match (even if the parameters do not). This vulnerability was introduced in Windows 10 since, before that, Windows didn't support ECC parameters.
Using a spoofed certificate could allow an attacker to spoof a valid encryption certificate and pretend to be to the valid organization. Typically an attacker would spoof a CA certificate. A CA stands for Certificate Authority and is a trusted root certificate that verifies and signs the certificates used for actual encryption. If your software or operating system trusts the CA, then it will trust all certificates that the CA has "signed" as trustworthy.
With a fake CA certificate, an attacker could generate and sign any certificate they want, and it would be trusted as authentic. For instance, an attacker could use a spoofed CA certificate to create certificates for your banking website or favorite e-commerce shop. If they could then convince you to visit their fake website, it would still appear to be valid by your webserver. In another attack vector, an attacker could play a man-in-the-middle attack if they have a presence on either the server or client's network. When the victim attempts to establish an encrypted connection with a website, the attacker intercepts the connection and presents the victim with their spoofed certificate instead. This would allow the attacker to decrypt all communication between the victim and the website.
Finally, the attacker could also use a spoofed certificate to sign software. Vendors often digitally sign their software so that users (via an automatic process in the Operating System) will know that the software they are executing actually came from the vendor that wrote it and not some rogue actor. With a spoofed certificate, an attacker could sign their malware and pass it off as valid software from a specific vendor.
In addition to the native patch now available from Microsoft, the Google Chrome web browser has been updated to flag these invalid certificates, while Mozilla's Firefox already had protections to prevent acceptance of these types of spoofed certificates.
Trustwave Secure Web Gateway (SWG) customers are protected "out of the box" against these types of attacks. Since SWG is not vulnerable to this issue, it will correctly validate certificates and reject those that are spoofed.
Note that there are two policies that pertain to SWG’s behavior with certificates: HTTPS policy, which controls whether or not SWG will allow establishing a connection with a website with an invalid certificate. The second policy is the digital certificate validation rule within the security policy, which tells SWG how to react to files signed with invalid certificates. The default policy is to reject invalid certificates, but customers may want to verify that these defaults have not been modified.
Additionally, Customers of Trustwave Security Testing Services will be able to verify if their systems have been appropriately patched against these attacks.
For more information, please refer to Microsoft's write up here: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/cve-2020-0601
