高木浩光＠自宅の日記

■ かんたんログイン方式で漏洩事故が発生

ガラケーからiPhoneに乗り換えた人々が「ガラケーサイトが見れない!!」とご不満らしいという話は、聞いたことがあったし、そういう方々向けに「ガラケーサイトを閲覧できる」と謳うスマホ用の専用ソフトが提供されたというのも、どこかで見た記憶があった。

そんな10月9日の夜遅く、ある方から、「iPhone用のSBrowserというアプリで、クロネコヤマトのサイトを使ったら、知らない人の個人情報が出てきてびっくりした。どうしたらいいか」という相談が舞い込んできた。

早速、iTunes Appストアで「SBrowser」の商品説明ページを見に行ったところ、数々の雑言レビューが付いており（図1）、この種のアプリの需要とユーザ層が見えた。

図1: 「SBrowser」に対するレビューの一部

このアプリの機能説明を見ると、「携帯サイトのテストにどうぞ」（図2）と冒頭で書かれているが、実際の利用者層は（レビューの内容からすると）どうもそういう人々ばかりではなさそうだった。

図2: 「SBrowser」の商品説明（冒頭と最後の部分）

そして、最近のバージョンの新機能として「個体識別情報をランダムに自動設定できます」と書かれているのを見て、何が起こったのか、すぐにピンときた。

通報を頂いた方には、その設定のまま使い続けるのは中止するようアドバイスするとともに、設定画面のキャプチャを撮って送ってくださいとお願いした。送られてきた設定画面は、図3（左）のもの*1であった。

図3: SBrowserの設定画面（左：通報者のiPhone、右：私のiPod touch）

私もSBrowserを購入して、設定画面に行き、「ランダム設定」ボタンを押したところ、上の図3（右）のように、「識別番号」と「ユーザID」が設定された。両者を見比べると、同じ値になっていることがわかる。*2

ちなみに、この部分は、SBrowserの初期状態では以下の図4のように空欄になっている。

図4: SBrowserの設定画面の初期状態（「識別番号の送出」をオンにした直後）

「ランダム設定」ボタンを何回か押すと、押す毎に別のランダムっぽいIDが生成されるけれども、プログラマならすぐに予想がつくように、電源を切って入れなおして、SBrowserを起動して最初に「ランダム設定」ボタンを押したときの結果は、必ず図3と同じ値になるという挙動を示した。

「ランダム設定」ボタンをもう一度押したとき（つまり電源を入れ直した後に2回に押したとき）に設定される値は必ず「E33F9A……」という値になるし、その次の値も必ず「B441E2……」という値になる。まあ、コンピュータの「ランダム」というのは基本はそういうもの（擬似乱数）だ。*3

この値が、HTTPリクエストの「X-JPhone-UID:」ヘッダに載せられて送信されるようになっているわけで、この値だけで「かんたんログイン」ができるサイトがあるならば、そもそもそのサイトに脆弱性があるということになる。それだけなら新しい話ではなかった。

しかし今回、意図した攻撃ではなく、不意に他人の情報が見えてしまう事故が発生したのは、SBrowser利用者の何割かが、「ランダム設定」ボタンをちょうど1回押した状態の設定で使用していて、かつ、謳われている「携帯サイトのテスト」用途ではなく、実用としてガラケーサイトで使っていたためだろう。

そうした人々が、同じガラケーサイトを使うと事故は起きる。つまり、Aさんが上記の設定でガラケーサイトで（パスワードで）ログインした後、Bさんが、同じ設定で同じガラケーサイトで、かんたんログインのボタンを押すと、Aさんとしてログインしてしまう事故が発生する。

今回事故が起きたのは「クロネコメンバーズ」というサービスで、携帯サイトは http://9625.jp/ にあり、PCから一般のインターネット回線でアクセスしても、普通に閲覧することができた（今もできる）（図5）。

図5: 「クロネコメンバーズ」の携帯サイト

そこで、「クロネコメンバーズ」に自分のアカウントを作成して、テストを行った。

テストでは、図3のIDを使用しないよう注意し、自分のSoftBank携帯のX-JPhone-UID:の値を手入力で設定（図6左）した。そして、自分のSoftBank携帯で「クロネコメンバーズ」携帯サイトに（クロネコIDとパスワードで）ログインし（図6中央、右）、「クイックログイン」ができる状態にした。

図6: 自分のアカウントと自分のX-JPhone-UID:でテストする様子

この状態で、iPod touch上のSBrowserで「クイックログイン」ボタンを押したところ、（SoftBank携帯で設定したはずの）私のアカウントにログインすることができた（図7）。

図7: SBrowserで「クイックログイン」できた様子

この状態で、「お客様情報の参照」のページに進んだところ、図8のように、登録していた個人情報が表示された。

図8: 「お客様情報の参照」のページを閲覧した様子

報告書を書くにあたっては、「SBrowserの問題」と勘違いされないように、SBrowserを使わないテスト方法の画面を使用した。図9は、Firefoxでテストする様子を示した画面である。

図9: Firefoxでのテスト画面

報告書には、これらの脆弱性を示す証拠の他に、今回は、実際に事故が発生した事実を書き、SBrowserの挙動についても書いた。以下はその部分からの抜粋（図は省略）である。

「クロネコメンバーズ」携帯サイトにおける「クイックログイン」のセキュリティ欠陥について

携帯電話向けWebアプリケーションの「簡単ログイン」方式の危険性について調査する過程で、「クロネコメンバーズ」の「クイックログイン」機能を調べたところ、何ら、なりすまし対策がなされておらず、どこのIPアドレスからでもいつでも誰にでもなりすまして不正ログインされてしまう欠陥があることに気づきましたので、以下の通りお知らせします。

1.「クロネコメンバーズ」 の「クイックログイン」機能の挙動

（略）

2. セキュリティ上の問題点

（略）

3. 生じ得る被害

（略）

4. 事故による実際の被害の発生

10月9日に、ある個人の方から私のところへ、意図せず他人の個人情報を閲覧してしまったとの報告がありました。その方は、iPhoneで「SBrowser」というアプリ（図3左）を用いて、「クロネコメンバーズ」にアクセスしたそうです。

その際、「SBrowser」に契約者固有ID（ユーザID）を自由に設定して送信する機能があり、このIDを「SBrowser」の機能「ランダム設定」（図3右）によって設定したとのことです。

この「ランダム設定」は、タップする毎に異なる「ユーザID」を生成するようになっているものの、iPhoneの電源を入れた直後に「ランダム設定」をタップしたとき（つまり初回の乱数値）は、常に同じ値となるようです。図3の画面はその値を示しています。

このことから、次のシナリオによって事故が生じたと考えられます。過去に別の誰かが「SBrowser」を用いて「クロネコメンバーズ」に「クイックログイン」した際に、このユーザID「76931FAC……」が登録されたと考えられます。その後、別の方（事故の通報者の方）が「SBrowser」を用いて同様に「ランダム設定」をしたところ、同一のユーザID「76931FAC……」が設定され、それを用いて「クロネコメンバーズ」に「クイックログイン」したときに、前者の方のアカウントでログインした状態になったと考えられます。

意図せずその方法でログインしてしまったという通報者の方は、ログイン後の画面に、他人の名前が表示されたことから、驚いて「お客様情報参照」のページへ確認に行ったところ、他人のメールアドレスや住所が表示されたとのことです。

私は、このユーザID「76931FAC……」を用いた再現実験は行っていません。同様の事態を確認するため、自分のソフトバンク携帯電話の契約者固有IDを「SBrowser」にセットして、「クロネコメンバーズ」にアクセスしたところ、図4のように、自分の個人情報が表示されました。

これは、「SBrowser」に問題があるために起きたのではない点にご注意ください。仮に「SBrowser」が存在しなかったとしても、前記の第2節で述べたように、「クロネコメンバーズ」の携帯サイトは、 他人の携帯電話の契約者固有IDを用いて、一般のインターネット回線からPC等によってなりすましログインができてしまう状態にあり、問題の原因は、「クロネコメンバーズ」サイト側にあります。

5. ご参考

こうした欠陥は、これまでにいくつものサイトで存在が確認されており、何度も指摘されているところです。詳しくは以下のWebページをご覧ください。

• はてなのかんたんログインがオッピロゲだった件, 2010年2月21日
  
 http://takagi-hiromitsu.jp/diary/20100221.html
• ユニークIDがあれば認証ができるという幻想, 2010年4月11日
  
 http://takagi-hiromitsu.jp/diary/20100411.html
• ここまで破綻しているケータイID認証（簡単ログイン）, 2010年4月25日
  
 http://takagi-hiromitsu.jp/diary/20100425.html
• 今こそケータイID問題の解決に向けて, 2010年6月19日
  
 http://takagi-hiromitsu.jp/diary/20100619.html

以上

この報告書を、12日の朝にヤマト運輸に送付し、夕方には「関係部署にて検証し、問題のある箇所については善処」という返事をもらった。同じ日に、IPAの脆弱性届出窓口にも届け出た。今回はいつもと違って、現に事故が起きているので、即座に対応されるかなと予想したが、そうでもなかったのは意外だった。

また、今回は現に事故が起きているので、報道機関にも通報した。ここ数年、白浜シンポジウムや越後湯沢ワークショップでしばしばお目にかかる読売新聞の方々にお伝えした。

その後いつ何があったのか、10月19日になって、「クイックログイン」機能が一時サービス停止になった（図10）。

図10: 「クロネコメンバーズ」の「クイックログイン」機能がサービス停止になった様子

そして、10月25日、読売新聞朝刊の社会面で報道された。

• 他人の情報 iPhoneで見えた 「携帯ID」認証に穴, 読売新聞2010年10月25日朝刊

通報してくださった方、ご本人のブログでも、経緯が公表された。

• YOMIURI ONLINEに掲載された「iPhoneで人の情報丸見え」記事について、当事者から。, Moba Photo Life!!, 2010年10月25日

そして、他のメディアからも続報が相次いだ。

• “なりすまし”で閲覧 ケータイで個人情報流出, テレビ朝日, 2010年10月25日
• ヤマト運輸で個人情報漏れ アイフォーンで閲覧可能に, 共同通信, 2010年10月25日
• クイックログインに“穴”、ヤマト運輸の携帯Webサイトに脆弱性, ITmediaニュース, 2010年10月25日
• ヤマト運輸の携帯サイトに脆弱性、他人の情報が閲覧可能に, ケータイWatch, 2010年10月25日

ヤマト運輸からは、以下の告知が発表された。

• 携帯版「クロネコメンバーズのWebサービス」クイックログイン機能の脆弱性への対応について, ヤマト運輸, 2010年10月25日

  2. 影響範囲

  過去のデータを確認することで上記アプリケーションの影響調査は完了しており、1名のお客様が、2名のお客様からログインされたことが確認できました。該当のお客様については個別に対応いたしております。

「1名のお客様が、2名のお客様からログインされた」とのこと。私は図3のIDでのログインをしていないので、今回の通報者の方の他にも（意図せずに）同じように「クイックログイン」で他人のアカウントに入ってしまった事例があったということと思われる。気づかなかった可能性もあるし、びっくりしてスルーということもあるだろう。

類似の話として、携帯サイトで他人の情報が出たという事故は、これまでにも何度か起きており、事故が起きるとサイト運営者が事実関係を発表することが多いのか、ちゃんと表沙汰になっている。

• 下着通販のピーチ・ジョン、携帯サイトで他人の注文履歴が閲覧できる事故, ITmediaニュース, 2006年2月10日

  ピーチ・ジョン側が問題に気付いたのは2月5日。ユーザーから「自分のものではなく他の顧客の履歴画面が表示されてしまう」という問い合わせがあって問題が発覚した。同社では2月5日に、au／Vodafone向け携帯サイトの機能向上のため、プログラム修正を行ったが、その中に不具合があったことが原因だという。（略）

• au携帯電話におけるオンライン書籍販売サイト「au Books」におけるお客様情報の誤表示について, KDDIニュースリリース, 2007年6月26日

  本年6月22日20時37分から23日18時45分までの間、特定のリンク元サイトから「au Books」にアクセスしたお客様に対し、同じ時間帯にアクセスした他のお客様の登録情報 (氏名、住所、電話番号、生年月日、会員パスワード) が表示され、場合によっては、自分の情報が他のお客様の情報に書き換わってしまう事象が発生しました。（略）

• 会員情報の誤表示に関するお詫びとお知らせ, 株式会社インタースペース プレスリリース, 2009年2月24日

  2009年2月15日(日)18：00〜2月17日(火)10：00の期間、ページ内のリンクをクリックした時に、本来であれば移動しなければならないリンク先のページと異なるページへ遷移してしまうシステムの誤作動が発生いたしました。 その誤作動の中で、一部会員の方がマイページにログインした際、他の会員のマイページが誤って表示されるという不具合が発生し、他の会員のメールアドレスが閲覧できる状況が発生しておりました。（略）

• セキュリティ関連ニュース 相次ぐホームページからの個人情報流出〜7月以降、8件が明らかに, So-netセキュリティ通信, 2010年10月15日

  ■一休、携帯サイトで他人の予約情報が閲覧可能に
  （略）は7月28日、7月7日午前0時から12日午後5時30分までの間、一休.com携帯サイトで他の顧客の氏名、住所、電話番号、メールアドレスを含む予約情報が閲覧可能となっていたと発表した。該当者は122名。NTTドコモの「iMENU」で検索を行い、検索結果から一休.comにログインして予約関連の操作を行った場合、アクセス後30分以内にiメニューサイト検索結果を経由して「Myページ」にアクセスした他の顧客から情報が閲覧可能となっていた。
  ・お客様情報の取扱いに関するお詫びとご報告[PDF]（一休）
  http://www.c-direct.ne.jp/public/japanese/uj/pdf/10102450/20100728187820.pdf

  ■オーガスタファミリークラブ、他の顧客情報が閲覧可能に
  （略）は7月21日、通販システムの不具合により、7月9日午後9時〜翌午前0時、または7月10日午後4時〜7月11日正午までに同サイトへ携帯電話でアクセスして注文情報確認画面表示を行った顧客の一部について、住所、氏名、電話番号、メールアドレス、クレジットカード情報が他の顧客から閲覧可能になっていたと発表した。同社によると、アクセス中の顧客を識別する管理情報が正常に発行されないケースがあり、別の顧客の個人情報が携帯電話の画面に一時表示される状態となっていた。
  ・【オーガスタファミリークラブ】個人情報流出のご報告とお詫び（オーガスタファミリークラブ）
  https://www.augfc.net/webshop/apologize.html

これらは、今回のものとは原因が異なる。セッションIDをURLに載せている方式がひき起す障害（リバースプロキシにキャッシュされてしまう障害、あるいはsession fixation脆弱性による障害（2007年6月29日の日記）等）や、レースコンディションのバグが原因のものだろう。

今回の件が従来の事故と異なるのは、従来の事故は、意図してひき起そうとしてもそう簡単にはできない（偶然によって他人の個人情報が画面に出る）ものがほとんどだった思われるのに対し、今回のものは、犯意を持ってすれば任意のユーザの情報を引き出せてしまうという、致命的な脆弱性がある上での偶然の事故であった。その意味で従来の事故よりも深刻度が高いと言える。

今回の読売新聞の記事には、SBrowserの「ランダム設定」について、次の記述がある。

• 他人の情報 iPhoneで見えた 「携帯ID」認証に穴, 読売新聞2010年10月25日朝刊

  エスブラウザの販売元「さいこち」（大阪府）では、「本来、携帯サイトの開発者がアイフォーンを使ってサイトの機能を検証するためのソフトで、今回は想定外の使われ方だ」としているが、エスブラウザは既に約2万5000本を販売。実際には、多くの一般の利用者が携帯サイトを見るために購入しているとみられ、同社では今後、同じID番号を提供しないような対策をとるという。

この対策というのは、おそらく、疑似乱数生成器のseedを時刻などから決定するように変更という話（あるいは暗号論的擬似乱数生成器に変更）だろうと思うが、それで解決なのだろうか。

そもそも、テスト用途であるなら、その対策は無用である。テスト用途でなく、実用を認めるのでれば、その場合のID送信機能は、何のためのものなのか？

もし「かんたんログイン」を使うためだというのなら、そもそも、それはサイト側の致命的な脆弱性があるということであり、それを前提とした用途を提供するというのは不適切である。

それ以外に必要性があるのか。あるとすれば、ガラケーサイトが、ガラケー以外からアクセスされたときにPCサイトへジャンプさせる仕掛けを講じる際に、ガラケーか否かの判定に、User-Agent:だけでなくX-JPhone-UID:などのケータイID（契約者固有IDや端末固有ID）の有無を拠り所にしている場合に、そのガラケーサイトをスマホで閲覧する目的で、だろうか。

そのときに、「ランダム設定」の乱数をちゃんとすることは何の意味があるのか。何らかの事故の可能性に配慮して、他人と衝突しないようにということか。であるならば、衝突しないと言えるだけの、IDの長さが必要であろう。図3のIDは64ビットなので、微妙なところだ。最低でも80ビットは欲しいところであり、ちなみにUUID Version 4では、256ビットになっている。

しかし、IDを長くすると、上記の目的で使えなくなる可能性もある。docomoの場合、iモードIDは長さが固定長で規定されており、7文字の英数字とされている。Webサイト側が、iモードIDを取得する際に、「7文字の英数字」という形式のチェックをしているならば、上記の目的（iモードIDの有無をチェックしているガラケーサイトのスマホでの閲覧）をするには、この形式に沿ったIDを「ランダム設定」する必要に迫られるだろう。

7文字の英数字というのは、(26*2+10)^7 = 3,521,614,606,208 で、42ビットしかない。乱数で設定していると、偶然に他人のIDに一致してしまう確率は、無視できないほどに大きい。それどころか、docomoの本物の利用者のiモードIDに当たってしまう確率も無視できない。

docomoの利用者が5000万人で、1人が2つくらいのIDを消費すると仮定して、約1億個のiモードIDが実在するとする。7文字の英数字のID空間は、上記の通り3兆5千億なので、3万5千倍の余裕しかない。SBrowserの販売数が2万5000本というのだから、全員がそのような利用をしたとすれば、誰かが他人のIDと同じになってしまうことは十分にあり得る。*4

ということは、上記の目的の利用（ケータイIDの有無をチェックしているガラケーサイトのスマホでの閲覧）は広めてはいけないということになる。

結局、SBrowserは、テスト用であることを十分に告知した上で、利用者の責任でもってIDを入力するようにするほかないのではないか。

一方、SBrowserの作者の方のご認識は、事態発覚時のTwitterでの発言から推察できる。（以下は、10月19日のもの。）

お知らせ：SBrowserによる個体識別番号の衝突が原因の可能性がある個人情報流出の報告を受けています。重ねてご案内致しますが、個体識別番号を送出する設定で他者のサイトにアクセスを行なわない様お願い致します。*

Aさんが番号NNNNに設定してサイトXに登録。Bさんが同じく番号NNNNに設定してサイトXにアクセス。結果、BさんがAさんのサイトXに対する登録情報を見えてしまうケース。*

自社プロダクトが火種になった事はとても遺憾ではあるけれども、今回の件を鑑みて「携帯の識別番号だけで簡単ログイン」という機能が滅びてくれると嬉しい。*

むしろ、「識別番号だけのログインは非常に危険」と常々言っていた自分としては逆に悲願として喜ぶべきか。*

しかし、ランダム設定が正しく動作していないというバグを仕込んだ自分としては痛恨の極み。*

@sonk んと、公式サイト等であればキャリアのネットワーク網からアクセスされる事をキャリア側の責任で担保できてたと思うのですが、それならば簡単ログイン大いに結構なんです。*

@sonk ただ、勝手サイトではキャリアの公開するネットワーク帯域を常に確認しながらアクセス制御を行なう事が最低限必要であり、それすら行なっていない場合には簡単ログインはセキュリティホール以外の何者でもないのです。*

@sonk で、さらにキャリアの公開しているネットワーク帯域の情報もそれが必要十分であるかの担保が無いので、安全側に倒すならばその情報を信用しない事が必要であると考えてます。*

@sonk 要はIPアドレスの制御を組み込んでいるにせよ簡単ログインなんて脆弱な物を使うな！ということですw*

@sonk 乱れうち申し訳ないw このあたりを140文字で説明できないんですよねー。何年も前から言われてる事ですし、最近はcookieを喰える端末も増えてきたのでいい加減に他の方法に移行すべきと思ってるのですがなかなか難しいですね。*

@sonk 自分が直接関わるプロジェクトでは絶対に導入しないように説得してますw 違法コピーのアプリを使用するのと同様、とまで言うと言い過ぎなんですがユーザーを保護する為に脆弱性は埋め込んじゃ駄目！って。*

単純に、「ランダム設定」の固定seedはプログラムとしてバグであるということで、修正ということなのだろうとは思う。

一方で、テスト用と謳っているのだから勝手に実用に使うIT弱者が悪いのだと言えるのかどうか。iPhoneは、冒頭で紹介したレビューにあるように、ごく普通の携帯電話と同じ感覚で使われているものであるし、iTunes Appストアも一定の安心感を持って使われているため、提供するアプリの使われ方を限定しようとしても、実用に使いたいという需要の勢いがある限り、無理があると思う。SBrowserを紹介して「iPhone 3Gでケータイサイト見たいんです！」などという記事も出ていた。

• ケータイサイトを閲覧できるiPhoneアプリに惚れた！, ASCII, 2009年6月9日

このことは、iPhoneだけの話ではない。他のスマホであるAndroidケータイにおいても、同様の動きがあるようだ。Androidには「Galapagos Browser」というアプリがあるようで、「端末ID送信」機能があるとされている。

• Galapagos Browser - ガラパゴスブラウザ

  主に以下のような機能を搭載しております。
  ・携帯シミュレーター機能（UserAgent変更、端末ID送信）
  （略）

iモードに対応しているようで、「端末ID送信」機能がどうなっているのかが問題となる。私はまだAndroid端末を持っておらず確認できないので、ググってみたところ、以下の掲示板に情報があった。

• 『ガラパゴスブラウザで』 ソニー・エリクソン ドコモ スマートフォン Xperia SO-01B のクチコミ掲示板, 価格.com

  当方、仕事の連絡を携帯サイトにログインして行っており、この操作が必須なのです。
  これまでの口コミで「galapagos blowser」というアプリで携帯サイトはみれるのはわかりましたが、固体識別番号登録と、ログイン時に携帯電話製造番号通知でログイン制限もしているのです。

  このアプリで
  携帯電話製造番号通知と
  固体識別番号の判別は
  おこなえるのでしょうか？
  当方ちなみにドコモユーザーです

  2010/10/13 21:16　[12055283]

  ガラパゴスブラウザが送出する識別子を確認してみました（略）

  ・送信されていたUserAgentと個体識別子
  DoCoMo/2.0 N905i(c100;TB;W24H16;serXXXXXXXXXXXXXXX;iccxxxxxxxxxxxxxxxxxxxx)

  UserAgentはN905iとして偽装
  ser ＝ FOMA端末個体識別子 ＝ FOMA端末製造番号
  icc ＝ FOMA端末個体識別子 ＝ FOMAカード製造番号 です

  "ser"部分（FOMA端末製造番号）、"icc"部分（FOMAカード製造番号）は、
  iモード端末では数字のみでできた製造番号が送信されるのですが、
  ガラパゴスブラウザではランダム風な半角英数字が送信されます
  このランダム風な疑似識別子をどうやって決めているかは不明です
  （略）

  2010/10/14 00:11　[12056471]

こういう利用形態が広まって、こういうことができて当たり前であるかのような認識が一般ユーザに広がっていくと、元に戻れなくなって、さらには、Webサイト運営者側で、こういう利用のためにIPアドレス制限をあえて外すという、愚かな措置をとる（新たに脆弱性を生み出す）ところさえ出てきかねない。そして、今回同様の事故が再び起きるだろう。

どうすればよいか。最も効果的な方法は、「かんたんログイン」というUI自体を撲滅して、愚かなサイト運営者に真似をさせないことである。そもそも（docomoの「utn」が要らなくなった）今日では「かんたんログイン」というUIは無用の長物である。

そして、ケータイIDを使わず、cookieを使うよう、一般のPCと同じ技術でWebアプリを構成するようにすればよい。それだけの話であって、いまさら議論する余地などない。

関連： 


• 今こそケータイID問題の解決に向けて, 2010年6月19日の日記