WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱

1. ケータイ2.0が開けてしまったパンドラの箱 2010年5月22日 HASHコンサルティング株式会社徳丸浩

2. 徳丸浩の自己紹介  経歴  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. 今日はケータイの「かんたんログイン」のお話です 3

4. ケータイWebアプリの構成キャリア基地局ゲートウェイコンテンツ提供事業者 iモード EZweb Webサーバ DBサーバ Yahoo! ケータイワイヤレス網インターネット端末 DB (Hand Set) 言語変換認証 SSL処理 Cookie保持・・・ 4

5. 「かんたんログイン」とは端末固有IDのみをキーとして認証する端末固有IDあれこれキャリア名称 HTTPヘッダ NTTドコモ FOMA端末識別番号 User-Agent iモードＩＤ X-DCMGUID Au EZ番号 X-UP-SUBNO ソフトバンク端末シリアル番号 User-Agent ユーザーＩＤ X-JPHONE-UID 5

6. かんたんログイン画面の例(1) 6

9. 「かんたんログイン」がなりたつための条件  端末固有IDは、同一端末であれば、すべてのサイトに同じ値が送出される。すなわち、端末固有IDは秘密情報ではない  秘密情報でない、固定のIDで認証するためには、端末固有IDは書き換えができないという前提が必要  端末固有IDはHTTPヘッダに乗ってくる値なので、通常は任意に書き換えができる。携帯電話を使っている時は変更できないと考えられているが…  まとめると、かんたんログインはケータイの以下の条件によって支えられている  ケータイ網が閉じたネットワークである  ケータイ端末の機能が低く、HTTPヘッダを書き換える機能がない今日のテーマはこちら 9

10. iモードブラウザ2.0の登場 2009年5月19日づけNTTドコモ社の報道発表よりおや? http://www.nttdocomo.co.jp/info/news_release/page/090519_00.html より引用 10

11. ケータイJavaScriptで端末固有ＩＤを書き換える条件  以下の三条件がそろえば、端末固有IDの書き換え、すなわち「かんたんログイン」なりすましができるが・・ a. 携帯電話のJavaScriptでXMLHttpRequestオブジェクトが利用できる b. XMLHttpRequestにてsetRequestHeaderメソッドが利用できる c. setRequestHeaderメソッドにてUserAgentなどのリクエストヘッダが書き換えできる  10月末のJavaScript再有効化の際に、 setRequestHeaderメソッドが無効化された模様。すなわち、上記b、cが成立しなくなった。  元々のNTTドコモのサイトではJavaスクリプトの仕様書に setRequestHeaderもちゃんと載っていたのだが…現時点では削除されている  XMLHttpRequest自体にも制限が加わり、JavaScriptが置かれたコンテンツのディレクトリかサブディレクトリのみがアクセス可能参照: http://www.tokumaru.org/d/20090805.html#p01 11

12. きっかけはmpw.jp管理人様の日記 12

13. http://mpw.jp/blog/2009/11/188.html より引用 13

14. mpw.jp管理人様指摘の方法はDNSリバインディング  DNSの内容を短時間の間に書き換える手法は、DNSリバインディングとして知られている  従来は、ローカルネットワーク内のサーバーを攻撃する手法として知られていた  ケータイ向けサイトはインターネット上にあるが、IPアドレス制限から、ローカルネットワークと類似の性格を持つ  mpw.jp管理人様指摘の手法は、HTMLソースを読み出すものだが、かんたんログイン突破にも応用可能これはまずい 14

15. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 192.0.2.2 攻撃者はワナを準備して誘導 15

16. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 192.0.2.2 ユーザがワナを閲覧 16

17. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 115.146.17.185 攻撃者は DNSを操作 17

18. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 115.146.17.185 ケータイJavaScript 10秒後に evil.example.jp を閲覧開始 18

19. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 115.146.17.185 evil.example.jpの IPアドレスを要求 19

20. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 115.146.17.185 115.146.17.185 を返す 20

21. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 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

22. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 115.146.17.185 個人情報を返す氏名、メールアドレス、住所、電話番号 22

23. DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp evil.example.jp 115.146.17.185 192.0.2.2 攻撃対象ワナ example.jpのDNS evil 115.146.17.185 個人情報をワナのサーバーに返す 23

24. 徳丸浩の熱い日  2009年11月22日 mpw.jp管理人様のブログを読む  すぐに、DNSリバインディングにより、かんたんログインが突破される可能性に気づく  検証専用に新たにドメインを購入して、調査を開始。かんたんログインが突破されることを確認  携帯電話事業者設備では対策が困難であり、一方Webサイト側には効果的な対策が存在することが分かる  そのため、事業者に通知ないし届け出するよりも、一般に公開してサイト運営者に対策を呼びかけることを決定。  ただし、翌11月23日は祝日（勤労感謝の日）のため、迅速な対応がとれないと判断し、11月24日まで発表を見合わせた  11月24日HASHコンサルティング株式会社ホームページにて、アドバイザリを公開 24

25. 25

26. DNSリバインディング対策はケータイ事業者側ではできない  本来はケータイブラウザあるいはゲートウェイで対策するべきものではあるが…  ケータイブラウザはゲートウェイ（PROXY）経由のアクセスなので、ブラウザでは名前解決をしていない。すなわち、ブラウザでは対策（DNS Pinning）できない  ゲートウェイはマルチユーザが対象なので、文脈を意識した Pinningは不可能で、いつかはIPアドレスを切り替えなければならない 26

27.  キャリアのDNSが最低1時間DNSキャッシュする想定では、以下のような攻撃が可能となる  攻撃者はワナサイトを用意する  攻撃者は自ら携帯電話でワナサイトをアクセスする  ワナサイトのIPアドレスをターゲットサイトのIPに切り替えておく  58分後に、ワナサイトのURLをまいて誘導する  被害者がワナサイトを閲覧した直後に、DNSサーバーのキャッシュ保持が無効となる  被害者のブラウザ上でDNSリバインディングを悪用したリクエストが発行されるが、既に標的サイトのIPアドレスが有効となり、攻撃が成立する 27

28. ゲートウェイIPの変遷 28

29. Webサイト側でのDNSリバインディング対策  iモードブラウザ2.0のXMLHttpRequestでは、setRequestHeader メソッドが無効化されているので、リクエストヘッダのHostフィールドはワナサイトのドメインになっている  したがって、かんたんログインの際に、Hostフィールドをチェックすればよい  簡単に実装するには、名前ベースのバーチャルホストにすればよい 29

30. twtr.jpの事例 http://www.tokumaru.org/d/20100222.html#p01 30

31. http://takagi-hiromitsu.jp/diary/20100228.html#p01 より引用 31

32. ケータイ2.0がパンドラの箱を開けてしまった 32

33. 続いてソフトバンクも… 33

34. ソフトバンクでもJavaScriptに対応 http://k-tai.impress.co.jp/docs/news/20100518_367787.html より引用 34

35. 本当に2010年夏モデルからなのか?  実はかなり以前からソフトバンク端末の一部のモデルで JavaScriptに対応していた  ノキア 702NK(2004年12月発売)では簡単なJavaScriptに対応  XMLHttpRequestやIFRAME、DOMには対応していない  804SS(2006年3月)、910T(2006年10月)、910SH(2006年11月) では、NetFront 3.3によるJavaScript対応  XMLHttpRequestには対応していない  IFRAME、DOMに対応…攻撃に利用できる可能性*1  922SH(2008年3月)では、NetFront 3.4にてAjaxに対応  XMLHttpRequestのサポート  setRequetHeaderのサポート (!) 実は2006年から、パンドラの箱は開いていた注 *1: 804SSはIFRAMEに対応していない 35

36. setRequestHeaderはどのヘッダを改変してよいか? http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest より引用・追記 36

37. setRequestHeaderはどのヘッダを改変してよいか? 37

38. これはまずい (((( ;ﾟд ﾟ))))ｱﾜﾜ 38

39. 徳丸浩の熱い日2  2009年11月24日朝『iモードIDを用いた「かんたんログイン」の DNS Rebinding脆弱性』を発表する  この日の午前中は商談のため外出していた  はてなダイアリーのコメント欄にてナカニシさんという方から、ソフトバンク端末(932SHで検証)でXMLHttpRequestが動くことを教えていただく…外出先にて確認…大変だ  原宿のソフトバンクショップで確認しようとするが、うまくいかず  自宅に移動  地元（横浜市）のソフトバンクショップにて確認するがうまくいかず  ナカニシさんのコメントを信じて932SHを購入する  端末のセキュリティ設定で「Ajax規制」という項があり、デフォルトは「許可しない」となっていることを確認。「許可する」に変更すると、 XMLHttpRequestが利用可能であることを実機にて確認。 39

40. 徳丸浩の熱い日2（続き）  ソフトバンク端末のXMLHttpRequestでは、setRequestHeaderが有効であることを確認  setRequestHeaderでHostフィールドを改変できる…だめじゃん  サイト側での即効性のある対策が思いつかなかったため、公開を保留し、ソフトバンク社に連絡をとることを決意  同日、ツテにより同事象をメール連絡。  ソフトバンクモバイル側の担当者がアサインされる  12月某日、ソフトバンクにて打ち合わせ  問題点と対策案の説明  DNSキャッシュの最短保持時間を延ばすと攻撃を緩和できる  Hostフィールドの改変防止が根本対策  「当面の間は」公表を見合わせることを約束  ・・・あまり時間が掛かるようだと、公開する場合もあり得る 40

41. その後4ヶ月弱が経過 41

42. 3月末の某日  ソフトバンク端末にて対策がとられていないか確認  端末のアップデートが動いていないのでダメとは分かっていた  ・・・やっぱりダメだった  しかし、DNSの挙動に変化が・・・ 42

43. ゲートウェイIPアドレスの変遷(ソフトバンク) DNSのキャッシュを5分間保持ゲートウェイが切り替わるとダメ 43

44. このままでは攻撃者が気づいてしまう  WASFのタイミング（つまり本日）で、ソフトバンク端末の件は当初伏せておく積もりだった  しかし、発見・通報から半年経って何のアナウンスもされていない  対策を打つべき機種があまりにも多く、迅速な対応は望めないだろう  Webサイト運営者・開発者はこの問題を知らないが、一人でも気づいた人が悪用するとまずい  Ajaxが有効な機種は、シャープ製に限られ、デフォルトではAjax無効になっていると思われた  影響範囲は狭いのではないか  であれば、広く公開して、注意喚起した方がよいのではないか 44

45. 徳丸浩の熱い日3  他の端末はどうなのか。デフォルトでAjaxが許可された端末は、本当にないのか  約90種類の端末のマニュアルをダウンロードして調査  シャープ製のみ「Ajax規制」という項目があり、デフォルトで「禁止」となっているものが多かった  マニュアルにデフォルトの記入がないものもあり、挙動は不明  シャープ以外はAjax規制という設定がなく、許可・禁止が不明  費用はかかるが、実機をまとめて検証することを決意  費用や時間などを考慮して、60台を3時間で検証することに  5月某日をターゲットに端末および検証ルームを予約  決行その結果 45

46. 940Pの結果よしよし 46

47. 940SCの結果 940SCを含む4機種がデフォルト設定でAjaxが有効 Σ(ﾟдﾟlll)ｶﾞｰﾝ 47

48. Ajax有効な機種のサマリ •ただし、SHARPの最新機種943SHのみは、Refererが送出されるが、改変はできない •△はデフォルトでAjax無効、オプションにより有効化可能（SHARP端末は多いので抜粋） •上記以外のPanasonic、Toshiba等はAjax無効 48

49. ソフトバンクの端末は統制がとれていない印象  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

50. ブラウザ開発社の責任インターネットエクスプローラーも昔はセキュリティ上の問題が多かったが、いち早く自動アップデートの機能を備え、XSSフィルタを実装するなど、セキュリティ面の貢献も大きい。ACCESS社にも、シェア8割に見合う責任を果たしていただきたい http://it.nikkei.co.jp/mobile/special/i-mode10th.aspx?n=MMITi3000023022009 より引用 50

51. 幸い、Ajax該当機種はシェアが低く、影響を受けるユーザは少ない SoftBankの利用統計アクセスシェア上位20端末 2010年3月の統計 920P この2機種以外はすべてSHARP 911T http://myrt.auriq.com/mobile/jp/statistics/2010/03.php より引用 51

52. ソフトバンク端末向けの対策は?  Ajaxが有効になっている端末については、アプリケーション側にて即効性のある対策がない  ユーザにブラウザのセキュリティ設定を促す  Ajax規制のある機種（シャープ製）については、Ajaxを禁止する  Ajax規制のない機種については、スクリプトを無効にする  現在チェックサイトを準備中チェックサイト作りました http://www.hash-c.co.jp/ajax/chkajax.cgi  もしサイト運営者にやる気があれば・・・  現在有効なすべての機種について網羅的な調査をして、デフォルトで Ajaxが有効な機種を調べ、該当機種ではかんたんログインを無効にする  ・・・しかし、シェアの高いシャープ端末は、ユーザがAjaxを有効にした瞬間に、脆弱性が生まれる  いっそ、ソフトバンク端末では、かんたんログインを無効にするという考え方もあり 52

53. 能動的攻撃の可能性(再) 53

54. ケータイJavaScriptによる能動的攻撃の可能性  iモードブラウザ2.0はsetRequestHeader()が無効化されているので、User-AgentやX-DCM-GUIDの変更は不可能と思われる  ソフトバンク端末では、 setRequestHeader()関数自体は無効化されていないが、User-AgentやX-JPHONE-UIDの変更は禁止されている  ・・・  抜け道はないのか？ 54

55. 2種類のトリックによる端末固有IDの改変が可能  トリック１：End-EndのSSLを使う  キャリアゲートウェイのチェックをすり抜ける  ソフトバンクにはゲートウェイ型のSSLもあるが、こちらはゲートウェイのチェックが有効  トリック２：ハイフン「-」の代わりにアンダースコア「_」を用いる  リクエストヘッダ中のハイフンは、アプリケーションが利用する際にアンダースコアに変更される仕様を悪用 55

56. 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

57. アプリケーションが受け取ったリクエストの例（一部） 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

58. ＳＳＬを悪用した能動型なりすまし攻撃への対策  SSLではかんたんログインを受け付けない  必須はソフトバンクのみ禁止だが、全キャリア禁止することが無難  キャリア判定は、User-Agentではなく、IPアドレスで行う 58

59. まとめ  かんたんログインに対して、ケータイJavaScriptによる攻略手法がわかってきた  かんたんログインに際しての必須対策  キャリアゲートウェイのIPアドレスとのみ通信を制限する  キャリアの判定にもIPアドレスを用いる  Hostヘッダのチェック（あるいは名前ベースのバーチャルホスト）  ソフトバンク端末については、Ajax規制あるいはスクリプトの禁止  SSLでは、かんたんログインは行わない  ・・・  これで完璧かどうかは誰にも分からない  とくに、ソフトバンク端末のように機種依存性が多いと、全ての端末について検証しないと確かなことは言えない  それでも、まだ、かんたんログイン続けますか？  ケータイセキュリティについてオープンに議論できる場の必要性 59

60. ご清聴ありがとうございました 60

WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱

You are reading a preview.

Check these out next

WAS Forum 2010カンファレンス:ケータイ2.0が開けてしまったパンドラの箱

More Related Content

Viewers also liked (20)

More from Hiroshi Tokumaru (20)

Recently uploaded (20)