*********** Update 7/21/20 ***********
Update: Industrial Defender has just posted a new policy on our customer support portal. Similar to other vulnerability policies for major vulnerabilities, we have provided one for the MS DNS vulnerability CVE-2020-1350. This policy will check your environment and let you know through policy exception which assets are still missing the patch and are running a DNS server.
Please see https://support.industrialdefender.com/vulnerability-responses/ for more information.
*********** Update 7/16/20 ***********
Microsoft has released more information regarding this CVE-2020-1350. While others have made claims about other potentially non-vulnerable configuration setups, Microsoft has clearly stated that you either patch or apply the work around, otherwise, if you are running DNS server on a Microsoft server OS from 2003 forward, you are vulnerable. Period. See KB4569509 for the work around, and MS Security Update Guide for CVE-2020-1350, where they clearly state no mitigating factors have been found by Microsoft.
Given the critical nature of AD controllers running DNS services in a control system, I would take this much more conservative guidance from Microsoft, especially given how a relatively easy registry fix is the work around until you are able to safely reach a point to patch. As always, please check with your system supplier and test as much as possible, and backup prior to making any change.
You should add this registry value to your evaluation criteria, and once applied, constantly monitor it until the system is patched. Any change to this setting should warrant further investigation, as it could be indicative of a potential attempt to escalate an on-going threat.
***************************************
The impact of Microsoft’s latest critical exploit could be problematic for the ICS/OT world. CVE-2020-1350, is being a called a "wormable" flaw, meaning it can transmit system to system all by itself. No emails, no user interaction, just good old fashioned TCP/IP -- well actually DNS in this case. This impacts every Windows Server OS back to 2003 that isn’t patched. 2008 R2 will require an extended support agreement. It works by allowing a specially crafted DNS message to execute arbitrary code on the target system.
Don’t take my word for it, to quote Microsoft itself, “We consider this to be a wormable vulnerability, meaning that it has the potential to spread via malware between vulnerable computers without user interaction.” They further clarified the significant risk as follows, “DNS is a foundational networking component and commonly installed on Domain Controllers, so a compromise could lead to significant service interruptions and the compromise of high level domain accounts.”
Why is this so critical to control systems? Because despite years of best practice saying you should move DNS off of your Domain Controllers, many, many ICS systems are delivered this way. Most control systems are independent little Active Directory islands, often built without any eye towards standards like the CIS Benchmarks. This means DNS is enabled by default, and is leveraged extensively by the all the machines on the network. This often includes the credentials for control system itself. To make matters worse, it will sometimes be used as the authentication for the firewalls as well, making this a potential high risk and high impact situation.
But we have firewalls one might say. It will be okay until we can patch in 12-24 months. Did you know many of those firewalls are setup to allow DNS through? You hope those are for returns queries only and only from approved servers, but I’ve seen it all. Port 53 Any, Any exists.
I’d also, say that while this might help mitigate externally, so many people haven’t started, let alone finished, their segmentation projects, so accounting or engineer’s laptop could just as easily be the attack path that brings down a system. There will be no firewall to stop that evil DNS request.
Okay, I’ll just do emergency shutdown and patch. Well okay, that’s fair, but is it approved? Do you know it won’t break the system? And are you even supported? It is not uncommon to see Server 2003 and Server 2008 out there, and those are either not getting a patch or require a very expensive extended support contract with Microsoft or from whomever you get your patches. Many vendors won’t even support the newest versions unless you have maintenance agreement with them.
So what can you do?
There are really two primary parallel paths I would take. And patching is not the first step in either one of them, because that’s not how ICS systems work.
One path is something you should be doing anyway. Make sure you are getting quality feeds for your IDS/IPS and other malware prevention systems. Make sure you understand any of the known IOCs and keep watch for them. This is one path, and primarily doesn’t need a lot of help from you ICS/OT teams. Hopefully this will buy you some time to snipe the worst of the internet from hitting you.
The second path is arming yourself with quality knowledge to form an intelligent response based on facts.
First, get a solid inventory that will tell you all the Windows Servers you have that are impacted. Hopefully you have an ICS asset management system that will tell you all the Windows Servers you have, and more importantly what version, what patches are installed, and which are missing, and if the hosts are running DNS services. Another criterion I would want to know, is the Windows Firewall status and the rules that are in place to help mitigate at the host level. This will give you the list of assets you need to prioritize and circle the troops around. Bonus points if you can set this up to alert you to any changes in these conditions, especially in the negative.
The next step would be to see is if your asset and configuration management system, can pull your firewall configuration and tell you exactly how your DNS services are dealt with at the firewall. Again, it is great if you can setup and monitor for changes, especially after you’ve fixed any holes.
With this data, now you can you sit down and make an appropriate response. You can focus on the most vulnerable and decide the best plan of action across your enterprise. You can decide if where and how you want to respond for each case.
As a former asset owner and former OEM cyber security product manager, I can tell you this is either an exercise of a few minutes to hours, or a few weeks, and there aren’t a lot of in-between. If you haven’t invested in a quality asset and configuration management system with quality reporting and/or integration with data reporting tools, then you are likely in the latter camp.
