Slashdot Mirror
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."
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?
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.
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?
End of lesson. You may press the button.
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 :)
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.
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.
RFC 1945, section 12.2 (under the oh so stealthy heading of "Security Considerations"):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?
CSRF explained, albeit clumsily. The examples made the article. Solution: use POST requests for user actions, and add unique tokens to each form.
technical writing / development
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.
---- Just another spud server.
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.