Windows NTLM認証とマン・イン・ザ・ミドル攻撃Cyber Security Management 2004年5月号
あるWindowsシステムが他のWindowsシステムのリソース（資源）を使用する場合、通常、ネットワーク経由のログオン処理が行われる。このようなログオン処理の過程では、そのユーザがどういったユーザなのか（ユーザの識別）、確かにそのユーザ本人であるか（ユーザの認証）、さらにそのユーザがリソースを使用する権限を所有しているかどうか（アクセスの承認）について確認される。 今回はそのようなWindowsのログオン処理において重要な位置を占める「Windows NTLM認証」と、それに対する「マン・イン・ザ・ミドル攻撃」について解説する。 Windows NTLM認証のあらましWindowsには各種のネットワーク経由でのユーザ認証機能があるが、その中でもNTLM認証（Windows NT LAN Manager認証）はさまざまなフェーズで用いられる、Windowsシステムの非常に基本的なユーザ認証プロトコルである。Windows 2000以降、ドメイン環境ではデフォルトのユーザ認証プロトコルとしてKerberosが使用されるようになったが、NT4.0以前のサーバや、スタンドアローンのWindows 2000サーバに対するネットワークログオンには、依然としてNTLM認証が用いられる。また通常のファイル共有やプリンタ共有におけるネットワークログオン以外に、Windowsのtelnetサービスや、Windows標準のWebサービスであるIISのHTTP認証等でも、設定によってはNTLM認証が使用される。 NTLM認証では、チャレンジ/レスポンス方式をベースとした認証メカニズムが用いられている。つまり、クライアントからの認証要求を受けたサーバは「チャレンジ」（ランダムなバイト列）をクライアントへ返し、クライアントはパスワードの情報に基づいてチャレンジを処理した結果である「レスポンス」をサーバへ送る。サーバではクライアント側で行われたレスポンス生成と同じ処理を行い、その結果とクライアントから送られたレスポンスとを比較する。それらが同一のものであれば、サーバおよびクライアントの双方が持っているパスワード情報（正確にはパスワードを一方向関数で処理した、パスワードハッシュ）が等しいことになるので、サーバはクライアントからのログオンを許可する。 NTLM認証の流れを図1に示す[1]。
② サーバは認証要求を受け、ランダムなバイト列「チャレンジ」を送り返す ③ クライアントは、チャレンジとパスワード情報に基づいて「レスポンス」を生成し、サーバに送る ④ サーバ側でも先ほど送ったチャレンジとパスワード情報を基にレスポンスを生成する ⑤ クライアントから送られたレスポンスと、自ら生成したレスポンスを比較することにより、クライアント側とサーバ側両方のパスワード情報が同一であることを確認する ⑥ パスワード情報の同一性が確認できた場合、クライアントにログオン許可を与える ⑦ クライアント側ではログオン許可を受け、ログオン処理を実行する NTLM認証に対するマン・イン・ザ・ミドル攻撃さてこのようなチャレンジ/レスポンス方式の認証は、一般的にマン・イン・ザ・ミドル攻撃と呼ばれるネットワーク攻撃に弱いとされている。 マン・イン・ザ・ミドル攻撃とは、ネットワーク通信を行うマシンの間に密かに割り込んで双方の通信を中継（リレー）することにより、
図2を見ていただきたい。これはクライアントとサーバとの間のNTLM認証に攻撃者が割り込んで、クライアントからの認証要求をサーバへ、サーバからの返答をクライアントへ、それぞれの通信を攻撃者のコンピュータが中継しているところを示している。この場合、見かけ上、クライアントはサーバへログオンしているのだが、実際には攻撃者のコンピュータがサーバへログオンしているため、攻撃者はサーバに対して不正な操作を行ったり、クライアントからの要求を横取りして改変したりすることが可能となる。
② 攻撃者はクライアントと同じユーザIDを用いて、サーバに対し別の認証要求を発行する ③ サーバは認証要求を受け、ランダムなバイト列「チャレンジ」を送り返す ④ 攻撃者はサーバから送られたチャレンジを複製し、クライアントからの認証要求（①）のチャレンジとしてクライアントへ送信する ⑤ クライアントは、チャレンジとパスワード情報に基づいて「レスポンス」を生成し、サーバに送る（実際は攻撃者に向けて送られる） ⑥ 攻撃者はクライアントから来たレスポンスを複製し、サーバに対する認証要求（②）のレスポンスとしてサーバへ送信する ⑦ サーバ側では、先ほど送ったチャレンジとパスワード情報を基にレスポンスが生成される ⑧ 攻撃者から送られたレスポンスと、自ら生成したレスポンスを比較することにより、両方のパスワード情報が同一であることを確認する ⑨ 攻撃者が送ったレスポンスはクライアントが生成したものであるため、パスワード情報の同一性が確認され、サーバは攻撃者にログオン許可を与える ⑩ 攻撃者側ではログオン許可を受け、ログオン処理を実行する ⑪ 攻撃者はサーバからのログオン許可を装って、クライアントにログオン許可を送る ⑫ クライアント側ではログオン許可を受け、ログオン処理を実行する SMBRelayNTLM認証に対するマン・イン・ザ・ミドル攻撃の危険性を解説した技術文書は、筆者が知る限り、Dominique Brezinski氏の「A Weakness in CIFS Authentication」（1997年）が最初である。その後、2001年にSir Dystic氏により、ファイル共有等で行われるネットワークログオンのNTLM認証（いわゆるSMB認証）を対象としたマン・イン・ザ・ミドル攻撃ツール「SMBRelay」が公開された。 SMBRelayはまさに図2に示したような行為を「攻撃者のコンピュータ」上で実行する、コマンドラインツールである。異なる点は、図2では⑪でクライアントに対してログオン許可を送り、クライアントは⑫でログオン処理を実行しているが、SMBRelayはクライアントにエラーを返すようにプログラミングされている。そのため、クライアント側はログオンに失敗した状態となり、一方で攻撃者はサーバにログオンした状態となる。つまり、SMBRelayを用いることで攻撃者は、クライアントに成り代わってサーバに不正にログオンすることができるわけだ。 実際にSMBRelayを実行した様子を図3に示す。このコマンドプロンプト画面は、SMBRelayでクライアントからの認証要求をIPアドレス：192.168.183.130のサーバに対してリレーするように指定し、IPアドレス：192.168.183.100で待受けているところに、IPアドレス：192.168.183.230のクライアントからアクセスがあったところをあらわしている。この時点でSMBRelayは、クライアント（192.168.183.230）の認証情報を用いてサーバ（192.168.183.130）にログオンしていることになる。画面上の「Challenge (8 bytes)」の部分にはチャレンジの値が、また「Case insensitive password」および「Case sensitive password」の部分にはレスポンスの値が表示されている。
SMBRelayを用いたリバースログオンここまでは「クライアント～攻撃者～サーバ」という具合に、クライアント/サーバの二者の間に攻撃者が割り込んで不正ログオンを行うケースについて述べてきたが、同様の原理を用い、クライアントからの認証要求をそのままクライアントに返すことで、クライアントマシンに逆に不正ログオンすることも可能である。ここではこのような行為を「リバースログオン」と呼ぶことにする。 Windows NT/2000/XPではファイル共有等のクライアント機能は「Workstationサービス」が、サーバ機能は「Serverサービス」が司っているが、これらのサービスはいずれもデフォルトでシステム起動時に自動的に動作するように設定されている。つまりこれらのOSはクライアントマシンとして使用する場合であっても、標準でサーバ（ファイルサーバ等）として機能するように構成されているわけだ。いわばクライアント機能とサーバ機能が同居している状態だと考えてもらえればよい。 先ほどはSMBRelayでクライアントマシンからの認証をサーバマシンへリレーする例を示したが、リレー先を、認証要求を発行したクライアントマシン自身のサーバ機能に向けると、どのようなことになるだろうか。Windowsのネットワークログオンは特にユーザIDを指定しない場合、基本的に現在ログオンしているユーザのユーザIDとパスワード情報を用いて認証を行おうとする。そのためSMBRelayを実行する攻撃者は、クライアントマシンのクライアント機能から発行された認証要求を、同じクライアントマシンのサーバ機能へ中継することにより、現在クライアントマシンにログオンしているユーザの認証情報を使って「リバースログオン」することができることになる（図4）。
② 攻撃者はクライアントのサーバ機能に対し、認証要求を発行する ③ クライアントのサーバ機能は認証要求を受け、ランダムなバイト列「チャレンジ」を送り返す ④ 攻撃者は送られたチャレンジを複製し、クライアントからの認証要求（①）のチャレンジとして送信する ⑤ クライアントは、チャレンジとパスワード情報に基づいて「レスポンス」を生成し、攻撃者に送る ⑥ 攻撃者はクライアントから来たレスポンスを複製し、クライアントのサーバ機能に対する認証要求（②）のレスポンスとして送信する ⑦ クライアントのサーバ機能では、先ほど送ったチャレンジとパスワード情報を基にレスポンスが生成される ⑧ 攻撃者から送られたレスポンスと、自ら生成したレスポンスを比較することにより、両方のパスワード情報が同一であることを確認する ⑨ 攻撃者が送ったレスポンスはクライアント（のクライアント機能）が生成したものであるため、パスワード情報の同一性が確認され、クライアントのサーバ機能は攻撃者にログオン許可を与える ⑩ 攻撃者側ではログオン許可を受け、ログオン処理を実行する ⑪ 攻撃者はクライアント（のクライアント機能）にログオン失敗のメッセージを送る ⑫ クライアント側ではログオン失敗のメッセージを受け、エラーとして処理する NTLM認証のマン・イン・ザ・ミドル攻撃を防ぐにはNTLM認証自体は、基本的にマン・イン・ザ・ミドル攻撃に対して脆弱である。NTLM認証の最新プロトコル「NTLMv2」を用いることで、SMBRelayによる攻撃を防ぐことは可能だが、それは単にSMBRelayがNTLMv2に対応していないだけの理由であり、本質的な解決にはならない。 ここではNTLM認証に対するマン・イン・ザ・ミドル攻撃を防ぐための、いくつかの方法を紹介する。 1) SMB署名を有効にするマン・イン・ザ・ミドル攻撃に対してマイクロソフトが採用した解決策の一つは、NT4.0のサービスパック3で導入した「SMB署名」機能である。SMB署名とは、ファイル共有のプロトコルにおいてクライアント/サーバ間で通信されるSMBパケットに対し、一つ一つ電子的に署名を行い、クライアント/サーバ双方でそのパケットの署名を確認するというものだ。署名にはパケットのシーケンス番号、認証時のレスポンスデータ、それからクライアント/サーバの両方で持っているはずのパスワード情報が用いられるため、パスワード情報を持たない攻撃者は中間に割り込んでマン・イン・ザ・ミドル攻撃を実行することができなくなる[2]。SMBRelayに対する最良の防御策は、このSMB署名機能を有効にすることだろう。ただしSMB署名を有効にすると、ファイル共有における通信のパフォーマンスが10%～15%程度低下するといわれているため、パフォーマンスが要求される環境下では注意が必要とされる。またSMB署名はNTLM認証自体の安全性を向上させるものではない。あくまでも認証された後の通信（ファイル共有におけるデータのやりとり）の整合性を図るものである。 Windows 2000以降のOS上でSMB署名機能を有効にするには、ローカルセキュリティ設定ウィンドウのセキュリティオプションで設定すればよい。NT4.0ではレジストリを直接編集する必要がある。いずれにせよサーバとクライアントで整合性のとれた設定がなされていない場合、通信ができなくなるので注意が必要だ[3]。 2) NTLM認証の自動実行を制限する前述のとおり、NTLM認証はファイル共有におけるネットワークログオン以外にも、telnetのクライアント/サーバ間での認証や、Internet ExplorerがIISに対して認証する場合など、さまざまな局面で使用されている。そしてこれらのNTLM認証は、マイクロソフトが目指すところのシームレスなシングルサインオンの考えに基づき、ユーザが意識することなく実行される。興味深いことに、例えばtelnetのNTLM認証で交換されたチャレンジ/レスポンスが、ファイル共有のNTLM認証でも使用できるといった具合に、異なるプロトコル上のNTLM認証同士で相互乗り入れが可能になっている。そのため、攻撃者がクライアントマシンにtelnet NTLM認証を実行させることができれば、前述のようなクライアントのサーバ機能に対するリバースログオンが行われてしまう[4]。 telnetやInternet ExplorerのNTLM認証は、デフォルトでイントラネット上のホスト（Internet Explorerのイントラネットゾーンに属するホスト）に対して、現在のユーザで自動的に実行されるようになっている。つまり組織内部でのマン・イン・ザ・ミドル攻撃に対して脆弱であるわけだ。そもそもマン・イン・ザ・ミドル攻撃は、組織内部における脅威が大きいことを考えると、このようなNTLM認証の自動実行は極力制限することが望ましい。そのためにはInternet Explorerのセキュリティ設定で、インターネットおよびイントラネットゾーンについて、「ユーザー名とパスワードを入力してログオンする」をチェックすればよい（図5）。
またWindows XPではデフォルトで、ネットワーク上の共有フォルダや共有プリンタを自動的に検索する機能が有効になっているが、これによりファイル共有のNTLM認証が自動的に発生するため、この機能も停止する方がよいだろう[5]。エクスプローラのフォルダオプションで、「ネットワークのフォルダとプリンタを自動的に検索する」のチェックをはずすことによりこの機能を止めることができる。 3) クライアントマシン上でサーバ機能を停止するクライアントマシンに対するリバースログオン攻撃を防ぐには、クライアントマシン上で稼動しているサーバ機能（Serverサービス）を停止することが最も確実である。もちろん何らかの理由でサーバ機能が必要な場合は別だが、特にワークグループ環境下で使用しているクライアントコンピュータ上では、ファイル共有やプリンタ共有のサーバ機能を必要とするケースはほとんどないと考えられる。不正にネットワークログオンされないためにも、そのようなクライアントマシンではサーバ機能を停止しておくことが推奨される。サーバ機能を停止するには、管理ツールの「サービス」ウィンドウを起動し、Serverサービスを選択して「停止」を実行する。さらにServerサービスの「スタートアップの種類」を「無効」に設定しておけば、OSの再起動時に自動的にServerサービスが立ち上がることはなくなる（図6）。
[1] The NTLM Authentication Protocol
http://davenport.sourceforge.net/ntlm.html
[2] Common Internet File System (CIFS) Technical Reference
http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf
[3] SMB署名に関するメモ
http://www.port139.co.jp/ntsec_smbsig.htm
[4] Windows 2000 telnetクライアントのNTLM認証問題
http://www.st.rim.or.jp/~shio/w2kworld/w2ktelnet/
[5] Windows XP でネットワークのプリンタとフォルダの自動検索を無効にする方法
http://support.microsoft.com/default.aspx?scid=kb;jpn;320138
2004年3月執筆 |
