☰

Como superar o problema de hash MD4 mais fraco com o samba

tag-icon • tag-icon linux ldap samba4 hash
Como superar o problema de hash MD4 mais fraco com o samba

Estamos usando a configuração samba em nossos sistemas RedHat (RHEL7.9), onde a autenticação SMB é baseada em um hash de senha NTLM que basicamente é uma credencial de texto simples para uma autenticação de resposta a desafio que é armazenada em um atributo separado, sambaNTPassword no LDAP (Oracle unified Directory) banco de dados de diretório.

Então, nossa equipe de segurança realizou alguns testes de penetração e descobriu que o MD4 usado pelo nosso samba pode ser interceptado porque carrega um hash mais fraco.

Além da autenticação, garantir a integridade dos dados e a criptografia em trânsito são partes importantes da segurança das pequenas e médias empresas, que novamente dependem do hash MD4.

Abaixo está o exemplo da minha configuração do 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

Detalhes do usuário do lado LDAP com atributo:

Exemplo:

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

Outros detalhes:

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

Se alguém se deparar com isso e tiver uma solução, gostaria de buscar orientação ou conselho para mitigar o problema.

Pós-atualização recebendo documento de avaliação de segurança:

Depois de ler e analisar o resultado do pen-testing, descobri que o pen-tester recebeu a conta de usuário interna de um usuário baseado em LDAP e descobriu pontos fracos do LDAP (Oracle Unified Directory), onde encontrou "LDAP Anonymous Null Bind", portanto, eles descobriram que era possível recuperar informações críticas por meio do serviço LDAP sem ter que fornecer quaisquer credenciais de autenticação, uma vez que ele também suporta solicitações de pesquisa com objetos base NULL e vazios, portanto, um invasor não autenticado pode explorar e obter as informações até mesmo qualquer anterior conhecimento de LDAP.

Assim, obtive acesso ao servidor LDAP, pois ele estava permitindo conexões de base NUll/vazias ao servidor LDAP e despejou todos os DADOS LDAP, onde obteve facilmente todas as informações de senha para userPassword& sambaNTPassword.

Para realizar o ataque “pass-the-hash” foram utilizados a ferramenta “Mimikatz” e o navegador “Internet Explorer”.

Porém, é interessante destacar aqui, para obter acesso à Organização eles necessitavam de acesso VPN de fora, portanto utilizaram meterpreterferramenta para contornar a mesma com o reverse https connectionpaylod.

Responder1

Os hashes de senha do NT usam MD4 e não há nada que você possa fazer sobre isso.

Mas você já mitigou o problema de interceptação de rede usando ldaps, que é LDAP protegido com TLS. A menos que algo esteja muito errado com sua configuração TLS, esses hashes não podem ser interceptados da rede. Eu ficaria muito interessado em saber os detalhes de como sua equipe de segurança quebrou o TLS.

As únicas outras maneiras de obter esses hashes de senha são com acesso local direto aos servidores LDAP ou se houver uma falha no controle de acesso que permita que alguém os consulte. Você não mencionou nada sobre isso, no entanto.

informação relacionada