Microsoft issued patches yesterday for CVE-2019-0708, a remote-code-execution vulnerability in Remote Desktop Services on Windows 7, Windows Server 2008, Windows Server 2008 R2, and the still-in-extended-life Windows XP and Server 2003 (Microsoft Security Advisory and patches, Microsoft blog post by Simon Pope). The flaw is pre-authentication, server-side, and triggers from a single specially-crafted RDP connection. Microsoft has assessed the vulnerability as "wormable" and has taken the unusual step of issuing patches for the out-of-support Windows variants — a step they last took for WannaCry in 2017. The historical analogue is the operative comparison.
The technical content is in the same family as MS17-010 / EternalBlue. Pre-authentication remote code execution via a network protocol that is widely exposed in enterprise estates and that has been the subject of substantial research attention for years. The deployment population — Windows 7 specifically — remains very large in 2019; estimates of internet-reachable RDP endpoints on TCP/3389 from various scanning sources (Shodan, Censys) put the externally-exposed vulnerable population at approximately 950,000 hosts as of this morning, with the internal-network population substantially larger. The patching cadence in the next several weeks is going to be the determining factor for whether a worm-grade event materialises.
The worm-grade question is the part of the analysis that needs particular care. WannaCry materialised four weeks after MS17-010. The conditions that produced WannaCry were the combination of a public-information-loaded population (the patch was issued, the vulnerability characteristics were publicly inferable from the patch diff) and the prior existence of a weaponisable exploit (EternalBlue, in the Shadow Brokers cache) that the worm authors did not have to develop themselves. The BlueKeep equivalent — the question of whether public exploit development will produce a stable, productionisable exploit before patching closes the productive target population — is genuinely uncertain in mid-May. The vulnerability is technically exploitable but the engineering work to produce a stable remote exploit against the specific memory layout of Windows 7's RDP stack is non-trivial. The research community will produce proof-of-concept exploits in the coming weeks; whether one of those reaches the level required for worm-grade weaponisation is the question.
For the customer estates, the action this week and next is the standard patching cycle — accelerated for the BlueKeep CVE on the Windows 7, Server 2008, and out-of-support Windows population. Verify patch deployment, not just patch issuance. Inspect for any RDP-exposed-to-internet hosts and either move them behind VPN or block the exposure; the perimeter inventory cycle should pick those up but the audit is worth running explicitly. Monitor for RDP-related anomalies — the EmilyAI deployment has the relevant detection content for the pre-authentication exploitation pattern that public PoCs are likely to use, although the actual PoCs are not yet available for signature verification.
The wider Windows 7 question. Windows 7 reaches end-of-extended-support in January 2020 — eight months from now. The customer-organisation populations on Windows 7 are, in the cases I am working with, being migrated to Windows 10, but the migrations are not, generally, going to be complete by January. The combination of a high-severity worm-grade vulnerability against Windows 7 in May 2019 and end-of-extended-support in January 2020 produces a pressure that the customer-organisation programmes need to absorb. The customer-organisation conversations this week have included accelerating the Windows 10 migration where possible.
I will return to this if the worm-grade event materialises and to track the patching cadence across the customer estates in any case. Microsoft's choice to issue patches for the out-of-support variants is the right move and is itself a useful signal of the perceived severity.