Posts tagged ‘脆弱性’

auのPCサイトビューアーで脆弱性が発覚か？ – 続:auのEZWebがそろそろ終了しそうな件

この記事はauのEZWebがそろそろ終了しそうな件の続編です。

当該記事では「EZブラウザとPCサイトビューアーのIPアドレス帯域が統一される」ことから場合によってはEZWebの課金システムや一部認証が脆弱性に晒され得るのではないかと危惧したのだが、もしかすると本当に現在それが起きていた(いる)かも知れない。

F001のHTTPヘッダ

F001（PCサイトビューアー）※一部伏せ字
あれ？REMOTE_ADDRが111.87.241.##？
これ、2011年秋冬モデル以降の一部機種のEZブラウザ/PCSVのIPアドレス帯域じゃないですね。
従来のPCサイトビューアーのIPアドレス帯域でもありません。

EZWebとPCサイトビューアーのIPアドレス帯域が具体的にどんなアドレスになるかは上記の通り既に公表されているのだが、どうやら現在PCサイトビューアーからアクセスすると全く別のアドレスになっているようだ。つまり以前からのアナウンスにも関わらずEZWebとPCサイトビューアーのIPアドレス帯域は統一されておらず別のものになっているようだ。これは何を意味するのか。

auの2011年秋冬モデルである「F001」のHTTPヘッダが従来機と比べて大きく変更になっているようです

通常のEZwebブラウザとPCサイトビューアーのIPアドレス帯域が統一された関係で、PCサイトビューア＋JavaScriptを使っての値のねつ造ができないかどうかが気になります。

上記の記事を見ると、本来来るはずのない帯域からアクセスが来ているとのことなのですが、この辺りの問題が解決できてなかったからとかではないでしょうね。。。

恐らくk-tai.orgさんの予想か当たっているのではないだろうか。

これは想像だが、当初はもちろんEZWebとPCサイトビューアーのIPアドレス帯域は統一されたのだろう。しかしPCサイトビューアーでEZWebのHTTPヘッダーのケータイID(個体識別番号、サブスクライバーID)を偽装できる問題が発覚してしまったのでは無いだろうか。
そのため少なくとも一時的にでも問題を回避できるように、PCサイトビューアーのIPアドレス帯域をEZWebとは急遽別にしたのではないか。

以前の記事からも繰り返しになるが、ケータイIDを脆弱ながらもぎりぎり安全に保つには一般に三つの条件がある。

(1) そのアクセスがそのキャリアの携帯網(IPアドレス帯域)からのみであることをサービスプロバイダーが保証すること
(2) 携帯網ではケータイIDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くしてケータイIDの偽装などの可能性をできるだけ低く保つこと

このうち2についてはauでは採用されていない可能性がある。そして今回PCサイトビューアーとIPアドレス帯域を統一することで1でサービスプロバイダー側にてEZWebからだけのアクセスでありHTTPヘッダーのケータイIDをそのまま信じていいのかどうかは微妙になった。後は3の条件のみが頼みの綱となった。
すなわち「PCサイトビューアーからケータイIDを偽装して付加できることがあっては絶対にならない」のだ。もしそうなってしまえばケータイECの信頼性は崩壊する。
しかしながら、それが今回偽装できることが発覚してしまったのでは無いだろうか。

以上はあくまで想像に過ぎない。またとりあえずPCサイトビューアーのIPアドレス帯域が緊急的に変更されているのなら差し迫った危機は回避されている。

そこで以下のような公開質問をauのカスタマーサポートへ行ってみた。

「PCSVのIP帯域とセキュリティについて」
表題についてご質問です。
1. 今秋冬モデルからEZWebとPCSVのIP帯域が統一されるとのアナウンスがありますが
http://j.mp/vzi7QB
http://j.mp/tG3hDj
こちらの記事 http://j.mp/uEniDb によれば実際には記載の無いアドレスからPCSVはアクセスされているようです。
これは事実ですか？事実である場合理由は何ですか。
2. どこかでこれらはアナウンスされていらっしゃいますか。
3. http://j.mp/v4AqrD では「PCSVにてHTTP_X_UP_SUBNOの偽造が可能なのでは」との推測がされています。
私も同様の疑いを持ちますが事実関係はいかがでしょうか。
4. 3が事実であった場合、現在まで告知がされていません。それは何故ですか。脆弱性は隠したいとの意図でしょうか
なお本件は公開質問として送付させて頂いております。ご回答に付き適時適切に公開させて頂く場合があります旨ご了承下さい。
以上、お忙しい中大変恐縮ではございますが、ご回答頂けましたら幸いです。どうぞ宜しくお願い致します。

(なお質問がつっけんどうで分かりにくく感じられると思うが、これはauの問い合わせフォームが上限500文字で最低限まで文字数を削る必要があったためだ。せめて1000文字ほどあればもう少し丁寧に書けるのだが…)

結果が帰ってくればまたご報告したいと思う。
以前脆弱性公開ポリシーについてauへ質問した際には、「システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する」「セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している」と回答頂いているので、仮に事実であれば問題解消後には必ず公表されるだろうし、また少なくともF001ユーザーやコンテンツプロバイダーには事後報告がされるはずだ。今回の件はその試金石となることだろう。

事実であったとして、F001にはセキュリティアップデートが行われるかも知れない。しかし全ての端末がアップデートをするとも限らない。とすればIP帯域の統一は簡単には戻せないかも知れない。果たしてどのような改修が行われ得るだろうか。
今後その点にも注目しておきたいと思う。

追記(2011/11/23)
Kimuraさんの検証によれば、F001のPCサイトビューアーではJavaScriptでUserAgentおよびX-UP-SUBNOの変更や追加は出来なくなっているとのこと。(以前の機種では出来た)
F001のPCサイトビューアーでsetRequestHeader
こうした仕様はIPアドレス帯域を統一する以上想定内(大前提)の仕様なのだが、にも関わらずIP帯域が分けられていると言うことは、これを回避して変更・追加する方法が存在するということになりますね

追記(2011/11/28)

KDDIから回答が来ましたが、「PCでもPCサイトビューアーでもHTTPヘッダーの書き換えが出来るのは当然のこと」「セキュリティ確保のためEZWebとPCSVのIPアドレス帯域は分離している」のだそうで・・。この自分で整えたちゃぶ台をひっくり返す回答はどうしてくれようか、混乱中です･･･。
因みにEZfactoryのお知らせとIPアドレス帯域に変更がされましたね。何やらこれまでアナウンスしていた「EZWebとPCSVのIPアドレス帯域の統一」が無かったことにされているのですが・・？？

とりあえずこういう質問にしておいた。

以前よりKDDI様では「2011年秋冬モデルよりEZWebとPCSVのIPアドレス帯域は統一する」とアナウンスされていらっしゃいましたが、
下記ご回答とEZfactoryを拝見する限り、これらが無かったことになっているようですね。
今後ともEZWebとPCSVのIPアドレス帯域は恒常的に分離されたままになる、ということでしょうか。
またずっと以前よりアナウンスされていた内容がここに来て突如変更された理由は何でしょうか。私が指摘させて頂いていたように
「当初統一する予定だったが、本来変更できてはいけないX-UP-SUBNOがF001のPCSVでは変更できてしまった脆弱性(または仕様抜け)
が発覚したため、予定を変更してIPアドレス帯域を分離することにした」との理由しか思いつかないのですが、いかがでしょうか。
仮にこれが事実であれば全ユーザーが影響を受けるセキュリティ問題であった訳ですから、お立場のある通信事業者としては
隠蔽するのでは無く明白に公表されるべきと思いますが、いかがでしょうか。

追記(2011/11/29)

徳丸浩氏から今回の脆弱性の詳細について公表されました。

KDDIの新GWで「かんたんログイン」なりすましの危険性あり直ちに対策された

端的にはPCSV単独の脆弱性ではなく、PHPなど特定言語との組み合わせの問題ですね。しかし結果として脆弱性として「合成」されてしまう訳で･･･。悩ましいですね。ただ当面は回避されていること、かんたんログイン時のみの問題であることはまだ幸いであるとも言えるでしょう。

追記(2011/12/03)

遅くなりましたが、11/30に上記質問に対してauより返答がありました。
「敢えて」そのまま回答を掲載します。

IPアドレスの帯域は恒常的に分離しておく予定です。
以前よりアナウンスしていた内容を変更した理由は、セキュリティ確保のためです。
セキュリティ確保のために、IPアドレスを分離したことは既に公表しております。
詳細につきましては、セキュリティの観点から回答は差し控えさせていただきます。

とのことです。

この回答への評価についてはまずは皆さんにお任せしますが、後日別途エントリーを上げるかも知れません。

Posted by ROCA No Comments

オープン化への変貌とキャリアの隠蔽体質を考える – secure.softbank.ne.jpの問題を受けて

7月になってsecure.softbank.ne.jpという一種のSSLプロキシの廃止を受けて、高木さんと徳丸さんから続けて背景説明のエントリーが発表されている。

SoftBankガラケーの致命的な脆弱性がようやく解消
ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る

簡単に言えばこのSSLプロキシの廃止は重大なセキュリティリスクを回避するために絶対的に必要だったと言うことなのだが、詳細はぜひ上記を参照して欲しい。

正直に言うと、この高木さんとソフトバンクモバイル宮川氏のやり取りの前に少しきっかけに関わったので興味を持ってみていたのだが、当初は発端となったアプリ側でのCookieの取り扱いにくさ以上の感触を得ていなかった。
それが違うなと思い直したのは両名が7月を前に盛り上がりだしてからで(笑)、それが同一生成元ポリシーに関わる問題であろうことはその後すぐ気付いた。
しかし実は水面下では、端末のJavaScriptを調整してsecure.softbank.ne.jpでの挙動のみ変更したいたことなどは今回のエントリーで始めて知った次第だ。
アクロバティックな対応だなと思うし、非常に感じるのはこれまで閉塞した世界でなら何も考えずとも良かった問題がJavaScriptやあるいは通信路の解放などといった「オープン化」によって大きく揺らいで行くであろう未来の姿だ。

先のエントリーで徳丸氏は以下のように述べている。

この事例から言えることは、（ガラパゴスと表現されることもある）日本の携帯Web独自の仕様というのものが非常にきわどく、もろいものだということです。

 

携帯Webの仕様がオープンにならないことも問題です。私は前述のJavaScript等の仕様を調べるために、公開されている仕様書だけでは十分でないために、実機での試行錯誤が必要でした。携帯Webの安全性確保のため、開発者やセキュリティ研究者に向けた十分な情報開示を希望します。

僕も全く同意見だ。
そもそもの問題はあまりに日本のケータイWEBがガラパゴスと言われるような独自進化をし、それはクローズドだったからまだよかったものの、ここへ来てスマートフォンに始まり、JavaScriptなどブラウザがリッチ化しOSはAndroidなどよりオープンなもの(逆に言えばキャリアやメーカーが手を加えにくい) となり、また通信路はWi-Fiや定められた端末しか繋げられない閉塞したものではなくPCなどと同居するよりオープンなものへと変貌しつつある。
日本のケータイシーンはただ端末がガラケーからスマートフォンへ置き換えられているだけではない。技術的な観点からすると「一般的なインターネット」へ変貌つつある。

問題はそうした急速な変化の中で果たしてキャリアはこうした旧世代の脆い仕様との乖離に伴う脆弱性に正しく対応可能なのか、ということだ。

少し古い話になるのだが、実は半年ほど前個人的に一ユーザーとして各キャリアに以下のような質問を行ってみた。

1. 具体例は示しませんが、近年携帯電話やスマートフォンに関して、セキュリティ上の脆弱性がネットなどで指摘されることが多くなってきました。
この1年間において御社にて脆弱性が発覚または発見しこれを修正などの対策をされた実績がありますか。ある場合、もし宜しければ具体例をお教え下さい。
2. 1のケースに関わらず、一般論で結構なのですが御社では脆弱性が発覚した場合修正し対応なさいますか。対応する/しないの判断基準はどの点だと認識していらっしゃいますか。
3. その場合、脆弱性があった旨ユーザーに情報を開示されますか。
4. 御社にてこうした脆弱性対応のためのポリシーを策定し運用されていらっしゃいますか。またそれは公開されユーザーへ周知されていらっしゃいますか。

各社様々経緯があり返答に時間もかかり結局一ヶ月近くかかった覚えがあるのだが、簡単にまとめると各社の回答は以下のようなものだった。

多少の違いはあるが、どれも判で押したような特に具体性のない内容であることは間違いないだろう。
注目すべきはどこのキャリアも回答には数週間から一ヶ月かかっている、つまりあらかじめ想定している内容ではなく、 社内調整した結果の回答であったのだろう。それは脆弱性ポリシーの有無の質問に対していずれも明確な回答がなかったことからも察しが付く。
つまりは各社とも今回のような脆弱性への対処については明確な社内規定やルールがあり運用されている訳ではなく、発覚した場合のケースバイケースということなのではないだろうか。
これは一言で言って常に対処が後手に回り対処療法に陥りやすい危険な兆候とも言えるだろう。

「フルディスクロージャ」という言葉がある。これは「脆弱性情報を隠蔽しこれを知り得ている一部の悪意あるユーザーに悪用されるよりは、脆弱性情報を発見したらすぐに広くオープンにして全てのユーザーに完全に周知した方が安全だ」という考え方だ。
これはこれで極端な考え方で、例えば0Dayアタックと呼ばれるような一般ユーザーにこのような脆弱性から守る術を持たないうちから攻撃されるリスクが十分あるからだ。
そこまで極端なフルディスクロージャーは近年では採用されることは少ないが、しかし一方で上記のようなキャリアの態度というのは、これまた極端な「隠蔽体質」と言われても仕方ないだろう。

しかし実はこのフルディスクロージャーの考え方には、インターネット黎明期に脆弱性の隠蔽が頻繁に行われ、その結果被害が拡大した結果、反省と反発からの一種の極論から生まれたという背景がある。

キャリアが理解しているかどうかは分からない。しかし僕にはこれまでのキャリアは閉塞網と完全に制御された端末でのうのうと暮らしてきた「井の中の蛙」に見える。
スマートフォンの伸長は歴史の針を一気に進め、蛙を大海へ叩き込んだ、とも言えるだろう。
彼らが今後暮らさなければならない「本当のインターネット」の大海では、脆弱性情報は共有され適切に管理され、インターネット全体の安全性のバランスを取る仕組みと常識感が既に熟成されている。それはインターネットの巨大なプレーヤーとしてはほぼ責務と言っていい。 だがそんな「本当のインターネットでの常識」に付いていけるだけの力を身に付けられているだろうか。僕は甚だ疑問だ。

キャリア各社は今後スマートフォンへ軸足を移し、また「普通のインターネット」を提供したいと発言している。一方で各キャリア毎に課金・認証の仕組みを導入しようとしており、ドコモはiモードを、auはau one IDをすでにAndroidに組み込んでいるようだ。
けれど彼らは本当にそれらがインターネットの大海でどういう意味を持つか理解して実現できるだろうか。
僕はこうした脆弱性ポリシーや、インターネットでは当たり前の技術情報の周知1つ出来ていない現状では結局同じことを繰り返し、更に酷いセキュリティ問題を繰り広げる未来としか思えないのだ。

Posted by ROCA No Comments

過保護は主体性を腐らせる、のか

ちょっと唖然としたのでエントリーを上げてみる

まあぶっちゃけ
Amebaのセキュリティ対策について

そもそも脆弱性を意識しているエンジニアがいないから、第三者に頼ってるだけじゃん？ってのが大体の感想だろう。このアメーバのコメントでも「第三者検証まで導入している」というのが免罪符のように語られているのが印象的だ。
これには奥深い物も感じていて、そういう第三者検証を導入するからこそ、現場エンジニアの脆弱性に対する意識や主体性、責任感を欠如させている側面があるのでは？と感じる。

ちゃんと金を払って第三者検証を導入しているアメーバ自体は偉いと思う。上がそれなりには脆弱性に対してプレッシャーを感じている証ではあるだろう。
けれど得てしてそういうプロセスを入れることで現場での「どうせ第三者検証プロセスが入るし」「テストチームがチェックしてくれるし」という意識にも繋がりやすい。更に言えばマネージメント層においても「金を払って検証させているのだから問題が発生したら第三者検証業者の問題だ」とのエクスキューズにも繋がりやすい。

テスト全般では当然のことなのだけど、現場のプログラミングチームが主体性と責任を持てないとバグとか脆弱性は減らないんじゃないかな。だいたい、第三者がコードも見ずに脆弱性なんてまず評価できないと僕は思っている。ブラックボックス・テストでホワイトボックス・テストは兼ねられないはずだから。
はまちちゃんも言っているように、どこが悪いだとかどこを直すではなく全体として脆弱性対策が取られていないというのは、現場が全く意識していなくて、第三者検証部隊はブラックボックステストで分かる範囲しか試して無くて、マネージメントは金を払って責任転嫁できると安心している証左だろう。

この辺のモチベーション維持はまさしくマネージメントの範疇であって、いろいろな方法はあると思うけど例えば、バグや脆弱性などの問題は開発チームの責任であって理由は何であれそのチームが確実に対処すること、問題を少なくするのが開発チームの評価であること、一方テストチームの評価はバグ発見率で行うが一方でバグを見逃したとしても何ら責任を取らなくてよい、という体制でチーム運営したことがある。当たり前のことではあるんだけど、意外にここを明快に出来ていないチームも多い。
結果としてどうだったかはちゃんと効果検証できていない(難しい)ので何とも言えないのだけど、そうした主体性を持たせるチーム作りという発想がないんじゃないかな。
せっかく予算も十分にあるだろうに、もったいない。
方向性のない過保護は結局主体性を腐らせてしまうのだと思う。

一方で経営層とかは、テストチームや脆弱性専門業者も入れて金を使ってるのに何で？？とか思って下に当たったりしてるんだろうね。ご愁傷様です。
そういう会社や組織を変えるにはどうするべきなんだろう？と以前考えたことがあるけど、今でもよくわからないです。

Posted by ROCA 1 Comment