The NSA recently disclosed a pretty severe finding in Windows. The vulnerability itself was in the DLL crypt32. This was publicly disclosed as CVE-2020-0601, and has gone by some names such as "Let's Decrypt" (a phrase termed by Mike Thompson) and "CurveBall". This vulnerability is a result of ECC certificates not being validated correctly. Without going into detail (there are other posts which do a great deal explaining the technical details of the flaw), this flaw can be exploited to generate rogue certificates which any application using this DLL to perform certificate validation, would then trust this rogue certificate. From a security perspective, certificate validation is vital to ensure that one is either talking to the intended recipient, or handling data from the intended recipient. An attacker could exploit this flaw in several ways:
- To be able to perform Man in The Middle (MiTM) attacks.
- To be able to stand up rogue services, pretending to be legitimate services.
- To be able to sign packages/software pretending to be legitimate software.
- To Be able to sign other data, such as email, pretending to be someone else.
The purpose of this post is to attempt to show how an attacker could use this flaw to perform both a MiTM attack, as well as stand-up a rogue service. For both cases I will be using the PoC provided by ollypwn to generate the certificates required to be able to pull off these "attacks". This post is nothing earth shattering, and makes use of already well known things. The purpose of this post is to hopefully help show the weakness in some context which can help in aiding to explain the issue and the severity as it. It was also a means for me to put the vulnerability to the test and see how difficult it was to actually exploit in a feasible manner.
Rogue Service
The first illustration will be a rogue service. For this I will setup a simple spoofed login page for Facebook. I purposely made it a VERY bad and horrible spoof, just to help emphasize the point that this is not a legitimate page, as well as not being the point of this example. Attackers would typically take great effort to make as indistinguishable from the real login page as possible. I'm merely trying to show that IE and Edge on vulnerable systems would show the certificate being valid for an obviously illegitimate site.
Now in order for an attacker to be able successfully perform this attacker they would either need to control the victim's DNS infrastructure, or perform attacks such as subdomain takeover. Another approach an attacker could use is to compromise the victim via a rogue or compromised wireless AP or even a router (such as a vulnerable home router). In this example, the attacker has managed to tamper with the DNS infrastructure of the victim, changing the DNS records for www.facebook.com and login.facebook.com to point to their malicious server, which is serving the horrendous spoofed login page.
With this in place, an attacker could use this spoofed login page to do things such as steal user credentials for Facebook, or perhaps inject BeEF hooks, or something similar. As shown in the screenshot below, the certificate is trusted by the browser (I most certainly do not have the ability to create valid certificates for facebook.com domain), although it is most certainly not a valid certificate signed by a valid CA.
Validating the hostname resolutions on the system, confirms that the "attacker" (me in this case) has modified which system www.facebook.com and login.facebook.com resolve to (pointing instead to the system which the attacker controls):
After applying the patch, we get an appropriate error for the invalid certificate:
And using other browsers such as the new Edge:
Man in The Middle
For the other illustration, I attempted to perform a Man in The Middle attack, illustrating how IE on the vulnerable system will trust the "invalid" certificate.
The first approach is to gain Man in The Middle. There are several ways in which an attacker could accomplish this such as:
- ARP Spoofing (if on the same local network)
- Rogue Wireless Hotspot
- Compromised router
- DNS poisoning
For this example, I did the example on my local network so I performed an ARP Spoofing attack. This allowed my attack system to receive all requests and responses of the target system (the vulnerable Windows 10 host). The next step was to setup request and response to hit my local instance of Burp Suite to make it easier to view and intercept HTTP requests and responses, this was done via iptables. Finally the last thing was to fire up Burp Suite itself. With this in place, the attacker is now in a position to view as well as tamper with requests and responses to and from their victim. However I didn't get the results I was expecting:
I suspect that either Burp Suite is doing something with the certificate, or that when I converted the certificate from X509 format into PKCS12 (so that Burp Suite can use it), that broke it. Either way I will attempt to try do further digging into this when I have some time. If anyone has any idea, please let me know. It should have worked.
Update 19 January 2020
I managed to get MiTM working. In order to successfully exploit this attack, the attacker needs to provide the full certificate chain (the rogue server certificate as well as the rogue CA). Burp Suite does not supply this chain. So I threw a hack together where I fronted Burp Suite with an Apache HTTPD server. So the traffic looks like: Client -> Malicious Apache HTTPD Server (containing the full certificate chain) -> Burp Suite -> Target Site.
I did notice some errors with the page itself, likely caused by this setup, which unfortunately prevents the user from submitting their email or phone number to login. I'm pretty sure with some effort and tweaks these errors can be resolved. However I did illustrate with this how an attacker is still able to perform a MiTM attack an modify the content on the page (they could inject a BeEF hook for example).
This shows the original login page, as well as the rogue certificate details, showing it is trusted by IE.
This shows the original response from Google:
This show the attacker modifying the response from Google:
The end result showing the modified login page:
Conclusion
As can be seen, this vulnerability does present a real risk (i.e. it's not just hypothetical). The risk it poses will likely to vary depending on the organization and individual. However my advice is patch, and reduce the risk as much as possible (patches were released on Tuesday 14 January 2020).
