首页 > 代码库 > CVE-2010-3332分析 Microsoft ASP.NET - Padding Oracle (MS10-070)
CVE-2010-3332分析 Microsoft ASP.NET - Padding Oracle (MS10-070)
相关链接:
exploit-db:https://www.exploit-db.com/exploits/15213/
微软安全公告:https://technet.microsoft.com/library/security/ms10-070
Padding Oracle资料:http://blog.zhaojie.me/2010/10/padding-oracle-attack-in-detail.html
WebResource.axd教程:http://www.cnblogs.com/jackielin/archive/2005/11/29/286570.html
网站文件:http://files.cnblogs.com/files/poc-/MS10-070.rar
MD5值:6ea1bb594b688ab2d152c048b5c14c95
漏洞介绍:
微软提供的漏洞原因是,使用加密填充的 ASP.NET 在可能被攻击者用来读取和篡改加密数据的错误响应中提供信息。
有关Padding Oracle的内容全部来自于上面的链接
先来解读漏洞的标题,"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)