What Should I Do About BadLock (CVE-2016-2118 & CVE-2016-0128/MS16-047)?
The simple answer: Patch soon.
Despite the hype, which led many to assume a Remote Code Execution (RCE) was involved, this issue requires a Man-int-the-Middle (MITM) attack in order to be successful. With that noted, it is still a serious issue that requires patching.
Overview
Badlock for Samba is referenced by CVE-2016-2118 (SAMR and LSA man in the middle attacks possible) and for Windows by CVE-2016-0128 / MS16-047 (Windows SAM and LSAD Downgrade Vulnerability).
http://www.badlock.org
According to badlock.org, the name “badlock” doesn’t really mean anything.
The issue relates to old protocols (Security Account Manager Remote Protocol aka MS-SAMR & Local Security Authority (Domain Policy) Remote Protocol aka MS-LSAD, both of which leverage RPC) which use Server Message Block, SMB, (the issue was discovered by a member of the Samba team) and the fact that the initiator controls the communication channel’s security (which is why SMB signing/encryption don’t seem to mitigate the issue). SMB is used for file sharing, printer sharing, and a host of other core Windows communication between clients and servers. While SMB is related to the exploitation of this vulnerability, Microsoft has stated: “Only applications and products that use the SAM or LSAD remote protocols are affected by this issue. The SMB protocol is not vulnerable.”
In order to exploit the issue, an attacker has to get the user (preferably using admin credentials) to connect to a computer the attacker controls instead of the desired target system which the attacker proxies access to (in other words, a “Man-in-the-Middle” attack). The typical MITM attack requires the ability to ARP spoof, or modify DNS to point to the attackers system, or control a shared connection such as WIFI. If the attacker can MITM an admin while connecting to a sensitive system (Domain Controller, HR/finance database, file share appliance, etc), it is possible the attacker could gain access to all usernames and passwords stored on that system.
This vulnerability can be leveraged to perform a Denial of Service (DoS) against a system.

Graphic & quote below from http://www.heise.de/ct/artikel/Badlock-Why-the-Windows-and-Samba-Vulnerability-is-Important-3175176.html
It turned out that Samba’s implementation of MSRPC services will exhibit several defects when it is confronted with mass amounts of malformed data; a process that is known as “fuzzing”. This isn’t limited to crashes and excessive CPU load. A close look revealed that a secured and encrypted connection with authentication had turned into an insecure one. Stefan Metzmacher now tried to figure out why. He discovered that current versions of Windows Server exhibit the same behaviour. They answer RPC requests that manipulate or request sensitive data, even if the connection is neither signed nor encrypted. The vulnerability affects the user login interface Local Security Authority (LSA) and the user management component Security Account Manager (SAM).
Manipulating RPCs
During typical usage, such insecure connections do not happen. Clients and server try very hard to only send data over secure connections, but Samba and Windows servers both may be tricked to deviate from this behaviour. As far as we know one only needs a Windows client system that is part of an Active Directory domain. When an administrator logs in on such a system, it sends several standard RPC requests to the domain controller. If a man-in-the-middle intercepts such a connection, he can change harmless name resolutions into requests to LSA or SAM(R) and remove the request to encrypt the connection which the client includes when initiating it. Similar attacks are possible when an admin introduces a new domain controller to an Active Directory.
The attack depends on the way that RPCs take to reach the server. They can arrive wrapped in authenticated SMB connections that are secured by SMB’s intergrity checks and encryption – those can’t be manipulated. But RPCs can also arrive without an SMB layer directly over a TCP connection. Data that arrives in such a way initially isn’t checked for integrity and it’s also unencrypted. With RPC via TCP, client and server are also required to handle authentication. The very first RPCs that Windows sends when a user logs on to a domain are handled over TCP. The client first asks the RPC Endpoint Mapper which TCP port it should use to contact its target to initiate a connection via the Microsoft Directory Replication Service (DRSUAPI). The client then uses that port to send RPCs, including authentication data.
Since this vulnerability exists in Samba and Windows, it’s a bit tricky unraveling the exploit potential for each one separately (and when samba is used in an Active Directory environment). Treat this as a serious issue and patch all systems.
Note: Microsoft Windows XP/2003 is unsupported and there is no patch for it. Yet another good reason to move to an OS that isn’t a decade old.
Continue reading