BlueKeep (CVE-2019-0708): Patch RDP Before Somebody Writes the Worm

Microsoft doesn’t usually open a security blog post by comparing a bug to WannaCry, and it doesn’t usually ship patches for Windows XP. On Tuesday it did both. The Patch Tuesday release included a fix for CVE-2019-0708, a remote code execution vulnerability in Remote Desktop Services, and the nickname BlueKeep has been making the rounds since. Nobody has reported it being exploited yet, and that’s exactly why this week is the time to deal with it.

I’m sticking to what Microsoft and the US government have actually published: the MSRC blog post, the Security Update Guide entry, Microsoft’s customer guidance for older Windows, the NVD entry, and CISA’s notice.

What Microsoft said

The MSRC blog post, written by Simon Pope, MSRC’s Director of Incident Response, and dated May 14, lays it out plainly. The bug is in Remote Desktop Services, the thing that used to be called Terminal Services, and it affects some older versions of Windows. The post is careful to say the Remote Desktop Protocol itself isn’t vulnerable; the problem is in the Windows service that handles it.

What makes it scary is the combination Microsoft calls out: it’s pre-authentication and needs no user interaction. Nobody has to log in, click anything, or open a file. Microsoft’s own word for that is “wormable”, and the post explains what it means in practice: future malware that exploits it could spread from vulnerable computer to vulnerable computer on its own, the way WannaCry did in 2017. Microsoft says it hasn’t observed any exploitation, but it also says it’s highly likely attackers will write an exploit and build it into malware.

The Security Update Guide entry adds a little more. An unauthenticated attacker connects over RDP and sends specially crafted requests, and a successful attacker could run arbitrary code on the target, which Microsoft spells out as installing programs, viewing, changing, or deleting data, or creating new accounts with full user rights. The fix changes how Remote Desktop Services handles connection requests. The guide rates it Critical on every affected product and lists it as neither publicly disclosed nor exploited. The NVD entry, published on May 16, carries the same short description.

I’m deliberately not going into how the bug works. Microsoft hasn’t published those details, and nobody defending a network needs them to act.

Which Windows versions are affected

On the supported side, the blog post names Windows 7, Windows Server 2008 R2, and Windows Server 2008. The Security Update Guide lists Windows 7 SP1, Server 2008 SP2, and Server 2008 R2 SP1, Server Core installations included. For Windows 7 and Server 2008 R2 the fix ships in the May Monthly Rollup (KB4499164) or the Security Only update (KB4499175). For Server 2008 it’s KB4499149 or KB4499180. Microsoft notes that if you’re on a supported version with automatic updates turned on, you’re already protected.

Then there’s the unusual part. Windows XP and Windows Server 2003 are out of support, and Microsoft released fixes for them anyway. Those updates are described in KB4500705, which says they’re available only from the Microsoft Update Catalog and covers XP SP3, XP Professional x64 Edition SP2, XP Embedded SP3, and Server 2003 SP2 in x86 and x64. Microsoft also says the best fix for those machines is upgrading to a current version of Windows, which is fair, but the patch is there for the ones you can’t move this week.

Windows 8 and Windows 10 aren’t affected at all. The blog post says that’s no coincidence and credits architectural security improvements that can’t be backported to older releases. If your fleet is all Windows 10, you can skip this one, though I’d check that against a real inventory first.

Microsoft’s mitigations, and the NLA catch

The Update Guide offers a few things you can do alongside the patch, and every one of them comes with Microsoft telling you to install the update anyway.

The first is Network Level Authentication on Windows 7, Server 2008, and Server 2008 R2. With NLA on, a client has to authenticate before a Remote Desktop session is set up, so an attacker would need a valid account on the target before they could reach the vulnerable code. The blog post calls this a partial mitigation and is specific about why it’s only partial. Because authentication has to happen before the bug can be triggered, NLA protects against wormable malware and advanced malware threats, but a system with NLA turned on is still exploitable by an attacker who has valid credentials. Given how often credentials leak, that’s not a caveat to shrug off. Microsoft’s conclusion is that affected systems should be patched whether NLA is on or not.

The second is blocking TCP port 3389 at the enterprise perimeter firewall. Microsoft calls that the best defense against attacks from the internet, and then points out the obvious limit: machines are still exposed to anything already inside the perimeter. A worm that gets in through one laptop doesn’t care about your edge firewall.

The third is simply turning off Remote Desktop Services where you don’t need it. Fewer running services, fewer ways in.

What the US government said

On May 16, CISA posted a short notice encouraging users and administrators to review Microsoft’s advisory and customer guidance for CVE-2019-0708 and apply the updates. It doesn’t add technical detail, but a vendor and CISA saying patch in the same week is worth forwarding to whoever approves your change windows.

What I’d do about it

Start by finding every machine that actually has RDP turned on. That sounds trivial, but Remote Desktop gets enabled on a server for a one-time fix and then forgotten, or it’s on in a golden image nobody remembers building. The simplest first pass is checking which hosts accept connections on TCP 3389 at all. For machines running Vista or Server 2008 and later, WMI can also tell you whether NLA is required: the Win32_TSGeneralSetting class exposes a UserAuthenticationRequired property, and Microsoft’s docs say connections to its namespace need packet privacy authentication. Something like this, run from an admin workstation with a recent PowerShell against each host, gives you a starting point:

Test-NetConnection -ComputerName $pc -Port 3389 |
  Select-Object ComputerName, TcpTestSucceeded
Get-WmiObject -ComputerName $pc -Namespace root\cimv2\TerminalServices -Class Win32_TSGeneralSetting -Authentication PacketPrivacy |
  Select-Object PSComputerName, TerminalName, UserAuthenticationRequired

That WMI class starts with Vista and Server 2008 according to the docs, so the port check is what will catch XP and Server 2003. Back it up with asset records, your patch management tool, and a conversation with the people who run the factory floor and the lab equipment. Those are often the machines nobody wants to touch, which is exactly why they’re a problem here.

Then patch, and patch the internet facing machines first. On Windows 7 and Server 2008 or 2008 R2 that means the May rollup or the Security Only update named above. On XP and 2003 it means grabbing the KB4500705 updates from the Update Catalog yourself, because they won’t just show up. The Update Guide marks the Windows 7 and Server 2008 updates as needing a restart, so schedule one, and confirm the update is actually installed rather than just approved.

Don’t expose RDP directly to the internet, patched or not. This bug is a good example of why: a service listening on 3389 for the whole world is a service that anyone can send crafted requests to before logging in. If people need remote access, put it behind a VPN or a Remote Desktop Gateway so the thing facing the internet is built for that job and requires authentication first. Block 3389 inbound at the edge, and check your cloud security groups too, since that’s a common place for a wide open RDP rule to hide.

Finally, require NLA everywhere it’s supported. On Server 2008 R2 that’s a checkbox in Remote Desktop Session Host Configuration, as described in Microsoft’s NLA documentation, or with the SetUserAuthenticationRequired method on that WMI class. The docs note that clients need Remote Desktop Connection 6.0 or later and a CredSSP capable OS, so very old clients may stop connecting. That’s a fine trade. Just remember what Microsoft said: NLA narrows who can exploit this, it doesn’t make the machine safe.

Don’t wait for the headline

The thing I keep coming back to is that Microsoft wrote this post before anything bad happened. When WannaCry hit in May 2017, Microsoft’s own guidance pointed out that the fix for the bug it used had shipped back in March. The damage landed on machines that hadn’t taken it. This time Microsoft is saying out loud that it expects an exploit, it’s patching operating systems it no longer supports, and CISA is echoing it. That’s about as clear a warning as you get. Find your RDP hosts, patch them, get 3389 off the internet, and turn on NLA, and do it before someone else’s exploit makes the decision for you.