Pass-the-Hash攻撃の起源は今から20年以上さかのぼるほど古い。ネットワークOSとしてMicrosoftが販売していた「LAN Manager」や、Windows 98などに実装されていた「LM認証」に対する攻撃が最初期のものだ。
LM認証で利用する「LMハッシュ」は、パスワードを全て大文字とした16bitのハッシュとして設計されていたことに加えて、ハッシュ化に不備があり、パスワードの推測が可能であった。
LMハッシュだけでは不十分なため、Windows NT 4.0では「NTLM認証」が加わった。Windows 2000/XPでは「NTLMv2認証」が実装され、Active Directoryでは、「Kerberos認証」をデフォルトの認証方式にしている。こうして、Pass-the-Hashへの対策が進んできた。
しかしWindows 8においても、Pass-the-Hashが可能な攻撃用のツールが開発された。そこでWindows 8.1では、メモリ上に認証情報を残さない「Protected Users」「RestrictedAdmin RDP」という新しいアカウントグループを用意した(図5)。
Windows 10で導入されたCredential Guardは、「Protected Users」「RestrictedAdmin RDP」といった新しいアカウントグループ以外を使っていた場合でも、Pass-the-Hash攻撃対策として機能する。
Windows 8.1までは、NTLMハッシュやKerberos派生資格情報を、Windows上で動作するLSAプロセスが保持していた。つまり、原理的には他のWindowsプログラムからアクセスされてしまう危険性が残っていた。冒頭で解説したように、仮想マシンにハッシュ情報を隔離することで、これらのハッシュ情報を攻撃から守っている。
ただし、Credential Guardを有効にした場合でも、全ての認証情報が保護されるわけではないので、注意が必要だ*2)。
*2) Credential Guardを有効にした場合、制約のないKerberosデリゲーション、Kerberos DES暗号が利用できない点も注意する必要がある。
例えば、NTLMv1とMS-CHAPv2、Digest、CredSSPの認証情報ではシングルサインオンが機能しない。よって、これらの認証を利用するアプリケーションがシングルサインオンを実現するために資格情報を保持する場合、Credential Guardでも資格情報は保護されない。このためサインインや重要なサービスの認証では、これらのプロトコルの利用を避けることを推奨する。ドメインユーザーが、これらのプロトコルを使用する必要がある場合は、2要素認証でこれらの認証を保護しなければならない。
繰り返しになるが、Credential GuardはSAM(Security Account Manager)データベースなどに保存された資格情報を完全に保護するものでは「ない」。
Pass-the-Hash攻撃に対するより詳しい対策方法については、以下の資料を参考にしてほしい。
次回はWindows 10が備える5つのセキュリティスタックのうち、4番目に当たる「情報の保護」を解説する。
高橋 正和(たかはし まさかず)
日本マイクロソフト株式会社
チーフ セキュリティ アドバイザー
1980年代初頭からミニコン、PC-98、8085、4bitマイコンなどを使った制御システムの開発などを経験。
1980年代中頃から、日本デジタル研究所株式会社で標準ライブラリの開発保守、開発環境の開発保守、独自OSからWindows NT/Windows XPへの移植、品質管理、新入社員向けのC言語の新人教育などを担当した。
標準ライブラリでは、ファイルシステムやSocketライブラリの開発と実装、保守を行い、開発環境では、68K系のCPUにWhite Sims’s Cによるリロケータブルな実行ファイル形式という特性を使って、オーバレイリンカーやオーバーレイローダーなども開発した。
1999年にISS(現在はIBM)セキュリティに関わり、2006年から現職(日本マイクロソフト株式会社 チーフセキュリティアドバイザー)を務める。
Copyright © ITmedia, Inc. All Rights Reserved.