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."
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.
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?
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!
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.
Is that not the reason to use POST for important actions (e.g. modification to data) rather than GET?
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.
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 :)
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
I may be wrong, but I think Amazon already implements something like that. I cannot bookmark my "shopping cart" page ... and then go into it from a different computer with a different IP address. Even if I'm logged into Amazon on both computers.
... weird.
There seem to be a lot ways to defeat this "sleeping giant" of a vulnerability. And most of them seem to related to basic security practices by the websites themselves.
"Solving" this at the firewall level just seems
http://www.cgisecurity.com/articles/csrf-faq.shtm
Believe me, if I started murdering people, there would be none of you left.
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.
So long as the malicious site isn't on HTTPS you should get a url referrer with the request that doesn't look like the one you'd expect to get from a legitimate request.
thank God the internet isn't a human right.
Could anyone explain what this is all about? The article doesn't go into much detail. We all know that any http GET request can be accessed from another website, for example by putting it inside an IMG tag. When the user's browser visits the site, it goes and fetches all the image URIs. But that doesn't seem like an attack, because as we all know, you should never use GET requests for anything other than harmless idempotent information retrieval (to perform potentially dangerous operations use POST requests, which cannot be linked to).
Is there something else going on here?
-- Ed Avis ed@membled.com
While that does happen, it probably would be extremely rare.
And the "attacker" would have to pre-craft the page. This would be easily defeated by simply dynamically generating each page and giving a short time to live.
The attacker would need to know the dynamically generated ID
and
He'd need to know it before that page expired
and
He'd need to get that code into his webpage that you were looking at.
Sure, this "attack" would work on static pages. Or pages that use a guessable format (based upon "screen name" or some such). But that's about it.
And that's exactly why this is such a concern. Everyone is going to ignore it and think they are safe.
You don't have to have the two sites open at the same time, you just have to have not logged out of the sensitive site when you visit the malicious site. Given that at least one popular consumer firewall doesn't let you log out, it may not be as easy as you think to log out.
Finally, do you really expect every web surfer out there to clear their cookies and close their browser every time they log into anything sensitive? Do you even think every web surfer out there has any idea what is sensitive and what is not? How about that little web control panel that is only used locally, so it doesn't really need to worry about security?
It's things like this that make me laugh out loud any time I see a security related product, or any product where security is a strong concern for that matter, with a web interface.
Personally, I surf with Firefox and control with IE (compatible with the intranet).
A NYC lawyer blogs. http://www.chuangblog.com/
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.
How can I get IPTables at the command line to do this?
2 cheapest ways to fix:
1. cookie / session authority per form
2. validate important transactions with either
"pls enter the" {random} "digit of your password"
or
"type the letter shown on this image"
Routers are not the only target! Any kind of bank website, or server app that sits behind your firewall could be at risk to CRSF. I
Straw Poll:
/. and some less then respectable intentions.
How many people are browsing Slashdot right now with a web interface to a router or appliance open?
I/m betting that there are enough of you out there for me do do some nasty stuff if i had a 0day in
UTM is the new buzzword for security appliances, which for the lay person is: unified threat management. As complicated as UTMs are, when sold to SMB users, as described in the article, most do not employ a full-time sys-ad and either self configure or hire a consultant. The problem is that daily business needs are dynamic and the average VP/CFO/CTO/CSO/CIO all in one will not configure all of the flags, filters, and rules to adequately protect the internal network, like accidentally placing the file server in the DMZ. These UTM devices are marketed as the drop in fix-all plug it in and forget about it solution, and not to mention affordable for the SMB market. UTMs are also in the Enterprise market as large companies buy smaller companies to create SOA UTMs, like Cisco buying Iron Port, and are a morphed version of VPN, IPS, Firewall, NAC, and AV rolled into one. Traditionally each device required a sys ad and now with the new SOA model only 1 person is needed to manage that 1 box. So now imagine what 4 sys ads did and there is 1 sys ad with 1 device and the many flags? In the end the private network still gets hacked since the ports are open on the firewall and the NAC and IPS do not detect the hostile packets as the hackers have already found a way to bypass the security. Why so complicated? What about just closing the ports on the firewall entirely and using a basic commodity firewall? Then how is traffic going to get through like VPN? Easy. Steelcape Inc has engineered a new protocol that allows traffic to go through the closed ports on a firewall thus eliminating the primary attack vector of hackers. Set up takes only minutes and there is an added layer of security with an enterprise server that determines which zones can transact data which is similar to a VLAN. If these SMBs used the Steelcape solution they would have kept their firewalls and had a securer network.
Umm, I think this comment should probably be bumped [modded] up. I'ts darned helpful information.
It seems rather foolish to me to be browsing the web in one tab/window while another is logged into your credit card or paypal account. That isn't even a natural workflow for me. When i log into something like that, i'm there to do something and then get out, not hang out. The real culprit seems to be cookie retention. I know cookies are very useful and i'd even say indispensible. However, I don't think any software should retain cookies between sessions. I always configure my browsers to delete cookies upon exiting. Trusting a computer to have your password is more dangerous than trusting a person to have your password.
OR...
post your password on slashdot and it will be secure...
If it's the device I've heard about before, it tunnels the things you need through non-TCP protocols.
So, yeah, you don't need to open up *any* TCP ports. I'm not sure it buys you anything, besides the customer's ear for 2 seconds.
Aside from referrer checks, I don't see how a security gateway is supposed to prevent this.
I don't see any release information on Checkpoints site. The software download comes from a non checkpoint site. The patch release notes are an image of a pirate guy. Unless some one can supply some other supporting info this is a HOAX and should be removed from the Main page. On another note don't these articles get investigated before posting? Isn't there a responsibly of due diligence by the /. Admins!!!!
Change the web browsers. Firewall sites from each other in the browser. Any http authentication / cookies / SSL Client certificates used to access a site or that were created by a site must not be acessable or usable from another site for anything.
While we're at it. Allow users to clear HTTP authentication passwords and SSL client authentication or better yet, clear them when the user closes the last page that uses them.
This caching of authentication while any browser instance keeps running is dangerous and, for most users, unexpected.
No it doesn't. There's no "software download" from the Sofaware site, the company that handles Check Point's SMB business.
If you have a Check Point product affected by this, it's probably already downloaded the 7.0.45x fix.
I think that simply creating a unique ID for each form/URL and validating that on the Post/Get request should stop the problem.
:-(
Unless of course the javascript loaded the page containing the form, parsed it and pulled out the secret variable
Ok, it won't solve the problem, but you know you want to do it anyway ;/)
Oh, I'm sorry sir, I thought you were referring to me, Mr. Wensleydale.
This has been old news for years, there are much bigger and more real problems out there in commercial sites. Before I worry about CSRF, I'd far rather people sorted out SQL injection and XSS which are ridiculously common. If a site is (reasonably) secure (something I rarely see) then modern frameworks like django already provide tools that eliminate this issue see http://www.djangoproject.com/documentation/csrf/
You are somewhat correct. The attack vectors that are eliminated by closing ports on the firewall are:
1) Port based exploits
2) Man-in-the-middle attacks
3) Wireless attacks-as long as router or AP is protected by Steelcape
4) DNS hijacking
5) packet ip spoofing and hijacking
If TJMAXX was using a stronger password policy and was using Steelcape's protocol from the WAP or wireless router to the wireless device or to the server there would be no $6 billion dollar poster child, since their firewall would have denied the hackers attempts to access their private network.
see for yourself:
http://www.steelcape.com/
Well it got you as far as Slashdot.
Next thing you know you'll be revising Wikipedia entries.
I don't have the time right now to give this issue any serious thought, but my immediate reaction is that the present cookie mechanism is too promiscuous. If we had the notion of a secure cookie, I suspect some of these problems could be eliminated.
A secure cookie is a cookie which includes submission directives: don't send this cookie with any request unless A and B and C are true. These conditions could be that the referrer page was fetched through the same SLL authentication, or from a page with a correct referrer tag, or not from any page containing/enabling Javascript, or pointless friviolity 2.0, or ideally, all of the above.
These cookie directives would allow a well-implemented user agent to protect the user against many of the attack scenarios described in this thread. Presumably the site issuing the cookie in the first place knows what kinds of pages and content the cookie should be associated with for legitimate uses.
Most of the hacks described here would become useless if the cookie won't play. Am I missing something, or is this problem really that stupid?
http://www.steelcape.com/ Congratulations, you've invented your own tunneling protocol. Like IPSEC or GRE, except instead of being carefully designed and peer reviewed by the IETF it's been tossed together by some no-name, snake oil vendor that thinks spamming Slashdot is an acceptable marketing strategy.
You do realise that anyone can click your username and instantly see how you're posting the same irrelevant shit to different stories, right?
Wow a user-marketingdroid.
And this is why - in order to forge the request you have to know the internal IP or host you're trying to exploit in order to construct the CSRF attack vector.
e thing?badstuff=this
So this attack ONLY works if you already have some knowledge of the companies internal network structure.
Here is an example working CSRF attack
a) I put a CSRF attack on my blog - some AJAX request or hidden image to go to http://internalcompanysite.net/somesoftware/dosom
b) I send sysadmin an email poting at my cool blog
c) Sysadmin visits my cool blog boom he is expoited!
Problem? how did I know what internalcompanysite.net was, or where somesoftware is? Answer: I don't.
CSRF can only be used if you already know the attack vectors for the company. Otherwise it is useless.