SPN通信 2015年5月7日NTLM認証を発生させる「Redirect to SMB」みなさん、こんにちは。 SPNの塩月です。 先月、「Redirect to SMB」という攻撃手法に関するブログ記事およびホワイトペーパが公開されました。今回のSPN通信はWindowsシステムをターゲットとしたこの攻撃手法と、それに対する効果的な対策方法について解説したいと思います。
Redirect to SMBの基本的な考え方は以下の通りです。 (1) ターゲットマシン(Windowsシステム)がHTTPリクエストを発信 (2) 攻撃者がそれに対しURL「file://攻撃者のIPアドレス/」へリダイレクト (3) ターゲットマシンがファイル共有のSMBプロトコルで攻撃者へアクセス (4) ログオンユーザの認証情報を使用したNTLM認証が発生 +-----------+ +-----------+ | | HTTPリクエスト | | | | -----------------------------> | | | | file://10.1.1.1/へリダイレクト | | | Target | <----------------------------- | Attacker | | | | | | (Windows) | -----------------------------> | (10.1.1.1)| | | SMBプロトコルでアクセス | | | | | | | | | V | | | | NTLM認証が発生 | | +-----------+ +-----------+例えばターゲットマシンのIE(Internet Explorer)がどこかのWebサイトへアクセスを開始したとしましょう(上記の1に相当)。攻撃者はそのHTTPリクエストに対してリダイレクトの返答を返します。リダイレクトというのはWebサイトのURLが変わった際などに用いられる、別のURLへとブラウザを導く返答のことで、一般的なWebサイトでもリダイレクトはよく行われます。ただここで攻撃者は通常のWebサイトのURLを表す「http://IPアドレス/」ではなく、ファイルシステムへのアクセスを表す「file://IPアドレス/」を用いてリダイレクトを行います(上記の2)。 URL中のコロンの前にある「file」という指定はURLスキームの一種です。URLスキームは一般的には「http」や「https」または「ftp」などのプロトコルが使用されますが、特定のファイルシステム上のコンテンツを参照したい場合のためにfileというスキームが用意されています。通常、fileスキームのURLでは「file:///c:/windows/temp/aaa.html」のようにホスト名／IPアドレスを省略し、ローカルファイルシステム上のファイルを表示させるために使用しますが、OSやソフトウェアの実装によってはホスト名／IPアドレスを指定してリモートファイルシステムにアクセスすることもできます。 「file://10.1.1.1/」のリダイレクト要求を受けたIEがどのように振る舞うかというと、IPアドレス「10.1.1.1」に対しWindowsのファイル共有プロトコル「SMB」を使用して当該ホストへのアクセスを行います(上記の3)。SMBプロトコルでリモートホストへアクセスする際には、通常、ユーザ認証が必要となりますが、Windowsシステムでは基本的にまずローカルホストにログオンした際のユーザ認証情報(ユーザIDおよびパスワード)を使用してリモートに対し自動的に認証を試みます。この時に発生するのがログオンユーザの認証情報を使用した「NTLM認証」です(上記の4)。ちなみにドメインアカウントでローカルログオンしている場合でも、アクセス先のホストがIPアドレスで指定されているとWindowsはKerberosではなくNTLMで認証を行います。 IEがfileスキームのURLに対してSMBアクセスを行い、NTLM認証を発生させることは昔から広く知られていました。今回公開された記事で新しく報告されているのは、IE以外のさまざまなソフトウェアについても、上記のようにリダイレクトの仕組みを使用することでNTLM認証を発生させることが可能だということです。Webブラウザ以外でHTTP(あるいはHTTPS)リクエストを発信するソフトウェアは数多くあります。例えばソフトウェアのアップデートでHTTPを使用する場合は多いでしょう。またインターネットからデータを取得する際にHTTPを使うソフトウェアもあります。攻撃者がARPキャッシュ汚染や偽Wi-Fiスポットなどの手法でそのマシンとインターネットとの間に割り込み、ソフトウェアが発信するHTTPリクエストをキャッチすれば、任意のHTTPリクエストに対してリダイレクトのレスポンスを返すことができます。つまり当該記事は、攻撃の機会が今まで考えられていたよりも実は多いという警鐘を鳴らしているわけですね。記事の中では例としてAdobe Reader、QuickTime、Windows Media Player、Excelなどがあげられていますが、特定のAPIを使用しているソフトウェアでこのような問題が起こるとのことです。 それでは攻撃者のマシンに対してNTLM認証が発生することにより、どのようなリスクが生じるのでしょうか? まず考えられるのは、ターゲットマシンにログオンしているユーザのパスワードがオフラインクラックによって解析されてしまう危険性です。NTLMではチャレンジ・レスポンス方式の認証が行われますが、攻撃者は自分あてに認証を発生させることでこれらの情報を取得し、オフラインで時間をかけてパスワードを解析することができます。パスワードの解析にどれだけの時間がかかるかは攻撃者が保有するコンピュータ資源とパスワードの複雑さ、およびNTLMのバージョンに依存します。最近のWindowsシステムはデフォルトでより解析の困難なNTLMv2を使用していますが、それでも複数のGPU(Graphics Processing Unit)を搭載した数十万円程度のコンピュータで8文字の英大文字小文字数字を組み合わせたパスワードが9.5時間以内にブルートフォースできると言われています。
二つ目にあげられる危険性としてNTLM認証のリレー攻撃があります。Windowsシステムには許可された別のWindowsマシンに対して透過的にアクセスするシングルサインオンの機能が備わっています。この機能を利用し、ターゲットマシンから受け取った認証情報をそのマシンがアクセス可能な別のWindowsマシンへリレー(中継)することで、リレー先のマシンに不正にアクセスするのがNTLM認証のリレー攻撃です。シングルサインオンで運用されるWindowsドメイン環境内に攻撃者が存在する場合、この攻撃によりさまざまなWindowsマシンがセキュリティ侵害を受けてしまう危険性が生じます。 Redirect to SMBが引き金となってNTLM認証が発生することにより、これらの危険性へと発展するわけですが、このようなWindowsの振る舞いは基本的に仕様であり、現時点ではパッチ適用で解消できるものではありません。前述のJVNVU#99430390(脆弱性レポート)は回避策として以下をあげています。 ■ 外部ネットワーク向けのSMB通信を遮断する
■ 強固なパスワードを設定し定期的に変更する
■ NTLM認証の発生を制限する
今回のRedirect to SMB問題は、NTLM認証の自動発生により生じる危険性を改めて認識するよい機会になったと思います。NTLM認証は思いもよらぬタイミングでユーザの意思に関わらず発生します。上記のNTLM認証を制限するセキュリティオプション設定は、うまく使えばきわめて有効な対策になりますので、まず導入の容易な家庭環境で試してみてはいかがでしょうか。 それではみなさん、またお会いしましょう。
合同会社セキュリティ・プロフェッショナルズ・ネットワーク
|