Is it vulnerable to ASP Padding oracle

When I open chat.mysite.com/WebResource.axd?d=jzjghMVYzFihd9Uhe_arpA2 It gives me: Padding is invalid and cannot be removed.
When I open chat.mysite.com/WebResource.axd?d=acunetix It gives me: Invalid viewstate.
When I open chat.mysite.com/WebResource.axd?d= It gives me: The resource cannot be found.

However, when I open any of those /WebResource.axd to my main site www.mysite.com, no error happens....

My question, Is my site vulnerable to padding oracle, and if yes, what data can be stolen? Another thing is that once I open the "view source" of www.mysite.com, there is no such thing as script=webresource.axd, or anything like that.... Im confused, if an attacker wants to take control of the site, what can he do? How would he perform his attack? Can the attacker can gain access to admin privilege?

回答1:

With the little information provided I would say it is likely that this vulnerable to padding oracle. A padding oracle can be used to decrypt the cipher text, one byte at a time starting at the very end of the message working backwards.

All cipher text should be protected with a MAC.

回答2:

Answer based on comments to the question.

Yes, you are currently vulnerable to the padding oracle attack.

This means they can download things like your config file and decrypt your viewstate and cookies.

Regarding access to the "admin priviledge", maybe. Depends on what is found. For example, if you have a database connection string in the web.config file AND that database server is accessible on the internet then the attacker might just completely bypass the app and go straight to the db. There are certainly numerous factors here that might limit the damage down by exposure of the web.config info but unfortunately a LOT of developers don't know what they are doing. They tend to not think about this.

So, what can you do about this?

First up, keep your servers up to date with their patches. Windows has ways to automate this through auto update. Which I highly recommend for web servers. MS tends to patch things pretty quickly. Further, in over 10 years of letting windows servers patch themselves I have never run into an issue. I wish I could say the same for DB patches, but even those are starting to become things you simply must do.

Second, look at the application itself. Is there anything in the web.config that could lead to compromising the data. Things like references to database servers, passwords to other systems, etc. If so, then I'd suggest immediately after patching you change all of those passwords. For DB access I tend towards ensuring even the application doesn't have direct rights to query tables. But that's a completely separate discussion.

Third, develop a tendency to not trust anything. Not your own servers nor even your own code. This will lead to being a better programmer anyway. If an attacker is able to drop a executable file in your website they could get access to literally everything your web app has access to.

Fourth, expose ONLY what's necessary to the internet. This requires a lot of education and testing to make sure your routers/firewalls/etc are properly configured. Unfortunately developers tend to lower those defenses as soon as it's inconvenient. For example, installing debugging tools on a server or exposing a database to the internet in order to get access to it from home... This goes along with #3 above.

Fifth, research research research. Take the time to learn how things are compromised and what that means. It's a lot easier to code defensively when you know what you are protecting and what you are protecting it against. There is a tremendous amount of bad information out there and knowing how attacks work will make it easier for you to filter it out. A simple example are sites showing how to dynamically build a sql statement. The vast majority of those don't use parameters; and the ones that do completely ignore the idea that the web application itself could be bypassed.

There's more, a lot more, but that's enough to chew on for now.