BlueKeep and Forthcoming RDP Attacks - Zingboxgo.zingbox.com › rs › 562-ZPO-907 › images ›...

Copyright © 2019 Zingbox, Inc. 1

Proprietary. All rights reserved.

BlueKeep and Forthcoming RDP Attacks Zingbox Security Research

Executive summary In the May 14, 2019 Patch Tuesday, Microsoft released a critical update to correct a remote code execution vulnerability due to improper request handling in the RDP (Remote Desktop Protocol). This vulnerability (CVE-2019-0708) does not require authentication and does not require user interaction to be exploited. It can be exploited simply by sending a specially crafted packet to the target system via RDP.

This vulnerability is present in the following Windows versions:

• Windows 7

• Windows server 2008 R2

• Windows server 2008

• Windows XP

• Windows server 2003

Due to its criticality, Microsoft has released patches even for unsupported Windows versions such as Windows 2003 and Windows XP. This vulnerability has been named BlueKeep as a reference to the TV show Game of Thrones and because it frequently causes a Blue Screen of Death when exploited.

RDP is a service that allows machines to connect and manage resources on a remote computer. To establish an RDP session, a client machine sends a connection request over the network to a host machine on standard TCP port 3389. RDP can be secured using SSL/TLS. As a result, the RDP traffic will be encrypted.

BlueKeep and Forthcoming RDP Attacks

Copyright © 2019 Zingbox, Inc. 2 Proprietary. All rights reserved.

The RDP connection sequence is described in the following image:

Figure 1: The RDP connection sequence diagram (provided by Microsoft)

To allow communication between two machines, RDP uses Static Virtual Channels. These channels are created before the security check is performed, which is the fundamental defect in design that attacks seek to exploit. Due to a flaw in request handling that causes a use-after-free condition, an attacker can crash or even gain access to a victim’s machine.

Traditional rule-based security solutions cannot always detect this issue because the inbound traffic from an attacker can be fully encrypted and appear as a normal connection. However, through the application of AI and machine learning, behavioral analysis can detect different types of anomalies in network traffic. And this is what the Zingbox platform does to detect that a victim is receiving unusual RDP requests.

https://www.zingbox.com/



By performing a Shodan search, it was possible to find 3,865,098 devices with TCP port 3389 open to the Internet:

Figure 2: Shodan search results of port 3389 exposed to the Internet

Even when more than 3 million devices have TCP port 3389 exposed to the Internet, only one third of them have the BlueKeep vulnerability.

It is important to mention that RDP can be running on ports other than 3389, just like any other service. It is natural to compare BlueKeep with MS17-010 (the vulnerability exploited by WannaCry) since they share similarities:

• They are both remote code execution vulnerabilities.

• They are both potentially wormable.

• They do not require authentication to compromise a vulnerable device.

• Computers all over the world have these vulnerabilities.




Nevertheless, there are some important differences between the vulnerabilities mentioned above:

• As a consequence of previous disruptive attacks, system administrators and users are now more aware and may implement better patch policies.

• The exploits available online are very limited and the working PoCs (proofs of concept) are not weaponized. Telemetry shows that attackers are only using the BlueKeep scanner available in Metasploit and a leaked PoC that causes a Blue Screen of Death.

• Even though scans targeting RDP port 3389 have increased, the increase has been small and gradual.

• It requires some level of skill to weaponize one of the existing PoCs that can be found online to gain access to the shell on the victim machine.

Technical analysis A patch analysis was performed to fully understand the underlying cause of the vulnerability relies and to create ways to detect this type of RDP attack for our solution. To accomplish this, we proceeded to make a binary diffing. Binary diffing is commonly performed to analyze infected binaries, firmware changes, and security updates, as was the case here.

The update we analyzed was KB4499175 for Windows 7 x86:

Figure 3: Microsoft Update Catalog




The handling of pre-authenticated RDP packets involves several modules, some of them are in user mode and others are in kernel mode:

User mode

• icaapi.dll

• rdpcore.dll

• termsrv.dll

Kernel mode

• termdd.sys

• rdwp.sys

After extracting the patch from the .msu file, we saw that icaapi.dll was not modified in this last security update. Therefore, we proceeded to compare the patched termdd.sys to the original unmodified version. termdd.sys is a Windows-signed driver. It is in charge of sending messages for mouse and keyboard activity to and from the RDP driver.

Figure 4: Patched termdd.sys




The original binary can be typically found in C:\Windows\System32\drivers:

Figure 5: Original termdd.sys

After diffing the original and the patched binary, we spotted notably larger changes starting at physical address 0x00001ebe. We used this as a first reference to start looking at the important changes in the code that were applied to the patched driver.

Figure 6: Significant differences between the original and patched binaries start here

Note that before 0x00001ebe (physical address), the changes are not significant. Major differences begin from this point.




We observed that the major changes mentioned above are part of the .text section of the binary, which is where the executable code is.

Figure 7: The .text section of the binary goes from 0x0400 to 0x7800 (physical addresses)

These physical addresses belong to two different functions. Both of them have a similar change in the patched version involving the value “MS_T120” (0x18146). These are the differences at those addresses:

Figure 8: Diff results (red = original, green = patched)




The notable changes in the two functions are the instructions lea eax, dword [esi/edi + 0x94]; push 0x18146; push eax, which correspond to a string comparison of “MS_T120” (0x18146).

The following images graphically compare the original and patched functions based on changes found in the previous images. We can observe that an if statement was added to both functions to verify connection requests using channel name “MS_T120” (0x18146) and using channel index 31 (0x1F) exclusively:

Figure 9: Function 1 graph comparison (original vs patched)

Figure 10: Function 1 P-code comparison (original vs patched)




Figure 11: Function 2 graph comparison (original vs patched)

Figure 12: Function 2 P-code comparison (original vs patched)

As mentioned before, RDP uses Static Virtual Channels to allow communication between two machines and creates them before the security check is performed. termdd.sys creates a channel, which persists until the end of a session. The vulnerability resides on the MS_T120 (0x18146) channel. To terminate the channel, a specially crafted packet must be sent to the MS_T120 channel. If data is then sent to this channel, termdd.sys replies with an error message and terminates the channel by calling the _IcaFreeChannel function, which frees the MS_T120 ChannelControlStructure using index channel 31 (0x1F) from the channel pointer table.




The vulnerability exists because the pointer isn’t deleted properly. After the connection is terminated, the RDPWD!SignalBrokenConnection function is called. This function tries to access a freed structure using the 0x1F pointer, which produces a use-after-free condition. As a consequence, an attacker can remotely exploit the vulnerability by establishing a session by opening a channel called MS_T120 without prior authentication.

A simulation of the behavior explained above is shown in the following screen capture:

Figure 13: Detecting a vulnerable device




Recommendations The Zingbox security research team has confirmed that this vulnerability can be successfully exploited. This indicates that many attacks could be forthcoming to take advantage of this vulnerability. In fact, Metasploit has already integrated a scanner to find devices with the BlueKeep vulnerability into its toolset. It’s important to take precautions to prevent attacks exploiting this vulnerability even when there is no public remote code execution exploit and no solid evidence of exploitations in the wild.

Additionally, there are many fake PoCs (proofs of concept) online pretending to demonstrate the exploit while actually attempting to make you execute malicious code on your devices. Most if not all of the publicly available PoCs are fake. However, if you still want to try one of them, only do so on your test network; never on your production network.

To protect your devices from attack, consider taking the following precautions:

• Follow best practices for hardening and up-to-date patching.

• Limit RDP exposure only to your intranet by configuring your perimeter firewalls to block incoming traffic on the RDP port.

• Perform regular scans for vulnerable devices on your network.

• If Remote Desktop Services is not a required service, disable it on your IoT and IT devices.

Zingbox has expanded its existing detections of anomalous network behavior by implementing detections of behavior indicative of RDP scans and RDP exploits related to BlueKeep. IoT Guardian will detect any anomalous behavior on devices vulnerable to this exploit and generate alarms.

Research and analysis by Asher Davila, Zingbox Security Researcher

About Zingbox Enabling the Internet of Trusted Things, Zingbox provides hospitals, companies and manufacturing facilities with IoT (Internet of Things) security software that helps ensure service delivery. Its approach is based on deep learning and enforcement of trusted behavior and is the only IoT security company in the Microsoft Active Protections Program (MAPP).

Founded by Silicon Valley veterans with expertise in cyber security, IoT, deep learning and networking, Zingbox was founded in 2014 and is privately held. Zingbox is headquartered in Mountain View, CA. For more information, visit www.zingbox.com.



BlueKeep and Forthcoming RDP Attacks - Zingboxgo.zingbox.com › rs › 562-ZPO-907 › images ›...

Documents

Transcript of BlueKeep and Forthcoming RDP Attacks - Zingboxgo.zingbox.com › rs › 562-ZPO-907 › images ›...