ECB模式利用與CBC翻轉攻擊
前言
最近看WEB安全，其中講到cookie操縱的時候， 提到ECB與CBC加密模式的利用，實際操作了一下，記錄一下。
ECB缺陷
ECB加密過程:
從圖中可以看出加密過程，是明文分組後，每個分組被分別加密，所以明文相同的兩個分組，被加密出來的密文分組也是一樣的。換句話說，這種加密方式，沒法完全隱藏明文信息。
常見的一種利用方式，就是構造分組，獲取想要的明文對應的密文。
一種典型的場景，假如某系統用戶名使用ECB模式加密，我們想獲取用戶A（假設A對應一個分組，簡化理解，多個分組同理）的權限，就得設法構造A加密後的密文，但是我們又無法再次註冊一個A用戶。這種情況下，我們註冊一個(PAD)A的用戶,(PAD)就是一個分組填充，如8字節或16字節，依據加密算法而定，具體需要嘗試。這樣就會得到(PAD)A的密文，而該密文對應的最後一個分組，就是A對應的密文。
使用AES ECB 16字節分組, KEY=“8765432187654321”字節一個分組加密，測試結果如下:
明文: admin
密文：B9CB9D5D68EF28B73A1404AD23B15C03
明文: xxxxxxxxxxxxxxxxadmin
密文: 176EF38A69F2AF33430D9EFD39ED5737【B9CB9D5D68EF28B73A1404AD23B15C03】
(【】爲標註使用，並非密文結果)
從上面測試結果可以看出，最後一個分組(16字節)完全一致。
CBC翻轉攻擊
CBC的解密過程：
從解密過程可以看出，CBC的解密依賴前一個分組的密文作爲IV與中間結果異或， 這個增加了複雜度，但是從另一個方面也可以看出，也可以通過修改前一個密文值來得到想要的明文。原理即是利用異或的特性，兩個相同值異或，結果爲0。
異或特性：0 ^ b = b ; a ^ a = 0 ; a ^ a ^ b = b;
假設當前CBC分組爲第i個分組，則cipher爲對應的分組密文，plain爲明文，inter爲中間值, 以修改第i個分組第j個字節爲pseduo_char爲例。則過程如下：
【1】inter[i] = cipher[i] decrypt
【2】plain[i] = inter[i] ^ cipher[i-1]
【3】plain[i][j] = inter[i][j] ^ cipher[i-1][j] #第j個字節
【4】0 = inter[i][j] ^ cipher[i-1][j] ^ plain[i][j]
【5】pseudo_char = inter[i][j] ^ cipher[i-1][j] ^ plain[i][j] ^ pseudo_char
所以，若修改前一個密文分組第j個字節：
pseudo_cipher[i-1][j] = cipher[i-1][j] ^ plain[i][j] ^ pseudo_char
則由式【3】【5】可以得出
plain[i][j] = inter[i][j] ^ pseudo_cipher[i-1][j] = pseudo_char
即可以得到想要的值。
根據上面的推導，對多個字節可以使用同樣的方式進行修改。若是第0個分組，則cipher替換爲iv即可。(大部分使用場景中，iv是附加在密文前面傳輸的)
使用DES CBC 8字節，KEY="87654321", IV="87654321"，試驗從xxxxxxxxadmix得到xxxxxxxxadmin.過程如下：
明文: xxxxxxxxadmin
密文:919B08D902104B8809620E369EC30477
明文: xxxxxxxxadmix
密文:919B08D902104B88899829F860AF29EA
修改後的密文:919B08D914104B88899829F860AF29EA
解密後的明文: +~@2Padmin
修改後的IV:6B310E7F5C494119
再次解密後的明文: xxxxxxxxadmin
該使用場景也適用於上節ECB的場景，操縱cookie越權之類的。
因爲該方式是以損壞前一個分組密文爲前提，所以存在僞造的密文在解密過程中出現pad error或其它不能解密的情況。
總結
從上面的試驗可以看出，ECB貌似很不安全，即使不用上面說的方式來做，通過多份數據比較，可能也能獲取一定的信息；而CBC好像問題也挺多，本文講的是構造密文得到想要的明文，而之前寫的一篇Padding Oracle則可以在不需要祕鑰的情況下獲取明文，感覺也是篩子。。。當然，這些都是實驗場景，實際運用肯定要複雜的多，比如確定加密方式(最近看一道CTF的加密題有感)。。。
附錄: