Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Encryption Security IT

New Crypto Attack Affects Millions of ASP.NET Apps 156

Posted by CmdrTaco from the duck-and-cover dept.
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."
This discussion has been archived. No new comments can be posted.

New Crypto Attack Affects Millions of ASP.NET Apps More

New Crypto Attack Affects Millions of ASP.NET Apps

Comments Filter:

  • Oh come on... (Score:3, Funny)

    by santax ( 1541065 ) on Monday September 13, 2010 @11:56AM (#33562618)
    Just give us the exploit!

    • Re: (Score:2)

      by mcgrew ( 92797 ) *

      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.

      • I wouldn't say no danger. I don't understand why people think that not using their info online means nobody can access their info online. If your data is stored anywhere, there's a good chance some sequence of events could leak it.

        That said, you've probably reduced your vulnerable surface area, but don't get too confident; incompetence comes in all forms, many of which are probably handling your (and my) data.

  • Not so bad after all... (Score:5, Informative)

    by EvilRyry ( 1025309 ) on Monday September 13, 2010 @11:56AM (#33562624) Journal

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

    • 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: (Score:2, Redundant)

        by Neil Watson ( 60859 )

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

        That certainly never happens.

    • 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... (Score:4, Informative)

        by KarmaMB84 ( 743001 ) on Monday September 13, 2010 @12:38PM (#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.

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

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

            Yeah, but those are a *hell* of a lot harder, and are subject to noise from network jitter, server load, and other variables. The odds of being able to deduce the crypto keys in a reasonable amount of time drop substantially in that case, as you need a lot more requests to smooth out that variability.

            • It's hell of a lot harder, but once the statistical analysis is in place and the right conclusions can be retrieved from them (setup a server and perform tests locally) the computer will do the job. But yes, it will take an awful amount of requests, for practicality a bot net will probably be needed.

        • Re: (Score:1, Insightful)

          by Anonymous Coward

          There is no reason for an application to do that. ASP.NET already does that by default. If an exception occurs the user is presented with a friendly error message that basically says, "something went wrong, try again later." The full error message is written into the logs on the server and can be reviewed by an admin. Said admin can also browse to the site via localhost to get the full error message as it occurs, something remote users will not see.

          This "exploit" relies on the "bank" deploying the site

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

    • > 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: (Score:3, Informative)

        by Mongoose Disciple ( 722373 )

        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.

  • 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?

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

  • 100% reliable? (Score:5, Insightful)

    by Mongoose Disciple ( 722373 ) on Monday September 13, 2010 @12:05PM (#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: (Score:3, Interesting)

      by Unequivocal ( 155957 )

      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 term

      • Follow the links (Score:3, Informative)

        by aBaldrich ( 1692238 )
        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: (Score:3, Interesting)

          by Unequivocal ( 155957 )

          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 u

      • Re:100% reliable? (Score:4, Informative)

        by Mongoose Disciple ( 722373 ) on Monday September 13, 2010 @12:31PM (#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.

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

    • Re: (Score:1)

      by TBBle ( 72184 )

      It's 100% reliable for sites in a vulnerable configuration (ie. the sites the attack targets).

      They presumably mean this to distinguish from attacks which require some level of luck or coincidence (eg. triggering a race condition) to exploit.

      Or for attacks which require a certain state to be achieved but which there's no useful upper bound on when that state might be achieved due to the actions of the attack, eg. a purely passive attack.

      So in short, they're saying that the attack is able to drive it's own pr

  • Meh... (Score:2, Insightful)

    by Anonymous Coward

    "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

    • 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 "wha

    • "This is a non-issue as long as you realize that what is encrypted can be decrypted"...

      That statement is not true in any pragmatical sense. I can create random secret AES key, encrypt a piece of plain text with it and send it to you. Then throw away the key. Call me back when you've decrypted it. You can specify any size, but anything over 10 MB will be a bugger to upload.

      Of course, the cookie should mostly be used to keep session state, not bank details, I'm with you there.

  • 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.
    • Exactly. Anyone who's liable to an attack like this probably has bigger things to worry about in their software.

    • On the one hand you are absolutely right. On the other hand, they make it an encrypted cookie for nothing. If you encrypt something the overall idea with developers will be that it is a safe place to store data.

      So it comes down to 3 culprits:
      - no (H)MAC used to protect the data (always a bad thing, as one of the first posters correctly pointed out): BAD PROTOCOL
      - too much information leaked by default ASP.NET implementation
      - bad decision to put sensitive data in a cookie by the appli

      • - too much information leaked by default ASP.NET implementation

        Incidentally, it's not -- the default behavior is to not provide the information in question, except to a user on the server. That is, a developer running both the web browser and the web server on one machine (a common development situation) would get the information about the mangled ciphertexts, but any remote user would not.

        It's possible to configure error messages such that every user would get the detailed error messages the exploit needs

  • 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...)

  • Oracles are not new (Score:2, Interesting)

    by bk2204 ( 310841 )

    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 implement

    • If you're encrypting then HMACing, then telling them whether HMAC passed or not shouldn't matter much (under normal assumptions), since they can't get it to pass except under very rare conditions (P(2^-n) for n bits of HMAC). But yeah, ideally, you want to leak as little info as possible to the end user.

      I personally also find CBC and padding a little obnoxious and artificial, and used CFB in certain applications of my own that I wrote as learning exercises before such things were widely available - see

    • >You should never give the user the invalid decrypted data or any information about it
      Exactly, you would just send out a properly formatted error message stating a code (implicit to your company) and the rest very simple ...contact your admin etc...as most programmers use codes, but do not need to offer a whole stack trace anymore.

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

  • The root cause of the problem, like the earlier Flickr API Signature Forgery vulnerability, is “web developers used encryption when they should have used MAC”.

    MAC = Message Authentication Code, prevents a client from forging a valid value. You can think of it like a digital signature, except that it’s much faster and the same key creates and verifies the data - which is perfect when your web app generates, sends the value to the client, receives the value from the client, and wants to v

    • Oh yeah, forgot how to apply this to the first block - I think it depends on IV, and if it's not part of the blob under client control, or can't be tampered with, it requires special handling. They seem to discuss this in their paper.

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close