首页 > 代码库 > 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)