新闻链接：http://www.91ri.org/6715.html
新闻时间：2013-07-25
新闻正文：
我记得这个漏洞在12年的时候，国内的资料还很少，当时遇到之后来回找资料，但是国内当时在网上能看到的资料只有2篇，但我忘记是哪2篇了，不过手上是有2篇比较早的资料，先传上来做个引题吧。
《ms10-070(ASP.NET Padding Oracle Vulnerability)exp使用方法》《 浅谈Padding Oracle攻击》
然后，在13年，这个漏洞不知道被谁翻出来了，然后就有点要火的意思了，大多数人看到这个漏洞之后都会开始尝试一下了。
说到这里，推荐一下ay暗影同学的利用视频：《padding oracle vul attack》
然后还有其他朋友在问这个漏洞的问题，那就索性做个科普好了。
漏洞简介
ASP.NET由于加密填充验证过程中处理错误不当，导致存在一个信息泄漏漏洞。成功利用此漏洞的攻击者可以读取服务器加密的数据，例如视图状态。 此漏洞还可以用于数据篡改，如果成功利用，可用于解密和篡改服务器加密的数据。 虽然攻击者无法利用此漏洞来执行恶意攻击代码或直接提升他们的用户权限，但此漏洞可用于信息搜集，这些信息可用于进一步攻击受影响的系统。
说的简单点，就是这个漏洞不能直接getshell，但是理论上可以利用它读取网站上任意文件的源码，比如数据库配置文件。
利用工具及环境
所利用到的工具的下载地址是：
http://blog.mindedsecurity.com/2 … ith-or-without.html
http://www.exploit-db.com/sploits/padBuster.pl
2个工具都是perl写的，执行之前需要先在本地安装perl环境。
perl环境下载地址：http://www.skycn.com/soft/appid/10600.html
我测试的时候用的perl是“ActivePerl-5.14.2.1402-MSWin32-x86-295342”，上边发的perl下载地址是5.16的，这个版本是否可以执行这2个工具我没测试，如果不行请访问此地址下载跟我测试时候的同版本的perl：http://www.baidu.com/s?wd=Active … -MSWin32-x86-295342
漏洞发现
扫描工具Acunetix Web Vulnerability Scanner可以扫描到这种漏洞，给个效果图：
目前没发现别的能发现这个漏洞的扫描工具，所以说，作为专业做web漏洞扫描工具的厂商，Acunetix Web Vulnerability Scanner还是做的不错的，虽然被国内的破解大牛轮的一点脾气都没有。
寻找WebResource.axd
这个漏洞利用的最关键的一点就是寻找WebResource.axd，准确的说是寻找网站中可能存在的对WebResource.axd的引用，因为网站中引用WebResource.axd的时候会显示出原本的加密字符串，类似这样的：
view source1 WebResource.axd?d=9MBwmxN6TLKjC8S3CdFGyw2
我们要找的就是参数d的值，如果在源码中看到有其他的参数，不需要理会。
这个WebResource.axd不大好找，有时候根本就找不到，如果人品好，访问首页，看看源码或许就找到了WebResource.axd，如果人品还行，那在网站上点几下或许也能找到，但人品不好的话可能一直找不到。
不过可以使用Acunetix Web Vulnerability Scanner对网站做一个深度全方位的扫描，或许可以找到这个文件的位置，如果Acunetix Web Vulnerability Scanner扫到了这个文件的位置，会提示在哪个页面中的，在Acunetix Web Vulnerability Scanner扫描结果中的文件列表显示栏也是可以直接看到WebResource.axd和它的参数和值的，这样就方便很多。
漏洞利用第一步：padding填充
找到WebResource.axd参数的值之后，就可以开始利用了。
安装好perl环境，执行：
view source1 Padbuster.pl http://www.91ri.org/WebResource.axd?d=9MBwmxN6TLKjC8S3CdFGyw2 9MBwmxN6TLKjC8S3CdFGyw2 16 -encoding 3 -plaintext "|||~/web.config"
参数说明：
这里的16为每个数据块的字节数，分为8和16，目前本人还没有什么好的方法判断这个字节数，所以需要大家可以两种都试一下(大多数为16)。
encoding参数有4种，分别是0=Base64, 1=Lower HEX, 2=Upper HEX 3=.NET UrlToken, 4=WebSafe Base64，由于本次测试为asp.net，所以这里我们选择3。
plaintext为想读取内容的文件，本次测试以web.config为例。
执行几分钟后，程序会提示：
这里是让我们选择一个相应模式，并且**表示程序推荐的，那么这里就选择程序推荐的2号模式，等几分钟
到这里，就拿到了web.config的URL的加密地址。
下面就该上Webconfig Bruter.pl继续填充并获取完整的访问地址了。
漏洞利用第二步：继续padding填充并筛选结果
执行：
view source1 Webconfig Bruter.pl http://team.f4ck.net/ScriptResource.axd XXXXXXXXXXXXXXXXXX 16
这里有几点要注意：
1、URL后跟的是ScriptResource.axd，不再是WebResource.axd了
2、我这里写的XXXXXXXXXXXXXXXXXXXX是第一步得到的加密字符串，不是在网页源码中得到的参数d的值
再等几分钟，也很快的，没有传说中需要等那么久的，然后就得到了最终的加密字符串：
OK，记好这个加密字符串，使用浏览器访问：
view source1 http://www.91ri.org/ScriptResource.axd?d=XXXXXXXXXXXXXXXXXX
这里有几点要注意：
1、URL后跟的是ScriptResource.axd，不再是WebResource.axd了
2、我这里写的XXXXXXXXXXXXXXXXXXXX是第二步得到的加密字符串，不是在网页源码中得到的参数d的值，也不是第一步得到的加密字符串
这样就得到了web.config的源码了：
就是这样，很简单，不需要多长的时间的，看上边的图就可以知道，我这次测试工具只发了4984个包就得到了正确的KEY。
小编语：为了读者方便，文章中的附件已经转到了百度网盘，如果链接失效大家可以点击下面的link查看原文。
国内对于这个信息泄漏的漏洞也有些许大牛研究过，这里也给出一篇当初刺总分析的文章链接可供大家参考：
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
