ようこそ、その後の世界へハートブリード弊社はサーバーにパッチを当て、SSL 証明書を交換しています。しかし、弊社のサーバーが修復されたからといって、インターネットの残りの部分が修復されたわけではありません。弊社には従業員がおり、彼らはインターネットを使用してクレジットカード番号やログオン認証情報などの秘密を交換しています。彼らは弊社にアドバイスを求めています。
私たちはクライアントに、Heartbleedテストページ訪問したいサイトに脆弱性があるかどうかを確認します。サイトが陽性を返した場合は、そのサイトとは秘密を交換しないでください。しかし、サイトがないHeartnet で陽性が返された場合、状況は次のいずれかである可能性があります。
- このサイトには脆弱性がなかった（良い）
- サイトには脆弱性があり、修正されましたが、侵害された可能性のある SSL 証明書がまだ使用されています (悪い)
- サイトには脆弱性があり、それを修正し、SSL 証明書を再生成しましたが、キーは再生成しませんでした (悪い)
- サイトに脆弱性があったため、それを修正し、キーを再生成し、SSL 証明書を交換しました。(良い)
従業員がフォームにクレジットカード番号を入力する前に、良いシナリオから悪いのものですか?
Heartbleed によって侵害されたサーバーへの露出を最小限に抑えるよう、従業員に指示するにはどうすればよいでしょうか?
答え1
基本的には、いいえ、ユーザーは使用しているシステムを完全に把握していないため、良いシナリオと悪いシナリオを区別する方法は 1 つではありません。
このバグによって生じた被害の範囲はまだほとんどわかっていませんが、被害のほとんどは過去に発生した可能性があり、今後も長期間にわたってインターネットに影響を及ぼし続けるでしょう。どのような秘密がいつ、誰によって盗まれたのかはわかりません。
たとえば、Google の OpenSSL のハートブリードは約 1 年間続きます。未知の攻撃者がサーバーを盗み、興味深い秘密を探します。繰り返しますが、攻撃者がこれを実行したかどうかは私たちにはわかりません。攻撃者は、Twitter.com、AnyBank.co.uk、dev.redhat.com など、別のシステムへのアクセス権を持つ人物のアカウントを見つけるまで、このような秘密を探します。このようなアカウントにアクセスできれば、攻撃者はさらに調査を続け、他のシステムにアクセスし、他の損害 (目に見えるかどうかは関係ありません) を与え、他のアカウントをさらに侵害する可能性があります。侵害の原因を誰も疑うことはありません。この段階で、すでに OpenSSL サーバーから遠く離れていますが、これはハートブリードの最も厄介な結果の 1 つです。さらに、サーバーの秘密鍵が侵害されるリスクもあります。
信頼を築くには長い時間がかかり、すぐに失われることもあります。インターネット上で信頼の問題が以前になかったと言っているわけではありませんが、Heartbleed は間違いなく役に立ちませんでした。損害の修復には長い時間がかかり、これを理解することは、自分自身や従業員、顧客、上司などを保護する方法と、保護できない方法を理解することの一部です。脆弱性への露出を制限するために制御できるものもあれば、制御できないものもありますが、それでも影響はあります。たとえば、この脆弱性に対して他のすべての人がどのように対応するかを制御することはできません。NSA はバグを発見したが、沈黙していたと伝えられています。これは私たち全員にとってかなり悪い状況でしたが、私たちにはそれから身を守る方法がありませんでした。
インターネット ユーザーとして、次のことができますし、またそうすべきです。
- 理解するどれだけひどいのかバグは
- パスワードをリセットするように指示するメールに返信したり、メール内のリンクをクリックしたりしないでください。代わりに、会社/組織のWebサイトに直接アクセスして、積極的にパスワードをリセットしてください。このような場合、詐欺師はフィッシングを好みます。
- AndroidスマートフォンにHeartbleedがないか確認してください。アプリLookout Mobile Security から OpenSSL のバージョンをチェックします。
アクセスするウェブサイトに Heartbleed がないか確認します (不完全なチェックリスト):
サーバーは OpenSSL を使用していますか?
- いいえ: あなたは (このバグによって) 直接的な影響を受けていません。サイトの使用は継続しますが、バグによって直接的または間接的に影響を受ける別のサーバーがあなたのパスワードにアクセスした場合に備えて、パスワードを変更してください。もちろん、これは、そのネットワーク上のすべてのサーバーにパッチが適用され、新しい証明書が発行されていることを前提としています。
- はい: 2に進みます。
サーバーは Heartbleed フリー版の OpenSSL を使用していますか? Heartbleed チェック ツールが実際に脆弱性をチェックし、HTTP ヘッダーやその他の「インジケーター」をチェックしていないことを確認してください。
- いいえ: サイトに秘密を送信しないでください。ただし、可能であれば、ウェブマスターにメモを送信してください。
- はい: 3に進みます。
OpenSSL の以前のバージョンには Heartbleed が含まれていましたか?
- いいえ: 一部の管理者は、OpenSSL の最新バージョンにアップグレードしませんでした。これは、十分な期間のフィールドテストが行われていなかったためです。それらのサーバーはこのバグに対して脆弱ではありませんでしたが、上記の理由により、パスワードを変更した方がよい場合があります。
- はい: サーバーは脆弱であり、脆弱なバージョンへのアップグレード時から公開時までの間 (最大 2 年、場合によっては 3 年) にメモリ内のデータが侵害された可能性があります。
ここで信頼の話に戻ります。誰かの信頼を失うのは悪いことです。特にその人がユーザー/顧客/上司である場合はなおさらです。信頼を取り戻すには、もう一度築き直し、対話の姿勢を示さなければなりません。
これを開始するために、Web 管理者が公開できる内容は次のとおりです。
- 以前の OpenSSL バージョン (脆弱/脆弱でない)
- 現在のバージョンと更新日時
以前のバージョンの OpenSSL に脆弱性があった場合:
- 現在のSSL証明書が生成された時期
- 古い証明書が失効された経緯の詳細な説明
- 新しい証明書に新しいシークレットが使用されたことの保証
- 上記の情報に基づいたユーザーへの提案
ユーザーであれば、この種の情報を求める権利があり、サービスの全ユーザーのためにもそうすべきです。これにより、セキュリティ コミュニティの可視性が高まり、ユーザーが侵害されたサーバーにさらされるリスクを最小限に抑えることが容易になります。