时间：2021-07-01 10:21:17 帮助过：196人阅读
先来解读漏洞的标题，"Padding"指的是便是加/解密时的填充，加密时明文可以是任意长度，但是块状加密算法需要一定数量的相同长度数据块组成。为了满足这样的需求，便需要对明文进行填充。
有多种填充规则，但最常见的填充方式之一是在PKCS#5标准中定义的规则。PCKS#5的填充方式为：明文的最后一个数据块包含N个字节的填充数据（N取决于明文最后一块的数据长度）。8字节数据块对齐方式如下：
“Oracle“指的是提示，如果解密后的最后一个数据块末尾不符合这样的填充方式的话，大部分加/解密程序都会抛出一个填充异常。这个异常对于攻击者尤为关键，它是Padding Oracle攻击的基础。
下面模拟一个场景：某个应用程序使用Query String参数来传递一个用户加密后的用户名，公司ID及角色ID明文为，“BRIAN;12;1;”。参数使用CBC模式加密引入IV，密文 = Enc(密钥, XOR(IV, 明文))，每次都使用不同的初始化向量（IV）并添加在密文前段。
当应用程序接受到加密后的值以后，它将返回三种情况：1、填充正确且包含合法的值（200 - OK） 2、解密后发现填充不正确（500 - Internal Server Error） 3、填充正确但值非法(200 - OK)
场景中的URL是 http://sampleapp/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
UID参数使用了ASCII十六进制表示法，攻击者可以根据加密后值的长度来推测出数据块的大小。由于长度（这里是24）能被8整除但不能被16整除，因此可以得知数据块的大小是8个字节。
一个正常的加密过程如下，其中带圆圈的加号表示XOR（异或）操作：
将IV和明文异或后得到中间值，再将中间值利用密钥进行3重DES加密，加密结果作为下一个块的IV。
解密过程为逆过程，
Padding Oracle 攻击的流程如下：
我们将每次操作一个单独的加密块，因此我们可以独立出第一块密文（IV后的那块），在前面加上全为NULL的IV值，并发送至应用程序。并递增IV的最后一个字节
Request: http://sampleapp/home.jsp?UID=0000000000000000F851D6CC68FC9537 Response: 500 - Internal Server Error
Request: http://sampleapp/home.jsp?UID=0000000000000001F851D6CC68FC9537 Response: 500 - Internal Server Error
由于解密出来的填充值不符合规则，返回一个500错误。重复请求，对于可能的256个值中只有一个值会产生正确的填充字节0x01。此时IV最后一个字节递增至0x3C时，解密出来为0x1符合填充规则。
Request: http://sampleapp/home.jsp?UID=000000000000003CF851D6CC68FC9537 Response: 200 OK
根据状态码200响应，这样我们就可以在不知道加密Key的情况下，推断出中间值（Intermediary Value）的最后一个字节，因为我们知道它和0x3C异或后的结果为0x01，于是：
因为 [Intermediary Byte] ^ 0×3C == 0×01, 得到 [Intermediary Byte] == 0×3C ^ 0×01, 所以 [Intermediary Byte] == 0×3D
在解密的过程中，中间值的每个字节都会与密文中的前一个数据块（对于第一个数据块来说便是IV）的对应字节进行异或操作。于是我们使用之前示例中原来的IV中的最后一个字节（0x0F），与中间值异或一下便可以得到明文。不出意料，我们会得到0x32，这表示数字“2”（明文中第一个数据块的最后一个字节）。
我们现在已经破解了示例数据块中的第8个字节，是时候关注第7个字节了。在破解第8个字节时，我们使用暴力枚举IV，让解密后的最后一个字节成为0x01（合法填充）。在破解第7个字节的时候，我们要做的事情也差不多，不过此时要求第7个字节与第8个字节都为0x02（再重复一遍，这表示合法的填充）。我们已经知道，中间值的最后一个字节是0x3D，因此我们可以将IV中的第8个字节设为0x3F（这会产生0x02）并暴力枚举IV的第七个字节（从0x00开始，直至0xFF）。使用这种技巧，我们可以从后往前破解中间值里的每个字节，最终得到解密后的值。
Padding Oracle就是根据填充异常的响应提示，使我们不知道Key的情况下，推断出中间值。
环境介绍：
1、pl脚本运行环境（ActivePerl_5.16.2）
2、被漏洞影响的环境，我选用了一台03 Enterprise Edition SP2虚拟机 + .NET Framework 3.5
安装.NET Framework3.5后，可以通过查看 %WINDIR%\Microsoft.NET\Framework\ 目录可以看到已安装的版本。通过搜索注册表项NET Framework Setup，查看SP信息。
漏洞重现：
下载 exploit-db 提供的pl脚本，根据脚本中的示例来了解漏洞。先了解脚本中所需第一个参数是一个URL指向 ScriptResource.axd 文件。
在ASP.NET中可以将js和css等资源文件打包到dll中，打包后可以通过WebResource.axd加参数的形式访问资源文件。ScriptResource.axd的作用也差不多，用于返回js文件比WebResource.axd拥有更多特性。发现只要在页面中嵌入了ASP.NET UpdatePanel，页面里就会出现WebResource.axd 和 ScriptResource.axd，完全符合漏洞环境。可以自己写或者部署我上传的网站文件。
网站文件如下：
在IIS上准备好ASP.NET3.5的环境，结果发现网上说Framework2.0,就可以运行了，3.0 和 3.5都是在2.0的基础上延伸的.。启用IIS的 ASP.NET Web 服务扩展 。然后将网站的文件复制到IIS的网站目录下访问。
再了解第二个参数EncryptedSample，注释说这个参数来自于Padbuster。根据提示下载另一个脚本padBuster.pl。在padBuster脚本中需要3个参数URL，EncryptedSample，BlockSize。接下来查看部署的页面生成的Html源码。我打算用ScriptResource.axd这个链接。
完整的命令行如下，块大小一般是16。发现不成功
根据错误提示搜索padSub脚本，定位到解码函数 encodeDecode 。应该指定格式3即.NET UrlToken。该格式会将d参数进行替换 ‘-‘ =>‘+‘ ‘_‘=>‘/‘ 并填充‘=’，再进行base64解码。这是由于URL编码器会把标准Base64中的“/”和“+”字符变为形如“%XX”的形式，素有才会有这样的替换存在。
所以最终命令行如下，可以增加-log 开关，查看详细的http请求日志，首先会将IV最后一个字节循环递增请求，来确定Padding错误的提示。会根据Status，Length等响应信息确定。我们只需选择带两个星号的ID就可以了
确定好Padding异常的提示后，就会开始爆破。解密出来的值是：nsions,3.5.0.0,,31bf3856ad364e35|MicrosoftAjax.js|zh-CHS。如果出现无法响应请求的情况，可以调整一下网站的连接配置，后续再恢复配置。连接超时从120秒设置为5秒，并不保持HTTP连接。
根据网上的提示将 “|||~/web.config” 进行加密命令行如下，得到加密结果为：HLcNhlIbsORxFMYA6ro1GgAAAAAAAAAAAAAAAAAAAAA1。
密文 = Enc(密钥, XOR(IV, 明文))
加密的流程是 任意给定最后一个块的密文，用最后一个块的密文，通过Padding Oracle知道中间值再异或明文，算出IV(上面的流程是算出明文)，这个IV是前一个加密块的密文。所以只需爆破出初始IV就可以访问 "|||~/web.config"了。
然后再运行exploit-db上下载的脚本,Web.config_bruter.pl 进行运行，该脚本爆破出正确的IV，最终得到能访问webconfig的url。
爆破结果：
访问http://192.168.0.15/ScriptResource.axd?d=sGQ6SzO0gY5_kXYCskHWZRy3DYZSG7DkcRTGAOq6NRoAAAAAAAAAAAAAAAAAAAAA0 即可看到web.config的内容。
CVE-2010-3332分析 Microsoft ASP.NET - Padding Oracle (MS10-070)
标签：并发 日志 6.2 tga update app conf 安全 aaa