我对Padding Oracle Attack的分析和思考

时间 2019-11-10

标签 padding oracle attack 分析思考栏目 Oracle 繁體版

原文原文链接

道哥的《白帽子讲web安全》有一章提到Padding Oracle Attack的攻击方式，听说这货在2011年的Pwnie Rewards上还被评为"最具价值的服务器漏洞"。php

抱着书看了半天，感受也不是很理解，和密码学结合的比较紧，有一些理论的东西在里面。这里作个学习笔记，研究一下。html

1. 相关阅读材料python

https://github.com/GDSSecurity/PadBuster　　PadBuster - Automated script for performing Padding Oracle attacksgit

http://hi.baidu.com/aullik5/item/49ab45de982a67db251f40f6　　道哥的分析github

http://www.di-mgt.com.au/cryptopad.html　　Padding原则web

http://hi.baidu.com/306211321/item/faa44923c3c07d98b7326387　　分组密码的连接模式算法

http://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attacks-with-padbuster.html　　做者写的分析安全

http://www.cnblogs.com/JeffreyZhao/archive/2010/09/25/1834245.html　　老赵写的分析(和ASP.NET结合)服务器

http://www.isg.rhul.ac.uk/~kp/secretIV.pdf　　国外的牛牛写的分析(拓展Padding Oracle的知识面)cookie

http://www.icylife.net/yunshu/attachments/Padding-Oracle-Attack.pdf　　云舒写的分析

http://netifera.com/research/poet/PaddingOraclesEverywhereEkoparty2010.pdf　　EKOPARTY 2010的演讲PPT

http://netsecurity.51cto.com/art/201101/244089_1.htm　　51CT上看到的分析

2. 前引知识

2.1 分组的填充Padding

分组密码Block Cipher须要在加载前确保每一个每组的长度都是分组长度的整数倍。通常状况下，明文的最后一个分组颇有可能会出现长度不足分组的长度:

这个时候，广泛的作法是在最后一个分组后填充一个固定的值，这个值的大小为填充的字节总数。即假如最后还差3个字符，则填充0x03。

这种Padding原则遵循的是常见的PKCS#5标准。http://www.di-mgt.com.au/cryptopad.html#PKCS5

2.2 CBC(Cipher Block Chaining CBC)模式

这是一种分组连接模式，目的是为了使本来独立的分组密码加密过程造成迭代，使每次加密的结果影响到下一次加密。这行能够强化加密算法的"敏感性"，即实现所谓的"雪崩效应"，在香浓理论中这就是"扰乱原则"。

以前在《密码学》课后作的笔记:http://hi.baidu.com/306211321/item/faa44923c3c07d98b7326387

这里我我的感受要注意的一点是：

在连接模式中，初始化IV的长度要和对称加密算法的分组长度一致。缘由是连接模式中的异或操做是等长操做。

3. Padding Oracle Attack攻击的原理

由于Padding Oracle Attack是针对CBC连接模式的攻击，和具体的加密算法无关(分组)。因此这里咱们选择DES为例进行阐述。

假设明文为: LittleHann(明文长度为10 8 < 10 < 16 即便用2个分组)

通过DES加密(CBC模式)后，其密文为: EFC2807233F9D7C097116BB33E813C5E

加密程序: http://pan.baidu.com/s/1e2o7

密文采用了"ASCII十六进制的表示方法"，即两个字符表示一个字节的十六进制数。这是由于密码学算法中获得的密文常常会出现不可打印字符，为了保证在网络上传输的正确而不受不一样系统间编码方案的影响，就有必要对密文进行"可视化"转化(即转化成可打印字符)。除了"ASCII十六进制的表示方法"以外，还能够采用"base64编码方法"。

PS：

这里插个题外话：PHP的DES及其余密码学算法的加密是经过"PHP加密扩展库Mcrypt"来实现的。

http://www.php100.com/cover/php/2651.html

http://baike.baidu.com/link?url=U8OtBP-IcYLRGrfWpSNhHskzrnA0qPNTsIrgGZcZSjLTGBPfpEI35ry51JtAXFxVuVsXKBK_UUZoXbZWgM-xLK

整个加密过程以下:

初始化向量IV与明文(第一组明文)XOR后，再通过运算获得的结果做为新的IV，用于下一分组(分组2)，若是迭代下去。

解密过程是加密过程的逆过程:

这里要注意，前几个分组的解密结果对咱们都没有意义，咱们重点关注的是最后一个分组的解密结果。看这张图可能会清楚一点:

注意到最后一个分组的末尾的数值为0x04，即表示填充了4个Padding。若是最后的Padding不正确(值和数量不一致)，则解密程序每每会抛出异常(Padding Error)。而利用应用的错误回显，咱们就能够判断出Paddig是否正确。

这里有几个概念要先理清一下:

1. 基于密码学算法的攻击，每每第一个要搞清楚的是，咱们在攻击谁，或者准确的说咱们的攻击点在哪里？在一个密码学算法中，有不少的参数(指攻击者能够控制的参数)，攻击者每每是针对其中某一个或某一些参数进行破解，穷举等攻击。

在Padding Oracle Attack攻击中，攻击者输入的参数是IV+Cipher，咱们要经过对IV的"穷举"来请求服务器端对咱们指定的Cipher进行解密，并对返回的结果进行判断。

2. 和SQL注入中的Blind Inject思想相似。我以为Padding Oracle Attack也是利用了这个二值逻辑的推理原理，或者说这是一种"边信道攻击(Side channel attack)"。http://en.wikipedia.org/wiki/Side_channel_attack

这种漏洞不能算是密码学算法自己的漏洞，可是当这种算法在实际生产环境中使用不当就会形成问题。

和盲注同样，这种二值逻辑的推理关键是要找到一个"区分点"，即能被攻击者用来区分这个的输入是否达到了目的(在这里就是寻找正确的IV)。

好比在web应用中，若是Padding不正确，则应用程序极可能会返回500的错误(程序执行错误)；若是Padding正确，但解密出来的内容不正确，则可能会返回200的自定义错误(这只是业务上的规定)，因此，这种区别就能够成为一个二值逻辑的"注入点"。

3. 攻击成立的两个重要假设前提:

1. 攻击者可以得到密文（Ciphertext），以及附带在密文前面的IV（初始化向量）
2. 攻击者可以触发密文的解密过程，且可以知道密文的解密结果

4. 可能出现的状况

明文分组和填充就是Padding Oracle Attack的根源所在，可是这些须要一个前提，那就是应用程序对异常的处理。当提交的加密后的数据中出现错误的填充信息时，不够健壮的应用程序解密时报错，直接抛出"填充错误"异常信息(这个错误信息在不一样的应用中是不一样的体现，在web通常是报500错误)。

攻击者就是利用这个异常来作一些事情，假设有这样一个场景，一个WEB程序接受一个加密后的字符串做为参数，这个参数包含用户名、密码。参数加密使用的最安全的CBC模式，每个block有一个初始化向量IV(注意：这个IV在服务器第一次生成这个密文的时候就产生了，并保存在服务器上，攻击者须要在提交数据的时候也提交这个IV，后面咱们会看到，攻击者实际上就是在"穷举"这个IV)。

当提交参数时，服务端的返回结果会有下面3种状况：
a. 参数是一串正确的密文，分组、填充、加密都是对的(程序运行自己没出问题)，包含的内容也是正确的(业务逻辑是对的)，那么服务端解密、检测用户权限都没有问题，返回HTTP 200。
b. 参数是一串错误的密文，包含不正确的bit填充(程序运行自己出现致命错误)，那么服务端解密时就会抛出异常，返回HTTP 500 server error。
c. 参数是一串正确的密文(程序运行自己没出问题)，包含的用户名是错误的(业务逻辑是错的)，那么服务端解密以后检测权限不经过，可是依旧会返回HTTP 200戒者HTTP 302，而不是HTTP 500。

攻击者无需关心用户名是否正确，只须要提交错误的密文(由于这里有4中变量状况，为了构造出二值逻辑推理，咱们要定住其中2个状况，即让业务逻辑恒错，对Bit Padding的状况进行逻辑推理)，根据HTTP Code便可作出攻击。

咱们继续回到原理分析上来。

假设有这样一个应用 http://sampleapp/home.jsp?UID=0000000000000000EFC2807233F9D7C097116BB33E813C5E

(中间用箭头隔开了，前面的16个字母(即8字节 ASCII十六进制表示法两个字母为一个字节)为攻击者输入的IV。后面的32个字母(即16字节)为攻击者输入的密文)

咱们向服务器发送这样一个请求:

Request: http://sampleapp/home.jsp?UID=0000000000000000EFC2807233F9D7C097116BB33E813C5E

Respose: 500 - Internal Server Error

此时在解密时Padding是不正确的(填充的值和填充的数量不一致)

例如:

程序判断Padding是否出错通常是去检验末尾的那个字节的值，这里是0x3D，显然不对。这里咱们再次回忆一下Padding原则:

1个字节的Padding为0x01

2个字节的Padding为0x02

3个字节的Padding为0x03

4个字节的Padding为0x04

5个字节的Padding为0x05

6个字节的Padding为0x06

7个字节的Padding为0x07

8个字节的Padding为0x08(当原始的明文正好是分组的整数倍的时候，Padding一个整组的填充值)

也就是说，Padding的值只多是0x01~0x08之间。

接下来就是最关键的部分了，也是我一开始看比较难理解的地方。

咱们接下来要利用选择密文攻击的思想，不断调整，修正IV。来对Intermediary Value进行猜想。

1) Padding 0x01

咱们不断地调整IV的值，以但愿解密后，最后一个字节的值为正确的Padding Byte，这里是0x01。由于Intermediary Value是固定的(咱们此时不知道Intermediary Value)，所以从0x00~0xFF之间，只可能有一个IV的值与Intermediary Value的最后一个字节进行XOR后，结果是0x01(思考: 由于0x01只有最后1 bit为1，其余都是0，因此根据XOR的性质，只能存在一个值能XOR获得0x01)。攻击者经过遍历这255个值，能够找出IV须要的最后一个字节。

Request: http://sampleapp/home.jsp?UID=0000000000000066EFC2807233F9D7C097116BB33E813C5E

Respose: 200 OK

经过XOR运算，能够立刻推导出此Intermediary Byte的值:

if(Inermediary Byte) ^ 0x66  == 0x01
{
       Inermediary Byte = 0x66 ^ 0x01                 
}
so:
        Inermediary Byte = 0x67

在回过头来看看加密过程:

初始化向量IV与明文进行XOR运算获得了Inermediary Value，所以将刚才获得的Inermediary Byte(0x67)与"真实"的IV的最后一个字节0x0F(攻击者事先获取到的)进行XOR运算，即能获得明文:

0x67 ^ 0x0F = 0x68 : H

即获得明文(第一个分组)的最后一个字母H！

这里我们要稍微停一下，把思路理一理:

1. 咱们在得出明文的那次XOR计算中用到的IV(0x0F)和咱们攻击者不断"注入"的IV(0x01~0xFF)不是一回事，要区分开来。在计算明文的那个IV(0x0F)是咱们事先就获取到的，回想咱们以前说的这个Padding Oracle Attack攻击的成立条件:

这个IV(0x0F)是服务器端在发送密文的时候(多是cookie形式)附带在密文的头部发给咱们的。通常状况下，若是跨系统发送这种"带盐"的密文，都要把"盐(IV)"附带在密文的头部或其余位置一块儿发送给接收方。这里咱们接收到的IV就是0x0F，在不一样的环境中这个IV必然是不同的，关键是要理解原理。

2. 为何咱们能够不断尝试IV？

按理来讲，IV不是在服务器第一次生成这段密文的时候就生成好了吗？而后在每次发送的时候都附带在密文的头部，不会再变了......

的确是这样，但这说的是在正常的解密状况下发生的事，而咱们攻击者如今作的事并非在解密(事实上攻击者这个时候也不知道IV和KEY)，咱们只是在经过不断的修改IV来对目标解密系统进行"试探"，从返回的结果来进行"侧信道攻击"，从而进行二值逻辑推理。

这就是一种所谓的"选择密文攻击"方式，好像也有叫Bit-Flipping Attack：

http://www.vnsecurity.net/2010/03/codegate-2010-challenge-8-bit-flipping-attack-on-cbc-mode/

继续回到思路分析上来:

在正确"匹配"了Padding 0x01以后，须要作的是继续推导出剩下的Intermediary Byte。根据Padding 原则，在须要Padding两个字节的时候，其值应该是0x02。

2) Padding 0x02

这个时候咱们要注意，以前说过，这个攻击过程是个循环迭代的过程，上一步的结果就是做为下一步的基础。

咱们以前已经知道Intermediary Byte的最后一个字节为0x61，所以能够"更新"IV(攻击者输入的IV)的第8个字节为 0x66 ^ 0x02 = 0x64。

(思考: 这个Padding Oracle Attack的过程当中，攻击者须要不断地调整输入IV的值，以前由于在Padding 0x01中，咱们只是在假设Padding 0x01的状况，在这个假设下，咱们经过得出IV的最字节，从而计算出Intermediary Byte，进而算出明文的最后一个字节"H"。这里要注意的是，这个假设的IV没有任何意义，只是咱们进行"选择密文攻击"过程当中的一个路人甲而已。而接下来咱们要继续假设Padding 0x02的状况，为了使在假设Padding 0x02中，Intermediary Value的最后一个字节依然为"0x67(以前算出来的)"，因此咱们要对IV的最后一个字节进行迭代更新: 0x66 ^ 0x02 = 0x64)。

这个时候，本质上攻击者是固定住了IV的最后一个字节不变，开始循环"盲注"倒数第二个字节。开始依照第一步时的方法对倒数第二个字节进行"盲注"逻辑判断。

Request: http://sampleapp/home.jsp?UID=0000000000007064EFC2807233F9D7C097116BB33E813C5E

Respose: 200 OK

经过遍历能够得出，IV的第7个字节为0x70。

if(Inermediary Byte) ^ 0x70  == 0x02
{
       Inermediary Byte = 0x70 ^ 0x02                
}
so:
        Inermediary Byte = 0x72

对应的Intermediary Byte为0x72。知道了Intermediary Byte的倒数第二个字节为0x72，就能够得出明文的的倒数第二个字节:

0x72 ^ 0x17 = 0x65 : e

(这里的IV: 0x17是咱们从服务端接收到的附带在密文头部的IV的倒数第二个字节)
接下来，要继续对IV进行假设，同理，此次"选择密文攻击"的假设是Padding 0x03，对IV进行迭代更新，而后对IV的倒数第三个字节进行"穷举"循环探测。

Padding 0x03

Padding 0x04

Padding 0x05

Padding 0x06

Padding 0x07

Padding 0x08

最终获得这个分组的明文LittleH。这是第一个分组的明文。

注意，Padding Oracle Attack是以单个分组进行的。到了这一步，咱们会发现，咱们的攻击目标其实就是那个临时中间值变量Intermediary Value，获得了这个值，再加上咱们原本就能够获取到IV(服务器端生成的附在密文头部的那个IV)，咱们能够经过XOR运算获得这个分组的明文。

对于多个分组的密文来讲，咱们继续观察一下CBC的解密流程:

第二个分组使用的IV(对于第一组来讲是附带在密文头部的那段)是第一组分组的密文。所以咱们就把第一组的密文带入带第二组的计算中。继续第对二组的Intermediary Value进行逻辑推导，最终获得第二组的密文:ann。

多分组的密文能够依次类推，由此便可以仅根据密文和IV还原出明文。

4. Padding Oracle Attack的攻击利用场景

一旦咱们经过暴力破解获得中间值Intermediary Value以后，IV即可以用来生成咱们想要的任意值。新的IV能够被放在前一个示例的前面，这样即可以获得一个符合咱们要求的，包含两个数据块的密文了。这个过程能够不断重复，这样便能生成任意长度的数据了。

使用PadBuster加密任意的值

https://github.com/GDSSecurity/PadBuster

5. 模拟实验

这是道哥写的python脚本，能够用来模拟实验出Padding Oracle Attack的原理:

http://pan.baidu.com/s/1eitwK

能够参考源代码来进行深刻的学习，加深理解。

6. 后记

本身按照书上讲的理解了一下，若有不对之处，望指正。