ロードバランサーの後で、CVE-2015-4852をWebLogicサーバーに対して悪用できますか？
私はJavaロードバランサの後にあるOracle WebLogicサーバーによって提供されるアプリケーションです。WebLogict3プロトコル（脆弱）はWebLogicサーバーにトンネルされず、HTTPリクエストのみがトンネルされます。
このシナリオでは、CVE-2015-4852（Javaシリアライゼーション/デシリアライゼーションの脆弱性）を使用して、WebLogicサーバーによるJavaアプリケーションサーバーが悪用される可能性がありますか？
脆弱性は重要です（事前認証RCE）。あなたはここでより多くの情報を見つけることができます：
では、要点を説明しましょう：脆弱性CVE-2015-4852はT3プロトコルに関するものではありません。問題は、WebLogicが使用するシリアライゼーション/デシリアライゼーションルーチンと、Javaクラスパスを構成する基礎となるライブラリにあります。
したがって、いくつかのポイントを明確にするために：
- T3プロトコルは、ユーザー提供のシリアル化されたデータへの入り口であるため、引用されています。
- 影響を受けるApache Commonsライブラリにバンドルされており、WebLogicの実行時にクラスパスにロードされるため、WebLogicが引用されています。影響を受けるバンドルライブラリも更新できるように、更新する必要があります。または、自分で更新することもできます。
- 実際の問題は、Apache Commonsライブラリ自体にあります。
したがって、質問に答えて、はい、攻撃者がシリアル化された悪意のあるデータを入力する他の場所を見つけることができる場合、アプリケーションは逆シリアル化の脆弱性の影響を受ける可能性があります。一部のJavaアプリケーションはシリアル化に依存します重い。それらの多くまた、base64でエンコードされたHTTP/S接続を介して、または他のタイプのエンコーディングで送信します。Java JSPアプリケーションもビューステートを使用します（base64も使用しますが、異なる構造を使用しています） ASP.NET Viewstatesから）。
OracleのHCM（Human Capital Management）モジュールがbase64でエンコードされたシリアル化を使用してページタイトルを定義するのを見たことさえあります（そうです、私はそれを好きなように変更することができましたが、調べた時点ではあまりありませんでしたデシリアライゼーションの欠陥の内部動作を認識している）
UPDATE：
この問題にはいくつかの進展がありました。このCVE自体にはありませんが、シリアライゼーション/デシリアライゼーションの問題全体に対して脆弱なライブラリが非常に多い（非常に一般的なライブラリも）ことを知っている人もいます。
http://www.theregister.co.uk/2015/12/07/Java_deserialization_research_library_vulnerable/
ここで言及されている脆弱性についての私の理解から https://stackoverflow.com/questions/33679614/cve-2015-4852-evaluating-apps-for-vunerability 、ObjectStream.readObjectに到達できる場合（）Java=アプリケーションの場合、これを悪用することは可能です。そのため、URLがexample.com/sampleであり、サンプルがロードバランサーに http ：// Host1：9003/sample 、Host1ではなくexample.comにアクセスするユーザーは、weblogicの観点から安全でなければなりません。
あなたが心配する必要があるのは、ロードバランサーがt3接続を許可するかどうかだけだと思います。その場合は、ブロックするように要求してください。 Oracleのドキュメント（Doc ID 2076338.1）が示唆しているように、t3アクセスをブロックすれば問題ありません。
シリアル化されたデータがアプリケーションに到達できる場合のみ、（「脆弱」とは異なり）悪用可能です。この場合、T3トラフィックが通過しない場合、いいえ、この方法で悪用されることはありません。
ただし、ユーザーが制御するシリアル化されたデータが受信される他の場所も同様に脆弱であり、これはhttp経由で発生する可能性があります。
CVE-2015-4852はOracle WebLogicソフトウェアの特定の脆弱性です。 t3プロトコルは、潜在的な攻撃者から信頼できないシリアル化されたオブジェクトを受け取る可能性があるため、脆弱であることが発見されました。 t3プロトコルがロードバランサーからトンネリングされていない場合、悪意のあるトラフィックはWeblogicポータルに渡されませんこの場合の脅威を防ぎます。
ただし、serialize/deserialize脆弱性は脆弱性の完全なカテゴリです。 Oracle WebLogicソフトウェアの他のコンポーネントは、t3プロトコルだけでなく脆弱である可能性があります。事実、WebLogicの他のコンポーネントが脆弱であると確認されていないことです。
一方、標準またはカスタムJava Oracle WebLogicサーバー（または他のアプリケーションサーバー）によって提供されるアプリケーション）は、脆弱性のシリアライズ/デシリアライズに対して脆弱である可能性があります。シリアル化されたオブジェクトをHTTP経由で渡すことが頻繁にありますが、それらをヘッダー、Cookieに含めたり、データを投稿または取得したりすることが可能な場合があります。
アプリケーションが脆弱かどうかを知るための推奨される方法は次のとおりです。
- アプリケーションディレクトリに移動
- grep -R InvokerTransformer。
- トラフィックを傍受または傍受し、ユーザーからアプリケーションへのシリアル化されたオブジェクトを探します。
- rO0AB（base64）
- ac ed 00 05（16進数）
- 特定の概念実証を作成して確認する
危険なreadObject（）呼び出しを悪用する他の方法がInvokerTransformerを使用せずに発見される可能性があるのように、これはこの種の脆弱性を見つけるための典型的な方法ではありません。