Remote desktop vulnerabilities: Identifying the exposure and patch using osquery
[Updated March 11th] This article was written in May 2019 and updated in June 2019. We are updating it again, as CVE-2020-0796 is now public, and has not been patched yet.
CVE-2020-0796 is a remote code execution bug in Microsoft’s SMB (file sharing) server.
Expect attacks targeting this vulnerability soon. Use the queries in this article to find machines with port 445 exposed to the Internet.
As Microsoft recommends disabling compression as a workaround, which is configured in the registry, you can also query for the mitigation status of your systems.
Disabling SMBv3 compression
A registry parameter can be configured, via PowerShell or any other method, to disable SMBv3 Compression.
|Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force|
Checking SMBv3 compression is disabled with osquery
This query only returns results if a machine has the workaround configured properly.
|SELECT name, data, key, type FROM registry WHERE key='HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters' AND name='DisableCompression' AND data=1;|
If you are sending osquery data to a centralized environment, configure this query to run, or run it as a real-time/distributed query. Any system that does not return data is unprotected at the moment, until a patch is released.
If you want more data, and want to get results from machines that are not protected as opposed to the other way around, this query will return a 0 if the key does not exist, a 1 if it exists but is misconfigured, or nothing if it is configured properly.
0 = Key missing
1 = Key misconfigured
Null results = all good
SELECT IFNULL(key_count,0) AS key_state FROM (SELECT COUNT(*) AS key_count, data
FROM registry WHERE path='HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\DisableCompression')
WHERE key_state!=1 OR data!=1;
[Updated June 5th] Patching for the CVE (CVE-2019-0708) vulnerability (referred to as BlueKeep) appears to have been slow, according to Rob Graham among others. One security expert, Ryan McGeehan (@Magoo), with experience in modeling vulnerability exploit probability and has done just that with the BlueKeep security flaw.
His concerning summary concludes:
"Chances are about even (47.62%) for “in the wild” BlueKeep exploitation to be observed between now and end of June."
Follow the outline below to check your exposure using osquery.
Microsoft released an important patch to the remotely exploitable Remote Desktop Services (RDS) vulnerability. This vulnerability does not require any authentication and allows an attacker to run code remotely. Expect public exploits to start appearing soon.
Similar to bugs used by exploits like EternalBlue, it has the potential of becoming wormable.
While not necessarily easy to exploit, it is still serious enough that Microsoft released patches for all affected versions of Windows going as far back as XP, which normally does not get security updates. Windows 2012 and newer are not affected.
What should be done:
- Halt Any Exposure of RDS to the internet. RDS is often exposed to the Internet to provide remote access to workers or support staff. It is rarely patched frequently enough, configured to use proper transport encryption, and accessed with two-factor authentication. It is almost always a risky proposition to have RDS on the Internet.
- Deploy patches as soon as possible, and verify that it was done on all your Windows systems with RDS enabled.
How osquery or Uptycs can help:
Identifying Internet-Exposed Remote Desktop instances
Many systems on the Internet scan for open RDS instances, trying to brute-force their way in. You can easily spot internal instances that are listening to the Internet by monitoring the connections to them. Though the vulnerability only affects specific versions of Windows, we highly encourage you to consider any Internet exposed RDS as a vulnerability.
process_open_sockets where the local port is
3389, and the
remote_address is not localhost or part of your network’s address space.
Any result returned will indicate a connection to port 3389, originating from unknown sources, on one of your endpoints. You then need to fix firewall rules that would allow this to occur, and run this query frequently to spot any other control failure.
To keep things simple, we included
172.16%, although this won’t cover all possible IPs under 172.16.0.0/22. If you use those ranges, we recommend you list the subnets you do not use in your query.
Uptycs alerting is built to handle non-RFC1918 IPs in a more scientific manner, but considering the amount of scanning and brute-forcing that occurs on RDS, this approach should provide a very valuable and quick way to identify machines to protect.
Identifying the presence of the new - or any - Windows patch
The patches table in osquery is especially useful in this situation.
As we know the patch is KB4500331, all we need to do is query for its presence, as well as check if the operating system has been identified as vulnerable. Windows 2008 R2 is the most recently identified and is represented by version 6.1.
The vulnerable versions that we can query with osquery are therefore:
- 6.1 - Windows 7 and 2008 R2
- 6.0 - 2008 (yes, and Vista - but who’s using that?)
Note: Older versions 2003 R2, 2003, XP are not supported by osquery.
Results indicate a machine that was previously vulnerable, but has been patched properly.
While patching may take precedence this week, and new vulnerabilities are constantly discovered, ensuring services that use protocols like RDP and SMB/RPC are not exposed to the Internet will have a long-lasting impact on your security posture. Once you have ensured you do not see any exposure using osquery, you may want to scan all of your Internet IPs for these ports on a daily basis. One way to do this is by using a network scanning tool like nmap or MASSCAN to ensure no system is exposed, but not reporting to your centralized osquery platform.
Then, the next step would be ensuring that those same services are only exposed to people who need them, on systems that need them. You can customize the process_open_sockets query to see where lateral movement is done over port 3389, 445 or even 22, to help you plan further segmentation to ensure it’s only exposed where needed.
Special thanks to defensivedepth for helping test the query and finding a nice way of identifying only vulnerable OS versions.
Related osquery resources: