I thought I will take some time to write up something about Padding Oracle attacks and how to exploit the vulnerability based on some scenarios that I encountered in the field.
Before we start, this issue has nothing to do with Oracle database (just in case you mistook) or is specific to a platform (e.g.
Padding Oracle – The vulnerability
Padding oracle has been covered in detail by many leading experts. And so, I am not going to explain the technical side of the issue. If you want to refresh your memories, check out these blog posts
- Practical Padding Oracle Attacks and exploit tools
- Automated Padding Oracle attacks With PadBuster By Brian Holyfield
- Padding oracle attacks: in depth by Ron Bowes
- A padding oracle example by Ron Bowes
Padding Oracle – Identification and Exploitation
Its not often that you would come across Padding oracle issue these days and the ones I cane across have always been .NET based. And so, I will cover how to quickly identify and exploit the vulnerability on a .NET application –
Identification, in a hurry
Update: 10 Aug 2013) A word of caution before we proceed. Dan (@commonexploits) pointed out that the tools described below for testing for vulnerability do report
.NET 4.5 to be vulnerable, even though they are not. So, I advice you to take your head while testing and not to rely solely on the tools. Also, I think the test without tools (described below) may help solving this issue. However, I am yet to test this out. If you are in a position to test it and find promising results let me know and I will update it on my site.
Testing without tools
- First, get the link for
- Delete the value of 'd' parameter and send the request. Keep the response with you.
- Next, put a random value to 'd' parameter and send the request again. Get the response and compare it with the previous results.
If the vulnerability exists, then you will see some difference in the pages.
Testing with tools
To identify a potentially vulnerable site, first scour the .NET website for a link referencing to WebResource.axd and ScriptResource.axd. Obtain the value of the 'd' parameter within this link.
There are two scripts you can use to quickly check if the site is vulnerable or not.
- Check Patch by Giorgio Fedon at Minded Security
- MS10-070_check by Bernado Damele
- dotnetpaddingoracle by Gabriel Caudrelier at NCC Group (Update: 10 Aug 2013). Note: This runs on Python v3.
Run either of the script and provide the value of
'd' parameter within
ScriptResource.axd. The script will check and will let you know if the site is potentially vulnerable or not.
Exploitation – Scenario based approach
Scenario # 1 – Normal cases
Normal cases involve the application responding with a 500 status codes when there is an error in decryption.
Tools to use
First task is to find the encrypted cipher block for the arbitrary file to download. As a proof of concept, we will try to extract the
PadBuster from Brian Holyfield at Gotham Digital Security to aid in obtaining the encrypted cipher block.
padbuster.pl http://vulnerablesite.com/WebResource.axd?d=12sfion23c0293jrm_asdmals232d2lms23f2 12sfion23c0293jrm_asdmals232d2lms23f2; 16 –encoding 3 –plaintext "|||~/web.config" –prefix 12sfion23c0293jrm_asdmals232d2lms23f2
The above command structure can be broken down as follows
padbuster.pl <URL TO WEBRESOURCE WITH VALUE OF D> <VALUE OF D> <BLOCK SIZE> <ENCODING> <PLAINTEXT/FILE TO EXTRACT> <PREFIX VALUE OF D>
After few minutes,
PadBuster will ask you to select one from a list of response signatures – it will have
** beside it.
Wait for few minutes until
PadBuster does its business and in the end will give you the encrypted cipher block for
Next task is to brute force and gain access to web.config. We now have three different choices of tools –
PadBuster by Brian Holyfield.
Web.Config bruter by Giorgio Fedon and
ASPX_PO_CHOTEXT_ATTACK script by Agustin Azubel.
padbuster.pl http://vulnerablesite.com/ScriptResource.axd?d= 16 –encoding 3 –noiv –bruteforce –log –prefix 12sfion23c0293jrm_asdmals232d2lms23f2
Look out for a relatively larger (or smaller) content length (which would be web.config)
Web.config_bruter.pl http://vulnerablesite.com/ScriptResource.axd 16
Once web.config is obtained, the script will print it on the screen and stop.
ruby aspx_po_chotext_attack.rb http://vulnerablesite.com/page.aspx
As you can see here, we don't have to give the direct link to WebResource.axd or ScriptResource.axd. Just give the link to the page which will have ScriptResource.axd link. The script will find it and then do the decryption and then brute forcing for you.
- PadBuster by Brian Holyfield
- Web.config Bruter by Giorgio Fedon
- ASPXPOCHOTEXT_ATTACK by Agustin Azubel
Scenario # 2 – Custom error messages enabled
When this issue was first discovered and disclosed, Microsoft released a quick workaround (link) – Use custom error messages. When custom error messages are enabled, things get very tricky as you might not get the usual 500 status code when decryption fails.
But, if you don't configure custom error message properly like reference two different types of error files for the type of error (e.g. filenotavailable.html for 404, error.aspx for 500) then this difference can be used to exploit. Also, look for any difference in the pages being returned (e.g. words).
Brian Holyfield has written some steps that can be taken to exploit even when custom error messages are enabled. Check this link for more info. Read the section "Bypassing the Workarounds".
Hope all the information I collected and provided helps you.