高木浩光＠自宅の日記

■ SoftBankガラケーの致命的な脆弱性がようやく解消

ソフトバンクモバイルのガラケーWebブラウザで、https:接続する際の仕様に変更があった。昨年10月に予告が発表され、元々は2月に実施される予定だったのが、6月30日に延期されていたもの。これまで、https:サイトへのリンクのすべてが https://secure.softbank.ne.jp/ 経由に書き換えられる仕様だったが、この機能が廃止された。

• ソフトバンクモバイル、携帯サイトの仕様変更で注意喚起, ITmedia, 2011年6月30日
• Yahoo! ケータイ、2011年2月に仕様変更 ユーザーとサイト開発者に注意喚起, ITmedia, 2010年10月15日
• MOBILE CREATION - WEB & NETWORK SSL/TLS, ソフトバンクモバイル
  

これは、昨年6月に、ソフトバンクモバイル宮川CTOにTwitterで約束を取り付けていた*1もので、このとき一般には、SSL使用時におけるcookieの非標準的な挙動を排するためのものと受け止められたかもしれないが、じつはそういう趣旨のものではなく、致命的なセキュリティ上の欠陥を排除するための措置である。

経緯

ソフトバンクモバイルのガラケーWebでは、かなり古くから（JPhoneだったころから）、https:サイトへの接続方法が、他キャリアとは異なるものになっていた。他キャリアでは、インターネットにおけるごく普通のSSL接続と同様、ブラウザからWebサーバまでを直接SSLで接続するもの（end-to-endのSSL）であったのに対し、ソフトバンクモバイルでは、HTML中のリンクのURLを書き換えて、例えば、https://example.com/index.html へのリンクをすべて、https://secure.softbank.ne.jp/example.com/index.html へと強制的に変更して、secure.softbank.ne.jp のゲートウェイ上で通信内容の書き換えを行うようになっていた。通信内容書き換えの目的は、ケータイID（X-JPhone-UID）の付与などであろう。

図1: ソフトバンクモバイルによる旧仕様の説明

ガラケーが昔ながらのガラケーであった数年前までは、この仕様も、「まあ許されないとまでは言えないもの」と思っていた*2。なぜなら、ガラケーにはJavaScript機能がない。アドレスバーもないので、アドレスバーによる本物サイト確認は元々できない。*3*4

ところが、昨年の4月、これがまずいことになっていることに気づいた。

事の始まりは、一昨年、NTTドコモが「docomo 2.0」としてJavaScript導入に踏み切った際、徳丸浩氏が「iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性」を指摘したことに遡る。その後、徳丸氏から、じつはソフトバンクモバイルでも端末の一部で同様の問題がある（のだが、回避策がないので公表ができない）という話を打ち明けられた*5。その時点まで、ソフトバンクモバイルの端末にJavaScript機能はないと思っていたのだが、いつの間にか、仕様にないのに一部の端末でJavaScript機能が搭載されているという話だった。自分がテスト用に持っていた端末816SHで確かめてみると、たしかにJavaScriptが動いた。

実証実験

これはまずいかもわからんね、ということで、具体的な危険を確認するため、Gmailを対象にして実験を行った。以下はそのときの記録である。

図2: 実証実験の様子（テスト用画面）

この画面は、私の管理するWebサーバ（攻撃者のサイトと想定）にhttps:のページを作り、以下のHTMLを記述して、IFRAMEとしてGmailサイトを埋め込んだ様子である。画面の上半分がIFRAME部分であり、Gmailにログインした後の状態で試したため、IFRAME中に私のGmailの受信トレイが表示されている。画面の下半分はテスト用のHTML（攻撃側の想定）である。

<iframe src="/mail.google.com/" id="foo"></iframe>
<script>
  function d() {
    return document.getElementById("foo").contentDocument;
  }
</script>
<a href="javascript:alert(d().body.innerText)">Get text</a><br>
<a href="javascript:alert(d().body.innerHTML)">Get html</a><br>
<a href="javascript:alert(d().cookie)">Get cookie</a>

IFRAMEタグでは、SRC属性に「/mail.google.com/」と指定しているが、このページ（https://takagi-hiromisu.jp/test.html）をソフトバンクモバイルの端末で訪れると、表示されるページのURLは、https://secure.softbank.ne.jp/takagi-hiromitsu.jp/test.html（※1）となり、IFRAMEの部分のURLは、https://secure.softbank.ne.jp/mail.gmail.com/（※2）となる。

これは、Webセキュリティの基本*6である same origin policy（同一生成元ポリシー）でいうところの「生成元」が、私の攻撃テスト用ページとGmailページとで同一（https://secure.softbank.ne.jp）になっている。

ということは、私の管理下にある※1のJavaScriptから、※2のコンテンツにDOM経由でアクセスできるということになるはずである。

以下の図3は、上の図2の「Get text」「Get html」「Get cookie」のリンクを踏んだときの様子である。

図3: 実証実験の様子（テスト用リンクを踏んだとき）

このように、Gmailの内容やcookieの内容を攻撃者側から取得できてしまっていることがわかる。同様にして、Gmail側を操作することもできるだろう。

つまり、ログイン中のサイトの情報を盗み出されたり、勝手に操作されてしまう被害（セッションハイジャックされたときと同等の被害）が出る危険があるということである。（Gmailに限らず。）

どう対処したか

これを脆弱性届出窓口に届けるべきか迷った。届けてしまうと、発見者には、取り扱いが終了するまで公開しないよう「お願い」されることになる。しかし、おそらくこの件は長期間直されないまま結果が出ないと予想され、その間何も言えなくなることの方が問題だと考えた。

この問題は、製品の脆弱性ではないし、Webサイトの脆弱性でもない。ソフトバンクモバイル向けにガラケーサイトを提供しているすべてのサイト運営者にも関わることであり、言わば「プロトコルの脆弱性」に類するものと考えた。脆弱性届出のガイドラインでは、次のように書かれている。

III.本ガイドラインの適用の範囲

・国内で利用されているソフトウエア製品
国内で、多くの人々に利用されている等のソフトウエア製品が該当します。「暗号アルゴリズム」や「プロトコル」を実装しているものも含みますが、一般的な「暗号アルゴリズム」や「プロトコル」等の仕様そのものの脆弱性は含みません。

情報セキュリティ早期警戒パートナーシップガイドライン

迷っている間に、何人かの脆弱性発見に慣れた方々に、「こんな脆弱性があるのですが、どうすべきですかね」と話しかけてみたところ、「その件は先日届け出た」という情報を得た。なるほど、既に先に気づいて届け出た人がいると。ならばということで、私としては届出をしないで、独自の活動をすることにした。根本的な解決は、端末の修正ではなく、この方式の廃止だと考えたからである。*7

そして、昨年6月、iPhone用の電波チェッカーの件でソフトバンクモバイルの宮川CTOとTwitterでお話をすることができた際に、ついでに、この件についてもお願いをしてみた。

実は、このやりとりの途中で、SBCSIRT（Softbank Telecommunications Security Incident Response Team）宛に、詳しいことを書いた以下のメールを送っていた。

Subject: secure.softbank.ne.jpの件 （Re: 脆弱性通知: 「電波チェッカー」で...）
Date: Wed, 16 Jun 2010 11:25:41 +0900

SBCSIRT〓〓様

（略）

別件についてここで続けさせていただいてよろしいでしょうか。secure.softbank.ne.jp についてです。

ソフトバンクモバイルの携帯電話のWebブラウザで、https:// のページにアクセスすると、secure.softbank.ne.jp を通すようにリンクが書き換えられる仕組みになっています。（以下参照。）
http://creation.mb.softbank.jp/web/web_ssl.html

これは「ユーザID」をSSL通信時にも利用できるようにするためなどの措置であると理解しています。

しかしこれは、JavaScript機能のある端末では重大なセキュリティ欠陥となります。

なぜなら、すべての https:// のサイトが同じ secure.softbank.ne.jp のドメイン上で表示されるのですから、Webのsame-origin policyが完全に破れ、任意ドメインのサイトから任意ドメインのサイトにアクセスできてしまいます。

たとえば、Gmailをソフトバンクモバイル端末で使うとき、普通にログインしますと、
https://secure.softbank.ne.jp/mail.google.com/.....
というURLで、ログイン状態になります。このとき、ログイン状態の維持は、secure.softbank.ne.jp に対して発行されたcookieによってブラウザ上で制御されます。

ということは、
<iframe src="/mail.google.com/" name="foo"></iframe>
というHTMLを、攻撃者の https:// サイト上に設置すれば、攻撃者は、alert(foo.document.body.innerText); といったJavaScriptでGmailのテキストを取得することができてしまいます。同様に、
alert(foo.document.cookie);
といったJavaScriptで当該cookieを取得することもできてしまいます。

ログイン中の画面を盗み読むことができるだけでなく、任意の操作も可能ですから、致命的な欠陥と言えます。

私がこの問題に気づいたのは、今年4月のことでした。もっと早く気づくべきだったと悔やんでいますが、ソフトバンクモバイルの一部の端末でJavaScriptが動くということを知らなかったためです。フルブラウザとケータイブラウザが分けて提供されている意味は、ケータイブラウザにはJavaScriptを搭載しないというつもりなんだろうと思っていました。

この問題について、私は、IPAの脆弱性届出窓口には届け出ていません。その理由は以下の理由からです。

1. この問題は、特定のWebサイトの脆弱性でもないし、ソフトウエア製品の脆弱性とも言い難い。いわばプロトコルの脆弱性であり、IPAの届出制度の取り扱い対象外だと思う。

2. 修正によって解決する方法がないと思われる。この仕組み自体を廃止して、各Webサイト側が対処するしか解決しないと思われる。

3. 何か月か前に同じ問題について既にIPAに届け出た人がいるという情報を得た。

ここで直接そちらに連絡を差し上げているのは、問題解決が困難と思われるからです。

上で「修正によって解決する方法がない」と書きましたが、修正方法として考えられるのは以下などの候補だと思いますが、それぞれ不適切であると思います。

(a) 全端末のブラウザを修正して、ホスト名が secure.softbank.ne.jp のときだけ特別扱いをし、パス名の最初の部分を仮想的にドメインとして扱う方法。

=> この方法は、どんな副作用が出るか予想もつきません。すべての機能が期待した通りにうまくいくかどうか大いに不安です。今後新機能が追加されるときに何が起きるかもわかりません。

(b) https://secure.softbank.ne.jp/www.foo.com/bar.html という形態をやめて、https://www.foo.com/bar.html の通信を直接書き換えるようにする方法。通信内容を書き換える（ユーザIDの付与等）ためには、SSL通信の中継をする必要があるので、man-in-the-middle attackと同様の方法によって実現する。このときに、端末側でSSLサーバ証明書のエラーが出てしまうのを避ける必要があるので、ゲートウェイ上で、アクセス先ドメイン用の偽の証明書をオンデマンドに自動生成し、その発行者となる独自CAのルート証明書を事前に全端末にインストールしておく。

=> この方法は、実現可能（偽証明書のオンデマンド生成は、企業向けの監視システムで実現されていると耳にします）と思われますが、偽証明書によるSSLというものをはたして、電気通信事業者がやってよいのかという疑問があります。私企業が社内ネットワークの監視目的で導入するのは許されても、電気通信事業者が一般向けのサービスにおいてそれを実施するのは、電気通信事業法違反かどうかわかりませんがスレスレだと思いますし、倫理的に許されないと思います。

(c) ゲートウェイ上のフィルタリングでなんとか攻撃を防ぐ方法。

=> 無理だと思います。

(d) JavaScript機能を凍結する方法。全端末を修正してJavaScript機能を凍結する。

=> 2010年夏モデルからJavaScriptを公式にサポートすると発表されているので無理ではないでしょうか。

以上のことから、secure.softbank.ne.jp は廃止するしかないと思います。

廃止によって何が失われるかですが、ユーザID付与の機能について言えば、元々、SSL経由で送られてきたユーザIDは、偽装されている可能性があるため、認証に使用することができません。

なぜなら、ソフトバンクモバイルは、現在、特定のAPNとProxyを使用することで、PCからゲートウェイ経由でアクセスすることができるため、
http://creation.mb.softbank.jp/web/web_ip.html
のIPアドレスでアクセス制限しているWebサイトであっても、任意のHTTPリクエストを送られる可能性がある状態であり、PCから直接SSLで接続されると、任意のX-JPhone-UID: を送られてしまうのですから、SSL経由でのX-Jphone-UID: はいずれにせよ使用できない状態です。

したがって、secure.softbank.ne.jp は廃止してしまってよいと考えます。

私は、この問題が放置されることを懸念しています。修正による解決が困難で、廃止するしかないときに、廃止の決断ができないで、半年、1年、あるいは何年も放置されるのではないかと懸念しています。

私としては、各Webサイトの安全を守るために、対策方法を周知していかなければならないと考えています。その一つは、secure.softbank.ne.jp を通さないようにするためのリンク方法を見つけ出して周知していくことです。

しかし、周知するにあたって、なぜそうしなければならないかの理由を説明しなければなりません。そのためには、この問題があることを説明せざるを得ません。

一般的には、脆弱性が修正されるまで、もしくは脆弱性を通知してから一定の期間は脆弱性の内容を公表することは控えるべきという考え方が、責任ある情報開示の手順とされていますが、今回のように、修正が見込まれないものについては、回避策を周知することも正当であると思っています。

しかし、できれば、ソフトバンクモバイル自身によってそれを行っていただきたいと思います。つまり、まず、secure.softbank.ne.jp の廃止を予告したうえで、暫定措置として、secure.softbank.ne.jp に書き換えられない https:// のリンク方法を用意してそれを周知することです。そのためには、廃止の妥当性を説明するために、そもそもSSLで送られてきたX-JPhone-UID:を使用してはならないことの周知も必要と思います。

いかがでしょうか。

高木 浩光＠自宅

これ対するSBCSIRTからのお返事は頂けなかったが、上のように宮川CTOとTwitter上で直接対話することとなった。

ソフトバンクモバイルの対応は適切だったか

正直、いくら「廃止するしかない」とお願いしたところで、実現は無理かもしれないと悲観的に思っていた。なぜなら、廃止すると不具合の生じるWebサイトがあちこちにありそうで、そこからの苦情対応に追われることになりそうだからだ。

一方で、昨年5月の時点で、2010年夏モデルから、ソフトバンクモバイルは、Ajaxなどに対応し、正式にJavaScriptをガラケーWebに搭載すると発表されていた（ケータイWatchの記事）。

その後、その夏モデルの一つである「944SH」について、徳丸氏が購入してテストしたという知らせが入った。それによると、新端末では、上記のSBCSIRTへのメールの中で書いていた(a)の対策がとられているっぽいとのことだった。

(a) 全端末のブラウザを修正して、ホスト名が secure.softbank.ne.jp のときだけ特別扱いをし、パス名の最初の部分を仮想的にドメインとして扱う方法。

944SHの発売日は2010年6月18日なので、Twitterでのやりとりから2日後である。つまり、これが「お願いへの対応」ということはないだろう。おそらく、別の方が先に（数か月前に）脆弱性として届け出ていた件への対応、もしくはソフトバンクモバイルが自力で気づいて対応していた結果であろうと考えられる。

一方、従来機種でJavaScriptを勝手にサポートしていた機種については、危険が残ったままということになるが、ソフトバンクモバイルは、別件の脆弱性への対応で、2010年5月27日の時点で、それらの機種ではJavaScriptをオフに設定するよう告知していた。*8

• ブラウザのセキュリティ設定に関する重要なお知らせ, ソフトバンクモバイル, 2010年5月27日（2010年7月2日更新）
• ソフトバンク107機種のブラウザに不具合――個人情報詐取の恐れも, ITmedia, 2010年5月28日
• 今ソフトバンクから携帯電話のスクリプトの設定を OFFにしてくださいとメールが入..., Yahoo!知恵袋, 2010年7月14日

ソフトバンクモバイルによる告知はわりと徹底されていたようで、メールによる告知もされていたようだし、旧機種の販売においては、JavaScriptをオフにするよう説明した紙を同梱していたようだった。（そのわりには、「ソフトウェアアップデート」によるJavaScriptオフ設定への強制変更という措置はとられなかったが。*9）

そうすると、ソフトバンクモバイルとしては、この事案も含めて「もう解決済み」というスタンスなのかもしれないという話になる。secure.softbank.ne.jp廃止の約束はどうなったのか。このまま「解決済み」として、廃止の話は立ち消えになってしまうのではないかとの不安がよぎる。

対処済みと言えるならば、脆弱性情報を公表して、危険性を呼びかけるということも考えられた。しかし、せっかく、宮川CTOがTwitterの場で廃止を約束してくださっているのだから、それを信じたいと思い、しばらく静観することにした。

そして、Twitterでのお願いから4か月後の10月15日、ソフトバンクモバイルから、secure.softbank.ne.jp廃止のお知らせが出た（ITmediaの記事）。廃止の実施はそれからさらに3か月半後の2月1日だという。ずいぶん時間がかかるなと思ったが、廃止が決定されただけでも大いなる英断であると思ったので、とやかくは言わなかった。

それがその後、廃止が2月1日から6月30日へと、5か月も延期されたときには、さすがにいかがなものかと思った。脆弱性の解消である旨も伝えられておらず、ITmediaの記事でも「サイト開発の利便性向上などを目的に」と伝えられているだけだった。

おそらくは、いわゆる「公式サイト」などソフトバンクモバイルと契約のあるサイトに対しては、事前に情報が伝えられて、サイト改修の必要性について説得が試みられていたのだろうと思うが、5か月もの延期が、そうした提携先のわがままによるものだったとすれば、情報を知らされないまま危険を放置することになった一般のWebサイトにとっては、やりきれないものがあるのではないか。

私としては、SBCSIRTへのメールの中で、暫定措置を提案していた。「secure.softbank.ne.jp に書き換えられない https:// のリンク方法を用意してそれを周知すること」と具体的に提案したのだったが、それは実現されなかった。

secure.softbank.ne.jpの機能が生きている限り、Webサイト側での自衛策はそれしかない。また、それさえ提供されれば、廃止までに各Webサイトで事前に対処できるわけで、スムーズに移行できたはずではないか。実現が不可能だったのだろうか。

Webサイト運営者らの反応と対応

secure.softbank.ne.jpは6月30日の早朝に廃止され、Twitterでいくらか反応が出ていた。ざっくり集めたものを以下に示す。

• Togetter - 「secure.softbank.ne.jp廃止時におけるWebサイト運営者らの反応」, 2011年6月30日

やはり、不具合が生じているようだが、secure.softbank.ne.jp廃止は、避けて通るべきではなかった重要な措置であるのだから、こうした措置を遅らせるようなことを言わないようにと願う。

その他、検索して調べてみたところ、2月の時点でもいくらか反応が出ていたようだ。

• Togetter - 「ソフトバンクSSL仕様変更について」, 2011年2月1日

また、この仕様変更によってどのような不具合が生じ得るかについてのまとめもあった。

• SoftBank SSL仕様変更への対処まとめ, 株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報, 2010年11月16日

ここに記載されている情報によると、「SSP（SoftBank Solution Provider）認定企業に限り、申請すれば2月以降も「GW中継SSL」を利用できるようだ。SSP認定企業ならこの方法も選択肢に入れて対処できる」とある。

しかし、そうした申請をする企業は、secure.softbank.ne.jpを使い続けることの危険性を知らされているのだろうか。*10

廃止の理由を単に、「セキュリティの向上。従来はゲートウェイサーバーが一旦SSLを解いていたが、今後は端末とWebサーバー間でSSLが解かれることがない」というものとして解釈していると、「うちのサイトではSSLが解かれても別に問題ない」と、誤った判断をしてしまう虞れがある。

不具合の出たWebサイト運営者におかれては、大変なこととはお察しするが、廃止の重要性に鑑みて、粛々と対応を進めて頂きたい。間違っても、secure.softbank.ne.jpを復活せよなどと要求するようなことはしないで頂きたい。

かんたんログイン廃止、ケータイID廃止に向けて

ソフトバンクモバイルは、2010年10月の時点で、この件についての利用者向けのお知らせを出している。

• 携帯サイト閲覧時の重要なお知らせ, ソフトバンクモバイル, 2010年10月15日
  

上のように、いわゆる「かんたんログイン」が（SSLサイトで）使えなくなることを知らせている。

昨年4月27日の日記「まだまだ他でも破綻しているケータイID認証 」で「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」とまとめたように、ソフトバンクモバイルの端末において、httpsサイトでケータイIDのなりすましを防ぐ方法は存在しない。

ケータイIDを使った「かんたんログイン」なる方式は、そもそも安全に実装できないのだから、この際やめてしまうべきであることは、これまでにも述べてきた通りである。

今回の事態からも、キャリアがインターネット標準から離れた独自方式を安易に投入して、技術コミュニティとのオープンな議論を断絶するようなやり方は、将来に長期にわたってやっかいな問題を引きずりかねないもので、いずれ自分の首を絞めることになるものと、そのような教訓が得られるはずではなかろうか。

その他の類似のケース

ガラケーWebでない、一般のインターネットのWebにおいても、1990年代には、DeleGateを用いて、「-_-」記法を用いて http://www.delegate.org/-_-http://example.com/ の形式で利用する中継サーバを立ち上げて、漢字コード変換や、大阪弁変換フィルタのようなサービスを提供するなどのことが行われていた。

今から思えばおおらかな時代であったわけだが、21世紀になると、JavaScriptが定着し、cookieを用いたログイン機能を持つサイトが当たり前となり、Webの仕組みがsame origin policy（同一生成もとポリシー）に強く依存して成り立つ時代になると、そのようなサービスは危険を生じさせ得るものとなっていた。

今でも、URL中に中継先を指定するサービスが残存しているところがあると思うが、そういうサービスで、中継先のサイトにログインしないように注意しないといけない。いくつかのそうしたサービスでは、そうしたログインができないようにcookieを削ったり、ログインを要するサイトへの中継を遮断するなどの対策をとっているようである。

そうしたサービスで対策のないものは、脆弱性に該当すると言える場合もあるかもしれない。

関連（この問題に気づいたころに書いたもの）

• ここまで破綻しているケータイID認証（簡単ログイン）, 2010年4月25日の日記
• まだまだ他でも破綻しているケータイID認証, 2010年4月27日の日記
• EMOBILEのX-EM-UID、はじめから破綻, 2010年4月28日の日記
• 共用SSLサーバの危険性が理解されていない, 2010年5月10日の日記
• クッキー食えないのはドコモだけ, 2010年5月20日の日記
• 今こそケータイID問題の解決に向けて, 2010年6月19日の日記