Hi All,
My group runs several Samba services in production and we are trying to
determine our exposure level to this vulnerability. It is my understanding
that, on success, this attack gives read/write access to both the "Local
Security Authority" service and to the "Security Account Manager"
database(s). From the reading that I've been doing, it looks as though the
datastore for these security services will contain identities and credentials
*only* in the case of a service that is maintaining its own ID mapping and/or
password database.
In the case of our services, we pass the authentication routine off to an Active
Directory domain controller using this smb.conf option:
security = ADS
Furthermore, on our newer systems, authorization (UID and GID resolution) is
performed on our services in one of two ways:
1) Sourced from ADS through a name serviced caching daemon (`sssd` via nss):
idmap config * : backend = nss
2) Stored locally in /etc/passwd and /etc/group
In neither of these cases do the Samba service store their own ID mapping using
TDBSAM.
We *do* have an older (2.5) version which does not seem to have configuration
options for 'idmap config*:'. Can the list recommend a way to determine
definitively what the id-mapping routine used by this older system is?
These facts seem to suggest that an attacker who gained access to these services
on our systems would not actually acquire any useful information. Can you share
your comments on this argument?
Finally, can anyone recommend a penetration test or simulation of this attack so
that my group can try it out for ourselves against our own systems?
Thank you so much for your help as always!
Stewart Howard
Indiana University
On Thu, 2016-04-14 at 14:44 +0000, Howard, Stewart Jameson wrote:> > > In the case of our services, we pass the authentication routine off > to an Active Directory domain controller using this smb.conf option: > > > security = ADSIn your situation, the impact is limited to a possible DoS (most likely crashing of the smbd attached to the client), of winbindd if the DC was impersonated, or possibly the persistent spoolss server for printing if you had set: [global] rpc_server:spoolss = external rpc_daemon:spoolssd = fork You are unlikely to be running with smb singing (unless you had set server signing = mandatory at a performance cost) so have always been vulnerable to MitM attacks in general, leaving this one as a less -important detail. Patching Samba is still good to do, and we fixed a lot of important details along the way, but the MitM attack prevention mattered essentially entirely for those running Samba an an AD DC. Hopefully this helps clarify things. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba