What is the padding oracle attack? The oracle is a part of a cipher that can answer if the cipher is valid or not. In the simplest terms the oracle can be asked questions and depending on the response the attacker can decrypt a valid cipher text. The text must be able to be divided into an exact number of blocks. If a word such as “test” is submitted it would have to be padded with 4 additional bytes to equal 8. However, if the final block does not end with a valid byte an error is given. This error is what is leveraged for the padding attack.
What can be done with it? The most popular demonstration of this attack is the video that shows a Dotnetnuke install falling victim to it. In the video the padding attack is used to gain admin access to the Dotnetnuke site. Other uses of the attack allow an attacker to retrieve almost any file from the web server’s web directories. However, the attacker needs to know where the files are. The first file an attacker will most likely retrieve is the web.config. Strategically this is a good choice because it can contain passwords, usernames, connection strings, and locations of other files.
Before the patch was available Microsoft released a work around for ensuring your sites’ immunity. It was basically turning on custom error handing. However, if the custom errors didn’t redirect you to the exact same page it could still leak the information.
A site with custom errors turned off can be identified as vulnerable by issuing the following request. http://www.site.com/WebResource.axd?d=zt87v2JeCPKYzqUfGEffpA2. If the site is vulnerable it will give a “padding is invalid and cannot be removed” error.
But in all honesty I have found this not to be 100% reliable. Using a tool like padbuster can identify if the site is vulnerable. Padbuster also can identify which response signature should be used.
Penetration testers can find some valuable information in using this attack. Besides the files that can be obtained, this attack can be used to test monitoring and incident response. The attack is noisy and can fill error logs very fast. The attack can generate thousands of 500 or 404 error responses. The attack is generally not fast, either. Retrieving a web.config can take from ten to sixty minutes. In the screenshot we retrieved a connectstring.config
If this attack goes unnoticed it is because of a couple points of failure. This attack generates hundreds of errors which would fill event logs. The amount of generated errors shouldn’t go unnoticed by an administrator or a monitoring system. Also, an attacker has to know exactly where certain files exist. While an attacker most likely will go after the web.config first, it should not point out other sensitive files. However, the major problem arises from a lack of patch management: this was a critical patch and should have been applied immediately. The most important thing to take away from this is when a critical patch is released, apply it now.
By Chris J. Murrey