asp.net - 常に200OKの応答でOracle攻撃のパディングは可能ですか

Question

私は現在、ASP.NETアプリケーションの侵入テストを実行し、PaddingOracleAttackを悪用しようとしています。このAFAIKは応答コード分析に基づいていますが、テスト対象のシステムのScriptResource軸とWebResource軸はどちらも、暗号が無効であっても、常に200OKで応答します。ただし、この場合、応答の内容は空の文字列です。

この場合、任意のaxdをオラクルとして使用することは可能ですか？たぶん、応答内容の違いに基づいています。

Answer 1

パディングOracle攻撃は、次の2つのケースを区別できるようにすることで機能します。

• サーバーは、復号化時に適切にフォーマットされたパディングが見つからなかったため、データの復号化に失敗しました。
• サーバーは正しいパディングを検出しましたが、復号化されたデータはランダムなジャンクであることが判明しました。

攻撃者がそのような区別を得るには、いくつかの方法があります。サーバーからの特定のエラーコードは、悪用するのが最も簡単です。しかし、検出可能な違いで十分です。この攻撃は2002年に最初に公開され（そうです、ASPに適用できることに気付くのに8年かかりました！）、タイミングの違いだけでSSL接続で実証されました：サーバーがデータを復号化し、次に、復号化が正常に行われた場合にのみMACを検証していました。攻撃者は、MAC計算に2ミリ秒かかるだけで、パディングが有効かどうかを知ることができ、パディングOracle攻撃を直接適用できます。

Answer 2

元の質問に答えるために、コンテンツの長さを使用できます。Padbusterはステータスコードを記録しますが、応答の長さを完全に検出していると思います。

トロイへの返信に答えるために、長い暗号文の長さは、それらが脆弱であることを示していません。通常、暗号文の長さが短い場合は脆弱であることを示していますが、値をドットネットURLデコードしてから、モジュラス8=0かどうかを確認して脆弱かどうかを確認する必要があります。つまり、長さは8の倍数になります。通常、ドットネットURLエンコードされると、暗号文の1つのブロック（16バイト）が約25バイトになります。修正にはHMAC（私は思う）が含まれています。これは長さを延長し、1ブロックのcipertextを不可能にするはずです。HMACの長さや、パディング後に機能するかどうかがわからないため、これを確実に言うことはできません。

Answer 3

パディングオラクルパッチがインストールされている可能性があり、その結果、期待したエラーコードが表示されないようです。あなたはあなたのホスティングプロバイダーを信頼し、彼らが本当にパディングオラクルパッチをインストールしているかどうかを見て、あなたがこれを確立できるかどうか見てください。