Feeds

back to article cPanel, Netgear and Linksys susceptible to nasty attack

If you use cPanel to administer your website or certain Linksys or Netgear devices to route traffic over your wireless network, you're susceptible to web-based attacks that could take complete control of your systems, two security researchers said Saturday. All three wares contain CSRF, or cross-site request forgery, holes that …

COMMENTS

This topic is closed for new posts.

Browser problem, not site problem

To be sure, this definitely is a problem, and we've known about it for a very long time. However, contrary to what these "experts" claim, it is NOT a problem with cPanel, Linksys, or Netgear. This is a problem with BROWSERS. It is the browser which is not protecting an authenticated session. It is the browser which is allowing a web page from one domain to make/redirect requests to another site, especially a protected site. And it is the browser which allows this redirection to be executed via Javascript.

One might argue that sites should be allowed to make/redirect requests to other domains, and I would be open to that argument. I do not, however, understand why browsers do not protect authenticated sessions. By requiring authentication, you (the website) are telling the browser that the site is protected by user authentication, so why do browsers allow other domains to make requests to the protected site? If a request for the protected site comes from any site other than the protected site itself, the browser should, at the very least, alert you to that fact and prompt for your authentication credentials again.

Personally, I never understand why you can't treat each browser window (and now tab) as its own session, separate from other windows and tabs. This is, once again, a problem in the way browsers access a website, which is something the website has literally no control over. If the browser wants to share the user's authentication status among all open windows and tabs, there's not a damn thing the website can do about that.

0
0
Paris Hilton

So if I understand, protection is easy?

Just log off any site you care about before you go looking for porn, yes? Probably start with a new browser too.

Paris; because she's not only easy, but also understands the importance of protection.

0
0
FAIL

Layer 7 traffic management

This is the second big exploit announcement in a week which could be easily mitigated by using a decent application layer traffic manager.

Bind9 exploit Pah!

http://knowledgehub.zeus.com/articles/2009/07/29/bind_9_exploit_in_the_wild

Time for another article...

0
0
Silver badge

But that's the point, right?

"Of course, the best defense is for vendors to fix their buggy products"

Well, as the rest of the article implies, that may not be possible or easily done due to the way authentication works on the web.

0
0
Boffin

NoScript does fight CSRF

A couple of things need to be clarified.

1.

NoScript contains a module called ABE (Application Boundaries Enforcer) enabled by default, which is specifically designed to fight CSRF.

It's similar to a web-application firewall, but working on the client side.

Its built-in rules block all the CSRF attacks from the internet to your private network (such as those against your router or your intranet servers), but it can be configured either by the user, by the web site owners or by trusted organizations to prevent any kind of CSRF scenario.

More info here: http://noscript.net/abe

2.

On the other hand, Mozilla's "Content Security Policy" proposal which the article talks about, while effective in the long term to help web authors at mitigating their XSS vulnerabilities, can't do anything about CSRF, because it's just out of its scope: https://wiki.mozilla.org/Security/CSP/Spec

0
0
Stop

Feature

I dont see how the issue (as far as cPanel is concerned at least) can be the fault of a "bug" in the system - As the reply from cPanel notes, it's an intentional feature that cPanel will accept commands from logged-in users, to allow various billing/manipulation scripts to be able to communicate with the system.

cPanel does (and has for years) provide several perfectly easy ways to mitigate/avoid the feature/vulnerability (delete depending on paranoia level), the most straightforward being to enable it's own security check to only accept commands from requests that have a referrer, and have one matching a domain/ip on the system itself. This breaks the above script integration, but it also means the problem discussed in the article vanishes, unless your XSRF attacker fancies getting into the realm of having to compromise an account on the system in the first place just to launch the attack. The option within cPanel even perfectly clearly states that enabling it's a good idea to help avoid XSRF attacks. And suddenly not having this option enabled that's existed for quite some time is a massive newly-discovered flaw?

Here's a blog post from cPanel in may 2008, over a year ago, discussing their knowledge of the possibility of XSRF attacks and the introduction of the referrer checks:

http://www.cpanel.net/2008/05/cpanel-security-update-advisory.html

Second way to avoid the issue - Don't be a muppet. Baily goes on about how CSRF is such an under-appreciated problem, but appears not to mention (or at least doesnt get quoted in the article) that those big useful logout buttons in pretty much every authenticated system on earth that most users are too bloody lazy to use are there for a reason.

The article mentions logging into cpanel as root (though the same non-flaw would exist for any non priviledged user goes for their own account at least), if you're a sysadmin logging in as root standard good-practice should tell you not to be surfing around elsewhere while managing the system, and to explicitly logout when you're done (thus wiping out the session both ends and, again, removing the possibility of the attack), whether the specific possibility of an XSRF attack exists or not.

Those logout buttons happen to exist in linksys/netgear routers as well. And online banking systems. And pretty much everywhere else. Press them, and you're no longer an authenticated user, and so can no longer be used to launch the attacks. Simple.

0
0

This post has been deleted by a moderator

Linux

bloody CRSF

I wish "researchers" would stop talking about CRSF being a flaw.

Its just a automation of a user action which is triggered by a XSS.

User clicks "Delete All" is the same as writing a script that does the same thing and getting the browser to execute it.

0
0
Anonymous Coward

@zerofool2005

"Its just a automation of a user action which is triggered by a XSS."

<img src="http://example.com/delete.pl?what=everything">

Where's the XSS?

0
0
Anonymous Coward

Site problem, and browser problem

CSRF absolutely is a bug on the server side. Mitigation techniques have been around for years, but none of these vendors implemented them. The attack has nothing to do with Javascript or XSS.

It could be effectively argued that the bug is really in the HTTP and HTML specifications- still not the browsers' fault- but that does not change the fact that these vendors built the applications using current technology, for use with current browsers, and preventing these attacks is not difficult knowledge to come by.

cPanel's XSRF protection feature is virtually undocumented and as implemented, it is ineffective, which was one of the points made in the talk. The presenters both described and demonstrated a bypass of that feature.

NoScript is a useful tool to be sure, and while it did recently add the ABE, it only prevents cross-zone (ie. internet to intranet) attacks. The cPanel CSRF still works perfectly.

0
0
Stop

Chrome...

If only there was a browser with it's tabs running in seperate sandboxed threads, that would provide protection for the average less than computer savvy user who is likely to remain logged into one site while surfing another!! Oh wait, there is, Google Chrome!

Now, if only every browser done that, a whole class of vulnerabilities either go away completely or become much more difficult to exploit!!

0
0

re: Site problem, and browser problem

"CSRF absolutely is a bug on the server side. Mitigation techniques have been around for years, but none of these vendors implemented them."

I'm afraid I just don't see it. Could you please explain exactly how this is a server-side bug? The way I see it, the server tells the browser that the site is protected by user authentication. The browser asks for a username and password, sends that info to the site, and the site authenticates the user. Subsequent requests from that user contain that user's authentication information in the HTTP headers, so the server processes those requests as the authenticated user. How is that a bug?

Maybe this is a bug in HTTP, I'm not sure. I haven't read the HTTP specs, so I can't say either way. But I remain convinced that this is a browser problem. If a browser allows code (HTML, Javascript, Flash, or anything else) from one page to access a protected page at a different site, without even doing so much as throwing up a warning, then it is insecure by design.

0
0
Anonymous Coward

Discuss

CSRF in form-based authentication is a bug on the server side.

CSRF in so-called basic authentication is a bug on the client side.

0
0
Bronze badge
Boffin

NoScript

Why does everyone always jump on NoScript as the answer to every security issue?

The real answer is to block all HTML, not least because so many sites rely on JavaScript these days that most users have got half of the Internet whitelisted, completely negating any effect.

0
0
Anonymous Coward

If they just stop forcing us to use all this crap in the first place ...

Of course it would be nice to be able to just turn off everything iffy: iframes, script, third party cookies, etc. Problem is all these banks and retailers and everyone else who harps on about how much they care about our security have websites that would stop working if we did.

0
0
This topic is closed for new posts.