☰

Cómo superar el problema del hash MD4 más débil con samba

tag-icon • tag-icon linux ldap samba4 hash
Cómo superar el problema del hash MD4 más débil con samba

Estamos utilizando la configuración de samba en nuestros sistemas RedHat (RHEL7.9), donde la autenticación SMB se basa en un hash de contraseña NTLM que básicamente es una credencial de texto sin cifrar para una autenticación de desafío-respuesta que se almacena en un atributo separado, sambaNTPassword en LDAP. Base de datos del directorio (directorio unificado de Oracle).

Entonces, nuestro equipo de seguridad llevó a cabo algunas pruebas de penetración y encontró que el MD4 que utiliza nuestra samba puede ser interceptado ya que lleva un hash más débil.

Además de la autenticación, garantizar la integridad de los datos y el cifrado en tránsito son partes importantes de la seguridad de las PYMES, que nuevamente dependen del hash MD4.

A continuación se muestra el ejemplo de mi configuración de samba:

 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

Detalles del usuario del lado LDAP con atributo:

Ejemplo:

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

Otros detalles:

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

Si alguien se encontró con esto y tiene una solución, me gustaría buscar orientación o consejo para mitigar el problema.

Después de la actualización que recibe el documento de evaluación de seguridad:

Después de leer y revisar los resultados de la prueba de penetración, descubrí que al pentester se le proporcionó la cuenta de usuario interna para un usuario que se basa en LDAP y descubrí debilidades para LDAP (directorio unificado de Oracle) donde encontraron "LDAP anónimo". Null Bind", por lo tanto, descubrieron que era posible recuperar información crítica a través del servicio LDAP sin tener que proporcionar ninguna credencial de autenticación, ya que también admite solicitudes de búsqueda con objetos base NULL y vacíos, por lo que un atacante no autenticado puede explotar y obtener la información incluso antes. conocimiento de LDAP.

Entonces, obtuve acceso al servidor LDAP ya que permitía conexiones base NUll/vacías al servidor LDAP y descarté todos los DATOS LDAP donde obtuve fácilmente toda la información de contraseña para userPassword& sambaNTPassword.

Para realizar el ataque "pass-the-hash" se utilizó la herramienta "Mimikatz" y el navegador "Internet Explorer".

Sin embargo, es interesante destacar aquí que para obtener acceso a la organización requerían acceso VPN desde el exterior, por lo que utilizaron meterpreteruna herramienta para evitar lo mismo con el reverse https connectionpaylod.

Respuesta1

Los hashes de contraseñas de NT usan MD4 y no hay nada que puedas hacer al respecto.

Pero ya ha mitigado el problema de la interceptación de la red mediante el uso de ldaps, que es LDAP protegido con TLS. A menos que haya algún problema grave con su configuración TLS, estos hashes no se pueden interceptar desde la red. Me interesaría mucho escuchar los detalles de cómo su equipo de seguridad rompió TLS.

Las únicas otras formas de acceder a estos hashes de contraseñas es mediante acceso local directo a los servidores LDAP, o si hay una falla en el control de acceso que permitiría a alguien consultarlos. Aunque no mencionaste nada sobre esto.

información relacionada