web-dev-qa-db-ja.com

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

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

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

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