Badlock: SAMR and LSA protocol man-in-the-middle attack against Samba (CVE-2016-2118)

Red Hat Product Security has been made aware of a protocol flaw in the DCE/RPC-based SAMR and LSA protocols used in the Microsoft Windows Active Directory infrastructure. This issue has been assigned CVE-2016-2118.

Note: This is a protocol issue and affects all applications implementing this protocol, including Samba - CVE-2016-2118, and Microsoft Windows - CVE-2016-0128.

Background Information

DCE/RPC is the specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol. The Security Account Manager (SAM) Remote Protocol (Client-to-Server) provides management functionality for an account store or a directory containing users and groups. The protocol exposes the "account database" for both local and remote Microsoft Active Directory domains. The Local Security Authority (Domain Policy) Remote Protocol is used to manage various machine and domain security policies. This protocol, with minor exceptions, enables remote policy-management scenarios. Both SAMR and LSA protocols are based on the DCE 1.1 RPC protocol.

These protocols are typically available to all Windows installations, as well as every Samba server. They are used to maintain the Security Account Manager database. This applies to all roles (for example, standalone, domain controller, or domain member).

Attack Description and Impact

Any authenticated DCE/RPC connection that a client initiates against a server could be used by a man-in-the-middle attacker to impersonate the authenticated user against the SAMR or LSA service on the server. As a result, the attacker would be able to get read/write access to the Security Account Manager database, which could reveal all passwords and any other potentially sensitive 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.

All versions of Samba packages shipped with Red Hat Enterprise Linux server and Red Hat Gluster Storage are affected by this flaw. Red Hat Product Security has rated this issue as having a security impact of Important.

Affected Configurations

• An Active Directory infrastructure with a Samba server as a domain member is vulnerable to this flaw. A man-in-the-middle attacker could intercept DCE/RPC traffic between the domain member and the domain controller to impersonate the client and get the same privileges as the authenticated user account. The attacker could view or modify secrets within an AD database, including user password hashes, or shutdown critical services.

• Any Samba server configured as a file or print server is also vulnerable to this flaw. The attacker could use the flaw to modify user permissions on files or directories.

Mitigation

Risk can be reduced by not using privileged accounts to access SMB/CIFS services until a package containing a fix has been applied. Restrict administrative access to physical hardware (console, server), so that authentication does not involve any network communication.

Resolution

Acknowledgements

Red Hat would like to thank the Samba project for reporting this issue. Upstream acknowledges Stefan Metzmacher (SerNet) as the original reporter.

Additional Notes

The security update for this flaw introduces a new option in smb.conf, documented as:

  allow dcerpc auth level connect (G)

    This option controls whether DCERPC services can be used with
    DCERPC_AUTH_LEVEL_CONNECT, which provides authentication, but no per-message  integrity (SIGN) nor privacy protection (SEAL).

    Some interfaces like samr, lsarpc, and netlogon have a hardcoded default
    of no; epmapper, mgmt, and rpcecho have a hardcoded default of yes.

    The behavior can be overwritten per interface name (for example, lsarpc,
    netlogon, samr, srvsvc, winreg, or wkssvc) by specifying
    'allow dcerpc auth level connect:interface = yes'.

    This option yields precedence to any implementation-specific restrictions. For
    example:
    * 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

Frequently Asked Questions

Do I need to update both Samba servers and Samba clients in my infrastructure?

At the very least, Samba servers should be updated. Because Badlock is a protocol flaw, both the servers and clients may be affected, depending on the configuration of the Samba infrastructure. Red Hat Product Security advises customers to update both servers and clients.

Will the updated packages break my existing clients running older versions of Samba?

This security advisory tightens some of the security options used to configure Samba. This may break configurations when a Samba server is updated but the client is not. It is possible to roll back to older insecure options to continue interoperatibilty, (for example by setting allow dcerpc auth level connect = yes in the smb.conf file), but Red Hat Product Security highly recommends not to do so, since it re-introduces some of the attack vectors.

My Samba server instances are not connected to any Windows Domains, am I still affected?

Yes, if an admin user communicates with a Samba server using a non-secure client, or uses a secure client to communicate to an insecure Samba server, a man-in-the-middle attacker could potentially use this to exploit this flaw.

I have updated my Samba servers and clients, do I need to restart anything?

No, when the update is applied on your system, the smb service will be restarted automatically.

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.

References

http://badlock.org/