Bad Luck Over The Upcoming Badlock Vulnerability?

The Beginning (March 22)
Badlock: The Day After (March 23)
All Quiet on the Disclosure Front (April 5)
The Day of Reckoning (April 12)

badlock

The Beginning (March 22)

It has only been twenty-one days after the last named vulnerability (DROWN), and now we have the next one! Early on March 22nd, the security industry started hearing rumors of ‘Badlock’ and then the site announcing it began making the rounds. The domain was registered by Johannes Loxen out of Germany on March 11, 2016, to announce “a crucial security bug in Windows and Samba” that will be disclosed on April 12, 2016. Given that April 12 falls on the next Microsoft Patch Tuesday, we can probably assume that will begin the standard race between patching computers and bad guys writing exploits to take advantage of administrators that are slow to update. The web site also warns they are “pretty sure that there will be exploits soon after we publish all relevant information.” To us, that sounds like the issue will be remote code execution, and the update to their web site on the 12th will make it trivial for any exploit writer to come up with reliable code to do so.

It should be no surprise to anyone that Microsoft has a long history of vulnerabilities (over 3,200 across 489 products lifetime, with a 7.38 CVSSv2 average score according to VulnDB). Samba on the other hand, is well-known in IT circles but may be unfamiliar to many consumers. The software acts as file and print services for any client using the SMB/CIFS protocol, which includes Windows and Linux. Historically, there are only 114 published vulnerabilities in Samba, despite enjoying considerable deployment in corporate environments. Samba’s web site has updated their news also warning users that “a crucial security bug in Windows and Samba will be disclosed“, making this vulnerability interesting to many. With both vendors apparently offering patches, it suggests the vulnerability is either within the integration between the two vendors, the separate implementations by each vendor, or in the SMB/CIFS protocol itself (we’re betting on the latter).

As with most named vulnerabilities (that have a logo, website, and apparent marketing campaign), a certain level of drama tends to come with them, despite being the tiniest fraction of vulnerabilities disclosed every year. Badlock is no exception (even without an apparent acronym), and this is just the first day we are hearing of it, with 20 days before the discovering researchers disclose it.

badlock-sprog

We emphasize the word ‘discovering’ because named vulnerabilities announced pre-disclosure with some level of media fanfare taunt the hacker mindset, both good and bad. There is heavy debate as to if this is a good or bad thing for defenders. Just knowing the vulnerability affects Windows and Samba starts to narrow down where the issue is. We know it is almost assuredly remote, and likely has to do with the implementation of the SMB/CIFS protocol. With thousands of talented exploit developers out there, the odds of someone finding the same issue, or one equally serious, is considerable. Noted security researcher David Litchfield puts the odds of details leaking or being independently discovered at 15:1.

badlock-litchfield

Litchfield goes on to speculate what the vulnerability may be based on the name and a quick evaluation. We should note that the string ‘lock’ appears in over 40 file names within the current Samba distribution! However, we do not think that would hinder an experienced researcher from potentially finding the vulnerability, but it may slow them down an extra few hours. Again, compared to the 20 days before disclosure, that is barely a speed bump in the big picture. With 20 days to go, and the promise of a remote code execution vulnerability in Windows and Samba, you can be assured that criminal hackers are looking for it too. This is the routine part of pre-disclosures, not the drama!

For Badlock, the first day of poking around the Samba source code came up with a very interesting tidbit. As Wojciech Pawlikowski points out, Badlock was discovered by Stefan Metzmacher, and his name appears somewhere else interesting:

badlock-wpawlikowski

While this is merely speculation at this point, it cannot be ignored. The name Badlock is likely based on a file or resource locking mechanism within the SMB implementation, and the code that controls it. But that one file and one copyright from 10 years ago is not necessarily damning. Taking a quick look at the extensive source code of Samba, Stefan Metzmacher’s name appears in 463 files, with the copyright ranging from 2002 until 2014. It is clear that he has been seriously involved in Samba development for over a decade, and likely knows the software better than almost anyone else. If there is any question of that, look to the German-based company SerNet who just today posted an article about the upcoming Badlock vulnerability. They call Metzmacher “a renowned member of the international Samba core developer team” which can be verified on the Samba Team page where he and four others from SerNet are listed (out of the six total at SerNet, including Loxen who registered the Badlock domain). SerNet advertises itself as having two USPs (unique selling points): SAMBA and verinice. Their Samba service page goes on to say that by choosing them, you “get the best Samba support out there. We offer support, consulting, training and coding around Samba. Worldwide. 24/7.” It is certainly eye opening when someone develops a piece of software for over a decade, then finds a critical vulnerability in it a couple years after their name starts disappearing from soure code copyright, and will most likely capitalize on it directly. As Gabor Szathmari quips:

badlock-gszathmari

Chris Nickerson goes on to summarize, “Wait wait… So #Badlock was found by the dude who wrote the code and camped on his own vuln till he could get paid? #Gangsta“.

At this point, it certainly seems that way and it appears we will need to wait until April 12, 2016 for more details… assuming details aren’t leaked, or the vulnerability isn’t discovered and disclosed in the meantime.

Badlock: The Day After (March 23)

Late last night, Steve Ragan published an article on the CSO Salted Hash blog titled “Company behind the Badlock disclosure says pre-patch hype is good for business“, immediately taking SerNet to task over their handling of the disclosure so far. One of the more telling parts of his article came during a conversation between Sean Sposito and Johannes Loxen, who registered the Badlock domain, in which Loxen said something about the vulnerability and then promptly deleted the Tweet:

badlock-jloxen1

Loxen’s comment appears to confirm that the vulnerability will allow a remote attacker to gain administrative access to the targeted host. Along with other clues, odds are still high that the issue will be independently discovered, potentially leading to serious headache for administrators. That leads into another interesting point that should be considered. While we know that Samba and Microsoft will be issuing patches in the coming weeks, we are also pretty confident that this is a flaw in the SMB/CIFS protocol, or in their implementation of it. If these two vendors implemented the protocol in a fashion that led to this issue affecting them, it is reasonable to assume that any other vendor implementing the protocol may do the same. That prompted us to dig around for other vendors and products that use it. Fortunately for us, Wikipedia made this very easy as it has a list of such vendors and products. Other software and vendors of note that may be impacted by Badlock, and who may find themselves scrambling when the details are published as they were not part of the pre-disclosure, include the Linux Kernel, FreeBSD, NetBSD (used heavily in integrated devices), Mac OS X, Solaris, Novell Netware, FreeNAS, VERITAS, EMC, and NetApp. If these vendors are in fact impacted, without the same heads-up that Microsoft received, users of these products may be at increased risk when details are published and there are no patches available.

At present, the Samba web site still has the same brief blurb saying the information is coming, but no official statement regarding Metzmacher, Loxen, and SerNet’s involvement and handling of what is becoming a fiasco. We’re sure several journalists have reached out to Samba for a statement, but without an obvious single person as a designated leader, a statement may take a while to appear. More interesting is if the six Samba core developers that are part of SerNet will have their input into the process. Meanwhile, researchers are still pointing out interesting bits in the Samba code and further speculating on the vulnerability as more information becomes available. This speaks to a problem in the open source model, where some form of liability is difficult to place. For Samba, it comes in the form of so many core developers and no apparent unified voice that has a name. For libraries and smaller packages, sometimes finding an email contact or the official vendor page is near impossible.

badlock-litchfield1

Earlier today, Jake Williams posted his thoughts on Badlock, dubbing the ordeal a “douche disclosure” instead of the more friendly full disclosure, responsible disclosure or coordinated disclosure. He goes on to take exception with conspiracy theories that Metzmacher deliberately introduced the vulnerable code since this issue also affects Windows, where Metzmacher could not have introduced the code unless it was borrowed by Microsoft. That is absolutely a fair assessment and probably right. However, it does not mean that the vulnerable code wasn’t an accident, and still introduced by Metzmacher or one of the SerNet / Samba core developers.

The one thing most can agree on, is that the style of pre-disclosure taken by Metzmacher et al is not benefiting anyone but themselves and the company they work for. This isn’t a case where naming the vulnerability will help ‘force the vendor to patch’, since they are clear the patch is already in the works and coming soonish. While a researcher or company may want to capitalize on their efforts in finding the bug, that can be done much closer to the patch (including naming the vulnerability) being released to minimize the window of independent discovery. As it stands, even though this issues has gained a lot of exposure, Badlock has done nothing but put all organizations using SMB/CIFS at potential risk should the issue be figured out by criminal hackers, or a researcher who opts to share the details with the world.

All Quiet on the Disclosure Front (April 5)

With a week to go before the hyped Badlock vulnerability gets disclosed (with patches finalyl!), it has been mostly quiet as far as any further detail or insight. In the fourteen days since it was first announced, MITRE has still not seen fit to issue a CVE identifier for the vulnerability despite the widespread attention after it hit the news. But, that isn’t too surprising given the lack of detail about the vulnerability and that they have also taken months to respond to researchers requesting a CVE ID, sometimes only to say “no” to the assignment over 100 days later.

Since the initial flurry of media attention, system administrators and security staff have had nothing more to go on and therefore nothing actionable to be done to protect their organizations. Just the vague threat of a remote attack that can be leveraged for administrative access.

Meanwhile, some security researchers continue to poke around the Samba code looking for clues.

litchfield-badblock-mar

For computer criminals, notoriously ahead of the defensive crowd, it is hard to say what has occurred in this quiet period of time. While there has been no detection of a new attack against Samba installations, which would suggest that bad guys have figured it out, that possibility still can’t be ruled out. Since a majority of security detection is based on signatures of known attacks, we cannot assume that organizations would have yet detected such an exploit. This is especially true if attackers were using it very strategically to compromise specific targets, rather than using it against large portions of the Internet.

Meanwhile, since the initial Badlock disclosure, 42 vulnerabilities have been disclosed with a CVSSv2 score of 10.0. Not one of them have been named, have their own web site, or generated a flood of news articles. Worse, 10 were remote and had a public exploit available, re-opening the debate as to if naming a vulnerability really helps organization focus on the issues that need attention. Those organizations struggling to keep up, debating if the named vulnerability should warrant more priority? Remember that only one of those exploitable remote vulnerabilities had a CVE identifier, and that one was RESERVED as usual. Fortunately for your organization, it was only in an Apache product.

Until something concrete happens, or next Tuesday comes, we’ll all continue to wait and watch and at RBS we will continue to track all of the other vulnerability activity.

The Day of Reckoning (April 12)

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.

badlock-whiskeyneon

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:

badlock-update

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?