Mitigate curl vulnerabilities on Windows

Microsoft’s monthly Windows updates include a binary copy of the open source utility curl. Microsoft is not especially diligent about keeping the utility up to date, and they take measures to stop you from updating it yourself. In this blog post, I’ll talk about how to go about mitigating the vulnerabilities when you can’t update with a patch.

The problem with Microsoft’s distribution of curl

The problem is that Microsoft ships vulnerable copies of the curl utility and only updates that utility every few months. If a high severity vulnerability in that utility gets discovered, many organizations have a policy to apply and update in a relatively short period of time. 30 days wouldn’t be unusual. But when Microsoft doesn’t provide an update, that leaves its customers in breach of that policy, leaving them with one of three bad options: do nothing, update the utility and break the functionality it’s there to provide, or delete the file since you’re going to break the functionality anyway.

The danger of the last two options is Windows may very well put the file back after you change or delete it, giving you a false sense of security.

Let’s talk about a fourth option. This option is more work, but I’ve used it in the past, either when I wanted to protect against unknown future threats and vulnerabilities, or when known vulnerabilities existed and I wasn’t able to deploy updates for whatever reason.

Step 1: collect URLs

The first step to mitigate the curl vulnerability is to look in your SIEM or whatever centralized log management system you have, and look for curl’s user agent. At the time I’m writing this, the user agent you want is curl 8.0.1. There will be a relatively small number of URLs it talks to, and all of them will have some affiliation with Microsoft.

Export that list, and truncate all of the items down to just domain names and deduplicate it. This will reduce the number even more, and also put you in a better position for next month. Because curl will probably be talking to the same servers next month, but pulling different files.

Step 2: put rules in your proxy server

The next step to mitigate the curl vulnerability is to put rules in your proxy server allowing that specific curl user agent, curl 8.0.1 in this case, to talk to that small list of servers. And then you put in a rule disallowing any other server.

You will want to look at your proxy logs every month around Patch Tuesday to see if that user agent is trying to talk anything new, and enter those domain names after verifying they are somehow related to Microsoft.

You may even want to configure your SIEM to send you alerts if that user agent is denied. This will allow you to be a little more proactive about managing it, and in the event of malicious activity, you’ll see that as well.

And then, after Microsoft distributes a newer curl binary, if future vulnerabilities appear, you can repeat the same process for the new user agent to mitigate any future curl vulnerability.

Why this counts as a mitigation

Taking these steps mitigates the risk just about as far as you realistically can. You’ve limited the URLs that curl is able to talk to, so anyone looking to exploit one of these vulnerabilities would have to first compromise one of those servers, and then, out of the hundreds of thousands of companies who do business with Microsoft, they would have to choose you to exploit.

It seems like a fairly safe bet that in the event of Windows update servers getting compromised, you would be far enough down on the list to have time to take additional evasive measures before the hypothetical attackers got to you.

Don’t get me wrong, the risk isn’t zero. But it’s an acceptable risk at that point. Along the lines of the risks you take driving to work each morning. There’s no perfect security. Only acceptable risk.

Examples of using similar tactics in the past

I’ve used very similar methodologies in the past. Back in the waning days of Adobe Flash as the scourge of the Internet, I put rules in place to limit Adobe Flash content from all but about 1,000 websites. If someone had a business need to view Flash content on some website I missed, I was quick to add it to the list. I only got one or two requests per month. It cut down on the number of security incidents so much that I had plenty of time to handle those requests.

I also blocked fonts when there were font driver vulnerabilities we hadn’t patched yet.

I’ve also used the same methodology to limit Internet Explorer to the internal network, and whatever external business critical sites demonstrably only worked with Internet Explorer. These results were less dramatic, because by the time we did this, there weren’t a lot of people left who preferred Internet Explorer, and there weren’t a lot of sites left that required it. It helped us manage risk while migration plans were under way.

Using a combination of allowlists in your Web proxy and alerts in your SIEM is a good example of defense in depth and managing risk when patching is impossible, and it also takes some pressure off teams when the update becomes available.

The discipline is called vulnerability management, not vulnerability patching. Patching is the most common method of mitigating risk, and it’s usually the preferable option when the option exists. But a competent security professional needs to be able to pivot and still do something when factors beyond your control keep your organization from deploying patches.