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

Comments

Computer systems need security audits.

[suck_burners_rice]

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.

[TheLink]

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.

[zobier]

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.

[TheLink]

Well then that sort of internet accelerator will break on slashdot, gmail etc, since the last I checked, with all of them, you can get logged out with a simple GET request.

Clicking the following will result in a GET request that logs you out from slashdot:

http://slashdot.org/my/logout

Why is it that...

[Darkness404]

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:Why is it that...

[Chundra]

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.

Big flippin deal

[Jeffrey Baker]

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.