SSL / TLS再ネゴシエーションハンドシェイクMiTMプレーンテキストデータインジェクション-中リスクか低リスクか？
これはNessusの調査結果であり、デフォルトで中程度と見なされます。
基本的には、平凡な注入を可能にするかもしれません。
私の質問は、これらは実際に悪用されているのですか？それを利用するツールはありますか？クライアントに提供するレポートのリスクを完全に低くすることを考えていますが、続行する前にそうすることが理にかなっていることを確認したいと思います。
CVSSの評価では、なぜこの発見を中程度と見なすべきかについての議論はありますか？
この脆弱性は、次の状況で発生します。
- 攻撃者は MitM をネットワークレベルで実行できます（通常は DNSポイズニング を介して、または偽のオープンWiFiアクセスポイントを操作して）。
- WebサイトはHTTPSを介していくつかのサービスを提供しています。
- Webサイトの一部では、ユーザー認証が必要です。
- Webサーバーは、SSL/TLS再ネゴシエーションを受け入れます。
- Webサーバーは、以前の要求に認証を遡及的に適用する準備ができています。
最後のポイントが重要です。それを理解するために、攻撃がどのように進行するかを見てみましょう：
- クライアント（被害者）CはサーバーSに接続しようとしています。しかし、攻撃者AはTCPレベルで接続をインターセプトし、自分で応答します。
- クライアントCは、その
ClientHelloSSL/TLSメッセージを攻撃者に送信します。 - 攻撃者はクライアントとしてサーバーSに接続します。その後、攻撃者はサーバーとの通常のSSL/TLSハンドシェイクを実行します。
- 攻撃者はコマンドX（ユーザー認証を必要とする種類のコマンド）をサーバーSに挿入します。
- どういうわけか、再ネゴシエーションがトリガーされます。これは、すでに確立されているA-> S SSL接続内で実行される、メッセージを備えた新しいハンドシェイクです。
- その再ネゴシエーションの場合、攻撃者はクライアントC（まだ待機中）から
ClientHelloを送信し、クライアントとサーバーの間で後続のメッセージを転送します。ここでの巧妙なトリックは、ハンドシェイクはクライアントの観点からは最初のハンドシェイクですが、サーバーの観点からは再ネゴシエーションです。 - ハンドシェイク中または直後に、サーバーはクライアントを認証します。そして、どうにかして、サーバーは、同じクライアントとずっと話し続けていると想定し、再認証の前に受信したコマンドXにその認証を適用します。サーバーはクライアントCの名前でコマンドXを実行しますが、コマンドは攻撃者によって挿入されました。
これはどのようにして起こりますか？重要な点は、サーバーがコマンドXを、この時点では認証されていないクライアントから受信しますが、実行されないことです。すぐに。サーバーは再ネゴシエーションが発生するのを待ってから、ある種の認証を待機し、その後のみコマンドを処理します。 HTTPSリクエストでは、これはサーバーが再ネゴシエーション自体をトリガーし、2番目のハンドシェイクが認証を提供することを期待する場合にのみ現実的に起こります。これは、HTTPSの階層化された性質に関連しています。SSL内のHTTPであるため、SSLレベルで行われるすべての処理はHTTPレイヤーに対して透過的です。 HTTPリクエストXを受信すると、サーバーはすべてのSSLレベルのタスクが実行されるまで応答を遅らせます。
したがって、実際には、クライアント証明書を使用すると、このようなことが起こります。これは、Microsoft IISの典型的な動作方法です。
- クライアントがサーバーに接続します。最初のハンドシェイク中に、サーバーはサーバー名をクライアントがターゲットURLで（ サーバー名表示 拡張子を介して）認識しますが、URLは認識しません。サーバーはクライアント証明書を要求しません。
- 最初のハンドシェイクが完了すると、クライアントは実際のHTTP要求を送信します。その時点で、その時点でのみ、サーバーは完全なパスとパラメーターを使用してターゲットURLを学習します。サーバーは、要求が証明書ベースのクライアント認証を必要とするサイトの一部に対するものであることを認識します。
- リクエストに応答する前に、サーバーは再ネゴシエーションをトリガーします。今回は、サーバーがクライアント証明書を要求します。
- 2回目のハンドシェイクの後、サーバーは適切なクライアントと通信していることを認識し、HTTP要求を実行します。
IISは、完全なサーバーではなく、特定のパスでのみクライアント証明書を要求します。これは、主に、ユーザー証明書の選択のためにブラウザーによって提供されるユーザーインターフェイスが、見た目上最適ではないためです。実際、彼らは平均的なユーザーにとって実に恐ろしいです。ユーザー証明書はまれです。それらを使用するサーバーはほとんどありません。
したがって、TLS再ネゴシエーションの脆弱性が適用される唯一のもっともらしいシナリオは、クライアント証明書を必要とするWebサーバーであり、IISのように機能します。証明書ベースのクライアント認証を使用しない場合、この脆弱性は問題になりません（少なくとも、この脆弱性が利用されることはないと思います）。一方、クライアント証明書をdo使用する場合、この脆弱性は非常に深刻なものであり、悪用することは難しくありません（必要なのは 100 $デバイス ）。したがって、nessusなどのツールが自動的に推測できないシステムアーキテクチャの特性に応じて、関連するリスクは「なし」または「高」になります。次に、nessusは「中」で応答します。「中」は、この場合、実際には「依存」または「たぶん」です。
この脆弱性は、最初のハンドシェイクと再ネゴシエーションにまったく同じハンドシェイクメッセージが使用されるという事実に起因することに注意してください。その脆弱性の fix は、ClientHelloメッセージを「初期」または「再ネゴシエーション」として明確にマークする方法であり、サーバーが不正なプレイを検出できるようにします。ただし、クライアントとサーバーの両方がサポートしている場合にのみ機能し、サーバーは、その拡張をサポートしていないクライアントとの通信を拒否します。 Nessusは、サーバーが拡張機能をサポートしていないクライアントとの会話を受け入れ、したがって潜在的に脆弱であるとサーバーに通知しています（サーバーがIIS方法）。 トレードオフがあります。拡張サポートを適用することで、サーバーは保護を追加する場合がありますが、古いレガシーブラウザー（互換性がある場合があります）との互換性が失われます。または望ましいことではないかもしれません）。
概念的な観点から見ると、本当の問題は、SSL/TLS標準が再ネゴシエーションを記述しているが、それによって実際にどのセキュリティ特性が実現されるかを説明していないことです。 IIS誤って、遡及認証がこれらの特性の一部であると想定しました。
私の仮定は、これがこのCVEに関連しているということです。
[〜＃〜] cve [〜＃〜] および CVE Details
多くの組織がこの脆弱性の確認を公開しているため、悪用される可能性があります。メタスプロイトモジュールは見つかりませんでしたが、正当な攻撃者にとってはそれほど意味がありません。
これは2009年に遡ったため、最新のシステムのほとんどにはパッチが適用されています。これを中程度の脆弱性としてリストされていることをクライアントに伝えるのとは異なる方法でこれを提示しようとしますが、あなたはそれを低い脆弱性だと思います。
これは大した問題ではないという印象を与えないで、中程度の脆弱性として扱い（そして脆弱性が存在することを確認し）、クライアントの脅威を評価します。もし彼らが主にスキディからの脅威であれば、私はクライアントに低いことを知らせるのを見ることができます悪用されるリスクがありますが、クライアントが正当な人々に攻撃される可能性が実際にある場合は、そのままにしておきます。
最後に、私の経験では、クライアントは低リスクのアイテムをドラッグする傾向があります。これを低リスクのアイテムとして提示する場合は、更新が存在し、システムにパッチを適用する必要があることを強調します。