PUBLIC SECTOR

BlueKeep Wormable Vulnerability

Back in May of 2019, Microsoft took the rare step of releasing patches for unsupported operating systems due to a recently disclosed “wormable” vulnerability in versions of Windows Remote Desktop Services (RDS) present on certain operating systems.

The unusual step of issuing patches for outdated operating systems provided the world some insight into the potential severity of this vulnerability, and was enough to garner my attention for a day or two shortly after the security bulletin was initially released.  

After looking at it briefly, I decided that despite the severity of the vulnerability, all that was really needed for mitigation was some basic best-practices patching. After reaching that conclusion, I have to admit that I just assumed all would be under control and additional research or SPL slinging wasn’t really necessary.

Fast-forwarding to the first week in June, NSA issued a supplemental advisory about this vulnerability, urging Windows administrators to assess the systems on their networks and issue these critical patches to the affected operating systems.

Reading NSA’s somewhat unusual follow-up advisory prompted me to revisit this vulnerability. In short, I spent yesterday afternoon and this morning 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.


This initial line says “go find me the CVEs, Microsoft KBs, and hosts from the Vulnerabilities data model." Knowledgeable Splunkers will be quick to point out that I should’ve explicitly searched for cve-2019-0708 in the initial tstats search to make things more efficient. True, 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-2019-0708 OR relevant Microsoft KB’s (4500331, 4499180, 4499149, 4499175, 4499164) 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=* Vulnerabilities.dest=* by Vulnerabilities.cve Vulnerabilities.mskb Vulnerabilities.dest 
| search Vulnerabilities.cve=cve-2019-0708 OR Vulnerabilities.mskb=4500331 OR Vulnerabilities.mskb=4499180 OR Vulnerabilities.mskb=4499149 OR Vulnerabilities.mskb=4499175 OR Vulnerabilities.mskb=4499164
OR Vulnerabilities.mskb=4499164 Vulnerabilities.dest="*"
| 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-2019-0708 and/or require the relevant MS KBs/patches

Identifying Susceptible OSs Without Vulnerability Scans

I didn’t want to solely rely on vulnerability scan results since some vulnerable systems may not be scanned regularly (or at all). 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 Service Pack versions that were flagged as “impacted” in CVE-2019-0708. 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 ServicePackMajorVersion 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 data I had on-hand was fairly limited, hence the repeated Windows 7 SP1 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 7*" ServicePackMajorVersion=1) OR (Caption="Microsoft Windows Server 2003*" ServicePackMajorVersion=2) OR (Caption="Microsoft Windows Server 2008*R2*" ServicePackMajorVersion=1) OR (Caption="Microsoft Windows Server 2008*" ServicePackMajorVersion=2) OR (Caption="Microsoft Windows XP*Professional*" ServicePackMajorVersion=2) OR (Caption="Microsoft Windows XP*" ServicePackMajorVersion=3)
| eval os_string = Caption+" SP"+ServicePackMajorVersion
| 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. The left panel focuses on detecting OS versions susceptible to CVE 2019-0708 (exclusive of vulnerability scan data). The panel on the right exposes systems that were flagged as “vulnerable” to CVE 2019-0708 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 2019-0708.  Here’s an image of the unmodified dashboard constrained down to just this CVE and related Microsoft KBs:

“No results found." Hopefully your vulnerability scans don't turn up any affected systems either.


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 2019-0708. Special thanks to my colleague Sabrina Lea, who served as a sounding board and offered valuable perspective as I started thinking through this approach over the last couple of days.


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.

One final item to consider, NSA guidance also points out that standard RDP port TCP/3389 should be blocked as a best practice defensive measure—particularly on perimeter / Internet-facing systems.

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!

Anthony Perez
Posted by

Anthony Perez

Anthony is Director of Field Technology for Splunk’s public sector headquarters in Mclean, Virginia.  Prior to joining Splunk, Anthony spent several years at a global consulting firm where he led the development and execution of novel approaches for aggregating, analyzing, and assessing cyber threats to US interests.

Mr. Perez is a graduate of the Whiting School of Engineering at Johns Hopkins University and holds an M.S. in Information Systems specializing in Security.

TAGS

BlueKeep Wormable Vulnerability

Show All Tags
Show Less Tags

Join the Discussion