WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱
220 Views
May 24, 10
スライド概要
関連スライド
SPAセキュリティ超入門
徳丸 浩
680.4K
各ページのテキスト
ケータイ2.0が開けてしまった パンドラの箱 2010年5月22日 HASHコンサルティング株式会社 徳丸 浩
徳丸浩の自己紹介 経歴 1985年 京セラ株式会社入社 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 2008年 KCCS退職、HASHコンサルティング株式会社設立 経験したこと 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 その後、企業向けパッケージソフトの企画・開発・事業化を担当 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ その他 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開 「大学時代のPascal演習がCabezonでした」という方にお目にかかることも 現在 HASHコンサルティング株式会社 代表 http://www.hash-c.co.jp/ 京セラコミュニケーションシステム株式会社 技術顧問 http://www.kccs.co.jp/security/ 独立行政法人情報処理推進機構 非常勤研究員 http://www.ipa.go.jp/security/ 2
今日はケータイの「かんたんログイン」 のお話です 3
ケータイWebアプリの構成 キャリア基地局 ゲートウェイ iモード EZweb Yahoo! ケータイ コンテンツ提供事業者 Webサーバ DBサーバ ワイヤレス網 インターネット 端末 (Hand Set) DB 言語変換 認証 SSL処理 Cookie保持 ・・・ 4
「かんたんログイン」とは 端末固有IDのみを キーとして認証する 端末固有IDあれこれ キャリア 名称 HTTPヘッダ NTTドコモ FOMA端末識別番号 User-Agent iモードＩＤ X-DCMGUID Au EZ番号 X-UP-SUBNO ソフトバンク 端末シリアル番号 User-Agent ユーザーＩＤ X-JPHONE-UID 5
かんたんログイン画面の例(1) 6
かんたんログイン画面の例(2) 7
かんたんログイン画面の例(3) 8
「かんたんログイン」がなりたつための条件 端末固有IDは、同一端末であれば、すべてのサイトに同じ値が送 出される。すなわち、端末固有IDは秘密情報ではない 秘密情報でない、固定のIDで認証するためには、端末固有IDは 書き換えができないという前提が必要 端末固有IDはHTTPヘッダに乗ってくる値なので、通常は任意に 書き換えができる。携帯電話を使っている時は変更できないと考 えられているが… まとめると、かんたんログインはケータイの以下の条件によって支 えられている ケータイ網が閉じたネットワークである ケータイ端末の機能が低く、HTTPヘッダを書き換える機能がない 今日のテーマはこちら 9
iモードブラウザ2.0の登場 2009年5月19日づけNTTドコモ社の報道発表より おや? http://www.nttdocomo.co.jp/info/news_release/page/090519_00.html より引用 10
ケータイJavaScriptで端末固有ＩＤを書き換える条件 以下の三条件がそろえば、端末固有IDの書き換え、すなわち「か んたんログイン」なりすましができるが・・ a. b. c. 携帯電話のJavaScriptでXMLHttpRequestオブジェクトが利用でき る XMLHttpRequestにてsetRequestHeaderメソッドが利用できる setRequestHeaderメソッドにてUserAgentなどのリクエストヘッダが 書き換えできる 10月末のJavaScript再有効化の際に、 setRequestHeaderメソッ ドが無効化された模様。すなわち、上記b、cが成立しなくなった。 元々のNTTドコモのサイトではJavaスクリプトの仕様書に setRequestHeaderもちゃんと載っていたのだが…現時点では削 除されている XMLHttpRequest自体にも制限が加わり、JavaScriptが置かれた コンテンツのディレクトリかサブディレクトリのみがアクセス可能 参照: http://www.tokumaru.org/d/20090805.html#p01 11
きっかけはmpw.jp管理人様の日記 12
http://mpw.jp/blog/2009/11/188.html より引用 13
mpw.jp管理人様指摘の方法はDNSリバインディング DNSの内容を短時間の間に書き換える手法は、DNSリバインディ ングとして知られている 従来は、ローカルネットワーク内のサーバーを攻撃する手法として 知られていた ケータイ向けサイトはインターネット上にあるが、IPアドレス制限か ら、ローカルネットワークと類似の性格を持つ mpw.jp管理人様指摘の手法は、HTMLソースを読み出すものだ が、かんたんログイン突破にも応用可能 これはまずい 14
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 192.0.2.2 攻撃者はワナを 準備して誘導 15
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 192.0.2.2 ユーザが ワナを閲覧 16
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 攻撃者は DNSを操作 17
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 ケータイJavaScript 10秒後に evil.example.jp を閲覧開始 18
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 evil.example.jpの IPアドレスを要求 19
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 115.146.17.185 を返す 20
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 iモードIDが送出 X-DCMGUID:xxxXXX9 http://evil.example.jp/ userinfo.php?guid=ON にアクセス 21
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 個人情報を返す 氏名、メールアドレス、 住所、電話番号 22
DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 個人情報をワナの サーバーに返す 23
徳丸浩の熱い日 2009年11月22日 mpw.jp管理人様のブログを読む すぐに、DNSリバインディングにより、かんたんログインが突破さ れる可能性に気づく 検証専用に新たにドメインを購入して、調査を開始。かんたんログ インが突破されることを確認 携帯電話事業者設備では対策が困難であり、一方Webサイト側 には効果的な対策が存在することが分かる そのため、事業者に通知ないし届け出するよりも、一般に公開して サイト運営者に対策を呼びかけることを決定。 ただし、翌11月23日は祝日（勤労感謝の日）のため、迅速な対応 がとれないと判断し、11月24日まで発表を見合わせた 11月24日HASHコンサルティング株式会社ホームページにて、ア ドバイザリを公開 24
25
DNSリバインディング対策はケータイ事業者側ではできない 本来はケータイブラウザあるいはゲートウェイで対策するべきもの ではあるが… ケータイブラウザはゲートウェイ（PROXY）経由のアクセスなので、 ブラウザでは名前解決をしていない。すなわち、ブラウザでは対策 （DNS Pinning）できない ゲートウェイはマルチユーザが対象なので、文脈を意識した Pinningは不可能で、いつかはIPアドレスを切り替えなければなら ない 26
キャリアのDNSが最低1時間DNSキャッシュする想定では、以下 のような攻撃が可能となる 攻撃者はワナサイトを用意する 攻撃者は自ら携帯電話でワナサイトをアクセスする ワナサイトのIPアドレスをターゲットサイトのIPに切り替えておく 58分後に、ワナサイトのURLをまいて誘導する 被害者がワナサイトを閲覧した直後に、DNSサーバーのキャッ シュ保持が無効となる 被害者のブラウザ上でDNSリバインディングを悪用したリクエスト が発行されるが、既に標的サイトのIPアドレスが有効となり、攻撃 が成立する 27
ゲートウェイIPの変遷 28
Webサイト側でのDNSリバインディング対策 iモードブラウザ2.0のXMLHttpRequestでは、setRequestHeader メソッドが無効化されているので、リクエストヘッダのHostフィール ドはワナサイトのドメインになっている したがって、かんたんログインの際に、Hostフィールドをチェックす ればよい 簡単に実装するには、名前ベースのバーチャルホストにすればよ い 29
twtr.jpの事例 http://www.tokumaru.org/d/20100222.html#p01 30
http://takagi-hiromitsu.jp/diary/20100228.html#p01 より引用 31
ケータイ2.0がパンドラの箱を開けてしまった 32
続いてソフトバンクも… 33
ソフトバンクでもJavaScriptに対応 http://k-tai.impress.co.jp/docs/news/20100518_367787.html より引用 34
本当に2010年夏モデルからなのか? 実はかなり以前からソフトバンク端末の一部のモデルで JavaScriptに対応していた ノキア 702NK(2004年12月発売)では簡単なJavaScriptに対応 804SS(2006年3月)、910T(2006年10月)、910SH(2006年11月) では、NetFront 3.3によるJavaScript対応 XMLHttpRequestやIFRAME、DOMには対応していない XMLHttpRequestには対応していない IFRAME、DOMに対応…攻撃に利用できる可能性*1 922SH(2008年3月)では、NetFront 3.4にてAjaxに対応 XMLHttpRequestのサポート setRequetHeaderのサポート (!) 実は2006年から、パンドラの箱は開いていた 注 *1: 804SSはIFRAMEに対応していない 35
setRequestHeaderはどのヘッダを改変してよいか? http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest より引用・追記 36
setRequestHeaderはどのヘッダを改変してよいか? 37
これはまずい (((( ;ﾟд ﾟ))))ｱﾜﾜ 38
徳丸浩の熱い日2 2009年11月24日朝 『iモードIDを用いた「かんたんログイン」の DNS Rebinding脆弱性』を発表する この日の午前中は商談のため外出していた はてなダイアリーのコメント欄にてナカニシさんという方から、ソフト バンク端末(932SHで検証)でXMLHttpRequestが動くことを教え ていただく…外出先にて確認…大変だ 原宿のソフトバンクショップで確認しようとするが、うまくいかず 自宅に移動 地元（横浜市）のソフトバンクショップにて確認するがうまくいかず ナカニシさんのコメントを信じて932SHを購入する 端末のセキュリティ設定で「Ajax規制」という項があり、デフォルト は「許可しない」となっていることを確認。「許可する」に変更すると、 XMLHttpRequestが利用可能であることを実機にて確認。 39
徳丸浩の熱い日2（続き） ソフトバンク端末のXMLHttpRequestでは、setRequestHeaderが 有効であることを確認 setRequestHeaderでHostフィールドを改変できる…だめじゃん サイト側での即効性のある対策が思いつかなかったため、公開を 保留し、ソフトバンク社に連絡をとることを決意 同日、ツテにより同事象をメール連絡。 ソフトバンクモバイル側の担当者がアサインされる 12月某日、ソフトバンクにて打ち合わせ 問題点と対策案の説明 DNSキャッシュの最短保持時間を延ばすと攻撃を緩和できる Hostフィールドの改変防止が根本対策 「当面の間は」公表を見合わせることを約束 ・・・あまり時間が掛かるようだと、公開する場合もあり得る 40
その後4ヶ月弱が経過 41
3月末の某日 ソフトバンク端末にて対策がとられていないか確認 端末のアップデートが動いていないのでダメとは分かっていた ・・・やっぱりダメだった しかし、DNSの挙動に変化が・・・ 42
ゲートウェイIPアドレスの変遷(ソフトバンク) DNSのキャッシュを5分間保持 ゲートウェイが切り替わるとダメ 43
このままでは攻撃者が気づいてしまう WASFのタイミング（つまり本日）で、ソフトバンク端末の件は当初 伏せておく積もりだった しかし、発見・通報から半年経って何のアナウンスもされていない 対策を打つべき機種があまりにも多く、迅速な対応は望めないだ ろう Webサイト運営者・開発者はこの問題を知らないが、一人でも気 づいた人が悪用するとまずい Ajaxが有効な機種は、シャープ製に限られ、デフォルトではAjax無 効になっていると思われた 影響範囲は狭いのではないか であれば、広く公開して、注意喚起した方がよいのではないか 44
徳丸浩の熱い日3 他の端末はどうなのか。デフォルトでAjaxが許可された端末は、 本当にないのか 約90種類の端末のマニュアルをダウンロードして調査 費用はかかるが、実機をまとめて検証することを決意 シャープ製のみ「Ajax規制」という項目があり、デフォルトで「禁止」と なっているものが多かった マニュアルにデフォルトの記入がないものもあり、挙動は不明 シャープ以外はAjax規制という設定がなく、許可・禁止が不明 費用や時間などを考慮して、60台を3時間で検証することに 5月某日をターゲットに端末および検証ルームを予約 決行 その結果 45
940Pの結果 よしよし 46
940SCの結果 940SCを含む4機種が デフォルト設定でAjaxが有効 Σ(ﾟдﾟlll)ｶﾞｰﾝ 47
Ajax有効な機種のサマリ •ただし、SHARPの最新機種943SHのみは、Refererが送出されるが、改変はできない •△はデフォルトでAjax無効、オプションにより有効化可能（SHARP端末は多いので抜粋） •上記以外のPanasonic、Toshiba等はAjax無効 48
ソフトバンクの端末は統制がとれていない印象 2010年夏モデル以降が「正式な」JavaScript対応だとすると、これま でのJavaScript対応機種は、端末メーカーの独自機能なのか NECとCASIOは、ソフトバンク端末に慣れていなかった。NECは1年 半ぶりのソフトバンク端末、CASIOは初めてのソフトバンク端末 NEC、CASIOとも、Ajax対応した次の機種ではAjaxを殺している SHARPは新機能の実装にどん欲な一方、慎重な一面も なにか問題に気づいたのではないか Ajax機能をon/offでき、デフォルトではoffにしたこと Refererを無効化していたのは、問題点に気づいていたからでは? 最新の943SHで、Refererを有効化したのは、NetFront3.5で問題が解 消していることを確認したからでは？ メーカー間の情報共有がなされていない印象 iモードブラウザ2.0の教訓も活かされていない ソフトバンクおよびACCESS社はなにをしていたのか? 49
ブラウザ開発社の責任 インターネットエクスプローラーも昔はセキュリティ上 の問題が多かったが、いち早く自動アップデートの 機能を備え、XSSフィルタを実装するなど、セキュリ ティ面の貢献も大きい。ACCESS社にも、シェア8割 に見合う責任を果たしていただきたい http://it.nikkei.co.jp/mobile/special/i-mode10th.aspx?n=MMITi3000023022009 より引用 50
幸い、Ajax該当機種はシェアが低く、影響を受けるユーザは少ない SoftBankの利用統計 アクセスシェア上位20端末 2010年3月の統計 920P この2機種以外は すべてSHARP 911T http://myrt.auriq.com/mobile/jp/statistics/2010/03.php より引用 51
ソフトバンク端末向けの対策は? Ajaxが有効になっている端末については、アプリケーション側にて 即効性のある対策がない ユーザにブラウザのセキュリティ設定を促す もしサイト運営者にやる気があれば・・・ Ajax規制のある機種（シャープ製）については、Ajaxを禁止する Ajax規制のない機種については、スクリプトを無効にする 現在チェックサイトを準備中 チェックサイト作りました http://www.hash-c.co.jp/ajax/chkajax.cgi 現在有効なすべての機種について網羅的な調査をして、デフォルトで Ajaxが有効な機種を調べ、該当機種ではかんたんログインを無効に する ・・・しかし、シェアの高いシャープ端末は、ユーザがAjaxを有効にした 瞬間に、脆弱性が生まれる いっそ、ソフトバンク端末では、かんたんログインを無効にするとい う考え方もあり 52
能動的攻撃の可能性(再) 53
ケータイJavaScriptによる能動的攻撃の可能性 iモードブラウザ2.0はsetRequestHeader()が無効化されているの で、User-AgentやX-DCM-GUIDの変更は不可能と思われる ソフトバンク端末では、 setRequestHeader()関数自体は無効化さ れていないが、User-AgentやX-JPHONE-UIDの変更は禁止され ている ・・・ 抜け道はないのか？ 54
2種類のトリックによる端末固有IDの改変が可能 トリック１：End-EndのSSLを使う キャリアゲートウェイのチェックをすり抜ける ソフトバンクにはゲートウェイ型のSSLもあるが、こちらはゲートウェイ のチェックが有効 トリック２：ハイフン「-」の代わりにアンダースコア「_」を用いる リクエストヘッダ中のハイフンは、アプリケーションが利用する際にア ンダースコアに変更される仕様を悪用 55
SSLを利用したリクエストヘッダ改変スクリプトの例
var requester = new XMLHttpRequest();
requester.open('GET', 'https://example.com/login.php', true);
requester.onreadystatechange = function() {
if (requester.readyState == 4) {
onloaded(requester);
}
};
requester.setRequestHeader("Host", "twtr.com");
requester.setRequestHeader("User_Agent",
"SoftBank/1.0/943SH/SHJ001/SN359XXXXXXXXXXX0 " +
" Browser/NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1");
requester.setRequestHeader(
"X_JPHONE_UID", "a3XXXXXXXXXXXXXP");
requester.send(null);
56
アプリケーションが受け取ったリクエストの例（一部） HTTP_USER_AGENT=DoCoMo/2.1 P07A3(c500;TB;W24H15)Fake SERVER_NAME=twitter.com SERVER_PORT=443 HTTP_COOKIE=aaa=bbbx REMOTE_ADDR=123.108.237.4 SERVER_PROTOCOL=HTTP/1.1 HTTP_X_JPHONE_UID=fakejphoneuid HTTP_X_DCMGUID=fakedcmguid HTTP_X_UP_SUBNO=fakesubno HTTP_HOST=twitter.com ※URLと証明書のドメインが異なるので警告が出るが、処理は続行可能 57
ＳＳＬを悪用した能動型なりすまし攻撃への対策 SSLではかんたんログインを受け付けない 必須はソフトバンクのみ禁止だが、全キャリア禁止することが無難 キャリア判定は、User-Agentではなく、IPアドレスで行う 58
まとめ かんたんログインに対して、ケータイJavaScriptによる攻略手法が わかってきた かんたんログインに際しての必須対策 これで完璧かどうかは誰にも分からない キャリアゲートウェイのIPアドレスとのみ通信を制限する キャリアの判定にもIPアドレスを用いる Hostヘッダのチェック（あるいは名前ベースのバーチャルホスト） ソフトバンク端末については、Ajax規制あるいはスクリプトの禁止 SSLでは、かんたんログインは行わない ・・・ とくに、ソフトバンク端末のように機種依存性が多いと、全ての端末に ついて検証しないと確かなことは言えない それでも、まだ、かんたんログイン続けますか？ ケータイセキュリティについてオープンに議論できる場の必要性 59
ご清聴ありがとうございました 60