Last 24 hours have been extremely interesting – this month’s patch Tuesday by Microsoft brought to us 2 very interesting (and critical) vulnerabilities. The first one, the “BlueKeep” like remote code execution vulnerability in Remote Desktop Gateway (CVE-2020-0609, CVE-2020-0610) has been kind of ignored, although it’s really critical … so I guess I’ll continue doing that in this diary (but rest assured that we are keeping an eye on the RDG vulnerability as well). This diary is about the vulnerability in Windows CryptoAPI, CVE-2020-0601, that everyone has been talking about; we decided to sum up known and tested information so far. The vulnerability exists in the Windows CryptoAPI component (Crypt32.dll), specifically in the part that is used to validate Elliptic Curve Cryptography (ECC) certificates. Due to a serious bug in code, ECC certificates are not properly verified – there have been several posts about why this fails (i.e. the one here), but the bottom line is that it is trivial to use an existing Certificate Authority (that must be using ECC) to create a spoofed certificate. It took only hours for first proof of concept certificates to be released, and we can confirm now that it is trivial to create such certificates. So, what can an attacker do with this? While certificates are used for all sorts of things, the two most common ways of abusing the vulnerability are probably through spoofing web certificates and digital signatures for binaries on Windows. Let’s address those. Spoofing web certificates In order to spoof a certificate, an attacker will typically want to pick an ECC CA that comes bundled with Windows. There are several such certificates, and in examples below I used Microsoft ECC Product Root Certificate Authority 2018 which comes installed by default (and for bonus, it’s a Microsoft’s CA). Due to vulnerability being in the way ECC certificates are verified, in the process of creating the spoofed certificate, the attacker takes the public key from the CA and creates a fake CA, where the public key will be the same, but it will use different generator (G) for the curve. Normally, this should be rejected due to the generator not being the original one, but Crypto32.dll fails to do that and, as long as the public key matches the original CA will accept the certificate. We have generated several such certificates and put a test site that you can use to see if you are vulnerable. The test site is available at https://curveballtest.com/index.html - once you open it, there is a special style sheet loaded from a site using such a fake certificate. If it renders, you will see a message saying that you are vulnerable, as below: Now, this will by default work only in Internet Explorer and Edge on Windows. Mozilla Firefox does not use Crypt32.dll to verify certificates and does not have the same bug. Google Chrome does use Crypt32.dll, however it tries to verify every certificate in Certificate Transparency log, which is another safety feature in Chrome. That being said, Google introduced that feature for all certificates issued after May 1, 2018. Finally, the vulnerability exists only on Windows 10 and Windows Server 2016 and 2019 – other Windows OSes do not support ECC certificates so they are safe. Once you visit such a site with a vulnerable OS (and IE or Edge), the certificate will be correctly validated, although certificate details in IE will be weird, as you can see below:
Edge is actually even worse – there isn’t a single sign of a certificate being spoofed: Ok, so it is bad, but how bad is it? Remember that while an attacker can spoof a certificate, he/she still has to get the victim to visit the web site. In other words, if we spoof certificate for isc.sans.edu, we must get the victim to connect to the IP address of a malicious server (with the spoofed certificate). This means that a prerequisite for the attack is some kind of Man-in-the-Middle between the legitimate site and the victim, or some kind of DNS poisoning which will make the victim visit the attacker’s server. I would say that this decreases a risk a bit – sure, an attacker can use social engineering or phishing techniques, but in such an attack the final domain will be fake anyway (i.e. isc.sans.edu.malicious.com). Spoofing digital signatures for binaries Besides web sites, binaries are nowadays commonly signed. Actually, a lot of endpoint security software will skip verifying correctly signed binaries and will blindly trust them. This is what makes this vulnerability more critical: if it’s possible for an attacker to spoof a certificate for a binary pretending to be Microsoft for example, then it might be possible to evade certain defenses. We have successfully created such binaries and tested on both pre and post-patch machines and the results here were a bit more worrying. On a non-patched machine, the digital signature shows as perfectly fine, as you can see in figures below:
Of course, it will run without any issues, as expected. However, the bad binary will still be executed on a patched machine, silently, without any warning except the event log above. This is a serious issue since the patch will not prevent such a maliciously signed binary from working, it will just create a log. Endpoint protection software should, hopefully, in this case correctly detect and block such an attempt. Finally, if you just want to test for detection and create a fake Event Log as the one above, our handler Didier Stevens created a simple VBA program that will generate such an event. I liked the idea so I recreated it in Powershell (hey, it's Posh), you can find equivalent PSH code below:
If you want to test with a real binary, Didier created a simple program that does nothing really except showing a window which we then signed with a fake certificate. To sum it up: it’s not the end of the world, but the vulnerability is serious: you should patch affected systems as soon as possible. Keep in mind that any other software that uses Crypt32.dll to verify ECC certificates is vulnerable, so it’s best that patching is not delayed. We will be updating the diary as we get more information – of course, if you have something to share with us, let us know! Small update: Just a small update regarding digital signatures for binaries. First, the binary we put last night was not signed - we have put a signed one up now (with a fake signature), it is available at the following URL: https://curveballtest.com/SANSISC_signed_fake.exe Additionally, the fact that Windows will not prevent the binary from being executed is correct (thanks Stefan for the comment). The only sign of something going wrong will be when elevated, when the UAC prompt is shown. On a vulnerable system, the following prompt is shown: While a patched system will display the UAC prompt stating an unknown publisher. I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Pen Test Hackfest Europe 2022 - Berlin |
Bojan 403 Posts ISC Handler Jan 17th 2020 |
Thread locked Subscribe |
Jan 17th 2020 2 years ago |
Excellent article. Would X.509 Certificate Based Authentication also be vulnerable?
|
Anonymous |
Quote |
Jan 17th 2020 2 years ago |
Thanks for this article. This is scary.
https://curveballtest.com/SANSISC_signed.exe does not seem to be signed at all. I checked with Explorer/Properties, signtool.exe and PowerShell Get-AuthenticodeSignature, all report "no signature". To make sure the signature has not been tampered with through some antimalware magic, I also downloaded on a Linux system and compared hash codes (it's 6FDEEDBA9E319D9B83ECD0C9124CC7C9DD9B18670B1C13047050EDEF8EFF250B) You write: However, the bad binary will still be executed on a patched machine, silently, without any warning except the event log above. Why would you assume that it won't execute? Windows only checks signatures in specific situations, e.g. SmartScreen (Explorer launch if MotW is present) or UAC (when elevating permissions). I'm actually surprised that MS chose to do additional checks that result in an EventLog entry, there's a performance penalty after all. How did you launch the sample? Did it have the MotW? See https://about.signpath.io/code-signing/windows-platform/#when-are-signatures-verified Best, Stefan |
@stefan_wenig 2 Posts |
Quote |
Jan 17th 2020 2 years ago |
Quoting Anonymous:Excellent article. Would X.509 Certificate Based Authentication also be vulnerable? Thank you! Yes - depending on how it is used, certificate based authentication is vulnerable as well. |
Bojan 403 Posts ISC Handler |
Quote |
Jan 17th 2020 2 years ago |
Quoting @stefan_wenig:Thanks for this article. This is scary. Hi Stefan, Thank you for the comments. We have put an incorrect binary on the web and you are right that it's not signed. We'll fix that soon (read: as soon as Johannes wakes up ![]() Regarding starting binary, you are right about checking signatures. For some reason I expected that it will at least warn about the incorrect signature, and that appears when elevating permissions. I will update the diary soon with that data to clear this up. Thank you for the comment, Bojan |
Bojan 403 Posts ISC Handler |
Quote |
Jan 17th 2020 2 years ago |
Another thing to think about is firewalls that package an encrypt traffic. Once the traffic is encrypted the company becomes the root CA. If this is the case then it does not seem to matter if the cert is spoofed or not. All sites would be inherently trusted. Any thoughts?
|
Anonymous |
Quote |
Jan 17th 2020 2 years ago |
TLS intercepting firewalls have to inspect the certificate of the site. But you are right, it is a somewhat common misconfiguration. For CVE-2020-0601, a correctly configured TLS intercepting proxy will actually protect users. It will not accept the fake certificate and not connect to the server.
|
Johannes 4513 Posts ISC Handler |
Quote |
Jan 17th 2020 2 years ago |
Hey Bojan,
Can you confirm that on the unpatched machine if the spoofed binary ran with elevated privileges (since there's no warning of anything)? You mention on the patched machine that the UAC prompt shows, indicating that the binary is attempting to run with administrative privileges. I'd assume it would be ran as standard user, being this is a trust vuln and not a EOP vuln, but just wondering what you saw there? Thanks, Tom |
Anonymous |
Quote |
Jan 17th 2020 2 years ago |
The new binary (sha2 A701650AF027956BFCC27001C0A7ED3E5011AC03471426B208D4A67ECDB43D54) also reports as "no signature", with the exception of PowerShell Get-AuthenticodeSignature which now reports UnknownError. Unpatched Win10 x64 Version 1903 build 10.0.18362.535.
|
@stefan_wenig 2 Posts |
Quote |
Jan 17th 2020 2 years ago |
Very useful informations! I was talking about that type of infection-spoofing at windows platforms ages ago. Unfortunately i was treated as crazy and faced the wrath of local authorities!
At least i know now there is people out there who do some serious work! Thank you all, George (former =MM= now just a crazy one!) |
Anonymous |
Quote |
Jan 18th 2020 2 years ago |
Quoting Anonymous:Hey Bojan, Hi Tom, Sorry for a delayed reply. On an unpatched machine, if executed with elevated privileges the UAC prompt shows whatever has been written into the certificate used to signed the binary (so it's up to the attacker to trick the victim). In our demo I actually put Microsoft so it looks very legitimate. On a patched machine, the UAC prompt shows unknown signature. Hope this helps, Bojan |
Bojan 403 Posts ISC Handler |
Quote |
Jan 19th 2020 2 years ago |
Thanks for the reply Bojan. No worries on the delayed reply. What I was trying to understand (in relation to your spoof binary tests) is what could an attacker do if this "malicious" binary were executed on a standard user account in the Windows OS and/or domain. If the user were a standard Windows user (no admin rights), then the malicious binary would have to leverage code exploiting another vulnerability on that system to gain elevated privileges or establish persistence, correct? You mention that "it might be possible to evade certain defenses". Can you elaborate a little more on what that may be and what measures can be taken to minimize damage/impact if this were actually exploited and executed? I'm just talking about the malicious binary aspect here only and not MitM.
|
Anonymous |
Quote |
Jan 20th 2020 2 years ago |
Hi Bojan!
Any indications that CVE-2020-0601 has been used in the wild before 14.jan ? |
Anonymous |
Quote |
Jan 21st 2020 2 years ago |
Quoting Anonymous:Thanks for the reply Bojan. No worries on the delayed reply. What I was trying to understand (in relation to your spoof binary tests) is what could an attacker do if this "malicious" binary were executed on a standard user account in the Windows OS and/or domain. If the user were a standard Windows user (no admin rights), then the malicious binary would have to leverage code exploiting another vulnerability on that system to gain elevated privileges or establish persistence, correct? You mention that "it might be possible to evade certain defenses". Can you elaborate a little more on what that may be and what measures can be taken to minimize damage/impact if this were actually exploited and executed? I'm just talking about the malicious binary aspect here only and not MitM. Exactly, if a user is a standard user then this does not help an attacker -- there still has to be a way to escalate privileges and this will not help. Regarding evading - I was referring to a possibility of evading anti-virus or endpoint protection defenses in case such an application was only skipping binaries signed by Microsoft (for example). Even if that worked, the majority of reputable AV vendors already added signatures for detection of such fake certificates. Finally - the best approach is to install the patch. Running an up-to-date AV helps as well. |
Bojan 403 Posts ISC Handler |
Quote |
Jan 22nd 2020 2 years ago |
Quoting Anonymous:Hi Bojan! As far as we've seen there are no indications that is has been used in the wild before the patch was released. We're keeping an eye on this, of course, and will post a diary if something changes. |
Bojan 403 Posts ISC Handler |
Quote |
Jan 22nd 2020 2 years ago |
Sign Up for Free or Log In to start participating in the conversation!