Chat with us, powered by LiveChat

Dejablue: The Return of BlueKeep

by Daniel Simpson 0 Comments

Late in the spring of 2019 the National Vulnerability Database published CVE-2019-0708, later becoming known as BlueKeep. As many are aware this affected older versions of Windows, Windows 7 and Server 2008 and 2008 R2. This vulnerability was slighted against the RDP protocol, allowing an attacker to have unauthorized access to disclose information, modify files, and cause disruption of service. Microsoft released a patch for this and suggested workarounds, and things were peaceful for a time.

Last month there was a return of RDP vulnerabilities, same premise that affected the Windows 7 and Server 2008 operating systems, however a larger surface was struck when the same service became vulnerable for more current versions of Windows operating systems. On August 13th 2019, Microsoft released additional patches for the new RDP vulnerability that affects newer Windows operating systems and the vulnerability was aptly dubbed DejaBlue.

A small panic rippled through those of us that were still running on older operating systems as support falters and patches come few and far between. Once the industry made it over this summit, the new threat arrived increasing its surface area greatly by affecting Windows 8.1, Windows 10, Server – 2008 R2, 2012 R2, 2016, and 2019. Four CVE’s were published for the vulnerabilities over RDP; CVE-2019-1181, CVE-2019-1182, CVE-2019-1222, and CVE-2019-1226.

So, what does this mean to any organization? In short, someone could send a specially crafted request to a machine with RDP enabled that takes advantage of the vulnerability. This all happens before authentication, so the attacker does not need credentials. This would allow the attacker to install programs, modify data, or even create new accounts in your system with full user rights.

This is not good right? Indeed, it’s very bad. If there is a machine that is facing the Internet, there is already a storm of activity checking Internet presence of RDP enabled machines. If an attacker were able to access the RDP protocol, they could use the vulnerability to leverage a foothold in your infrastructure, modify data, steal data, and create persistence for themselves by creating accounts. Additionally, the ability to move laterally to other machines in the environment is significantly increased. With lateral movement, worms can propagate easily across the entire infrastructure, attackers can find new places and new vulnerabilities to use against the owners.

You can be saved! Microsoft has released patches for this vulnerability. There are also a couple of workarounds that can be done to also help mitigate the use of this vulnerability. At Agio, we cannot stress the importance of vulnerability scanning and remediation. Patching is also very important for the cycle of remediating unintentional vulnerabilities caused by vendors. Sometimes a patch may not be in the cards so the work arounds would suffice until patching may be deployed.

The patches are available at the following locations:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1181
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1182
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1222
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1226

The workarounds available are also listed on the pages above. I’ll call them out here as well:

  • Block TCP port 3389 on the perimeter firewall. It’s used to connect to the affected service and shutting it down will lower the chance that an Internet facing host would fall victim to the RDP vulnerability. If the port has been obfuscated you will need to block the port you used as well.
  • Enable Network Level Authentication (NLA). Turning this on forces the attacker to authenticate first, subverting the vulnerability.

Also, this is a great time to look at a best practice for services. On any given machine, shut down services that are not in use or have no plans of being used; this will decrease the surface area of potential vulnerabilities an attacker would have. In this scenario, if the machines in your organization have no use for RDP, or if a selection of them do not, just turn off the ability for RDP.

It’s been a rough year so far for the RDP protocol. The two vulnerabilities discovered this year were substantial. Thankfully there was a quick response from Microsoft for patches and advice for workarounds. If you have not done any vulnerability scanning in your environment, Agio would strongly urge you to do this to see if you’re susceptible to any of the CVE’s mentioned in this article due to their severity. If you have any questions, we’re here to help!