「Heartbleed」のジレンマ - 本当にすべてのパスワードを今すぐ変更すべきか?

4月 11, 2014 Sophos Press Release

※この記事は本社サイト 「Naked Security」掲載の記事を翻訳したものです※
by Paul Ducklin on April 10, 2014
この記事に関する最新の更新情報は Naked Security 掲載記事をご確認ください。

OpenSSL の「heartbleed」のバグが大きな問題になっています。

このバグの詳細について、今回は割愛しますが (詳細な解説は こちら をご覧ください)、一般的な流れとしては次のような処理が行われます。

  • 悪意ある人物からサーバーに対して暗号化通信 (TLS) が行われます。


  • 悪意ある人物は、実際のデータの代わりに ハートビート リクエスト を送って、サーバーが接続を維持するように指示します。


  • 悪意ある人物は、送信されるリクエストに数バイトしか含めませんが、65535 バイトを送信したと主張します。

ハートビートは、受信するリクエストデータをレスポンスパケットにコピーして返信することで、接続が正しく機能していることを相手が確認できる仕組みになっています。

しかし、問題のあるバージョンの OpenSSL は、次のように応答します。

  • 返信に 65535 バイトをコピーします。受信リクエストのデータのバイトを最初に含めますが、受信バッファをオーバーフローさせます。


  • 65535 バイトをすべて返信します。最初の要求データの他に、サーバー上の RAM 周辺にあるデータはどんなものでも追加します。

→ この 65535 という値は、16 ビット (2 バイト) で表現可能な最大の数 (16 進数の 0xFFFF) であり、TLS の heartbeat 拡張プロトコルで request length フィールドに割り当てられたサイズです。またしても、おなじみの 64KB の制限に関連する話です。

これはバッファオーバーフローですが、これまで一般的だったものではありません。

通常は、膨大な データを送り、相手をクラッシュさせて、データをコードとして実行させます。一方で、今回は 過度に小さな データを送り、不足分を相手のデータで補わせるという手法が用いられています。

この欠陥のニュースが公開されて以降、研究者達が、世界中の Web サーバーに対して「heartbleed」パケットを送信し、64KB ずつ漏洩するデータがどのようなものになるかを監視してきました。

漏洩するデータの大部分がつまらないものであることは、想像できます。しかし、脆弱なサーバーに対して、興味深い情報を得られるまで、ただ単に「heartbleeding」パケットを送信し続ければいいのです。

実際に研究者達は、ユーザー名、パスワード、サーバー暗号化鍵など、漏洩してはならない多種多様なデータを発見したと主張しています。

したがって、この欠陥によって皆さんのパスワードは 恐らく漏洩していない と考えられますが、漏洩した可能性は存在 しています。これは、あなた が今週宝くじに当選しなかった一方で、他の誰か が当選したのと同じことです。

このことから、万が一に備えてパスワードをすべて変更すべきであると勧める記事が登場しています。

これは、「それが万全である」という理由からです。

たとえば、クレジットカードを使用した店舗のセキュリティに後から不安を感じたなら、不正な取引が行われたことを発見するまで待たずに、カードの解約と新規発行を銀行に依頼しようと考えるでしょう。

There was only one catch and that was Catch-22, which specified that a concern for one's safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn't, but if he were sane he had to fly them. If he flew them he was crazy and didn't have to; but if he didn't want to he was sane and had to. Yossarian was moved very deeply by the absolute simplicity of this clause of Catch-22 and let out a respectful whistle.問題の重大性に比べればオンラインパスワードの変更は些細なことですが、先を見越して対応するという観点で考えると、道理にかなっていると言えます。

しかし、すべてのサービスのすべてのパスワードを慌てて今すぐ変更する必要もない、重要な理由もあります。つまり、現時点では一種のお手上げの状態なのです。

「heartbleed」の問題で危険性のあるサーバーでパスワードを変更する必要がある場合、変更する新しいパスワードも「heartbleed」の問題で危険にさらされる可能性があります。

また、1 週間前、1 か月前、または 1 年前の、現在のパスワードを設定した当時と比べて、今は新しいパスワードを「heartbleed」により取得しようと構えている輩がはるかに大勢いるとも言えます。

ソフォスでは、この件に関するサイトからの発表などにより問題がないことを確認するまで待つか、または、Web サイトに接続して安全性を評価する公開のテストサービス を最初に利用することをお勧めします。

→ ただし、「heartbleed」の問題について Web サイト (または、電子メールサーバーや、TLS や HTTPS 接続を受け入れるアプリケーション) をリモートからテストしても、完全な答えを得ることはできない点に注意してください。たとえば、Microsoft IIS を使用している企業が運営するサーバーについては、問題はありません。しかし、この企業がミラーサーバーの運用を第三者に外注している場合、これらのミラーサーバーが問題の影響を受ける可能性があります。つまり、毎回のアクセスで使用されるサーバーによっては危険な可能性がありますが、常に危険というわけではありません。

やはり、パスワードをすべて変更する準備はぜひともしておきましょう。

ただし、現在のパスワードにより保護されているサービスに「heartbleed」の脆弱性がないと妥当的に判断できるまで、変更するのは控えましょう。

また、できる限り二要素認証 (2FA) を使用することを検討しましょう。

2FA システムは、一般的には 1 回限りのコードのシーケンスを使用することで、盗まれたパスワードがサイバー犯罪に利用される可能性を大幅に低減します。

その仕組みについては、音声による解説をお聴きください。

今すぐ聴く

ダウンロードして聴く

Download Techknow podcast