Как преодолеть проблему слабого хэша MD4 с помощью Samba

Как преодолеть проблему слабого хэша MD4 с помощью Samba

Мы используем конфигурацию Samba в наших системах RedHat (RHEL7.9), где аутентификация SMB основана на хэше пароля NTLM, который по сути представляет собой открытые учетные данные для аутентификации по принципу «вызов-ответ», которые хранятся в отдельном атрибуте sambaNTPassword в базе данных каталога LDAP (Oracle unified Directory).

Итак, наша команда безопасности провела тестирование на проникновение и обнаружила, что MD4, используемый нашей Samba, может быть перехвачен, поскольку он несет в себе более слабый хэш.

Помимо аутентификации, важными элементами безопасности малого и среднего бизнеса являются обеспечение целостности данных и шифрование при передаче, которые снова полагаются на хэш MD4.

Ниже приведен пример моей конфигурации 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

Данные пользователя на стороне LDAP с атрибутом:

Пример:

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

Другие детали:

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

Если кто-то сталкивался с этим и знает решение, то я бы хотел получить руководство или совет по смягчению проблемы.

После обновления получен документ об оценке безопасности:

После прочтения и изучения результатов тестирования на проникновение я узнал, что тестировщику на проникновение была предоставлена ​​внутренняя учетная запись пользователя, основанная на LDAP, и он обнаружил уязвимости LDAP (Oracle Unified Directory), в частности, «LDAP Anonymous Null Bind», что позволило ему извлечь важную информацию через службу LDAP без необходимости предоставления каких-либо учетных данных для аутентификации, поскольку она также поддерживает поисковые запросы с пустыми и пустыми базовыми объектами, поэтому неаутентифицированный злоумышленник может воспользоваться этой возможностью и получить информацию, даже имея какие-либо знания о LDAP.

Итак, получил доступ к серверу LDAP, поскольку он разрешал нулевые/пустые базовые соединения с сервером LDAP, и выгрузил все ДАННЫЕ LDAP, откуда легко получил всю информацию о паролях для userPassword& sambaNTPassword.

Для проведения атаки «передай хэш» использовался инструмент «Mimikatz» и браузер «Internet Explorer».

Однако интересно отметить, что для получения доступа к организации им требовался VPN-доступ извне, поэтому они использовали meterpreterинструмент для обхода этой защиты с помощью reverse https connectionполезной нагрузки.

решение1

Хэши паролей NT используют MD4, и с этим ничего не поделаешь.

Но вы уже смягчили проблему сетевого перехвата, используя ldaps, который является LDAP, защищенным с помощью TLS. Если только что-то не очень не так с вашей конфигурацией TLS, эти хэши не могут быть перехвачены из сети. Мне было бы очень интересно услышать подробности того, как ваша команда безопасности взломала TLS.

Единственные другие способы получить эти хэши паролей — это прямой локальный доступ к серверам LDAP или если есть сбой контроля доступа, который позволит кому-то запросить их. Вы ничего об этом не упомянули.

Связанный контент