SlideShare a Scribd company logo
1 of 60
ケータイ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                              Webサーバ DBサーバ
Yahoo! ケータイ
              ワイヤレス網

                             インターネット



端末
                                               DB
(Hand Set)
                       言語変換
                       認証
                       SSL処理
                       Cookie保持
                       ・・・
                                                      4
「かんたんログイン」とは




                               端末固有IDのみを
                               キーとして認証する



    端末固有IDあれこれ
   キャリア     名称           HTTPヘッダ
   NTTドコモ   FOMA端末識別番号   User-Agent
            iモードID       X-DCMGUID
   Au       EZ番号         X-UP-SUBNO
   ソフトバンク   端末シリアル番号     User-Agent
            ユーザーID       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を書き換える条件

    以下の三条件がそろえば、端末固有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
きっかけは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   evil.example.jp
      115.146.17.185     192.0.2.2
      攻撃対象               ワナ


                                     example.jpのDNS
                                       evil 192.0.2.2

                                      攻撃者はワナを
                                       準備して誘導




                                                        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




                                  ユーザが
                                  ワナを閲覧




                                                        16
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
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
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
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
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
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
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
徳丸浩の熱い日

   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に対応
       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
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の改変が可能

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




                                             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を悪用した能動型なりすまし攻撃への対策

   SSLではかんたんログインを受け付けない
       必須はソフトバンクのみ禁止だが、全キャリア禁止することが無難
   キャリア判定は、User-Agentではなく、IPアドレスで行う




                                         58
まとめ

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

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




                 60

More Related Content

Viewers also liked

文字コードに起因する脆弱性とその対策
文字コードに起因する脆弱性とその対策 文字コードに起因する脆弱性とその対策
文字コードに起因する脆弱性とその対策 Hiroshi Tokumaru
 
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011Hiroshi Tokumaru
 
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~Hiroshi Tokumaru
 
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのかSecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのかHiroshi Tokumaru
 
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Hiroshi Tokumaru
 
安全なPHPアプリケーションの作り方2013
安全なPHPアプリケーションの作り方2013安全なPHPアプリケーションの作り方2013
安全なPHPアプリケーションの作り方2013Hiroshi Tokumaru
 
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかにHiroshi Tokumaru
 
ログイン前セッションフィクセイション攻撃の脅威と対策
ログイン前セッションフィクセイション攻撃の脅威と対策ログイン前セッションフィクセイション攻撃の脅威と対策
ログイン前セッションフィクセイション攻撃の脅威と対策Hiroshi Tokumaru
 
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収Hiroshi Tokumaru
 
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010Hiroshi Tokumaru
 
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)Hiroshi Tokumaru
 
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティHiroshi Tokumaru
 
文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?Hiroshi Tokumaru
 
いまさら聞けないパスワードの取り扱い方
いまさら聞けないパスワードの取り扱い方いまさら聞けないパスワードの取り扱い方
いまさら聞けないパスワードの取り扱い方Hiroshi Tokumaru
 
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試みセキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試みHiroshi Tokumaru
 
安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014Hiroshi Tokumaru
 
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
 Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編) Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)Hiroshi Tokumaru
 
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼうCMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼうHiroshi Tokumaru
 

Viewers also liked (20)

文字コードに起因する脆弱性とその対策
文字コードに起因する脆弱性とその対策 文字コードに起因する脆弱性とその対策
文字コードに起因する脆弱性とその対策
 
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
 
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~
 
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのかSecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
 
Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介Rails SQL Injection Examplesの紹介
Rails SQL Injection Examplesの紹介
 
安全なPHPアプリケーションの作り方2013
安全なPHPアプリケーションの作り方2013安全なPHPアプリケーションの作り方2013
安全なPHPアプリケーションの作り方2013
 
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
 
ログイン前セッションフィクセイション攻撃の脅威と対策
ログイン前セッションフィクセイション攻撃の脅威と対策ログイン前セッションフィクセイション攻撃の脅威と対策
ログイン前セッションフィクセイション攻撃の脅威と対策
 
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収
 
今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010今日こそわかる、安全なWebアプリの作り方2010
今日こそわかる、安全なWebアプリの作り方2010
 
文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)文字コードに起因する脆弱性とその対策(増補版)
文字コードに起因する脆弱性とその対策(増補版)
 
徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ徳丸本に載っていないWebアプリケーションセキュリティ
徳丸本に載っていないWebアプリケーションセキュリティ
 
文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?文字コードの脆弱性はこの3年間でどの程度対策されたか?
文字コードの脆弱性はこの3年間でどの程度対策されたか?
 
いまさら聞けないパスワードの取り扱い方
いまさら聞けないパスワードの取り扱い方いまさら聞けないパスワードの取り扱い方
いまさら聞けないパスワードの取り扱い方
 
セキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試みセキュアコーディング方法論再構築の試み
セキュアコーディング方法論再構築の試み
 
XSS再入門
XSS再入門XSS再入門
XSS再入門
 
安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014安全なPHPアプリケーションの作り方2014
安全なPHPアプリケーションの作り方2014
 
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
 Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編) Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
Webサイトをめぐるセキュリティ状況と効果的な防御方法(WordPress編)
 
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼうCMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
CMS四天王への攻撃デモを通じて、WordPressの効果的な防御法を学ぼう
 
Phpcon2015
Phpcon2015Phpcon2015
Phpcon2015
 

More from Hiroshi Tokumaru

SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021Hiroshi Tokumaru
 
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説するウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説するHiroshi Tokumaru
 
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証するHiroshi Tokumaru
 
SQLインジェクション再考
SQLインジェクション再考SQLインジェクション再考
SQLインジェクション再考Hiroshi Tokumaru
 
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入するHiroshi Tokumaru
 
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1introduction to unsafe deserialization part1
introduction to unsafe deserialization part1Hiroshi Tokumaru
 
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方Hiroshi Tokumaru
 
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門Hiroshi Tokumaru
 
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題Hiroshi Tokumaru
 
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)Hiroshi Tokumaru
 
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門Hiroshi Tokumaru
 
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018Hiroshi Tokumaru
 
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみようデバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみようHiroshi Tokumaru
 
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座Hiroshi Tokumaru
 
ウェブセキュリティの常識
ウェブセキュリティの常識ウェブセキュリティの常識
ウェブセキュリティの常識Hiroshi Tokumaru
 
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則Hiroshi Tokumaru
 
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門Hiroshi Tokumaru
 
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かりウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かりHiroshi Tokumaru
 
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴くセキュリティの都市伝説を暴く
セキュリティの都市伝説を暴くHiroshi Tokumaru
 

More from Hiroshi Tokumaru (20)

SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
ウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説するウェブセキュリティのありがちな誤解を解説する
ウェブセキュリティのありがちな誤解を解説する
 
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
脅威分析の手法によりウェブサーバーにウイルス対策ソフトが必要かを検証する
 
SQLインジェクション再考
SQLインジェクション再考SQLインジェクション再考
SQLインジェクション再考
 
徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する徳丸本VMに脆弱なWordPressを導入する
徳丸本VMに脆弱なWordPressを導入する
 
introduction to unsafe deserialization part1
introduction to unsafe deserialization part1introduction to unsafe deserialization part1
introduction to unsafe deserialization part1
 
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
 
XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門XXE、SSRF、安全でないデシリアライゼーション入門
XXE、SSRF、安全でないデシリアライゼーション入門
 
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
ウェブ・セキュリティ基礎試験(徳丸基礎試験)の模擬試験問題
 
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 (PHPカンファレンス2019)
 
Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門Railsエンジニアのためのウェブセキュリティ入門
Railsエンジニアのためのウェブセキュリティ入門
 
安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018安全なWebアプリケーションの作り方2018
安全なWebアプリケーションの作り方2018
 
秀スクリプトの話
秀スクリプトの話秀スクリプトの話
秀スクリプトの話
 
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみようデバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう
 
若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座若手エンジニアのためのセキュリティ講座
若手エンジニアのためのセキュリティ講座
 
ウェブセキュリティの常識
ウェブセキュリティの常識ウェブセキュリティの常識
ウェブセキュリティの常識
 
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則
 
ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門ウェブアプリケーションセキュリティ超入門
ウェブアプリケーションセキュリティ超入門
 
ウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かりウェブセキュリティの最近の話題早分かり
ウェブセキュリティの最近の話題早分かり
 
セキュリティの都市伝説を暴く
セキュリティの都市伝説を暴くセキュリティの都市伝説を暴く
セキュリティの都市伝説を暴く
 

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
  • 4. ケータイWebアプリの構成 キャリア基地局 ゲートウェイ コンテンツ提供事業者 iモード EZweb Webサーバ DBサーバ Yahoo! ケータイ ワイヤレス網 インターネット 端末 DB (Hand Set) 言語変換 認証 SSL処理 Cookie保持 ・・・ 4
  • 5. 「かんたんログイン」とは 端末固有IDのみを キーとして認証する 端末固有IDあれこれ キャリア 名称 HTTPヘッダ NTTドコモ FOMA端末識別番号 User-Agent iモードID X-DCMGUID Au EZ番号 X-UP-SUBNO ソフトバンク 端末シリアル番号 User-Agent ユーザーID X-JPHONE-UID 5
  • 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を書き換える条件  以下の三条件がそろえば、端末固有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
  • 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
  • 29. Webサイト側でのDNSリバインディング対策  iモードブラウザ2.0のXMLHttpRequestでは、setRequestHeader メソッドが無効化されているので、リクエストヘッダのHostフィール ドはワナサイトのドメインになっている  したがって、かんたんログインの際に、Hostフィールドをチェックす ればよい  簡単に実装するには、名前ベースのバーチャルホストにすればよ い 29
  • 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
  • 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
  • 42. 3月末の某日  ソフトバンク端末にて対策がとられていないか確認  端末のアップデートが動いていないのでダメとは分かっていた  ・・・やっぱりダメだった  しかし、DNSの挙動に変化が・・・ 42
  • 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
  • 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
  • 54. ケータイJavaScriptによる能動的攻撃の可能性  iモードブラウザ2.0はsetRequestHeader()が無効化されているの で、User-AgentやX-DCM-GUIDの変更は不可能と思われる  ソフトバンク端末では、 setRequestHeader()関数自体は無効化さ れていないが、User-AgentやX-JPHONE-UIDの変更は禁止され ている  ・・・  抜け道はないのか? 54
  • 55. 2種類のトリックによる端末固有IDの改変が可能  トリック1:End-EndのSSLを使う  キャリアゲートウェイのチェックをすり抜ける  ソフトバンクにはゲートウェイ型のSSLもあるが、こちらはゲートウェイ のチェックが有効  トリック2:ハイフン「-」の代わりにアンダースコア「_」を用いる  リクエストヘッダ中のハイフンは、アプリケーションが利用する際にア ンダースコアに変更される仕様を悪用 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
  • 58. SSLを悪用した能動型なりすまし攻撃への対策  SSLではかんたんログインを受け付けない  必須はソフトバンクのみ禁止だが、全キャリア禁止することが無難  キャリア判定は、User-Agentではなく、IPアドレスで行う 58
  • 59. まとめ  かんたんログインに対して、ケータイJavaScriptによる攻略手法が わかってきた  かんたんログインに際しての必須対策  キャリアゲートウェイのIPアドレスとのみ通信を制限する  キャリアの判定にもIPアドレスを用いる  Hostヘッダのチェック(あるいは名前ベースのバーチャルホスト)  ソフトバンク端末については、Ajax規制あるいはスクリプトの禁止  SSLでは、かんたんログインは行わない  ・・・  これで完璧かどうかは誰にも分からない  とくに、ソフトバンク端末のように機種依存性が多いと、全ての端末に ついて検証しないと確かなことは言えない  それでも、まだ、かんたんログイン続けますか?  ケータイセキュリティについてオープンに議論できる場の必要性 59