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.
Hmmm .. and we're faking certificates, aren't we? So, how about we issue a certificate before that date, let's say 24.3.2018. And voila - it works in Google Chrome out of box as well!
The maximum validity for a certificate that Chrome allows is about 27 months - enough for us
Google was fast addressing this - with the latest release of Chrome, released today (Thursday, 16/1/2020) they added additional checks for Chrome so make sure you update Chrome as well!

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.
With the patch, besides fixing certificate validation, Microsoft also added a new event to Windows Event Log, that will warn when a binary with a fake certificate is executed. This is what the signature and the event log looks like on a patched machine:

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.

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.
You can download it from here: https://curveballtest.com/SANSISC_signed.exe - once you start it, there should be an event created in Windows Event log (Application). Additionally, on a patched machine, when you start it as administrator, you should see a message about an incorrect signature.

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.

Although less than two days have gone by since the latest release of MSFT patches, I find that it would actually be hard to add anything interesting to them that hasn’t been discussed before, as the most important vulnerabilities (couple of RCEs and an interesting vulnerability in CryptoAPI) seemed to be all anyone talked about for the last 24 hours. If you didn’t hear anything about it, I suggest you take a look at the ISC coverage of the CryptoAPI vulnerability[1] as well as the Patch Tuesday overview[2]. But for the rest of us, I thought today might be a good day to take a short break from this topic and take a look at what the last year brought us instead.

Since 2019 has passed us by, I thought it might be interesting to take a look at the malicious files, which it left in my e-mail quarantine. Specifically, I thought it might be worthwhile to try to determine which of the malicious files was the smallest and which the largest as these might provide us with good example of how two extreme cases of malware might have looked in 2019. The assumption was that one would probably be very simple and the other one very complex.

I started out with a little over 650 files, mostly of the usual malspam types. After unpacking all of the archives (by the way, let me know if anyone still uses the ACE format), IMGs, ISOs, etc., I was left with plenty of Office documents, PDFs, different varieties of scripts, and – of course – executables. Most of these were left with the default EXE extension, however there were couple SCRs and COMs in the mix as well. There were plenty of other file types as well – for example a couple of LNKs, one of which tried to look like a RTF file and the other like a PNG file.

The latter file turned out to be the smallest of the bunch. It was originally packed within an archive (777 bytes long ZIP file titled PO.pdf.zip), which was attached to a phishing e-mail from the end of October. At 2,296 bytes, it was no larger than any normal LNK. Correspondingly, it wasn’t overly complex – the target of the shortcut was set to the following string.

As we may see, the LNK was just a simple downloader for a HTA file, which it was supposed to execute. So far, the assumption of positive correlation between size and complexity of the malware attachments held true.

Where things got interesting was the hunt for the largest file. Although there are exceptions, malicious files are only seldom significantly larger than 2 or 3 megabytes. Considering this, I was quite surprised when I sorted the files and found a 74 MB executable (an EXE with .COM extension) at the top.

Since no file among the original attachments was nearly as large as this one, there was only one possible explanation of where it came from. The file had to have been part of one of the archives and it had to have been packed with an extremely good compression ratio enabled by its internal structure. My guess was that the authors of the file included lots of unused uniform space (most likely in the form of null bytes) in the executable in order to make it extremely large and very compressable at the same time. This turned out to be the case as the archive (ZIP with a .R20 extension), in which the file was originally stored, was only 442 kB large.

After taking a closer look at the executable, the theory about null bytes was proven as well. In fact, as the following histogram of byte values in the file demonstrates, almost 99% of the file was nothing but one large segment filled with null bytes intended only to make the file much larger than it needed to be.

I assume that the size of the executable was increased in this way in order to enable it to bypass anti-malware scans. It is customary to configure anti-malware software with a maximum size of files, which it should scan. This is done in order to minimize impact of scans on computing resources and since most malicious files aren’t too large, the fact that scans are only done on smaller files doesn’t usually present much of an issue. In the case of our 74 MB executable, it however means that its size alone might potentially shield it from being scanned and detected on some systems.

This technique is quite imaginative, because since it is very easy to implement, it is a very “cheap” way for malware authors to shield their creation from at least some methods of detection. Although I’m sure the technique has been used before (I found 3 other files which used it among the samples I had available), it is definitely not common.

Due to its inflated size, the executable ended up not being as complex as I have hoped. After further analysis, it turned out that the file, which originally arrived in an e-mail at the beginning of February 2019, was otherwise a normal variant of the Pony/FareIT info stealer.

Although the original idea of showing a very simple and a very complex malware did not pan out, I believe that taking a look at the files wasn’t a total loss since our not-so-complex large file turned out to be interesting in its own right… Additionally, when I saw all of the executables placed in a single folder, I thought it might be a good opportunity to demonstrate one more interesting concept.

It is quite usual for malware authors to use similar naming schemes when it comes to filenames and variables and this may aid us in quickly finding links among different malicious files and campaigns. However, file names aren’t necessarily the only visual indicator we may use to determine links between different malicious files. In some cases, just looking at the icons of the executables may provide us with similar information, as some malicious actors can get quite attached to a single icon design or style. The following icons may serve as a good example since, although they are all different, the similarities are so notable that one can reasonably assume that they were created by the same author or were part of the same campaign. Which is true – all the executables were part of a malspam campaign active during February and March 2019.

While the similarity in icon designs isn’t always so striking, and it usually doesn’t provide us with a definitive link between files (it may only mean that the files were created use the same SW), it can sometimes be a useful indicator that multiple files are in some way related even though their names might not appear similar.