Heartbleedの修正中にインターネットを使用する方法は?


119

現在脆弱ではない多くのウェブサイトがありますが、数日前にそれら脆弱であったかどうかわかりません。

例えば:

  • twitter.com:現在脆弱ではありませんが、証明書は2014年3月5日水曜日00:00:00 UTC 2014からのものです
  • google.com:現時点では脆弱ではありませんが、証明書は2014年3月12日水曜日09:53:40 UTC 2014
  • bankofamerica.com:現在脆弱ではありませんが、証明書は2013年12月5日(木)00:00:00 UTC 2013からのものです

私は何をしますか?再発行されるまでこれらを使用しないでください?新しいキーを使用して証明書を再発行することをどのようにして知ることができますか?これらのサイトにログインしてパスワードを変更するべきではないようです。なぜなら、それらが本当のウェブサイトであることを知る方法がないからです。


回答:


201

更新2014-04-11

Cloudflareは、秘密鍵の抽出が実際に可能であったことを確認するためのチャレンジを設定しました。これは約10万件のリクエストで行われ、恐怖を検証しています。もはや理論的ではありませんが、証明されています。あなたはそれについて読むためにここに行くことができます。

また、ブルームバーグは、NSAがこのエクスプロイトについて少なくとも2年間知っていると報告しています。NSAには、このようなソフトウェアのエクスプロイトを見つけることが唯一の仕事であるアナリストを雇うリソースがあるため、これは理にかなっています。米国政府がこれを長い間悪用してきたことがわかったので、他の州がそれを知って悪用した可能性は大きい。


TL; DR システムのステータスに関する組織からの発表を監視し、パスワードをすべて変更し 、銀行やその他の金融システムなどの重要なアカウントでの詐欺/疑わしい活動を監視します。

状況が非常に危険な理由を理解するには、まずこの攻撃が実際に何をするのかを理解する必要があります。Heartbleedとも呼ばれるCVE-2014-0160は、攻撃者がOpenSSLの脆弱なバージョンを実行しているサーバーから最大64 kBのメモリを取得することを可能にするバッファオーバーリードバグです。

それは本当に悪いように聞こえます。実際にはどのように機能しますか

あなたは正しい、それは深刻な欠陥ですが、我々は少し後でそれに戻ります。今、エクスプロイトが機能する理由について話しましょう。Transport Layer Security(TLS)は、HTTPHTTPS)を含む多くのアプリケーションによって情報を保護するため、またはSMTPを保護するために使用されますたとえば、有効になっている場合。TLSの標準を設定するRFC 5246には、ハートビートと呼ばれる機能があります。クライアントとサーバーは、後で使用できるように、接続を維持するためにデータをやり取りします。実際には、クライアントはデータを送信し、サーバーはそれを送り返すだけで、すべてが素晴らしいです。ただし、影響を受けるOpenSSLバージョンでは、クライアントが実際に送信したデータ量を送信したかどうかを確認するチェックはありません。したがって、1バイトを送信し、実際に64 kBを送信したことをサーバーに伝えると、64 kBが返送されます。これらの他のバイトはどこから来たのですか?それが問題の鍵です。OpenSSLは64 KBを送り返します-1バイトが保存されている場所に応じて、プロセスがアクセスでき、最初は送信しなかった1バイトのメモリ。サーバーが使用するために復号化する秘密鍵素材¹と情報。たとえば、パスワード、クレジットカード情報、PINなどです。

OK。情報セキュリティにとってそれはどういう意味ですか? 非対称暗号化がどのように機能するかを理解していれば、開示によって暗号化が難読化にすぎないため、これが深刻であることをすでに知っています。これは、サーバーにパッチが適用され、メモリリークが発生しなくなったとしても、セッションは依然として安全でない可能性があることを意味します。これが公に知られる前に、またはパッチの適用中に悪用された可能性がありますが、現在、攻撃が行われたことを示す方法は証明されていません。IDSのルールが利用可能になる可能性がありますが、現時点ではそうではありません。 IDSルールがリリースされました。オペレーターは自分のキーがまだ安全かどうかわからないため、それ自体は非常に危険です。

キーが漏えいしたと仮定することを余儀なくされます。つまり、回線を介して送信するすべてのものが第三者によって解読される可能性があることを意味します。これを軽減する唯一の方法は、キーを再生成し、古い証明書を失効させながら新しい証明書を再発行することです。残念ながら、現時点ではCAがこれらの要求であふれていることは間違いないため、これには時間がかかります。それでも、これは中間者攻撃や他のフィッシングの可能性を残します。

安全になるのはいつですか? 安全になる時期を知ることは難しい質問です。監視することをお勧めするいくつかのことは、影響を受けるバージョンを使用したことがないため、バグが環境内で修正された、または脆弱性がないことを説明する公開アナウンスです。彼らがOpenSSLの新しいバージョンにアップグレードしたことを発表したら、エクスプロイトの公開リリース日(2014年4月7日)以降に署名さた新しい証明書を使用していることを確認します。

**秘密鍵が後で漏洩した場合、以前に記録されたトラフィックが復号化される可能性があることに注意してください。

自分を守るためにユーザーとしてできること

今後数日間、オンラインバンキングやオンライン医療カルテアクセスなどの重要なサイトの使用を避けることができれば、そうすることをお勧めします。そうする必要がある場合は、セッションが潜在的に危険にさらされていることを理解し、その結果を受け入れる準備をしてください。また、組織が脆弱ではなくなったと発表した後、パスワード変更する必要があります。パスワードマネージャーを使用すると役立ちます。また、銀行の詳細やクレジットカード番号など、使用した他の情報を変更または監視する準備をする必要があります。

活動家への特別な通知

OpenSSLを使用するなど、影響を受ける可能性がTorの。このようなエクスプロイトを探すために必要な膨大なリソースがあるため、政府は2年以上前のOpenSSLリリースに含まれていたため、この欠陥を使用できた可能性があります。プライベートではなくなりました。

** 完全転送セキュリティ(PFS)が実装されていない限り、秘密キーが後で漏洩した場合、以前に記録されたトラフィックが復号化される可能性があることに注意してください。

¹-秘密鍵がメモリ内にない可能性が高いという主張がありましたが、同時に鍵抽出が成功したという主張がありました。この時点で、どちらの側が正しいかは不明です。


45
これは、私がこの新しいホットクレイジークリティカルハートブリード攻撃について読んだ最も有益なテキストです(他のすべての記事/ブログ/ニュース投稿にはほんの一部の情報が含まれています)。良くやった :) 。
ラドゥマーゼア14

4
新しいキーを使用して新しい証明書が生成されることをどのようにして知ることができますか?

3
Note that previously recorded traffic may be decrypted if the private key was later leaked. サーバーが前方秘匿性のある暗号を使用していた場合ではありません。
ウェス14

2
@Wes PFSがトラフィックを安全に保っていた可能性が高いことは正しいです。私は、人々を混乱させることなく、状況を説明するための細かい行を歩いていました。残念ながら、PFSは広く展開されていません。
ジェイコブ14

6
要約するとwhat is heartbleed bug xkcd.com/1354
GoodSp33d

14

この脆弱性がもたらすリスクは誇張されすぎています。これは、この脆弱性が2日前に研究者によって公開される前に知られていた、または悪用されたというゼロの証拠があるためです。

脆弱なWebサイト、特にインターネット上で機密データを処理するWebサイトにパッチを適用することは急務です。同様に、攻撃の署名をIDSおよびマルウェア保護ツールに読み込むことも緊急です。IT内部では、この脆弱性に最優先で対応する必要があります。

そうは言っても、この脆弱性に関連する公共報道機関によるリスクのレベルが正当化されるとは思いません。

個人は自分自身を守るために何をすべきですか? 脆弱なバージョンのOpenSSLを実行しているサイトを使用しないでください。

この脆弱性が悪用されたという証拠がない限り、それ以上のアクションは無意味であり、FUD以外の何ものでも動機付けられません。あなたは同意しませんか?任意のコードの実行可能にする、毎月または四半期にリリースされる多くの脆弱性を考慮してください。攻撃者にルートまたはシステムレベルの特権を与える、または攻撃者が特権エスカレーションによってその後それらを取得できる場合、この脆弱性が存在するため、脆弱なシステムによって処理されるすべてのデータのセキュリティに対するリスクが大きくなります。

多くの場合、これらの脆弱性はソフトウェアベンダーまたはベンダーに通知する研究者によって発見されます。ベンダーは、脆弱性の詳細を公開せずにパッチを作成し、市場にリリースします。場合によっては、テストツールで使用するためにセキュリティコミュニティによって詳細が公開され、エクスプロイトが公開されます。これらの多くの脆弱性に対して、「すべての秘密が暴露された可能性があります!」と言って反応することはありません。

搾取の証拠がある場合、適切に対応する必要があります。この脆弱性を発表した研究者の過剰反応と、研究者のゆるい話を増幅した報道機関には大きなリスクがあります。 彼らは泣いているオオカミです。

-エルビエホ


9
この回答は、より多くのIMOに賛成票を投じる必要があります。ありたくさんの人がサーバの秘密鍵を盗むためにできるようになる毎月公表された脆弱性のは、と大騒ぎの多くはそれらについて行われません。これ、OpenSSLが広く普及しているために、平均よりも深刻ですが、依然として誇大宣伝されています。
アラステア14

2
「この脆弱性が悪用された証拠がない限り」「悪用の証拠がある場合、適切に対応する必要があります。」あなたは搾取の証拠についてたくさん話します。ただし、Heartbleedバグの恐ろしい点の1つは、悪用の成功が事実の後に検出できないことです(着信ハートビートメッセージを毎回完全に保存し、それでも悪用の成功がセキュリティ)。バグの悪用が成功したという事実の証拠の後に、どのように確立することを提案しますか?
CVn 14

6
-1この著者は、私が考えていない攻撃の性質を本当に理解していないからです。1つは、この種のアクセス権を持っている攻撃者は、それを秘密にして、侵入の証拠が出ないようにするために非常に懸命に働くでしょう。インターネット上の安全なトラフィックの約半分のセキュリティに割り込むこの種のバグは、オオカミの泣き声ではありません。それは非常に深刻な問題だと思います。
楕円ビュー

19
ITセキュリティに関しては、ブルース・シュナイアーに最高の敬意を払います。引用するにはハートブリードの脆弱性についての彼のブログ記事を「致命的な」は正しい言葉です。1から10のスケールでは、これは11です。それだけで、問題に対するあなたの軽視に強く反対するのに十分です。
抽象化14

8
この投稿はダウングレードする必要があります。この問題は宣伝されているわけではなく、OpenSSLの壊滅的な障害であり、公に発表されるまで使用されなかったとしても、悪いプレイヤーはサイトを完全に侵害してしまいます。また、NSAがそれについて知っていた可能性が高いです(しかし、これは証明できません)。これは意図的な妥協であることを指摘する説得力のある理論がありますが、著者はそれを否定しています。
davidgo

5

すべてのWebサイトがHTTPS用のOpenSSLライブラリを使用しているわけではなく(たとえばGnuTLSやPolarSSLもあります)、OpenSSLのすべてのバージョンが脆弱であったわけではありません(古いバージョンはそうではありませんでした)。これは、あなたが言及したウェブサイトが必要としないために証明書を変更しなかった可能性がかなりあることを意味します。証明書が発行された日付を見るだけでは十分ではありません。

ウェブサイトが脆弱である場合、たとえば、あなたがチェックに役立つツールやサイトの数があります。 - http://filippo.io/Heartbleed - https://gist.github.com/mitsuhiko/10130454 - HTTPS:/ /www.ssllabs.com/ssltest/

残念ながら、あなたがすでに述べたように、これは彼らがそうであったかどうかを教えてくれません。ここでの重要な問題は信頼であると思います。内部情報なしで使用および使用されているSSLライブラリを検証する客観的な方法はありません。あなたは彼らがするべきことをすることを望んでいなければなりません(それは正しいことだから、あるいは彼らは公的な屈辱を恐れているからです)。

もちろん、これらのWebサイトに影響があるかどうかはいつでも尋ねることができます。これについての公式声明を発行する多くのWebサイトを見てきました。TwitterやFacebookなどのソーシャルメディアを使用して公に質問することは、多くの場合有効です。

したがって、私ができる最善のアドバイスは、一般的なアドバイスです。インターネット上に残すものや、個人情報で信頼するWebサイトに注意してください。


3
表示される避けられないPolarSSLのバグのために待機し(それはある ...リスト内の次)
strugee

1

公開されている秘密鍵に関して、誰かが暗号化されたセッションでデータを復号化できるかもしれませんが、秘密鍵を持っているので、セッションの途中としての地位を確立する必要があります。インターネット上の誰もがこれを行うことはできません。

私の理解では、ローカルLANとARPスプーフィングのいずれかによってトラフィックを傍受するか、偽のルートをインターネットルーターにアドバタイズしてトラフィックをハイジャック/リダイレクトできる必要があります。この種の攻撃は、この脆弱性がなくても常に可能です。


2
Heartbleedには必ずしも当てはまりません。バグが存在するのは、RAMにアクセスすることで(暗号化されるはずの)データが公開される可能性があるためです。したがって、この脆弱性を悪用するためにトラフィックを傍受/盗聴する必要はありません。ただし、サーバーまたはクライアントのいずれかに悪意のあるソフトウェアをインストールする必要があり、RAMにアクセスするには適切なアクセスも必要です。
ub3rst4r 14

そうではありません。Man-In-The-Middle攻撃によっても侵害される可能性があります。また、メモリダンプは、そのセッションのみに影響を与えません、それは[MITM攻撃を経由]すべてのトラフィックをデコードfaciliteする秘密鍵に加えて、他のユーザーの暗号化されていないユーザー名とパスワードを確認する(メモリ・ブロックの内容に応じて)が可能です
davidgo 14

サーバーにパッチを適用した後、主に侵害されたキーの使用に言及していることを少し明確にすべきだったと思います。
PeterJ 14

0

LastPass Heartbleed CheckerでサイトのURLを入力すると、そのサイトが脆弱であったかどうか、およびその証明書が更新された時期が通知されます。

また、Chromebleedと呼ばれるChrome拡張機能もあり、Heartbleedの影響を受けるサイトにアクセスしている場合に警告します。

Mashable.comには、影響を受けているかどうか、パスワードを変更する必要があるかどうか、よく知られているサイトのリストがあります。興味深いことに、Banks and Brokeragesリストのサイトはいずれも影響を受けませんでした。



-1

全体として、私は偏執病があなたに届かないようにしないでください。現実的には、トラフィックを復号化してパスワードを取得できただけでは、実際に実行したのと同じではありません。

Twitter、Facebook、Gmail、銀行などのサイトで二要素認証を使用する場合は(そうするべきです)、あまり心配する必要はありませんし、そうでない場合でもおそらく大丈夫です。

すべてのパスワードを変更する必要があると感じた場合は、先に進み、必要なときにそれを実行する必要があります。これですべてです。


1
二要素認証は、悪用者がこの悪用を取り巻く可能性のあることを何もすることを止めません。あなたがそれを育てる理由はわかりません。ソーシャルアカウントへのアクセスを取得することは、とにかくOpenSSLでこのエクスプロイトを利用する可能性のある誰かの関心事ではありません。
ラムハウンド14

1
@ramhoundはコメントが削除される前にコメントで言及しましたが、2つの要素が役立ちます。サイトが新しい証明書を発行すると、攻撃者が持っていたパスワードはもはや役に立たなくなるからです。新しい証明書が発行(およびサーバーにパッチを適用)するまでパスワードを変更しても意味がないため、得られるのは、攻撃者が秘密キーを持っている間に発生した可能性のある資格情報漏洩からアカウントを即座に再確保することです。彼らは他の多くのウェブサイトのためのシングルサインオンとして使用することができる。また、TwitterやFacebookが重要である(私は信じている。この1を含む?)
Sirex

ユーザーは同じパスワードを使用するので、パスワードは有効です。はい、2要素認証を使用するユーザーもです。攻撃者が基本的にセッションデータをダンプできる限り、攻撃者はあなたに対してMiTM攻撃を実行できます。
ラムハウンド14

ええ、しかし、パスワードの再利用は本当に別の失敗です。私のポイントは、余波の深刻さと寿命を軽減するのに役立つ2つの要因でしたが、実際には、実際のバグが悪用されるのを助けません。
Sirex 14

@Sirex 2ファクタ認証を使用してログインしているサイトが見つからない限り、私のマシンのCookieは無効になります。これはもちろん彼らの失敗ですが、私のポイントは、現時点では二要素認証は救世主ではありません。攻撃者は非常に簡単にクッキーを傍受し、独自のリクエストでそれらを使用する可能性があります。さらに、(システム管理者であっても)このバグを悪用したかどうかを知る方法がないため、唯一の安全な前提は、このバグが悪用されたということです。たとえば、水曜日の朝の時点で、chase.comが依然として脆弱であったことを知っています。ありそうにないが、攻撃者はそれを見逃した。
CrazyCasta
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.