Black Hat USA 2016／DEF CON 24 ラスベガス現地レポート 第2回

自動プロキシ設定機能の悪用で通信乗っ取りのリスク、Black Hat 2016で報告

東京都庁の通信内容がダダ漏れ危機？「badWPAD」脆弱性とは

　「Black Hat USA 2016」レポートの第1回記事では、NetBIOSの「BadTunnel」脆弱性を悪用する攻撃例として「WPAD（Web Proxy Auto-Discovery）」を組み合わせた手法が登場した。だが実は、このWPAD自体にも、未だ修正されていない別の脆弱性が存在する。

　8月5日、Black Hatの講演で登壇した元トレンドマイクロのマキシム・ゴンチャロフ氏が、「badWPAD」と名付けられたこの脆弱性の実態調査結果を発表した。これを悪用すれば、ターゲットを攻撃者のプロキシサーバーに接続させることができ、フィッシングサイトへの誘導、偽の認証画面を使ったログイン情報詐取（中間者攻撃）、通信内容の監視など、幅広い攻撃が可能になる。

　しかもゴンチャロフ氏の調査では、東京都が使っている多数のクライアントPCが、現在進行形でそのリスクを抱えていることも具体的に明らかにされている。

元トレンドマイクロのマキシム・ゴンチャロフ氏。最近ドイツ企業に転職したばかりだという

自動でプロキシ設定を行うWPAD、その単純な仕組みを知る

　WPADは、ブラウザが使うプロキシサーバーを自動的に設定するプロトコルだ。20年前の1996年に「Netscape Navigator 2.0」で初めて実装され、現在も「Internet Explorer」や「Firefox」「Chrome」「Safari」などで採用されている、デファクトスタンダードの技術である。

Windows／Internet Explorerの設定画面。初期設定ではWPAD（設定を自動的に検出する）が有効になっている

　大規模な企業や組織では、アクセス制御や負荷分散などを目的として、社内ネットワークからのWebアクセスをプロキシ経由で提供しているケースが多い。しかし、多数のクライアントPCに対して1台ずつ、手作業でプロキシサーバーを設定していくのは大変だ。そこで、一括設定できるWPADが活躍することになる。

　WPADの仕組みを見てみよう。WPADでは、ネットワーク管理者が社内サーバー上に配置した設定ファイル「wpad.dat」をクライアントPC（ブラウザ）がダウンロードし、ファイルに書かれたプロキシサーバーへの接続設定を反映する。前述した自動プロキシ設定機能が「有効」になっていれば、これらの処理はすべて自動で実行される。

　しかし、これだけでは管理者が配置したwpad.datファイルのありか（URL）がわからない。そこでWPADでは、設定ファイルのURLを自動的に検出する手段を2種類、用意している。

　1つめの手段は、あらかじめDHCPサーバーにwpad.datファイルのURLを教えて（設定して）おき、DHCPサーバーがブラウザにそれを通知するというものだ。具体的にはDHCPのオプション252を使い、ブラウザからのリクエストに応じてwpad.datファイルのURLをレスポンスする。

1つめの手段、DHCPサーバーのオプション。これでうまくいかなければ2つめの手段へ

　1つめの手段でURLがうまく取得できない場合は、2つめの手段として、単純なルールに基づいて設定ファイルのサーバーを探す。たとえば、接続しているネットワークのDNSサフィックス（検索ドメイン）が「infosec.mycompany.org」であれば、頭に「wpad.」を付けてホスト名を生成し、「http://wpad.infosec.mycompany.org/wpad.dat」というURLにアクセスする。ここに設定ファイルがなければ、次は「http://wpad.mycompany.org/wpad.dat」、その次は「http://wpad.org/wpad.dat」と、ドメインを1階層ずつさかのぼりながらファイル探索を繰り返す。

2つめの手段、ネットワークのDNSサフィックスからWPADサーバーを推測し、探索する

　このように、WPADの仕組みは単純であり、セキュリティも考慮されていないため簡単に悪用できる。特に、上述した“2つめの手段”の動きを悪用して、攻撃者が「wpad.～」というホスト名でwpad.datの配布サーバーを立てておけば、WPADが有効になっているブラウザが勝手に設定ファイルを取得し、攻撃者が用意したプロキシサーバーに接続してくれる。

　もっとも、企業や組織の管理下にあるドメインを使った攻撃（たとえば「wpad.kadokawa.co.jp」というホスト名を使うような攻撃）は、内部犯でなければ実行は難しいだろう。だが、もしも「wpad.org」のような「wpad.＋TLD（トップレベルドメイン）」という形のドメインが取得できてしまえば、広範なターゲットに対して攻撃を実行できてしまう。しかも、すべて自動で処理されるため、ユーザー自身がこの攻撃を受けていることに気づくのは難しい。

　こうしたWPADのセキュリティリスクは、実は以前から指摘されてきたものだ。しかし、未だ修正されていないため、ブラウザやOSの実装側で探索先のドメイン範囲を絞り込む、TLDを運用管理するレジストリ側でそうしたドメインを取得できないようにする、といった対応が取られてきた。しかし、近年になってTLDの種類が一気に拡大し、レジストリの対応が追いついていないケースもあるようだ。

JPCERT/CCとIPAが共同運用する脆弱性情報ポータルのJVNでも、今年5月付けでWPAD問題への警告が掲載されている