Root Causes 62: Windows CryptoAPI Spoofing Vulnerability Explained

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

January 22, 2020

On January 14 Microsoft announced a sweeping vulnerability that makes it possible to defeat the authentication of Elliptic Curve Cryptography (ECC) on Windows 10 and Windows Server systems, making it possible to create fake certificates on trusted roots that will fool these systems. Join our hosts and guest Nick France, CTO of SSL at Sectigo, as we explain this vulnerability, how it could be used in exploits, and what must be done to address it.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanSo, we are very lucky. We have a guest episode. I always love the guest’s episodes and we have a great guest. It's our CTO of SSL. Nick France is joining us. Hello, Nick.

Nick FranceHi, Tim. Hi, Jason. Nice to be here and thanks for having me for the first time.

Tim CallanYeah. Very excited to have you and we're here today to talk about the Windows Crypto API spoofing vulnerability that was revealed by Microsoft on January 14, 2020.

Maybe we should start from the top. What happened on January 14?

Nick FranceYeah. So, January the 14th is what's known as a patch Tuesday, which as hopefully most of your listeners will know is one of the days of the month when Microsoft released their updates to Windows and to their various software products and we got some word on social media that this release was particularly of interest due to a cryptographic floor and a vulnerability that happened and that the NSA was somehow involved as well, and then by Tuesday afternoon, the cybersecurity director of the NSA had a briefing to give some advance notice of the issue before the patch was released and it turns out this was a bug that the NSA had actually found themselves and reported to Microsoft as part of a new, you know, vulnerability discovery program that they had placed. So, we quickly found out by Tuesday afternoon that this was indeed a cryptographic vulnerability specifically related to the verification of ECC certificate.

Tim CallanYeah. So, this was a coordinated disclosure right. So, NSA found it, talked to Microsoft in private, they got the patches ready and then there was a single day when the disclosure went out to everybody and when it went out the patches were already available. This is, you know, under most circumstances considered to be a best practice for how to do it.

Nick FranceAbsolutely. Yes. And that was obviously released I think early morning, Pacific Time on the Tuesday and fairly quickly, there was a number of researchers out there we're able to dissect the patch and more technical information was published. And what it boiled down to was that some versions of Windows, it was actually Windows 10 and I believe Windows server 2016 and 2019 we're both vulnerable to this problem where ECC certificates were basically not verified properly by Windows.

Tim CallanAnd this is a lot of systems we're talking about. Like this is a very wide-ranging vulnerability that affects huge numbers of both corporate and endpoint systems and servers throughout the world. Right? Like this is a major, major, major, vulnerability.

Nick FranceOh, it was huge. Absolutely and I suppose part of the irony here was that that same day was that when Microsoft actually ended support for Windows 7 and so, they've done everything they can to get as many users as they can onto Windows 10. So, absolutely, the number of impacted machines here is incredibly high. And of course, the number of impacted systems due to this vulnerability is big as well because would it be in a cryptographic vulnerability, it's going to affect, you know, HTTPS and TLS connections, which is obviously very particularly interesting tools. It's going to affect signed files and signed emails. You know, and of slightly more danger, it's also going to affect, signed code. So, you know, software and applications that are traditionally signed with code signing certificates, they're also vulnerable which would allow potentially malicious code to have a fake signature and still run and not be blocked by the Windows operating system.

Tim CallanBasically, how this would work - - let's use the TLS scenario, right? Is if I could somehow, you know, be a man in the middle, get a man in the middle attack that I've made on there and pretend to be anybody I want with a signed cert on a trusted root.

Jason SorokoYeah. I’d even go further than that, Tim. Interestingly enough, there is a setting in Microsoft Office that says, please only allow me to operate office code such as, you know, VBA macros, that sort of thing, that have been signed by a legitimate signature the chains up to a CA. And I think a lot of people might not realize that there's probably a lot of corporate policy settings set around that that could therefore be bypassed with this particular flaw if you're not patched.

Nick FranceYes. So, obviously, it's a very dangerous vulnerability when you are in that position to do man in the middle and you can obviously present these spoofed certificates and effectively, as you said, Jason, fake any website or any secure website, certainly. It is important to remember in this particular scenario though this is reliant on the Windows libraries that are built into Windows and for doing this verification. So, there are some browsers and pieces of software that are impacted and there are some that aren't. So as an example, Mozilla Firefox, the browser, actually uses its own library for doing TLS and handling certificates and verification of certificates and so that, thankfully, isn't vulnerable to this particular issue. And one other thing to note that came out with a lot of the talk on social media as well is there were concerns, obviously, that Windows update would be impacted. Now for attackers, that's an incredibly juicy target because they would be able to intercept Windows update and potentially send malware in there as well, but it turns out that certainly for a few years now since one of the malwares that didn't affect Windows update - - I believe it was the Flame malware - - Microsoft have added an extra few layers of protection to Windows update. So, it doesn't just rely on a single, a TLS - - it's a bigger - - there's a lot more security there and thankfully Windows update wasn't impacted by this particular vulnerability.

Jason SorokoYeah. So, Nick, I'd love to get also a little bit more into the weeds around this failed validation of the ECC parameters itself. Some research has come out, especially with respect to some of the public proof of concepts that have shown us now exactly what the problem is. I'm sure in your notes you have some other commentary about that and I'd love to hear a little bit more.

Nick FranceYeah. Absolutely. We can dive into some of the more technical details there. So basically, we mentioned this is for ECC certificates or elliptic curve certificates - - that's elliptic curve, as I'm sure you and your listeners are aware is one of a small number of cryptographic algorithms that are in common use today. The other one being RSA, which obviously wasn't impacted by this vulnerability. But ECC relies on the cryptographic properties of what's called elliptic curves, which are curves based on, you know, algebraic functions, and what actually happens is with these curves, there are a number of parameters defined for curves and then the cryptographic operations are performed with the specific curves. There's a number of well-defined ones that are pretty much in common use through throughout Windows, Apple Ecosystem, Linux and everywhere else. A good example are the Suite B sets of curves that were originally provided by NIST, the industry standards group. There are a number of other curves as well that have specific names, but this particular vulnerability, what it actually did was within the certificates themselves it is possible to specify individual parameters for the curve that aren't necessarily verified in this case by Windows to be that of one of these specific named curves. Now it seems like a great idea to allow people to specify your own parameters and have that flexibility, but in the end, these things tend to result in flaws and exploits like we're seeing here. So, it was actually possible through specifying specific parameters for the curve within the certificate to essentially fake that you had a private key for a given public key for one of the many trusted CAs that exist within Windows. And as you mentioned, Jason, there are now a fairly widespread proof of concept tools that allow you with a couple of commands to generate these spoof certificates both for TLS connections but also for authentic code certificates in order to then fake sign pieces of software, which then run without warning on Windows. So, there's obviously a lot more, very, very technical details there. We can get into the specifics of the code parameters, the generators, but ultimately, it's the fact that Windows allowed the specification of these parameters beyond specific well-defined parameters and that led to them not correctly verifying the details and the certificate or that it was issued by a proper CA.

Jason SorokoNick, if I oversimplify this a little bit - - sometimes we do that on this podcast for fun. If I have your public key, right, which I'm able to extract from certificate perhaps, I am able to derive a fake, private key based on a different curve or parameter that immediately should a ring alarm bells to a proper validation system, say that's done in Linux and other operating systems but just happened to not be done in specific versions of crypto API. Is that a good over-simplification?

Nick FranceThat’s a perfect over-simplification, Jason. Yeah, absolutely. That's exactly what it is. It's this acceptance of non-standard parameters which are then correctly verified. So, absolutely. You're able to have a private key, which is valid for an existing public key, as you said, simply because this, this generator, this other curve parameter can be adjusted and isn't actually checked correctly.

Jason SorokoGut feel, Nick. Tell me if I'm wrong - - my gut feel says that that's a fairly dramatic blunder.

Nick FranceIt is. Yes. Um, again, looking for - - on social media at a number of kind of commentators and researchers, it often seems that when these kinds of things are introduced, they're often introduced with the desire to be flexible. So, there's some examples in terms of TLS itself, you know, there was the ability to specify no ciphers that were included in there. There was the oft discussed ability to have middle boxes in versions of TLS that can kind of downgrade various cryptographic levels and it's seen as flexibility, but as you suggested, Jason, it ends up resulting in flaws like this, which are presumably very hard to discover. I mean, the fact that the NSA discovered this and, you know, not some individual researcher often suggests that it might be a fairly difficult problem to find, maybe even an edge case that wouldn't have otherwise been discovered and so, absolutely, it's something that is a fairly catastrophic blunder, but seems to happen quite unfortunately, quite frequently when the goal is more flexibility. In cryptographic operations, there really should be a lot more rigidity to that in order that things don't deviate from well-known standards and parameters.

Jason SorokoSo, let's step back for a moment then, Nick, and recap it. In the sense of finger pointing, which is what a lot of people end up doing after these things. This really is a flaw in validation within a portion of Microsoft's operating system. It’s not a fault of cryptography. It's not a fault of the Certificate Authorities that are out there. This, this is just a flaw in a particular validation point within a singular operating system. I think it's it - - we can narrow it down to that, right?

Nick FranceYeah, absolutely. Absolutely and it's interesting, you mentioned it that way, Jason, cause I know we spoke briefly before this, um, one of the things that's happened before is these kinds of vulnerabilities crop up frequently and multiple parties have to be involved or to blame or have the take action. In this particular case, the only action that anybody is able to recommend and certainly the one that we've been recommending to our customers and anybody that we communicate with is to apply the patch because it is purely a fault of this software vulnerability, and that's the only fix. But if you look at other things that have happened historically, particularly those that have impacted those as a CA you look back at something like Heartbleed and how, how we had to make a large number of reissues and how the whole ecosystem was impacted both vendors and CAs and individual users.

Tim CallanThis is a very important point. Let's just drive it home, which is that this is not something that can be fixed on the server side. You cannot go and re-issue certificates and have this problem go away. You cannot go and change your server software and have this problem go away. This is a client-side bug and a client-side patch is the only solution.

Nick FranceAbsolutely and that is it. And that really is the overriding advice that we can give when we're discussing this with anybody is to go ahead and get those patches from Microsoft and get them installed as soon as possible.

Tim CallanRight and then likewise, along the same line, it doesn't even matter if you are using ECC with your certs because the false cert can use ECC and even if your certs are RSA that's irrelevant because your certs are not in the mix in any way.

Nick FranceNo, that’s a very, very good point, actually, Tim. One of my notes here as well is that it really doesn't make a difference. These certificates, whether it's ECC or RSA, they aren’t treated any differently, they aren't delineated, they aren't exposed to the customer in different ways or the end user in different ways. So, absolutely, you are not safe just because you don't use ECC you are only safe in this scenario once you have that patch installed.

Tim CallanAnd so, this is an important point because we get this question. People say, well, I'm on RSA this doesn't affect me, right? And we say, yeah, no, that's not how it works. It's somebody else using this vulnerability to pretend to be you with a cert that has nothing to do with you. So, I just want to make that crystal clear.

Jason SorokoIt's an important point. Scrutinizing what software that you're installing, especially if you have automated systems that do automated installs, you might even want to check your logs for what has been installed from the point of which the patch was released up until now at a minimum. It's just to keep inventory of what - - where there might be problems, but there's also been some other good advice. And, in fact, some of that good advice came from the NSA advisory, Nick. I know you and I both read it and they've even talked about using proxies, uh, Linux proxies in front of your Windows machines in the meantime, while you're in a patching process, which, which can make sense, uh, you know, uh, something that can help to scrutinize those certificates that could possibly have been spoofed. Part of the NSA's advisory was - - went pretty technical in the sense of, since we are looking at certificates that almost by definition would have mismatched ECC curve parameters, as you said, Nick scrutinizing that by hand is difficult and costly, but letting a system that does it automatically, such as a Linux proxy might be a way out of it. You know, I'm just trying to throw out other suggestions for what people might want to think about doing.

Nick FranceYeah. That’s an interesting point, Jay, and you're right they did include that in the bulletin that the NSA put out, which basically, I suppose that piece of advice boils down to, you know, if you have Windows systems exposed to the world then put them behind a system that perhaps isn't vulnerable to this, put them behind like a, you know, a Linux-based proxy as they suggested such that the certificates will actually be locked there or they will at least be logged and noted that because as you said they aren't vulnerable in these other kinds of systems, but I think the other piece of advice you mentioned in terms of getting these updates out - - it's primarily, it’s the point we said right at the start, which is, this was patch Tuesday. Microsoft do this - - they have these patch Tuesdays specifically scheduled for the second Tuesday of the month in order to make it easier for enterprises who have, you know, thousands to hundreds of thousands of machines to install upon. You know, it's easy for, you know, myself as a home user to install it on a Tuesday and reboot and carry on the next day. When you have a fleet of thousands of machines, you know, you need to prepare, you need to plan, and it takes some time to get these things rolled out, but certainly the fuss and the news around this particular patch really highlights how critical it is to be able to get those updates done quickly.

Jason SorokoYeah, Tim and I on this podcast have often given a lot of sympathy to people, CIO, CSOs, etc. that are in this patch cycle and immediate patching is not always possible. That's absolutely the case. Anyway, this has been a really interesting topic, Tim, and I'm glad we had Nick on to help explain it.

Nick FranceThanks very much for having me gents and yes, it was certainly very interesting. It's a great, interesting topic to discuss, but, yeah, thank you for my first time on the podcast and hopefully there will be more in the future.

Tim CallanYeah. That was great. We'd love to have you back. Thank you very much for joining us, Nick and thank you, Jay, and this has been Root Causes.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!