New Crypto Attack Affects Millions of ASP.NET Apps

Trailrunner7 writes "A pair of security researchers have implemented an attack that exploits the way that ASP.NET Web applications handle encrypted session cookies, a weakness that could enable an attacker to hijack users' online banking sessions and cause other severe problems in vulnerable applications. Experts say that the bug, which will be discussed in detail at the Ekoparty conference in Argentina this week, affects millions of Web applications."

Comments

Re:Who knew!

[WrongSizeGlass]

This is /. aren't you supposed to say "What a surprise, .NET has flaws!" ?

No, no, no ... you're supposed to say "this doesn't affect Linux". But does it affect Mono?

Re:when it comes to anything important:

[TheNinjaroach]

roll your own at the lowest possible layer. anything else and you're leaving your chin open.

I don't know about that. I'm not out to write my own implementation of OpenSSL anytime soon. Some tasks are simply best left to field experts.

100% reliable?

[Mongoose Disciple]

TFA has a bizarre idea of a "100% reliable" attack:

"It's worth noting that the attack is 100% reliable, i.e. one can be sure that once they run the attack, they can exploit the target. It's just a matter of time."

By that logic, this attack is 100% reliable against (web platform of your choice) too.

Beyond that, this attack requires fairly verbose error messages be sent back to the user of a web application. While I'm sure there do exist some ASP sites where this is the case, I don't think it has been in any of the non-intranet sites I've seen in my career.

It just is not standard in any exposed web site, especially the kind of web site where you would care about customer information getting out, to allow useful error messages reach the end user. It is by far the standard to catch the exceptions, log them on the server, and show the end user a generic error message which would not be helpful in the case of this exploit.

Re:when it comes to anything important:

[jpapon]

If you know enough about cryptography to make a good implementation, then your job does not involve writing web applications.

Very true, but there's no point in feeding trolls, they never get full.

Re:Who knew!

[Mongoose Disciple]

Respectfully, are you sure you understand how a one-time pad works?

Attempting to brute force a one-time pad is as likely to produce a third option:

3) The account numbers to the secret Swiss Bank account are 3435464482 and 363578345. Please do not access the accounts more than once a month.

as your #1. In other words, the same message with totally different account numbers. Or any other message of the same length.

Re:Who knew!

[zindorsky]

Even one time pads are susceptible to brute force attacks.

Nope, absolutely incorrect. That's what makes one-time pads different. When the key length is the same as the plaintext length, it is possible have perfect security. Look up unicity distance.

If the original was normal human readable text it becomes immediately obvious when your brute force succeeds and a subsequent dictionary comparison of each word yields a hit.

But your brute force attack will yield every single possible plaintext (with the same length as the original plaintext). Which is the real one?

For example, if the ciphertext is BWIJAA, your brute force attack will get ATTACK for one key, and GOHOME for another. (And every other 6 character string.)

Re:Who knew!

[BitZtream]

Actually the implementation and use of AES in the ASP.NET framework is fine.

Websites that aren't trapping internal exceptions are bugged.

The problem here is the developer using the code who isn't catching the exception, and worse still allows it to pass through directly to an untrusted 3rd party (the user).

Its not an ASP.NET bug if you proceed to print the password on the screen when users attempt to login, this really isn't any different. The dev using the ASP.NET framework is using it wrong.