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.
Patch Availability (as of 4/13/2016):
At least one person is tracking the available patches for this issue.
Here’s an excerpt from that page with the systems that have patches as of when this post went live. I’m not updating this table beyond the original posting, so please visit here for updates.
ORGANIZATION | NOTIFICATION | PATCHES AVAILABLE |
---|---|---|
Red Hat | RH Notice | Yes |
Microsoft | MS16-047 | Yes |
Samba | Samba Security Releases | Yes |
Debian | Vuln Page | Yes |
Novell (Suse) | Bug Page | Yes |
FreeBSD Ports | samba4.3, samba4.2, samba3.6 | Yes |
Patch table from https://mwguy.us/?p=151
Microsoft Windows (MS16-047 / KB3149090):
The vulnerability in Microsoft Windows could allow elevation of privilege if an attacker launches a man-in-the-middle (MiTM) attack. An attacker could then force a downgrade of the authentication level of the SAM and LSAD channels and impersonate an authenticated user.
All currently supported versions of Windows are vulnerable (as well as the Windows 2016 Technical Previews).
Microsoft describes the vulnerability:
An elevation of privilege vulnerability exists in the Security Account Manager (SAM) and Local Security Authority (Domain Policy) (LSAD) remote protocols when they accept authentication levels that do not protect them adequately. The vulnerability is caused by the way the SAM and LSAD remote protocols establish the Remote Procedure Call (RPC) channel. An attacker who successfully exploited this vulnerability could gain access to the SAM database.
To exploit the vulnerability, an attacker could launch a man-in-the-middle (MiTM) attack, force a downgrade of the authentication level of the SAM and LSAD channels, and then impersonate an authenticated user. The security update addresses the vulnerability by modifying how the SAM and LSAD remote protocols handle authentication levels.
Microsoft notes there are no workarounds or mitigations, so patch your systems to resolve.
General advice:
Patch all affected systems soon, starting with Domain Controllers and critical systems, but you don’t likely have to patch ASAP (within 24 hours) since on a corporate network, a Man-In-The-Middle attack is non-trivial to pull off (though the risk is higher on wireless due to the shared nature of the communication). Microsoft categorizes this issue as “Important” which means you should patch, but since it’s not listed as “critical” this doesn’t necessarily have to be a “patch in the next 24 hours” type issue (like MS14-068 was).
Jake Williams (@MalwareJake) has some great advice on additional security actions (in addition to patching):
What should I do (besides patch)?
1. Disable SMBv1. It’s a relic and doesn’t need to be a thing anymore. If you still have it in your network and need it, determine what architectural changes are needed.2. Enable SMB signing and enforce it for all machines where it makes sense. Microsoft has been recommending this to prevent SMB relay attacks for years. You can read all about it here.
3. Enable port security on your network switches – this makes ARP spoofing nearly impossible. Helpdesk hates it, but it does improve your security in a measurable way.
4. MITM is easier on wireless in the corporate environment than it is on the wired network. Make sure the attacker can’t get on your wireless network in the first place to ensure maximum security. WPA2 Enterprise goes a long way here.
Samba on *NIX:
Samba.org has a great write-up on the vulnerability:
Description
The Security Account Manager Remote Protocol [MS-SAMR] and the
Local Security Authority (Domain Policy) Remote Protocol [MS-LSAD]
are both vulnerable to man in the middle attacks. Both are application level
protocols based on the generic DCE 1.1 Remote Procedure Call (DCERPC) protocol.These protocols are typically available on all Windows installations
as well as every Samba server. They are used to maintain
the Security Account Manager Database. This applies to all
roles, e.g. standalone, domain member, domain controller.Any authenticated DCERPC connection a client initiates against a server
can be used by a man in the middle to impersonate the authenticated user
against the SAMR or LSAD service on the server.The client chosen application protocol, auth type (e.g. Kerberos or NTLMSSP)
and auth level (NONE, CONNECT, PKT_INTEGRITY, PKT_PRIVACY) do not matter
in this case. A man in the middle can change auth level to CONNECT
(which means authentication without message protection) and take over
the connection.As a result, a man in the middle is able to get read/write access to the
Security Account Manager Database, which reveals all passwords
and any other potential sensitive information.Samba running as an active directory domain controller is additionally
missing checks to enforce PKT_PRIVACY for the
Directory Replication Service Remote Protocol [MS-DRSR] (drsuapi)
and the BackupKey Remote Protocol [MS-BKRP] (backupkey).
The Domain Name Service Server Management Protocol [MS-DNSP] (dnsserver)
is not enforcing at least PKT_INTEGRITY.New smb.conf option
allow dcerpc auth level connect (G)This option controls whether DCERPC services are allowed to be used with
DCERPC_AUTH_LEVEL_CONNECT, which provides authentication, but no per
message integrity nor privacy protection.Some interfaces like samr, lsarpc and netlogon have a hard-coded default
of no and epmapper, mgmt and rpcecho have a hard-coded default of yes.The behavior can be overwritten per interface name (e.g. lsarpc,
netlogon, samr, srvsvc, winreg, wkssvc …) by using
‘allow dcerpc auth level connect:interface = yes’ as option.This option yields precedence to the implementation specific restrictions.
E.g. the drsuapi and backupkey protocols require DCERPC_AUTH_LEVEL_PRIVACY.
The dnsserver protocol requires DCERPC_AUTH_LEVEL_INTEGRITY.Default: allow dcerpc auth level connect = no
Example: allow dcerpc auth level connect = yes
RedHat adds some additional information on the vulnerability:
Any authenticated DCE/RPC connectionthata client initiates against a server couldbe used by a man-in-the-middleattackerto impersonate the authenticated user against the SAMR or LSA service on the server.As a result,the attackerwould beable to get read/write access to the Security Account Managerdatabase, whichcouldreveal all passwords and any other potentiallysensitive information.
The client-chosen application protocol, authentication type (for example, Kerberos or NTLMSSP), and authentication level (NONE, CONNECT, SIGN, or SEAL) do not matter in this case. A man-in-the-middle attacker could downgrade the authentication level to CONNECT and take over the connection. The Badlock issue is fixed along with a series of CVEs as documented here:
- Important Security flaws in Samba released on 12-April-2016 (CVE-2015-5370, CVE-2016-2110, CVE-2016-2111, CVE-2016-2112, CVE-2016-2113, CVE-2016-2114, CVE-2016-2115, CVE-2016-2116) .
Will encryption protect me against this MITM attack?
The SMB protocol, by default, only encrypts credentials and commands while files are transferred in plain text. It is recommended that in security and privacy sensitive scenarios encryption is used to protect all communications. Encryption was added to Samba in version 3.2, but only for Samba clients. Microsoft added SMB encryption support to SMB 3.0 in Windows 8 and Windows Server 2012. However, both of these types of encryption only protect communications, such a file transfers, after SMB negotiation and commands have been completed. It is this phase that contains the vulnerability highlighted above. Samba/SMB encryption is a good practice but is not sufficient for protection against this vulnerability.
Badlock References:
- RedHat: Badlock: SAMR and LSA protocol man-in-the-middle attack against Samba (CVE-2016-2118)
- Samba.org
- MalwareJake: Badlock: it’s here, now what?
- DarkReading: Badlock Bug Declared A Bust–But Patch, Anyway
- ArsTechnica: Yes, Badlock bug was shamelessly hyped, but the threat is real
- TrendMicro: How Bad is Badlock (CVE-2016-0128/CVE-2016-2118)?
- ZDNet: Badlock: Patch your Samba and Windows server now
SMB Resources:
- The Deprecation of SMB1 – You should be planning to get rid of this old SMB dialect
- SMB3 PowerShell changes in Windows Server 2012 R2: SMB1 can now be completely removed
- Disable SMB versions in Windows
Recent Comments