私はいかにしてソフトバンク端末60機種のJavaScriptを検証したか

　昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。　このエントリでは、検証の様子を報告します。

なぜJavaScript対応状況を調査したか

　http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方︵この方︶から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました︵参考のやりとり︶。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 ●確かにJavaScript、XMLHttpRequestが動く ●DNSリバインディング攻撃も成立する ●なんとHostヘッダが書き換えできる。リリースで推奨した対策が使えない　困りました。回避策がないので公表ができません。そのため、ツテをたどってソフトバンクモバイルのセキュリティ担当者に連絡をとっていただき、12月初旬に打合せを持ちました。打合せ自体は紳士的かつスムーズに進み、対応の検討をいただくことになりました。帰り際に、当面この件は秘密にするがあまりに対応に時間がかかるようであれば公表するかもしれないと申し上げました。　その後約半年後に、WASForum2010にてドコモ端末でのDNSリバインディング攻撃について発表することになりましたが、ソフトバンク端末にももっと深刻な問題があることを伏せて、ドコモ端末の問題のみを取り上げるのも心苦しい気がしました。　そこで、あらためてソフトバンク端末でのDNSリバインディング攻撃の影響について評価し直し、影響が軽微であると評価できれば公表することにしました。

まずはマニュアルの調査

　最近の携帯電話のマニュアルはPDF等で公開されており、ソフトバンク端末のマニュアルも公開されています。そこで、約100種類の端末についてマニュアル*1を調査しました。調査のポイントは以下の通りです。 ●JavaScriptに対応しているか ●︵DNSリバインディング攻撃に必要な︶XMLHttpRequestに対応しているか*2 ●XMLHttpRequestはデフォルトで有効になっているか　その結果、以下のことが分かりました。 ●シャープ製の端末はXMLHttpRequestに対応しているがデフォルトでは無効になっているものが多い ●シャープ以外の端末はXMLHttpRequestに関する記述がなく、機能自体がないようにも思えるが、ないと断言はできない　XMLHttpRequestがデフォルトで無効になっている端末だけであれば、NTTドコモの端末向けの対策で対処できるので新たな影響はないと考えたのですが、マニュアルの記述だけでは、全ての端末でXMLHttpRequestがデフォルト状態で無効になっているかどうかは分かりませんでした。

実機での検証を決意

　マニュアルだけからでは確証が得られなかったので、実機を用いて検証することを決意しました。携帯端末の実機検証用に、全ての携帯端末を保有していて貸し出しをする会社が日本には何社かあります。そのうちの一社に申し込みをして、実機での検証をすることにしました。　実機検証の方法には何種類かありますが、一番安上がりの方法として、検証センターの会議室を借りて自分で検証する方法を選びました。その場合、端末の台数と、検証の時間で費用が変わります。　端末の台数については、マニュアルによる調査の感触から、2006年春モデルから2010年春モデルまで、数機種ずつを選択することにして、60台くらいで傾向がつかめると予測しました。また、それ以前の海外製の端末もJavaScriptが動作するものがあると分かっていましたので、検証に加えることにしました。　検証に要する時間は、1台あたり3分以下で終わらせることとして、60台で3時間という目標にしました。これは、かなり *忙しい* 想定です。そのため、以下に述べるように、時間短縮の工夫をしました。

検証用スクリプトの作成

　短時間で検証が終えられるように、検証用スクリプトを工夫しました。下図に、検証スクリプトの実行例を示します。

　表示されているように、上から、ダンプファイル名、iframe利用可否、JavaScript利用可否、XMLHttpRequestの利用可否とHostヘッダの書き換えの有無、User-Agentなどが分かるようになっています。　端末の上側に、インクで821Nと書いているのは、端末をB5サイズのホワイトボード上においてマーカーペンで機種名を書き、全体を写真に撮ることで記録の効率化を図った結果です。

検証用ドメインの取得

　検証を効率化するためには、検証用スクリプトのURL入力時間も馬鹿にならないと予想しました。私が既に持っているtokumaru.orgやhash-c.co.jpでは、まどろっこしい気がしました。そのため、検証用にドメインを取得することにしました。　携帯端末で打ちやすいドメイン名は、テンキーからワンクリックで入力できる文字のみで構成され、かつ文字数の少ないドメインがベストです。具体的には、ドットとA, D, G, J, M, P, T, Wのみで構成されるドメインです。また、同じ文字が連続してもいけません(AAD.JPはダメ)。たまたま.JPドメインはこの条件に当てはまるので、.JPとして取得できるドメインの最小文字数である3文字で、かつ先に述べたアルファベットだけからなるドメインが残っているか調べたところ、幸いまだ数個は残っていました。そのうちの一個を取得しました。これで、ドメインは***.jpと6文字になり、6ストロークのキー入力で検証用スクリプトのURLを入力できることになりました。

検証実施

　準備ができたので、2010年5月某日の13時に検証センターに入りました。　検証センターでは、いきなり60台の端末を貸してくれるわけではなく、四角いトレイに乗った8台程度ずつを預かり、検証が済めばそれを返して次の端末が乗ったトレイを受け取るという仕組みでした。写真を取っておけば良かったのですが、当方も焦っていてそのような余裕はありませんでした。　検証は全体としては順調に進んだのですが、もっとも手こずったのは携帯電話の操作でした。古いノキア製端末などは、操作方法が独特なものがあり、﹁これはどうやって使うんだ?﹂と少しばかり悩みました…が、なんとか分かりました。　検証結果は、下図の写真のように、紙のシートに記録していきました。ノートPCは一応持って行きました。このノートPCは現地でスクリプトを修正するなどの緊急対応用でしたが、幸いなことに出番はありませんでした。

　記録用写真の最後のタイムスタンプは15:56。なんとか3時間で検証を終えることができました。

検証結果の例

　下図に検証結果の写真を示します。機種は、先ほどの821Nです。


JavaScriptの設定画面	基本の検証画面	ヘッダ改変チェック(HTTP) Hostヘッダ、Refererが改変できている。	ヘッダ改変(HTTPS) User-Agent、端末製造番号、 UIDが改変されている

　821Nは、JavaScriptによるヘッダ改変の自由度がもっとも高い機種の1つです。　ご覧のように、HTTPSではUser-AgentとUIDの改変ができています。User-Agentが変更できるということは、端末製造番号も変更できるということです。　HTTPSの方が変更できる幅が広いと書くと、﹁HTTPSは改ざんできないはずなのにどうしてだ?﹂と疑問に思われる方が出てくると思います。しかし、HTTPSは通信路上での改変を防ぐもので、端末上でのヘッダの変更を妨げるものではありません。さらに、HTTPの場合はゲートウェイでヘッダのチェックや︵正しい値への︶変更が入っているのに対して、HTTPSの場合はゲートウェイでのチェックや変更ができません。ゲートウェイは端末とWebサーバーの途中にあるので、HTTPSの保護範囲であり、ゲートウェイは素通しになるのです*3。　現在、某銀行において、ソフトバンク端末でオンラインバンキングが使用できなくなっています。アナウンスを読む限り、SSLでケータイIDをチェックしていたようですが、現実には、SSLでケータイIDを認証等に用いることは非常に危険です。ケータイIDを認証に使うこと自体が好ましくないわけですが、仮に使うのであれば、SSLを避けなければなりません。

結果

　検証の結果、820N、821N、830CA、940SCの4機種*4で、デフォルトでXMLHttpRequestが使えることが分かりました。これらの端末では、DNSリバインディング攻撃の影響を強く受けるわけですが、幸いこれら機種のシェアは低く、危険性の公開に踏み切った方がマクロで見れば安全性が高まると判断しました。私の発表の後、すぐソフトバンクからもJavaScript停止の案内が出ましたので、情報公開して良かったと思います。

まとめ

　ソフトバンク端末のJavaScript対応状況の一部始終を報告しました。PCと違って、実機を用いないと検証ができないのでやっかいですね。せめて、端末に関する技術情報がもっと開示されるとよいと思います。　また、ケータイに関する脆弱性を知ってしまうと、取り扱いに窮する場合があります。このあたりの実状は、このエントリの他、高木浩光氏のエントリ高木浩光＠自宅の日記 - SoftBankガラケーの致命的な脆弱性がようやく解消も参考になります。

[PR]