web-dev-qa-db-ja.com

Heartbleedに対して脆弱であることが証明されているクライアントは何ですか？

severalpages では、Heartbleedに対して脆弱なOpenSSL実装を使用する攻撃者がサーバーまたはクライアントから最大64Kのメモリを取得できることが繰り返されます（CVE-2014-0160 ）。サーバーアプリケーションのバグを明らかにする 数十oftools があります。

これまでのところ、クライアントアプリケーションのバグを悪用する単一のツールを見たことがありません。クライアントでバグを悪用するのは難しいですか？クライアントは実際に脆弱ですか？

tlsheartbleed
73
Lekensteyn

実際、yes、クライアントは脆弱です。これまでのところ、サーバーは悪用に対してよりオープンであるため、サーバーに注目が集まっています。 （ほぼ）誰でもパブリックHTTP/SMTP/...サーバーに接続できます。

このブログ は、バグが実際にどのように機能するかを説明しています（dtls_process_heartbeat()について言及していますが、tls_process_heartbeat()も同じように影響を受けます）。この関数はクライアントとサーバーアプリケーションの両方で使用されるため、実際にはクライアントshouldも脆弱です。

RFC 6520によると、ハンドシェイク中にハートビートを送信しないでください。実際には、OpenSSLはServerHelloの送信直後にハートビートを受け入れます（これはJared Staffordのssltest.pyが行うことです）。さらにテストを行ったところ、サーバーがハートビート権限を送信することでクライアントを悪用できることを発見しましたafter ServerHelloも送信します。同じバグを引き起こします。

概念実証は、私のリポジトリの https://github.com/Lekensteyn/pacemaker にあります。 READMEから：

次のクライアントは1.0.1fに対してテストされており、ハンドシェイクの前にメモリリークが発生しました。

  • MariaDB 5.5.36
  • wget 1.15（以前の接続と自身の状態のメモリをリークします）
  • curl 7.36.0（--ftp-sslを使用したhttps、FTP/IMAP/POP3/SMTP）
  • git 1.9.1（テスト済みのクローン/プッシュ、リークはほとんどありません）
  • nginx 1.4.7（プロキシモードでは、以前のリクエストのメモリリーク）
  • リンク2.8（以前の訪問の内容を漏らす！）
  • KDE 4.12.4（kioclient、Dolphin、httpsおよびftpsをkde4-ftps-kioでテスト）
  • Exim 4.82（送信SMTP）

64 KiBのメモリ（65535バイト）が実際に返されることが実証されています。また、クライアント（wget、KDE ​​Dolphinなど）が、パスワードを含む可能性のある以前のリクエストと同様にデータをリークする可能性があることも実証されています。

66
Lekensteyn

これをテストするためにMetasploitモジュールを作成しました、現在レビュー中ですが、比較的すぐにマスターブランチにヒットするはずです。この時点で、最初のバージョンはmasterブランチにマージされます。

https://github.com/rapid7/metasploit-framework/blob/38a2614fbee1851252462c858057738c06a9f2ab/modules/auxiliary/server/openssl_heartbeat_client_memory.rb

サーバー側の攻撃とは異なり、ハートビート応答はSSLセッションキーに対して暗号化されるため、ほとんどのTLSを実装する必要があります。 wget、curl、opensslコマンドラインでテストしました。興味深い一口は、wgetおよびopenssl（1）に対して、証明書の検証に関係なく攻撃が成功することです。 curlバイナリは、攻撃が機能するのに十分な時間セッションを開いたままにしておくために-kまたは有効な証明書を必要とします。これらの比較的総合的なテストに対して、TLSセッションキー（AES-128-CBC）を確実に漏洩する可能性がありますが、サーバーはハンドシェイク中に同じキーを知っているため、これはあまり提供しません。

EDIT1：ペースメーカーコードが完全なTLSハンドシェイクを行わずにこれを達成しているように見えます（さらに優れています！）。実装の間に人々が持つ可能性のあるテスト結果に興味があります。 IOW、ペースメーカーは、自己署名証明書が原因でクライアントが切断する場合に成功しますか？

EDIT2：@Lekensteynがペースメーカーで使用する方法（サーバーHelloの後にハートビートを送信）は、CA検証が問題ではないため、より良いアプローチです。デフォルトでこのモードになり、NEGOTIATE_TLSオプションを使用してTLSネゴシエーションコードパスを保持する新しいMetasploit PRを送信しました（古いモードではNEGOTIATE_TLSをtrueに設定します）。 @Lekensteynへの小道具！

26
HD Moore

クライアントのバグを悪用することは可能です。 このテスター を使用して、任意のクライアントに「悪意のある」URLを配布し、餌をとるかどうかを確認できます。 2014-04-09の時点で脆弱なクライアントを使用してURLをフェッチする上位100のWebサイト（ここでは名前を付けません）を3つ見つけました。

8
Brad

Androidデバイスをお持ちの場合は、次のように、脆弱性をテストするHeartbleedアプリの1つをインストールできます。

https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector

私はこれを2つのAndroid電話、4.3と4.4の両方の電話でテストしました。どちらも脆弱性があると報告されていますが、どちらのOpenSSLも使用されていないため、すべて良好です。..

Everything is OK!

だからすべてがOKです。それでは、OpenSSLを使用しているアプリはありません。しかし、それを使用するアプリをインストールするとどうなりますか？通知されますか？違いますね！

4.4の電話はソニーの新品で、最初に使用した後にシステムアップデートをダウンロードしましたが、これは修正するのに十分重要ではないと思いますか？！

0
SPRBRN