Microsoft’s latest Patch Tuesday included fixes for 8 critical vulnerabilities covering Windows Server 2012, 2012 R2, Windows Server 2016 and 2019 and Windows 8.1 and Windows 10. Some of these vulnerabilities impact cryptographic certificates and components of the remote desktop service. These vulnerabilities allow attackers to attach remote desktop gateways without credentials and spoof encrypted HTTPS traffic and provide fake code signing certificates.
Here I’ll cover the impact of three of them, that collectively require careful attention to understand their scope and impact.


Cryptographic Spoofing Vulnerability


The biggest story is a vulnerability in Windows Crypto API (CVE-2020-0601), disclosed by the NSA, that allows attackers to spoof any x.509 certificate. This certificate type underpins most of the encryption mechanisms used today, among them HTTPS encryption and Windows binary files signing, used for Secure Boot and other cryptographic security mechanisms. This vulnerability impacts Windows Server 2016 and Windows Server 2019 along with all supported Windows 10 machines.

Unlike the majority of cryptographic vulnerabilities, this one is simpler to exploit. We expect that by the end of the week, public demonstrations breaking HTTPS and code signing will be released. Security researchers are already working on proof of concepts demonstrating spoofed TLS certificates, allowing them Man-in-the-Middle communication.

The vulnerability itself is not simple to find, as evidenced by the fact that many world class cryptography engineers missed it during the more than 5 years it existed. For readers interested in more details, at the end of this post is a mathematical explanation.

In essence, if attackers can provide an arbitrary public key and have the defender confuse it for standard public key, they can easily spoof any cryptographic signature by using an arbitrary matching private key. At that point, the attackers win. But how can they do that?

In Elliptic-curve cryptography, public keys are composed of multiple parameters. In case of this vulnerability, an attacker could pick very specific circumstances that cause Windows to not check all these parameters properly. A sophisticated attacker can pick parameters that are nearly identical to a standard parameters without Windows noticing. This is equivalent to spoofing an arbitrary public key certificate and allows the attackers to forge any signature.

In their released patch, Microsoft added an alert to the Windows Event Log in case of an attack using spoofed certificates. Therefore, in patched machines, it is easy to detect exploitation attempts using the following PowerShell command

Get-WinEvent -LogName application | where {$_.Id -eq 1}

Alternatively, networks that collect all public key certificates that enter their network can automate certificate examinations. The NSA published an advisory, providing possible detection steps to check certificates if the organization collects TLS certificates at the entrance to the network. Organizations that perform TLS inspection without using Microsoft software can easily collect these certificates, however performing TLS inspection is not always recommended.

Software utilities such as OpenSSL and Windows certutil can be used to perform in-depth analysis of certificates to check for malicious properties.

Certutil can be used to examine an X509 certificate by running the following command:

certutil -asn

OpenSSL can be used to examine an X509 certificate by running the following command:

openssl asn1parse -inform DER -in  -i -dump

or

openssl x509 -inform DER -in  -text

The commands parse and display the ASN.1 objects within a specified DER encoded certificate file. Review the results for elliptic curve objects with suspicious properties.
Certificates with named elliptic curves, manifested by explicit curve OID values, can be ruled benign. For example, the curve OID value for standard curve nistP384 is 1.3.132.0.34. Certificates with explicitly-defined parameters (e.g., prime, a, b, base, order, and cofactor) which fully-match those of a standard curve can similarly be ruled benign.

Certutil can be used to list registered elliptic curves and view their parameters by running the following commands:

certutil -displayEccCurve

OpenSSL can be used to view standard curves enabled/compiled into OpenSSL by running the following commands:

openssl ecparam -list_curves
openssl ecparam -name  -param_enc explicit -text

Certificates containing explicitly-defined elliptic curve parameters which only partially match a standard curve are suspicious, especially if they include the public key for a trusted certificate, and may represent bona fide exploitation attempts.


RDP Vulnerabilities


Besides the crypto API spoofing vulnerabilities, two other critical systems had vulnerabilities disclosed and patched yesterday.

The first is the Windows Remote Desktop Gateway service, used by many enterprises to proxy remote desktop (RDP) connections into their organizations. The vulnerabilities (CVE-2020-0609 and CVE-2020-0610) allow attackers to run code on the proxy server without requiring any authentication.

Because Remote Desktop Gateway servers are typically internet exposed, the impact of this vulnerability is immense. All supported Windows Server versions (2012, 2012 R2, 2016 and 2019) are affected and this vulnerability is likely wormable. Malicious actors can simply scan the internet, searching for vulnerable gateways and with a single easy-to-exploit attack find their way into a data center.

The second system is the Windows Remote Desktop Client. This vulnerability(CVE-2020-0611) allows an attacker who can impersonate a valid Remote Desktop Server to take over the connecting client. Impersonating a valid remote desktop server in itself is not simple, but combined with the cryptographic vulnerability also published, this attack is made easier.


Closing Thoughts


It is crucial to note that this month was the last month where Microsoft provided patches for Windows Server 2008 and Server 2008 R2 and that these operating systems are now End of Life according to Microsoft and no more security updates will be released to the public. We have previously described possible mitigations for this circumstance but running these operating systems is not advised.

In this post, we only covered the vulnerabilities we consider relevant to data centers. Microsoft patched a total of 8 critical vulnerabilities and 41 other vulnerabilities, so as usual, we urge organizations to patch their systems as soon as possible. In addition, this is a good time to remember that Citrix has still not provided patches for Application Delivery Controller (ADC) and Citrix Gateway and these data center appliances are typically exposed to the internet and easy to attack.


Mathematical Speculation


What follows is Guardicore Labs speculation on the exact vulnerability. Our speculation is based on the NSA’s advisory and other cryptographers guesses on what is the exact flaw.
In ECC, an elliptic curve comprises 4 parameters: (a, b, p, g).
a, b, and p are three numbers which define the curve itself.
g is by itself two numbers (“g.x” and “g.y”), which you can think of as coordinates of a point in the plane which define a base point on the curve.
See the following diagram:


An elliptical curve

The private key, x, is another (secret) number. If you have the number x, you can use it to get from the base point g to another point, q. The point q is the public key.
The calculation of q from g and x is done using a mathematical method known as elliptic curve scalar multiplication.


Elliptical curve cryptography

If you know x, then it’s very easy to get from g to q. It’s also very easy to go backwards from q to g. However, if you don’t know what x is, it’s extremely difficult to find out what it was, even if you know where g and q are. This is what makes it a good secret.

In the vulnerability before us, a curve is given explicitly (with all parameters), and it is compared to a well-known curve which Windows supports natively. However, only the parameters a, b, p (defining the curve itself) are checked. The parameter g (defining the base point) is not checked, and an attacker can freely change it. But how can an attacker use this to build a private key which is compatible with (unchangeable) public key q?
All an attacker has to do is create their own secret key, x’, and then go “backwards” from q to wherever the path takes us:


An elliptical curve attack with an attacker

(The direction of the arrow indicates the “forward” direction of the calculation, but the attacker would compute it “backward” to get from q “back” to g’, using their chosen x’ as the secret key.)

The new curve, with the same parameters a, b, p but a different base point g’, would then be able to use a different secret key x’ with the same public key q.