Major Flaw Found In Security Products

ancientribe writes "A stealthy and potentially dangerous bug has been discovered in security products from eight different vendors, including Check Point Software, according to an article in Dark Reading. The so-called cross-site request forgery (CSRF) lets an attacker access the user's network and even conduct transactions on behalf of the user. It could affect over a million installations, but so far, Check Point is the only security vendor to step up and patch it. This vulnerability is found in most everything with a Web-based interface, including printers, firewalls, DSL routers, and IP phones." An article on the vulnerability from last fall quotes Jeremiah Grossman, CTO of WhiteHat Security, who calls CSRF "the sleeping giant" vulnerability: "It's not seen as a vulnerability because it works like the Web works."

Comments

What the ... ?

[khasim]

CSRF works like this: An attacker identifies a URL on a Website -- such as Netflix or a bank -- that initiates typical Web functions such as making a purchase, changing an email address or transferring funds. "The attacker takes that URL and loads it to a Web page they control," White Hat's Grossman says.

The actual attack occurs when the user visits the attacker-controlled Web page via a legit link, which forces the browser -- using legitimate, authenticated cookies -- to make malicious requests. The user has no clue as to what's happening.

And the catch is that neither the original Website nor the user's computer is necessarily compromised, Grossman says.

Wouldn't this be easily killed by simply having the webpage dynamically generate a page with a life of 15 minutes or less?

Or even by using some basic encryption that involves the IP address of the original request?

sheesh!

Re:What the ... ?

[bryguy5]

Expiring the Session in a short time frame like 15 minutes does limit the damage, but doesn't eliminate the threat. The above example said Checkpoint was only vunerable when both were open at the same time.

The IP address doesn't work because the initial exploit is from the orignal user on the same computer, same ip address. Just a different tab or window of the same browser that carries the same cookie/http-auth as the original, but comes from a seperate malicious webpage.

I can think of 2 general fixes but both would require changes to the browser.

1) Allow Users/Webservers to determine that a cookie should be bound to a particular window, so that a request originating from a different window containing the malicious site does not include the cookie.

2) Add an extension to the cookie protocol where the cookie always sends the url and ipaddress that is the source of the request (I haven't thought out what the source is with confusing external js scripts which may be controled by js in the main html) - this would allow sites to weed out requests generated from malicious sources.

Both of these would still allow the exploit to be used in XSS situations, but could plug the hole in the more general cases.

Without a change to the browsers your best off generating some type of session token and passing it back and forth on the url and using that and a cookie as two part authentication. The malicious site shouldn't be able to read or guess the url's. A lot messier than simple cookie based authentication.

POST vsn GET

[El_Muerte_TDS]

Is that not the reason to use POST for important actions (e.g. modification to data) rather than GET?

Re:POST vsn GET

[ckd]

Is that not the reason to use POST for important actions (e.g. modification to data) rather than GET? Indeed it is, but why should the vendors of security appliances be any better at reading RFCs than anyone else?

RFC 1945, section 12.2 (under the oh so stealthy heading of "Security Considerations"):

The writers of client software should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they may take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods should never have the significance of taking an action other than retrieval. These methods should be considered "safe." This allows user agents to represent other methods, such as POST, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

But hey, that RFC was only written in 1996; why would we expect something that was specifically stated as a security problem eleven years ago to be taken into account by security vendors?

Re:POST vsn GET

[asdfghjklqwertyuiop]

With POST, on the other hand, you have to get the victim to submit a deliberately crafted form. With JavaScript you could do this automatically, but that's not nearly as easy as

Not nearly as easy? Here, lets transform your sample attack into a POST-based one:

<form id="funnyform" action="http://www.bankofsomethingorother.com/acco unt.asp" method=post>
<input type=hidden name="action" value="transfer">
<input type=hidden name="amount" value="1000.00">
<input type=hidden name="dest" value="716281">
</form>
<script language="javascript">
document.forms['funnyform' ].submit();
</script>

That wasn't very hard at all. POST gains you nothing security-wise.

This happens though.

[khasim]

You'll be looking for the solution to a problem on a web page and trying it on your firewall.

In that rare instance, I can see this as being a potential problem.

Re:A good explanation

[rthille]

You should never use GET for actions. The last company I was at had a 'delete' link that was a GET action. And we had a spider that indexed our intranet...

And the spider deleted everything!

Trusted sites may inadvertently launch the attack

[Anonymous Coward]

Unfortunately, even if you trust all the sites and they are all trustworthy and well-known, you can still get hit. It is a _potential_ calamity (hence the "sleeping giant" reference) and this is why the advice to companies that require security in their public web-apps is to review them now.

Drawing partially on a previous post, here is an example. You're on Disney's site and want to buy some toy. You think, eBay/Paypal to shop and pay for the toy would be much cheaper than Disney's site. You have both open in your browser. While you are logged into Paypal, suddenly an ad on Disney's site updates. Site ad's come from 3rd party websites. It turns out the new ad is not an image or whatever but a bit of javascript code. The code sends a request to Paypal to transfer money from the currently logged-in account to some recipient account. The request is accompanied by your current Paypal session cookie. Paypal receives this request FROM YOU to transfer money to the recipient with the session cookie validating that IT IS YOU and YOU ARE LOGGED IN. Viola! You didn't even know that it happened (until you noticed the money gone and your past "request" in Paypal's history). [I don't know if this could happen to Paypal, it depends on their system, I'm just talking of the hypothetical.]

Now, it's not difficult to design sites in a way to prevent this attack, however, this design is a low-level design decision. To retroactively repair a site to prevent this attack may or may not require the modification of everything on the site, depending on how the original design was done. This can't sit well with companies that are potentially vulnerable.

This problem has existed for a long time (something like a decade), but apparently people are only realizing it now. Now it's a race between the patchers and the attackers. Now, the chance of proper attack conditions existing is very low IMO, but spread this over millions of users, combinations of target sites and hosting sites, and you will have a few hits and it only takes one hit to make an attacker a lot of money (or simply amuse themselves).

My two cents.
--Dave Romig, Jr.

Re:Can someone explain this for me...?

[owlstead]

The bigger problem is that, indeed, the browser accepts data from any source to be put in a page, as well as allow communications to any destination. This can be images, video's, web-casts, posts, redirects, css pages - the works. To make matters worse, you cannot even trust links anymore, you never know what the scripting which is behind the link is going to do. This is just like Outlook displaying mails in Internet explorer, it's damn convenient at times, but it's really, really bad for security.

Now, if you would have to do this over again, sites should only accept data from and communications to a single domain and it sub-domains (e.g. slashdot.org and images.slashdot.org). Links to outside pages should be highlighted, and scripts should not be able to influence them. Of course, this would mean that you cannot use cross site cookies, counters, off-site images etc. These should be implemented/pushed to the original site (or maybe you could do something with a sub-domain).

Yes, this would be a lot of work, and yes you would loose just a bit of functionality. But think of the security advantages of this approach. Even better, think of the annoyances that you would loose, no more waiting for pages while a (&*^(*& ad or page counter fails to load. Frames were a horrible idea, but it would have been a lot better if the frames all originated from the same site, I know that.