Heartbleedが修正されている間にインターネットを使用する方法？
現在脆弱ではないWebサイトは多数ありますが、数日前にがに脆弱であるかどうかはわかりません。
例えば：
- Twitter.com：現在脆弱ではないが、証明書は2014年3月5日水曜日00:00:00から
- google.com：現在脆弱性はありませんが、証明書は2014年3月12日水曜日のものです。09:53:40 UTC 2014
- bankofamerica.com：現在脆弱ではありませんが、証明書はThu Dec 05 00:00:00 UTC 2013のものです
私は何をしますか？彼らが再発行するまでこれらを使用しないでください？彼らが新しい鍵で証明書を再発行することをどうやって知ることができますか？自分のパスワードを変更するためにこれらのサイトにログインしてはいけません。なぜなら、それらが本当のウェブサイトであることを知る方法はないからです。
2014-04-11の更新
Cloudflareは、秘密鍵の抽出が実際に可能であったことを確認するためのチャレンジを設定しました。これは約10万件のリクエストで行われ、恐怖を検証しています。もはや理論的ではありませんが、実証済みです。 here に進んでそれについて読むことができます。
また、 Bloomberg は NSA が少なくとも2年間この悪用について知っていることを報告しています。 NSAには、このようなソフトウェアの悪用を見つけることを唯一の仕事とするアナリストを雇うリソースがあるため、これは理にかなっています。米国政府がこれを長い間悪用してきたことがわかったので、他の州がそれを知って悪用した可能性は大きい。
TL; DRシステムのステータスに関する組織からの発表を監視し、変更ALLパスワードを入力し、銀行やその他の金融システムなどの重要なアカウントでの不正行為/疑わしい活動を監視します。
状況が非常に危険な理由を理解するには、まずこの攻撃が実際に何をするのかを理解する必要があります。 Heartbleedとも呼ばれるCVE-2014-0160は、攻撃者がOpenSSLの脆弱なバージョンを実行しているサーバーから最大64 KBのメモリを取得することを可能にするバッファオーバーリードバグです。
それは本当に悪い音です。実際にはどのように機能しますか
あなたは正しい、それは深刻な欠陥ですが、我々は少し後でそれに戻ります。今、エクスプロイトが機能する理由について話しましょう。 Transport Layer Security （TLS）は、 HTTP （ HTTPS ）を含む多くのアプリケーションによって情報を保護するため、または保護するために使用されます SMTP たとえば有効な場合。 TLSの標準を設定するRFC 5246には、ハートビートと呼ばれる機能があります。クライアントとサーバーは、後で使用できるように、接続を維持するためにデータをやり取りします。実際には、クライアントはデータを送信し、サーバーはそれを送り返すだけで、すべてが素晴らしいです。ただし、影響を受けるOpenSSLバージョンでは、クライアントが実際に送信したデータ量を送信したかどうかを確認するチェックはありません。したがって、1バイトを送信し、実際に64 KBを送信したことをサーバーに伝えると、64 KBが返送されます。これらの他のバイトはどこから来たのですか？それが問題の鍵です。 OpenSSLは、64バイト-プロセスがアクセスでき、元は送信しなかった1バイトのメモリを、1バイトが保存されている場所に応じて送り返します。メモリからのこれらの余分なバイトは、秘密鍵素材¹などの貴重な情報と、サーバーが使用するために復号化する情報を含む可能性があるため、問題です。この例としては、パスワード、クレジットカード情報、および/または PIN があります。
OK。情報セキュリティにとってそれはどういう意味ですか？非対称暗号がどのように機能するかを理解していれば、開示が暗号化を難読化にすぎないため、これが深刻であることをすでに知っています。これは、サーバーにパッチが適用され、メモリーリークが発生しなくなったとしても、セッションは依然として安全でない可能性があることを意味します。これが公に知られる前に、またはパッチが適用されている間に悪用された可能性がありますが、現時点では攻撃が行われたことを示す方法は証明されていません。 IDS のルールが利用可能になる可能性がありますが、 しかし、今のところそうではありません。 IDSルールがリリースされました 。オペレーターは自分のキーがまだ安全かどうかわからないため、それ自体は非常に危険です。
キーが漏えいしたと想定せざるを得ません。つまり、ネットワークを介して送信するすべてのものが第三者によって解読される可能性があるということです。これを軽減する唯一の方法は、キーを再生成し、古い証明書を失効させながら新しい証明書を再発行することです。残念なことに、 CAs がこれらのリクエストであふれているのは間違いないので、これには時間がかかります。それでも、これは 中間者攻撃 、または他のフィッシングの可能性を残します。
いつ安全になるのか？いつ安全になるのかを知るのは難しい質問です。監視することをお勧めするのは、影響を受けるバージョンを使用したことがないため、環境にバグが修正された、または脆弱性がないことを説明する公開アナウンスです。彼らがOpenSSLの新しいバージョンにアップグレードしたことを発表したとき、私は彼らが署名された新しい証明書を使用することを保証しますafter公開日2014-04-07であったエクスプロイトの.
**秘密鍵が後で漏洩した場合、以前に記録されたトラフィックが復号化される可能性があることに注意してください。
自分を守るためにユーザーとしてできること
今後数日間、オンラインバンキングやオンライン医療カルテアクセスなどの重要なサイトの使用を避けることができれば、そうすることをお勧めします。そうする必要がある場合は、セッションが潜在的に危険にさらされていることを理解し、その結果を受け入れる準備をしてください。また、組織が脆弱ではなくなったと発表した後、パスワードを変更する必要があります;パスワードマネージャを使用すると役立ちます。また、銀行の詳細やクレジットカード番号など、使用した他の情報を変更または監視する準備をする必要があります。
活動家への特記事項
OpenSSLを使用するすべてのものが影響を受ける可能性があります（ Tor など）。このようなエクスプロイトを探すために必要な膨大なリソースがあるため、政府は2年以上前のOpenSSLリリースに含まれていたため、この欠陥を使用できた可能性があります。プライベートではなくなりました。
**以前に記録されたトラフィックは、 完全転送セキュリティ （PFS）が実装されていない限り、秘密鍵が後で漏洩した場合に復号化される可能性があることに注意してください。
¹-秘密鍵がメモリにない可能性が高いという主張がありましたが、同時に鍵の抽出が成功したという主張がありました。 この時点で、どちらの側が正しいかは不明です。
この脆弱性によってもたらされるリスクは、過度に高まっています。私がこれを言うのは、この脆弱性が2日前に研究者によって公表される前に知られていたか、または悪用されたというゼロの証拠があるからです。
明確にしておきますが、脆弱なWebサイト、特にインターネット経由で機密データを扱うサイトには、パッチを適用することが急務です。攻撃のためのシグニチャがIDSおよびマルウェア防御ツールにロードされることも同様に緊急です。 IT内部では、この脆弱性に最優先で対処する必要があります。
そうは言っても、私は、このような脆弱性に関連する公的機関によるリスクのレベルが正当化されるとは思わない。
自分自身を保護するために個人は何をすべきですか？OpenSSLの脆弱なバージョンを実行しているサイトを使用しないでください。
この脆弱性が悪用されたという証拠が存在するまでの間は、それ以上の対応は無意味であり、FUD以外の何ものでもありません。あなたは同意しませんか？毎月または四半期にリリースされた任意のコードの実行を許可する多くの脆弱性を考えてください。攻撃者にルートレベルまたはシステムレベルの特権を与える、またはその後特権の昇格によって攻撃者が特権を得ることができる場所には、この脆弱性が存在するのと同じくらい脆弱なシステムによって処理されるすべてのデータのセキュリティに対するリスクがあります。
多くの場合、これらの脆弱性はソフトウェアベンダまたはベンダに知らせる研究者によって発見されています。ベンダーは、脆弱性の詳細を公表せずにパッチを作成して市場に公開します。場合によっては、詳細が公開され、エクスプロイトがテストツールで使用するためにセキュリティコミュニティによって公開されます。 「私たちの秘密はすべて公開されている可能性があります」と言って、私たちはこれらの多くの脆弱性に反応しません。
搾取の証拠がある場合は、それに適切に対応する必要があります。私はこの脆弱性を発表した研究者の過剰反応と研究者たちのゆるい話を増幅させた報道機関に大きなリスクを感じます。 泣いているオオカミです。
- エルビエホ
すべてのWebサイトがHTTPSにOpenSSLライブラリを使用するわけではなく（たとえばGnuTLSやPolarSSLもあります）、OpenSSLのすべてのバージョンが脆弱であるとは限りません（古いバージョンはそうではありませんでした）。これは、あなたが言及したWebサイトが証明書を変更しなかったために証明書が変更されなかった可能性がかなりあることを意味します。証明書が発行された日付を見るだけでは十分ではありません。
Webサイトが脆弱であるかどうかを確認するのに役立つツールやサイトがいくつかあります。例えば、 - http://filippo.io/Heartbleed - https://Gist.github.com/mitsuhiko/10130454 - https：//www.ssllabs。 com/ssltest /
残念ながら、あなたがすでに述べたように、彼らがそうであったかどうかこれはあなたを教えていません。ここでの重要な問題は信頼です。内部情報なしでどのSSLライブラリを使用し使用したかを検証するための客観的な方法はありません。あなたは彼らが彼らがする必要があることをしたことを願わなければなりません（それが正しいことであるから、あるいは彼らが公の屈辱を恐れているためでさえ）。
もちろん、影響を受けた場合はいつでもこれらのWebサイトに問い合わせることができます。私はこれについて一般の声明を発行しているWebサイトをいくつか見ました。 TwitterやFacebookのようなソーシャルメディアを公に使用して尋ねることはよく機能します。
だから私が与えることができる最もよいアドバイスは一般的なアドバイスの一部です：あなたがインターネットに置き去りにするものとあなたがあなたの個人情報であなたが信頼するウェブサイトに注意してください。
公開されている秘密鍵に関して、暗号化されたセッションで誰かがデータを復号化できる場合がありますが、秘密鍵を持っているにもかかわらず、 として設定する必要があります。セッションの途中 にいる男。インターネット上の誰もがこれを実行できるわけではありません。
私の理解するところでは、彼らはあなたのローカルLAN上にいて ARP なりすましたり、インターネットルーターに誤った経路を広告することによってトラフィックをハイジャック/リダイレクトすることによってトラフィックを傍受する必要があります。 。この種の攻撃は、この脆弱性がなくても常に可能です。
私はまた次のサイトを訪れるでしょう。
https://www.ivpn.net/blog/heartbleed-passwords-change
影響を受けた人気のあるサイトのリストと、パスワードを変更するタイミングと場所
サイトのURLを LastPass Heartbleed Checker に入力すると、そのサイトが脆弱かどうか、および証明書が更新された時期がわかります。 。
Heartbleedの影響を受けるサイトにアクセスしている場合は、 Chromebleed というChrome拡張機能も表示されます。
Mashable.com には、よく知られているサイト、影響を受けているかどうか、パスワードを変更する必要があるかどうかのリストがあります。興味深いことに、Banks and Brokeragesリストのどのサイトも影響を受けませんでした。