エフセキュアブログ

ssl を含む記事

新ブログ:labsblog.f-secure.com

 このブログ「News from the Lab」(訳補:https://www.f-secure.com/weblog/)は、4,232日前に、Mydoomワームによるsco.comへのDDoS攻撃を監視する件から始まった。

 これが11年2か月とちょっと前のことだった…。そして我々は今、新たなサイトへブログの引っ越しを行った。

 https://labsblog.f-secure.com

labsblog.f-secure.com

 RSSフィード経由でNews from the Labをフォローする場合は、好みのリーダーでここを指定しよう(近々、301リダイレクトを設定する)。

 またTwitterで@FSLabsを「フォロー」することもできる。Twitterでは記事へのリンクやその他のことをつぶやく。

 では、f-secure.com/weblogのコンテンツに起きたことは、何だろうか?今のところは、ここにちゃんと置かれている。ここからアーカイブを見られるし、Bingで検索することもできる。なぜBingかって?というのも、Googleは2012年10月頃、検閲を始めた大々的にこのブログのインデックス登録を停止したからだ。我々の伝統的な方法でのRSS全文配信における何かが、Googleの「Penguin」アルゴリズムと衝突した(世界中の情報をまとめるなんてことは、もはやこれでおしまいだ)。結局、検索エンジン企業の事業利益を拡大することがなければ、検索エンジンに記憶される権利はないのだ。公平を期して言うと、当時Googleはコンテンツファームとの戦いに大きな問題を抱えており、当社はそれに巻き込まれただけなのだ。コンテンツファームは、意のままに当社の全文配信を取り上げて、再発信できる。そして、無用なものといっしょに必要なものまで捨てられた。

 おそらく、これからもさらにそうなるだろう。

 最終的な考えはこうだ。このブログが当初2007年7月4日にリリースされたバージョンのプラットフォーム上で動作しながら、いかにセキュアであり続けるか?答えはシンプルだ。このプラットフォームはもはやWeb「上」にはない。このGreymatterのブログは内部サーバ上で稼働しており、我々はスクリプトを利用して、Webベースのフォルダにコンテンツをコピーしている。そのため、あなたがたった今読んでいるものは、コピーに過ぎないのだ。

 もはや何か違うことを試みるときが来た。そちらで皆さんに見えることを楽しみにしている。

 では!

JVNVU#92002857とGoogle不正証明書事案のメモ

しばしば騒ぎになる証明書、認証局関連の事案ですが、先週より俄かに盛り上がってますね。
今週はJVNVU#92002857の問題。先週はGoogleがブログで報告した問題についてです。

前者はJVNの報告によれば、
複数の認証局において、証明書発行時の確認が「特定のメールアドレスでのやりとりが可能であること」のみで行われています。これにより、関連するドメイン の管理とは無関係な第三者によって SSL 証明書が取得され、クライアントのソフトウェア上で警告が発せられることなく HTTPS スプーフィングが行われる可能性があります。
とのことです。つまり、想定脅威としてはフィッシングサイトが立ち上げられたり、HTTPS通信の傍受等の可能性があるということになります。影響のあるシステムは、CERT/CCのVendor Informationを参考にしてください、とのことです。まだ、被害情報は耳にしていませんが、ある程度の影響はあるかもしれませんね。

また、後者については、Googleが複数のGoogleドメインの不正なデジタル証明書を発見しブロックしたことをブログで報告しています。記事によれば、この証明書はMCS Holdingの所有する中間認証局が発行しており、この中間証明書はCNNIC(中国インターネット情報センター)により発行されている、とのこと。この辺りは、GREATFIRE.orgars technica に詳細に記載されていますのでご参考までに。
尚、Googleのブログ投稿者は次のようなツイートをしています。内容から憶測すると、被害が発生していても不思議では無さそうな雰囲気です。

langley tweet

前者は認証局、後者は証明書(一部、中間認証局?)の問題の情報となります。
特に後者のような通信傍受目的(?)と推察される攻撃は、今後も目が離せません。
この種の攻撃は、比較的広範囲において影響を受ける可能性もあり、今後も続く脅威のひとつとしてみています。
実現性のある根本的対策が待たれるところですが、それまではひとつひとつの脅威に対処していくしか無さそうですね。
今後、国内の中間認証局がターゲットになるかは分かりません。とりあえずは節目の年である2020年まではウォッチし続けていこうと思った、今日この頃でした。。。


Apple Watchが恐らくマルウェアに感染しない理由

アップルが最新のiPhoneのモデルと、待ち望まれていたウェアラブル技術の新製品を発表しました。Apple Watchです。

TechRadar誌はクパチーノ発の最新のイノベーションを「iPhoneと併せて楽しめるiOS8フレンドリーな時計」と評してします。

最新のエフセキュア・ラボによる「脅威レポート」はiOSのマルウェアに関するひとつの大きな誤解を払拭しています。存在するのです、極めて稀ではありますが。

Screen Shot 2014-09-09 at 4.43.06 PM

2014年の上半期に、295に及ぶモバイルのマルウェアの新しいファミリーや亜種が発見されました。294はAndroid、そしてひとつはiOSを狙ったものです。iPhoneユーザーはフィッシング詐欺やWi-Fi乗っ取りの被害に会う可能性があり、そのためにエフセキュアはFreeDome VPNを開発しましたが、iOSデバイス上の悪意あるアプリの脅威はほとんど存在しません。

「Androidと異なり、iOSでのマルウェアは現在のところ’脱獄’したデバイスに対してのみ有効であり、様々なハッカーによって作成された’脱獄’ツールは(そしてそれらは通常プラットフォーム上の未公開のバグによって作動します)、セキュリティ研究者の関心を引くところになっています」とレポートは解説しています。

Unflod Baby Pandaと呼ばれるiOSの脅威は今年初めに発見されました。これはデバイスのApple IDとパスワードの詳細を詐取するために、SSL接続を盗聴します。Apple IDとパスワードは最近ニュースで取り上げられているように、著名人のiCloudのアカウントを乗っ取る一連の作業の中で一部の役割を担っており、多くのプライベートな写真が公開されてしまう事件に繋がりました。

弊社のミッコ・ヒッポネンは最新のウェビナーにて次のように説明しています。「多くのユーザーは何年もの間これらのアカウントを使用し続けており、それは主にiTunesストアから買い物をするためですが、どれだけのデータが実際に保護されているのか気づいていません。」

しかしUnflod Baby Pandaは著名人のハッキングにはほとんど役割を果たしていません。デバイスの’脱獄’は極めて稀だからです。iOS App Storeの「クローズな空間」の手法による保護がハッキングを防いでいることを認識しているユーザーはほとんどいません。その手法はプラットフォームからマルウェアを排除することに成功しており、特にオープンなAndroidの世界と比較すると顕著です。悪意のあるアプリやアドウェア、スパムウェアが公式のPlayストアに潜入することもありました。一方iOS App Storeではほとんどありません。しかしAndroidの脅威の大多数は非公式のマーケットから感染するため、エフセキュア・ラボは非公式のマーケットを避けるよう勧めています。

iPhoneユーザーの大多数はマルウェアについて心配する必要はありませんでした。そしてApple Watchがアプリに対して厳重な制限をかけるのであれば、デバイスはセキュリティの心配は無用でしょう。
しかしスマートフォンに匹敵する能力をもつWatchを丸一日ほぼ24時間、体に装着するのであれば、従来考慮されていなかったプライバシーに関する問題を引き起こす可能性があります。

>>原文へのリンク

管理者達へ:Heartbleedの修正するときに設定基準を見直そう

 とにかくSSLの更新は必要なので、設定が最近の基準に沿っているかについても確認しようではないか。

 Heartbleedについてたくさんの大騒ぎがあったから、管理者ならすでに何をすべきか知っているだろう。

 1. 脆弱なバージョンのOpenSSLを使っているものをすべて特定する
 2. 最新バージョンのOpenSSLに更新する
 3. 古いプライベートキーとSSL証明書は漏えいした可能性があるので、新しいものを作成する
 4. 古い証明書を失効にする

 だがサーバの設定を触って、新しいSSL証明書を作成しなければならないのなら、証明書生成の設定やサーバの設定にも手を伸ばすことをお勧めする。HeartbleedはSSL/TLSの実装における問題だけではない。プロトコルを下手に選択したり、暗号方式が弱いと、Heartbleedのバグと同等に危険になり得る。

 OWASP Transport Layer Protection Cheat Sheet(Open Web Application Security Projectによるトランスポート層保護についてのチートシート)を一読することを推奨する。

 そしてボーナスポイントのチャンス!

 5. PFS(Perfect Forward Secrecy)を実装する。これは件のOWASPのチートシートの「Prefer Ephemeral Key Exchanges」というルールのところに記載がある。

 詳細については、EFEの「Why the Web Needs Perfect Forward Secrecy More Than Ever(なぜかつてないほどWebにPFSが必要なのか)」というポストを参照してほしい。

追記:

 もう1つ追加する。

 6. トランスポート層のセキュリティのみに依存してはならない。もしデータがクリティカルであるなら、実装において追加的な保護を用いる。

 一例を挙げるならYounitedだ。「How do I turn on advanced login authentication?(高度なログイン認証を有効にする方法は?)」というサポートの質問を参照してほしい。

younited's 2FA

 2要素認証だ。提供してほしい。お願いだ。

更新:

 プライベートキーの変更が当然必要なことや、古い証明書を失効にすることを明確にする記述を追加した。ありがとう。@oherrala.

広範な攻撃ツールFinFisher

 FinFisherGamma Groupという企業によって開発、販売されている広範な攻撃ツールだ。

 最近、FinFisherの販売用のパンフレットやプレゼン資料がネット上に流出した。そこには、このようなツールに関する数々の興味深い詳細が記されている。

 FinFisherのプレゼン資料での背景のパートでは、Gamma社の攻撃ツール群を構築するために、同社がどのようにBacktrack Linuxの(当時の)中心的な開発者を雇ったかの説明に続いている。これはMartin Johannes Munchを指している。同社はまた、自社の開発者達がBlack HatやDEF CONにどれくらい参加したかを自慢している。

FinFisher

 FinUSBツールはUSBスティック経由でコンピュータを感染させるために使用される。「Can be used e.g. by housekeeping staff(たとえば家政婦でも使用可能)」

FinFisher

 このドキュメントによれば、FinIntrusionキットは、たとえサイトがSSLを採用していたとしても、無線ネットワーク経由でユーザ名とパスワードを記録するために使えるそうだ。

FinFisher

 Gamma社はまた、ユーザのネット口座の認証情報の窃取に、FinIntrusionが使えることを強調している。

FinFisher

 バックドアFinFly(USBドライブからデプロイ)は「can even infect switched off target systems when the hard disk is fully encrypted with TrueCrypt(ハードディスク全体がTrueCryptで暗号化されている場合、標的のシステムの電源が切られていても感染可能)」とのことだ。

FinFisher

 FinFly Webエクスプロイトは、自動的に気付かれず感染させる(drive-by-infection)ために使用できる。また地域のISPが当該エクスプロイトを組み込むと、被害者がGmailまたはYoutubeへアクセスする際に、これらの「信頼された」サイトへモジュールを注入することが可能だ。

FinFisher

 被害者を感染させる別のメカニズムでは、被害者がダウンロードする度に、マルウェアを含めるように、被害者のISPが汚染させるようにする。また、これは自動ソフトウェア更新に手を入れることでも実現可能だ。

FinFisher

 興味深いことに、FinSpy Mobileの説明でWindows Phoneをサポートしていることに特に言及している。これは我々が気付いた、初のWindows Phoneのマルウェアへのリファレンスになる。

FinFisher

Flameは不十分

  Flameマルウェアが2週間前に発見された時、「非常に先進的」「スーパーマルウェア」「史上最大のマルウェア」と呼ばれた。

  これらのコメントはすぐに、Flameには特に新しい点も興味深い点も無いと指摘した専門家たちによる嘲笑を受けた。

  実際、Flameで唯一ユニークなのは、そのサイズでしかないようだ。それとても、それほど刺激的ではなかった。アナリストはもっと大きなマルウェアの事例を探してきたし、実際、発見してもいる(マルウェアの中にはビデオファイルのように見せかけようとするため、本体にノーカット版の映画を含むものもある)。

  FlameがStuxnetやDuquのように、政府によって作成されたもので、国民国家が作成したものだという示唆も、嘲笑を受けている。

  しかし、この2週間で我々がFlameについて知ったことを見てみよう。

1. Flameはキーロガーとスクリーングラバーを持つ

  否定派は感銘を受けていない。「以前、見たことがある。Flameは不十分だ。」

2. FlameはビルトインのSSH、SSLおよびLUAライブラリを持つ

  「肥大化している。遅い。Flameはやはり不十分だ。」

3. Flameはローカルドライブおよびネットワークドライブで、すべてのOffice書類、PDFファイル、Autodeskファイル、テキストファイルを探す。盗み出せる情報が多すぎるため、IFilterを使用して書類からテキストの引用を抜粋する。これらはローカルのSQLLiteデータベースに保存され、マルウェアのオペレータに送信される。このようにして、彼らはマルウェアに指示し、本当に興味深い資料に焦点を合わせる。

  「Flameは不十分だ。」

4. Flameは感染したコンピュータのマイクをオンにし、マシンの近くで話される会話を録音できる。これらの会話はオーディオファイルとして保存され、マルウェアのオペレータに送信される。

  「Flameは不十分だ。lol」

5. Flameは感染したコンピュータとネットワークで、デジタルカメラで撮影された画像ファイルを検索する。これらの画像からGPS情報を抽出し、それをマルウェアのオペレータに送信する。

  「Flameはやはり不十分だ。」

6. FlameはBluetoothを介して、感染したコンピュータに接続している携帯電話があるかどうかをチェックする。もしあれば、その端末(iPhone、Android、Nokiaなど)に接続し、アドレス帳の情報を収集して、マルウェアのオペレータに送信する。

  「Flameはやはり、ちょっと不十分だ。」

7. 盗まれた情報は、感染したマシンで使用されているUSBスティックを感染させ、このスティックに暗号化されたSQLLiteデータベースをコピーすることにより、それが閉環境の外側で使用された時に送信される。このようにしてデータは、ネットワーク接続の無い安全性の高い環境からも盗み出されることになる。

  「Agent.BTZが2008年、既に似たようなことをしている。Flameは不十分だ。」

8. Flameは現在、とうとう捉えられたが、攻撃者はすべての証拠を破壊し、影響を受けたマシンから感染を取り除こうと活動している。

  「何も証明されていない。不十分。」

9. 最新の調査で、Flameが実際、Stuxnetと関係していることが分かっている。そしてFlameが発見されたちょうど1週間後、イスラエルの軍隊とともにStuxnetを開発したことを米国政府が認めた

  「大げさにしようとしているに過ぎない。やはり不十分。」

10. FlameはMicrosoft Updateへのトラフィックを傍受するのに使用する、ローカルプロキシを作成する。これはFlameをLANで他のマシンに広めるのに使用される。

  「不十分。他のコンピュータがそうした偽のアップデートを受けとったにしても、Microsoftによって署名されていないのだから、受け入れるはずがない。」

  攻撃者がMicrosoft Terminal Serverライセンス証明書を再利用する方法を見つけたため、偽のアップデートはMicrosoftのルートと結びつく証明書で署名されている。これだけではWindowsのより新しいバージョンになりすますことはできないとしても、最先端の暗号の調査が行われ、証明書のスプーフィングを可能にするハッシュ衝突を生み出す、完全に新しい方法が考え出されている。しかし、彼らはさらにスーパーコンピュータを必要とした。

  「…」

  そして突然、何の前触れもなく、Flameが不十分か否かに関する議論は…消えてしまった。


Stuxnet、Duqu、Flameについて

  2日ほど前、イランから電子メールを受けとった。イランのComputer Emergency Response Teamのアナリストからのもので、彼らのチームが、さまざまなイランのコンピュータに感染させていることを発見したマルウェアについて、私に知らせてきた。これはFlameであることが判明した。世界中でトップニュースになっているマルウェアだ。

  マルウェアに関連するサンプルを、我々のアーカイブで探したところ、2010年、2011年に遡って、すでにFlameのサンプルを保有していたことを発見して驚いた。持っていることに気づいていなかったのだ。これらは自動の報告メカニズムを通じてもたらされたものだが、詳細に検討すべきものとして、システムから警告が出たことは一度も無かった。他のアンチウイルス企業の研究者は、それよりさらに以前に同マルウェアのサンプルを受けとった証拠を発見した。同マルウェアが、2010年以前のものであることを示す証拠だ。

  これが意味するのは、我々全員がこのマルウェアを2年かそれ以上、検出できずにいたということだ。これは我々の会社の、そしてアンチウイルス業界全体のミスだ。

  このようなことが起きたのは、今回が初めてではない。Stuxnetは、イン・ザ・ワイルドになって1年以上、検出されず、ベラルーシのアンチウイルス企業が問題の起きたイランのマシンをチェックするために呼ばれ、ようやく発見された。研究者がStuxnetに似たものをアーカイブで探し求めたところ、Stuxnetで使用されたゼロデイエクスプロイトが、他のマルウェアと共に、以前使用されていたことを発見したが、当時はそれに気づいていなかった。DuQuという関連するマルウェアも、1年以上、アンチウイルス企業の検出を免れていた。

  Stuxnet、DuquそしてFlameはもちろん、通常の良くあるマルウェアではない。3つはすべて、発見されないことを意図した秘密オペレーションの一部として、西側諜報機関によって開発された可能性が高い。同マルウェアが検出を回避したという事実が、攻撃者がいかに良い仕事をしたかを証明している。StuxnetとDuQuの場合、これらのマルウェアを信頼できるアプリケーションに見せかけるため、彼らはデジタル的に署名されたコンポーネントを使用した。そしてコードをカスタムパッカや難読化エンジンで保護しようとする代わりに(そうすることで、疑いを向けられる可能性がある)、ありふれた外観の中にひそませた。Flameの場合、攻撃者はSQLite、SSH、SSLおよびLUAライブラリを使用して、コードがマルウェアの一部というよりは、ビジネスデータベースシステムのように見せかけた。

  我々がこれらコードの一部を発見できなかったのは幸いだと言う人もいるかもしれない。大部分の感染はイラン、シリア、スーダンといった、政治的に混乱した地域で発生している。Flameが何のために使用されたか、正確なところは分かっていないが、我々がもっと早く検出し、ブロックしていたら、外国の諜報機関が監視しようとする努力を、これらの国々の圧政が妨害するのを間接的に援助することになっていたかもしれないからだ。

  しかし、それはポイントではない。その出所や目的とは関係無く、我々はマルウェアを検出したいと考えている。政治は関係無いし、そうあるべきでもない。あらゆるマルウェア(標的型のものも)手に負えなくなることがあるし、意図された被害者ではないマシンに「副次的被害」を引き起こす可能性がある。たとえばStuxnetは、USBワーム機能を介して世界中に広まり、イランのNatanzウラン濃縮施設を管理しているコンピュータという、真の標的を探しながら、10万台以上のマシンを感染させた。つまり、マルウェアに対してコンピュータを守ることは、業界としての仕事である、ということなのだ。

  実際のところ、消費者向けレベルのアンチウイルス製品は、莫大な予算を与えられた、十分な資金力のある国家が作成した標的型マルウェアに対して、十分な保護を与えることはできない。こうした製品は、バンキング型トロイの木馬、キーストロークロガー、電子メールワームなど、普通のマルウェアからユーザを保護するものだからだ。しかし今回の様な標的型攻撃は、故意にアンチウイルス製品を回避するために、どんなことでもする。そしてこれらの攻撃で使用されるゼロデイエクスプロイトは当然、アンチウイルス企業には未知のものだ。我々の知る限りでは、被害者を攻撃するこれらの悪意あるコードをリリースする前に、攻撃者はマルウェアが検出されないことを確実にするべく、市場に流通している関連アンチウイルス製品をすべてのテストを行った。彼らには、攻撃を改良する時間が無制限にあるのだ。攻撃者がこちら側の兵器を入手できる場合、攻撃者と防御者の間の戦いは公平とは言えない。

  アンチウイルスシステムは、誤警報を出すことなく、あらゆる攻撃の可能性を検出できるよう、バランスをとる必要がある。そして我々は常に改善を試みているが、100パーセント完璧なソリューションは存在し得ないだろう。深刻な標的型攻撃に対する、入手可能な最高の保護には、ネットワーク侵入検出システム、信頼のおけるアプリのホワイトリスト、組織のネットワークに対する上下トラフィックのアクティブなモニタリングなどによる、重構造の防御が必要とされる。

  この話はFlameで終わりではない。我々がまだ検出していない、似たような他の攻撃が、既に進行中である可能性は非常に高い。つまり、このような攻撃は上手くいくのだ。

  Flameはアンチウイルス業界にとって失敗だった。我々はほんとうに、もっと上手く対処できるべきだったのだが、そうはできなかった。我々自身のゲームでありながら、上手く守備することができなかったのだ。

ミッコ・ヒッポネン

  このコラムは当初、Wired.comに掲載された。

追記:

  ミッコのコラムには、我々が共有したいと考える、いくつかのフィードバックがあった。

反論:一部は正しい;失敗したという部分は by @attritionorg
反論の修正 by @imaguid

「Diginotar」がBlack.Spookとイランのハッカーによりハッキング

  「Diginotar」はオランダの認証局で、SSL証明書を販売している。

Diginotar

  2011年7月10日、何者かが何らかの形で、彼らから不正なSSL証明書を獲得することに成功した。この証明書は、ドメイン名「.google.com」用に交付されたものだ。

  このような証明書で何をすることができるのだろうか? まず、Googleになりすますことができる。最初にgoogle.comに対するインターネットトラフィックを、自分に対してリルートできるならばだが。これは政府や不正なISPによって行える事だ。このようなリルートは、その国もしくはそのISPのもとにいるユーザしか影響を及ぼさない。

  しかし、何故Googleをインターセプトしたいと考えるのだろうか? これは実際には「www.google.com」のサーチエンジンに関することではない。「mail.google.com」のGmailサーバおよび「docs.google.com」のGoogle Docs、そしておそらく「plus.google.com」のGoogle+が問題だ。

  5月にも(イタリアの証明書リセラー「instantssl.it」を介した)同様の攻撃が見られた。そのケースはイランと関係していた。今回も同様だ。イラン政府が反体制派をモニタするのにこのテクニックを使用している可能性がある。

  イランには自身の認証局は無い。もしあれば、不正な証明書自体を交付すれば良いだけだ。しかし、彼らは認証局を持っていないため、広く信頼されたCAからの、こうした証明書が必要となる。「Diginotar」のような。

  「Diginotar」はどのように侵入されたのだろうか? 我々にはまだ分からない。

  しかし、我々が発見したことはいくつかある。

  以下は現在のhttps://www.diginotar.nl/Portals/0/Extrance.txtのスクリーンショットだ:

Diginotar

  「Diginotar」のポータルはハッキングされている。イランのハッカーを自称する何者かが侵入したのだ。

  これは決定的な証拠のように見えるだろう。明らかにこれは、不正な証明書にどのようにしてか接続していなければならない。

  しかし、きちんと見るなら、このページがhttps://www.diginotar.nl/Portals/0/owned.txtからのものであることが分かるだろう:

Diginotar

  イランの別のハッカーグループ?

  もっと深く掘り下げるなら、これらのWeb改ざんは現在もまだ残っているが、新しくはないことが分かるだろう。もっと悪いことには、それらは数年前になされたものだ。

  以下は、https://www.diginotar.nl/Portals/0/fat.txtで、2009年5月にトルコのハッカーにより行われた別の例だ:

Diginotar

  実際、これらのハッキングは非常に古いもので、現在の問題に関係している可能性は低い。あるいは少なくとも、そうであって欲しいと思う。

 

P.S. この出来事のニュースは、最初、S. Hamid Kashfi(@hkashfi)がTwitterで公表した。彼は2010年には、イランのマン・イン・ザ・ミドル攻撃についてブログに記事を書いている。ここに2010年5月の(Google Translateを介した)ブログ記事がある。

hkashfi

P.P.S. 我々の以前の記事にも、SSL関連の問題に関する詳細がある。

P.P.P.S. 改ざんに関する「Diginotar」の公式声明が出されたが、回答よりも多くの疑問を残した。「Diginotar」は確かに、2011年7月19日にハッキングされた。攻撃者は不正な証明書をいくつか生成することができた。おそらくEVSSL証明書も含まれている。しかし「Diginotar」は、他の不正な証明書を無効にしたが、Googleに発行されたものを見逃した。「Diginotar」は、Googleが突然彼らのSSL証明書を更新しようとし、よりにもよって、オランダの小規模なCAで行おうと考えたことを、少し奇妙だとは思わなかったのだろうか? そして「Diginotar」が改ざんの後、自分達のシステムを検査していた時に、上記のイランの改ざんをどうして見逃したのだろうか?

追記:9月5日の時点で、攻撃者が証明書を作成することができた既知のドメインリストは以下の通り:

*.*.com
*.*.org
*.10million.org
*.android.com
*.aol.com
*.azadegi.com
*.balatarin.com
*.comodo.com
*.digicert.com
*.globalsign.com
*.google.com
*.JanamFadayeRahbar.com
*.logmein.com
*.microsoft.com
*.mossad.gov.il
*.mozilla.org
*.RamzShekaneBozorg.com
*.SahebeDonyayeDigital.com
*.skype.com
*.startssl.com
*.thawte.com
*.torproject.org
*.walla.co.il
*.windowsupdate.com
*.wordpress.com
addons.mozilla.org
azadegi.com
friends.walla.co.il
login.live.com
login.yahoo.com
my.screenname.aol.com
secure.logmein.com
twitter.com
wordpress.com
www.10million.org
www.balatarin.com
www.cia.gov
www.cybertrust.com
www.Equifax.com
www.facebook.com
www.globalsign.com
www.google.com
www.hamdami.com
www.mossad.gov.il
www.sis.gov.uk
www.update.microsoft.com

  さらに、攻撃者は以下の名称に関し、不正な証明書を作成した:

Comodo Root CA
CyberTrust Root CA
DigiCert Root CA
DigiCert Root CA
Equifax Root CA
Equifax Root CA
GlobalSign Root CA
Thawte Root CA
VeriSign Root CA

Black Hat USA 2011

  今週、「Black Hat」および「DEF CON」が開催され、コンピュータセキュリティの専門家が、何千人もラスベガスに集まっている。

Black Hat 2011 DEF CON 2011

  Siemens PLCセキュリティ、SSLモデルの見直し、Macラップトップのバッテリーなどが今年のホットトピックだ。

Black Hat 2011 DEF CON 2011

Black Hat 2011 DEF CON 2011

Black Hat 2011 DEF CON 2011
「DEF CON 19」で基調講演を行うミッコ

  非常に期待されていたトークに、Riley HassellとShane Macauleyの「Androidのハッキング」がある。不可解な理由により、二人のスピーカーとも、自身のトークに姿を見せず、何故そんなことが起きたかに関し、突飛な陰謀説も現れた。

  しかし、アンチウイルスの観点から言えば、最も興味深かったのはTavis Ormandyによる「Sophail」というタイトルのトークだった。

  2010年の夏、Tavis OrmandyはWindowsのHelp and Support Centerで、ゼロデイ脆弱性を発見した。Microsoftに同脆弱性を知らせた5日後、Microsoftがパッチをリリースする以前に、TavisはPOCコードを公開した。数日後、未知のマルウェア作者たちが、このコードをドライブバイダウンロードエクスプロイトに組み込み、同エクスプロイトは世界中の何万ものコンピュータを感染させ続けた。

  Sophosの専門家は、Tavisの行為を声高に批判し、最終的に登場したパッチに「Patch Tavis」というあだ名を付けさえした。

  2011年夏の現在、Tavis OrmandyはBlack Hatで、「Sophosアンチウイルスの批判的分析」をリリースした。

Black Hat 2011 DEF CON 2011

  その非常に風変わりなトークで、TavisはSophosアンチウイルスエンジンをリバースエンジニアリングし、Sophosの検出データベースの保護システムを解読するためのツールをリリースしたと説明した。

  それはともかく、DEF CONの間、ワイヤレスネットワークへの接続は、実際のところ推奨されないことに注意したい。同ネットワークをいじっているハッカーがあまりにも多い。公式なプログラムパンフレットでさえ、パーティネットワークにアクセスする際、利用者の「幸運」を祈っている。DEF CONホテルで利用できるWi-Fiホットスポットのリストを見れば、よく分かるだろう:

def con wifi

サインオフ
—BO

Black Hat 2011 DEF CON 2011

Googleサーバでホスティングされるフィッシングサイト

  Google Docsでは、ユーザはgoogle.com(Googleのクラウドでホスティングされている)でドキュメントやスプレッドシートなどを作成することができる:

spreadsheets.google.com

  スプレッドシートは、フォームなどの機能をも含むことができ、これらは世界に向けて公開することが可能だ。

  残念なことに、このことはGoogle Docsスプレッドシートを介して、spreadsheets.google.comでホスティングされているフィッシングサイトに、頻繁に遭遇するということを意味している。

  以下はその例だ:

spreadsheets.google.com

spreadsheets.google.com

spreadsheets.google.com

  フィッシングページは本物のgoogle.comでホスティングされており、有効なSSL証明書を備えているため、これらは扱いにくい攻撃と言える。

spreadsheets.google.com

  リサーチを行っている時、我々は以下のGoogleスプレッドシートフォームに遭遇した:

spreadsheets.google.com

  そして、これがフィッシングなのか、それともGoogleが管理している有効なページなのかどうか、どうしても見抜くことはできなかった。

  最初、このページは明らかにフィッシングのように見える。誰もがフォームを作成できる、パブリックなspreadsheets.google.comでホスティングされているし、このページはGoogle Voiceナンバーやメールアドレス、PINコードを要求するからだ。

  しかし、明らかにGoogleの職員が同フォームにリンクしているのにも気づくだろう。

  そのため、フィッシングなのかそうでないのか分からないのだ。あなたには分かるだろうか?

  以下がそのフォームのURLだ:
https://spreadsheets.google.com/viewform?formkey=cjlWRDFTWERkZEIxUzVjSmNsN0ExU1E6MA

  このフォームを使用することは推奨しない。しかし、もし同フォームの正体が分かったら、コメント欄から我々に報せて欲しい。

追記:Twitterでは、これはフィッシングサイトだというのが大方の意見のようだ。しかしまだ結論は出ていない。

spreadssheets


Google Webサーチを使用して改ざんされたGoogle画像を見つける

  Googleサーチに問題がある。

  数週間にわたり、Google Imageサーチの結果がますます、Search Engine Optimization(SEO)ポイズニングにより汚染されている。Google Imageの結果を介して、スケアウェアTrojanやエクスプロイトにリンクした多くのサイトが、毎日発見される。これらのサイトの多くは、さもなければ安全と思われるであろうものだが、何らかのハッキングにより障害が起きている。

  問題の一端は、Googleが画像をクローリングし、ランキングする方法にある。

  以下はGoogle Imageの結果からの、汚染されたリンクの例だ:

Google Image Search, imgurl, imgrefurl

  「imgurl」と「imgrefurl」がマッチしていないことが分かるだろうか。この画像は「ホットリンク」されている。そして同画像は、実際には「enterupdate.com」のサーバでホスティングされているのだが、Googleはこれが参照している(改ざんされた)サイトからのものであるかのように、同画像のプレビューとサイト情報を表示する。

  しかし、この画像の「ホーム」として参照サイトを表示する正当な理由はある。たとえば、エフセキュアの「Safe and Savvy」ブログはVIP WordPress.comにより供給されており、画像はWordPressのサーバ上でホスティングされている。もしもGoogleが画像の参照サイトを考慮せず、ホットリンクを無視するなら(Bingはそうであるようだが)、この検索結果はあまり役には立たないだろう。

  WordPress.orgでは、上記の例で女優オリヴィア・ワイルドの汚染された画像は、「wp-images」というフォルダ内のHTMLページに埋め込まれている。障害が起きたこのサイトは、WordPress.orgブログだ。

http://www.#####################.co.uk/wp-images/olivia-wilde-twitter.html

  以下は「olivia-wilde-twitter.html」ページのものだ:

oliva-wilde-twitter

  ご覧の通り、テキストは完全にデタラメだ。同ページのハイパーリンクはすべて、同じサイトにある他のページに結びついており、画像はすべてホットリンクされ、外部のソースからロードされる。

  このHTMLは多かれ少なかれ、Google Trendsから直接引き出されたトピックにフォーカスしたセクションを含んでいる。

  こうした調査から、Google Webサーチを障害が起きたサイトを特定するのに利用可能であることが分かった。「inurl:wp-images」および現在の「トレンディングトピック」を検索すると、SEO攻撃を試みる多くの結果を得る事ができるのだ。

  言うまでもなく、リサーチネットワークから行うのでなければ、こうした検索を推奨するわけではない。(そして、改ざんされたSEOサイトは「http://www.google.com」から訪問された場合のみ攻撃を行うため、「Google SSL」を使用するべきでもある。)

問題のある証明書

  最近の事件で、証明書、そしてコードサイニングおよびSSL証明書におけるアカウンタビリティの欠如が注目され、大きな問題となっている。

  SSL証明書を持つことは、Webサイトのオーナーが、サイトのビジターに、自分が本当にオーナーであることを証明する一つの方法だ。大部分のインターネットユーザ、そして主要なインターネット会社でさえ、暗黙のうちに認証機関(CA)を信頼している。CAはSSL証明書をWebトラフィックの暗号化のために販売する。これにより、オンラインバンキングやショッピングなど、httpsコネクションを介してセキュアなトランザクションが可能になる。

  しかし、現行の認証システムは1990年代に始まったもので、今日のインターネットの圧倒的な規模や複雑さにうまく対応していない。VerisignやGoDaddy、Comodoといった主要な認証企業に加え、基本的により大規模な企業のための再販業者である地域的なCAさえ何百も、何千も存在する。

  Comodoは先頃、ハッカーがイタリアの再販業者の一社のパスワードとユーザ名を獲得することで、システムに侵入することができたと発表した。そのハッカーはその後、イランの出身であると公に主張しているが、その会社を通じて9つの不正な証明書を交付した。証明書はgoogle.com、yahoo.com、skype.comといったポピュラーなドメイン用に発行された。

  第一に、イタリアの小さな再販業者が、google.comの証明書を交付することができる、というのは驚くべきことだ。あなたは、どこかでサニティーチェックが妨害されたのだろうと考えるかもしれないが、そうではない。

  このような証明書によって何ができるだろうか? あなたが政府で、自国内のインターネットルーティングをコントロールできるなら、すべてのルート変更が行える。たとえば、Skypeユーザを偽のhttps://login.skype.com アドレスに導き、SSL暗号化が存在するように見えるかどうかに関わらず、彼らのユーザ名やパスワードを収集することができる。あるいは、彼らがYahooやGmail、Hotmailにアクセスすれば、その電子メールを読むことができる。プロであってもほとんどが、これに気づくことはないだろう。

  2010年8月、コードサイニング証明書によって署名されたマルウェアサンプルを発見したため、エフセキュアのシニアリサーチャであるJarno Niemelaが、Comodoを巻き込んだID窃盗のケースについて調査を開始した。彼は証明書に記載された企業を追跡し、小規模なコンサルティング会社を見つけた。

  Niemelaはその会社に連絡し、彼らが自分達のコードサイニング証明書が盗まれたことに気づいているかどうか訊ねた。彼らの反応は、コードサイニング証明書は持っていない、というものだった。実際、彼らはソフトウェアの制作さえしておらず、したがってサインすべきものが何もなかった。明らかに誰かが、彼らの名前でその証明書を獲得したわけだ。彼らは企業ID窃盗の被害者だったのだ。

  被害者とComodoの協力を得て、Niemelaはこの証明書が実在する従業員の名前でリクエストされ、Comodoは申込者の身元をチェックするため、電子メールと電話による確認を行ったことを確認した。残念なことに、この詐欺師はその従業員の電子メールにアクセスすることができ、Comodoの電話による確認は、間違った相手にかかってしまったか、誤解が原因で失敗してしまった。

  実際、件の従業員は別のCA会社であるThawteからも電話を受けている。Thawteが彼女に、会社の名義でコードサイニング証明書をリクエストしたかどうか訊ねた際、彼女は「ノー」と返事をした。そこでThawteは、認証プロセスを打ち切った。

  このケースは、入口を見つけるまで、マルウェアの作者が複数のCAを試すということを示している。

  詐欺師が企業のメールにアクセスできる場合、その企業からのリクエストが本物かどうか、CAが確認するのは非常に難しい。評判が良く、やましいところの無い企業が、有効な証明書を手に入れるためのプロキシとしてマルウェア作者に利用されるというケースは、今後増えそうだ。

  認証機関は既に、認証を獲得しようとする疑わしい試みや、その他のシステムの悪用に関する情報を報せる手段を有している。しかし、これらのシステムは人間によって運営されているため、間違いも起こりやすい。我々は、現行のシステムでは、証明書は完全に信頼できるものではないという事実を、受け入れなければならない。

  このトピックについて、最新のYouTubeビデオで取り上げている。

企業マルウェア開発

  Washington Timesが、政府使用のためのバックドアおよびトロイの木馬を開発する企業に関する、長文の記事を掲載している。

  この記事は、Gamma Technologies、Elaman GmbHおよびエジプト政府間の関係についてのニュースを我々が伝えた後に開始された。

Elaman / Gamma Technologies
Photo by F-Secure GmbH

  バックドアやエクスプロイト、トロイの木馬を開発する大企業が存在するとは、不安どころではない。

Elaman / Gamma Technologies
Elaman HQ Photo F-Secure GmbH

  もちろん、それらのほとんどは「合法的なインターセプト」のために設計されている。

  合法的なインターセプトは、絶えず存在した。もともとはオペレータによる通話の選別を意味し、そのうち、携帯電話の通話やテキストメッセージに拡大。そして次に、電子メールとWebサーフィン情報の選別に拡大した。しかし、疑わしい人物がSSLを使用したサイト(たとえばGmail)にアクセスするなら、オペレータはそれを選別することはできない。そのため、標的のコンピュータを感染させるマルウェアやバックドアを使用する必要が生じた。一度感染させれば、そのマシン上で行われるすべてをモニタすることができる。

Finfisher offer

  理論的には、合法的なインターセプトには何ら問題は無い。それが警察によって行われるなら。民主主義国家で行われるなら。裁判所命令があるなら。そして容疑者が実際に有罪である場合なら。

  Eli Lakeの記事で挙げられている企業には、HBGary FederalとEndgame Systemsも含まれている。

Facebook HTTPSに進捗

  2月23日の記事で、FacebookのSSL「Secure Browsing」プリファランスには、保存に関する問題が若干あると指摘した。



  それ以降、いくつか有望な進捗があり、現在、非HTTPSアプリケーションにアクセスすると、以下の様になる:

Facebook, Secure Browsing (HTTPS)

  よって少なくとも、セッティングは保存される。うまく行けば近い将来、この機能はよりダイナミックになるだろう。

  あなたがFacebookのアカウントをお持ちで、HTTPSの設定をアップデートしたいなら、同オプションは「Account Security」にある。

追記 (不正なSSL証明書 「Comodoケース」)

2011年3月24日にポストされたミッコ・ヒッポネンの記事「不正なSSL証明書 (「Comodoケース」)」の末尾に、「Comodoハッカー」だと主張する人物(あるいは人物/組織)が、発表した公式の覚え書きについて追記が記載されましたのでお知らせいたします。

追記 (不正なSSL証明書 「Comodoケース」)

2011年3月24日にポストされたミッコ・ヒッポネンの記事「不正なSSL証明書 (「Comodoケース」)」の末尾に追記が記載されましたのでお知らせいたします。

不正なSSL証明書(「Comodoケース」)

  SSL証明書は、Webサイトがエンドユーザに自身のアイデンティティを明らかにするために用いられる。

comodogate  証明書ベンダー「Comodo」が今日、同社を通じて9つの不正な証明書が発行されたと発表した。これらの証明書が交付されたのは以下に対してだ:
  • mail.google.com (GMail)
  • login.live.com (Hotmail et al)
  • www.google.com
  • login.yahoo.com (three certificates)
  • login.skype.com
  • addons.mozilla.org (Firefox extensions)
  • "Global Trustee"


  Comodoによれば、これらの登録はイランのテヘランからのもののようで、彼らは攻撃のフォーカスとスピードからみて、「state-driven」であると考えている。

  このような証明書で何ができるだろうか?

  そう、もしあなたが政府で、自国内のインターネットルーティングをコントロールできるなら、すべてルート変更し、たとえばSSL暗号化が整っているかどうかに関わらず、Skypeユーザを偽の「https://login.skype.com」に導いてユーザ名とパスワードを収集することができる。あるいはSkypeユーザがYahoo、GmailあるいはHotmailにアクセスした際、彼らの電子メールを読む事が可能だ。相当のギークであっても、このようなことが起きているとは気づかないことだろう。

  「addons.mozilla.org」の不正な証明書はどうだろう? 当初、私はFirefoxエクステンションをある種のマルウェアインストールベクタとして使用する以外の理由は無いと考えていた。しかし、SymantecのEric Chienが、興味深い理論を述べている。すなわち、それは検閲フィルタをバイパスする特定のエクステンションをインストールするのを妨害するのに利用できる、というのだ。(ありがとう、Eric!) そのようなエクステンションの例として、ここここを見て欲しい。

  証明書失効システムは絶対確実とは言えないため、Microsoftはこれらの不正な証明書を信頼できないローカルな証明ストアに移動させるWindowsアップデートをリリースすると発表した

追記:現在Comodoは、ヨーロッパの関連会社のパスワードおよびユーザ名を獲得して、システムに侵入したと発表している。ひとたび内部に侵入すれば、攻撃者はどんなサイトの証明書でも発行することが可能だ。この件に関し、Wall Street Journalが詳細を掲載している。

追記:「Global Trustee」用に交付された証明書の重要性とは何か? 我々には分からない。文書化された形では、どこにも発見できなかったものだ。現時点の最も有力な推測としては、一部の大規模ベンダが「Global Trustee」用の証明書のハードコードされたサポートを持っており、それらのベンダのハードウェア製品が存在するのでは、ということだ…

追記:イランは自身のCAを有していない。もし有しているなら、不正な証明書自体を発行することが可能なのだから、このようなことを何らする必要がないはずだ。Twitterで、@xirfanがこの件に関して、以下のようにコメントしている:「私はwebhosterで働いている。イランとシリアのカスタマは、SSLを許可されていない。」

  MozillaプロジェクトRoot CAストアに保存されているルート証明書のリストはここにある。中国、イスラエル、バミューダ、南アフリカ、エストニア、ルーマニア、スロバキア、スペイン、ノルウェー、コロンビア、フランス、台湾、英国、オランダ、トルコ、アメリカ合衆国、香港、日本、ハンガリー、ドイツおよびスイスのCAにより発行された証明書が含まれている。

追記:「Comodoハッカー」だと主張する人物、あるいは人物たちが、この件に関する公式な覚え書きを発表した。同記事の背後にいる人物(たち)は、Comodoの、あるいは「instantssl.it」の内部システムにアクセスしたようだ。彼らの話の他の部分が真実であるかどうか、我々には分からない。






Facebook HTTPS:実現は完璧よりも優れているのか?

  私のFacebookアカウントが先週ついに、「可能な場合は常に」HTTPS接続を使用するオプションの提供を開始した。

  同オプションは「Account Settings」ページの「Account Security」セクションにある:

Facebook Account Security

  そこで私はこのオプションを選択して、変更を保存した:

Facebook Account Security

  それで、FacebookはセキュアなHTTPS接続をデフォルトに設定している:

https://www.facebook.com/?sk=nk

  あるいは、私はそう考えていた…(詳細は以下)

  今日、私は「http://omg」についてFacebookサーチを行い、スパムに遭遇した。

  典型的なFacebookスパムのエサ「see who stalks your profile(誰があなたのプロフィールをストーキングしているか見る)」だ:

OMG, see who stalks your profile...it's Working

  このリンクをクリックすると、以下の表示が開いた:

Switch to regular connection (http)?

  オーケー… このアプリケーションはHTTP接続でのみ見られるのだろう。

  そこで私は「Continue」ボタンをクリックした。

  そして以下が、同アプリケーションが許諾を求める「Request for Permission」だ:

Request for Permission

  うーん、「Who Spends Watching Your Profile?」の開発者は誰だって?

Who Spends Watching Your Profile?

  Justn Bieber? Justn?

  なるほど。さて、我々は現在、このスパマーの標的となるグループが分かっている。

  「Justn Bieber」は、ジャスティン・ビーバー・ファンページについてのコメントに時間を費やしているようだ:

Justn Bieber

  私はこのスパムアプリケーションをFacebookに報告し、立ち去った…

  その少し後で、私は自分のアカウントがもはやセキュアでないことに気づいた:

http://www.facebook.com/?sk=nf

  待てよ、何だって?

  設定をチェックしたところ:

Facebook Account Security

  セキュリティ設定が取り消されている? だが、このオプションは「可能な場合は常に」のはずであり、「標準接続」に切り替える、以前のプロンプトは、単に一時的なものだったのでは?

  いや。

  数回テストしてみたが、毎回、アプリケーションが「標準接続」を「続ける」よう求め、デフォルトの「Account Security」設定がHTTPに戻っていた。

  これに最初に気づいたのは私ではない。Facebookはこの問題を認識しており、SSLプリファランスを持続させるよう作業を行っている

  Facebookはこのような事を故意に行っているのでは、と言うであろう皮肉な人たちもいるはずだ。個人的に、私はそうは思わない。単なる見落としだろう。

  何故って?

  Facebook HQからの以下の写真を見てほしい:

Move fast and break things — Done is better than perfect

  何が見えるだろうか?(ケイティ・ペリーではなく。もう一度見てほしい。)

  ドアの上だ。「move fast and break things(迅速な行動が物事を動かす)」「done is better than perfect(完璧を目指すより実現すべし)」という言葉が見えるだろうか?

  それで分かった。なるほど。Facebookは革新に向け突き動かされているのだ。

  (Googleが王座を奪おうとしている状況の中)彼らは成長し、ソーシャルネットワーキングの先頭にとどまる必要がある。

  しかし、「Account Security」設定に関して言えば、完璧を目指すよりも実現することの方が、本当にベターなのだろうか?

  完璧である必要は無いが、個人的には、中途半端よりは完成したものの方が良いと思う。

  中途半端は、長い目で見れば混乱を引き起こすだけだ。

  それでは、我々が中途半端な結果を得る理由は何だろう? 率直に言って、(ある程度)Twitterのせいだと私は思う。

  まじめな話だ。

  Blogosphere(ブログ圏)は現在Twittersphereであり、昨年10月、Firesheepがニュースになったとき、Twittersphereはツイートを開始した。ではFacebookは? 彼らは人々に、彼らが要求していたもの、すなわちHTTPSオプションを提供した。

  このオプションがいつ中途半端でなくなるかは、実際、問題ではないのかもしれない。Twittersphereはいずれにせよ、次の旬なトピックについてツイートするのに忙しく、気づかないだろうから。

では、
ショーン

「Firesheep」:複雑だったことを容易にするツール

  暗号化されていないHTTP接続でWebをサーフィンすることは安全ではない。特にあなたが、暗号化されていないWi-Fi接続を介してサーフィンしている場合は。同じホットスポットを使用している他の誰でも、あなたのトラフィックをモニタするための特別なツールを使用することができるからだ。

  暗号化されたHTTPS接続によりWebをサーフィンする方がはるかに良い。強力な暗号化(WPA2)を使用したホットスポットの利用も安全だ。しかし、これらのオプションは通常、エンドユーザが決められることではない。大部分のオープンなホットスポットは、まったく暗号化していないし、多くのポピュラーなサイトは、たとえあったとしても、ログイン手続きにHTTPSを使用するのみだ。

  そしてたとえログインセッションが暗号化されるにしても、多くの人気サイト(Facebook、Twitter、Amazonなど)は、以降のすべてのリクエストのために使用されるクッキーをブラウザに与える。もし誰かがこのクッキーを盗むことができれば、同サービスでのあなたのセッションを盗むことができるのだ。

  人々は、クッキーを盗むことによってセッションをキャプチャすることは、特別なツールを持つ熟練ハッカーによってのみ可能であるという印象を持ってきた。
Firesheep
  この状況は現在変化している。

  「Hey Web 2.0: Start protecting user privacy instead of pretending to(ユーザのプライバシーを守るふりではなく、本当に保護することを始める)」という名のペーパーが、 Ian GallagherとEric Butlerにより、先週「Toorcon」で発表された。彼らのスライドはここにある。

  彼らは「Firesheep」というツールもリリースした。

  「Firesheep」は、この問題を示すために設計されたFirefoxブラウザのエクステンションだ。

  「Firesheep」はローカルWi-Fiネットワークをスキャンする。同ツールはFacebook、Twitter、Google、Amazon、Dropbox、Evernote、Wordpress、Flickr、bit.lyといったサービスにログインしているユーザをつきとめる。そしてこれらのユーザのアイコンを表示し、これによりあなたは彼らになることができるのだ。あなたは彼らのオープンセッションを続けたり、何かを投稿したり、削除したりすることができる。あなたは、これらのユーザにできることは、何でも実行することができる。

  これはかなり深刻な問題だ。実行するのが難しかった何かが、突然、取るに足りないほど簡単に実行できるようになるのだ。

  Windowsでの「Firesheep」の使用には、まだ若干のスキルが必要であることに注意して欲しい。すなわち、WinPcapパケットキャプチャソフトウェアをインストールする必要があるからだ。

  「Firesheep」は不正使用されるだろうか? 間違いなく。

  上記のサイトのいくつかに、完全なSSLをもたらすだろうか? 我々はそう願う。Gmailは今年初め、これを実行している。

  現状でユーザは何をすることができるだろうか? 可能ならば、SSLを押し進めること。暗号化なしでWi-Fiを使用してはいけない。あるいはVPNを使用すること。

  ほとんどの企業ラップトップは、企業VPNがインストールされている。しかしユーザの多くは、自分たちがそれを必要とする時にオンにするだけだ。これは間違った考え方だ。もしVPNがあるならば、ホットスポットでは常にオンにしておくべきだ。あなたが「働いている」のではなくて、単にFacebookをサーフィンしているだけだとしても。

  明らかに、ホームユーザは自分達のラップトップに企業VPNはインストールされていない。それでは、どのVPNサービスを使用するべきだろうか? 我々は同市場を調査していないので、実際、分からない。皆さんのご意見に興味を持っている。コメント欄からフィードバック頂ければ幸いだ。

追記:「TechCrunch」がFirefoxエクステンション「Force-TLS」に関する記事を掲載している:「Firesheep」からあなたのログイン情報を守る方法

コードサイニング証明書獲得に用いられる企業ID窃盗

  先週、ラボは大量に出回った奇妙なマルウェア群を特定した。有効なAuthenticodeコードサイニング証明書でサインされたファイルだ。

Company X's stolen certificate

  このようなものを、我々は以前目にしたことがある。しかし今回のケースは、連絡先が非常に本物らしい点が奇妙だった。通常、有効だが悪意ある証明書では、詳細は明らかに虚偽であるか疑わしいものだ。

  私は、この証明書にある名称とアドレスに該当する企業を探し、産業用プロセス制御とオプティマイゼーション関連のサービスを提供する、小規模なコンサルティング会社を見つけた。

  この会社に連絡をとり、彼らのコードサイニング証明書が盗まれたことに気づいているかどうかを尋ねた。そして彼らがコードサイニング証明書を有していないと回答したため、事態は私にとってより興味深いものとなった。実際、彼らはソフトウェアを作成しておらず、それゆえサインすべきものなど何も無いのだ。明らかに、誰かが彼らの名前で証明書を獲得したわけだ。彼らはID窃盗の被害者ということになる。

  私は、被害者と不正な証明書にサインした認証局であるComodoの助けを借りて、このケースを調査した。そして同証明書が、実在の従業員の名前で申請され、Comodoは電子メールだけでなく、電話による確認も行ったことが分かった。この詐欺師は、その従業員の電子メールにアクセスすることができ、電話による確認は、違う人のところにかかったか、何らかの誤解があったようだ。そのため、電話によるチェックは、このケースを食い止めることができなかった。

  Comodoは不正な証明書の取り消しを行い、同証明書でサインされたすべてのファイルは、自動的にブロックされる。

  また、今回の調査で、私は被害を受けた従業員が、他のCA会社Thawteからの電話を受けとったことを知った。Thawteは彼女に、会社の名称でコードサイニング証明書を申請したかを尋ね、彼女はそれに対し「いいえ」と回答した。そしてThawteは、証明書受け付けのプロセスを打ち切った。どうやらこのマルウェアの作者は、アプリケーションプロセスを操作するため、すべてが上手く行くまで、複数のCAを試したようだ。

  このケースは、コードサイニングの信頼性に対して深刻な懸念を与えるものだ。

  詐欺師たちが企業の電子メールにアクセスできる場合、その企業からの申請が本物かどうかをCAが確認することは非常に難しい。将来的に、間違いが起きることもあるだろう。評判の良い無実の企業が、マルウェア作者のプロキシとして、有効な証明書を入手するために利用されるという、今回のようなケースを目撃することが増える可能性は高い。

  認証局は既に、疑わしい証明取得の試みや、その他のシステム悪用に関する情報をパスする手段を有している。しかし、これらのシステムは人間によって維持されており、それゆえ間違いも起こりうる。我々は、現行のシステムでは、証明書はファイルの素性に対する100パーセントの保障とはならないという事実を受け入れるべきだ。

  いくつかの認証局で提供されているシングルエントリの現状は、セキュリティの観点から見て良いことではない。認証局は、単一のドメイン名、たとえば「f-secure.com」が、一度に1つのレジストラのみがホスティング可能なドメイン名と同様、類似したプロセスを持つべきだ。

  また、コードサイニングあるいはSSL証明書は、一度に1つのCAのみにより署名することができるようにすべきだろう。

  そうすれば、何者かがエフセキュアの名前で証明書を得たいと考えた場合、その人物はエフセキュアが現在証明書を得ている、エフセキュアと取引関係のあるCAからのみ、獲得することができ、その結果、すべての証明書の新規リクエストは、既存の連絡窓口で確認されることになる。こうしたことを可能にするには、CAは情報リソースを集約する場所が必要となるだろう。

  すべてのCAが、どのような名称でも証明書を交付できるという現行モデルは、スキャムやソーシャルエンジニアリングの可能性があまりにも高いことを考えれば、セキュアではあり得ない。

  コードサイニングの悪用について、さらに知りたいとお考えの方のため、この10月、私は「T2 Information security conference」でプレゼンテーションを行う予定だ。

T2'10

サインオフ
ジャルノ

バックナンバー
セキュリティ関連リンク
セキュリティ機関

政府関連

セキュリティ関連団体

研究機関・大学
詳細カテゴリ
メディア関係者の皆様へ
エフセキュアブログメンバー
エフセキュアブログメンバー
ミッコ・ヒッポネン
エフセキュア CRO(セキュリティ研究所主席研究員)(ヘルシンキ)
(Twitterアカウント)
(研究所Twitter)
ショーン・サリバン
エフセキュア セキュリティ・アドバイザー(ヘルシンキ)
(Twitterアカウント)
高間 剛典
メタ・アソシエイツ代表
(公式ブログ)
(Twitterアカウント)
星澤 裕二
株式会社セキュアブレイン 最高技術責任者
(公式ブログ)
(人物紹介)
岩井 博樹
デロイト トーマツ リスクサービス株式会社 (〜2013年3月 株式会社ラック) 情報セキュリティ大学院大学 客員研究員
(Twitterアカウント)

(人物紹介)
福森 大喜
株式会社サイバーディフェンス研究所 上級分析官
CDI-CIRTメンバー
(人物紹介)
鵜飼 裕司
株式会社FFRI 代表取締役社長
(人物紹介)
福本 佳成
楽天株式会社
執行役員
OWASP Japan
アドバイザリーボード
Rakuten-CERT representative
(人物紹介)
神田 貴雅
エフセキュア株式会社 プロダクトグループ 部長
富安 洋介
エフセキュア株式会社 プロダクトグループ
コーポレートセールスチーム
エフセキュア株式会社
(エフセキュアブログ公式Twitterアカウント)

海外記事翻訳
株式会社イメージズ・アンド・ワーズ
エフセキュアメールマガジン

ブログに載らないメルマガ限定情報や、技術者インタビュー、製品情報、技術解説を掲載して毎月一回配信します。アドレスのみの登録で購読無料。

エフセキュアブログQRコード
QRコード