"The PCI Security Standards Council’s mission is to enhance payment account data security by driving education and awareness of the PCI Security Standards. The organization was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc."
They are essentially the governing standards body for security in the credit card industry. This article will not try to educate you on PCI but rather I wish to show in this article how testing for PCI compliancy on your own server might turn up some interesting and scary things.
PCI compliance is required for any merchant accepting credit or debit cards. PCI was born out of the fact that there is so much credit card fraud. Interestingly enough - even companies who claim they are PCI compliant are getting hacked and credit cards stolen.
To my knowledge, you do not need to conduct a PCI scan if you are ONLY accepting PayPal® Standard
however its still a good idea to scan and if in doubt about the requirements contact PayPal®.
In our test case we selected a qualified third party security assessor to conduct the test on our target server. We chose Comodo and conducted our scan. Oddly enough the target server we chose - while we knew it had a few holes in it (on purpose) we did not expect to see the amount of vulnerabilities.
17 KNOWN security holes (we expected five or so), 24 warnings and 44 security notes.
That's a server that Whistles when it walks! Naturally - we then proceeded to run YUM UPDATE to patch our server - it said: Nothing to update. This of course if we hadn't run this test - would have left us feeling good. We reran the test - same results.
A quick peak at one of those "holes" :
Apache 2.2 - URGENT - this is a nasty hole. The image only convey's part of the message that we received.
Again - remember - we UPDATED The server.
The net result is that we are running the latest build of CentOs on our server, and researching it out - it seems that the CentOs project, does not keep the 'latest' patches out there. So simply doing a update would not have brought us up to current levels. We would have to manually install the latest versions of PHP, Apache, and other server based components.
While I could debate one way or another for or against this mindset, it's pointless - the server is vulnerable and it would not pass for a PCI compliant server. Which could result in fines, loss of merchant card charging privileges or allow a hacker to break in and steal credit card data.
This was only a test of the server to see what we could learn but it spawned a thought. If my server running the what I assumed to be the latest patches and it is vulnerable - how about yours?
Part II - Fedora.
To continue our test we built a new server (thank you RackSpace cloud!) on the latest build (12) of Fedora. We built out the server, installed MySql, PHP, Apache and Joomla. We reran the test and received one error.
This error is telling us that an attacker could use the debug functions of TRACE and TRACK to use an XSS attack on our site. -- Not cool.
The fix? They suggest this.
If you have access to your Apache httpd.conf file, and depending on the version you are running you can add: TraceEnable off to the end of the file. See the Apache docs here for more information.
So in closing, while many of you are taking in money from your Joomla! sites using PayPal® and thus may not be subject to PCI compliance, obtaining a PCI scan from Comodo and subscribing to this service, might just help you discover a problem, before your Joomla! site is hacked. For those of you who are considering a full merchant account - get ready as you will be required to go through PCI compliant testing.
Until next time - stay safe!
