web-dev-qa-db-ja.com

Heartbleedエクスプロイトの使用についてログを確認しますか？

以下 などの記事によると、Heartbleedエクスプロイトで説明されているペイロードと一致するハートビート要求のログを確認することは明らかに可能です。

これは、サーバーオペレーターが自分のログ（サーバーレベル、標準のLinuxディストリビューション）で確認できるものですか？その場合、どのログをどのようなパターンでチェックする必要がありますか？

loggingserverheartbleed
10
Jon L.

サービス（nginx、Dovecotなど）のアクセスログからは、影響を受けたかどうかはわかりません。以前にすべてのSSLトラフィックをキャプチャしていない限り、過去に攻撃されたかどうかを確認することもできません。

パケットキャプチャで照合するパターンは非常に簡単です。

  1. 悪意のあるハートビート要求が送信されます。
  2. 過度に長いハートビート応答が返されます（バグのあるバージョンの場合）。

ハートビート要求が暗号化されていない場合（つまり、ハンドシェイクが完了する前に送信された場合）、トランスポート層（UDP、TCPまたは追加のアプリケーション固有層））のデータは次のとおりです。

18       # Content Type Heartbeat 
vv vv    # TLS version (e.g. 03 01 is TLS 1.0, 03 03 is TLS 1.2)
ll ll    # Record length (length of the following data)
01       # Message type (1 = request, 2 = response)
xx xx    # Payload length
[payload]
[at least 16 bytes of padding]

ペイロードの長さが正確にxx xx（ビッグエンディアン）でない場合は、攻撃された可能性があります。返答が返ってきたら成功です。

18 vv vv    # Same record layer header
ll ll       # Length of following data
02
xx xx       # Same length as requested
[data of length xx xx]

中断されるまでネットワークインターフェイスeth0から将来のすべてのデータをキャプチャするコマンドの例（rootが必要）：

tcpdump -i eth0 'tcp port 443' -w ssl.pcap

Wireshark を使用して、ファイルssl.pcapを調査できます。表示フィルターssl.heartbeat_messageは、すべてのハートビート要求とメッセージを表示します。注：SSLフィルターが適用されない場合があります。その場合は、パケットを右クリックし、Decode as ..をクリックして、SSLを選択します。 git commit 3f81af22e0116a2f83c0298de7874959b3967da2（2014年4月11日）なので、エキスパートフィルターssl.heartbeat_message.payload_length.invalidを使用して、不正な形式のハートビートリクエストをターゲットにすることもできます（暗号化されていない場合）。

暗号化されたハートビートについては...ハートビートを見るのは一般的ではないので、TCP接続用にハートビートを取得すると、それはすでに疑わしくなります。暗号化されたハートビートに関するいくつかのヒントが役立つかもしれません：

  • ハートビートリクエストとそれに続く巨大なハートビートレスポンスは、脆弱なサーバーが悪用された兆候です。
  • ハートビート要求に続いてハートビート応答がない場合、サーバーを悪用しようとする試みを通知する可能性がありますが、サーバーにはパッチが適用され、応答しません。
  • 暗号化されたアラートが後に続くハートビート要求は、サーバーを悪用しようとする試みを示す可能性がありますが、サーバーはOpenSSLを実行せず、無効な要求を拒否します。
  • 後続の多数のハートビート（たとえ小さい場合でも）は、ペイロード長が短い場合に悪用の試みに成功する可能性があります。
11
Lekensteyn