☰

So überwinden Sie das Problem mit schwächeren MD4-Hashes bei Samba

tag-icon • tag-icon linux ldap samba4 hash
So überwinden Sie das Problem mit schwächeren MD4-Hashes bei Samba

Wir verwenden eine Samba-Konfiguration auf unseren RedHat-Systemen (RHEL7.9), wobei die SMB-Authentifizierung auf einem NTLM-Passwort-Hash basiert, der im Grunde ein Klartext-Anmeldeinformationselement für eine Challenge-Response-Authentifizierung ist, das in einem separaten Attribut, sambaNTPassword, in der LDAP-Verzeichnisdatenbank (Oracle Unified Directory) gespeichert wird.

Unser Sicherheitsteam hat also einige Penetrationstests durchgeführt und festgestellt, dass der von unserem Samba verwendete MD4 abgefangen werden kann, da er einen schwächeren Hash enthält.

Neben der Authentifizierung sind die Gewährleistung der Datenintegrität und die Verschlüsselung während der Übertragung wichtige Bestandteile der SMB-Sicherheit, die wiederum auf MD4-Hashes basiert.

Unten ist das Beispiel meiner Samba-Konfiguration:

 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-seitige Benutzerdetails mit Attribut:

Beispiel:

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

Andere Details:

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

Wenn irgendjemand darauf gestoßen ist und eine Lösung kennt, würde ich gern um Anleitung oder Rat bitten, um das Problem zu entschärfen.

Nach dem Update Erhalt des Dokuments zur Sicherheitsbewertung:

Nachdem ich die Ergebnisse des Penetrationstests gelesen und durchgesehen hatte, erfuhr ich, dass dem Penetrationstester das interne Benutzerkonto eines Benutzers zur Verfügung gestellt wurde, das auf LDAP basiert, und dass er Schwachstellen für LDAP (Oracle Unified Directory) entdeckte, wo er „LDAP Anonymous Null Bind“ fand. Daher stellte er fest, dass es möglich war, kritische Informationen über den LDAP-Dienst abzurufen, ohne irgendwelche Authentifizierungsdaten angeben zu müssen, da dieser auch Suchanfragen mit NULL- und leeren Basisobjekten unterstützt, sodass ein nicht authentifizierter Angreifer dies ausnutzen und sich die Informationen verschaffen könnte, selbst wenn er vorher LDAP kennt.

So erhielt ich Zugriff auf den LDAP-Server, da dieser die NULL-/Leerbasisverbindungen zum LDAP-Server zuließ und alle LDAP-Daten ausgab, wodurch ich problemlos alle Kennwortinformationen für userPassword& erhielt sambaNTPassword.

Um den „Pass-the-Hash“-Angriff durchzuführen, wurden das Tool „Mimikatz“ und der Browser „Internet Explorer“ verwendet.

Interessant ist hier jedoch, dass sie für den Zugriff auf die Organisation einen VPN-Zugriff von außen benötigten und daher meterpreterein Tool verwendeten, um diesen mit dem reverse https connectionPaylod zu umgehen.

Antwort1

NT-Passwort-Hashes verwenden MD4 und dagegen können Sie nichts tun.

Sie haben das Problem des Netzwerkabfangens jedoch bereits durch die Verwendung von LDAPs gemildert, einem mit TLS gesicherten LDAP. Sofern mit Ihrer TLS-Konfiguration nichts sehr falsch ist, können diese Hashes nicht vom Netzwerk abgefangen werden. Mich würden die Einzelheiten darüber, wie Ihr Sicherheitsteam TLS geknackt hat, sehr interessieren.

Die einzigen anderen Möglichkeiten, an diese Passwort-Hashes zu gelangen, sind der direkte lokale Zugriff auf die LDAP-Server oder ein Zugriffskontrollfehler, der es jemandem ermöglichen würde, sie abzufragen. Sie haben jedoch nichts darüber erwähnt.

verwandte Informationen