POODLE漏洞分析
一、漏洞背景
10月14號由Google發現的POODLE漏洞(Padding Oracle On Downloaded Legacy Encryption vulnerability)，可被攻擊者用來竊取采用SSL3.0版加密通信過程中的內容，又被稱為“貴賓犬攻擊”。雖然該攻擊利用有一定的難度，需要完全控制網絡流量，但在公共wifi遍地都是和強調國家之間對抗的APT背景下，該漏洞仍有不小的影響，我們的小伙伴也緊急分析了漏洞原理，poc仍在驗證中，稍后放出。
二、SSLv3.0協議基礎
協議協商數據
在協議握手階段，協商的數據包括：
明文/密文分組長度：長度一般為16字節。
初始化向量IV：根據SSLv3.0協議定義的算法生成，要求隨機性較高，與明文/密文分組長度相同(16字節)。
對稱密鑰Key：即SSLv3.0協議中定義的主密鑰(the Master Secret)，用于數據加密。
加密模式：常見的加密模式有多種，本漏洞本質就是SSLv3.0協議推薦的CBC加密模式可能泄露信息。
數據填充與分組
明文加密之前和密文解密之前需要分組，每個分組長度為128比特，即16字節。
對于待加密的明文數據，分組處理過程為：
(1)計算明文簽名MAC(Message Authentication Code，消息驗證碼)序列，長度為20字節。
(2)將MAC序列附在明文數據之后組成平文(Plaintext)，將Plaintext的長度填充至16字節的整數倍。
填充方式為：如果原始Plaintext長度不是16字節的整數倍，再其后附加零個、一個或多個Padding字節，再附加1個字節，其值為Padding長度;如果原始Plaintext長度正好是16字節的整數倍，則在其后附加15字節長度的Padding序列，再附加1個Padding長度，其值為15。
(3)將填充后Plaintext每16字節分為一組，稱為平文塊(Plaintext Block)，使用符號P1 , P2 … Pn 表示。
初始化向量IV用于首次加密，此時使用P0表示。
對于待解密的密文數據，由于數據長度肯定為16字節的整數倍，所以其直接按照16字節長度分組，每個分組稱為密文塊(Cipher Block)，使用符號C1 , C2 … Cn表示。
初始化向量IV用于首次解密，此時使用C0表示。
CBC模式原理
在CBC模式中，每個平文塊(Plaintext Block，即明文分組塊)先與前一個密文塊(Cipher Block)進行異或后，再進行加密。在這種方法中，每個密文塊都依賴于它前面的所有平文塊。同時，為了保證每條消息的唯一性，在加解密過程初期需要使用初始化向量IV。
基于CBC加密模式的對稱加密流程如下圖：
即，對于每一個平文塊Pi，得到密文塊Ci：
換個角度考慮，平文中的微小改變會導致其后的全部密文塊發生改變。
基于CBC加密模式的對稱加密流程如下圖：
即，對于每一個密文塊Ci，得到平文塊Pi：
因此，如果密文塊Ci被修改，不會影響對密文塊Ci-1的解密結果，而Ci及Ci之后的解密結果Pi’，Pi+1’ … Pn’ 將與原始的Pi，Pi+1 … Pn不同。
從密文得到平文后，服務端會立即驗證明文的MAC以確保數據有效性，根據前述的平文填充方式，SSLv3.0協議定義的驗證原理為：
(1)根據平文數據最后一個字節的得到Padding序列長度，移除該字節以及Padding序列后，平文的最后20字節數據是客戶端計算得到的MAC序列。
(2)移除該MAC序列得到的數據是明文數據，服務端重新計算該段數據的MAC序列并與客戶端MAC序列對比，即可確定數據是否有效。
三、POODLE漏洞分析
根據之前所述，如果明文數據的長度加20字節的MAC序列長度正好為16字節的整數倍，平文Padding算法會在Plaintext的最后附加15字節的Padding序列和1字節的Padding序列長度(值15)，即最終的平文的最后16字節屬于附加部分，加密后對應密文分組的最后一個密文塊Cn。該在這種情況下，如果使用密文中的某一個密文塊Ci替換密文塊Cn并發送給服務端，服務端有可能認為數據是有效的，滿足這種可能性必須要求解密后的數據最后一個字節值是15，這樣恰好既不影響原始明文序列，也不影響MAC序列，從而通過服務端對MAC序列的驗證。
定義密鑰為k的對稱加密算法的加密過程和解密過程分別為Dk( )和Ek( )。
此時：
Pn’= Dk(Cn’)⊕Cn-1 = Dk(Ci)⊕Cn-1
且
Pn’[15] = 15
即：
Dk(Ci)[15]⊕Cn-1 [15]= 15
由于：
Pi[15] = Dk(Ci)[15]⊕Ci-1[15]
所以：
Pi[15] = 15⊕Cn-1 [15]⊕Ci-1[15]
很明顯，此時密文塊Ci對應的平文塊Pi的最后一個字節可以通過計算得到。
四、POODLE漏洞利用
到此，在前述假定的條件下僅僅解密一個字節的數據并無任何實際意義，然而，Google安全研究員在其發布的分析報告This POODLE Bites: Exploiting The SSL 3.0 Fallback 中考慮了這樣一個針對HTTPS協議的攻擊場景：
(1)攻擊者可以實施中間人攻擊，控制用戶流量以及控制客戶端發送AJAX請求;
(2)攻擊者的目標是獲取用戶的cookies;
(3)攻擊者已經知道cookies數據長度。
對于(3)條假設并不一定完全成立，這里首先假定在其成立的條件下考慮POODLE漏洞的利用方式。
假設請求明文的Plaintext如下：
POST /path Cookie:…\r\n\r\nbody ‖ 20bytes-MAC ‖ 15-bytes-padding || 15
攻擊者可以控制path和body的長度使上述Plaintext的長度為16字節的整數倍，并且，由于已知cookies的長度，控制欲解密的cookies字節位于某個平文塊Pi的最后一個字節上。
首先，設置客戶端請求使P5[15] = ‘e’，請求加密前的Plaintext為：
圖 計算第一個數據
中間人截獲密文Ciphertext之后使用C5代替C11后傳遞請求，如果發現服務端解密后驗證失敗，控制客戶端變換請求的path內容再發送，一般經過不超過256次變換，可能會有一次使服務器解密后驗證成功，即中間人可以根據上面介紹過的方式計算得出該處明文字節數據。
然后，控制客戶端請求的path長度和body長度，比如path長度加1同時body長度減1：
圖 計算第二個數據
繼續發送請求、中間人攔截替換再發送等操作，依次可以分析出整個cookies數據。
在cookies長度不確定的情況下，可以通過控制增加客戶端的path長度并對比密文Ciphertext長度，基本在16個請求以內就可以確定其實際長度。比如：
第一次請求的Plaintext為：
GET /\r\nCookie: n1=v1\r\n\r\n || 20bytes-MAC ‖ padding
即：
圖 計算cookies長度的第一次Plaintext
此時，Ciphertext的總長度為48字節。
第二次請求的Plaintext為：
GET /A\r\nCookie: n1=v1\r\n\r\n || 20bytes-MAC ‖ padding
圖 計算cookies長度的第二次Plaintext
此時，Ciphertext的總長度為48字節。
第三次請求的Plaintext為：
GET /AA\r\nCookie: n1=v1\r\n\r\n || 20bytes-MAC ‖ padding
圖 計算cookies長度的第三次Plaintext
此時，Ciphertext的總長度為48字節。
第四次請求的Plaintext為：
GET /AAA\r\nCookie: n1=v1\r\n\r\n || 20bytes-MAC ‖ padding
圖 計算cookies長度的第四次Plaintext
此時，Ciphertext的總長度為48字節。
第五次請求的Plaintext為：
GET /AAAA\r\nCookie: n1=v1\r\n\r\n || 20bytes-MAC ‖ padding
圖 計算cookies長度的第五次Plaintext
此時，Ciphertext的總長度為64字節，從而知道第一次的Ciphertext的總Padding長度為4字節(3字節Padding序列和1字節的Padding序列長度)，而Ciphertext總長度為48字節，“GET /\r\n”序列長度7字節，MAC序列長度為20字節，所以“Cookie: n=v\r\n\r\n”長度為15字節。
參考：
[1] RFC6101： http://tools.ietf.org/html/rfc6101
[2] Google分析報告：https://www.openssl.org/~bodo/ssl-poodle.pdf
[3] 塊密碼的工作模式：
http://zh.wikipedia.org/wiki/%E5%9D%97%E5%AF%86%E7%A0%81%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%A8%A1%E5%BC%8F
