-
Titre
Microsoft CVE-2020-0601 Verification of Signatures using Elliptic Curve Cryptography -
Description
Microsoft recently released an update for Windows to correct a defect in the verification of signatures utilizing elliptic curve cryptography. -
Cause
A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. -
Résolution
Given that this vulnerability has been categorized by Microsoft as important only and the attack vectors describe above have minimal risk to Safeguard, One Identity will be incorporating the OS level patches into the next major version of Safeguard and will not be issuing a patch for any other Safeguard versions at this time.
The CVE-2020-0601 vulnerability can be exploited utilizing two methods.
The first method would involve codesigning vulnerabilities, whereby signatures can be spoofed to allow Windows to install malicious software that provides a threat actor control of the system. SPP is not vulnerable to this form of attack. SPP only installs software from patches provided by One Identity. SPP uses RSA public key cryptography for codesigning. An attacker cannot gain control of SPP via the CVE-2020-0601 vulnerability.
The second method involves a man-in-the-middle attack, where server identity is verified via TLS using elliptic curve cryptography. This attack method could only be used against SPP when SPP is configured to communicate with other applications, e.g. ticketing systems, Starling 2FA, and managed assets. Using this vulnerability, SPP could be configured to communicate with a malicious server. For such an attack to be successful, the threat actor must also compromise the corporate network by spoofing DNS or corrupting routing tables. Man-in-the-middle attacks are extremely difficult to perform in practice. If the threat actor were successful in the configuration of the attack, they would also have to properly imitate the target host to avoid detection. Only a minimal amount of data can be exfiltrated using this method. Most installations of SPP utilize security mechanisms other than TLS to manage the majority of their assets, e.g. SSH, SASL, Kerberos, etc. Connections to those managed assets (Active Directory, Windows, Linux, Unix, and many others) are unaffected by this vulnerability.