I was onsite at one of our restaurant clients conducting a penetration test of the point of sale (POS) environment at several of their locations. The environments were made up of several registers, kitchen displays and one ‘back-of-the-house’ server. Our methodology includes running port scans and vulnerability scans using commercial-off-the-shelf (COTS) tools to evaluate the systems and services in the environment and identify vulnerabilities in those systems. The vulnerability scans came up clean except for some information leakage on the registers.
The leaked information was a list of accounts on the system. Based on the name of one of the accounts, it didn’t appear to be part of the POS software solution and was clearly not part of the operating system defaults. I successfully “guessed” the password to this (non-standard) account set-up on the register. I leveraged this account’s access and escalated privileges, which allowed me to dump the password hashes for the register. The password hashes were sent to Coalfire’s password cracking system and subsequently cracked. One of the local accounts that was cracked was the Administrator account, and another was an account that the register’s POS software uses to operate.
I tried accessing the back-of-the-house server with the register’s Administrator account, but failed.
Then I tried to access the back-of-the-house server with the register POS account, and I was successful. Conveniently, this account was also part of the administrator group on the back-of-the-house server. At this point I had administrative access to all registers and the POS server.
I proceeded to another store that had an upgraded deployment with new registers and a new operating system for the back-of-the-house server. The vulnerability scan came up completely clean – no vulnerabilities, no information leakage. Additionally, the non-standard account wasn’t present on any of these systems, either. But lo and behold, the register software account username and password worked on all systems at this location, too. And every other store in the chain. They were now completely compromised. The only thing I didn’t have access to was their Muzak service.
The moral of the story is that a vulnerability scan, while important to maintain secure configuration, would not have uncovered this information leakage vulnerability with complete compromise of the entire restaurant chain. At the first store, the tool didn’t provide the user list that was leaked through the vulnerability. It wouldn’t have identified the weak password for the non-standard user account as it didn’t know about the non-standard user account. Nor would it have used that non-standard user account against the server. Nor would it have had that information to use at other stores. That’s the value that penetration testing brings to the table.
The root cause of this compromise: their integrator did not follow the Integration Guide that the vendor publishes. The non-standard user account is not part of the Integration Guide, is not required for the proper operation of the system, and violates the PCI PA-DSS and PCI DSS account and password policies. This is a significant problem in the field, and to address this issue, the PCI has established a new qualification for Integrators and Resellers called the “QIR Program”. This program is intended to validate companies that have the knowledge and skills to deploy systems in a secure and compliant manner. The compromise that we uncovered is indicative of the need for such a program. Fortunately we were able to find this before the “bad guys” did.