Microsoft Patch Tuesday
On Tuesday, June 9, Microsoft released fixes for 129 security issues in multiple products. This is the fourth month in a row that Microsoft has fixed more than 100 vulnerabilities in its scheduled security updates. The patches include a fix for a critical remote code execution vulnerability in the Server Message Block (SMB) v1 protocol. Microsoft also released fixes for two other vulnerabilities in SMBv3.
In the current environment, two important points: (1) The NewsBites item last week about Rapid7 discovering over 80% of Microsoft Exchange servers had not installed a February critical patch indicates that IT operations may not be focusing on server patching while IT staff is working from home, and (2) Employees working at home from their own PCs should be reminded to make sure auto update is on and that these mega-patch releases are being successfully installed.
Microsoft moved away from SMBv1 and introduced SMBv2 to reduce some of the attack surface created by many no-longer-used legacy features. In SMBv3, Microsoft started adding features like compression but apparently didnt learn from past mistakes and ended up with now three vulnerabilities that can be devastating if combined. In the end, the old rule still applies: Never allow SMB to pass your perimeter, and closely monitor SMB traffic internally. In March, we had SMBGhost (CVE-2020-0796). SMBGhost is a remote code execution vulnerability, but it is difficult to exploit, and it took until May for a working PoC exploit to be released publicly. This month, Microsoft patched another vulnerability in the exact same feature of SMBv3. SMBleed (CVE-2020-1206) sounds less severe at first, only allowing for information disclosure. But the information disclosed is Kernel memory, and paired with SMBGhost for privilege escalation, SMBleed can lead to devastating attacks. And finally, yes, we got another RCE in SMBv1 (SMBLost, CVE-2020-1301). But SMBv1 should have been disabled a long time ago.
On the heels of making sure the patch for SBMGhost was applied, MS releases added SMB fixes. While SMB is contained within the traditional corporate perimeter, the current work environment may not be as well contained, so timely patching is essential. As John reminds us, our environment is further complicated by personally owned systems which also need to be kept updated. Where possible, incorporate patch checking into your VPN posture check. Be sure to let users know the enforcement timeline and expectations around attempted use of an unpatched system.
For the moment and for most enterprises "patching" remains mandatory; failing to do so not only puts one at risk but puts one's neighbors at risk. At what point do we decide that the cost of patching is too high? When do we realize that the attack surface of these widely used products is so big, so homogenous, and so porous, that collectively they weaken the entire infrastructure? When do we realize that the architectures (e.g., von Neumann), languages, and development processes that we are using are fundamentally flawed? That hiding these products behind local firewalls and end-to-end application layer encryption is a more efficient strategy? When do we acknowledge that we must fundamentally reform how we build, buy, pay for, and use both hardware and software? At what point do we admit that we cannot patch our way to security?
William Hugh Murray
Read more in
KrebsOnSecurity: Microsoft Patch Tuesday, June 2020 Edition