Google Calendar などにアクセスする Android アプリに情報流出のおそれ 19
ストーリー by reo
スマホこわい 部門より
スマホこわい 部門より
ある Anonymous Coward 曰く、
ITmedia News の記事によると、「ClientLogin」という認証方式を使っている Android アプリケーションが、暗号化されない経路で認証情報をやり取りしているという問題が明らかになった (発見者である独ウルム大学のBastian Könings 氏による解説) 。
ClientLogin は Google Calendar や Google Contacts などへのアクセスで用いられており、公衆無線 LAN などの安全でない経路でインターネットに接続した際に認証情報を傍受して個人情報にアクセスしたり改ざんすることができるという。
この問題は Android 2.3.4 以降で対処されているが、調査によれば 2.3.4 以降を利用しているユーザのシェアは 0.3 % 程度であるため 99.7 % の Android ユーザに影響があると考えられるとのこと。
googleさんのコメント (スコア:2, 参考になる)
Google、Androidアプリの情報流出問題で対応を表明 [itmedia.co.jp]によると、「本日(5月18日)からフィックスの提供を開始する。ユーザー側で操作する必要はない。フィックスは今後数日かけて各国でリリースする」とのこと。
これって、要するに各種アプリがhttpsではなくhttpでログイン認証他をやってるから、WiFi等でパケットモニタすれば中身が見られてしまうよって話だよね。androidに限らず、WiFiスポットでノートPCやスマートフォンで接続してhttpのままログインしていれば普通に起きる話じゃないの?
Re: (スコア:0)
Twitter 等で利用されている OAuth 認証なんかは http 接続でも大丈夫な気がするけど、RequestToken の発行からトレースされればアウトかもね。
OAuth 採用のところは、すべて https 接続必須な OAuth 2.0 に移行してほしいね。
Re: (スコア:0)
ログイン認証をhttpでやっているのではなく、セッショントークンをhttpで流す局面が存在しているよ、という話だと思います
Re: (スコア:0, オフトピック)
CalenderでもAndroidでもなくてオフトピ気味だけど、
最近Using Ruby with the Google Data APIs [google.com]
Re:googleさんのコメント (スコア:1)
うへぇ...間違って投稿してしまいました。すいません。書き直します。
最近Using Ruby with the Google Data APIs [google.com]を読んでいたんですが、
ログイン認証時はhttpsなのに、他はhttpのままでトークンを流してるんですよね。
Re: (スコア:0)
ClientLogin の プロセスを解説した図があった。
http://code.google.com/intl/ja/apis/accounts/docs/AuthForInstalledApps... [google.com]
図の 8. と 9. のところが http でも通っちゃうってことかな？
アップデート後の Desire HD もダメでした。 (スコア:1)
手元の Desire HD でバージョンを確認したところ、2.3.3 でした。
Re:アップデート後の Desire HD もダメでした。 (スコア:2, 参考になる)
Re:アップデート後の Desire HD もダメでした。 (スコア:2, おもしろおかしい)
手元のIS01で(ry
RYZEN始めました
OS ではなくアプリケーションの問題 (スコア:0)
ITmeida の記事によると，
「Android 2.3.4 以降の Google Calendar, Google Contactでは対処している」
というだけですので，「この問題は Android 2.3.4 以降で対処されている」という
のは言い過ぎではないかと…。
サードパーティも含めて，アプリケーションが対処していなければ どのバージョンの
Android でも（Android でなくても）同じ「問題」が起こり得るのでは？
ClientLogin自体何用なんだろ？？？ (スコア:1, 興味深い)
いつの時代の発想？って気がするんですが、
ClientLoginは、なぜ平文での実装だたんだろ？
平文POP、SMTP、FTP、etc...
それと同じく仕方なしに残っているものなのかな？
それとも端末内ローカル限定で使える認証機能として
本来は実装したかったのかな？
# ミスは仕方がない
# だが原因は明確にしなければならない
# 勘違があったのか
# 疑問なく用いたのか
# そこが問題だ
Re: (スコア:0)
そうは言っても通信経路上のパケットを傍受される場面てそんなになくない？
ネットなんでどんな経路をとるかわからないけど、不特定多数の人がパケットキャプチャ
出来る場所ってあるのかな？
暗号化されてない無線LANとか変なプロキシとかは論外だけど、
普通にインターネットに接続したら、プロバイダや通信キャリアのルータぐらいじゃない？
キャプチャ出来るのは通信保守のエンジニアとかかなり限られた人だよな
（会社とかなら途中でミラーリングポート持ったSWとかかませられるけど…）
Re:ClientLogin自体何用なんだろ？？？ (スコア:1)
公衆無線ＬＡＮとか。
モバイル端末で公衆無線ＬＡＮ使うなとか、何のためのモバイル端末かわからなくなる。携帯キャリアも携帯電話ネットワークの負荷削減のために、スマートフォン向けに公衆無線ＬＡＮを提供する流れだしね。
exploit disclosure (スコア:0)
Re:exploit disclosure (スコア:2, 興味深い)
とりあえず、有るサイトが全てのサービスをhttpでやってる。
と同じ問題ですので、間に信用できないルータ等が無ければ・・・と言うことですね。
#正確には色々方法はあるけど致命的って程でもないのかなぁ？と思ってみた。
#セキュリティ的にまずいのは認識してますが、ルータ挟めるならHTTPSでも抜けるらしいですし。
Re:exploit disclosure (スコア:1, 参考になる)
・Androidアプリには通常アドレスバーのようなユーザーが確認して回避するための機構はない
・ユーザーが能動的にアクセスするWebサイトと違って、通信はバックグラウンドで行われる
ということでヤバさが違います。PCの世界でも、Apple Software UpdateがSSLを使っていないことは脆弱性とみなされました。
> ルータ挟めるならHTTPSでも抜けるらしいですし。
アプリがオレオレ証明書のエラーを無視して通信を強行するような馬鹿な設計になっていない限り、そんな問題は生じません。責任をユーザーに丸投げしているWebブラウザの場合と違って、通信を続行するかどうかはアプリの開発者が決められます。
Re: (スコア:0)
>#セキュリティ的にまずいのは認識してますが、ルータ挟めるならHTTPSでも抜けるらしいですし。
オレオレ証明書の場合は、ですよね？
バグではなく、仕様です。 (スコア:0)
Google 自身がこの脆弱性を認識していなかったら、そうするべきだったでしょうね。
実際のところは， Google もこの脆弱性を認識していたのではないでしょうか。
# ClientLogin の解説ページにも，できたら OAuth 使おうね，って書いてるみたい。
この場合に「サービスには HTTPS でアクセスしてね」という警告が必要な対象は，
ユーザとサードパーティのアプリケーション開発者だと思われます。なので，手順
としては間違っていないんじゃないかな。
で，（Google が作ってるはずの）「標準アプリケーション」でもきちんと対応されて
ないってのはまずいんじゃないの？というのがツッコミどころの一つだとは思います。
2.3.4 (スコア:0)
Custom ROM焼いてる人を除いて。