Incorrect. OP is correct. The article is sensationalistic to a fault. Anyone upvoting yours and downvoting his does not understand either how ASP.NET works or didn't read the article or its comments. Sorry - not trying to be a jerk but it bugs me whenever incorrect information is upvoted, especially when it comes at the expense of downvoting the correct information.
The first thing you learn about error handling and security is to not send back error messages that have useful information that hackers could use for penetration; that is programming 101 stuff. Therefore, any decent ASP.NET app does not send back the error messages that the article talks about - the app devs hide those behind, "Oops! Sorry 404!" type stuff. It's super simple and done on almost all ASP.NET sites.
So yes, there is a vulnerability, but this is sort of like the SQL Server bug from 5+ years ago that depended on their being no password for the server admin account. Yes, certain people will be bitten, but by and large "professionals" will have covered for this already.
And no, "the generic error" is not all they need b/c the developer says "Oops 404!" as the generic error or "Oops Server Error 500". Nothing substantial and no information that would give away what happened or why.
This attack doesn't rely on reading information out of errors. You seem remarkably confident about your interpretation of a talk that hasn't been presented yet.
Was it your perception from this report that the flaw here was developers leaking crypto secrets in the text of their errors? You were wrong.
It isn't at all clear how getting the default generic YSOD is going to generate "more data" for the attacker by repetition, unless response time is the data of interest. Is that the case here?
They don't need timing. They don't need to sniff. HMAC doesn't solve the problem. They don't use detailed errors. You should probably read their JSF paper from earlier this year to see the attack pattern they're working with.
Here is a clue: they are using ASP.NET behavior to generate a one bit signal from the target. Their attack requires many tens of thousands of requests. That's about as much as I can say.
Comments
Incorrect. OP is correct. The article is sensationalistic to a fault. Anyone upvoting yours and downvoting his does not understand either how ASP.NET works or didn't read the article or its comments. Sorry - not trying to be a jerk but it bugs me whenever incorrect information is upvoted, especially when it comes at the expense of downvoting the correct information.
The first thing you learn about error handling and security is to not send back error messages that have useful information that hackers could use for penetration; that is programming 101 stuff. Therefore, any decent ASP.NET app does not send back the error messages that the article talks about - the app devs hide those behind, "Oops! Sorry 404!" type stuff. It's super simple and done on almost all ASP.NET sites.
So yes, there is a vulnerability, but this is sort of like the SQL Server bug from 5+ years ago that depended on their being no password for the server admin account. Yes, certain people will be bitten, but by and large "professionals" will have covered for this already.
And no, "the generic error" is not all they need b/c the developer says "Oops 404!" as the generic error or "Oops Server Error 500". Nothing substantial and no information that would give away what happened or why.
This attack doesn't rely on reading information out of errors. You seem remarkably confident about your interpretation of a talk that hasn't been presented yet.
Was it your perception from this report that the flaw here was developers leaking crypto secrets in the text of their errors? You were wrong.
It isn't at all clear how getting the default generic YSOD is going to generate "more data" for the attacker by repetition, unless response time is the data of interest. Is that the case here?
They don't need timing. They don't need to sniff. HMAC doesn't solve the problem. They don't use detailed errors. You should probably read their JSF paper from earlier this year to see the attack pattern they're working with.
Here is a clue: they are using ASP.NET behavior to generate a one bit signal from the target. Their attack requires many tens of thousands of requests. That's about as much as I can say.
As somebody who is familiar with some details of the vulnerability, I can assure you that the error reporting configuration is irrelevant.
The HTTP response code is the only information needed for the attack.
200 vs. 500 vs. 404