摘要:[ASP.NET] 了解Padding Oracle Attacks的細節(一)
這是小弟最近學習DotNET的第一篇文章，希望以後還有很多東西能夠再提出分享。另外本篇文章主題尚未完結，將會陸陸續續在這幾天分成幾篇來做介紹。
從9月17號微軟公佈ASP.NET的漏洞以來，陸陸續續讀了國內外很多篇介紹該漏洞理論的文章和防範主機被此漏洞攻擊的機制，當大部分的文章在強烈建議使用微軟的暫時解決方案外，較少看到有稍微深入分析該漏洞的文章，最近拜讀了Brian Holyfield在這裡所發表的文章後有了更深入的了解，在此和各位做個簡單的分享。
首先，Padding Oracle Attacks到底是什麼呢？我們先從字面上來了解一下該字的原意:
- Padding: 指的是填充、塞值的意思，加密時以演算法會以8或16(以上)的bytes為一區塊做加密,當所需加密的內容不到八個bytes時，演算法會自動塞值(padding)到滿8個bytes時才做加密的動作。這裡的區塊大小是以金鑰(Key)值長度來決定，現今大部分常見的AES加密金鑰長度有128、192、甚至256bits(相當於16、24、32bytes)，以下文章均以8 bytes做解釋。我們知道Padding的意義後，就來看圖吧。從下圖我們可以看到演算法替我們所塞的值的尾數會等於空格的數量，比方說當我們有FIG三個字母時，演算法會自動幫我們加上五個0x05的值。
- Oracle: 相信大家都看過駭客任務系列的電影吧，當裡面的男主角有所困惑時，他會跑去找裡面一個名為Oracle的老婆婆，這位老婆婆會適時回答男主角的問題，而"回覆訊息"這項重要的特質，就是此次使用ASP.NET或JSF技術的網站主機所扮演的腳色，當主機收到加密訊息時會回覆攻擊方兩種錯誤訊息:
- HTTP 200 OK: 這個訊息告知攻擊方你的密文塞值方式是正確的，解密後的明文也如預期般正確(例:帳密皆吻合)
- HTTP 200 OK: 這個訊息告知攻擊方你的密文塞值是方式正確的，解密後的明文不如預期(例:帳密不吻合)
- HTTP 500 Error: 這個訊息告知攻擊方你的密文塞值方式是錯誤的
在解釋完Padding和Oracle後，我們還需要知道什麼是Cipher Block Chaining(密文區塊連結)，其實CBC是傳送密文的一種方式之一，很多加密演算法都選擇CBC為其Operation Mode，因為如果以傳統的方式傳送密文區塊，在兩個加密內容為相同時，這兩個區塊用同一把金鑰加密後會產生相同的輸出值。為了避免這種情形發生，CBC模式使用了一個名為Initialization Vector(IV)的初始陣列值，就是為了確保讓兩個同樣內容的區塊加密後可以產生不同的輸出值，我們再來看圖吧。
從上圖我們可看出當第一個區塊要加密時會先跟IV做XOR的動作後再加密，而且輸出的值C1會跟第二區塊的明文先做XOR的動作再做加密產生C2密文區塊。那當我們解密時，把流程倒過來看會知道，當我們解密C3後會需要前一塊的密文也就是C2當作IV值來做XOR的動作才得到明文，同理，解C2需C1，解C1需IV。