What is BlueKeep?
Well, the vulnerability isn’t yet publicly disclosed so it’s not exactly clear what the issue is. CVE-2019-0708 explains that there is the potential for unauthenticated remote code execution with no user interaction required. Using a carefully crafted exploit an attacker could “install programs; view, change, or delete data; or create new accounts with full user rights.”
How many machines are vulnerable?
As of May 15th there were over 2.3 million RDP hosts on the public internet that are vulnerable to the exploit. Machines that are running Windows XP, Windows 7, Windows Server 2003, Windows Server 2008 R2, or Windows Server 2008 with Remote Access enabled are vulnerable to the BlueKeep exploit if they have not been patched, or if they do not require the use of Network Level Authentication (NLA). Additionally the exploit is wormable, so one machine exposed to the internet can cause entire corporate networks to be exposed.
How do I protect my machines?
- Update to the latest Windows build available, or manually install the latest patches for machines that are no longer supported by Microsoft.
- Enable NLA to prevent unauthenticated connections on Windows versions that support it
- If RDP access is not required, block TCP port 3389 using a firewall to prevent any RDP connections
RDP allows attackers to bypass the lock screens of remote sessions
Another potential vulnerability was introduced in Windows 10 1803 and Windows Server 2019, and the latest response from Microsoft indicates that this is working as expected, so it will not be fixed. If a user locks their RDP session an attacker can interrupt the network connection of the system and gain access to the RDP desktop session due to a recent change in the automatic reconnection behavior. Certain MFA methods/providers as well as any login banners are able to be bypassed using this method, as well.
The issue is due to a change in NLA, wherein the client’s login credentials are cached on the RDP host in order to quickly reestablish the connection in the case of a connectivity loss. If the RDP session is locked, an attacker can take advantage of this new change to bypass the lock screen simply by interrupting the network connection. When the RDP session is reestablished the attacker will be presented with the user’s desktop on the RDP host. This does require the attacker to have physical access to the RDP client machine, but still the behavior seems concerning.
There are a couple of ways to mitigate this new behavior. The first is to disable the automatic reconnection feature in the Windows Group Policy. You can also advise users to lock the client machine (instead of the host machine) when they leave their machine unattended. The last option is to have users disconnect the RDP session instead of locking it, as disconnecting invalidates the session and will require authentication to reconnect.