How to overcome the Weaker MD4 hash issue with samba

We are using samba configuration on our RedHat(RHEL7.9) systems, where SMB authentication is based on a NTLM password hash which basically a clear-text credential for a challenge-response authentication which getting stored in a separate attribute, sambaNTPassword in the LDAP(Oracle unified Directory) directory database.

So, Our security team carried out some pen-testing and found the MD4 which is used by our samba that can be intercepted as it carries weaker hash.

In addition to authentication, ensuring data integrity and encryption in transit are important parts of SMB security, which is again relying on MD4 hash.

Below is the sample of my samba configuration:

 cat /etc/samba/smb.conf

[global]
  log file                       = /var/log/samba/%m.log
  log level                      = 2
  max log size                   = 50
  netbios name                   = FDI0816
  server string                  = FDI0816.myorg.com
  workgroup                      = FDI

; ldap configuration
  invalid users                  = root +wheel
  encrypt passwords              = Yes
  guest account                  = nobody
  ldap admin dn                  = cn=sambaAdmin,ou=users,o=services
  ldap group suffix              = ou=Group
  ldap passwd sync               = only
  ldap ssl                       = no
  ldap suffix                    = ou=FDI,o=myorg
  ldap timeout                   = 4
  ldap user suffix               = ou=People
  map to guest                   = Bad User
  security                       = user
  passdb backend = ldapsam:"ldaps://ldap.FDI.myorg.com ldaps://ldap.rnd.myorg.com"

; client connection settings
  deadtime                       = 15
  dns proxy                      = No
  lm announce                    = No
  server min protocol            = SMB2

; shares default settings
  create mask                    = 0750
  directory mask                 = 2750
  posix locking                  = No
  strict allocate                = Yes
  unix extensions                = No
  wide links                     = Yes

; printers are disabled
  disable spoolss                = Yes
  load printers                  = No
  printcap name                  = /dev/null
  printing                       = bsd
  show add printer wizard        = No

[homes]
  browseable                     = No
  comment                        = Your Home
  create mode                    = 0640
  csc policy                     = disable
  directory mask                 = 0750
  public                         = No
  writeable                      = Yes

[proj]
  browseable                     = Yes
  comment                        = Project directories
  csc policy                     = disable
  path                           = /proj
  public                         = No
  writeable                      = Yes

[home]
  browseable                     = Yes
  comment                        = Project directories
  csc policy                     = disable
  path                           = /home
  public                         = No
  writeable                      = Yes

LDAP side user details with attribute:

Example:

Attribute Description       value
sambaNTPassword             0735509A0ED9A577BD7D8GG7BC1T
uidNumber                   32222
userPassword                {RBKBD4-HMAC-SHA512)...

Other details:

Samba Version: 4.10
Client side smb version: 2
Samba Server : RHEL7.9

If anyone came across this and have a solution, then I would like to seek the guidance or advice to mitigate the issue.

Post Update receiving Security assessment Document:

After reading and going through with pen-testing result, I came to know pen-tester was provided with the internal user-account for a user which is based on LDAP and discovered weaknesses for LDAP(Oracle Unified Directory) where they found "LDAP Anonymous Null Bind" hence they found it possible to retrieve critical information via LDAP service without having to supply any authentication credentials, since it also supports search requests with the NULL and empty, base objects thus an unauthenticated attacker may exploit and get the information even any prior knowledge of LDAP.

So, gained access to the LDAP Server as it was allowing the NUll/empty base connections to LDAP Server and dumped all the LDAP DATA where easily got all the Password information for userPassword & sambaNTPassword.

In order to perform the "pass-the-hash" attack, the tool "Mimikatz" and the browser "Internet Explorer" were used.

However, interesting here to highlight, to get access to the Organization they required VPN access from outside, thus they used meterpreter tool to bypass the same with the reverse https connection paylod.

Solution 1:

NT password hashes use MD4 and there's nothing you can do about that.

But you have already mitigated the issue of network interception by using ldaps, which is LDAP secured with TLS. Unless something is very wrong with your TLS configuration, these hashes cannot be intercepted from the network. I would be most interested to hear the details of how your security team broke TLS.

The only other ways to get at these password hashes is with direct local access to the LDAP servers, or if there is an access control failure that would allow someone to query them. You didn't mention anything about these, though.