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

ケータイ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モードＩＤ X-DCMGUID
Au EZ番号 X-UP-SUBNO
ソフトバンク端末シリアル番号 User-Agent
ユーザーＩＤ X-JPHONE-UID

5

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

6


7


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. 携帯電話の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

115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS
evil 192.0.2.2

ユーザが
ワナを閲覧

16

115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS
evil 115.146.17.185
攻撃者は
DNSを操作

17

115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS
evil 115.146.17.185

ケータイJavaScript

10秒後に
evil.example.jp
を閲覧開始

18

115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS
evil 115.146.17.185

evil.example.jpの
IPアドレスを要求

19

115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS
evil 115.146.17.185

115.146.17.185
を返す

20

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

115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS
evil 115.146.17.185

個人情報を返す
氏名、メールアドレス、
住所、電話番号

22

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

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の改変が可能

 トリック１：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

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

More Related Content

Viewers also liked (20)

More from Hiroshi Tokumaru (20)

Recently uploaded (7)

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