I am always astonished at the common recurring themes that expert penetration testers uncover during routine testing for requirement 11.3 of the PCI DSS. Since misery loves company I will assuage your pain by pointing out you’re not alone – I’ve seen these same issues for a decade now.
“Your database is in the DMZ isn’t it?” to which he sheepishly replied, “Yes!”
Here are those common reasons:
- I can pull down your entire database of key information.
- You’re still sending clear text passwords in your application.
- Your web application is fraught with XSS vulnerabilities.
Your Database
Yesterday I was speaking with a fellow at a business trade show. He lamented about how his business had recently been hacked, and all of his customer data had been altered such that all his customer addresses now show Ontario, Canada. I said, “Your database is in the DMZ isn’t it?” to which he sheepishly replied, “Yes!”
That is a simple example of ignorance, but more sophisticated organizations – those who process card data, for example, and even those with multiple POS systems and central data relays – have been known to display a more sophisticated (though no less forgivable) ignorance.
One such organization did have their database in a secure zone, but due to blind SQL vulnerabilities, the penetration tester was just one command short of downloading their entire database structure and data.
Another organization had no password on several logins, and as above, the tester was able to potentially download the entire database. In fairness, that scenario was on an internal white box test, but no less ignorance of the facts regarding the issue.
Clear Text Passwords
Organizations build and run applications. Some are public facing, others have internal access only. Either way, equally astounding is the fact that password schemas often pass such in clear text instead of using cryptography. This is every hacker’s dream, giving him access to data, systems or worse – root access.
I am always floored when a major SAaS company is discovered to be running clear text passwords in parts or all of its application(s). Many a company has been compromised due to this issue.
Cross Site Scripting
Web server applications that generate pages dynamically are vulnerable to a cross-site scripting exploit if they fail to validate user input and to ensure that pages generated are encoded properly. An example of this is en exploit that creates a link to a page that looks proper but sends the user to a phishing page to steal credentials.
This is always do to insecure application coding with a failure to properly validate the user input or handle error messages.
The point here is that I’ve seen this in many card processing organizations where the failure to fix this vulnerability could be disastrous.
Summary
Having pointed out recurring key issues, you may be saying, “Well I can see that in other companies but not in mine!” The problem is, sometimes when one vulnerability is fixed, others are introduced. So while you may have passed your point-in-time compliance audit last year, this year may be a different story.
It is instructive to point out the PCI requirement 11.3.1 which applies here: “Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification.” Most companies simply don’t do this.
In summary, you don’t have to fail your PCI Audits every year – just test and fix before the auditor arrives (vs. waiting to test while your annual assessment is in progress), and during the ensuing year ensure that at least one additional pen test is conducted to avoid cascading accumulation of problems.