The Evolution of RDP
RDP is a pretty common protocol, and has been and is still the default way to have remote access to an Windows enviroment and has been a core part of the operating system for many years. RDP as a protocol is based on, and is an extension of, the T-120 family of protocol standards. A multichannel capable protocol allows for separate virtual channels for carrying presentation data, serial device communication, licensing information, highly encrypted data (keyboard, mouse activity), and so on. As RDP is an extension of the core T.Share protocol, several other capabilities are retained as part of the RDP, such as the architectural features necessary to support multipoint (multiparty sessions).
One reason that Microsoft decided to implement RDP for connectivity purposes within the old Windows NT Terminal Server was to provide a extensible base from which to build many more capabilities. This is because RDP provides 64,000 separate channels for data transmission.
RDP as a protocol has also evolved and has a pretty advanced connection sequence now in the latest iteration, which has taken a huge leap since the old NT days. With now the latest iteration has now support for advanced GPU sharing functionality.
RDP now has new options when it comes to how it handles user authentication with new mechanisms such as Windows Defender Remote Credential Guard and Restricted Admin, but I will get back on that.
Of course many are also using it for remote access and leaving it published directly out to the internet, which of course makes it an attractive target for many. Consider the following: you have an RDP endpoint publically available which has direct access to the rest of your infrastructure what if someone managed to gain access to it?
A Quick scan from Shodan.IO against port 3389 shows some endpoints available, and these are not all where most of the endpoints are based upon servers running in Google Cloud, Azure and Amazon.
Now an issue is that RDP out of the box, even if it provides an encrypted connection it does not provide any mechanism to handle multi-factor authentication. Microsoft has added a lot of enhancements to the protocol such as NLA with newer operatingsystems, but still it leaves wide open can open up to password spray attacks and therefore it can also do Denial-of-service attacks against legitimate users. Especially with the combination of password policies where people get locked out of Active Directory for X amount of minutes after failed X logon attempts.
RDP Bluekeep and the new one
A couple of weeks ago, we got the info about RDP Bluekeep, an RDP vulnerability which can allow remote access to an virtual machine running RDP without NLA (Network Level Authentication) By sending a specially crafted data packet that RDP does not understand, the attacker is able to cause memory corruption and remotely execute code with the NT Authority/Systemuser access level.
BlueKeep vulnerability in RDS (remote desktop services) affects Windows 7 SP1, Windows Server 2003, Windows XP, Windows Server 2008 and Windows Server 2008 R2. This may affect all of the service packs for a system, for example, both Windows 7 and Windows 7 SP1, but Microsoft is providing patches only for the latest service packs. You can also read more about the vulnerability here –> https://wazehell.io/2019/05/22/cve-2019-0708-technical-analysis-rdp-rce/
You can also read more here at Niall Brady’s blog https://www.niallbrady.com/2019/06/08/multiple-warnings-about-the-bluekeep-vulnerability-from-many-vendors-including-the-nsa/
Now it seems there is also exploits against the vulnerability coming into the wild as well, which shows that the endpoints may now get attacked.
Some others have also created an exploit which can trigger an remote BSOD –> https://blog.51cto.com/13694685/2405362
Microsoft has released hotfixes for all the versions of Windows affected by BlueKeep including Windows XP. For downloading the individual patches for your version of Windows, you can visit :
- For Windows 7 SP1 and Windows Server 2008 : https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708.
- For Windows XP and Windows Server 2003 : https://support.microsoft.com/en-in/help/4500331/windows-update-kb4500331
As of now, many are reporting that as many as 1 million endpoints that can be affected which are publically available. The fix here is of course to patch your endpoint and secondly do not leave it directly available.
Then last week another RDP vurneability came out as well, or as Microsoft calls it “by design”
Starting with Windows 10 1803 (released in April 2018) and Windows Server 2019, the handling of RDP sessions has changed in a way that can cause unexpected behavior with respect to session locking. If a network anomaly triggers a temporary RDP disconnect, upon Automatic Reconnection the RDP session will be restored to an unlocked state, regardless of how the remote system was left. It is important to note that this feature can only be triggered from the endpoint that was connected to the remote system.
From Microsoft documentation
“After a successful log on, the server sends the client an “auto-reconnect cookie” in the Save Session Info PDU. This cookie is bound to the current user’s session and is stored by the client. In the case of a disconnection due to a network error, the client can try to automatically reconnect to the server. If it can connect, it sends a cryptographically modified version of the cookie to the server in the Client Info PDU (the Secure Settings Exchange phase of the connection sequence, as specified in section 1.3.1.1). The server uses the modified cookie to confirm that the client requesting auto-reconnection is the last client that was connected to the session. If this check passes, then the client is automatically connected to the desired session upon completion of the connection sequence. The auto-reconnect cookie associated with a given session is flushed and regenerated whenever a client connects to the session or the session is reset. This ensures that if a different client connects to the session, then any previous clients that were connected can no longer use the auto-reconnect mechanism to connect. Furthermore, the server invalidates and updates the cookie at hourly intervals, sending the new cookie to the client in the Save Session Info PDU”
Now this “exploit” is also possible on remote endpoints where you might have MFA already and have NLA enabled. To secure against it you essentially need to ensure that end-users don’t use “lock” feature in the remote session which can be easily disabled using Group Policy or using Registry as defined here –> https://www.windowscentral.com/how-disable-windows-10-lock-screen
Or you can disable the automatic reconnection feature using Group Policy. Local Computer -> Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Connections -> Automatic reconnection
It should be noted that this vulnerability is only possible from the same endpoint which you trigger the lock from. So an attacker would need to have physical access to the device which is using RDP to connect to an endpoint to actually trigger the exploit.
How can we secure RDP?
Since RDP used in a lot of large organizations and not just regular endpoints but also using the full RDS stack where you have RDS Gateways and web access, how can we take measures to ensure a highly secure RDS solution? Here are some pointers.
- Ensure that RDP Network Level Authentication is enabled
- Do not publish RDP directly to the internet, put it behind an RDS solution in combination with Gateway.
- Define groups on how can actually logon using Remote Desktop Services (This is defined in a session collection or using Group Policy)
- Define a account lockout policy (By setting your computer to lock an account for a set number of incorrect guesses, you will help prevent hackers from using automated password guessing tools from gaining access to your system –> Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.
- Ensure a good password policy, having long passwords ensure that it doesn’t make it so easy to guess the password of end-users, and if someone is using password spray attacks it makes it even more difficult.
- Deploy RDP using the RDS stack in combination with RDS Gateway and Web Access. This adds an extra level of complexity but it allows us to add MFA solutions on top of RDS Gateway (Such as this, which shows integration of RDS with Azure MFA for MFA authenticaiton –> https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-rdg)
- Publish RDS using Azure AD Application Proxy –> https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-integrate-with-remote-desktop-services this allows us to provide Conditional Access and MFA in front of an RDS Solution and therefore reducing the attack surface.
- Define Client Encryption levels and set them to High –> (This ensures that Clients that do not support this level of encryption will not be able to connect.. This level when the RD Session Host server is running in an environment containing 128-bit clients only (such as Remote Desktop Connection clients, and makes it harder for automated attacks running other operatingsystems.
- Ensure that only the RDS ports are open regular RDP, 443 and 3391 (443 TCP/ 3391 UDP) for deployments using RDS in combination with RDS Gateway. Microsoft uses UDP for multimedia traffic and TCP for control mechanisms.
- For management purposes, use Windows Defender Remote Credential Guard or restricted admin mode, this ensures that credentials are not left on the remote host, which in case can leave it open for pass-the-hash attacks for instance. You can read more about those options here –> https://docs.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard
- Monitor for event ID’s for EventID 4776, 4625, 4624 on RDP / RDS Servers / VDI. A High number of 4625 Event Id’s on your machines might indicate that some attackers are trying to get into it.
- If using Azure, combine it with Just-in-time access using Azure Security Center –> https://docs.microsoft.com/en-us/azure/security-center/security-center-just-in-time