Critical Windows Vuln Used To Rickroll The NSA And Github
Less than a day after Microsoft disclosed one of the most critical Windows vulnerabilities ever, a security researcher has demonstrated how attackers can exploit it to cryptographically impersonate any website or server on the Internet.
Researcher Saleem Rashid on Wednesday tweeted images of the video “Never Gonna Give You Up,” by 1980s heart-throb Rick Astley, playing on Github.com and NSA.gov. The digital sleight of hand is known as Rickrolling and is often used as a humorous and benign way to demonstrate serious security flaws. In this case, Rashid’s exploit causes both the Edge and Chrome browsers to spoof the HTTPS verified websites of Github and the National Security Agency. Brave and other Chrome derivatives, as well as Internet Explorer, are also likely to fall to the same trick. (There’s no indication Firefox is affected.)
Rashid’s simulated attack exploits CVE-2020-0601, the critical vulnerability that Microsoft patched on Tuesday after receiving a private tipoff from the NSA. As Ars reported, the flaw can completely break certificate validation for websites, software updates, VPNs, and other security-critical computer uses. It affects Windows 10 systems, including server versions Windows Server 2016 and Windows Server 2019. Other versions of Windows are unaffected.
Rashid told me his exploit uses about 100 lines of code but that he could compress it down to 10 lines if he wanted to remove a “few useful tricks” his attack has. While there are constraints and several potentially difficult requirements in getting the exploit to work in real-world, adversarial conditions (more about that later), Wednesday’s proof-of-concept attack demonstrates why the NSA assesses the vulnerability as “severe” and said sophisticated hackers could understand how to exploit it “quickly.”
“Fairly terrifying”
Other researchers shared the NSA’s sense of urgency.
“What Saleem just demonstrated is: with [a short] script you can generate a cert for any website, and it’s fully trusted on IE and Edge with just the default settings for Windows,” Kenn White, a researcher and security principal at MongoDB, said. “That’s fairly horrifying. It affects VPN gateways, VoIP, basically anything that uses network communications.” (I spoke with White before Rashid had demonstrated the attack against Chrome.)
The flaw involves the way the new versions of Windows check the validity of certificates that use elliptic-curve cryptography. While the vulnerable Windows versions check three ECC parameters, they fail to verify a fourth, crucial one, which is known as a base point generator and is often represented in algorithms as ‘G.’ This failure is a result of Microsoft’s implementation of ECC rather than any flaw or weakness in the ECC algorithms themselves.
Attackers can exploit the flaw by extracting the public key of a root certificate that ships by default in Windows. These certificates are described as root because they belong to big certificate authorities that either issue their own TLS certificates or validate intermediate certificate authorities that sell certificates on the root CA’s behalf. Any root certificate will work, as long as it’s signed with an ECC algorithm. Rashid’s attack started with a root certificate from Sectigo, the Internet’s biggest CA, which previously used the name Comodo. The researcher later modified his attack to use a GlobalSign root certificate. His code made the switch automatic.
The attacker examines the specific ECC algorithm used to generate the root-certificate public key and proceeds to craft a private key that copies all of the certificate parameters for that algorithm except for the point generator. Because vulnerable Windows versions fail to check that parameter, they accept the private key as valid. With that, the attacker has spoofed a Windows-trusted root certificate that can be used to mint any individual certificate used for authentication of websites, software, and other sensitive properties.
The behavior is tantamount to a law enforcement officer who checks someone’s ID to make sure it properly describes the person’s height, address, birthday, and face but fails to notice that the weight is listed as 250 pounds when the person clearly weighs less than half that.
“It’s such a strange bug, because it’s like they’re only halfway checking something that is at the root of the entire trust system,” White said. “It’s a core part of the whole chain of trust.”
For more detailed technical explanations of the bug, see posts here and here and the Twitter thread here.
Update 1/16/2020, 1:20 PM California time: Researches from Kudelski Security have also exploited the bug and provided a fair amount of detail, including attack code, others can use to do the same thing. A second publicly posted exploit is here. Security firm Trail of Bits, meanwhile published this excellent explainer and site that detects if visitors’ system remain vulnerable.
The caveats
As noted earlier, there are several requirements and constraints that significantly raise the bar for Rashid’s attack to work in real-world uses by an adversary. The first is that it most likely requires an active man-in-the-middle attack. These types of attacks, which modify data as it passes through networks, may be difficult to carry out. An alternative to an active MitM is to convince a target to click on a fake URL. This method is much easier, but it also requires some targeting. (It wouldn’t apply to attacks against websites or other servers that require a certificate from the connecting client.)
The exploit also requires that the target has recently visited a site with a transport layer security certificate that’s chained to an ECC-signed root certificate. That’s because the root certificate must already be cached by the targeted system. In the event a targeted system doesn’t have the root certificate cached, Rashid said, an attacker could still pull off an exploit by adding JavaScript that accesses a site chained to the root certificate.
Another constraint: Chrome uses a mechanism known as certificate pinning for google.com and a variety of other sensitive websites. Pinning requires that the certificate authenticating a website contain a specific cryptographic hash, even if the certificate offered is otherwise valid. This measure would prevent exploits from working when they spoofed protected sites.
While installing Tuesday’s patch by Microsoft is by far the only reasonable way to prevent attacks, a Google representative said Chrome developers have already distributed a fix in a beta version and will fold the fix into stable versions soon. A word of caution: even with this fix, users of vulnerable Windows versions will still face considerable risk from other attack scenarios.
A matter of time
Despite the requirements and limitations, the vulnerability is serious. As NSA officials put it in the above-linked advisory:
The vulnerability places Windows endpoints at risk to a broad range of exploitation vectors. NSA assesses the vulnerability to be severe and that sophisticated cyber actors will understand the underlying flaw very quickly and, if exploited, would render the previously mentioned platforms as fundamentally vulnerable. The consequences of not patching the vulnerability are severe and widespread. Remote exploitation tools will likely be made quickly and widely available. Rapid adoption of the patch is the only known mitigation at this time and should be the primary focus for all network owners.
The vulnerability may not pose as extreme a threat as those caused by the Heartbleed flaw in 2014 that allowed attackers to steal private keys, passwords, and other highly sensitive data from hundreds of thousands of vulnerable sites. But because of the breadth of security measures foiled by the Microsoft vulnerability, it’s worse even than Apple’s critical goto fail flaw, which prevented iOS and macOS systems from detecting invalid TLS certificates served by websites. That makes CVE-2020-0601 one of the most severe vulnerabilities in recent memory.
Windows’ automatic update mechanism is likely to have patched vulnerable systems already. For anyone else, fixes for various vulnerable versions are available here. Readers who haven’t patched yet should do so immediately.
Post updated to correct description of certificate pinning and discussion of man-in-the-middle attacks.
READ MORE HERE