SPN通信 2015年5月7日

NTLM認証を発生させる「Redirect to SMB」


みなさん、こんにちは。 SPNの塩月です。

先月、「Redirect to SMB」という攻撃手法に関するブログ記事およびホワイトペーパが公開されました。今回のSPN通信はWindowsシステムをターゲットとしたこの攻撃手法と、それに対する効果的な対策方法について解説したいと思います。

  • SPEAR - Redirect to SMB
    http://blog.cylance.com/redirect-to-smb

  • Windows NTLMがfile://URLへのリダイレクト時にSMB接続を行いユーザ認証情報を送信する問題(JVNVU#99430390)
    https://jvn.jp/vu/JVNVU99430390/

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時間以内にブルートフォースできると言われています。

  • hashcat
    http://hashcat.net/oclhashcat/

二つ目にあげられる危険性としてNTLM認証のリレー攻撃があります。Windowsシステムには許可された別のWindowsマシンに対して透過的にアクセスするシングルサインオンの機能が備わっています。この機能を利用し、ターゲットマシンから受け取った認証情報をそのマシンがアクセス可能な別のWindowsマシンへリレー(中継)することで、リレー先のマシンに不正にアクセスするのがNTLM認証のリレー攻撃です。シングルサインオンで運用されるWindowsドメイン環境内に攻撃者が存在する場合、この攻撃によりさまざまなWindowsマシンがセキュリティ侵害を受けてしまう危険性が生じます。

Redirect to SMBが引き金となってNTLM認証が発生することにより、これらの危険性へと発展するわけですが、このようなWindowsの振る舞いは基本的に仕様であり、現時点ではパッチ適用で解消できるものではありません。前述のJVNVU#99430390(脆弱性レポート)は回避策として以下をあげています。

■ 外部ネットワーク向けのSMB通信を遮断する

    インターネット等の外部ネットワークに攻撃者が存在する場合、ルータやファイアウォールで外向きのSMBプロトコル(TCP/139またはTCP/445)を遮断することが有効です。企業内では既にそのような設定を行っているケースが多いと思われますが、家庭のインターネット環境についても今一度、外向きのフィルタ設定を確認した方がよいでしょう。

■ 強固なパスワードを設定し定期的に変更する

    どの程度のパスワードが強固かというのは使用状況や時代によって変わってきます。NTLMの認証情報が奪われることを想定するのであれば、前述の通り8文字のパスワード長はもはや十分ではありません。英数記号で少なくとも10文字は必要だと思われます。Windows 8以降、マイクロソフトアカウントを使用してローカルログオンしている方も多いでしょうが、マイクロソフトアカウントのIDとパスワードが漏洩してしまうとそのインパクトは非常に大きくなるため注意が必要です。

■ NTLM認証の発生を制限する

    Windows 7以降、セキュリティオプション設定の変更でNTLM認証の送信や着信を制限できるようになりました。これを使用すればドメイン環境およびスタンドアローン環境でNTLM認証をきめ細かに制御することが可能です。例えば家庭内でWindows PCを使用しており、ファイルサーバやリモートデスクトップによるアクセス先などがない場合、NTLM認証の送信をすべて拒否しても通常は問題ないでしょう。ファイルサーバがある場合はそれに対するNTLM認証を例外的に許可させることで対応できます。ドメイン環境でNTLM認証を制限したい場合は、現状どのようなケースでNTLM認証が発生しているかをあらかじめ調べ、システム運用に問題が生じないように設定する必要があります。セキュリティオプション設定にはNTLM認証の発生状況をイベントログで監査するための項目が用意されていますが、規模の大きなドメイン環境でNTLM認証を制限するのは結構大変かも知れませんね。

    • Using security policies to restrict NTLM traffic
      https://technet.microsoft.com/en-us/library/jj865668(v=ws.10).aspx

    • NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7
      http://blogs.technet.com/b/askds/archive/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7.aspx

今回のRedirect to SMB問題は、NTLM認証の自動発生により生じる危険性を改めて認識するよい機会になったと思います。NTLM認証は思いもよらぬタイミングでユーザの意思に関わらず発生します。上記のNTLM認証を制限するセキュリティオプション設定は、うまく使えばきわめて有効な対策になりますので、まず導入の容易な家庭環境で試してみてはいかがでしょうか。

それではみなさん、またお会いしましょう。

合同会社セキュリティ・プロフェッショナルズ・ネットワーク
代表社員 塩月誠人


※ 本サイトに掲載されている社名、団体名、製品名等は、それぞれ各社・各団体の商標または登録商標です。

Copyright (C) 2015 Security Professionals Network Inc. All Rights Reserved.