ハートブリードを専門用語なしで説明するには？
コンピュータに慣れていない私の友人のほとんどは、ハートブリードとは何か、それがどのように機能するかを知りたいと思っています。技術的背景のない人にハートブリードをどのように説明しますか？
銀行と銀行員の類推
あなたは銀行に電話して、新しい銀行口座を要求し、予約をします-何でも。どういうわけかあなたと銀行はあなたがあなたが誰であるかを確認し、銀行は実際には銀行です。これはあなたと銀行の間の接続を保護するTLSプロセスであり、これは適切に処理されると想定しています。
この劇の役割
- 銀行：ウェブサーバー
- 銀行員：そのサーバーのOpenSSLサービス
- あなた（銀行強盗）：そのサーバーから取得できるすべてをフェッチするボット
接続を維持-ハートビート
銀行の従業員があなたの電話に応答します。情報を要求します。従業員は1分間待つと言って、マイクを無効にします。彼はあなたを聞くことができます、あなたは彼を聞くことができません。その後、それは静かです。長い間。あなたは彼が電話を切ったかどうか疑問に思い始めます。 「こんにちは？」従業員はあなたが言うことをエコーするように指示され、「こんにちは」と返信します。これは、まだ接続があるかどうかを確認するためのハートビートです。
さて、この奇妙な銀行の従業員の場合、従業員がまだオンラインかどうかを尋ねる前に、使用する単語の数を最初に言う必要があります。したがって、「こんにちは」と言う代わりに、「one：hello」または「two：hello there」と言う必要があります。これで従業員は、これらの（最初の）2語を繰り返すことで返信できることを認識し、その後、引き続き要求に対応できるようになります。これはハートビートプロトコルです。
問題-ハートブリード-何が返されるかのチェックなし
OK、退屈し、冗談を言う。あなたは「千：こんにちは」と言います。従業員は、あなたが1つの単語（こんにちは）だけを言ったことを確認せず、「こんにちは」に加えて、マイクをオフにする前に、彼が言ったり、考えたり、記憶している次の999単語で返信し始めます。これが問題の原因となるバグです。
これらの999語は無関係です。それのほとんどは役に立たないでしょう、天気についての発言、コーヒーの要求、昼食の予定など。それのいくつかは銀行や他の顧客についての重要な情報になる可能性があります。金の輸送、顧客は100万ドル、銀行や金庫に入るコードなどを持ち込みます。
実際に1000語の返信があるかどうかのチェックはありません。さらに、この要求を何度も繰り返すことができます-従業員は文句を言わず、他の誰も何が起こっているのか気づかないでしょう。
制限は1つです。この銀行の従業員1人と、彼が話したり考えたりしていることだけから情報を取得します。他の従業員は影響を受けません。あなたは彼の机や彼のロロデックスに何があるのか見ることができません。 （アナロジー：メモリー（RAM）内のデータのみが危険にさらされています。メモリー内に読み込まれないハードディスク上のデータ、および他のプログラムとプロセスからのデータは安全です。）
これを行うと、取得する情報がわかりませんが、何度も何度も繰り返し行うと、だれにも気付かれずに侵入するのに十分な情報が得られます。営業時間後に銀行に入ったり、金庫を開けたりすることができます。これがリスクです。
ソリューション-リクエストの確認とコードの更新
従業員が一瞬だけ返事を考えて、マイクを無効にすると、話している内容が聞こえなくなります。このチェックを行うと、接続が維持され、従業員が電話を切っていないことがわかりますが、ランダムな情報は聞こえなくなります。実際には、従業員は何をエコーするかについての新しい指示が必要です。これは、OpenSSLの最新バージョンへのアップデートで修正されました。
誰かが古いコードを持っているかどうかは不明であるため、銀行は、銀行に入るためにセキュリティキーを更新する必要があります。
私はいくつかの専門用語を使用する必要がありますが、それらを最小限に抑え、それらを説明しようとします。
TLSと暗号化の基本的な概要
あなた（クライアント）は暗号化（アドレスはhttps://で始まる）を使用するWebサイト（サーバーと呼ばれます）にアクセスして、あなたと他のWebサイト以外の誰もがコンテンツの内容を知ることができないようにします送信または受信しているメッセージ。したがって、メッセージがインターネット上のコンピュータ間で転送される場合、メッセージは暗号化されます。このメッセージはこのトランスポート層セキュリティ（TLS）と呼ばれ、暗号化プロトコルの一種です。 TLSを実装するライブラリの1つはOpenSSLです（TLSはSSLの新しい名前ですが、どちらも同じ意図-インターネット上のネットワークトラフィックを暗号化します）。
Heartbeatとは-侵害されたTLS機能ですか？
TLS接続をセットアップするには、比較的コストのかかる（時間がかかる）ネゴシエーションがあります。相互に信頼して暗号化されたデータを安全にやり取りするには、クライアントとサーバー間でいくつかのメッセージを交換する必要があります。迅速で応答性の高いエクスペリエンスを実現する（そしてサーバーの負荷を最小限に抑える）には、すべてのリクエストの前に行うのではなく、可能な限りまれにこのネゴシエーションを実行する必要があります（最新のインタラクティブなWebサイトでは数百のリクエストを数分で実行することが多いため）。さらに複雑なことに、インターネット上のパケットはしばしば失われたり破損したりします。サーバーは、要求が多すぎてTLS接続の終端をドロップする必要がある可能性があります。または、クライアントがブラウザウィンドウを閉じた可能性があるため、サーバーは暗号化された接続の最後を保存し続ける必要はありません。
そのため、2012年にOpenSSL（Heartbeatsと呼ばれます）に提案が実装され、クライアントとサーバー間で「キープアライブ」メッセージを送信して、両方のエンドがまだ接続を使用している場合のネゴシエーションの数を減らします。クライアントはWebサーバーに定期的に「まだいますか？」と尋ねます。そして、ウェブサーバー（まだそこにある場合）は、それがまだそこにあるかどうか、または今後のリクエストで新しいTLSネゴシエーションが必要かどうかを通知します。
ハートビート拡張機能のしくみ
クライアントは、クライアントによって選択されたペイロードと、ペイロードのサイズを含む簡単なヘッダーで構成されるハートビートメッセージを送信します。たとえば、サイズ18とテキストThis is my payloadのハートビートリクエストを送信できます（通常、ランダムに選択されたデータになります）。ウェブサーバーはそのリクエストを受け取り、ペイロードのコンテンツをウェブサーバーのメモリに保存し、クライアントが伝えたペイロードのサイズ18を保存します。
次に、サーバーが「キープアライブ」応答をクライアントに送信すると、ライブラリは、ペイロードを格納した場所からメモリの次の18文字を読み取り、それをクライアントに送信します（クライアントは受信したことを確認します）正しいデータが戻されます）。その後、接続は維持されます。
OpenSSLのハートブリードの欠陥
（Heartbleedという名前の）致命的な欠陥は、OpenSSLライブラリが、ハートビートペイロードのサイズが送信されるペイロードの実際の長さに対応することを確認しなかったことです 。ユーザーは、ペイロードの実際のサイズに関係なく、65535（64キロバイト）までの任意の数値を入力できます。攻撃者がサイズが65535であるとハートビートリクエストを送信したが、ペイロードが18バイトしかない場合、脆弱なサーバーはメモリに18バイトしか保存しません。ただし、応答は保存されている18バイトから始まりますが、次の64KBのメモリからクライアントにデータを送信し続けます。このデータには、ユーザー名とパスワード、秘密鍵、ユーザー名、HTMLページ、ランダムなジャンク、またはWebサーバーがそのIDを確立するために使用する秘密の秘密などがあります。 （1.0.1g以降のバージョンで実装されたOpenSSLの修正は、本質的に、クライアントから通知されたペイロードサイズに対して健全性チェックを実行することです）。
攻撃は何度も繰り返される可能性があり、一般に、毎回Webサーバーのメモリのさまざまな部分が明らかになります。攻撃は、典型的なWebサーバー構成では検出できない方法で匿名で実行できます。通常、IPアドレスを記録するのはWebページを提供するときだけですが、この攻撃はWebページが提供される前の脆弱なバージョンの交渉プロセスの早い段階で発生する可能性があります。
クライアントへの攻撃
この逆バージョンもあり、悪意のあるTLSサーバーに接続するユーザーは、サーバーがキープアライブペイロードのサイズを偽った悪意のあるサーバーから送信されたキープアライブ要求を信頼します。これにより、Webブラウザーは最大64KBの情報をWebサーバーにリークします。 （これは、そこから使用可能な情報を取得するのがはるかに困難であり、匿名で実行することはできず、そのWebページに移動することを選択するクライアントによって開始される必要があります。ただし、OpenSSLにすばやくパッチを適用して、影響を受けるバージョン。）
対処法
OpenSSLを使用するクライアントとサーバーの対策は、それを更新することです。脆弱なOpenSSLライブラリを使用したウェブサーバーを実行しているシステム管理者は、秘密のTLSキーを取り消して新しいキーを生成する必要があります（また、長期間有効なセッショントークンを無効にする必要があります）。クライアントは、漏洩した可能性のある影響を受けるWebサイトのパスワードを変更する必要があります。クライアントの場合、lastpassは heartbleed checker tool をリリースしました。これは、サイトが（1）現在脆弱であるか、（2）以前に脆弱であるとテストされているか、または（3）脆弱である可能性があるか（unix/linux Webサーバーを使用） TLSは、UNIX/Linuxシステムで主に使用されているOpenSSLの使用を示している可能性があります）。これは、特定のWebサイトでパスワードを更新する必要があるかどうかを判断するのに役立ちます。
SSHはTLSではないため、SSHキーは安全です
SSH（Secure Shellの略）は、UNIXおよびLinuxマシンの一般的なツールであり、ユーザーはリモートでマシンにログインし、暗号化されたネットワークを介して転送されるコマンドを発行できます。 SSHはTLSとはまったく異なるプロトコルです（答えはSSLですが、それはTLSの古い名前です-用語はしばしば同じ意味で使用されます） 。 OpenSSH（SSHの最も一般的な実装）とOpenSSLの名前は似ていますが、Heartbleed攻撃のため、SSHキーは脆弱ではありません。
ハートブリード攻撃を通じてリークできるのは、TLS暗号化を実行しているプロセスのメモリのみです。 （プロセスは、アプリケーションの実行中のインスタンスの計算用語です。）最新のオペレーティングシステムは、プロセスが同じシステム上の他のプロセスに割り当てられたメモリを読み書きできないようにする プロセス分離 を実装しています。したがって、 xkcd.com/135 とは異なり、コンピュータのすべてのメモリが危険にさらされていることを心配する必要はありません。Webサーバープロセス（または逆の形式のWebブラウザ）のメモリのみを心配する必要はありません。他のプロセス（ssh、sshd、ssh-agent）で使用されるSSHキーのような秘密は、WebサーバーでもTLSを使用しているため、漏洩していません。
完全を期すために、この脆弱性はOpenSSLライブラリを使用してTLSを実行する可能性のあるすべてに影響を与えることを述べておかなければなりません。これはWebサーバーに限定されません。たとえば、FTPSサーバー（SFTPではない）、電子メールサーバー、データベースサーバーはすべて、構成によっては脆弱である可能性があります。
脆弱なコミットに関する詳細情報
ペイロードのサイズを検証しない脆弱なコードを書いた同じ人物が、TLSのハートビート拡張の同じ作者であったことにも注意する必要があります（ RFC 652 で説明）。プロトコルはハートビート応答の最大サイズを指定していません（最小サイズを指定している間）が、任意の長さにすることを許可し、ペイロードサイズを2バイトヘッダーで記述できるようにしました（最大サイズではなく最大65535にできます） 1バイトのヘッダーを持つ255。これは、255バイト未満のWebサーバープロセスのRAMのみを公開します。正直なところ、16バイト（128ビット）より長いハートビートペイロードを必要とする合理的な理由は考えられません。超偏執狂になりたければ、32バイト（256ビット）にすることもできます。これらの制限があれば、多くの使用可能な情報が漏洩することはほとんどありません。
脆弱なコード が2011年の大晦日の夜に日付が付けられていることも興味深いです。
非常にわかりやすい英語で：攻撃者はサイズ「x」のパケットを送信していると言い、サーバーにそれを送り返すように要求しますが、実際にははるかに小さいパケットを送信します。 OpenSSLライブラリは攻撃者を信頼し、小さな実際のパケットを応答の開始として送り返します。次に、メモリからデータを取得して、期待されるサイズの応答を入力します。これは、サーバーが最近処理した任意のデータである可能性があり、多くの場合、機密情報が含まれています。
この例のダイアログ-おそらくあなたは両方ともキャラクターであるか、あなたに質問してもらいます：
Q1：好きな色は何ですか（1 Word）
A1：青Q2：最後に休日に行った場所（2単語）
A2：フランスへQ3：どの車を運転しますか（1000語）
A3：ヴォクソールアストラ。チーズバーガー。明日はロンドンへ車で行きます。ケーキが好きだ。ああリス。私のPINは1234です。鶏が好きです。SPAAAACEEEE。昨夜はスパゲッティを食べました。BUDWEIS EEEEERRRRなど。
その最後のチャンクは主にゴミですが、そこにはいくつか良い点があるかもしれません。
ここでは、専門用語をほとんど使用しない試みがあります。
「安全な」Webサイト（緑色のバーと南京錠のアイコンが表示されているWebサイト）に接続すると、ブラウザーとWebサイトが少し数学的なやりくりを行い、非常に長くランダムなパスワードのような秘密鍵ができあがります。 -互いに暗号化されたメッセージを送信できます。
サイトをブラウジングしてリンクをクリックするとき、毎回全体をやり直すのは非常にコストがかかるため、Webサイトとブラウザはしばらくの間同じキーを使用し続けます。 Webサイトは、すべての訪問者が使用したすべてのキーのリストを保持したくないため、ハートビートと呼ばれるプロトコルが発明されました。あなたがまだブラウジングしている限り、時々、ブラウザはWebサイトにHEARTBEATというメッセージを送信します。これは、「私はまだここにいるので、キーを保持してください」という意味です。ウェブサイトは、「ロジャー・ザット」の効果に何かを返信します。 Webサイトでしばらくの間ハートビートが聞こえない場合は、他のサイトに移動したと考えられ、新しいサイト用のスペースを作るためにキーを捨てます。
実際、ハートビートはもう1つのことを行います。あなたはそれらと一緒に好きなテキストを送ることができ、ウェブサイトはまったく同じテキストで返信します。なぜこの方法で行われるのかははっきりしていませんが、ブラウザが何かおかしいことが起こっている（間違ったテキストが戻ってくる、またはテキストが間違った順序で戻ってくるなど）かどうかを確認し、誰かが嫌なことをする.
したがって、ブラウザは時々「ハートビート、5文字のテキスト、こんにちは」のようなメッセージを送信し、ウェブサイトは「了解、5文字、こんにちは」と返信します。現在の日付や時刻など、テキストはほとんど何でもかまいません。必要に応じて詩を送ることができます。
心底のバグは、「ハートビート、1000文字、チーズ」などのメッセージを送信した場合、WebサイトがOpenSSLと呼ばれるプログラムを使用して暗号化を行うと、ひどく間違ってしまうことです。 OpenSSLは、インターネットで暗号化を行うために使用される最も一般的なプログラムの一種です。それがすべきことは、チーズが1000文字ではなく6文字を持っていることに気づき、不平を言うことです。代わりに、メッセージを読み取り、メモリのどこかに書き込みます。それから、それは「大声で言う、1000文字、...」と応答し、それがあなたのチーズを保存したところから始めて、そのメモリから次の1000文字を読み始めます。したがって、メモリ内の次の994文字が何であっても聞くことができます。これは文字通り何でもかまいません。ウェブサイトの秘密鍵である可能性があります。それは詩かもしれません。他の顧客のパスワードやクレジットカードの詳細である可能性があります。猫の写真かもしれません。それは完全にランダムですが、このようなHEARTBEATメッセージを送信するたびに、ウェブサイトのメモリの別のランダムな部分が表示されるため、HEARTBEATを何度も繰り返すだけで、遅かれ早かれ面白いものにヒットする可能性が高くなります。
発生する可能性のある最悪の事態は、Webサイトのマスターキーを取得することです。マスターキーは、新しい訪問者がサイトにアクセスするたびに、やりがいのある作業を開始するために使用されていました。これを行うと、理論的には、暗号化がまったくなかったかのように、誰もがサイトで行っていることをすべて読み取ることができます。誰かがログインすると、パスワードを平文で見ることができます。それは良いことではありません。
私が使います 1二 「ハートビート」、「バグ」、「ウェブサーバー」の3つの専門用語。それがあなたの技術者でない友達を怖がらせないことを望みます。
コンピュータがインターネットを介してデータを交換するとき、他のコンピュータがまだ聞いているかどうかを知ることが役立つ場合があります。多くの場所で、「ねえ、あなたは聞いていますか？私が今言ったことを教えていただけますか？」と尋ねるのと同等のことを行うための規定があります。さまざまなコンテキストで、主流メディアで時々現れるようなテクニックには多くの異なる名前があります---「エコー」は1つ、「ping」はもう1つ、そして非常に広く使用されているソフトウェアに重大なバグがあるものです「ハートビート」です。この特定の「ハートビート」スキームは実際には多くのアプリケーションで使用されていませんが、一般的な考え方は非常に役立つため、多くのコンピューターで使用できます。
問題は、ほとんどのWebサーバーが使用するソフトウェアの1つにバグがあることです。と尋ねられた場合、それはだまされて、相手が実際に送信したものよりも多くを繰り返して、残りをWebサーバーが偶然知ることで埋めることができます。このようなトリッキーな方法で質問することにより、このバグのあるWebサーバーに、ユーザーパスワードや（そのような情報を処理するWebサーバーからの）クレジットカード番号、電子メールの内容などの機密データなど、知っているほとんどすべての情報を伝えることができます。他のコンピュータがこれらのWebサーバーになりすますことができる秘密さえも危険にさらされています。
これはウェブサーバーに限定されていませんが、インターネットを使用している誰もがそれに接触する場所です。しかし、コンピュータセキュリティの人々は、影響を受ける可能性のある多くのコンピュータとさまざまなソフトウェアで今すぐ手を尽くしています。
「https」を使用するウェブページにアクセスすると、あなたとウェブサーバー間の接続は暗号化されます。この保護層はSSLまたはTLSと呼ばれます。この実装の基礎となるコンポーネントにはセキュリティ問題があります-Webページを提供するサーバーに「データの漏洩」を引き起こします（つまり、メモリの内容を攻撃者に開示します）。このデータの漏洩方法にはいくつかの制約がありますが、それは非常に深刻であり、脆弱なサーバーであらゆる種類のデータを公開する可能性があります。
これは、脆弱なサーバーからのデータ漏洩の例と、データ漏洩を防ぐ方法を示すテクニカルビデオです。 https://www.youtube.com/watch?v=UjkK22VBzjA
新しいアナロジー：
銀行に電話して、そのオフィスの1つが開いているかどうかを尋ねているとします。あなたは機械を手に入れ（悪名高い「英語、1を押す」の女性）、それはあなたが時間を知りたい銀行の数と、どの銀行かを尋ねます。次に、65,000銀行の時間を希望するが、1つの銀行のコードのみを指定するとします。マシンは65,000銀行の時間を与える必要があると考えていますが、1つの銀行コードしか与えないので、残りを見つけることができるもので埋めます：ランダムな口座からの銀行取引明細書、クレジットカード番号とコード、キーの写真安全のために、マネージャーが彼の医者と当時話し合った...他のデータが無関係であり、あなたが1つの銀行の営業時間しか得ていないはずであることに気づいていません。
古い答え：
あなたの銀行があなたのデビットカードの現在のピンコードの安全なリクエストを送ることができるシステムを持っていると想像してください、そしてシステムはピンコードと銀行カード番号を返します。このシステムは、リセットするカードのリストを送信できるアップデートを取得します。
リセットする65,535のデビットカードのリストのリクエストを送信しますが、渡すのは1つのカード番号のみです。その単一のカードだけを返すか、エラーをスローする代わりに、銀行は他のランダムユーザーから65,534枚の他のカードの既存のコードを送り返します。
一度も読んだことがなく、内容がわからない本を想像してみてください。本が閉じているので、心が痛むバグは、ランダムにページを開いて本からテキストを読むことができる方法にすぎません。十分な情報を抽出した後は、本を複製して、誰にも気付かれずにシェルターで置き換えることができます。本はあなたのコンピュータかあなたのサーバーのどちらかです。
それが私が技術者でない人に与える最も簡単な説明でしょう。
こんな感じです。
あなたは通りを歩いていて、銀行の入口を通過すると、彼の道を行く途中で自閉症の聖人に遭遇します。彼はナイスガイのように見えますが、あなたはそうではなく、悪意のある目的で彼を使用できることを知っています。あなたは、サバントが驚くほどの量のデータを保持して繰り返すことができ、一般的にかなり注意深いことを学んだので、十分な映画を見ました。あまりにも。
それで、あなたは彼に時間を尋ねます。彼はあなたに時間を教えてくれますが、話し続けるしかないでしょう。彼はそこにいた間に彼の目と耳を通り過ぎたすべての銀行口座番号とパスワードをあなたに話します。
その情報はあなたのものです。あなたがしなければならなかったのは、彼の状態のおかげで、サヴァントはあなたに話すのを止められなかったので、時間を尋ねるだけでした彼が思っていた以上に。彼が気づいていないのは、あなたが悪意のある目的で時間を求めることによって、起こりそうなことを知っていたので、あなたは予想以上に求められたでもあるということです。
貧しいチャップ。