ドコモ製Android用メディアプレイヤーのIMEI問題

音楽・動画 | サービス・機能 | NTTドコモ
にわかに話題になっていますが、「どういう時に何の情報が抜かれるのか」が分かっていない人がかなり多そうなので簡単に解説。
(*最後に追記しましたが、仕様が追加されたので以下の問題・攻撃シナリオは(恐らく)解消したと思われます)


■まず、なにが「できない」のか
こちらの方を勘違いしている人が多いので列挙しておきます
・一般のアプリが無許可でIMEIを抜くこと
IMEIへのアクセスにはREAD_PHONE_STATEという許可が必要で、アプリインストール時に許可を取っていないとIMEIにアクセスした途端にアプリがエラーで落ちます。ユーザがREAD_PHONE_STATEを承認しなければ抜けません。
(ただしREAD_PHONE_STATEの説明文が分かりにくいとか、承認範囲をもっと細分化すべきといった指摘はあります。とりあえず今回の問題とは別です)
(追記)ドコモのアプリがインストールされていると、それを踏み台にすることでREAD_PHONE_STATEを無視してIMEIが抜けるという指摘を受けました。その手法を取ればIMEIは抜けます。
・ドコモ製メディアプレイヤーがインストールされていないAndroid端末でウェブアクセスしてきた人のIMEIを抜くこと
本件はドコモ製メディアプレイヤーの仕様バグですので他のAndroid端末は無関係です
■ドコモ製メディアプレイヤーの仕様バグ(セキュリティホール)とは何か
件のメディアプレイヤーは、(ドコモ以外の)外部サイトにアクセスする際、HTTPヘッダにIMEI(端末固有番号)を問答無用で付加して送ってしまう仕様です。
このメディアプレイヤーはOSの制限としてインストール時にREAD_PHONE_STATE承認が必要になるわけですが、困ったことにプリインストールなので出荷時点でドコモが勝手に承認してしまっていることになってしまいます。
■どんな「悪さ」が出来るか(情報漏洩編)
Androidのブラウザアプリは(当然)IMEIを送ったりはしないのですが、ドコモの仕様を見る限りデフォルトで音楽や動画の関連付けがドコモ製メディアプレイヤーに設定されていると考えられます。
つまり、悪用法はこうです。
悪意あるサイトは、Androidでサイトにアクセスされた時に、音楽コンテンツのURLにforwardします。これによりドコモ製メディアプレイヤーを起動しそのURLにアクセスされる(ここまではまともな動作である)わけですが、ドコモ製メディアプレイヤーがHTTP通信する時にヘッダにIMEIを付けて送ってしまう欠陥が存在するため、サイト側はそのアクセスを記録することでIMEIを回収することが出来てしまうわけです。
■どんな「悪さ」が出来るか(なりすまし編)
ドコモはIMEIを使って「悪意のないサイト」に何をさせたかったのでしょうか。それは恐らくガラケーでよくある「簡単ログイン」を意図したものであると思われます。しかしこれは意図そのものが既に重大な欠陥を抱えています。
実はAPIから見える(*後述)IMEIは端末側で変更可能ですし、そもそもhttpヘッダである以上は俺俺Proxyを立ち上げて書き換えることも容易なんです。
しかるにこの欠陥は以下のように悪用可能です。
・まず「情報漏洩編」の手法で他人のIMEIを回収する
・次に「IMEIによるかんたんログイン」を使用して(しまって)いるサイトに対して、盗んだIMEIを自機に設定してアクセス
・その人の権限でアクセスできてうめえwwww
この問題が存在するため、善意のサイトではIMEIを利用しようがないのです(利用するとサイトにセキュリティホールが出来てしまうため)
■つまり?
このメディアプレイヤーのIMEI送信仕様は、悪意あるサイトには多大な利用価値があり、善意のサイトには何の恩恵もない、という壮絶に頭の悪い代物であり、全くのゴミです。
■ユーザサイドの対応策
・ドコモの端末を買わない(あくまでドコモ製プレイヤーの問題であるため)
・ドコモ製メディアプレイヤーをアンインストールする(が、恐らく正常な手法では削除できないと思われる)
・ドコモ製メディアプレイヤーの関連付けを解除し、起動ダイアログが出ても絶対触らない
・ドコモ製メディアプレイヤーの代わりに別の(ダミーの)アプリを関連付けてしまう
3でもいいが単純な解除はできないかもしれません。
4の手法なら恐らく可能で確実性も高いと思われます(実物見ないと分からないですが)
ドコモのプレイヤーと同じIntentに反応する無害なアプリを作ってそれをデフォルトにしてしまえば、勝手に起動することも、起動しようと確認ダイアログが出ることもない……はず。
(追記)
指摘があったので追記。
3/4の方法は悪意のある「サイト」からの攻撃は防げますが、悪意のある「他のアプリ」からの攻撃は防げません。
つまり、悪意あるアプリがREAD_PHONE_STATEを持たないと思って油断してたら、そこからドコモ製メディアプレイヤーを直指定でキックされてしまうと、(悪意あるアプリの作者が管理する)悪意あるサイトにアクセスされてIMEIが抜かれる、という多段式のやり方です。
本当にどうしようもないアプリです。胴元が馬鹿だと手の打ちようがない。
■これはどの程度の「危なさ」なの
これをもって「Android”が”危ない」と勘違いしている人が多いので補足しておきます。
端末またはユーザ固有の番号が確認無しに送られてしまう問題は一般のガラケーに共通する欠陥として既に広く知られています。ガラケーの特性上成りすましはしにくいですが、デフォルトのブラウザで送りまくるためプライバシー問題は完全死亡です。
iPhoneの場合、ブラウザからのアクセスは安全ですがアプリの方でiOS4までUDID(端末固有番号)が確認無しで取得可能で、「悪用禁止だからな!!悪用禁止だからな!!」と言われながらかといってこれで審査落とされません。あまりに悪用されたため遂にiOS5から使用禁止になりました。
ソフトバンク製アプリがUDIDをかんたんログインに使って成りすまし放題になり、高木先生に突っ込まれまくったのも今や懐かしい思い出です。
Androidの場合、ブラウザからのアクセスは安全で、アプリの方もOS1.6から確認が必須です。
ところがこの確認はプリインストールのアプリに対しては適用外なので、「ドコモが」致命的なセキュリティホールを持つアプリをプリインストールしてしまうなどという状況は想定外です。
この結果、ガラケー脳丸出しのドコモのせいで、ガラケーどころか成りすませるだけガラケーよりなお悪い、という素敵な状況になろうとしています←いまここ
ドコモ担当者の方は、何故Android端末でアプリがIMEIを取得するのにユーザに承認を必要とするのか考えて下さい。先人の失敗を繰り返さないためにわざわざ施された布石を見て、なんか邪魔なものがあるからどけよう、としか思わなかったのですか?
まだプリインストール端末がリリースされていないので、今のうちに仕様が変更される必要性を強く訴えます。
(更に追記)
(Q)IMEIって変更できるの?
(A)ハードウェアに記録されているIMEIを書き換えることは(通常は)困難です。
しかしメディアプレイヤーはAndroid FrameworkのAPIを介して取得しているわけですから、ベースバンドが返すIMEIが変更できなくとも、rooted端末やカスタムROMでAPIが嘘のIMEIを返すようにしてしまえば事足ります。
こうなると古いiOS JB端末のUDID偽造問題と同程度まで落ちてしまいます。
もっともドコモの仕様を見る限りAPIを騙すよりHTTPヘッダを透過Proxyなどで改変した方が話は早そうですが。
(10/20追記)
先ほど

ただし、PlayReadyRのライセンス取得を行う通信では、以下となります。(ライセンス取得には、都度ユーザの許諾が必要です。)

との記載が追加されていました。
これって送信先はMSのみという認識でいいんですかね。
PlayReadyの仕様が分からないので俺には何とも言えません。分からんので俺はこれ以上突っ込みません。

コメント 8 件

  1. h_narazaki より:

    おおそういえばそうだwww俺ダセェwwww
    ……はい、ご指摘の通りですorz
    とりあえず本文は直しとくか……

  2. 774 より:

    謹製って謙譲語ですよ。

  3. LFS より:

    もちろん、そうすれば認証に使えるというのはわかりますし本当にそれやっていれば大問題でしょう。
    IMEIを認証に使うなんて発想はマトモな通信事業者から出てこないと信じたいですが。
    アプリの接続先がdocomoの代理サーバとかであればそこでIMEIで弾くとかは可能かと思ってましたが、
    コンテンツの配信方法をみるとそういうわけでもないんですね。
    だとすれば盗難端末のIMEI指定とか?まあ、これもわざわざ確認する人はいないですかね。

  4. h_narazaki より:

    認証に使う場合、最初は普通に登録させて後でユーザ情報とIMEIを紐付ける形になります。
    例えばブラウザ側で一旦ログインさせて、そのセッションIDをGETパラメータに付けてメディアプレイヤーにforward、といったやり方ですね。うーん、おぞましい。
    こうすることでログイン情報とIMEIが紐付くので、次からメディアプレイヤーでアクセスしてきたらIMEIだけでどのユーザか分かるので視聴許可不許可が出せる、というわけですね。
    これを簡単ログインと呼ぶのかDRMと呼ぶのかはともかく要するにIMEIだけで認証できる、と。
    ああもちろんこれ欠陥あるのでやっちゃだめですって話ですよ。
    それと、IMEIだけを見てドコモが売ったものかどうかドコモ以外が知る手段ってありましたっけ?
    ドコモの販売しているIMEIの一覧とかって公開されてんのかな。聞いたことないんですけど。

  5. LFS より:

    IMEIで簡単ログイン(のようなもの)の認証をさせようとしているとは考えにくいと思いますが。
    サービスの認証は当然ながらユーザを識別する必要がありますが、IMEIではその肝心のユーザを
    識別できるものではないんですから。
    IMEIで出来ることなんてdocomoで売ったかどうかの識別くらいなのでその目的じゃないですか。

  6. h_narazaki より:

    WP7と比べると甘いという指摘は正しいです。
    ただし管理系アプリもアプリなわけですから「IMEIにアクセスするアプリが存在しうること」自体がOSの欠陥ではありません(管理系アプリも制限下に置くことが出来るので構造上この方がセキュリティには有利)
    APIには「(1)ユーザに許可なく利用可能」「(2)ユーザが許可すれば利用可能」「(3)システムアプリのみが利用可能」「(4)システムアプリでもアクセス不能」の4段階があります。
    現状は(2)で、(4)だと管理ツールが困りますから、落としどころは恐らく(3)です。ですから(3)ではなく(2)になっていることは問題と言えます。(3)にすればWP7と同等になります。
    この指摘は以前からあるのですがGoogleの動きが悪いというのもまた事実ですので、もっと声を上げられるべきなんですが、いかんせん問題視する側も「なんかよくわからんがこわい」レベルのノイズが多いのが困り物。
    ただし今回のようにキャリア(またはメーカー)がやらかす場合、奴らは(4)のものですら台無しにする権限を持っているわけですからOSの堅牢さ以前の問題です。OSのセキュリティは「出荷時点で既にやらかしている」ような状況まで対応できません。
    あと余所の状況も良くないですよ。
    ガラケーは野良iアプリに関してはガチガチですがブラウザがユルユルで上記(1)の状態です。トラッキング情報以外に関してはまあ比較的堅牢な方ではあると思います。
    iOSもiOS3まで電話番号がiOS4まで端末固有番号が(1)の状態で垂れ流されまくっていましたが世界的に問題が多発し最新では両方(3)です(一方日本ではその間もずっと審査あるから平気とかおバカなことを言っていた)
    いまだに電話帳やスケジュールは(1)のままとの話ですので今後もアメリカでは揉めるんじゃないでしょうか(常識的には最低でも(2)にすべき)
    Androidの場合、電話帳などを含むほとんどの重要情報は(2)~(4)に分類されていますが、まずい情報がいくつか(1)に入っています。IMEIは一応(2)ですので、いまだに(1)に分類されている重要情報を(2)に格上げする方がより火急の問題です。
    本当にまずいのはユーザが重要情報を盗まれていることに気づけない(1)です。ドコモ問題の根幹は、せっかく(2)で保護されていた情報がドコモのせいで(1)まで下がってしまうことにあります。

  7. Docomo IMEI垂れ流し問題 まとめのまとめ

    固有ID系の問題で,昨日の未明から燃えているな.勉強しようと思う.見てみたがなんじゃこりゃー状態.
    出回る前に何とかしてほしい.
    問題のメディアプレイヤーの仕様解説:
    http://megalodon.jp/2011

  8. 匿名 より:

    こんなものを作れてしまうAndroidの仕様自体が問題なのでは?
    Windows Phone 7ではIMEIを取得するAPIすら存在しないという。
    (識別したいならLiveIDを使えって言われるような)
    ガラケーみたいにガチガチ仕様で固めれば(セキュリティ上は)問題ないんだろうけど、Androidはアプリ次第で何でも出きてしまう。
    Androidそのものを買わないように周知すべきかと。

コメントを残す

メールアドレスが公開されることはありません。

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*