背景
这是前两天的漏洞验证中发现的第二个有意思的古老的漏洞，算是做一个小科普。
微软在2010年9月17号发布了一个关于ASP.NET平台的安全漏洞公告，这个公告就是关于Padding Oracle攻击的，其实这个漏洞并不仅是ASP.NET才存在，而ASP.NET Padding Oracle这种说法引人注目的原因可能是由于微软官方的反应和其应用比较广泛吧。实际上Padding Oracle是一个攻击原理，这是一个普遍存在的安全漏洞，通过这个原理还可以攻击CAPTCHA、Ruby on Rails、Apache MyFaces、Sun Mojarra、JavaServer Faces等其他目标，甚至连OWASP提供给的企业维护安全的API工具包ESAPI都会受到这个攻击。
Padding Oracle攻击，在2010年由Black Hat、OWASP和White Hat Security三大安全组织联合发起的10大WEB黑客技术中排名中居于首位，由此对于它的威力也可见一斑。
漏洞简介
ASP.NET由于加密填充验证过程中处理错误不当，导致存在一个信息泄漏漏洞。成功利用此漏洞的攻击者可以读取服务器加密的数据，例如视图状态。 此漏洞还可以用于数据篡改，如果成功利用，可用于解密和篡改服务器加密的数据。 虽然攻击者无法利用此漏洞来执行恶意攻击代码或直接提升他们的用户权限，但此漏洞可用于信息搜集，这些信息可用于进一步攻击受影响的系统。
说的简单点，就是这个漏洞不能直接getshell，但是理论上可以利用它读取网站上任意文件的源码，比如数据库配置文件。
对称加密基础知识
说到Padding Oracle攻击，就不得不先说说对称加密，在对称加密算法中，密文就是密钥加明文经过加密算法处理的结果。加密算法里面的加密是分块实施的，如DES, RC2等算法。每块固定n(8, 16, 32„)位，有余数的情况一般按照某种规则补足，就是所谓的Padding填充，如常用的PKCS #5规则（图一），就是根据最后一个数据块所缺少的长度来选择填充的内容。为了加强加密的效果，所以会把上一块的密文用来混淆下一块加密数据，以此类推，用来混淆第一块数据的是预先生成的IV（初始化向量）。
另外为了保证针对同一明文和密钥的密文每次都不一样，Web应用中通常会随机生成IV，并将它附加在密文中进行传输。在解密时候解密算法回收密文中携带的IV，将密文逆向解密，拿到一个中间密文，然后使用IV逆向混淆此中间密文，随后检查Padding的合法性，最后返回明文信息。
Padding Oracle攻击
说实话，我第一眼看到Padding Oracle的时候还以为是关于oracle数据库的，不太明白为什么发现者取了个这样的名字，也许是为了调侃甲骨文oracle吧。
其实在这里的Padding是“填充”的意思，因为对于加密算法来说，它们是基于等长的“数据块”进行操作的（如对于RC2，DES或TripleDES算法来说这个长度是8字节，而对于Rijndael算法来说则是16、24或32字节）。但是我们的输入数据长度是不规则的，因此必然需要进行“填充”才能形成完整的块，通过这种规则我们便可以根据填充的内容来得知填充的长度，以便在解密后去除填充的字节。
一个密文被解密时也是分段进行的，在解密完成之后算法会先检查是否符合规则，如果它的Padding填充方式不符合规则，那么表示输入数据有问题。对于解密的类库来说，往往便会抛出一个Padding Error异常，提示Padding不正确。而在这里Oracle是“神谕、提示”的意思，和经常听说的oracle数据库没有什么关系。
可以这样来理解Padding Oracle攻击——黑客只需要一个合法密文，即可通过不断向网站发送篡改过的密文（这个过程主要是构造IV的过程），观察是否有Padding异常错误提示，网站中的异常错误提示可能直接显示在网页当中，也可能只是HTTP状态码，如“200 - OK”是正确的，“500 - Internal Server Error”是错误的，根据两个不同的HTTP状态码做对比即可，而不需要其他任何详细信息。
如果有异常错误提示即可不断地给网站程序提供密文，让解密程序给出错误提示，再而不断地修正，从而最终获得混淆之前的中间密文。拿到中间密文之后，可以通过构造IV，使得中间密文被逆向混淆之后得到的明文为指定内容，从而达到攻击的目的。在这过程中Padding Oracle攻击并没有破解掉加密算法的密钥，也没有能力对任意密文做逆向解密，只是可以利用一个有效密文，生成一个解密后得到任意指定内容明文的伪造密文。
一般一次成功的攻击所需要的平均耗时不会超过3个小时，以一个8byte的IV构造为例，每个Byte最坏的情况需要尝试256次，总共是2048次。假设每次尝试的时间为5秒（HTTP响应时间），总共耗时在3个小时以内。
利用工具及环境
该漏洞的利用工具为PadBuster，该漏洞利用工具运行环境为perl，需要在本机配置好perl脚本运行环境。本次我是在Kali上进行的漏洞验证，Kali自带perl环境，可通过perl -v命令查看本地perl版本，如图二所示。
漏洞发现
寻找padding oracle漏洞目标，可以简单的通过Acunetix Web Vulnerability Scanner等WEB漏洞扫描器来扫描目标网站发现。
另外最常用的方法就是Google hacking，通过allinurl: "WebResource.axd?d="或者搜索Java的javax.crypto.BadPaddingException。再就是黑箱测试从网页的源文件中查找一些BASE64形式的字符串，猜测常见的分割符，如“–”，“|”或是“:”等等。
如果你有网站的源代码的话，也可以通过源代码审计来寻找padding oracle漏洞，如下表。
| 编程语言 | 漏洞关键字 |
|---|---|
| C/C++ | OpenSSL, Crypto++ |
| Python | PyCrypto, M2Crypto |
| .NET | .NET Cryptography, Microsoft CryptoAPI |
| Java | Java Crypto Extension, BouncyCastle |
利用Padding Oracle进行攻击
利用Padding Oracle原理来攻击的方法是多种多样的，如可以破解验证码、解密JSF加密信息、解密ViewState信息、伪造管理员的cookie、甚至可以下载web.config配置文件等。这里就以读取web.config配置文件为例给大家演示一下。
配置好本地perl环境并下载好漏洞利用工具之后，执行命令：
1 | perl Padbuster.pl http://www.example.com/WebResource.axd?d=9MBwmxN6TLKjC8S3CdFGyw2 9MBwmxN6TLKjC8S3CdFGyw2 16 -encoding 3 -plaintext "|||~/web.config" |
执行结果如下图所示：
这样就得到了目标网站web.config的URL的加密地址encrypted_string，下面就该上Webconfig Bruter.pl继续填充并获取完整的访问地址了。执行命令：
1 | perl Web.config_bruter.pl http://www.example.com/WebResource.axd encrypted_string 16 |
然后耐心等待，即可得到一串新的加密字符encrypted_string_new，使用浏览器访问下面的地址就可以访问网站的web.config文件了。
1 | http://www.example.com/ScriptResource.axd?d=encrypted_string_new（注意是ScriptResource.axd） |
- More Info：这里有一个该漏洞的完整讲解利用视频，也许对你有帮助。