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!

Researchers Demo ASP.NET Crypto Attack

timothy posted more than 4 years ago | from the theoretical-no-more dept.

Bug 98

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

cancel ×

98 comments

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

First (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#33629918)

First

Re:First (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#33629948)

Certainly appears that way.

This is why we need to use Ruby on Rails. (-1)

Anonymous Coward | more than 4 years ago | (#33629994)

This is just more evidence to show why it's important to only use proven technologies like Ruby on Rails when developing web sites. PHP doesnt' cut it, ASP.NET apparently doesn't cut it, and people stopped developing web apps in Java years ago. Ruby is the only solution we can use in the real world. Django is getting close, but it will never be able to catch up with Ruby on Rails because Django doesn't use Ruby.

Re:This is why we need to use Ruby on Rails. (0)

Anonymous Coward | more than 4 years ago | (#33630022)

I'll just let MediaWiki, Wordpress, Joomla, phpBB, and countless other site systems know that they should port to Ruby on Rails since they'll never work in the real world.

Re:This is why we need to use Ruby on Rails. (4, Funny)

mangu (126918) | more than 4 years ago | (#33630134)

Ruby is the only solution we can use in the real world. Django is getting close, but it will never be able to catch up with Ruby on Rails because Django doesn't use Ruby.

Python is the only solution we can use in the real world. Ruby on Rails is getting close to Django, but it will never be able to catch up with Django because Ruby on Rails doesn't use Python.

Re:This is why we need to use Ruby on Rails. (1)

flyingfsck (986395) | more than 4 years ago | (#33632392)

Fortran is the only solution we can use in the real world. C is getting close, but...

Re:This is why we need to use Ruby on Rails. (1)

hairyfeet (841228) | more than 4 years ago | (#33633100)

Bah! The world is a dark and evil place, and we need tools that will bring with them much pain to teach those stupid developers to stay in their place! We need...Visual Basic! Even now just the thought fills the software engineers with dread, which is what you need in this cold and cruel world. Now get back to work on that VB app or I'll send your job to India, BWA HA HA HA HA!

Now get off my lawn, right after you mow it! And don't forget to trim the hedges! BWA HA HA HA HA HA!

Re:This is why we need to use Ruby on Rails. (1)

Joce640k (829181) | more than 4 years ago | (#33633144)

Visual basic is for weenies. QBASIC has everything a real programmer needs.

Re:This is why we need to use Ruby on Rails. (1)

whitedsepdivine (1491991) | more than 3 years ago | (#33635184)

The only reason Visual Basic has a bad rep, is that it was an horrible language when it was immature. Since Visual Basic uses the Common Language Runtime (CLR), it can do the majority of what C# can. C# is an extremely powerful language, with great frameworks and libraries. Visual Studio and the CLR, seems to have a completely different management process than windows, and has very few issues. (Microsoft.Windows != Microsoft.VisualStudio) And so what they had an stupid simple default web application that had a possible exploit if it was deployed.

The real problem is Microsoft assumed developeers wouldn't be so stupid. If IT idiots who never took a security class in there life are programming your web application, you will have problems.

Bottom line is, C# is what Java should have been if it had better backing, and VB can do the majority of what C# can. I much rather have a language that has a strong corp. backing.

Re:This is why we need to use Ruby on Rails. (1)

kiddygrinder (605598) | more than 4 years ago | (#33632462)

also ruby on rails is vulnerable to this same attack.

Re:This is why we need to use Ruby on Rails. (1)

aurelianito (684162) | more than 4 years ago | (#33630318)

I've talked with the 0-day authors and they said that RoR had (or have, I don't remember) the same kind of vulnerability reported in ASP.NET. The problem is that using encrypted but not signed content allows an attacker to decrypt it (check out the authors' paper for details, it is really cool).

Re:This is why we need to use Ruby on Rails. (2, Informative)

Caesar Tjalbo (1010523) | more than 4 years ago | (#33630556)

From a set of slides [netifera.com] (pdf, page 15) they used at the Black Hat Europe 2010:
  • Since RubyOnRails 2.3, to provide a simple way to encrypt
    information.
  • Vulnerability: encrypt and decrypt functions.
  • Use encrypt_and_sign and decrypt_and_verify instead.

Impressive video (0, Troll)

erroneus (253617) | more than 4 years ago | (#33630016)

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 less easy. (Then again, root isn't often as necessary as people seem to think as these days, the ability to run a [D]DoS or to extract sensitive information from a database only requires user level access as granted by level of the process compromised.)

Still, the dangers of a direct root level compromise is plain for all to see and understand. At that level, it's "game over" for all things including updating the BIOS or other ROM code of other on-board controllers of the host system to make "removal" or "cleaning" a much more difficult if not impossible task to perform.

I know Microsoft is not listening as we all begin to chant the same things: STOP RUNNING EVERYTHING AS ADMINISTRATOR

Maybe they will start to listen one day.

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

brunes69 (86786) | more than 4 years ago | (#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:You don't know what you are talking about, at a (1)

sjames (1099) | more than 4 years ago | (#33630156)

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.

Re:You don't know what you are talking about, at a (1)

Eirenarch (1099517) | more than 4 years ago | (#33630216)

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

Re:You don't know what you are talking about, at a (3, Informative)

wizbit (122290) | more than 4 years ago | (#33630474)

Per Scott Guthrie's blog [asp.net] , even if it's on, using anything other than a single default redirect still leaves the app vulnerable.

Re:You don't know what you are talking about, at a (1)

Eirenarch (1099517) | more than 4 years ago | (#33630538)

I may be wrong on this but I believe the multiple errors are just theoretically exploitable and practically it is impossible for an exploit to track the information needed to decrypt the cookie that way. Same goes for the timing of the error page.

Re:You don't know what you are talking about, at a (1)

spongman (182339) | more than 4 years ago | (#33630634)

all you need is a 1-bit difference between the response for the padding error case and the non-error case.

once you have that bit you have the machine key. once you have the machine key you have all the sites on that machine that share that machine key.

Re:You don't know what you are talking about, at a (0)

Anonymous Coward | more than 4 years ago | (#33630282)

Basically this exploit takes advantage of people who poorly code ASP sites.

that would be 99% of them right?

Re:You don't know what you are talking about, at a (1)

kmoorman (873896) | more than 4 years ago | (#33630828)

Yes, since 99% of all sites are poorly coded then 99% of ASP sites are probably poorly coded.

Re:You don't know what you are talking about, at a (1)

adamchou (993073) | more than 4 years ago | (#33630352)

\

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.

Re:You don't know what you are talking about, at a (1)

spongman (182339) | more than 4 years ago | (#33630638)

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

Re:You don't know what you are talking about, at a (0)

Anonymous Coward | more than 4 years ago | (#33631214)

The authors of the tool also have a demo that shows the tool working against Apache MyFaces (a JSF implementation).

Re:You don't know what you are talking about, at a (1)

Peach Rings (1782482) | more than 4 years ago | (#33630674)

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

Re:You don't know what you are talking about, at a (1)

spongman (182339) | more than 4 years ago | (#33630698)

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.

Re:You don't know what you are talking about, at a (1)

bloodhawk (813939) | more than 4 years ago | (#33631474)

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:You don't know what you are talking about, at a (0)

Anonymous Coward | more than 3 years ago | (#33636702)

I would suggest you take all your money out of any bank you use then. Two bank software vendors my company consults are frantically fixing EVERY web app on their servers due to this flaw.

Re:You don't know what you are talking about, at a (1)

brunes69 (86786) | more than 4 years ago | (#33633658)

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.

Re:You don't know what you are talking about, at a (0)

Anonymous Coward | more than 4 years ago | (#33630704)

You, sir, have no clue.
The interesting sensitive information ASP.NET stores in encrypted/signed cookies is the user ID.
Get the keys (which this attack lets you do), you can now make your own cookie saying you are user #1 and log in to the website as the admin.
Why does ASP.NET store the user ID in the cookie? Because you're not supposed to store a password, of course. So they encrypt and sign a user id instead.

Re:You don't know what you are talking about, at a (1)

goofy183 (451746) | more than 4 years ago | (#33631680)

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 but it seems like generating a secure random token should be a lot easier than all that goes into implementing a functional crypto solution.

Re:Impressive video (0)

Anonymous Coward | more than 4 years ago | (#33631246)

wow, impressive misunderstanding of the actual problem dude.

Not as serious as it sounds (2, Interesting)

Eirenarch (1099517) | more than 4 years ago | (#33630020)

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.

Many ASP.NET apps are developed in India. (0, Flamebait)

Anonymous Coward | more than 4 years ago | (#33630074)

You need to keep in mind that most ASP.NET apps are developed in India. A fuck up like that is routine for them. In fact, I'd be much more surprised if they didn't screw up something as simple as that.

Re:Many ASP.NET apps are developed in India. (1)

shutdown -p now (807394) | more than 4 years ago | (#33630470)

You need to keep in mind that most ASP.NET apps are developed in India. A fuck up like that is routine for them.

Yeah, but so is SQL injection, at which point this particular attack is pretty insignificant.

Re:Many ASP.NET apps are developed in India. (1, Funny)

Anonymous Coward | more than 4 years ago | (#33630978)

India is the world's leading exporter of SQL injection vulnerabilities. It literally makes up approximately 8% of their GDP.

Re:Many ASP.NET apps are developed in India. (0)

Anonymous Coward | more than 4 years ago | (#33630714)

+1: Jingoism

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33630092)

If you check out the info in the video error msg is turned off.

Re:Not as serious as it sounds (2, Informative)

Anonymous Coward | more than 4 years ago | (#33630150)

If you check out the video it shows that "custom error" messages are turned off. By turning off custom errors you are instructing ASP.NET to send the detailed error message to any connected client. The default value for this setting is "RemoteOnly" which causes the detailed error message to be sent to clients connecting over the loopback adapter and generic error messages to be sent to anyone else.

What the video shows is that the target site was configured poorly. If that is the default setting of DotNetNuke then that is absolutely a problem with that software. As mentioned, that is not the default in ASP.NET, nor is it a default when creating a new ASP.NET site in any Microsoft product.

Re:Not as serious as it sounds (1)

spongman (182339) | more than 4 years ago | (#33630658)

the http status code in the generic error message is sufficient for this exploit to work.

Re:Not as serious as it sounds (1)

Mongoose Disciple (722373) | more than 4 years ago | (#33631350)

the http status code in the generic error message is sufficient for this exploit to work.

Sure, but I've never seen a professionally built ASP.NET site that would return that, though I'm sure there are some.

There isn't a technology that exists that can survive user stupidity.

Re:Not as serious as it sounds (3, Insightful)

Eirenarch (1099517) | more than 4 years ago | (#33630162)

Not really. This option works the other way around. Custom errors in ASP.NET are the ones provided by the developer. He turned custom errors off. Also in ASP.NET by default this option is set to RemoteOnly meaning that the errors are on for anyone but the localhost. This way you can develop on your own machine but when you deploy you can't be exploited by this or similar exploit even if you don't change the default configuration. Now if you go out and change it this is another thing...

I believe it is a standard security practice to NOT show your error infomation to the user in production environment. If anyone is doing it he should be fired anyway. No need to wait for an exploit to hit.

Re:Not as serious as it sounds (0, Redundant)

spongman (182339) | more than 4 years ago | (#33630720)

the http status code is enough error information in order for this exploit to work. RemoteOnly is irrelevant.

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33630166)

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.

No sane person runs IIS to begin with, so that hurdle has been cleared.

Re:Not as serious as it sounds (1)

Giometrix (932993) | more than 4 years ago | (#33630394)

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.

No sane person runs IIS to begin with, so that hurdle has been cleared.

Wow, is this a post from 10 years ago? If not, you should really keep up with technology; IIS has matured quite a bit.

Re:Not as serious as it sounds (-1, Troll)

clang_jangle (975789) | more than 4 years ago | (#33630482)

Yeah, it's still crap compared to BSD, Linux, or even OS X. The only real value of microsoft products is to admins, because they require many,many more paid hours to keep them working. It would be against microsoft's philosophy to build better, more secure systems. Because as billg himself once said, "you have to make them need you". And you don't do that by building a reliable system that doesn't need attention...

Re:Not as serious as it sounds (1)

Timothy Brownawell (627747) | more than 4 years ago | (#33630826)

The only real value of microsoft products is to admins, because they

...come with Active Directory.

It would be against microsoft's philosophy to build better, more secure systems.

This is of course why Windows 7 has no security advantages over XP, and XP has no advantages over 98.</sarcasm>

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33630928)

This is of course why Windows 7 has no security advantages over XP, and XP has no advantages over 98.</sarcasm>

Considering the same exploit holes are in Win 7 as are in 2003, XP, 2000, 98, and 95... The only part wrong about your comment is the sarcasm tag :P

http://www.securityfocus.com/bid/27100 [securityfocus.com]

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33631332)

The only real value of microsoft products is to admins, because they

...come with Active Directory.

It would be against microsoft's philosophy to build better, more secure systems.

This is of course why Windows 7 has no security advantages over XP, and XP has no advantages over 98.</sarcasm>

You tell 'em!

Why, in a few more decades Microsoft products will be as secure as Unix/Linux systems were in 1989!

And someday soon, Microsoft products will be as 64-bit compliant as Solaris! The 1994 version of Solaris.

Maybe someday Microsoft will even have a file system that can keep up with XFS from Irix - the 1992 version of XFS.

Re:Not as serious as it sounds (1)

whitedsepdivine (1491991) | more than 3 years ago | (#33635456)

And maybe one day linux will support 512bit CPUs, since it already supports 256 bit(I think).

Here is a hit, Microsoft.Windows cares about the common person, who doesn't care about anything you listed.

Then on the opposite side you have Open Source teams so driven to program something so unbelievable useless, and call it progress. Tell me why you need to focus on something so useless, when you don't support so many things. Such as Flash 64 bit, until about a week ago.

http://xkcd.com/619/

Re:Not as serious as it sounds (2, Insightful)

nacturation (646836) | more than 4 years ago | (#33630948)

Wow, is this a post from 10 years ago? If not, you should really keep up with technology; IIS has matured quite a bit.

Yeah, it's still crap compared to BSD, Linux, or even OS X.

A web server is still crap compared to an operating system?

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33632294)

Not a very imaginative troll, are you?

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33630572)

Has it caught up to Apache yet?

Yeah I didn't think so. IIS has matured enough to keep up with Outlook Web Access and possibly Sharepoint for those masochistic admins out there.

I'd rather a date with a bathtub and a toaster over running IIS anywhere near customer-facing services..

Re:Not as serious as it sounds (1)

prudhvi (988493) | more than 4 years ago | (#33630454)

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:Not as serious as it sounds (1)

The Yuckinator (898499) | more than 4 years ago | (#33630530)

Really? Then why are your prices so low?

Re:Not as serious as it sounds (1)

JustOK (667959) | more than 4 years ago | (#33630728)

volume. Volume! VOLUME!!!

Re:Not as serious as it sounds (2, Insightful)

spongman (182339) | more than 4 years ago | (#33630810)

the real question is why are prices in the west so high?

Re:Not as serious as it sounds (1)

devent (1627873) | more than 4 years ago | (#33630588)

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:Not as serious as it sounds (1)

t0y (700664) | more than 4 years ago | (#33630722)

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:Not as serious as it sounds (1)

devent (1627873) | more than 4 years ago | (#33630894)

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:Not as serious as it sounds (1)

t0y (700664) | more than 4 years ago | (#33630962)

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:Not as serious as it sounds (0, Troll)

devent (1627873) | more than 4 years ago | (#33631646)

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 Affecting Linux/Apache Web Servers [slashdot.org] which "[exploit] vulnerabilities in QuickTime, Yahoo! Messenger, and Windows". So I don't know why it's affects Linux.

Please give me an example, where half a million websites are affected with Apache. While Apache is the most run webserver on the whole internet there is only the IIS server which is taken down which such big numbers. Why?

Re:Not as serious as it sounds (1)

t0y (700664) | more than 4 years ago | (#33631702)

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:Not as serious as it sounds (0, Troll)

devent (1627873) | more than 4 years ago | (#33632272)

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.

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33632780)

Answer: because Apache is open source software. The code has been scrutinized by many thousands of people and its well designed and secure.

Re:Not as serious as it sounds (1)

NuclearRampage (830297) | more than 3 years ago | (#33635194)

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:Not as serious as it sounds (1)

Jaime2 (824950) | more than 4 years ago | (#33631016)

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! (5, Insightful)

spongman (182339) | more than 4 years ago | (#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!

Re:NOOOO! (0)

Anonymous Coward | more than 4 years ago | (#33631504)

Sorry but the HTTP status code is somethign that will also be replaced by any professionally built site. You simply ALWAYS give the user 200's with a custom error message, this is basic 101 of web site security, you do not expose additional information.

Re:NOOOO! (2, Funny)

angst_ridden_hipster (23104) | more than 4 years ago | (#33631846)

Sorry, but real pros replace ALL of the HTTP status codes at random to prevent the client / browser from detecting a pattern. Similarly, pros override "true" and "false" constants to be functions that return random booleans, just to keep the code guessing. Sure, standards are great, but pros make sites that are secure, not standard.

Re:NOOOO! (0, Flamebait)

KarmaMB84 (743001) | more than 4 years ago | (#33632038)

Standards are often riddled with security holes.

Re:Not as serious as it sounds (0)

Anonymous Coward | more than 4 years ago | (#33634700)

No it doesn't. Watch the video. CustomErrors = "Off"

POET? (1)

itlurksbeneath (952654) | more than 4 years ago | (#33630082)

POET tool? More like Pwnit.

demoed at the ekoparty (1)

sergiusens (1417447) | more than 4 years ago | (#33630232)

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 (4, Informative)

shutdown -p now (807394) | more than 4 years ago | (#33630550)

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 (3, Interesting)

spongman (182339) | more than 4 years ago | (#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:Not just ASP.NET (1, Informative)

shutdown -p now (807394) | more than 4 years ago | (#33630938)

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 (4, Informative)

spongman (182339) | more than 4 years ago | (#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.

Re:Not just ASP.NET (1)

Mongoose Disciple (722373) | more than 4 years ago | (#33631382)

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

Potentially you can work out where something different went wrong from the timing of how fast you get back the response, though.

Re:Not just ASP.NET (1, Insightful)

Anonymous Coward | more than 4 years ago | (#33632020)

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:Not just ASP.NET (0)

Anonymous Coward | more than 4 years ago | (#33631546)

why do you keep posting this shit. A properly built app won't be giving 500's or 404's, the custom errors redirects these to a generic error page. it will give a 200 with a custom error page. The only place to see the real error is the server. Stop sprouting your garbage.

Re:Not just ASP.NET (1)

Bert64 (520050) | more than 3 years ago | (#33636614)

A custom error page with a 200 response code will usually still look like an error page, in that it will look different to the page given when a valid query is made. This exploit only needs to know that an error occurred, it doesn't need to know any more details about it, so a custom error page with a 200 response code will be perfectly sufficient in most cases.

Re:Not just ASP.NET (1)

pegr (46683) | more than 3 years ago | (#33639728)

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.

Re:Not just ASP.NET (0)

Anonymous Coward | more than 4 years ago | (#33632066)

Newer ASP.NET versions also have a vulnerability where if you can decrypt their "secret" then the untrusted server process will give you anything it has access to on the server filesystem.

So suddenly "I have a login to this ASP.net site but no permissions to read anything" plus POET becomes "Yay, I have downloaded all the super-sekret documents"

Re:Not just ASP.NET (2, Insightful)

shutdown -p now (807394) | more than 4 years ago | (#33632482)

Newer ASP.NET versions also have a vulnerability where if you can decrypt their "secret" then the untrusted server process will give you anything it has access to on the server filesystem.

Reference?

Sigh.... (5, Informative)

Anonymous Coward | more than 4 years ago | (#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.

Re:Sigh.... (1)

spongman (182339) | more than 4 years ago | (#33631306)

mod parent up

Re:Sigh.... (0)

Anonymous Coward | more than 4 years ago | (#33631628)

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.

again this is still clueless developers. this information does not ever need to leave the server and in a correctly built and configured site it won't

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

what utter bullshit, this is basics in any web application, NEVER TRUST THE CLIENT, encrypted or not, entrusted the client with error information or encrypted data is leaving yourelf open and should never happen in a well built app.

Re:Sigh.... (1)

benjymouse (756774) | more than 4 years ago | (#33632938)

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 login, expiry etc. This is separate from the session cookie. The authentication ticket comes into play when you use forms authentication. Note - this is an alternative to Windows authentication. Forms authentication is typically used for public facing websites. When you run FA you are not a Windows user on the server. So this attack does *not* allow you to run as "root" (the Local System) user.

It *is* a serious attack as it allows you to impersonate anyone provided you know their user name. But it is not a server compromise. Of course, if the application so designed so that one or more of the users you can impersonate are application administrators you can do what they do.

Note to everyone: IIS is *not* running under the Local System account. By default it is running as Network Service. This is a regular user account (on the local machine) with the added permission to represent the machine on the network. This means that if some other machine explicitly allows WebServerName$ access to resources, the IIS service can access those remote resources with those rights. This is the default, but in professional environments it is common to configure separate application pools so that each app runs under its own user account. Still, these accounts require no special privileges.

Which account the IIS service is running under is irrelevant in the context of the current vulnerability, as it does not allow you to run code on the server. It only allows you to impersonate users.

Re:Sigh.... (1)

davros-too (987732) | more than 4 years ago | (#33633090)

I wish you were right, but according to Microsoft's own blog: 'The public disclosure demonstrated using this technique to retrieve the contents of web.config. '

Re:Sigh.... (0)

Anonymous Coward | more than 4 years ago | (#33634294)

WebResource.axd

Re:Sigh.... (3, Informative)

spongman (182339) | about 4 years ago | (#33644066)

WebResource.axd provides the oracle. given the oracle, ScriptResource.axd provides the local files.

Re:Sigh.... (0)

Anonymous Coward | more than 3 years ago | (#33634780)

Note to everyone: IIS is *not* running under the Local System account. By default it is running as Network Service. This is a regular user account (on the local machine) with the added permission to represent the machine on the network. This means that if some other machine explicitly allows WebServerName$ access to resources, the IIS service can access those remote resources with those rights. This is the default, but in professional environments it is common to configure separate application pools so that each app runs under its own user account. Still, these accounts require no special privileges.

Which account the IIS service is running under is irrelevant in the context of the current vulnerability, as it does not allow you to run code on the server. It only allows you to impersonate users.

Did you watch the end of the video where they had a NT Authority\System command prompt using a .aspx exploit uploaded to the compromised system? Guess not.

Re:Sigh.... (1)

Newcastle22 (621052) | about 4 years ago | (#33644462)

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?

Wait wait this can't be right. (1)

shoehornjob (1632387) | more than 4 years ago | (#33631564)

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.

Re:Wait wait this can't be right. (1)

whitedsepdivine (1491991) | more than 4 years ago | (#33632202)

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 know not to do this. Regardless, of if it is under asp/php, or IIS/Apache.

Workaround (1)

BcNexus (826974) | about 4 years ago | (#33644106)

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?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?