To be fair, the "millions" does seem quite hyperbolic, at least insofar as it assumes every ASP.NET app will be in grave and imminent danger. Plenty of ASP.NET devs don't use cookies at all beyond the default behavior, which is to track session id. Modifying that wont be terribly useful without another known session to hijack, I'd think.
Bruce Leidl ('brl) works with Juliano, and just commented that this is a 100%-effective attack against any ASP.NET application's authentication.
It's OK to be skeptical about things (god knows I am), but it's important to be clear about where your actual knowledge ends. I think one thing that's confusing people is that the talk hasn't actually been presented yet.
Between your comments, brl's, and the JSF paper, its clear enough how this works now. Thanks.
I still suspect this is being overhyped. Being able to forge the auth cookie 100% of the time doesn't change the fact that you need a server-recognized value to actually forge.
This seems like it could indeed badly damage apps that stash important things in client state expecting it to be secure, but a lot of bog standard asp.net apps will be unscathed, unless I'm missing some killer detail. We'll see.
Edit: If the contents of a forms authentication cookie are not session-bound and assume that crypto == safe, that could certainly make things interesting. No idea though.
Edit2: Increasingly convinced that this could enable devastating attacks on forms auth (a large proportion of asp.net apps to be sure) - the content of a forms auth ticket appears to be trivially constructed.
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
The generic error is all they need. Next time, don't write "nothing to see here" when all you did was skim a news story.
To be fair, the "millions" does seem quite hyperbolic, at least insofar as it assumes every ASP.NET app will be in grave and imminent danger. Plenty of ASP.NET devs don't use cookies at all beyond the default behavior, which is to track session id. Modifying that wont be terribly useful without another known session to hijack, I'd think.
Bruce Leidl ('brl) works with Juliano, and just commented that this is a 100%-effective attack against any ASP.NET application's authentication.
It's OK to be skeptical about things (god knows I am), but it's important to be clear about where your actual knowledge ends. I think one thing that's confusing people is that the talk hasn't actually been presented yet.
Between your comments, brl's, and the JSF paper, its clear enough how this works now. Thanks.
I still suspect this is being overhyped. Being able to forge the auth cookie 100% of the time doesn't change the fact that you need a server-recognized value to actually forge.
This seems like it could indeed badly damage apps that stash important things in client state expecting it to be secure, but a lot of bog standard asp.net apps will be unscathed, unless I'm missing some killer detail. We'll see.
Edit: If the contents of a forms authentication cookie are not session-bound and assume that crypto == safe, that could certainly make things interesting. No idea though.
Edit2: Increasingly convinced that this could enable devastating attacks on forms auth (a large proportion of asp.net apps to be sure) - the content of a forms auth ticket appears to be trivially constructed.
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