摘要:[ASP.NET] 了解Padding Oracle Attacks的細節 (二)
接續上次提到的塞值方式和CBC加密傳送模式，接下來再讓我們看看解密的過程。
首先，我們得先了解主機接收的加密資訊長什麼樣? 使用CBC模式加密因為需要IV來當一個引子，這個IV通常都是隨機產生或是用Timestamp的方式，其目的就是為了不讓IV有重複使用的機會進而增加密文被破解的風險。就因為IV的資訊通常不帶有機密資訊，所以並不會有特殊的保護機制。當我們把資訊加密好準備傳送後，我們需要把IV放在最前頭，緊接著是第一塊密文，第二塊．．．到最後一塊密文。
主機在收到密文時就會開始做解密的動作，在這邊我們要注意一點，因為主機使用CBC模式，所以當主機收到加密資訊時，第一塊資訊會被用來當作IV來跟解密後的第二塊的密文做xor的處理，同理第二塊的密文會跟解密後的第三塊密文做xor的處理才得到明文。在下圖裡需要注意的第二點，就是當主機解密後得到的並不是明文喔，而是所謂的中介值(Intermediary Value)，這個中介值必須跟前一塊的資訊做xor的處理以後，主機才能順利得到明文。
講解完主機所接收的資訊長什麼樣，以及主機如何解密的步驟後，接下來我們就要來猜密碼了。先解設我們要加密的明文是BRAIN;12;2，而且假設我們是用querystring的方式來傳送這串密文，看起來就像下圖：
從圖裡我們可以知道IV=7B216A634951170F，而緊接著就是第一塊的密文F851D6CC68FC9537。我們的目的是猜F851D6CC68FC9537解完密的內容，並且從最後一個byte猜起，第一個步驟是先把原本的IV替換成Null值，這時候我們的整串密文會變成如上圖的底部所示。當主機收到我們所傳的IV(空值)和原本的密文時，這時候主機會開始利用金鑰做解密的動作，當主機解完密後第一件事情就是先檢查明文的塞值是否正確，第一篇有提到主機所預期有效的塞值是在0x01-0x08之間，所以當主機解密完發現最後一個塞值是0x3D，並不符合他要的特徵，這時候主機會回傳一個HTTP 500的錯誤訊息給我們，因為最後一個byte的值並不是預期的0x01。當我們知道我們所寄送的密文並不正確時，很簡單，我們把最後一個byte增加1，變成0x01再寄給主機並且等待回覆，相信接下來的過程大家就有個底了吧? 沒錯，我們就是利用主機會回覆所收到密文塞值正確與否的訊息，來不斷變換我們的IV。猜中一個byte只需要1/256的機會，因為一個byte是八個bits，所以共有2的八次方的可能性。
很快地，當我們猜到IV的第八個byte為0x3C時，我們從主機端得到了一個HTTP 200 OK的回覆，這時候我們知道當IV的第八個byte為0x3C時，主機解密完的明文經過xor的動作後一定是0x01，這時候重點來了，一旦我們知道了IV和明文，我們就可以利用反推的方式得到一個中介值(Intermediary Value)，打開附屬應用程式裡的計算機，開啟科學模式，把0x01 xor 0x3C，我們就得到0x3D的中介值了。從下圖我們可以看到，這個中介值是主機用金鑰解密後所產生的，而我們利用這種變換IV的方式，也可以不用破解金鑰就得到解密後的資訊。
在我們知道密文第八個byte的中介值時，現在要來開始猜密文第七個byte的中介值。而且我們知道，我們必須使第密文七個byte解密並經過xor的動作後會輸出0x02的塞值，主機才會回覆HTTP 200 OK的正確訊息給我們。跟之前的步驟類似，我們可以利用不斷變換IV的第七個byte直到我們收到主機的正確訊息為止。但是有人會問，那我們怎麼樣才先可以固定IV的第八個byte使其解密後的塞值也是正確的呢? 很簡單
，一樣利用反推法，我們知道第八個byte解密後經過xor必須為0x02，由前一個步驟我們已得知第八個byte的中介值為0x3D，這時候IV = 0x3D xor 0x02 = 0x3F。接下來我們只要先把IV的第八個byte固定為0x3F，就可以開始猜密文第七個byte的中介值了。
很快的我們知道當IV的第七個byte為0x24時，我們會得到正確的塞值(0x02)，在反推回去，我們就得到密文第七個byte的中介值0x26。
利用上述固定IV的步驟來求密文的中介值，我們就會得到整個密文區塊的中介值如下圖。
最後還記得主機解密的步驟嗎?主機先收到IV和密文後利用金鑰解開密文得到一串中介值，再利用密文前面的IV來做xor的動作後就可得到明文了。同理，當我們猜到所有中介值後，要先把原本我們用Null值抽換掉的原始IV來做xor的動作，這樣是不是不用金鑰就可解開密文了呢?
