Share
Microsoft published seven new Windows vulnerabilities sourcing, again, in the Remote Desktop Protocol (RDP).
Like the name hints, DejaBlue, similarly to BlueKeep has the potential to create a worm that my infect millions of PCs, leveraging an RDP vulnerability. One of the differences between the two worms is that while BlueKeep affects Windows 7 PCs and earlier, DejaBlue affects also everything after as well. In addition, it seems like DejaBlue may be easier to exploit than BlueKeep.
DejaBlue is actually a group of four new RDP vulnerabilities:
-
CVE-2019-1181 & CVE-2019-1182 influencing Windows versions:
- Windows 10 Version 1607.
- Windows 10 Version 1703.
- Windows 10 Version 1709.
- Windows 10 Version 1803.
- Windows 10 Version 1809.
- Windows 10 Version 1903.
- Windows 7.
- Windows 8.1.
- Windows RT 8.1.
- Windows Server 2008 R2.
- Windows Server 2012 (incl. Server Core installation).
- Windows Server 2012 R2 (incl. Server Core installation).
- Windows Server 2016 (incl. Server Core installation).
- Windows Server 2019 (incl. Server Core installation).
- Windows Server, version 1803 (Server Core installation).
-
CVE-2019-1222 & CVE-2019-1226 influencing Windows versions:
- Windows 10 Version 1803.
- Windows 10 Version 1809.
- Windows 10 Version 1903.
- Windows Server 2019 (incl. Server Core installation).
- Windows Server, version 1803 (Server Core installation).
- Windows Server, version 1903 (Server Core installation).
All four CVEs were given a critical severity code of 9.8, and are believed to affect somewhere around 1 million machines.
The DejaBlue vulnerabilities are in the early stages of the RDP connection. The flaws precede the authentication phase, thereby there is no need for passwords of keys to breach the system and eventually can lead to remote code execution.
In addition, CVE-2019-1181 and CVE-2019-1182 have the potential of being ‘wormable’, spreading inside the network, crossing between different internal networks and moving between internal and external networks. This, of course, adds another dimension of severity to DejaBlue.
Mitigation:
Besides obviously applying the latest patches published by Windows, there are two key components that can mitigate this vulnerability:
- Network Level Authentication (NLA)- enable NLA on systems with enabled RDP. This will enforce the connection user to authenticate himself before the session is established with the server.
- The RDP itself- utilized RDP gateways on the patched workstations to hold and authenticate requests for RDP sessions before external users are passed to your internal network.
** if you’re not using RDP, configure your firewall to block inbound TCP port 3389 traffic.
But the most basic mitigation step might be the most complex one:
Disable RDPs where they are not required. As simple as that! But is it?
Controlling configurations in your entire production environment is a pain. Deciding the right policy and then enforcing it may lead to outages and severe harm to production. In order to deal with the complexity in enforcing a secured configuration policy, expensive and time-consuming lab testing needs to be performed. That often leads to a permissive security policy, such as enabling RDPs when not requires and enlarging the attack surface.
CHS by CalCom will automate the entire process for you, eliminating your concern for production outages. With CHS there’s no need for lab testing, and strict security policies can be easily and automatically implemented on the production environment.
https://mobilesyrup.com/2019/08/14/microsoft-windows-security-vulnerability-dejablue/
