Late last week the US Department of Homeland Security, Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive to all government agencies to patch a recently discovered Windows Server vulnerability. Urgency at the agency was clear for this patch—giving government agencies only 24 hours to ensure that all of their systems had been squared away.
News over the weekend took hold of this patch and by Sunday morning, I had received countless emails from concerned security conscious MSP owners regarding what action they need to take specifically around this patch.
The vulnerability was super critical because an attacker could gain admin status access to your network by sending a string of zeroes through the Windows Netlogon protocol. CISA assumed that this vulnerability was being actively exploited in the wild (meaning that hackers had started to use this exploit in their attacks).
CISA doesn’t normally issue patch mandates, so this patch was particularly important. Government workers worked around the clock to get the patch updated on their systems.
The good news is that Microsoft already released a patch update in August for this vulnerability. If you have your servers patched and are running operating systems that have maintenance, you are good to go.
If not, time to do one of two things:
- If there are no patches available for your operating system (because you are end of life) then it is time to separate that server off onto its own VLAN and provide access to it only to the ports it needs to function (and to AD so it can check in, but be specific to the domain controller it communicates with)
- Upgrade the server to a supported operating system. (This may take planning and discovery so option 1 may be the best route if you have Server 2008 R2 in your environment. Here’s a link to the life cycle for Microsoft Server operating systems: https://support.microsoft.com/en-us/lifecycle/search/1163.
The bad news is that this code exploit demonstrates how unpatched systems could easily fall victim—especially if you are asleep at the wheel with a poor performing patching strategy.
The strategy that I have found most useful in tracking and making sure your team is keeping on top of patches (like this one released by Microsoft last month) is as follows:
Create an email address that is specific to patching — create an email account that will be receiving notices from vendors related to patching. Email should be monitored for upcoming patch releases and prioritized based on impact to business and cybersecurity. I’ve always used patches@yourcompanyname as an email address—make sure this account is delegated to someone in charge of patching or someone in your organization that will be held accountable to making sure critical patches get applied.
Subscribe to vendor patch release information — sign up for patch notifications for all of your and your clients’ software vendors.
Evaluate your list of patch updates — evaluate your patch email at least weekly. I would recommend checking the email at the beginning of the week (a lot of zero-day exploits get released or written about over the weekend). I also would check on Wednesdays, since Microsoft patching occurs on Tuesdays (and Microsoft will probably be a heavy lift for most of your environments).
Prioritize your patch list — identify the patches that are critical security vulnerabilities along with business-critical updates to ensure there are no work stoppages. Priorities based on your list for testing and patch releasing.
Test your patches — this is a critical overlooked step in more instances than I’d like to see. Make sure your team tests their patches on your own machines and then a subset of machines before rolling updates to all of your client base. This will save you many headaches that I’ve learned the hard way to avoid.
To reinforce how critical some patches can be many security analysts are sounding the alarm that CVE-2020-1472 will get weaponized quickly. This means that you and your team need to be able to follow a patch process and track patch success within your environments.
Better not to let history be the judge on critical vulnerabilities. Advanced Persistent Threats caused by unpatched or mispatched systems can be serious and attackers know this by now.
