6 ms·

'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

38 points by Uncle_Sam 16y ago

tedunangst 16y ago
Or you could use SSL and not give a shit. The bug isn't being able to decrypt cookies, it's thinking that encrypted cookies are useful.
- tptacek 16y ago
  SSL has absolutely nothing to do with this vulnerability. The encryption being discussed here protects the application from its own users.
  - tedunangst 16y ago
    From the article: "The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys." I'm pretty sure I already know my bank balance, so hiding it from me seems pretty pointless. And like I said, protecting an app from its users by encrypting cookies is a stupid idea from the start.
    - tptacek 16y ago
      I thought "the crypto is protecting the app from its users" was pretty clear, but apparently it wasn't. Let me try it again: "the crypto that Juliano and Thai broke is protecting your bank from you". Is that more helpful? The attack doesn't involve sniffing. Can I ask, what's the psychology of knee-jerk "this vulnerability doesn't matter" comments? You clearly don't know what the flaw is, and that's fine, but I'm really curious: why do you want it to be pointless? Isn't the world a more interesting place when ASP.NET can blow up spectacularly because of a 2-line programming error?
      - tedunangst 16y ago
        OK, fine, the crypto is protecting the bank from me. It's still stupid. Don't send users secrets with the implicit promise that they won't tamper with it. It's a lot better for my bank to not send me anything to tamper with. Then it doesn't matter if the crypto works or not, because there's nothing I can tamper with. Why is it pointless to point out that there's a better way to build apps that avoids the entire flaw?
        tptacek 16y ago
        What's your point? That you don't like the way ASP.NET, J2EE/JSF, Rails, and Django work? You started out saying "just use SSL and you don't have this problem". You were wrong. Then you said "but all I can see is stuff I already know". You were wrong there too. Now you've backpedaled all the way to first principles. Sure, now you're not wrong; indeed, if everyone just redesigns their applications not to use AES at all, they will in fact be safer.
        tedunangst 16y ago
        OK, the jab about SSL was misguided. On my first read of the article, I thought it was about protecting cookies from eavesdroppers. I didn't consider people attacking the app because I thought it was kind of silly that you'd leave yourself open to that. Oh well, turns out I'm wrong and the world is crazy.
tptacek 16y ago
I wrote a comment about this a year and a half ago, and I'm just go to re-paste it verbatim here: You want sick? Here's sick. An AES block is 16 bytes long. You want to encrypt the lyrics to "Yellow Submarine". You can't just repeat AES for each 16 byte block, because then you can tell where the words "yellow submarine" --- 1 AES block --- occur: they'll encrypt to the same block. So you use CBC mode, XOR'ing each plaintext block to the previous ciphertext block, creating a unique ciphertext every time you encrypt those lyrics. But "Yellow Submarine" is 902 characters long; the last block is 6 bytes short. So you pad the message which a count of the pad characters --- 06h 06h 06h 06h 06h 06h. With me so far? Decrypt the message. Check the padding: it should repeat as many times as the value of the last byte. If not, you decrypted badly. Send an error to that effect. Hey guess what! I can decrypt parts of your message! If I stick a random AES block in your message, it will scramble the padded block. Every once in awhile, that scrambled message will end in 01h. 01h is valid padding. The message will be gibberish, but you at least won't tell me it had bad padding. You wouldn't tell me if you decrypted to bad padding if I generated 02h 02h either. But that's much less likely than 01h. Now I know that your plaintext XOR my random block produces a last byte of 01h. Solve. Now my point: this is actually way old news --- back to Bleichenbacher and Vaudenay and probably before that (I'm not the resident expert) --- but attacks like this have broken peer-reviewed versions of TLS, the most peer-reviewed crypto protocol ever designed. Don't build crypto. Some quick back-story Vaudenay described this attack almost 10 years ago, in this paper: http://lasecwww.epfl.ch/php_code/publications/search.php?ref=Vau02a http://lasecwww.epfl.ch/php_code/publications/search.php?ref... It's very readable for a crypto paper. We blogged about padding oracles in our AES post 2 years ago. Then Thai Duong and Juliano Rizzo independently re-discovered them and went on a tear looking for software vulnerable to the flaw. Just a few months ago, they busted up Java Server Faces with the exact same vulnerability. The nature of the attack is this: in almost all modern web frameworks, session storage can be stored "clientside" in fat cookies. These cookies are encrypted so that users can't modify their contents. Because of this vulnerability, attackers can take legitimate fat cookies, decrypt them, and (often) modify their contents. Those attackers can then (say) issue fraudulent payments, change their user ID, alter their account balance, or inject SQL or Javascript into code that never expected to be exposed to attack because it was guarded with AES. This vulnerability is also a galactic pain in the ass to address: * It exploits the common-case error handling behavior of most web stacks (generate exception, do something that visibly indicates to the user that an exception was generated) * It's not enough just to stifle the errors; you have to make observable behavior in the bad-padding case identical to the good-padding case. * If you're MAC'ing packets as well as encrypting them, you also have to make sure the timing is the same in the bad-padding and good-padding case, which means you have to "pretend" to MAC the bad-padding packets, which is extremely counterintuitive (you have to catch an exception then pass "something" to a MAC verification routine). Some food for thought It's 2010, vulnerability research is no longer a cottage industry (it's hundreds of millions annually), and we're just now hearing about exploits of one of the simplest crypto flaws there is (there is almost no math to this one). Software security people simply don't read crypto papers. Crypto researchers, at least until recently, don't break software. God only knows how much other scary stuff is buried in those papers waiting for an enterprising bug hunter to try them out.
bdfh42 16y ago
I suspect that there are precious few ASP.NET applications where this is any sort of a risk (millions? - rubbish) and any developer that lets his or her server side code send anything other than a generic error message back to the client in 2010 would be an idiot. "Nothing to see here" as they say.
- tptacek 16y ago
  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.
  - ScottWhigham 16y ago
    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.
    - tptacek 16y ago
      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.
redstripe 16y ago
This looks pretty bad. The standard way to authenticate in an asp.net app, FormsAuthentication.RedirectFromLoginPage(), basically encrypts a username and saves it to a cookie. Any subsequent requests to a site will trust that cookie as long as it decrypts properly.
- brl 16y ago
  Yes, exactly. Among other things, this attack allows you to forge authentication cookies on any ASP.NET application with a 100% success rate.

38 points by Uncle_Sam 16y ago

Or you could use SSL and not give a shit. The bug isn't being able to decrypt cookies, it's thinking that encrypted cookies are useful.

tptacek 16y ago
SSL has absolutely nothing to do with this vulnerability. The encryption being discussed here protects the application from its own users.
- tedunangst 16y ago
  From the article: "The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys." I'm pretty sure I already know my bank balance, so hiding it from me seems pretty pointless. And like I said, protecting an app from its users by encrypting cookies is a stupid idea from the start.
  - tptacek 16y ago
    I thought "the crypto is protecting the app from its users" was pretty clear, but apparently it wasn't. Let me try it again: "the crypto that Juliano and Thai broke is protecting your bank from you". Is that more helpful? The attack doesn't involve sniffing. Can I ask, what's the psychology of knee-jerk "this vulnerability doesn't matter" comments? You clearly don't know what the flaw is, and that's fine, but I'm really curious: why do you want it to be pointless? Isn't the world a more interesting place when ASP.NET can blow up spectacularly because of a 2-line programming error?
    - tedunangst 16y ago
      OK, fine, the crypto is protecting the bank from me. It's still stupid. Don't send users secrets with the implicit promise that they won't tamper with it. It's a lot better for my bank to not send me anything to tamper with. Then it doesn't matter if the crypto works or not, because there's nothing I can tamper with. Why is it pointless to point out that there's a better way to build apps that avoids the entire flaw?
      - tptacek 16y ago
        What's your point? That you don't like the way ASP.NET, J2EE/JSF, Rails, and Django work? You started out saying "just use SSL and you don't have this problem". You were wrong. Then you said "but all I can see is stuff I already know". You were wrong there too. Now you've backpedaled all the way to first principles. Sure, now you're not wrong; indeed, if everyone just redesigns their applications not to use AES at all, they will in fact be safer.
        tedunangst 16y ago
        OK, the jab about SSL was misguided. On my first read of the article, I thought it was about protecting cookies from eavesdroppers. I didn't consider people attacking the app because I thought it was kind of silly that you'd leave yourself open to that. Oh well, turns out I'm wrong and the world is crazy.

tptacek 16y ago

I wrote a comment about this a year and a half ago, and I'm just go to re-paste it verbatim here: You want sick? Here's sick. An AES block is 16 bytes long. You want to encrypt the lyrics to "Yellow Submarine". You can't just repeat AES for each 16 byte block, because then you can tell where the words "yellow submarine" --- 1 AES block --- occur: they'll encrypt to the same block. So you use CBC mode, XOR'ing each plaintext block to the previous ciphertext block, creating a unique ciphertext every time you encrypt those lyrics. But "Yellow Submarine" is 902 characters long; the last block is 6 bytes short. So you pad the message which a count of the pad characters --- 06h 06h 06h 06h 06h 06h. With me so far? Decrypt the message. Check the padding: it should repeat as many times as the value of the last byte. If not, you decrypted badly. Send an error to that effect. Hey guess what! I can decrypt parts of your message! If I stick a random AES block in your message, it will scramble the padded block. Every once in awhile, that scrambled message will end in 01h. 01h is valid padding. The message will be gibberish, but you at least won't tell me it had bad padding. You wouldn't tell me if you decrypted to bad padding if I generated 02h 02h either. But that's much less likely than 01h. Now I know that your plaintext XOR my random block produces a last byte of 01h. Solve. Now my point: this is actually way old news --- back to Bleichenbacher and Vaudenay and probably before that (I'm not the resident expert) --- but attacks like this have broken peer-reviewed versions of TLS, the most peer-reviewed crypto protocol ever designed. Don't build crypto. Some quick back-story Vaudenay described this attack almost 10 years ago, in this paper: http://lasecwww.epfl.ch/php_code/publications/search.php?ref=Vau02a http://lasecwww.epfl.ch/php_code/publications/search.php?ref... It's very readable for a crypto paper. We blogged about padding oracles in our AES post 2 years ago. Then Thai Duong and Juliano Rizzo independently re-discovered them and went on a tear looking for software vulnerable to the flaw. Just a few months ago, they busted up Java Server Faces with the exact same vulnerability. The nature of the attack is this: in almost all modern web frameworks, session storage can be stored "clientside" in fat cookies. These cookies are encrypted so that users can't modify their contents. Because of this vulnerability, attackers can take legitimate fat cookies, decrypt them, and (often) modify their contents. Those attackers can then (say) issue fraudulent payments, change their user ID, alter their account balance, or inject SQL or Javascript into code that never expected to be exposed to attack because it was guarded with AES. This vulnerability is also a galactic pain in the ass to address: * It exploits the common-case error handling behavior of most web stacks (generate exception, do something that visibly indicates to the user that an exception was generated) * It's not enough just to stifle the errors; you have to make observable behavior in the bad-padding case identical to the good-padding case. * If you're MAC'ing packets as well as encrypting them, you also have to make sure the timing is the same in the bad-padding and good-padding case, which means you have to "pretend" to MAC the bad-padding packets, which is extremely counterintuitive (you have to catch an exception then pass "something" to a MAC verification routine). Some food for thought It's 2010, vulnerability research is no longer a cottage industry (it's hundreds of millions annually), and we're just now hearing about exploits of one of the simplest crypto flaws there is (there is almost no math to this one). Software security people simply don't read crypto papers. Crypto researchers, at least until recently, don't break software. God only knows how much other scary stuff is buried in those papers waiting for an enterprising bug hunter to try them out.

bdfh42 16y ago

I suspect that there are precious few ASP.NET applications where this is any sort of a risk (millions? - rubbish) and any developer that lets his or her server side code send anything other than a generic error message back to the client in 2010 would be an idiot. "Nothing to see here" as they say.

tptacek 16y ago
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.
- ScottWhigham 16y ago
  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.
  - tptacek 16y ago
    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.

redstripe 16y ago

This looks pretty bad. The standard way to authenticate in an asp.net app, FormsAuthentication.RedirectFromLoginPage(), basically encrypts a username and saves it to a cookie. Any subsequent requests to a site will trust that cookie as long as it decrypts properly.

brl 16y ago
Yes, exactly. Among other things, this attack allows you to forge authentication cookies on any ASP.NET application with a 100% success rate.