iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性

 2009.11.24  2023.03.31

iモードブラウザ2.0のJavaScriptとDNS Rebinding(DNSリバインディング)問題の組み合わせにより、iモードIDを利用した認証機能(以下かんたんログイン)に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。

HASHコンサルティング株式会社(現EGセキュアソリューションズ株式会社)
公開日:2009年11月24日
追記日:2010年1月21日

背景

携帯電話のかんたんログインとは、ケータイブラウザ(たとえばiモードブラウザ)に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送出される。現在、iモードIDは、ケータイWebアプリケーションに広く利用されている。

2009年5月より、NTTドコモの携帯電話ブラウザ(iモードブラウザ2.0)ではJavaScriptが利用できる。ケータイJavaScript機能は、その後いったん機能停止されたが、10月末より順次再開されている。

DNS Rebindingとは、DNSを利用した攻撃手法の一種で、DNSが返すIPアドレスを短時間の間に変更する。典型的な攻撃手法としては、被害者となるユーザにインターネット上のコンテンツ(A)を閲覧させた後、当該Webサーバーのホスト名に対するIPアドレスを変更し、その後コンテンツ(A)から同じホスト名に対して、JavaScriptなどにより同じホスト名に対してアクセスする。よく知られた攻撃手法は、第二のIPアドレスとしてローカルネットワークのアドレスを返して、被害者ユーザに対してローカルネットワークをアクセスさせ、その結果を攻撃者に戻すようなスクリプトを実行させる。

発見された問題

DNS RebindingとケータイJavaScriptを利用して、かんたんログインに対する攻撃が可能になるシナリオを説明する。

想定環境の説明

以下のような環境を想定して説明する。ホスト名やIPアドレスは架空のものである。

攻撃対象のWebサーバー www.hash-c.co.jp(IP:115.146.17.185)
攻撃対象ページのURL http://www.hash-c.co.jp/userinfo.php?guid=ON
ワナのWebサーバー evil.example.jp (IP:192.0.2.2)

evil.example.jpのDNS設定は、TTLが5秒に設定されているとする。
攻撃対象のURLは、かんたんログインにより、閲覧者の個人情報を表示するものとする。

攻撃シナリオ

攻撃シナリオは以下の通りである。

(0)攻撃者は、http://evil.example.jp/rebind.html を用意し、ユーザを誘導する
(1)ユーザがhttp://evil.example.jp/rebind.htmlを閲覧する
(2)rebind.htmlにアクセスした後、攻撃者はDNSを操作し、evil.example.jpのIPアドレスを115.146.171.185(攻撃対象サーバのIPアドレス)に変更する
(3)rebind.htmlは表示されてから10秒後に、JavaScriptのXMLHttpRequestにて、http://evil.example.jp/userinfo.php?guid=ONにアクセスする
(3-1)evil.example.jpのTTL(5秒)を既に経過しているので、evil.example.jpのIPアドレスを問い合わせる
(3-2)DNSサーバーは115.146.17.185を返す
(3-3)http://evil.example.jp/userinfo.php?guid=ONにアクセスしようとするが、IPアドレスが変更されているので、実体としてはhttp://www.hash-c.co.jp/userinfo.php?guid=ONにアクセスしている
(3-4)この際、iモードIDもユーザの正規のものが送出されている
(4)www.hash-c.co.jp側ではかんたんログイン認証され、個人情報を返す
(5)スクリプトは受け取った個人情報をワナサーバー(192.0.2.2)に返す

上記のシナリオを以下に図示した(Flash Playerが必要)。かんたんログインのDNS Rebinding攻撃

上記のようなシナリオにより、認証を突破され、個人情報の窃取、なりすまし等が行われる。攻撃対象のWebサーバーに複数回アクセスして、あらかじめ取り決めた画面遷移をたどることも可能である。

実証実験の内容

NTTドコモの2009年夏モデルP-07Aを用いて、上記シナリオを実機検証し、シナリオ通りの動作を確認した。

ただし、DNSのTTL設定は動作に影響しないようで、TTL=86400(有効期間一日)に設定した場合でも、10秒後のアクセスでDNSの引き直しが行われている模様である。この事実から、NTTドコモのゲートウェイ設備では、DNS情報をキャッシュしていないか、極めて短時間のキャッシュがなされているものと推測される。

影響範囲

以下の条件を満たすサイトがこの攻撃手法の影響を受ける。

  • iモードIDなど個体識別情報によるかんたんログイン、あるいはセッション管理を行っている
    (FOMAカード製造番号などを用いている場合は影響を受けない)
  • HTTPリクエストヘッダのHOSTフィールドをチェックしていない

また、影響を受けるユーザは、NTTドコモの2009年夏モデル以降を使用しており、かつJavaScript機能を有効にしているユーザに限られる。

発生しうる脅威

この攻撃が成功した場合は、攻撃者はユーザになりすまし、そのユーザに与えられた権限での全ての操作が可能となる。具体的には以下のような脅威が発生しうる。

  • ユーザの秘密情報の窃取(個人情報、Webメール、企業情報など)
  • ユーザ権限でのサービスの悪用(物品購入、不正な送金など)
  • ユーザ権限でのデータベースの更新など(不適切な内容の投稿、設定の変更など)

解決策・回避策

Webサイト提供者

以下の一つあるいは両方によりこの手法を防止できる。

  • iモードIDなど個体識別情報をかんたんログインおよびセッション管理に使用しない
  • HTTPリクエストヘッダのHOSTフィールドの正当性をチェックする
    iモードブラウザ2.0のXMLHttpRequestではHTTPヘッダの書き換えができないのでこの方式で対策になる(ケータイゲートウェイとのみ通信を許可している前提)

具体的には、以下のような実装方式が考えられる。

  • 認証には、パスワード認証(推奨)あるいはFOMAカード製造番号によるかんたんログインを使用する
  • セッションIDをURL埋め込みあるいはCookieに保持するセッション管理方式を用いる
  • HTTPリクエストヘッダのHOSTフィールドの正当性をチェックする。具体的には、名前ベースのバーチャルホストを使用する。

iモードのユーザ

iモードブラウザのJavaScript機能を無効にすることで上記攻撃を防止できる。

現状iモードコンテンツでJavaScriptを活用しているものは、まだほとんどないと考えられるので、JavaScriptの無効化がもっとも現実的なユーザの予防策となる。

携帯電話事業者(NTTドコモ)

一般的なDNS Rebinding対策としては、DNS Pinningが知られている。これは、ブラウザ側でDNSの検索結果を一定時間保持するものだが、携帯電話ブラウザはキャリアのゲートウェイ(PROXY)経由でのアクセスであるので、ブラウザ側ではDNSによるIPアドレス解決を行っていないと考えられる。このため、DNS Pinningを実装できない。

一方、前述のように、NTTドコモのゲートウェイ設備では、DNSのキャッシュを全くあるいはほとんど保持していないと考えられることから、一定時間以上DNSの結果をキャッシュすることで、予防的な対策となる。例えば、TTLの指定に関わらず最低1時間以上キャッシュを保持することで、DNS Rebinding攻撃が成功する確率をかなり低下させることができる。

技術メモ

DNS RebindingはPC用ブラウザでも成立するが、今回報告したような認証回避には悪用できない。その理由は、PC向けWebアプリケーションは、iモードIDのような固定の識別子を用いて認証していないためである。また、セッション管理に通常用いられるCookieはドメイン名により送出先サーバを特定しているので、上記シナリオのように別ドメインを指定している場合は、送出されない。

このため、パスワード認証やCookieによるセッション管理など、PC用Webアプリケーションで一般的に用いられる開発手法に従っていれば、DNS Rebindingによる認証回避やセッションハイジャックには至らないと考えられる。

訂正(2010年1月21日)

当初リリースで「FOMAカード製造番号などを用いている場合は影響を受けない」としていたが、これは誤りであり、FOMAカード製造番号などを用いている場合も影響を受ける可能性がある。FOMAカード製造番号をXMLHttpRequestにより送出する方法はないと当初考えていたが、XMLHttpRequestを用いずに別の方法で攻撃が可能であることが判明した。FOMAカード製造番号を使っている場合、利用者のブラウザ画面上に確認画面が表示されるので、そこでユーザが拒絶すれば攻撃にあわないが、巧妙な誘導などにより攻撃されれば、被害に遭うユーザも出てくると考えられる。

免責

このセキュリティ情報は予告なしに改訂される場合がある。このセキュリティ情報を適用した結果についてHASHコンサルティング株式会社(現EGセキュアソリューションズ株式会社)は一切の責任を負わず、利用者の利益のために、執筆時点のあるがままの状態で公開するものである。


RECENT POST「検証・考察」の最新記事


検証・考察

Apacheが最新版(2.4.41)かどうかを確認する方法

検証・考察

WordPressサイト移行に便利なDB置換ツールを使う際の注意点

検証・考察

診断文字列を打ち込まずにPHPのバージョンを推測する

検証・考察

httpoxyでAffected指定されているけどPoCが無いフレームワークで再現試験をした話

iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性
5分でまるわかり!WAFによるサイバー攻撃対策
1分でわかる「SiteGuardシリーズ」
RECENT POST 最新記事
ブログ無料購読
RANKING人気記事ランキング