Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Crypto Attack Affects Millions of ASP.NET Apps

CmdrTaco posted about 4 years ago | from the duck-and-cover dept.

Encryption 156

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."

cancel ×

156 comments

Sorry! There are no comments related to the filter you selected.

Who knew! (-1, Redundant)

phyrexianshaw.ca (1265320) | about 4 years ago | (#33562530)

What a surprise, encryption has flaws!

Re:Who knew! (1)

axx (1000412) | about 4 years ago | (#33562594)

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

Re:Who knew! (3, Insightful)

WrongSizeGlass (838941) | about 4 years ago | (#33562656)

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:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563488)

I'm pretty sure this .NET is server-side.

Re:Who knew! (5, Interesting)

ammorais (1585589) | about 4 years ago | (#33562654)

What a surprise, encryption has flaws!

RTFA. It's not about flaws in encryption. It's about "ASP.NET's implementation of AES has a bug in the way that it deals with errors when the encrypted data in a cookie has been modified"
So it's the ASP.NET AES implementation that has flaws. The problem seems to be that the errors reveal enough information about how to decrypt the data.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33562800)

Who the hell is dumb enough to send "unfriendly" error messages in the first place???

The only time you send stack traces is when your site is in pre-production/development phases.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33562904)

Sadly, many many people.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563162)

Stack dumps make me look smart. Chics dig stack dumps.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563658)

Stack dumps make me look smart. Chics dig stack dumps

And that is why you are fated to die a virgin

Re:Who knew! (3, Insightful)

BitZtream (692029) | about 4 years ago | (#33563898)

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.

Re:Who knew! (4, Informative)

Anonymous Coward | about 4 years ago | (#33562736)

What a surprise, encryption has flaws!

Nope, the cryptography is still flawless. ASP.NET just failed to use it correctly. AES-CBC would be perfectly secure if they used MAC to authenticate the data. MACs have been a critical part of crypto protocol design since the "DES ages" and padding oracle attacks have been known since 2002.
Just like RC4 is still secure if used properly, but WEP is broken due to protocol flaws (the problems with RC4 were known before WEP was designed).

So kids, make sure you always use MAC with your ciphers.

Re:Who knew! (1, Informative)

Anonymous Coward | about 4 years ago | (#33562834)

ASP.NET uses a hashed message authentication code by default. So not sure what point you are trying to make by talking about them as a solution.
Source: see 'protection' at http://msdn.microsoft.com/en-us/library/1d3t3c61.aspx [microsoft.com]

Re:Who knew! (2, Insightful)

Anonymous Coward | about 4 years ago | (#33563054)

I'm going to be a crypto pedant here for a moment. Don't use the words "perfectly secure" to refer to any cryptographic scheme other than a true one-time pad. The phrase "perfect security" has a *very* specific meaning in cryptology, defined by C. E. Shannon, and the only thing that meets the definition is a true one-time pad (a symmetric key that is perfectly random - the odds of any particular bit in the string being 1 are exactly 50% - and longer than the message it encrypts and is only used for that one message).

AES is extremely secure (no one who publishes has found a practical attack against it that's easier than brute force, and all the best cryptanalysis folks who publish have been trying since the original submission of Rijndael for the AES contest), but it cannot be "perfect" - because a brute force attack will work. Even a brute force attack won't work against a one-time pad.

Re:Who knew! (0)

icebike (68054) | about 4 years ago | (#33563168)

Even one time pads are susceptible to brute force attacks.

The only way you can make the assertion that they are not is to assume the original message was simply random characters, with no obvious language.

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.

Re:Who knew! (1)

colinrichardday (768814) | about 4 years ago | (#33563238)

Which human readable text? The point of trying to brute force a one-time pad encoded message (without having access to the pad itself) is that any message of the same length is just as possible. How do you determine the actual message from all of the other possible messages of the same length?

Re:Who knew! (0)

icebike (68054) | about 4 years ago | (#33563320)

Any message being possible only makes sense when you define "and message" to include total nonsense strings of text.

You can use the 5th grade test to see if your brute force attack worked.

Had the output to a 5th grader, and if can read it out loud your brute force worked.

If I handed you two messages:

1) The account numbers to the secret Swiss Bank account are 3432376482 and 367282345. Please do not access the accounts more than once a month.

--and
2) aljkhwerh;lkjerja;ke ;werj ;kljr;qijaof; ;ileurie;oir;iw;; ;lekjeri ;wkrie9jg; ;'keroje;kj ;wljejrei ioj;akjie;titj ww';ler;lj e;kerjw

Which one of those would your 5th grader choose?

Re:Who knew! (4, Insightful)

Mongoose Disciple (722373) | about 4 years ago | (#33563380)

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! (1)

icebike (68054) | about 4 years ago | (#33563624)

Would any message of the same length make sense?

Re:Who knew! (1)

Lokitoth (1069508) | about 4 years ago | (#33563718)

You are being pedantic. He clearly means any sensical message of the same length. Which makes one time pads more secure as the message length increases (provided the key size is still longer than the message).

Re:Who knew! (3, Informative)

Mongoose Disciple (722373) | about 4 years ago | (#33563876)

Any, no. But certainly there are many, many messages of the same length that would make sense.

To put it another way, let's say a /. sig is 120 characters (I don't know the exact number offhand) and that a million /. users have sigs, all of which are different and make some kind of sense. If I encrypt one with a one-time pad, there's no way for you, using brute force, to figure out which user's sig it is -- each of those million possibilities (and many, many more) would appear equally possible to your best discernment.

You're saying that as long as you come up with a message that looks like words and forms a sentence that's the right length, you've successfully brute forced the pad. That's not remotely the case.

Re:Who knew! (1)

MaskedSlacker (911878) | about 4 years ago | (#33564228)

*Boggle*

Really?

Let's try an experiment since you seem too thick to understand this. Here is my encrypted message:
zxc
I'll give you a hint that the clear text is an English word, and the one-time pad used to encrypt it used only letters (so we're talking modulo 26 addition here). This means that there are 17,576 one time pads I could have used.

You're right that the vast majority of those one-time pads can be eliminated, because they give garbage decrypted text. Among these would be:
abc, ujc, asd, qwe
Applying these one-time pads to the cipher text is left as an excersize to the reader.

However, there is a large subset of the 17,576 possible one-time pads that produce readable clear text, among them:
fpy, rwi, yco
which respectively decrypt the cipher text to:
the, hat, bum

Can you tell which was the real clear text? No you can't. And for longer messages you can't tell between 'Bill ate the cat' and 'Bill fed the cat.' from a cipher text of 'era and qwe omn' because there is a possible one-time pad for each.

Re:Who knew! (1)

slimjim8094 (941042) | about 4 years ago | (#33564944)

OK. You don't get it. Let me try and explain it a little bit better - admittedly, the other explanations are a bit lacking.

A one time pad is an encryption key of the same length as the original message. For a 15 character message, I need a 15 character pad. But I can construct a pad to give me *every single message of length 15*. So I have no way of figuring out which one it is, because I can make it say *anything*, as long as the length is right.

So I could try and brute-force a message of length 10, but I'd be able to "decrypt" every word and phrase of length 10.

*This* is why OTP is the only 'secure' encryption - it's precisely because the tumblers on our virtual lock never fall into place, since they often do anyways.

Re:Who knew! (2, Insightful)

rcuhljr (1132713) | about 4 years ago | (#33563400)

I don't think you're getting it.
Brute forcing a one time pad makes "The account numbers to the secret Swiss Bank account are 3432376482 and 367282345. Please do not access the accounts more than once a month." just as likely as "The account numbers to the secret Swiss Bank account are 123456789 and 987654321. Please do not access the accounts more than once a month." and you have no way of telling which one was the original message.

Re:Who knew! (1)

rcuhljr (1132713) | about 4 years ago | (#33563464)

Eh nevermind just ignore my post, I just saw your other 'pendant' comment; you have to be a troll.

Re:Who knew! (1, Insightful)

Anonymous Coward | about 4 years ago | (#33563508)

I don't think you know how a one time pad works - trying to brute force a one time pad will yield both "The account numbers to the secret swiss bank account are 12345 and 67890" and "The killer is staying in the Slashdot hotel, room number 1235", along with literally every permutation of letters and numbers (or whatever you're encrypting) that can be possibly produced. The only attacks against OTP are side attacks, against things such as your random number generator and transmission of the key.

Re:Who knew! (0)

icebike (68054) | about 4 years ago | (#33563676)

I know exactly how a one time pad works. EXACTLY. Stop asking the question.

Brute force attacks yield mountains of garbage, and a few nuggets of highly probable deciphers, of which usually only one makes language and contextual sense.

Re:Who knew! (2, Informative)

0123456 (636235) | about 4 years ago | (#33563766)

I know exactly how a one time pad works.

No you don't, if your posts on the subject are anything to go by.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563824)

I don't think you have a clue how a one time pad works, based on your comments here. You can make the message "qwerty iopas fghjkl xcvbn qwertyui" decrypt to anything which has the same length, so you could get something like "The attack will happen this Monday" AND "The attack will happen this Friday" AND "icebike does not understand OTPs!!"

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563512)

According to government statistics, if you mean 5th graders here in the US, they wouldn't be able to read either one.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563270)

For every plaintext of given length and every 1TP ciphertext of the same length there is a trivially obtainable 1TP key that converts the latter into the former.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563278)

Even one time pads are susceptible to brute force attacks.

This is outright wrong. If it's susceptible to brute force attacks, it's not a one time pad.

Reason being, if you don't know the key, you can decrypt a one-time-pad to produce any possible message by appropriately changing the key.
This is also how OTP can provide deniable encryption: if you have the ciphertext, you can construct another OTP key that decrypts to totally different material, at your choice.

Re:Who knew! (0)

icebike (68054) | about 4 years ago | (#33563350)

Any possible message is far from any reasonable message. A random sting of characters is not the sort of thing people encrypt.

Try to put this in real world terms here, and stop being such a pendant.

Re:Who knew! (2, Insightful)

Artefacto (1207766) | about 4 years ago | (#33563594)

Try not to be ignorant, not to say idiotic. "Any possible message" includes "any reasonable message". Come back when you understand Shannon's theorem.

Re:Who knew! (0)

Anonymous Coward | about 4 years ago | (#33563902)

a pendant is something that hangs, for example a locket hanging from a chain.

Did you mean to say pedant? http://en.wikipedia.org/wiki/Pedant [wikipedia.org] . Oh, whoops - guess I was a pedant...

Re:Who knew! (2, Insightful)

compro01 (777531) | about 4 years ago | (#33563448)

if the original was normal human readable text it becomes immediately obvious when your brute force succeeds

You will get any possible message of the same length, including several normal human readable ones. Barring having other information, there isn't any way to determine which one is the actual message. For example, if you have a 28 character message, attempting to brute force the OTP it will give you both of the results below, both equally plausible, along with many others which are equally plausible.

meeting canceled, stay home.
meeting at 10:00, room 1103.

Re:Who knew! (4, Insightful)

zindorsky (710179) | about 4 years ago | (#33563524)

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! (1)

Svartalf (2997) | about 4 years ago | (#33565084)

This presumes you can get the proper plaintext determined that way.

With a one-time pad, you're talking about something where you can conceivably get "intelligible" content and it could be the message with chaff around it- or it could be a false positive. Unless you know the plaintext from before it was encoded (along with any chaff measures you might have applied to the selfsame...)- you can't be sure you've got the message.

don't roll your own (0)

Anonymous Coward | about 4 years ago | (#33563608)

So kids, make sure you always use MAC with your ciphers.

There are actually a couple of things that people should probably generally know:

        http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

        http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
        http://rdist.root.org/2010/09/10/another-reason-to-mac-ciphertext-not-plaintext/

And as for MACs: don't try to roll your own, but use HMAC. Doing a simple (m = plaintext, k = key) solution as on of the following

        H(k || m)
        H(m || k)

is not secure even though many people think they are "salting" things with a key of some kind:

        http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/

Re:Who knew! (1)

bluefoxlucid (723572) | about 4 years ago | (#33564044)

Often it's repeated that programmers should not implement their own crypto libraries. I've been considering writing and public-domaining a cyrpto library front-end (an API library) that itself takes back-end plug-ins to implement stream/block cipher (or stream cipher AES ... basically a PRNG with a fixed IV having its output AES encrypted, and using the stream as a keystream i.e. XOR vs plaintext to make one-time-pad). Yes, there's crypto libraries now; but mine would explicitly have code and documentation explaining the mitigation mechanisms for algorithmic flaws and other implementation details that avoid brokenness.

The point here would be 1) to implement non-flawed algorithms (i.e. AES) in a documented, non-flawed way; and 2) to implement flawed algorithm mitigation.

For example, with RC4 you can statistically discover key bytes with weak IVs. In WEP the attacker assumes the first byte is 0xAA; then, for 24 bit IVs, all he needs is an IV (a+3, n-1, X) key index (a), element space (n), and any X. With 8 bit elements (1 byte at a time), this is n=256.

To mitigate this, make sure (n) never equals (256); also making sure (a) never equals 3 will prevent the attacker from figuring out the first word of the key, which is needed to find the second (which you need to find the third etc.), totally eliminating the starting point. This means you can theoretically allow (a!=3,n-1=255,X) or (a=3,n-1!=255,X) and be secure. If you simply leave (n-1!=255), you eliminate 0.0056 bits of the 24 bit IV; if you leave (a!=3) as well, you eliminate 0.011 bits. If you eliminate the initialization case (3,255,X), you only lose 1.7 x 10^-7 bits; however, if the attacker knows/can guess the second byte of the WEP header, your security falls again.

The best security for RC4 is to just ban (n-1=255), leaving 23.994 bit IVs instead of 24 bit IVs. If other weak conditions are present, we'll also examine their cases and detect/alter them as well. Of course, you can't just make n-1=255 imply n-1=254; instead, generate a random value between 1 and 254. If you think that generating a random 8 bits is faster, then have a custom get_random_RC4_IV() that does that and, failing that, subtracts a random value between 1 and 255 when it encounters n-1=255.

All encryption algorithms implemented for that library would be implemented and documented as such. Here's the attack. Here's the conditions. Here's the conditions we can eliminate. Here's the impact on entropy. Here's other considerations. Here's what considerations we ignore and why. Here's our final implementation plan and why we feel it's optimal. Here's the impact on entropy.

And that is why YOU shouldn't be writing your own AES implementation, or whatever else.

Re:Who knew! (1)

suomynonAyletamitlU (1618513) | about 4 years ago | (#33564700)

So kids, make sure you always use MAC with your ciphers.

Yes, I've always been a big proponent of MAC and c.

Nyuck Nyuck (0)

Anonymous Coward | about 4 years ago | (#33562606)

I never could find how session ids were generated, suffice to say I didn't trust MS to implement them properly.

I ended up rolling my own session management in "old asp" using a COM wrapper to crypto api for access to the RNG + hashing functions, and allowed for a SQL backend, so we could run load-balanced servers and still have a session. I would do an application-key hmac on the output of the RNG (which I also didn't trust), concatenated with a knowable, sequential, unique part.

I don't use ASP anymore.

Re:Nyuck Nyuck (1)

lwriemen (763666) | about 4 years ago | (#33563326)

OK, but why are you using Windows if you don't trust Microsoft?

Oh come on... (2, Funny)

santax (1541065) | about 4 years ago | (#33562618)

Just give us the exploit!

Re:Oh come on... (1)

mcgrew (92797) | about 4 years ago | (#33563316)

That's why I never bank over the internet, and do as little online buying as possible. If I have to buy online I use a prepaid credit card.

So while this is interesting to me, I'm in no danger.

Re:Oh come on... (0)

Anonymous Coward | about 4 years ago | (#33564420)

Yeah, it's way safer to give your CC to the clerk so he can easily scan it and copy your card.

Not so bad after all... (4, Informative)

EvilRyry (1025309) | about 4 years ago | (#33562624)

>If the padding is invalid, the error message that the sender gets will give him some information about the way that the site's decryption process works.

This is one reason you should send user friendly error messages to your consumers instead of stack traces, stack traces can contain details that an attacker could use against you. It sounds like you're safe if you're following best practices already.

Re:Not so bad after all... (1)

Mongoose Disciple (722373) | about 4 years ago | (#33562772)

Exactly. If the web devs are incompetent enough to let an end user see a stack trace error message, you've got much bigger problems than this hack. Professionally, it's about the equivalent of setting your root password on a machine to 'password'.

Re:Not so bad after all... (1, Redundant)

Neil Watson (60859) | about 4 years ago | (#33562852)

> Professionally, it's about the equivalent of setting your root password on a machine to 'password'.

That certainly never happens.

Re:Not so bad after all... (1)

nametaken (610866) | about 4 years ago | (#33562976)

If the attacker requires the stack trace, I feel better about this already. Is that a requirement of this exploit?

While I do see unhandled exceptions kicking stack traces to remote clients far too often, at least I know I've always covered that.

Re:Not so bad after all... (3, Informative)

KarmaMB84 (743001) | about 4 years ago | (#33563144)

The attack apparently relies on analyzing errors thrown by the application. If an app wraps everything in a try-catch and only rethrows if the app is in development and a generic error message to the public, it's doubtful they could ever pull off an exploit.

Re:Not so bad after all... (1)

owlstead (636356) | about 4 years ago | (#33565066)

Not so, you are forgetting side channel attacks, in particular side channel attacks based on computation time.

I.e. different exceptions thrown at different locations will take a specific amount of time, which can be leaked and used by performing statistical analysis.

Sounds far fetched, but it works beautifully in practice. Of course, it is still way better than throwing stack traces around.

Oh, and make sure the user gets an easy to understand message and that the server *logs* the exception.

That's some dumb stuff to be storing in cookies... (2, Insightful)

rescendent (870007) | about 4 years ago | (#33563374)

"The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. "

Re:Not so bad after all... (1)

johann21 (1701990) | about 4 years ago | (#33563434)

> This is one reason you should send user friendly error messages to your consumers instead of stack traces...

Right, and isn't the default CustomerErrors setting in ASP.NET set to RemoteOnly? Meaning that that the exception & stack trace are only sent when you are browsing from localhost? If you were dumb enough to send full errors from a production system, then you deserve to have your application exploited by this.

Re:Not so bad after all... (2, Informative)

Mongoose Disciple (722373) | about 4 years ago | (#33563588)

You are correct. (I think the property's called CustomErrors, but otherwise you're dead on.)

You'd have to manually decide you wanted your end users to see unfriendly error messages for the exploit as described to work. In other words, being negligent isn't sufficient for this to work -- you need to do something actively stupid.

I believe the same is true for the JSF exploit this is based on, but it's been a year or two since I've touched JSF at this point.

when it comes to anything important: (0, Troll)

Kristopeit, M. D. (1892582) | about 4 years ago | (#33562636)

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

Re:when it comes to anything important: (5, Insightful)

TheNinjaroach (878876) | about 4 years ago | (#33562734)

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.

Re:when it comes to anything important: (-1, Troll)

Kristopeit, M. D. (1892582) | about 4 years ago | (#33562872)

so in that case, given you are admittedly not an expert, the lowest "POSSIBLE" layer for you would be using an existing implementation.

work within your means. yours are getting smaller every day it seems.

Re:when it comes to anything important: (1, Insightful)

Anonymous Coward | about 4 years ago | (#33562966)

I originally modded you funny, but I'd like to retract and mod you "scary".

Now you could implement HMAC using other OpenSSL primitives, and that would be less than the highest possible level. But you WOULDN'T DO THAT!

When it comes to crypto, use the highest possible layer. I've never used ASP, and i'm rather glad, but before now I would have guessed it exposed encryption libraries to allow you to send a session cookie over HTTPS/HTTP only.

Re:when it comes to anything important: (-1, Troll)

Kristopeit, M. D. (1892582) | about 4 years ago | (#33563004)

ur mum's face is scary

Re:when it comes to anything important: (0)

Anonymous Coward | about 4 years ago | (#33562896)

When it comes to encryption, this is widely regarded as a really, really bad idea. Leave encryption to the experts.

Re:when it comes to anything important: (-1, Troll)

Kristopeit, M. D. (1892582) | about 4 years ago | (#33562986)

you're dismissing your ability to BE AN EXPERT.

so, are you lazy or dumb, idiot?

Re:when it comes to anything important: (0)

Anonymous Coward | about 4 years ago | (#33563062)

A wise man knows what he doesn't know. If you know enough about cryptography to make a good implementation, then your job does not involve writing web applications.

Re:when it comes to anything important: (1)

M. Kristopeit (1890764) | about 4 years ago | (#33563164)

i'm a systems engineer. i develop web applications that are not broken into.

the wisest man knows everything he needs to know.

you're an idiot.

Re:when it comes to anything important: (3, Insightful)

jpapon (1877296) | about 4 years ago | (#33563294)

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:when it comes to anything important: (1)

Thud457 (234763) | about 4 years ago | (#33563308)

Typical slasdot "jack of all trades, master of all "

Wait, that's not how the saying goes...

Re:when it comes to anything important: (1)

M. D. Kristopeit (1890086) | about 4 years ago | (#33563200)

"Troll" to suggest to do something right... that would result in not being exploited in the ways outlined by this story.

slashdot = stagnated

you're all idiots.

Re:when it comes to anything important: (0)

Anonymous Coward | about 4 years ago | (#33563328)

M. Kristopeit (1890764) writes: Alter Relationship on Monday September 13, @01:39PM (#33563164)

i'm a systems engineer. i develop web applications that are not broken into.

the wisest man knows everything he needs to know.

you're an idiot.

lol who's an idiot? God you need some new material, I'm guess you got tired of saying "Invented by Shampoo" eh?

So Mr. Non-idiot, what are the web applications that you've developed that no one here can break into? Inquiring idiotic minds would like to know.

Re:when it comes to anything important: (0, Troll)

M. D. Kristopeit (1890086) | about 4 years ago | (#33563364)

i'm guess you no speak the english no good, idiot

Re:when it comes to anything important: (1)

Michael D Kristopeit (1887500) | about 4 years ago | (#33563446)

look who's calling me "God", idiot.

you get NOTHING.

Re:when it comes to anything important: (1)

iamhigh (1252742) | about 4 years ago | (#33563548)

Where's the "back to 4chan" mod?

Re:when it comes to anything important: (1)

AusIV (950840) | about 4 years ago | (#33564710)

Here's the thing: In the working world if you roll your own implementation and your implementation gets compromised then you can probably expect to be fired. If you use a widely deployed, standard implementation and that implementation gets compromised you not only have someone to blame, but your employer would have a hard time finding someone to replace you that wouldn't have made the same mistake.

Re:when it comes to anything important: (1)

Kristopeit, Michael (1892492) | about 4 years ago | (#33564970)

agreed. so you just have to not implement anything that can get compromised.

it isn't hard.

Patch? (0)

Anonymous Coward | about 4 years ago | (#33562648)

When will MS release a patch for this? This could be really, really bad. I think it still requires that an attacker capture a cookie in order to steal the session, but not totally sure about that?

Anyone know just how serious this is?

Re:Patch? (2, Interesting)

Anonymous Coward | about 4 years ago | (#33562712)

Default ASP.NET credentials are basically a signed username with an expiration date. So if an attacker can figure out your encryption, they should be able to change their identity. So user "Joe Bob" should be able to become user "Super Admin" by decrypting his cookie, editing his user id, and re-encrypting it.

Re:Patch? (0)

Anonymous Coward | about 4 years ago | (#33563498)

Exactly, this is what they do after recovering the keys with another flaw.

Re:Patch? (1)

UnknowingFool (672806) | about 4 years ago | (#33562790)

My understanding is that it allows an attacker to masquerade as another user. So if they can intercept your network (like public wifi) they can intercept your session and pretend to be you. If you've decided to pay your bills online at the local cafe for example and forget to signoff, they can take your session and start making their own payments.

So... (1)

fuzzyfuzzyfungus (1223518) | about 4 years ago | (#33562672)

Will more of the script kiddie hacking packages have "hardcore" venomous snake related names and graphics(ASCII for the l33t) or "hilarious" anal violation pun derived ones?

Re:So... (1)

Culture20 (968837) | about 4 years ago | (#33563228)

Will more of the script kiddie hacking packages have "hardcore" venomous snake related names and graphics(ASCII for the l33t) or "hilarious" anal violation pun derived ones?

Neither. ASP is short for aspie. The hacking packages will have very descriptive names with poor user interfaces. Also, I don't understand what's so funny about violations of "am/are not a lawyer". Pretending to give real legal advice can get you in hot water. In some countries, you could get sent to prison and get "am/are not a lawyer"-ly violated.

flawed by design (0)

Anonymous Coward | about 4 years ago | (#33562708)

Recently I reviewed code of a colleague.
"Q: Why does the app store authorization i cookies?"
"A: But it's encrypted!"

Only a idiot would store "important stuff" in cookies. It's only a matter of time to break it.

Re:flawed by design (1)

ysth (1368415) | about 4 years ago | (#33563032)

The argument for storing important stuff in cookies is to save the time and other expenses of a database or key-value store lookup of a session id on every request. Given secure encryption, it's a reasonable choice; the only good argument against it is that the encryption might not be as secure as you think...

100% reliable? (4, Insightful)

Mongoose Disciple (722373) | about 4 years ago | (#33562754)

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:100% reliable? (2, Interesting)

Unequivocal (155957) | about 4 years ago | (#33562882)

100% seemed wrong to me - there seems like a lot of ways to secure against the attack based on the article, but that article seems unreliable in the details as you point out. This attack does seem to require some kind of non-generic output from the ASP server side:

The attack that Rizzo and Duong have implemented against ASP.NET apps requires that the crypto implementation on the Web site have an oracle that, when sent ciphertext, will not only decrypt the text but give the sender a message about whether the padding in the ciphertext is valid.

But what's really not clear is their reference to "side channels" where this information might also be obtained. Perhaps they can gain some understand of the errors from the time it takes the process to return to the query or other metrics?

In terms of speed - they claim they haven't run across a .NET implementation that they couldn't break in 50 minutes (avg 30 min). So this isn't an arbitrary N-time exploit - this is pretty concrete.

Follow the links (2, Informative)

aBaldrich (1692238) | about 4 years ago | (#33562982)

The guy who's giving the conference says:

The first part of the presentation introduces the audience to Padding Oracle Attacks, the cryptographic concepts of the vulnerability, and finally how to exploit it. We also describe the algorithms implemented in POET (Padding Oracle Exploit Tool). POET is the free tool that we released a few months ago which can automatically find and exploit Padding Oracle vulnerabilities in web applications. The second part presents a previously unknown advanced attack. The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API! Finally we demonstrate the attacks against real world applications. We use the Padding Oracle attack to decrypt data and use CBC-R to encrypt our modifications. Then we abuse components present in every ASP.NET installation to forge authentication tickets and access applications with administration rights. The vulnerabilities exploited affect the framework used by 25% of the Internet websites.The impact of the attack depends on the applications installed on the server, from information disclosure to total system compromise.

http://ekoparty.org/juliano-rizzo-2010.php [ekoparty.org]

Re:Follow the links (2, Interesting)

Unequivocal (155957) | about 4 years ago | (#33563262)

Thanks. It also got me thinking that if all this transactional stuff affected by POA is secured in an SSL channel, then it would be hard to get at it to begin with? This attack seems predicated on getting a hold of other's encrypted cookies/password in order to be powerful? This is just a sophisticated man-in-the-middle attack with capability to unwind *one* encryption channel? If SSL is in operation, then this doesn't help?

They claim it would work against many bank sites, but it seems like all bank sites use SSL.

What am I missing?

Re:100% reliable? (3, Informative)

Mongoose Disciple (722373) | about 4 years ago | (#33563068)

Basically, what I'm saying (that I don't think I expressed very clearly in my post that you replied to) is that what they're saying in the article is: If you find an ASP.NET web site (or a JSF one, for that matter) that gives back enough detail in its error messages to malformed/misized crypto packets, you can figure out what the size really should be and make it work from there, and then it'll work every time. It's like saying "A third of the time, it works every time!" Well, that's not 100%.

To put it another way, entering 'admin' and 'admin' will give you full access to 100% of machines that have a user called admin with admin privs that also set their password as admin. Or, the Blaster Worm still owns 100% of Windows 98 machines that haven't been patched in a decade. While technically true it's a useless statistic.

I have not personally encountered a site that would be useful to crack (ASP or JSF) that provides the end user with the kind of error messages they're talking about. There's no reason you couldn't, but you just never would.

More details on the "side channels" would've been nice, since the primary vector they talk about is, in practical terms, useless.

Re:100% reliable? (1)

Dancindan84 (1056246) | about 4 years ago | (#33563156)

They've done studies, you know. 60% of the time it works, every time.

Re:100% reliable? (0)

Anonymous Coward | about 4 years ago | (#33564404)

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

We're 100% dead, it's just a matter of time. Every OS is 100% unreliable. It will crash, it's just a matter of time. 100% of your RAM's bits will fail. It's just a matter of time.

Meh... (2, Insightful)

Anonymous Coward | about 4 years ago | (#33562812)

"The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. The attacker may also be able to create authentication tickets for a vulnerable Web app and abuse other processes that use the application's crypto API."

Anyone storing these things in a cookie, regardless of encryption, needs to step away from the keyboard and stop developing web applications.

This is a non-issue as long as you realize that what is encrypted can be decrypted and keeping that in mind when you store information in a cookie.

Re:Meh... (1)

RightSaidFred99 (874576) | about 4 years ago | (#33565154)

Bullshit. By this "Logic" you can never send or receive..well, anything over a computer network.

If I encrypt data using a session key that only I have, my assumption is only I see that data. If the encryption provider is broken, it's the encryption that's broken, not my code.

Your closing bit of wisdom that what is encrypted can be decrypted is equally facile. By this logic, we shouldn't be sending anything over the internet because SSL can be decrypted, PGP can be decrypted, etc...

1. Point out that "what is encrypted can be decrypted"

2. Shut down teh interwebz

3. ???

4. Profit!

One More Time ( Mod Down For Relevance) (-1, Troll)

Anonymous Coward | about 4 years ago | (#33562954)

Crapware, Inc. [microsoft.com] .

Yours In Vladivostok,
K. Trout

ASP.NET problem? Ha! More like Web App Problem (1)

PenguinBob (1208204) | about 4 years ago | (#33562964)

Seems to be more of a problem with the web application and less of ASP.NET. I mean, sure you can get the encryption key to the cookies, but seriously who puts information like a bank balance or a social security number in a cookie anyway? You should have that stored server-side and only use a session id.

Re:ASP.NET problem? Ha! More like Web App Problem (1)

16K Ram Pack (690082) | about 4 years ago | (#33565126)

Exactly. Anyone who's liable to an attack like this probably has bigger things to worry about in their software.

Fanbois, invoke the monocrop argument! (0)

Anonymous Coward | about 4 years ago | (#33563006)

And all the paid MS astroturfing fanbois started singing in choir the monocrop argument. Uh, no... Wait : .net is not the most successful platform for webapp. Darn. The monocrop fallacy ain't working this time, need to find another fallacy.

Does it affect asp.net user/roles authentication? (0)

Anonymous Coward | about 4 years ago | (#33563206)

I don't generally bother storing anything in a cookie if I can avoid it. There are simply better ways to do things IMHO.

On the other hand, if this will allow someone to spoof an asp.net user session (rather than a roll your own authentication system) then I may be in trouble.

Of course if it needs a verbose error in order to work, I'm fine. FriendlyError.aspx doesn't show stack traces.

Another "exploit" far less powerful than implied (0)

Anonymous Coward | about 4 years ago | (#33563272)

I immediately thought, "how would you even snip some one else's cookie in the first place"? Unless the site was not using SSL and you sniffed it off an open WiFi connection. Maybe this is what they meant by "side channels".

Copied this comment from "asmx86" on the TFA's talkback comments:

Totally useless. If you can sniff in realtime then you can already hijack their session which means accessing the site with user's credential.

So, what they discovered is that you can crack the content of this and see whats in it - which means the application itself must SAVE in these cookies important data, maybe stupid programmers do that - the way to do it is just using the session id and save data server side.

Besides all this, all banks in the world use SSL - try to break that...

Anyway, good research but too much smoke if you know what I mean.

peopleeeeeee helllooooooo? (1)

elvena (1868696) | about 4 years ago | (#33563290)

Cmon!

1) HTTP over SSL - sniff and BREAK that.

2) Important information in the cookies? That person should not be called programmer.

So maybe, MAYBE.. you could apply this to i-want-to-make-this-conference-very-popular-selling-some-smoke-yay.com.ar - thats it.

Whats the big deal here? Good research, sure.. too much SMOKE to publicity some mid-lame conference (Mid basically, there is some very intelligent people at it, wonder why...)

Re:peopleeeeeee helllooooooo? (2, Funny)

John Hasler (414242) | about 4 years ago | (#33563756)

> That person should not be called programmer.

The title is usually "Web developer", is it not?

Oracles are not new (2, Interesting)

bk2204 (310841) | about 4 years ago | (#33563650)

Basically, the problem here is that ASP.NET leaks information about incorrectly decrypted data. If the attacker can get information about the failed decryption, then that's called an oracle. The secure way to handle any sort of decryption error is simply to say "decryption error", regardless of whether it's a padding error, a MAC (message authentication code) error, invalid plaintext, or whatever. You should never give the user the invalid decrypted data or any information about it.

Some SSL/TLS implementations have this problem, too, because they treat a MAC error differently than other decryption errors. Secure implementations, including OpenSSL, have the sane behavior: simply stating that the decryption failed.

A good way to make padding oracle attacks irrelevant is to design protocols to use cipher modes that don't require padding. In other words, instead of using CBC, use CFB. This does have some tradeoffs, but overall CFB is a good choice. (For example, OpenPGP uses CFB.)

More info: (1)

gbrayut (715117) | about 4 years ago | (#33564338)

More details about the attack can be found here [netifera.com] and here [limited-entropy.com] . The original paper indicates that it affects may common libraries:

Another way is to look for known source code keywords. You can start by looking for code that imports low level cryptography libraries such as:

C/C++: OpenSSL, Crypto++
Python: PyCrypto, M2Crypto
.NET: .NET Cryptography, Microsoft CryptoAPI
Java: Java Crypto Extension, BouncyCastle

Then look for routines that perform encryption and decryption. If there’s some code to handle error while decrypting, and/or no sign of MAC usage, then it’s high probability you have found a target for the Padding Oracle attack. Regardless of which method one uses, the most important thing is to analyse and understand the meaning of error messages returned by the target upon receiving mangled ciphertexts. In short, you need to know when the padding is VALID, and when it’s INVALID.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>