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

Hope they used EEPROM

[jshriverWVU]

routers, IP phones, etc

because it sucks when there's a bug in hardware unless it's possible to do a firmware upgrade to fix or work around it.

Can someone explain this for me...?

[mikecardii]

I'm not completely retarded at computers, I just like reading comments on /. so I don't call attention to myself because for the most part I look like a complete dumbass. Yet this sentance makes no sense to me. "It's not seen as a vulnerability because it works like the Web works." What does this mean?

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

[MDHowle]

Sounds like the old saying "it's not a bug. it's a feature!"

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

[Anonymous Coward]

What does this mean?

It means that if you do something stupid like leave the default username/password for your "appliance" or log in and pick up a session cookie then go browse somewhere else, someone can set up a link like "http://192.168.0.1/networksetting.cgi?internet=di sabled&username=Admin&password=" and if they convince you to click on it, your internet turns off.

Except that they don't have to convince you to click on it, they could set that as the source of an image... you'd see a broken image tag and then the internet would stop working. Then they just have to get that image tag onto a website you read, say through an ad vendor (some of whom obviously don't care that they're hosting malware, so why not?) or an email to a webmail address that doesn't filter image tags.

This is how the internet works. Your browser follows links, and doesn't know or care about whats there until it gets there.

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

[stevey]

There is a simple example / introduction to CSRF attacks here.

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

[dch24]

Parent link is very helpful in understanding CSRF. In brief: malicious site knows or guesses you are logged in at paypal, slashdot, some valuable site, etc. ... malicious site sends you javascript that generates a form and submits it to valuable site. Valuable site sees it coming from your browser, so the cookies are valid. You are logged in, aren't you?

This lets malicious site do things like send $10 donations from your paypal account, submit blogspam, get your account balance, etc. if you can be convinced to visit malicious site.

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

[gEvil (beta)]

There may be a lot of comments saying CSRF is so 20006. Pfffft. I'm certain they'll have things fixed by then...

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

[planckscale]

By the way to not allow images execept from the original website, in FireFox2, open about:config, modify the value of the preference permissions.default.image

from 1 to 0 .

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

[iago-vL]

Of course, while that's generally good advice, it does very little to prevent CSRF. Instead of using an image, they could use an iframe or JavaScript code or anything else that loads a URL.

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.

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.

Re:What the ... ?

[morgan_greywolf]

I've said from the first day I learned what a 'cookie' was that using cookies alone for authentication is a very bad idea. Here is the real fix: don't use cookies alone for authentication. Your idea of using a session token passed on the URL is one such idea. Can anyone think of others?

Update!

[accessdeniednsp]

Anyone here like me who does managed firewall work, please notify your clients and get them updated! But this is Slashdot, and we all update our stuff don't we? :) Also, this kind of thing is irrespective of whether or not you allow remote web management of your device. Also, this is further evidence for why you should not use the default internal IP range the device gives you. Please always change the local LAN IP range!

I'm surprised it took this long to find something like this, but I'm not at all surprised it existed. I've loved web interfaces like these but I've always been nervous about them.

The sky is falling?

[Verteiron]

From TFA:
In Check Point's case, CSRF was possible when a user was logged onto https://my.firewall/ at the same time he or she was connected to a malicious Website, according to the company's patch release information.

This bad, sure, but hardly the internet-destroying calamity the article makes it sound like. When you're connected to the web interface of something critical, make sure you trust the other websites you're viewing at the same time. Am I missing something, or is this Calyptix company just trying to get its name on everyone's lips?

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

[stevey]

Using POST will help, but it doesn't solve the problem.

An attacker could still host a hidden FORM pointing at your local application, and use Javascript to submit it.

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

[spood]

While it's true that it's much better to follow the RFC here, just switching to POST doesn't solve the CSRF problem. An attacker could set up a malicious Web page which has a form with all the necessary parameters and a JavaScript to automatically submit it, hence meeting the POST requirement. Similarly, if the client has an older version of Flash or a buggy version which does not obey same-source security principles, the attacker could embed a malicious SWF which creates the entire HTTP request from scratch, even forging the Referer header if you were checking that as a security measure.

This is another good reason for using Firefox extensions such as Flashblock and Noscript. As a client, you can protect yourself pretty easily from a lot of these attacks. Noscript also has some nice features which help filter out the more common brands of XSS attacks.

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.

I Don't See It As a Sleeping Giant ....

[Luscious868]

All it takes is one malicious site to be open at the same time the Web interface is, and the attacker can gain access to your network, he says.

So don't manage any device on your network via it's web interface while browsing web sites you don't trust on the Internet. Problem solved. In this day and age you should be careful about opening links to non-trusted sites no matter what.

If you absolutely must do both at the same time, use one browser for the web and another to manage the device. If you're on Windows and you've got a brain then you've already installed a second browser to avoid the headache that is IE when possible anyway.

Check Point Edge firmware reset

[accessdeniednsp]

Anyone with a Check Point Edge or SofaWare appliance, be aware that if you do the reset procedure, you will be restoring both the original configuration *AND* the original firmware image that shipped with the product. Yes, the original image is still there. If you have a very old v3.x firmware box like I had one time, after upgrading to v6.5.x (back then) and then doing a reset, you're in for a surprise :)

A good explanation

[athloi]

CSRF explained, albeit clumsily. The examples made the article. Solution: use POST requests for user actions, and add unique tokens to each form.

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!

The Cross-site Request Forgery FAQ

[mrkitty]

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

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:What is the vulnerability?

[bryguy5]

POST doesn't help onclick=form.submit()

You can still do hidden posts with javascript. Just hook up the post to fire on onload or onclick of anything on the malicious site. The form response can be targeted to a hidden iframe so it's invisible to the user.

Most people have already turned off their browsers post warning and even if they didn't they don't have any reason to think it's posting to their bank's website or firewall device instead of the malicious site.

Re:What is the vulnerability?

[nolife]

I supply your browser a link like this:

http://slashdot.org/users.pl?op=edituser?sig="blow me"

If you are logged into /. and you happen to click on that link, your signature will be changed to "blow me"
(okay, I know nothing about scripting and this is just an example but you get the idea)

How do I supply this link to your browser? One example is on a malicious web page in an image tag, there are many others.
Since you have a /. set to log in automatically and save your cookie, any request from your machine to my malicious site would change your signature.