eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The all-in-one device many businesses think is protecting their security likely has a hole as big as a Boeing, according to new research from Calyptix Security.
Calyptix Security, in Charlotte, N.C., has discovered that CSRF (cross-site request forgery), a type of vulnerability that typically concerns large sites like Amazon.com, Google and Digg, also affects a vast array of the security devices that enterprises plunk down at the heart of their defense systems.
Calyptix notified eight security vendors of the concern, said CEO Ben Yarbrough, but only one—Check Point Software Technologies—has responded by issuing an update to multiple versions of its vulnerable apps. Calyptix declined to release the names of the other seven vendors, but said those vendors provide widely deployed appliances.
Calyptix classified the CSRF risk as medium, given that a successful attack requires knowledge of the URL that is used to manage a device. But in practice, “many are given addresses at the start of RFC 1918 address spaces, such as 10.0.0.1 or 192.168.0.1. The attacker can try several addresses simultaneously,” the company said in a June 26 advisory.
The particulars of the CSRF vulnerability—also known as one-click attack or session riding—differ according to vendor. With Check Point, the vulnerability allows an attacker to run commands on the Web interface of UTM devices if he or she can get the Check Point user to view a hostile Web page while logged into a Check Point device.
An attacker can commit various actions with a successful CSRF exploit, including opening up remote access through a VPN tunnel. Through a separate but iteratively worse vulnerability, a logged-in user can also change the administrator password without knowing the existing password, according to Calyptix.
The vulnerability is somewhat similar to XSS (cross-site scripting), said Calyptix Security Engineer Dan Weber, who headed the research that discovered the UTM device flaw. But, he added, the flaw deserves a class unto itself.
While XSS requires the attacker to inject unauthorized code into a site, CSRF merely has to transmit unauthorized commands from a user the Web site trusts.
To date there are no known public exploits on UTM boxes. And a successful exploit requires the user to have more than one browser window or tab open.
If a user is viewing a secure site in one browser tab while visiting a hostile Web page in another tab, Weber said, the hostile page can then submit information through the secure page, which will accept the information as arriving through a secure channel.
“[The UTM device] cant tell the difference,” he said.
Weber said the problem isnt a JavaScript flaw per se, although JavaScript makes it much easier to exploit. “Its really a problem with the Web site,” he said. “But people havent been paying attention to this until recently.”
Those who have been paying attention have discovered vulnerable sites of substantial size. Indeed, heres an example of an attack on Digg. Heres another example of an attack on Amazon.com, and yet another example of an attack on Googles AdSense.
The Amazon flaw has been open for over a year, according to Chris Shiflett, lead of the Web application security practice at OmniTI, in Columbia, M.D. Shiflett discovered the Amazon CSRF flaw on March 15, 2006. Amazon verified the vulnerability and told Shiflett it was a “top priority,” but a year later it was still open.
Amazon.com, headquartered in Seattle, Wash., declined comment on the matter, citing a policy against speaking about security concerns. Google, based in Mountain View, Calif., did not respond to a request regarding whether the AdSense vulnerability is still open.
As for the UTM devices, Weber said, there are ways to mitigate the danger.
“Dont use default passwords. Even if youre not logged in, if your password is easy enough to guess, a [malicious] site can log in for you without you knowing. Even a little [change] from the default will help. Its common to see the user name and password of admin, admin. A hostile page can log in for you if youre using [such a] default password,” he said.
To mitigate the danger of successful CSRF exploits on unpatched Check Point systems and other appliances, users managing the device can avoid staying logged in for longer than absolutely necessary. When done at a site, log out as soon as possible, Weber said.
Some sites and some devices make it hard to log out, he said, so users should close out of the browser when done using it.
Here are the advisorys mitigation steps for non-Check Point devices:
“1. Use Web management in isolation. Each browser instance should only connect to one devices Web interface. Do not operate multiple windows or tabs when managing a device.
“As a suggested approach, you could use Firefox to browse the Web while using Internet Explorer to manage only your firewall. You could also run your favorite browser inside of a virtual machine.
“2. Log out of your Web interface when not using it, and configure its inactivity timeouts.
“3. Update to the latest version of your products software. CSRF attacks have only recently gained popularity, so any device more than a few years old is very likely to be vulnerable to them.
“4. Disable JavaScript. Note that many devices and Web sites require JavaScript to be enabled. Authorizing sites on a case-by-case basis to use JavaScript can significantly reduce this vulnerability. (Please note that there may still be ways of exploiting this without JavaScript, but they generally involve social engineering or a poorly designed web interface.)
“5. Operate your Web management interface on a non-standard address and/or port. (Please note that this is security through obscurity, and although it may protect you from general attacks, anyone targeting you will likely be able to figure out the address.)”
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.