Windows 2000 telnetクライアントのNTLM認証問題
Windows 2000 World 2000年12月号
月刊セキュリティレポート No.11
|
本文書は、Windows 2000 World誌に寄稿した記事の原稿を、IDGジャパン編集部殿の許可を得た上で掲載したものです。
|
Windows 2000のtelnetクライアントのNTLM認証により、クライアントのパスワードがオフラインでクラックされたり、認証情報を利用して不正にネットワークログオンされる危険性が指摘された[1][2]。マイクロソフトはこの問題に対し、セキュリティ情報、回避策、および修正モジュールを提供している[3][4]。
NTLM認証とは
NTLM（NT LanMan）認証とは、Windows NTファミリーで共通して使用されるユーザ認証方式で、ファイル共有やプリンタ共有時のネットワークログオン（SMB認証）、IISにおける暗号化認証、Windows 2000のtelnetクライアント/サーバ間の認証等、さまざまな局面で使用される。
NTLM認証ではチャレンジ/レスポンス方式が用いられており、認証の際にネットワーク上をパスワードがクリアテキストで流れないようになっている。NTLM認証の概要を図1に示す。
|
図1 NTLM認証の概要。チャレンジ/レスポンス方式により、パスワードはクリアテキストで流れない。
|
1. クライアントからサーバへ、認証を要求する。
2. サーバは8バイトのランダムなバイト列「Challenge」を生成し、
クライアントへ送信する。
3. クライアントは「Challenge」と「Password」を基に、特定の一方向関数で
24バイトの「Response」を生成し、サーバへ送信する。
4. サーバでも同様に、「Challenge」と該当ユーザの「Password」から
「Response」を生成する。
5. サーバ側で生成した「Response」とクライアントから送られてきた
「Response」を比較し、同一内容であるかどうかをチェックする。
6. 「Response」の比較によりクライアント側の「Password」とサーバ側に
ある該当ユーザの「Password」の同一性を確認し、ログオンを許可する。
7. クライアントはその後のログオン処理を実行する。
実際にはクライアントは二種類の「Response」を送信する。一つはNT系サーバへの認証で使用される「NTLM Response」、もう一つはLan Manager系のサーバへの認証で使用される「LANMAN Response」である。後者は基本的に下位互換性を保つためにサポートされている。
telnetによるNTLM認証
Windows 2000に付属するtelnetは、前述の通りNTLM認証を標準でサポートする。すなわちWindows 2000のtelnetサーバに対し、Windows 2000のtelnetクライアントでログオンを試みる場合、デフォルト状態だとクライアントマシンにログオンしているユーザの情報を使用したNTLM認証でtelnetサーバに対する認証が行なわれるのである。これにより権限を持ったユーザはわざわざパスワードを入力する手間がはぶけ、しかも通常のtelnetのようにパスワードがネットワーク上を流れることがないといった利点がある。NTLM認証を使うかどうかは、telnetクライアントおよびtelnetサーバの設定で変更することができるが、デフォルトではNTLM認証を使うように設定されている。
今回指摘されたセキュリティ問題のポイントは、Windows 2000のtelnetを用いることで「ユーザが意図せずにサーバに対してNTLM認証を行なってしまう」ことにある。
例えば次のような内容を含むWebページにユーザがアクセスしたとする。
<iframe src="telnet://192.168.0.1/"></iframe>
これは指定されたURLの内容をフレームに表示するというHTMLの記述だが、URLにtelnetプロトコルが指定されているためクライアントマシンではtelnetクライアントが起動され、192.168.0.1のIPアドレスを持つサーバマシンにtelnetで接続が行なわれる。その際にサーバマシン側でNTLM認証をサポートするtelnetサーバが動いていた場合、telnetクライアントはNTLM認証を実行する（図2）。つまり、攻撃者はユーザに不正なWebページをアクセスさせることにより、特定のサーバマシンに対してNTLM認証を実行させることができることになる。ちなみにこれはHTMLメールを使用しても実現可能である。
|
図2 不正なWebページをアクセスさせることでクライアントマシン側でtelnetが起動、Webサーバに対してNTLM認証を実行させる。
|
このようにtelnetの認証でNTLMを使うのはWindows 2000のtelnetクライアントのみであり、NTやWindows 95/98ではこの問題は発生しない。
パスワードクラックの危険性
クライアントが悪意のあるサーバに対してNTLM認証を実行することにより、クライアントのパスワードがオフラインでクラックされる危険性がある。図1で示した通りNTLM認証ではパスワードはクライアント/サーバ間で直接送受信されることはなく、チャレンジとレスポンスを介してパスワードの同一性をチェックする。またレスポンスは一方向関数を用いて生成されるため、レスポンスからパスワードを導き出すことは事実上不可能である。しかし、悪意のあるサーバ側でチャレンジとレスポンスの両方を手に入れることができれば、さまざまなパスワードを片っ端から一方向関数にかけ、その結果とクライアントから受け取ったレスポンスとを比較することで元のパスワードを割り出すことが理論上可能になる。
さらにこの場合、チャレンジを発行するのは悪意のあるサーバであるため、攻撃者は任意のチャレンジをクライアントに送ることができる。チャレンジを特定のバイト列（例えばすべて0x00）に固定することにより、攻撃者はパスワードクラックをより効率的に行なうことができる。
NTのパスワードクラックツールとして有名なL0phtCrack[5]は、NTLM認証のチャレンジとレスポンスを基にパスワードをクラックする機能を持つ。上記の手法で入手したtelnetのNTLM認証のチャレンジ/レスポンスをL0phtCrackで解析することは可能である。このように一般的に入手できるツールで手軽にパスワードをクラックされる危険性があるのだ。
ネットワークログオンの脅威
この問題におけるもう一つのより重大な危険性は、NTLM認証のチャレンジ/レスポンスを「再利用」することで不正にネットワークログオン（ファイル共有等）を許可してしまうことだ。
図3に例として一つのシナリオを示す。ここでは「攻撃者側」が、telnetのNTML認証でやりとりされるレスポンスをファイル共有等のネットワークログオン（SMB認証）で再利用している。
|
図3 telnetのレスポンスを再利用することで、ファイル共有のSMB認証をパスワードなしで実現する一例。
|
1. 攻撃者側から被害者側へ、ファイル共有のSMB認証を要求する。
2. 被害者側は8バイトのランダムなバイト列「Challenge」を生成し、
攻撃者側へ送信する。
3. 攻撃者は前述の手法を用いて、攻撃者側へ強制的にtelnetセッションを
生成させる。
4. 攻撃者はこのtelnetセッションのNTLM認証用チャレンジとして、
被害者側から先に受け取った「Challenge」を再利用し、送り返す。
5. 被害者側は「Challenge」と「Password」を基に、特定の一方向関数で
24バイトの「Response」を生成し、攻撃者側へ送信する。
6. 攻撃者は受け取った「Response」をSMBセッションのNTLM認証用
レスポンスとして再利用し、被害者側へ送り返す。
7. 被害者側では、先に生成した「Challenge」と「Password」から
「Response」を生成する。
8. これらの「Response」はまったく同一の「Challenge」と「Password」
から生成されたものであるため、当然同一内容となる。
9. 以上により、被害者側マシンは攻撃者側からのSMB認証によるログオン
を許可する。
10. 攻撃者側はその後のログオン処理を実行する。
図を見ていただければわかる通り、このシナリオでは「攻撃者側」は「被害者側」のパスワードを知る必要がまったく無い。つまりWindows 2000マシンからtelnetセッションを受け付けるだけで、そのマシンに対してパスワードなしでネットワークログオンできてしまうのである。
ちなみにこの攻撃方法は単なるコンセプトではない。SAMBAに付属するsmbclientのソースコードを改造することでこの攻撃用のツールを作成することは実際に可能である。
対策方法
今回のWindows 2000 telnetクライアントにおけるNTLM認証の問題は、以下のいずれかの対策により回避することができる。
1. telnetクライアントの設定変更によりNTLM認証を禁止する
2. 修正モジュールを適用する（本原稿執筆時点では、日本語版は未提供）
1は本質的な対策ではないものの、telnetでNTLM認証を行なわない環境下であればその機能をOFFにしておいた方が良いだろう。ただしNTLM認証しか受け付けないように設定されているWindows 2000 telnetサーバ（デフォルト）に対してアクセスできなくなるので、注意が必要である。
以下の手順により、telnetクライアントでのNTLM認証を禁止することができる（図4）。
|
図4 telnetクライアントでNTLM認証を行なわないように設定する。
|
1) telnetをパラメータなしで起動する
2) telnetのプロンプトに対し、「unset NTLM」と入力する
3) displayと入力する
4) 「自動認証 (NTLM 認証) を使わない」と表示されるのを確認する
5) quitと入力し、telnetを終了する
きちんとした対策を施すためには、マイクロソフトが提供する修正モジュールを適用する必要がある。修正モジュール適用により、telnetクライアントはNTLM認証をサポートするtelnetサーバに接続した際に、警告メッセージを表示し、NTLM認証を実行するかどうかをユーザに確認することができるようになる（図5）。
|
図5 修正モジュールの適用により、telnetクライアントはNTLM認証を行なうかどうかをユーザに確認するようになる。（画面は英語版Windows 2000）
|
NTLM認証の実行をユーザに確認するか、それとも自動的にNTLM認証を実行するかは、Internet Explorerのゾーンセキュリティ「ユーザ認証/ログオン」の設定に依存する。インターネットゾーンのデフォルト設定では「イントラネットゾーンでのみ自動的にログオンする」となっている（図6）ため、インターネット上のホストに対して自動的にNTLM認証は行なわれない。逆に「現在のユーザ名とパスワードで自動的にログオンする」となっているようなゾーンのホストに対しては、今まで通り自動的にNTLM認証が行なわれる。
|
図6 Internet Explorerのゾーンセキュリティ設定。修正モジュールによりtelnetの自動NTLM認証がここのユーザ認証/ログオンの設定に依存するようになる。
|
今回例示したチャレンジ/レスポンスの再利用に関する危険性は、NTLM認証のオフラインクラックに対する脆弱性と共に古くから指摘されている。マイクロソフトはこれらの問題に対し、SMB署名やNTLM認証の各種設定の追加といったさまざまな対策を施してきた。しかしデフォルト状態ではいずれも脆弱性を持ったままであり、多くの場合、デフォルト状態で使用されているのが実情だと思われる。NTLM認証やSMB署名についてはPort139の伊原氏が執筆されたWindows NT World誌の記事[6]（1999年2月号、7月号）が非常に参考になるので、ぜひご参照の上、サイトの運用に適したセキュリティ対策を施されたい。
[1] Win2k Telnet.exe malicious server vulnerability
http://www.securityfocus.com/archive/1/82514
[2] NTLM Replaying via Windows 2000 Telnet Client
http://www.atstake.com/research/advisories/2000/a091400-1.txt
[3] MS00-067: Patch Available for "Windows 2000 Telnet Client NTLM
Authentication" Vulnerability
http://www.microsoft.com/technet/security/bulletin/MS00-067.asp
[4] 「Windows 2000 Telnet クライアントの NTLM 認証」の脆弱性に対する
対策
http://www.microsoft.com/japan/security/prekb.asp?sec_cd=MS00-067
[5] L0phtCrack
http://www.l0pht.com/l0phtcrack/
[6] NT Security - NT World
http://www.port139.co.jp/ntsec_ntworld.htm
2000年9月執筆
塩月 誠人
インターナショナル・ネットワーク・セキュリティ株式会社
| 