[Please comment if you have any feedback / suggested additions/corrections. You can also use our comment form ]
The most notable vulnerabilities patched by Microsoft last week addressed an input validation flaw in the Remote Desktop Service. To exploit the vulnerability, an attacker would send a specially crafted Remote Desktop Protocol (RDP) request to the Remote Desktop Service. The vulnerability is notable for several reasons:
- The exploitation of the vulnerability does not require authentication.
- An exploit may lead to arbitrary code execution.
- (too) many organizations are exposing RDP to the Internet.
- Windows 7 / 2008 and older are affected, going back to Windows XP.
Current Exploit Development Status
Several security vendors stated publicly that they developed exploits internally that will at least trigger a denial of service condition (blue screen). Currently, there are at least two public partial exploits [1][2]. One triggers the “vulnerable path” without triggering a blue screen or causing any other damage. It can be adjusted to play with the “channel” parameter to create normal and exploit traffic. The second one also triggers the vulnerability without any intended ill effect. The second exploit has been made available in the form of a stand-alone vulnerability scanner.
It does appear non-trivial to develop a reliable remote code execution exploit for this vulnerability, which will hopefully get us a few more days until one is publicly available. However, exploit development is active, and I don’t think you have more than a week.
Detection
The NCC Group publicly released a Suricata signature to detect attacks taking advantage of the exploit [3]. It is difficult to estimate how good the signature is. Cisco released rules for snort as well. Note that RDP usually uses TLS, and all current partial exploits use TLS, making the value of these rules questionable.
What you need to do NOW
Remember, we are coming up on a long weekend in the US. I hope you are well into mitigating this vulnerability as you read this, but here are a few things to consider:
- Do you have any systems running affected versions of Windows? Where are they located (e.g., are they confined to particular subnets)? Can you block port 3389 (RDP) inbound and possibly outbound?
- Deploy IDS/IPS rules to detect the exploit (just in case, but note the TLS issue above).
- Scan your network for open RDP. Do not just use the vulnerability scanner, but find out who is using RDP and why. RDP should not be exposed if possible.
- Follow up the scan with the vulnerability scanner.
- Patch! You want to patch this by Friday. For some organizations, the long weekend may provide a better patch window which is hopefully still ok.
Longer Term Fixes
Being vulnerable exposes two fundamental weaknesses in your network: You are still running Windows 7 (or XP??), and you are exposing RDP. Neither is good, and both issues need to be addressed. With this focus on RDP, there is a good chance that additional vulnerabilities will be found in the next few months. If this is true, then fire drills will continue until you can get these two issues resolved.
Upgrading from Windows 7 to 10, and upgrading from Windows Server 2008, should already be underway, so you may just accelerate what you are already doing. If you still run Windows XP: There better be a very good reason for it, and I hope that you have those systems adequately protected.
Eliminating RDP may be difficult for some organizations. But you can at least isolate it by requiring a VPN to connect to it, or by taking advantage of an RDP gateway supporting SSL. Take a look at some of the guidance offered by Microsoft [4]
Technical Details
Before authentication, RDP negotiates various parameters and capabilities. After initiating the connection with an X.224 connection request and having it confirmed by the server, the client will send a “Generic Conference Control (GCC) Conference Create Request.” Usually, this request defines three different channels. To trigger the exploit, an MS_T120 channel is added as a fourth channel. This channel should only bind to “channel 31”, but the exploit will bind it to another channel. The current signatures look for this particular artifact. McAfee’s blog offers an excellent summary of some of the details. [5]
I collected some packet captures from various normal and exploit tools. You can download the pcap files here: https://isc.sans.edu/diaryimages/BlueKeepPCAPs.tgz
[ note that some of the links below may trigger overly sensitive anti-malware scanners ]
[1] https://github.com/zerosum0x0/CVE-2019-0708
[2] https://github.com/n1xbyte/CVE-2019-0708/blob/master/poc.py
[3] https://github.com/nccgroup/Cyber-Defence/blob/master/Signatures/suricata/2019_05_rdp_cve_2019_0708.txt
[4] https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/welcome-to-rds
[5] https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/
—
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.