[PR]小規模ECサイトに最適なWAF、SiteGuard Lite

徳丸浩の日記


2009年08月05日 i-mode2.0セキュリティの検討

_携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性

このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。

5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。

実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止した頃から、私の頭の中には一つの仮説があったのだが、JavaScript機能が再開されてから確認しようと思ってそのままにしていた。しかし、中々JavaScript機能が再開されないことと、早期にサイト開発者に注意を呼びかけて予防的な対応をしてもらった方がよいと考えたことから、ここにその仮説を公開する。

その仮説とは、タイトルに記した通り、携帯電話のJavaScriptを悪用して「かんたんログイン」に対してなりすましが可能かどうかというものだが、攻撃が成立するための条件をまとめると以下のようになる。

  1. 携帯電話のJavaScriptでXMLHttpRequestオブジェクトが利用できる
  2. XMLHttpRequestにてsetRequestHeaderメソッドが利用できる
  3. setRequestHeaderメソッドにてUserAgentなどのリクエストヘッダが書き換えできる

iモード2.0の仕様書によると、上記の(1)と(2)を満足している。(3)については何も書いていないが、特にできないとも書いていないので、iモード2.0で上記が可能かもしれない。JavaScript機能が停止されていることから、現時点では確認する手段がない。

以下、具体的に説明する。

iモードの場合

iモードの「かんたんログイン」の場合、iモードIDか、FOMA端末製造番号あるいはFOMAカード製造番号(UIM)を使う。iモードIDは、拡張リクエストヘッダ「X-DCMGUID」に、FOMA端末製造番号およびFOMAカード製造番号はUserAgentに付与される。

したがって、UserAgentあるいはX-DCMGUIDをsetRequestHeaderメソッドにて書き換えれば、任意ユーザになりすましが可能になる。これが可能になる条件としては、攻撃対象となるWebサイトにクロスサイトスクリプティング(XSS)脆弱性がある必要がある。他のサイトからでは、XMLHttpRequestのSame Origin Policyの制限のため送信できない*1

すなわち、iモードの「かんたんログイン」を突破するのに必要な条件は以下のようになる。

  • setRequestHeaderにてUserAgentあるいはX-DCMGUIDを書き換え可能
  • 攻撃対象サイトにXSS脆弱性がある

前者に関しては、現在iモード2.0のJavaScript機能が停止されているので確認できない。X-DCMGUIDに関しては、おそらくドコモのゲートウェイで付与していると思われるので、ゲートウェイ側で削除するかもしれない。SSL通信の場合は、HTTPリクエストの内容をゲートウェイにて追加・変更・削除ができないが、元々X-DCMGUIDはSSLで受け取れないので、アプリケーションがSSLでもX-DCMGUIDを受け付けるか否かは、サイト側の実装に依存する。setRequestHeaderによるUserAgentの書き換えは、Firefoxでは可能なので、iモード2.0でも可能かもしれない。この場合は、後述のように、他事業者(au、ソフトバンク等)のユーザへのなりすましも可能になる場合がある。

後者に関しては、京セラコミュニケーションシステムが発行している「2009年版 Webアプリケーション脆弱性傾向」によると、携帯電話向け44サイトを含む177サイトを検査した結果、67%のサイトにXSS脆弱性がある。残念ながら携帯向けサイトだけの比率は公表されていないが、おそらく携帯電話向けサイトでも多くの割合でXSS脆弱性が検出されていると思われる。

au(KDDI)ユーザへのなりすまし

iモード2.0の端末を使って、auのユーザになりすましができる可能性がある。その条件は以下のようなものだ。

  • 携帯事業者(auであること)の判定をリクエストヘッダ(UserAgentまたはX-UP-SUBNO)のみで行っている
  • setRequestHeaderにてリクエストヘッダX-UP-SUBNOが追加できる
  • 事業者判定をUserAgentで行っているサイトの場合は、setRequestHeaderにてUserAgentが書き換え可能
  • 攻撃対象サイトにXSS脆弱性がある

ここで、一番目の条件について説明する。携帯事業者の判定方法には、一般に、

  1. IPアドレスを使用する方法
  2. UserAgentを使う方法
  3. 両者を併用する方法

の三種がある。かんたんログインの実現には、PCからのなりすまし防止のため、IPアドレスの帯域チェックは不可欠だが、IPアドレスのチェックを事業者の判定まではせず、単に「携帯電話からのリクエスト」であることのみを確認する場合があるのだ。

IPアドレス制限を実装する方法としては、

  1. ファイアウォールで制限する
  2. Webサーバの機能で制限する(Apacheの場合はhttpd.confや.htaccessに記述)
  3. アプリケーションで判定して制限する

の三通りがある。この中で、PC(携帯電話でない端末)からの攻撃を確実に防ぐという点では(i)がもっとも優れており、以下(ii)、(iii)の順になる。(iii)の場合だと、Webサーバ(Apache等)やアプリケーションサーバ(Tomcat、PHP等)に対する攻撃は止められないからだ。一方、(iii)を使用している場合は、IPアドレス帯域から事業者を判定することは容易だ。

以前紹介した書籍「PHP×携帯サイト 実践アプリケーション集」の場合は、まずUserAgentから事業者を判定しておいて、IPアドレスチェックの際に、当該の事業者のIP帯域に含まれているかを確認しているので、上記分類でいえば(c)および(iii)の組み合わせに相当する。一方、最近公開された実際に動いてすぐ使える「PHPによるかんたんログインサンプル」を作ってみました*2では、IPアドレスの制限は.htaccessで行うように指示しており、IPアドレスによる事業者のチェックはしていないので、同じく(b)および(ii)の組み合わせに相当する。

話を戻すと、方法(b)を用いた場合、携帯電話によるなりすまし行為が可能になった場合、若干脆弱になる。つまり、携帯電話JavaScriptのsetRequestHeaderメソッドにより、他事業者へのなりすましの可能性がある。すなわち、ドコモの携帯電話からの攻撃なので、IPアドレス帯域は携帯事業者のものである。UserAgentの書き換えが行われているので、アプリケーションはau携帯からのリクエストと誤認する。そこで、JavaScriptによるリクエストヘッダX-UP-SUBNO(EZ番号)追加により、別ユーザになりすましができるというシナリオである。

ソフトバンクの携帯電話ユーザへのなりすまし

ソフトバンク・ユーザに対するなりすましも、auの場合とおおむね同じだ。ソフトバンクの場合、個体識別番号が二種類ある。端末シリアル番号(UserAgentに付与)とユーザID(リクエストヘッダX-JPHONE-UID)である。そこで、なりすまし可能となる条件は以下の通りだ。

  • 携帯事業者(ソフトバンクであること)の判定をリクエストヘッダ(UserAgentなど)のみで行っている
  • setRequestHeaderにてUserAgentが書き換え可能
  • setRequestHeaderにてX-JPHONE-UIDが書き換え可能(ユーザIDで認証している場合)
  • 攻撃対象サイトにXSS脆弱性がある

NTTドコモへの要望

携帯JavaScriptによる、かんたんログインへのなりすまし攻撃の可能性について検討した。前述のように、現在iモード2.0端末のJavaScript機能は停止されており、上記条件を確認することはできない。おそらく、NTTドコモ社および端末メーカー、ブラウザメーカーは上記のような懸念も含めて対策をしておられる最中なのだろうと想像する。

本稿の検討により、携帯電話のJavaScriptでは、setRequestHeaderメソッドに一定の制限を設ける必要があることがわかる。

  • UserAgentを書き換えできないようにする
  • X-DCMGUID、X-UP-SUBNO、X-JPHONE-UIDなど、他事業者のものを含め、個体識別番号の指定に用いられるリクエストヘッダの指定もできないようにする

とくに、UserAgentの書き換え防止は重要である。さらに安全を期するためには、setRequestHeaderには大幅な制限を設けるのがよく、安全な仕様の例としては、追加・書き換え可能なリクエストヘッダをホワイトリストとして指定することなどが考えられる。

Webアプリ開発者側の対策

ここまで説明したように、かんたんログインに対するJavaScriptによるなりすましでは、いずれのパターンでもXSS脆弱性を悪用している。従って、XSS対策を行うことが根本的な対策になる。携帯電話向けだからと言って手を抜かないことが重要だ

また、保険的対策として、以下を推奨する。

  • かんたんログイン以外の認証手段を用意しておく
  • 重要な処理の前でパスワードなどによる再認証を求める
  • 携帯電話事業者の判定にIPアドレスを利用する

さらにいえば、究極の根本対策として「かんたんログインを使用しない」ことも検討いただきたい。

まとめ

携帯電話のJavaScriptとXSS脆弱性の組み合わせにより、かんたんログインに対するなりすましの可能性について報告した。

通常のXSS脆弱性に対する攻撃が、正規ユーザを媒介とした受動的攻撃であるのに対して、かんたんログインのなりすましは能動的な攻撃となる*3。それだけ、被害の規模も大きくなることが想定される。

かんたんログインに対する脅威はJavaScriptばかりではない。hideden氏の8月1日付けの日記「SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ」で示されたような、携帯電話をモデムとして使用して事業者のゲートウェイ経由でのアクセスが可能となる場合にも、同様のなりすましの懸念がある。参照先ではソフトバンクモバイル内でのなりすましのみ指摘されているが、本稿で示したUserAgentの書き換えを併用することにより、他事業者(ドコモ、auなど)ユーザへのなりすましも懸念される。こちらの方法は、攻撃自体はPCからできるので、いっそう深刻な問題と言えるかもしれない。

そして、おそらくこの種の脅威は今後も形を変えて現れるだろう。その理由は、かんたんログインという手法が、もともと暗号学等の理論的な根拠に裏付けられておらず、携帯電話網という閉じた世界でのみ通用する手法であるからだ。今後、携帯電話そのものの高機能化や、携帯電話網への多様な端末の投入により、その前提が覆る可能性は十分あるし、その兆候は既に現れてる。

とすれば、少なくとも「いつでもかんたんログインを捨てられる」状態にしておくことが、ユーザも、Webサイト運営者自身をも守る最低限の取り組みであると、私は考える。

最後に

若干の宣伝をさせてください。筆者の経営するHASHコンサルティング株式会社では、Webアプリケーションの安全性に関するコンサルティングや脆弱性検査サービスなどを提供しています。携帯電話向けサイトの脆弱性対策については10年ほどの経験があります(前職での経験を含みます)。ご相談はこちらからお気軽に。

HASHコンサルティングは非常に小さな会社ですので、与信などの点で心配される向きもあろうかと思います。その場合は、私が技術顧問をしている 京セラコミュニケーションシステム株式会社にご相談いただければと思います。問い合わせフォームから「技術顧問の徳丸に相談したい」と書き添えていただければ確実かと思います。

様々な形で、貴社のWebサイトの安全にお役に立つことができれば幸いです。

2009/10/26追記

ようやく10月末からiモードブラウザ2.0のJavaScript機能が再公開されると発表がありました。これに合わせて、KCCSにて11月12日(木曜)、11月19日(木曜)、12月10日(木曜)の3回にわたり、ケータイWebセキュリティのセミナーを実施することになりましたので、興味のある方は、こちらのリンクから内容確認の上お申し込みください。

*1 これに関しては実機での確認が間に合った

*2 このエントリは私が見たかんたんログインの解説としてはもっとも行き届いていると思う

*3 これをXSSと呼んでよいかどうかは議論があるだろうが、攻撃形態により脆弱性の呼び名を変えるのも煩わしいこと、XSSが既に定着した名称であることから、本稿ではXSSという呼び方で統一した

本日のツッコミ(全8件) [ツッコミを入れる]
_ 匿名の臆病者 (2009年08月06日 09:05)

勝手サイトよりも公式サイトのほうが影響が深刻化もしれません。なぜなら公式サイトではuid/EZ番号以外の認証手段が用意されていないからです。風の噂では、簡単ログインが擬装されるのではなく「公式サイトで」他人のなりすましが出来たと聞きました。

_ ketaiorg (2009年08月06日 11:03)

こんにちは、ke-tai.orgのmatsuiと申します。<br>このような良エントリーに当ブログの記事を取り上げていただきありがとうございます。<br><br>ご指摘大変参考になりました。<br>質問なのですが、.htaccessによる帯域制限に加えて、「X-DCMGUID、X-UP-SUBNO、X-JPHONE-UIDのうち2つ以上に値がセットされていた場合は接続をはじく」とするだけで、安全度が結構あがる気がしています。(各キャリア側でヘッダ情報を上書きしてくれることが前提)<br>メリットとしては実装が非常に簡単なことなのですが、この対策は効果がありそうでしょうか。<br>ご意見を伺えればと思います。<br>よろしくお願いいたします。

_ 徳丸浩 (2009年08月06日 11:22)

matsuiさん、こんにちは。コメントありがとうございます。<br>さて、「X-DCMGUID、X-UP-SUBNO、X-JPHONE-UIDのうち2つ以上に値がセットされていた場合は接続をはじく」というアイデアは、私には効果が薄いように感じられます。<br>というのは、なりすましというのは、固体識別番号をなんらかの方法で入手して行うものであり、その中にはキャリアの情報も含まれているわけです。ということは、複数キャリアの固体識別番号を同時にセットする必要は、攻撃者にとってないわけですので、そもそもそういうことをするとは思えないからです。<br>ですから、実装が容易というのはその通りだと思いますが、効果も薄いのではないかと思いました。

_ ketaiorg (2009年08月06日 11:47)

徳丸浩さん 早速のコメントありがとうございます。<br><br>少し言葉足らずだったため補足させてください。<br>上記は.htaccessのIP帯域制限で、より安全な方法はないかと模索するためのものでした。<br><br>記事内の例にあるような「当該の事業者のIP帯域に含まれているかを確認」という処理は重いですし実装も手間なので、<br>もっと良い方法がないかなと思案していたところでした。<br><br>各キャリアが、ゲートウェイで自キャリア分の契約IDヘッダを上書きしてくれることを前提とすると、<br><br>> すなわち、ドコモの携帯電話からの攻撃なので、IPアドレス帯域は携帯事業者のものである。<br>> UserAgentの書き換えが行われているので、アプリケーションはau携帯からのリクエストと誤認する。<br>> そこで、JavaScriptによるリクエストヘッダX-UP-SUBNO(EZ番号)追加により、別ユーザになりすましができるというシナリオである。<br><br>少なくともこちらの攻撃は防ぐことができるのかなと思いました。

_ hideden (2009年08月06日 12:45)

ちゃんと検証したわけではないので以下は参考程度にお願いします。<br><br>・APN書き換えで携帯ネットワークに入った場合の割り当てIPは、10.x.x.xのローカルIP<br>・DNS解決は出来るものの、直接NAT変換のような感じに外に出る事は出来ない<br>・特定のGatewayProxy(おそらくWAP2 to HTTP Proxy)を通してHTTPのみ外部に出られる<br>・GatewayProxyは一般的なProxyと違い、HTTPヘッダをすべて書き換える(ただし、UAのみ元の値を継承する)ため、独自のヘッダの付与は出来ない<br>・x-jphone-uidはGWで自動付与(MySoftBankの設定依存)<br>・UAとして使用可能なのはNokia,Samsungなどの海外メーカーの数機種のUAのみ<br><br>海外メーカーの日本向けモデルに対応する為に存在するGWと推測される(SBMのWAPではなく、標準的なHTTPしか対応してないモデルの携帯に簡単に対応する為に作られた?)<br><br>通常の日本向けの携帯が同一APNに接続しているかは、携帯の設定画面で確認できるわけではないので不明。<br><br>ってことで、<br><br>・x-jphone-uidが出力されるようになる以前に作られた製造番号のみを使用した自動ログイン<br>・製造番号のみを判定に使用し、機種名を考慮しない自動ログイン<br>・製造番号を抜き出すロジックが不適切かつ、製造番号/UIDを取り扱うインターフェイスがキャリア間で統一されているモジュール<br> (SoftBank/1.0/705NK/NKJ001/SNxxxxxxxxxx_xx.ezweb.ne.jp Series60/3.0... とか指定された場合に統一インターフェイスから読み出した値のみをkeyとした自動ログインの実装等)<br>・製造番号を抜き出すロジックが不適切かつ、UIDと製造番号のインターフェイスが同一のモジュールを使用している場合<br> (x-jphone-uidが設定でOFFになっている場合かつ製造番号がUAに付いている場合は、UIDではなく製造番号を代わりに返す実装のモジュール等)<br><br><br>などの場合はちゃんと修正しようね、と。特にi-modeのAタグのutn属性に対応した携帯と対応していない携帯がまだ混在していた頃に実装されたサービスなんかが特にあやしめな気がします。

_ 徳丸浩 (2009年08月06日 23:10)

matsuiさん、コメントありがとうございます。どうも、前提の違いがあるようですね。<br><br>私のこのエントリでは、攻撃はドコモの端末からJavaScriptを用いて行われます。ですので、ドコモ以外のauやソフトバンクのゲートウェイは通りません。<br>また、ドコモのゲートウェイは通るわけですが、X-DCMGUIDは、URLにguid=ONを指定した場合のみ設定されますので、攻撃者はguid=ONを指定しないで攻撃すればよいのではなでしょうか。<br>IPアドレスのチェックは重いということですが、少なくとも認証の際に一回だけチェックすればよいことですので、サーバー負荷や処理速度に影響するほどではないと予想します。<br>ただ運用は大変ですよね。.htaccessとアプリケーション用の設定ファイルの両方をメンテナンスしなければなりません。その点を指摘されているのであれば同意します。

_ 徳丸浩 (2009年08月06日 23:31)

hidedenさん、大変詳しいレポートをありがとうございます。さすがに色々制約はあるのですね。<br>ですが、少なくとも「かんたんログイン」はきわめて危うい均衡の元にかろうじて成立していることには変わらないと思いました。<br>ありがとうございました。またブログなどで色々教えていただければ幸いです。

_ ketaiorg (2009年08月07日 10:05)

徳丸浩さん<br>なるほどおっしゃるとおりです。<br>いずれにしてもこの方法は効果が薄いですね。大変参考になりました。<br>度重なる質問にお答えいただきありがとうございました。



[PR]小規模ECサイトに最適なWAF、SiteGuard Lite

ockeghem(徳丸浩)の日記はこちら
HASHコンサルティング株式会社

最近の記事

最近のツッコミ

  1. ketaiorg (08-07)
  2. 徳丸浩 (08-06)
  3. 徳丸浩 (08-06)
Google