タグ別アーカイブ: SSL

2011-07
02
01:55:07
オープン化への変貌とキャリアの隠蔽体質を考える – 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. 御社にてこうした脆弱性対応のためのポリシーを策定し運用されていらっしゃいますか。またそれは公開されユーザーへ周知されていらっしゃいますか。

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

質問事項 脆弱性が発覚または発見しこれを修正などの対策をされた実績はあるか 脆弱性が発覚した場合修正し対応するか。対応する/しないの判断基準はどの点だと認識しているか 脆弱性があった旨ユーザーに情報を開示するか 脆弱性対応のためのポリシーを策定し運用しているか。またそれは公開されユーザーへ周知されているか
ドコモ 特に回答無し – ウィルス対策、パターン更新などの対策を行っている
– 対策の判断基準は脆弱性の程度や影響などを総合的に判断
– お客様にお伝えできる情報は弊社ウェブサイト等にて公開させていただきますことをご了承ください 特に回答無し
au – 脆弱性事例はあり(最近の例を例示) – システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する – セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している 特に回答無し
ソフトバンク 弊社の機密事項に関するものとなるで社外への情報開示はWEBサイトで公開している内容のみでそれ以外は答えられない
イーモバイル 特に回答無し 特に回答無し – お客様に影響を及ぼす問題が発見された場合には、すみやかに情報を開示し対策を実施することとしています。
情報の開示方法は、弊社ホームページ上に掲載するケースや、
個別にご連絡する場合など案件によって最適な方法で実施いたします。
特に回答無し

 

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

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

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

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

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

 

2011-02
11
21:32:11
[改訂版] iPhoneアプリのSSL接続をパケットキャプチャする方法


前回記事のはてブコメントで教えてもらったんですが、Burp Proxyというプロキシー型キャプチャソフトがあるそうです。
で実際使ってみると、これいい!お手軽ですね。Fiddler2と違ってiPhoneアプリでも利用可能です。
ということで改訂版をまとめてみますよ。 一応再度のまとめにしますので前回と被る部分もありますがご了承下さい。

なおやはり再度の補足になりますが、セキュリティの向上や社会的に正当な目的の下で正しく使用されることを期待してこのエントリーを記載しています。筆者は利用の結果に対して全くの無責任・無保証ですので、あくまで自己責任でご利用下さい。

Continue reading

2011-01
24
07:25:54
iPhoneアプリのSSL接続をパケットキャプチャする方法


ブラウザでアクセスするWEBサービスだと、たとえSSL/TLSでセッションが暗号化されていても所詮ピア・ツー・ピア通信なので例えばFirefoxだとFirebugなどでブラウザ側でパケットをキャプチャできます。
でもiPhone(iOS)アプリだとiPhoneにそんなツールが入れられないしキャプチャできない、と思い込んでいませんか?
実は僕もそうだったのですが、この件に関連して可能なキャプチャ方法を見つけたので覚え書きで残しておきます。

但し素人の方法なのでもっと洗練された方法もあるはず。セキュリティクラスタの皆さんにおかれてはよりよい方法をご存じであればぜひTBやコメントなど頂きたく。

なおセキュリティの向上や社会的に正当な目的の下で正しく使用されることを期待してこのエントリーを記載しています。筆者は利用の結果に対して全くの無責任・無保証ですので、あくまで自己責任でご利用下さい。

Continue reading

2010-04
12
00:51:38
続:携帯で端末ID詐称は可能かもしれない話


前回の記事から3年もしてから続編もないものだと思うけど、ちょっと興味深いことに気付いたのでまとめてみる。
とは言えもしかしたらこのことは周知のことであり気付いている人には目新しいことでも何でもないかも知れない。

まずは前回のおさらいから。
端末IDとか個体識別番号とかサブスクライバーIDとか呼ばれる「端末や契約を識別するために端末側やゲートウェイから送出される識別ID」が偽装できるのかどうか実験と考察をしてみた。
docomoのUTNやSoftBankのシリアル番号などのように「端末から直接送出されるID」は携帯網にスマートフォンを接続するなど任意のアプリを実行可能な環境では詐称可能なことを示した。これは例えばUser-Agent環境変数を偽装するだけなので非常に簡単だ。少なくとも当時から現在においてもこれらを認証に利用することは全く持って推奨されない。
またその時実験は行えなかったが、docomoのuidやSoftBankのx-jphone-uidのようにゲートウェイが付加する(であろうと推測される)IDについてはゲートウェイが正しく付加したり偽装を判別するならば偽装は難しいだろう、というのが結論だった。
逆に言えばもしゲートウェイが騙されるようなリクエストが作成できれば偽装も可能だろうと推測したのだが、実際そうした事例もあったようだ。

実はその後エントリーにはしなかったのだけど、自作のWindowsMobileアプリを搭載したスマートフォンをSoftBankの携帯網(WAP)とイーモバイルのEMNetでx-jphone-uidとX-EM-UIDを偽装してみたがゲートウェイでは正しく本来の端末IDに置き換えてくれた。つまり偽装対策はゲートウェイにて正しく行われているようだ。
但しdocomoとauでは環境が整わなかったので試しておらず未確認だ。

さてその前提で、面白い資料を発見した。元々端末IDに関して各社の仕様を網羅的に記した有意義な資料なのだが、特に以下の部分に注目して欲しい。

携帯3キャリア個体識別情報(uid)の特徴 から抜粋

用途
分類 UTN iモードID NULLGWDOCOMO EZ番号 SB公式UID SBシリアル番号
公式連携 × × ×
勝手サイト ×
SSL対応 × ×
URLだけで使用 ×
ログインに使用
URL漏洩時の
なりすまし防止

不向き
SSL URL漏洩時の
なりすまし防止

不向き
× ×
GW-SSLのみ

「SSL対応」という箇所がある。docomoのUTNとSBシリアル番号およびauのEZ番号のみが○である。
SB公式UID(x-jphone-uid)はSSLゲートウェイを指定すればOKだが他については全て×だ。
これは大変重要な事実を示している。

UTNとSBシリアル番号が○なのは当然だ。SSLはポイント・トゥー・ポイントプロトコルであり、つまりブラウザ (この場合は端末)とWEBサーバーが直接暗号通信することで通信が傍受されたり改変されないことを保証するからだ。逆に言えば通常の携帯ゲートウェイがこの直接通信に介入することはできない(SSLゲートウェイは端末<->SSLゲートウェイ<->WEBサーバという2つの通信を見かけ上束ねているだけだ)。
なのでiモードIDやNULLGWDOCOMO、SB公式uidがSSLに対応しないのはゲートウェイでHTTPヘッダーを付加する必要があるから、と理解することが出来る。つまり当然の帰結なのだ。

しかしauのEZ番号(X-Up-Subno)は全てにおいて○だ。SSLにも対応している。
このことから分かるのは、EZ番号は端末から直接送信しておりゲートウェイは何ら偽装対策を行っていないはず、ということだ。

残念ながら(?)、環境が準備できないので本当にそうなのか僕には確認することが出来ない。しかしSSLの理屈からはまず間違いなくEZ番号は端末から直接送出されており偽装対策はまず取られていない。

何度でも記すが、現在の日本のケータイWEB、特にケータイECを脆弱に支えているのは

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

という三位一体の原則だ。これが1つでも崩れれば信頼性は崩壊する。
しかしもし上記の推測が正しければ、ことauのEZ番号については(1)と(3)によってのみしか支えられていない。SIMロック解除論議を持ち出すまでもなく、例えばauの携帯網のアクセスポイント情報が明らかになってしまったら。そこにスマートフォンなどで任意のアプリを実行できる端末が接続可能になったら・・・? 恐らくサービスプロバイダーは偽装を見破る術を持たない。
それが現実になれば、恐慌にも似たケータイECの信用崩壊が起こる可能性が非常に高い。

様々な批判に晒される中で「それでも日本のケータイ技術は世界一なのだから」と嘯くのは自由だ。キャリアの皆さんは好きにすればいい。
しかしこんなにも脆弱な 技術に支えられたバブルをどのような理由で自慢できるのか、さっぱり理解できない。
これまで業界を支えてきたかも知れない日本のケータイ技術はすでに賞味期限切れなのだ。そのことに早く気付いて行動を起こして欲しい。
消費者を人質に取るような寡占業界故の保身はすぐにも止めてもらいたい。

2010/4/13 追記しました。

2006-02
15
22:09:00
OperaではてなのSSL証明書に警告が出る件


Operaではてなにログインしようとすると、セキュリティ警告が表示されます。セキュリティレベルが「弱」だという警告です。
実は今までほとんどその警告には遭遇したことは無かったので気になっていたのですが、どうやらパブリックキーの強度不足(The server is using a short public encryption key, which is considered insecure.)を指摘しているようです。
20060215020853.jpg
調べてみると、はてなではRapidSSL(GeoTrust)を使用しており、パブリックキーは512bit RSA/SHAとなっています。
これが問題になっているみたいですね。512bitというのが短すぎるということでしょう。
20060215214920.jpg
他のサイトでは例えばGoogleなどは1024bit RSA/SHAとなっています。確かにこちらの方が一般的な気がしますね。
20060215215410.jpg Googleの場合の鍵アイコン。これで気付いたんですけど、Opera9ではアイコンにも強度が表示されるようになったみたいです。強度は3(強)です。
20060215215625.jpgこちらははてな。強度は1(弱)とされています。強度が足りないとグレーになるんですね。
因みにRapidSSLのサイトでサンプルのSSL証明書を調べてみると1024bit RSA/SHAです。
そもそもパブリックキーのサイズは、証明書要求の際のキー・ジュネレーション時の指定なので、認証局によってポリシーの差異があるとも思えません。
確かに1024bitが普通になってきたのは最近かもしれないので、昔からそうしたオペレーションになっているだけなのかも知れません。
変更コストもかかることではないと思われるので、次のサイクルからは変更してみてはどうでしょうね。

12