填充Oracle攻擊可能總是200 OK響應

Question

我目前執行ASP.NET應用程序的滲透測試並試圖利用Padding Oracle Attack。該AFAIK基於響應代碼分析，但被測系統的ScriptResource和WebResource axds始終以200 OK響應，即使密碼無效。但是，在這種情況下，響應的內容是空字符串。

在這種情況下是否可以使用任何axd作爲oracle？也許是基於響應內容的差異。

Answer 1

的填充甲骨文攻擊的原理是能兩種情況之間進行區分：

• 服務器無法對數據進行解密，因爲解密時，它沒有找到一個正確的格式填充。
• 服務器找到了正確的填充，但解密後的數據竟然是隨機垃圾。

攻擊者可能會通過多種方式獲得這樣的區別。來自服務器的特定錯誤代碼是最容易被利用的;但任何可檢測到的差異就足夠了。攻擊是第一次published in 2002（是的，人們注意到它可以應用於ASP 8年！），並且已經證明SSL連接僅具有時間差異：服務器正在解密數據，並且那麼只有在解密工作正常的情況下才能驗證MAC; MAC計算所花費的額外2ms足以讓攻擊者知道填充是否有效，從而可以直接應用Padding Oracle Attack。

Answer 2

這聽起來像填充甲骨文補丁可能已經安裝，因此你沒有得到你所期待的錯誤代碼。看看Do you trust your hosting provider and have they really installed the padding oracle patch，看看你是否可以建立這個。

Answer 3

要回答您的原始問題，可以使用內容長度。 Padbuster記錄了狀態碼，但我認爲它可以完全檢測響應長度。

要回答您對特洛伊的回覆，長長的密文長度並不表示他們是脆弱的。通常情況下，短密文長度確實表明他們是脆弱的，但你需要點淨網址解碼值，然後看看模數8 = 0，看看它是否易受攻擊。換句話說，長度將是8的倍數。通常我會看到一個密文塊（16字節）一旦被點網址編碼就會結束約25個字節。該修復包括一個HMAC（我認爲），它延長了長度，並應該使一個塊的cipertexts不可能。我不能肯定地說這一點，因爲我不確定HMAC有多長時間，以及它是否在填充後工作。