NTLM 認証とは
NTLM 認証は SMB や RDP 等の認証認可の必要な NW プロトコルにおいて組み込まれる認証方式です。
NTLM 認証は TCP/UDP 等の通信ポート番号があるわけではなく、GSS-API の SPNEGO という規格のフォーマットが NW プロトコル自体に組み込まれます。
SPNEGO に対応している NW プロトコルとして代表的なものは SMB (ファイル共有, tcp 445 port) です。
以下に NTLM 認証の主流な 2 パターンを示します。
パターン①はローカルユーザの NTLM 認証をする場合、パターン②はドメインユーザの NTLM 認証をする場合です。
パターン②にといては、サーバ (SV) は PC からの SMB アクセスにおける資格情報をドメインコントローラ (DC) へ問合せをしていますが、その問合せは MS-RPC のセキュアチャネルで行っています。セキュアチャネルはあくまでコンピュータ同士の認証・暗号化の仕組みですので、その経路を使ってユーザーの資格情報の受け渡しを行ったりするわけです。
セキュアチャネルについては以下を参照下さい。
また、具体的な NTLM 認証のシーケンス例を以下に示します。SMB プロトコルの中に GSS-API SPNEGO のフォーマットで NTLM 認証情報がやり取りされます。
Kerberos 認証との違い
SPNEGO は Kerberos 認証においても同様にパケット内で使われます。Microsoft としては NTLM 認証は非推奨ですが、ローカルユーザを前述の NW プロトコルで認証する際は非常に便利なため、実態としてはまだ根強く使われています。
パケットの中身を見ると以下のように違います。(左が kerberos, 右が NTLM)
NTLM ハッシュと Pass-the-hash 攻撃
Windows ではパスワードはハッシュ化した状態で使われます。平文のパスワードを md4 という salt 無しのハッシュ関数でハッシュ化したものになります。これを一般に「NTLM ハッシュ」と呼びます。
NTLM ハッシュは [C:\Windows\system32\config\SAM] に保存されますが、これは起動時に SYSTEM ユーザによって HKLM:\SAM にマウントされているようです。つまり SAM ファイルの内容が HKEY_LOCAL_MACHINE\SAM というレジストリに読み込まているようです。(正確な情報は見つからず。)
なお、このとき読み取りの排他制御が掛かっているようで、SAM ファイルについてはユーザログイン後には SYSTEM 権限でもアクセスできません。詳細手順は割愛しますが、SAM レジストリについては PowerShell を使って読み込みができました。
また、Windows 起動時には Lsass.exe (認証を司る) プロセスのメモリにパスワードハッシュが読み込まれますが、最近のサイバー攻撃の傾向としては、SAM ファイルやレジストリより、このメモリ部分が狙われやすいようです。
1 台の Windows マシンにバックドア (C&C サーバと通信しコマンドを受け付けるプロセス) を仕掛けられた場合、そこから以下のように隣接の Windows マシンへの侵入を試みるパターンが多いです。
- そのマシンの Lsass.exe メモリ内からローカルアカウント (ローカル管理者含む) の NTLM ハッシュを抽出
- 抽出した NTLM ハッシュを使って隣接マシンへそのパスワードハッシュで NTLM 認証を試行
Windows は salt 無しのパスワードハッシュなので、もし隣の Windows マシンで同じアカウント・同じパスワードを使っていると、パスワード自体が分からなくても NTLM ハッシュをそのまま使って認証成功してしまいます。
このような攻撃を「Pass-the-hash」攻撃と呼びます。
対策としてはローカル管理者のパスワードを各マシンでバラバラにする、というものがありますが、実はハッシュなので、パスワード自体は「P@55w0rd-01」「P@55w0rd-02」等の接尾句を通番にするだけでも効果があります。(もちろん、平文が流出した時のことを考えるとバラバラがベストではありますが、一定の効果は得られます。)
NTLMv1 と NTLMv2
NTLMv1 と v2 の主な違いは以下の2点です。
- 認証に HMAC-sha を使う
- クライアント側もチャレンジを送る (salt としての効果)
NTLMv1 の場合は NTLM ハッシュを 3つに分割し、ServerChallenge を暗号化するための DES キーとして利用し、DES で暗号化したものを１つにまとめて認証情報としてサーバへ送付します。サーバ側も認証相手の NTLM ハッシュを知っているので、同様の手順で照合し、照合に成功すれば認証成功とします。
ですが DES は色々と危殆化していますので、NTLMv2 からは HMAC-sha アルゴリズムを使って認証をすることになりました。
また、もし悪意ある機器が正規のサーバに成りすまし ServerChallenge を送るケースを想定します。すると、毎回同じ ServerChallenge を送付すると毎回同じ認証情報が返ってきます。この性質を悪用されることを想定し、NTLMv2 ではクライアント側でも ClientChallenge を送付することになりました。
これにより salt と同じ効果があり、サーバに返信される認証情報は ServerChallenge に依らず毎回変わります。
Windows 機器内に保持される NTLM ハッシュには salt は付加されていません。あくまで NTLMv2 認証時に、ネットワーク上を流れるときに ClientChallenge が salt と同じ効果を果たす、という意味です。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント