Abusing PCI Scanners

My company has a client with a small but successful ecommerce site. This site is a prime example of what I'd like all ecommerce sites to look like- thoroughly tested code, FTP disabled and no other unnecessary services running. The client is careful to make sure that patches stay up to date, and system logs are regularly reviewed.

It's one of the few companies that I would trust to handle security themselves. Unfortunately, this client needs to have his website tested for PCI compliance. He signed up with an ASV, and they started running scans. When the results came back, it showed every port on the server as being closed. A bit of research determined that the IDS had kicked in during the initial portscan and blocked the scanner from accessing his website at all- exactly as it should have. I received an email from the client:

They told me that [their server] needs to be 'whitelisted' - Their IP address needs to be listed as 'friendly'.

Essentially, we had to whitelist their IP on both IDS and firewall in order to get the PCI compliance certificate. This is pretty common throughout the industry, and I've heard this request from clients using a variety of ASVs.

Any security person should notice the problem though- the scanning system could not get past the IDS, so we opened the door and invited it to come in and break things.

I don't think many people have looked into the implications of this. Security administrators routinely poke holes in their own systems for the purpose of achieving PCI compliance. If that scanner were to be compromised in any way, it would leave my client's system (and thousands of others) vulnerable.

On Monday, I published details about a critical McAfee CSRF hole. Yesterday, I disclosed vulnerabilities in a handful of PCI ASVs' web sites and customer portals. Compromising the security administrator's account with web exploits is just one way to abuse the scanning service. Here are a few more-

• Client credentials can be compromised through offline attacks. In a recent weekend trip, I was driving by an ASV's office. On the top of their dumpster was a stack of customer signup forms with usernames, passwords and contact info- faxed in, entered into the system and discarded without even a trip to the paper shredder.


• The auditors themselves can be compromised in the same way- next to that customer information were printed pages from the administrator side of the ASV's website. Sales scripts, emails, and everything necessary to perform a social engineering attack were there too.


• Once the client or auditor accounts are compromised, the attacker gets lists of servers-including "secret" database, backup, infrastructure, development servers and others that shouldn't be publicly known. Along with the servers, they get nicely-formatted reports of all the vulnerabilities found


• In general, A few servers will perform the scans on all an ASV's clients. If compromising accounts isn't to your taste, you could just sign up and pay for the service. In most cases, all that's keeping you from scanning systems other than your own is a service agreement. As one employee at an ASV noted: "I am...waiting for a rogue account to use an ASV to scan sites that they don't have privileges to scan...to assist them with identifying vulns." Would they know if it had happened? With IDS disabled and scans already performed at random intervals, who would notice? It may not have happened yet, but it's bound to happen eventually.


• Knowing the source IP of the scanner (and knowing that it has full access to the target system), packets may be spoofed and a malicious payload delivered.


• Many ASVs use Nessus to perform these scans. It would be theoretically possible to piggyback a targeted, malicious payload with a normal plugin update. This probably wouldn't be worth the effort, but the idea of subverting the entire security community to execute a single attack appeals to me in a sick way.

I understand the good intentions and even the necessity of performing website scans. I should be clear: I am all for the testing of applications and systems, and I think that by and large, most systems are better off because they perform these PCI scans. The problem is that when we are trying to get that compliance certification, we approach it with an engineer's mindset ("How can I make it work?") rather than an auditor's mindset ("How can I make it fail?"). Even in the process of securing our systems, we need to stop at every step and consider the implications of our actions.

Assuming that the PCI ASVs treat clients and data with due care, these attacks are mostly not practical. Considering how irresponsible these security companies often are, inviting them to attack your server is likely a Bad Idea.