Preparing for the Badlock Windows/Samba Vulnerability

Something exploitable this way comes. It appears that a new high impact vulnerability is set to be unleashed upon the cyber world on April 12th.  Of course no high impact vulnerability would not be complete without its own logo and website at The vulnerability affects Windows and Samba and from the researchers who discovered the exploit “We are pretty sure that there will be exploits soon after we publish all relevant information.”

The vulnerability was discovered by Stefan Metzmacher who is a member of the international Samba Core Team and works at SerNet on Samba. He reported the bug to Microsoft and has been working closely with them to fix the problem. As mentioned on the website a patch will be made available on April 12th and all sysadmins should “get yourself ready to patch all systems on this day.”

Without knowing more about the specific vulnerability yet, there are some things organizations can do to mitigate risk, even if the vulnerability is much ado about nothing. We know a storm is coming, but are not quite sure how strong.However, just like when a hurricane is about to hit, there are things you should do to prepare. We know the day the patch will be released and vulnerability exposed, so security and IT teams may want to plan accordingly in terms of staffing and other resources.

At this point all we know about Badlock is that it affects Windows and Samba, so the obvious culprit is the SMB protocol. The Server Message Block (SMB) Protocol is a network file sharing protocol, and as implemented in Microsoft Windows is known as Microsoft SMB Protocol. In the OSI networking model, Microsoft SMB Protocol is most often used as an Application layer or a Presentation layer protocol, and it relies on lower-level protocols for transport. The Common Internet File System (CIFS) Protocol is a dialect of SMB. Both SMB and CIFS are also available on VMS, several versions of Unix, and other operating systems. So as this affects both Windows and Linux the impact can be substantial and will not be limited to traditional operating systems, but also network appliances and even potentially IoT devices (medical, industrial etc).

Runnshodaning vulnerability scans from the outside to identify SMB services that may be exposed (e.g. Running on port 135, 139 and 445) might be a good idea to help batten down the hatches. In a worse case scenario the vulnerability may provide Remote Code Execution over SMB which means it could be wormable. Blocking and alerting on egress and ingress from the network via SMB ports (135, 139, and 445) is key. There really is no reason for Internet facing assets to be exposing SMB services, however a quick Shodan search reveals hundreds of thousands of potentially vulnerable systems.

A while back I wrote a whitepaper on mitigating risk associated with high impact vulnerabilities (PDF). The paper provides some guidance with regards to what organizations should be doing before these types of vulnerabilities hits, particularly around taking inventory of hardware and software assets in your environment, as well as incident response.

Nmap provides a script for smb-os-discovery which may be useful. The script attempts to determine the operating system, computer name, domain, workgroup, and current time over the SMB protocol in your environment.

Previous post

Are 'selfies' good for cyber security?

Next post

Confessions of a LinkedIn Imposter: We Are Probably Connected

Ken Westin

Ken Westin

Your Pundit of Paranoia