[This was originally published on the RBS Blog.].
Word circulated earlier today that Badlock would be revealed at 1PM EST, which is curious given that Microsoft’s “Patch Tuesday” releases are not always public by that time. Almost ten minutes before 1PM, word of the patches being public were making the rounds.
The three patches and associated bug reports weren’t much help, as Samba’s site stopped responding quickly, presumably due to the high number of requests. The badlock.org site was updated and finally gave us some of the details:
Despite all the pre-disclosure hype, and ‘coordination’ for fixing the issues, these CVEs do not appear in Microsoft’s advisories, and offer no explanation as to why. Looking at Microsoft’s release, MS16-047 appears to cover Badlock on their side. However, their advisory makes no mention of that name, and uses a different CVE. The description on the Badlock site suggests these may be protocol flaws, the MS bulletin suggests implementation issues, and the Samba site for all the news still isn’t responding. Amusingly, when the Samba news update loaded, it too made no mention of ‘badlock’ in it.
RedHat’s advisory for Badlock offers more clarity on the issue than Microsoft or Samba, and strongly suggests these are protocol flaws, saying it “affects all applications implementing [the DCE/RPC-based SAMR and LSA protocols], including Samba, and Microsoft Windows.”
Using a combination of all the advisories, we can piece together the picture that this appears to be a vulnerability in the Security Account Manager (SAM) and Local Security Authority (Domain Policy) (LSAD) protocols, that allows a man-in-the-middle attacker to downgrade the authentication levels, leading to the ability to remotely manipulate the SAM database to gain privileges. Going back to Johannes Loxen’s deleted Tweet from March 23, the “admin accounts for everyone on the same LAN” suggested a remote attack, but it can just as easily speak to the man-in-the-middle requirement. While we were generally right about it being a protocol flaw, we bought into the hype and figured it was remote, not man-in-the-middle. Some are now referring to it as ‘Sadlock’ after the disappointing disclosure.
With a month or more of coordination to plan the fixes and subsequent disclosure, this emphasizes how naming vulnerabilities and ‘awareness’ can be more problematic than disclosing through a more routine process. What was assumed to be a remote code execution vulnerability due to the hype ultimately boiled down to a man-in-the-middle issue that requires privileged network position and intercepting a client’s communication to the server that has sufficient privileges. While this is certainly serious in the context of someone within your organization, this is far from the hype that we saw in the weeks prior. A CVSSv3 score of 7.1 is barely ‘High’ risk, and the temporal score drops it to a ‘Medium’ risk.
Perhaps the biggest take-away, is the one that increasingly gets discussed after each named vulnerability. Is the pre-disclosure hype really helping anything? In this case, did administrators need three weeks of waiting and hand-wringing for what sounded like a critical organization-ending remote vulnerability, only to install Microsoft patches (like usual) and update Samba (not usual)? Warning administrators via a Samba news post that a security fix was coming that addressed eight issues, at least one ‘high’ risk, would have achieved the same result. Many in our industry are calling for an end to named vulnerabilities, challenging their worth. Based on the previous 141 named vulnerabilities, yes that many, it is difficult to argue that most of them are providing any value.
Since March 22, when Badlock was announced, there have been 227 vulnerabilities disclosed with a CVSSv2 score higher than that of Badlock, 63 of which carry a 10.0 score. One has to wonder how many of those were lost in the hype and noise created by Badlock?
Leave a Reply