Rapidly Identifying Systems Critically Vulnerable to CVE-2020-0601 and Reporting for CISA Emergency Directive 20-02

Yesterday, Jan. 14, 2020, on the first “patch tuesday” of the year, Microsoft released patches for critical vulnerabilities in Microsoft Windows client and server operating systems.

To emphasize just how critical these vulnerabilities are, DHS Cybersecurity and Infrastructure Security Agency (CISA) released their second-ever Emergency Directive and the National Security Agency’s (NSA) Central Security Service issued a press release and Cybersecurity Advisory providing supplemental guidance. In both cases, the technical guidance and mitigation actions are clear and actionable. Organizations would be well-advised to conduct a quick review of the prioritized guidance in these materials.

In an effort to support organizations leveraging Splunk as a data platform, I spent this morning and early afternoon crafting some SPL and a prototype Splunk dashboard around this issue. Hopefully this post will help folks out there who are looking for a quick-start way to review their enterprise environment in the context of this exposure.

Read on for details...

Assessing Vulnerability Scan Results

When sitting down to craft some SPL, I started with vulnerability scan data because I had some on hand already, and let’s be honest — searching this data for a CVE and finding related hosts is easy in Splunk. For regular visitors of this blog, you’ll notice the similarities in this approach to my prior work on Bluekeep back in 2019.

This initial line says “go find me the CVEs, Microsoft KBs, and hosts from the Vulnerabilities data model." As was the case with the Bluekeep prototype, knowledgeable Splunkers will be quick to point out that I should’ve explicitly searched for cve-2020-0601 in the initial tstats search to make things more efficient. That’s completely right, but since I didn’t have this CVE in my sample data, I left Vulnerabilities.cve=* to make testing my SPL easier.

Adding to the original query to specifically look for cve-2020-0601 OR relevant Microsoft KB’s (4528760, 4534271, 4534273, 4534276, 4534293, 4534306) gives us a slightly longer SPL pipeline, but precise results that are reformatted to build out a table of results with “Vulnerable_Host, CVE, and Microsoft_KB” as the table header / fields returned. You’ll note that I haven’t included the results under this second screenshot because my sample data set doesn’t have the relevant CVE findings or MS KB’s, so it’s a blank table.

Pasting the SPL directly here to make copy/paste easy for anyone that wants it:

| tstats count from datamodel=Vulnerabilities.Vulnerabilities where Vulnerabilities.cve=* Vulnerabilities.mskb=* by Vulnerabilities.cve Vulnerabilities.mskb Vulnerabilities.dest 
| search Vulnerabilities.cve=cve-2020-0601 OR Vulnerabilities.mskb=4528760 OR Vulnerabilities.mskb=4534271 OR Vulnerabilities.mskb=4534273 OR Vulnerabilities.mskb=4534276 OR Vulnerabilities.mskb=4534293 OR Vulnerabilities.mskb=4534306 
| rename Vulnerabilities.dest as Vulnerable_Host Vulnerabilities.cve as CVE Vulnerabilities.mskb as Microsoft_KB 
| table Vulnerable_Host, CVE, Microsoft_KB

A couple of caveats for this SPL to work in your environment:

1. The above example assumes that the data has been ingested in Splunk Common Information Model (CIM) compliant format and, admittedly stating the obvious on these last two
2. You have to have vulnerability scan data ingested into your Splunk instance
3. The vulnerability scan data has to have actually identified instances of systems in your environment that are susceptible to CVE-2020-0601 and/or require the relevant MS KBs/patches
    

Identifying Susceptible OSs Without Vulnerability Scans

As with the Bluekeep prototype, I didn’t want to solely rely on vulnerability scan results since some vulnerable systems may not be scanned regularly, or may not have been on the network when the vulnerability scan looking CVE 2020-0601 was run. The following basic query provides a way to identify systems that correspond to the affected OS names and service packs that are identified in the advisories.

This base search says “go look at the Compute_Inventory data model and show me anything that has an Operating System (OS) that starts with the string Microsoft* and has a Caption field." This gave me something to test against.

My next step was to add in a specific search string that explicitly called out the OS and Version(s) that were flagged as “impacted” in CVE-2020-0601, CISA ED 20-02, and the NSA Advisory. I’ve highlighted the additional SPL in blue below to make it stand out from the base search in the previous image.

Since I knew that I would be moving these searches into a dashboard with some multi-selects and search boxes, I used the eval command to combine the Caption and Version fields into a new field called os_string (highlighted in blue below) then piped the results out by _time into a table.

I should point out here that the Windows sample data I had on-hand was fairly limited, hence the repeated Windows 10 results in the table above.

Copy/pasting the SPL here to make it easy for anyone that wants it. You may need to modify it slightly, but it should provide a quick way to get started without having to rely on vulnerability scan data.

| tstats prestats=1 count from datamodel=Compute_Inventory where All_Inventory.OS.os=Microsoft* AND Caption=* 
| search (Caption="Microsoft Windows Server 2016 *" Version=*) OR (Caption="Microsoft Windows Server 2019 *" Version=*) OR (Caption="Microsoft Windows 10 *" Version=*) OR (Caption="Microsoft Windows 10 *" Version="*1607") OR (Caption="Microsoft Windows 10 *" Version="*1709") OR (Caption="Microsoft Windows 10 *" Version="*1803") OR (Caption="Microsoft Windows 10 *" Version="*1809") OR (Caption="Microsoft Windows 10 *" Version="*1903") OR (Caption="Microsoft Windows 10 *" Version="*1909") OR (Caption="Microsoft Windows Server *" Version=*1803) OR (Caption="Microsoft Windows Server *" Version=*1903) OR (Caption="Microsoft Windows Server *" Version=*1909) OR (Caption="Microsoft Windows Server 2012 *" Version=*)
| eval os_string = Caption+" - "+Version
| search (os_string="*") (host="*")
| stats count by os_string host _time
| table _time, os_string, host

Making Things Even Easier with a Dashboard

Taking the prototype SPL from the examples above and considering how it could be more useful in the real world, I rolled these two queries into a basic dashboard and added in some multi-selects and a search box to make continuous monitoring easier -- all shamelessly borrowed from my prior Bluekeep prototype.

The left panel focuses on detecting OS versions susceptible to CVE 2020-0601 (exclusive of vulnerability scan data). The panel on the right exposes systems that were flagged as “vulnerable” to CVE 2020-0601 according to vulnerability scan results or required the Microsoft KBs/patches that apply to this CVE.

I should point out that I modified the panel on the right side of the image above to include unrelated KB 3065823. This is only to illustrate what results look like in the dashboard since my sample vulnerability data didn’t actually correspond to CVE 2020-0601.  Here’s an image of the unmodified dashboard constrained down to just this CVE and related Microsoft KBs:

“No results found," but only because my sample dataset was limited.  It's unfortunately not likely that your first round of vulnerability scan results will look this empty.

An additional unfortunate reality of modern enterprise environments with mobile  equipment (read as: laptops), is that multiple patch cycles will almost certainly be required before all affected systems are actually patched since these systems won’t necessarily be on the network when vulnerability scans are initially run and/or when patches are initially pushed out.

For Agencies Participating in the CDM Program:

The Splunk platform serves as the data integration layer for CDM.  Leveraging the sample SPL from this blog post, agencies can investigate, monitor, analyze, and act upon the hardware asset management (HWAM), software asset management (SWAM), and application vulnerability management data contained in the CDM data integration layer understand how much of your agencies is impacted by these critical vulnerabilities.

Leveraging Automation and Orchestration:

Splunk Phantom, our orchestration automation and response technology, can augment existing Network Access Control (NAC) technologies to ensure that only patched Windows devices are permitted onto the network.

As an example in the context of Advanced NAC and CDM, prior to permitting a device onto the network, Splunk Phantom could be used to proactively pull contextual information from the CDM data integration layer (e.g., date of last vulnerability scan, open vulnerabilities, latest patch, etc.) to determine if a device needs to be patched or scanned.  If the device has not been scanned or needs to be patched, Phantom can automate the scanning or patching of the device prior to allowing access to the network.

So there we have it, some basic SPL providing separate approaches to solve the same challenge—identifying systems in your environment that are susceptible to CVE 2020-0601. Special thanks to my friend and colleague Patrick Chu, who provided the above thoughtful commentary on CDM, Advanced NAC (network access control), and Phantom.

Again, consider this as a starting point that may need to be modified slightly to your environment and specific data. In any case, it should give you a head-start for reviewing affected systems across your enterprise if you’re looking for one.

I hope this is helpful for folks out there. Feel free to reach out to us at gov_answers@splunk.com if you need help or if you want the prototype dashboard pictured above.

Good luck out there, and happy Splunking!

Author’s post-script: CVE-2020-0601 and CISA Emergency Directive 20-02, have unsurprisingly created a great deal of interest and concern. The criticality of this vulnerability, along with the 10-day reporting requirement mandated in CISA directive 20-02, generated a very real sense of urgency for me to issue guidance quickly. The exchange for this rapid turn-around guidance however, was to narrow the focus of this post to focus on (1) detection of susceptible systems based on OS and version and (2) detection of vulnerable systems based on vulnerability scan results — all before POC exploit code was available. Fortunately one of my talented Splunk colleagues, Drew Church, has authored a follow-up post that includes two detailed examples for detecting CVE 2020-0601 exploit attempts using Zeek (AKA Bro) and endpoint logs. Multiple versions of POC exploit code for this vulnerability are in the wild, including the exploit code Drew used in his example. Readers would be wise to give Drew’s blog post some careful study and operationalize one or both of his recommendations for detection.

----------------------------------------------------
Thanks!
Anthony Perez