This blog was authored by Brandon Stultz
Cisco Talos started reverse-engineering work immediately to determine how exactly RDP was vulnerable. Talos wrote and released coverage as soon as we were able to determine the vulnerability condition. SID 50137 for SNORT® correctly blocks exploitation of CVE-2019-0708 and scanning attempts that leverage this vulnerability.
This rule prevents exploitation of CVE-2019-0708 by blocking any RDP connection that attempts to use the “MS_T120” virtual channel. The RDP protocol defines virtual channels that can be used to transfer different kinds of data (e.g. clipboard, audio, etc.). In addition to these client-specified channels, Microsoft creates the “MS_T120” channel in the Windows RDP system. Clients are not expected to create the “MS_T120” channel. A remote unauthenticated attacker can exploit CVE-2019-0708 by sending crafted data to this internal channel.
Since RDP servers are not aware of which virtual channels the client supports, the client provides a list of desired channels in the connect-initial packet at the start of the RDP session.
Client --> Connection Request --> Server
Client <-- Connection Confirm <-- Server
– Optionally switch transport to TLS –
Client --> MCS connect-initial --> Server
Client <-- MCS connect-response <-- Server
It is possible to specify in the RDP connection request that the client is TLS capable. In most cases, this causes the server to switch the connection to TLS after the Connection Confirm packet. This means that Cisco Firepower will only scan the virtual channel list in the encrypted case if TLS decryption is set up for RDP.
While the aforementioned Snort rule can help protect against BlueKeep, it is still possible for attackers to carry out an encrypted attack — essentially sneaking past users and remaining undetected. Unless users set up TLS decryption for RDP on their Firepower device, there is a chance an attacker could exploit CVE-2019-0708 to deliver malware that would have the potential to spread rapidly.
The following is a guide to set up RDP decryption on Cisco Firepower. This guide specifically applies to Windows Server 2008 instances (newer versions of Windows Server are not vulnerable to BlueKeep). Additionally, Windows 7 only allows setting up a custom RDP certificate in the registry. It is possible to export the self-signed RDP certificate and private key in Windows 7 but this requires using the mimikatz tool as the private key for the auto-generated certificate is marked as “not exportable”. Considering these hurdles, we focused on Windows Server 2008 for this guide.
*Note this procedure requires an inline Firepower device that supports SSL decryption. For more information, visit: Cisco Next-Generation Intrusion Prevention System (NGIPS) - Cisco.
Steps for RDP Decryption1. Determine the certificate used by the RDP server
In Windows Server 2008, TLS certificates for RDP are configured in "Remote Desktop Session Host Configuration."
Once the remote desktop host configuration is opened, double-click on any RDP connections and note the certificate used by the RDP server — we will need this later.
Open mmc.exe and navigate to: File -> Add/Remove Snap-in
Finally, click “OK” to add the certificates snap-in.
Navigate on the left to the Local Computer certificates and locate, on the right, the certificate used by the RDP server we found before in the Remote Desktop Session Host Configuration.
Right click on the certificate and in “All Tasks” click on "Export."
Finally, click "Finish."
You have successfully exported the RDP certificate and private key.
Now, prepare them for the Firepower appliance.
3. Prepare the RDP certificate and private key for Firepower
For this step, you will need the OpenSSL tool and the PFX file exported in Step 2
(dc1.pfx in this example).
Extract the RDP certificate from the PFX file:
$ openssl pkcs12 -in dc1.pfx -clcerts -nokeys -out cert.pemThe command above will ask for the import password, this is the password we typed in Step 2.
Enter Import Password:
Extract the RDP private key from the PFX file:
$ openssl pkcs12 -in dc1.pfx -nocerts -out key.pemThe above command will ask for the import password again, as well as a PEM password. Remember this private key passphrase, — we will need it when we add the RDP certificate to Firepower.
Enter Import Password:
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
4. Import the RDP key into Firepower
At this point, you should have the RDP cert “cert.pem,” as well as the encrypted RDP private key "key.pem."
You have successfully imported the RDP certificate and private key. Now, create an SSL policy for decryption.
5. Create an SSL policy
Name the rule and give it the action “Decrypt - Known Key.” Click the “with” field and select the certificate you imported earlier in Step 4.
If applicable, select “Source” and “Destination” networks or leave them as "any."
Click “Add” and then “Save” to save the rule.
Additional SSL documentation is available here.
6. Enable the Intrusion Prevention Rule for BlueKeep
Edit the desired Intrusion Policy.
Filter for Snort ID 50137 "OS-WINDOWS Microsoft Windows RDP MS_T120 channel bind attempt."
Click the checkbox and select Rule State -> Drop and Generate Events.
7. Configure the Access Control Policy
Navigate to Policies -> Access Control and edit the relevant Access Control Policy.
Verify RDP connectivity and functionality.
Encrypted Exploit in ActionLet’s start this by walking through what happens when the exploit is attempted on an unpatched, unprotected Windows 7 system.
ConclusionOver the last several years we have seen several high profile vulnerabilities affecting services associated with various Windows services. Some, if not all, of these services should not be exposed to the internet. To reduce external exposure organizations need to take additional steps to ensure that services like RDP and SMB are not exposed unless explicitly required, but does not eliminate the need for patching. This is yet another example of why patching is one of the core fundamental concepts in information security. Vulnerabilities this severe appear periodically, and organizations need to be prepared to respond in a variety of different ways. Patching takes time and making sure that you have detection and prevention in place can require varying levels of difficulty. In this particular example, in order to get a higher level of visibility, SSL decryption is required for more thorough protections.
As encryption becomes more ingrained in the internet and more applications take advantage of it, these types of steps are going to become more common. Adversaries are always going to look for ways to evade any type of detection and using encryption is a great way to evade some of these technologies. Regardless, Cisco Talos will always be looking at the ways adversaries are operating and developing new and clever techniques to defeat them.
Article Link: http://feedproxy.google.com/~r/feedburner/Talos/~3/OVRG-ZW_vgo/firepower-encrypted-rdp-detection.html