Shiro Padding Oracle Attack 反序列化
基础
参考ctfwiki中对CBC模式的介绍，先看一下CBC模式下的加解密模式图：
简单概括一下，加密过程初始化向量IV和第一组明文进行异或，然后经过加密算法得到第一组密文，并拿它作为下一分组加密的IV向量，迭代下去。解密过程反之，先解密再和IV向量异或得到明文plaintext。这里的IV参数是一个随机值(长度和分组长度等长)，为了保证多次加密相同数据生成的密文不同而设计的。
为了方便后文描述，将IV和Planttext异或后的值称为中间intermediary Value。
分组的填充padding分组的长度，不同加密算法的长度如下图所示：
分组密码(block cipher)需要保证总长度是分组长度的整数倍，但一般在最后一组会出现长度不够分组长度的情况，这时候就需要使用padding填充，填充的规则是在最后填充一个固定的值，值的大小为填充的字节总数，即需最后还差2个字节，则填充两个0x02。下边8个字节的填充范围为0x01-0x08。
这种Padding原则遵循的是常见的PKCS#5标准。http://www.di-mgt.com.au/cryptopad.html#PKCS5
Padding Oracle Attack
利用条件
攻击者知道密文和初始向量IV
padding错误和padding正确服务器可返回不一样的状态
攻击效果正常CBC解密需要知道IV、Key、密文，而通过Padding Oracle漏洞，只用知道IV、密文即可获得明文。
demo
以这样一个程序为例：
http://sampleapp/home.jsp?UID=0000000000000000EFC2807233F9D7C097116BB33E813C5E
前16个字母(8字节)0000000000000000为IV，后32字母(16字节)为密文：
padding 0x01通常程序校验padding是否正确是通过检查末尾的那个字节的值，我们可以通过修改IV的值使得其与中间量intermediary Value异或得到的结果(plaintext)最后一个字节(填充位)为0x01。
实现这样一个穷举的过程，需要改变IV的最后一个字节(最多255次)，且需要服务端将判断padding校验的结果返回给客户端(类似于布尔注入的逻辑)。比如在web应用中，padding正确(解密的内容不正确)返回200，padding错误(解密内容错误)返回500。
至此通过上述步骤，我们可以通过IV(fuzz出的IV)和0x01异或得到intermediary Value中间值。
在单个分组的情况下，其实我们拿着intermediary Value和初始向量IV异或，即可拿到最后明文的最后一个字节：
padding 0x02此时，通过修改IV第八个字节的值使得最后一个padding位变成0x02(上图中0x67^0x02=0×64)，再fuzz IV第七个字节，使得服务端解出plaintext其填充位为0x02，以此类推。
总的来说，其实攻击的本质都是为了得到中间临时变量intermediary value，通过其和初始IV计算出明文。
多分组密文情况上面说到的Padding Oracle Attack是以单个分组进行的，如果密文有多个分组，其最大的区别在于这一分组加密的初始IV向量为上次组加密的结果Ciphertext。
在多分组密文中，由于密文和IV已知且可控，先拿第一组padding的方式爆破IV推算intermediary value，然后根据原始IV计算出明文，也可以通过修改原始IV控制密文结果；再拿第一二组，用padding的方式爆破intermediary value，此时的初始IV为第一组的密文，以此类推。
防御
漏洞的关键点在于攻击者能够判断其padding的结果，在使用CBC模式的分组加密算法需要注意这一点，比如让服务端加上异常处理等等。
实验代码：Demo
CBC字节反转
在乌云知识库里有一篇文章的例子说的比较清晰：CBC字节翻转攻击-101Approach，再来参考ctfwiki中对CBC模式的介绍：
简单来说，通过构造第n的密文块为C(n) xor P(n+1) xor A，使得第n+1密文块为A(个人觉得CTFWiki这里写错了)，为什么呢？
C(n) xor P(n+1)的结果实际上就是第n+1组的intermediary value，在解密时让intermediary value自己异或自己得全0，然后再异或A得A。如下图所示：
简而言之，通过损坏密文字节来改变明文字节，攻击条件为知道一组明文和密文。
CVE-2016-4437: Shiro 反序列化(Shiro