2010-02-22 2010-02-22
●ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された
twitterのケータイ版twtr.jpにおいて、DNS Rebindingによるなりすましを許す脆弱性が発見され、1/15に通報したところ、その日のうちに修正された。以下、その経緯について報告する。
経緯
今年の1月12日に読売新聞の記事が出たのを受けて、現実のサイトはどうなのだろうかと改めて気になった。
ＮＴＴドコモの携帯電話のうち、インターネット閲覧ソフト「ｉモードブラウザ２・０」を搭載した最新２９機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。
同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。
[ドコモ携帯、情報流出の恐れ…最新２９機種より引用]
私自身も携帯電話でいくつかのサイトを巡回しており、その一つにtwitter.comの日本の携帯電話向けフロントエンドであるtwtr.jpも含まれる。ご存じのように、twitterは政府要人や有名人も数多く使っているし、twitter.comの画面で確認する限り、鳩山由紀夫首相や原口一博総務相などの閣僚の方々は携帯から書き込みをされることも多いようなので、仮に脆弱性があった場合、影響も大きくなると思った。原口総務相に関しては、記者団からの「Twitterの質問を受けて、つぶやきを確認する原口氏」という報道写真も公開されているので、（スタッフ任せではなく）自ら携帯電話を使いこなしてtwtr.jpにアクセスしておられることは間違いないだろう。
手始めにtwtr.jpのIPアドレスを別のドメインにセットして、携帯電話からアクセスすると、正常に画面が表示される（右の写真）。これはまずい。このため、DNS Rebindingを使ってなりすましができてしまわないか調べることにした。当然ながら、不正アクセス禁止法に抵触しないよう、自分のアカウントを使用して確認を行った。
調査の概要
調査にあたっては、自宅の調査用サーバと調査専用のドメインを用いた。DNS Rebindingを使ったかんたんログインのなりすましは、iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性を発表する際に実験で確認していたが、twtr.jpのログイン画面は、次の点で私の実験とは異なっていた。
- 実験ではGETメソッドだったが、twtr.jpはPOSTを使用
- twtr.jpはログイン時にトークンの受け渡しをしていた
認証機能は副作用を伴うので本来はPOSTメソッドを使うのが正しいし、トークンは、外部から認証リクエストを強要される行為（CSRFに似ているが、認証前なのでCSRFではない）を防ぐためだろう。デジタルガレージ社の実装はセキュリティ上の考慮がなされていると感じた。
しかし、DNS Rebindingを使用すれば、ログイン画面のトークンを読み出すことが可能である。すぐに確認作業が終わるだろうと思っていたが、意外なところで失敗した。ログイン・リクエストのPOSTがうまくいかないのだ*1。早く確認を終わらせないと、もたもたしているうちに脆弱性を悪用されるとまずい。結局、XMLHttpRequestをあきらめ、IFRAME要素を用いることにした。
最初、IRAME要素をDOMで動的に作ったりしていたのだが、IFRAME内のFORMをうまくSUBMITできない。このため、以下のような構成にした。検証コードを公開すると、スクリプトキディが他のサイトで悪用するといけないので、コードは非公開とする。
一般ユーザ（被害者）からリクエストあり ��DNS情報書き換え → これ以降、ワナサイトは twtr.jpのIPアドレスを指す ・以下はIFRAME内の処理 �▲蹈哀ぅ鷁萍未鰺弋瓠淵函璽�ンが含まれる） ��トークン取り出し → ログイン画面のINPUTにセット（写真2） �ぅ蹈哀ぅ鷦孫圈、� セッションIDがCookieにセットされる（写真3） ・以下はIFRAME外の処理 ��CookieをINPUTにセット ��Cookie値を情報収集サーバにPOST 以下は、攻撃者の立場 ・セッションID受信を確認 ・別の携帯電話にCookieをセット ・twtr.jpにアクセス → なりすましを確認 ・書き込みをしてみる → 成功（写真4、写真5）
写真2 |
写真3 |
写真4 |
写真5 |
||
写真2はトークンを受信した様子、写真3はIFRAME上でログイン後にCookie上のセッションIDをINPUTにセットしている様子である。このセッションIDを別の端末にセットして、書き込みをしてみたところが写真4である。
通報・届出およびデジタルガレージ社の対応
脆弱性を確認したので、twtr.jpの運営元である株式会社デジタルガレージに通報するとともに、IPAの脆弱性届出窓口に届け出た。その経緯を時系列で示す。
2010/01/14 深夜 脆弱性の確認完了 2010/01/15 11:37 デジタルガレージ社への通報 2010/01/15 12:52 IPAへの届出 取扱い番号 IPA#04364080 として受信される 2010/01/15 19:18 IPAより届出受理および取り扱い開始の連絡 2010/01/15 21:51 デジタルガレージ社の担当者より修正済みの返信。手元でも修正を確認。 2010/01/19 10:53 IPAより修正完了の連絡。その後取り扱い終了となる。
下図に、修正を確認した様子を写真で示す。
通知からわずか10時間あまりでの修正である。 高木浩光＠自宅の日記 - はてなのかんたんログインがオッピロゲだった件によると、はてなは通知から修正完了まで20日も掛かったようだが（修正内容は異なるものの）株式会社デジタルガレージの対応の素早さは際だっている。
脆弱性の影響範囲
当該脆弱性の影響を受けるユーザは以下の条件を全て満たす利用者である。
- twtr.jpを一度でも使ったことがある
- iモードブラウザ2.0の対応機種(2009年夏モデル以降)の利用者
- iモードIDを通知設定をONにしている（デフォルトはON）
- JavaScriptの設定を有効にしている（デフォルトは有効）
携帯電話のユーザは、大半の方がデフォルト設定で端末を使っていると思われるので、簡単に言えば、iモードブラウザ2.0端末でtwtr.jpを使ったことのあるユーザ、ということになる。
当該脆弱性の影響は、セッションハイジャックによって受ける影響と等しい。すなわち、ワナサイトを閲覧してしまったユーザの当該ユーザでの投稿、ダイレクトメッセージの送信、ダイレクトメッセージの履歴閲覧、自己紹介やプロフィール画像の変更などである。また、「メールでツイートの設定」画面から投稿用メールアドレスを確認しておけば、後からいつでも当該アカウントでのつぶやきが行える。個人情報に関しては、メールアドレスも含めて閲覧できる内容はあまりないようだ。
先にtwtr.jpのユーザの例として挙げた鳩山首相や原口総務相が仮にワナサイトを閲覧させられた場合は、首相や総務相のアカウントで、攻撃者は任意のつぶやきが行えたことになる。
保険的対応
twtr.jpの脆弱性を悪用された書き込みなどは、私の知る限りは公表されていないようだが、脆弱性が修正された今でも油断はできない。仮に、攻撃者がなりすましを成功させていた場合、後から書き込みをする手段があるからだ。それは前述の「メールでツイート」機能を利用する方法だ。これは、その名の通りメール経由でtwitterの投稿をするもので、ユーザ毎の専用メールアドレスに文章を送信すると、その内容がtwitterに投稿される。右の写真は、私の「専用の投稿先メールアドレス」を表示させたものである。このメールアドレスはいつでも変更できるので、twtr.jpユーザは念のため変更しておいた方が良いだろう。
また、twtr.jpはかんたんログインを禁止設定することができない。メニュー上は「各種設定」から「かんたんログインの無効化」というメニューがあるが、試してみたところ、かんたんログインの設定内容を削除するだけで、その後パスワード認証でログインすると、再びかんたんログインが有効となる。このため、ユーザがtwtr.jp上でかんたんログイン設定を残したくない場合は、twtr.jpにアクセスするたびに「かんたんログインの無効化」を実行する（現実的ではない）か、iモードIDを無効化するしかないだろう。iモードIDは、iモードのマイメニューから無効化できる。
利用者がDNS Rebinding攻撃を避ける目的では、JavaScriptの無効化が現実的かつ有効な方法だと考える。
かんたんログイン手法の脆弱性に対する責任は誰にあるのか（再）
デジタルガレージ社がかんたんログインのDNS Rebinding問題を対策していなかった理由は何だろうか。おそらく、単純にこの問題を知らなかったのだろう。無理もない。私が昨年11月に公表していたとはいえ、小さなセキュリティ会社が公表した内容まで含めて、セキュリティ情報をすべて拾い上げて検証・対応しなければならないとするのも酷な話だと思う。しかも、脆弱性を通知したらその日のうちに対策する能力がデジタルガレージ社にあったのだ。IPAの届出制度は、個別のアプリケーションやWebサイトの脆弱性を扱うもので、かんたんログインのような「認証手法」は取り扱い対象外だ*2。このあたり、問題を周知できない自分自身の力のなさを痛感するとともに、やはり携帯電話事業者に『どうやったら「かんたんログイン」なるものが実現できるのか、ちゃんとした実装方法の公式解説を出』してもらわないと、この種の問題はなくならないだろうと改めて感じた。
ツイッターを初めて登録しようと思いますので、よろしくお願いいたします。