Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Bug Microsoft Security Software Windows IT

Researchers Demo ASP.NET Crypto Attack 98

Posted by timothy from the theoretical-no-more dept.
Trailrunner7 writes "The crypto attack against ASP.Net Web apps has gotten a lot of attention this week, and with good reason. Microsoft on Friday night issued a security advisory about the bug, warning customers that it poses a clear danger to their sites. Also on Friday, the researchers who found the bug and implemented the attack against it released a slick video demo of the attack, clearly showing the seriousness of the problem and how simple it is to exploit with their POET tool."
This discussion has been archived. No new comments can be posted.

Researchers Demo ASP.NET Crypto Attack More

Researchers Demo ASP.NET Crypto Attack

Comments Filter:

  • There was so much wrong about that, I cannot begin to say it all. But I will say this. That "superuser" is available as a user in a web app is unforgivable. If it wasn't this exploit to take advantage of that fact, it would be another. *NIXes have learned the folly of that long ago and so now, with the exception of certain administrative tools, web services don't run as root, but as apache or some other non-root user. While this doesn't make the feat of root-level compromise impossible, it does make it

    • You don't know what you are talking about, at all. (Score:5, Informative)

      by brunes69 ( 86786 ) <slashdot@nOSpam.keirstead.org> on Sunday September 19, 2010 @04:32PM (#33630090)

      For one, IIS does not run as Administrator, unless you for some reason change it to do that.

      For two, this attack has nothing to do with that, at all. This attack basically involves a way to crack COOKIES on a client machine that are supposedly encrypted.

      For three, anyone who stores sensitive data in an "encrypted user cookie" is retarded. I don't care if it is encrypted or not, rule #1 is never trust the client with anything. Quote 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. 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."

      Why on earth anyone would put a bank balance or any other sensitive information in a cookie is totally beyond me. Also why on earth one's session cookie would be based on anything other than a totally random UUID is beyond me.

      Basically this exploit takes advantage of people who poorly code ASP sites. The exact same exploit could affect a poorly coded PHP site, or poorly coded JSP site, or poorly coded CGI site.

      • Re: (Score:2)

        by sjames ( 1099 )

        Why on earth anyone would put a bank balance or any other sensitive information in a cookie is totally beyond me. Also why on earth one's session cookie would be based on anything other than a totally random UUID is beyond me.

        It's beyond me too, but then I also had grave concerns about making email and documents executable code.

      • For four he turned the default (and secure) custom error mode setting to off.
      • \

        The exact same exploit could affect a poorly coded PHP site, or poorly coded JSP site, or poorly coded CGI site.

        I might be misreading the article but it appears that the exploit is specific to ASP.NET and the way they implemented AES. Unless, of course, you have some other information on how to implement this attack against the other aforementioned languages.

        • no, the AES implementation is fine. the vulnerability is the ability to detect the padding exception in the block cypher.

          you don't need to see the padding exception, you just need to know that it occurred. you can do that via a variety of means, not limited to http status codes, timing, etc...

      • I for one don't care to give up all "Remember me" checkboxes on the internet.

      • it's not just about cookies, it's about extracting the machineKey. for 99.9% of ASP.NET sites that's a complete disaster.

        if you admin ASP.NET and you think this doesn't affect you, then you're probably wrong.

        • it's not just about cookies, it's about extracting the machineKey. for 99.9% of ASP.NET sites that's a complete disaster.

          if you admin ASP.NET and you think this doesn't affect you, then you're probably wrong.

          That really isn't true. It should be, if your a moron and you have incorrectly and insecurely setup your asp.net site then this may affect you. If you are said moron you should not be the admin of a site that has confidential data in the first place though. Any correctly configured site will not be vulnerable to this attack.

        • Re: (Score:2)

          by brunes69 ( 86786 )

          If you weren't encrypting data into cookies and using that to store stuff then you would not be vulnerable to this exploit, at all.

          Session cookies should always be totally random. If your web app wants to "remember me" then store that random cookie in the database with the user ID affiliated. There is never any reason to store anything about the user on the client side, at all, encrypted or not.

      • That was my thought as well. Do what most Java servlet containers do, use a 256 bit securely hashed random number for the session tracking cookie. If you need to track a user for longer than an in-memory session stick that in your database as a key to the necessary info. I've always thought it rather irresponsible for storing encrypted data in cookies. You're just asking for someone to spend time trying to get your keys or session data and if they do they can spoof any data they want.

        I'm not a crypto expert

    • Re: (Score:3, Insightful)

      by TrancePhreak ( 576593 )
      You should check out this article that was on the front page a couple hours ago. http://linux.slashdot.org/story/10/09/18/2325240/Hole-In-Linux-Kernel-Provides-Root-Rights [slashdot.org]
  • The attack requires the ASP.NET error page that shows exception information to be enabled. No sane person will leave it like this in production let alone that it is turned off by default.

    • Re: (Score:1)

      by prudhvi ( 988493 )
      I see horrible ASP.NET/PHP Code from my American counterparts aswell. Stop blaming India/Indians from everything. And remember you get what you pay for Plain and simple.

    • Re: (Score:2)

      by devent ( 1627873 )

      Hmmm.

      Experts say that the bug, which will be discussed in detail at the Ekoparty conference in Argentina this week, affects millions of Web applications.

      For some reasons I trust the experts. Is there a reason why this kind of attacks are only done on IIS/ASP.NET? Some time ago there was another exploit According to Google over *114.000 different pages have been infected. [sucuri.net]

      Is there a reason why I never read anything about Apache or the other webservers and languages/frameworks?

      • Re: (Score:1)

        by t0y ( 700664 )
        Yes, there's a reason: you're filtering the information you get.
        That particular issue you are pointing out was an SQL Injection attack and IIS/asp.net can't do anything about that.

        • Re: (Score:2)

          by devent ( 1627873 )

          Well, I'm reading /. Don't know if /. is filtering in this way.

          It's a SQL injection attack, but why it's not done on the fast majority of web servern out there that are running Apache/Php?

          • Re: (Score:1)

            by t0y ( 700664 )
            It is. Often. Here's an example search within slashdot for wordpress vulnerabilities [google.com].

            You should know that these vulnerabilities will also work when running wordpress under IIS.
            The server software has nothing to do with it, it's a framework issue.

            • Re: (Score:1, Troll)

              by devent ( 1627873 )

              There are 197 results, but half of them are posted on a wordpress blog about something else. This search yields 347 results [google.com] which are all IIS vulnerabilities, my favorite one is 500 Thousand MS Web Servers Hacked [slashdot.org]. A search for the same with Apache is useless, because Slashdot have a menu with an "Apache" item. The Slashdot's own search against "Apache vulnerability" only yields one reacent item Serious Apache Exploit Discovered [slashdot.org], which only affects Windows servers. And the next is from 2008 Mystery Malware [slashdot.org]

              • Re: (Score:1)

                by t0y ( 700664 )
                This discussion would be over quickly once you understand that this isn't a IIS bug.
                Anyway, put any of these hacked websites running under Apache/Mono and voilá, an Apache vulnerability under your definition.

                Thanks for playing. ;)

                • Re: (Score:1, Troll)

                  by devent ( 1627873 )

                  Technically it's not an IIS bug, true. But why is only the IIS affected and not the more used Apache? Actually, why is it always the IIS and almost never the Apache? You should think that a hacker would target the most used webserver to hack as many websites as he/she can.

          • It is done on a vast majority of php sites, you just haven't been around long enough to hear about it I guess. phpBB back in the day had this issue like crazy and once someone found it could be injected, any major public forum using phpBB was injected. You just hear about IIS/ASP more on /. because OMG it's M$ products being hacked again. But really SQL injection has nothing to do with the technology being used and everything to do with lazy coding methods being used in applications.

      • Re: (Score:2)

        by Jaime2 ( 824950 )
        Neither this bug nor the one you linked to would affect a properly written web application on ASP.Net. This one requires the developer to store the user name in a cookie (and then trust it), and the linked one was SQL injection, which is easily preventable.

    • NOOOO! (Score:5, Insightful)

      by spongman ( 182339 ) on Sunday September 19, 2010 @05:57PM (#33630652)

      The attack requires the ASP.NET error page that shows exception information to be enabled.

      NO! NO! NO!

      This is wrong, and dangerous. There is no such requirement, the HTTP status code is sufficient. Actually, the timing is sufficient, but slightly harder to exploit.

      No sane person will leave it like this in production let alone that it is turned off by default.

      This is correct, and, unfortunately, why the 1st statement is so dangerous.

      Assuming that your site is safe just because you've followed best practices is WRONG! You MUST apply the fix in ScottGu's post immediately!

  • POET tool? More like Pwnit.
  • This was demoed at the ekoparty and was pretty cool, they gave away three copies of their POET tool, the crowd was like crazy for those pen drives thrown out.

  • Not just ASP.NET (Score:5, Informative)

    by shutdown -p now ( 807394 ) on Sunday September 19, 2010 @05:37PM (#33630550) Journal

    I understand this is Slashdot and all, and it would be very politically incorrect to ask the editors to read the original paper about the attack [usenix.org], much less understand it... but, for God's sake, the paper starts with a demo of this attack on JSF (which has precisely the same issues as ASP.NET)! There's also a presentation [netifera.com] devoted entirely to attacking JSF apps with this.

    And starting from there, I'll just quote:

    Besides JavaServer Faces, we have also audited someother popular web frameworks to see if they are vulnerable to padding oracle attacks. Here are some of our findings.

    Since version 2.3, Ruby On Rails has introduced ActiveSupport::MessageEncryptor which is a set of functions to provide a simple way to encrypt information for storage in an untrusted location (like cookies). If you look at ActiveSupport::MessageEncryptor's source code,
    you would probably see that applications that use the provided encrypt/decrypt functions would be vulnerable to padding oracle attacks.

    The reason why ASP.NET is most affected by this in practice is because there are many more clueless developers who enable full exception information being passed to the client in production (and that, in turn, is largely because ASP.NET is a common tool of choice for outsourcing bids).

    • Re:Not just ASP.NET (Score:4, Interesting)

      by spongman ( 182339 ) on Sunday September 19, 2010 @06:19PM (#33630798)

      clueless developers who enable full exception information

      this is irrelevant and misleading, the exploit does not require the stack trace pages to be enabled in order to be effective.

      • Re: (Score:2, Informative)

        by shutdown -p now ( 807394 )

        The point still stands that, 1) the default in ASP.NET is no information about the error other than something wrong happened, so it's not exploitable; and 2) the common cause of problems in this particular case is people enabling full reporting for development/debugging, and then keeping it that way for production.

        • Re:Not just ASP.NET (Score:5, Informative)

          by spongman ( 182339 ) on Sunday September 19, 2010 @07:41PM (#33631292)

          ARGH! NO!

          Why do you guys keep reiterating this crap.

          The vulnerability DOES NOT REQUIRE the stack traces in order for it to work. Telling people that this is the case is extremely dangerous and irresponsible because it leads people to believe that they are safe WHEN THEY ARE NOT!

          The exploit only needs to know that something went wrong. It doesn't need to know what went wrong. All it needs to know is that the response for a correct padding byte is different than the response for an incorrect one. The difference between a '500' and '404' in the HTTP response header is sufficient, and the 'production' error pages certainly have this difference.

          • The exploit only needs to know that something went wrong. It doesn't need to know what went wrong. All it needs to know is that the response for a correct padding byte is different than the response for an incorrect one. The difference between a '500' and '404' in the HTTP response header is sufficient, and the 'production' error pages certainly have this difference.

            What I think several people are trying to tell you and you don't seem to be getting is that typically an ASP.NET app won't be providing even th

            • Re: (Score:1, Insightful)

              by Anonymous Coward

              The timing is the key.

              If it takes 100ms to return a normal and 110ms to return a padding error.. they have figured it out.

              It doesn't matter about status codes, or stack traces.

      • Re: (Score:2)

        by pegr ( 46683 )

        Just to be crystal clear, the issue doesn't require ANY change in error pages. Bad encryption = error page (app doesn't know what/who/where etc.) Good encryption = proceed within the app with your injected and encrypted value.

        Yikes.

  • Sigh.... (Score:5, Informative)

    by Anonymous Coward on Sunday September 19, 2010 @06:56PM (#33631022)

    Remarks about clueless .NET developers aside, there are a lot of clueless comments here.

    1. This has nothing to do with exception data or stack traces being returned. It has to do with HTTP status codes. When ASP.NET is decrypting a cookie value, one of three things may happen:

    A. The value is decrypted and meaningful. The application returns HTTP 200.
    B. The value is decrypted but not meaningful. The application returns HTTP 200 with a human-readable error message.
    C. The value is not decrypted because the padding of the ciphertext was not correct. The underlying platform throws an exception that the application does not catch. The server returns HTTP 500.

    With a few thousand requests, being able to distinguish among these three cases allows you to eventually decrypt the message. That the attacker can distinguish between cases B and C is an "oracle" provided inadvertently by the platform and the way the application consumes it. The ideal solution is to make these two cases indistinguishable to the attacker. That is all we are talking about.

    The advice of "never trusting the client with encrypted data" or lambasting "retarded developers" is not helpful, and, I might add, defeats the entire @#$@#$@$# purpose of encryption!

    2. OK. This should sounds scary to you because you can imagine several platforms are vulnerable to this kind of attack. But of all of the platforms vulnerable to this kind of attack, in ASP.NET it is worse because once the machine key is deduced, a special request to the server using that key can be used to download any file within the application directory, such as the web.config file, which could contain sensitive information like database connection strings and passwords.

    • mod parent up

    • Thank you for an informative post!

      But of all of the platforms vulnerable to this kind of attack, in ASP.NET it is worse because once the machine key is deduced, a special request to the server using that key can be used to download any file within the application directory, such as the web.config file, which could contain sensitive information like database connection strings and passwords.

      However, this is not correct. There is no key which will let you bypass the IIS/ASP.NET mappings. A number of files and file types are always configured so that they will be served by the special "prohibited" handler. An IIS/ASP.NET server will *never* (barring any bugs) serve the clean text version of web.config, *.aspx or similar files. Not with any key.

      This is an attack on the authentication ticket - which is the cookie on the client which holds information about your lo

    • A recent Technet (http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx) article claims that using the customErrors tag to set all error types to return the same error page will fix this security hole. But according to the research paper (linked in another comment), the POET tool can simply check the HTTP return code. I don't know enough about ASP.Net and IIS, but is the MS Technet blog article totally off here?
  • Microsoft acknowleged a zero day threat AND advised its' customers of the threat IN THE SAME WEEK???? Nope can't happen> Stop smokin that crack... obviously you're delusional.
    • At least there is someone to be held responsible, unlike linux. This entire thread is just Microsoft vs Linux. This isn’t really an important exploit. Any security expert can tell you not to not to put exception information to your end user. This is why you provide generic errors. Like, when word crashes, it says “An unexpected error happened.” The real problem is the default configuration displays exception information, which is very simple to change. Any educated developer should
  • Couldn't maybe a work around be: "Don't respond to 37 thousand requests in 260 seconds from an attacker?" At least not from the same IP?

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close