Samba で弱い MD4 ハッシュ問題を克服する方法

Samba で弱い MD4 ハッシュ問題を克服する方法

当社では、RedHat(RHEL7.9) システムで samba 構成を使用しています。SMB 認証は、基本的にチャレンジ レスポンス認証用のクリア テキスト資格情報である NTLM パスワード ハッシュに基づいており、LDAP(Oracle unified Directory) ディレクトリ データベース内の別の属性 sambaNTPassword に保存されます。

そこで、当社のセキュリティ チームがペンテストを実施し、Samba で使用される MD4 はハッシュが弱いため傍受される可能性があることを発見しました。

認証に加えて、転送中のデータの整合性と暗号化を確保することは、再び MD4 ハッシュに依存する SMB セキュリティの重要な部分です。

以下は私の 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 サービスを介して重要な情報を取得できることがわかったことがわかりました。これは、NULL および空の基本オブジェクトを使用した検索要求もサポートしているため、認証されていない攻撃者が LDAP の事前知識を持っていても、これを悪用して情報を取得できるためです。

したがって、LDAP サーバーへの NULL/空ベース接続を許可していたため、LDAP サーバーにアクセスし、すべての LDAP データをダンプして、userPassword&のすべてのパスワード情報を簡単に取得できましたsambaNTPassword

「パス・ザ・ハッシュ」攻撃を実行するために、「Mimikatz」というツールと「Internet Explorer」というブラウザが使用されました。

しかし、ここで注目すべき興味深い点は、組織にアクセスするには外部からの VPN アクセスが必要だったため、ペイロードmeterpreterを使用してこれをバイパスするツールを使用したことですreverse https connection

答え1

NT パスワード ハッシュは MD4 を使用するため、これについては何もできません。

しかし、ネットワーク傍受の問題は、TLS で保護された LDAP である ldaps を使用することですでに軽減されています。TLS 構成に重大な問題がない限り、これらのハッシュをネットワークから傍受することはできません。セキュリティ チームがどのようにして TLS を破ったのか、詳細をお聞かせいただければ幸いです。

これらのパスワード ハッシュを取得する他の唯一の方法は、LDAP サーバーに直接ローカル アクセスするか、アクセス制御に障害が発生して誰かがクエリを実行できる場合です。ただし、これらについては何も言及されていません。

関連情報