Today it was unceremoniously announced that a number of major restaurant chains’ franchisees had been potentially hacked between February 28, 2014 and April 18, 2014 because their point of sale (POS) vendor’s remote access account had been compromised. I say franchisees because I know a couple of these restaurant chains’ corporate operations and they were not using a third party to manage POS.
In a nutshell, the attackers gained access to the POS vendor’s LogMeIn account. LogMeIn, like a lot of similar remote access facilities, has an address book where you can store remote access credentials. So with access to LogMeIn, by default, the attackers had access to the address book that contained credentials for any customer environments in the address book (likely all customers, but possibly not).
To remind everyone, requirement 8.5.1 of the PCI DSS v3 states:
“Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.
Note: Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a requirement.”
The PCI SSC guidance for requirement 8.5.1 states:
“To prevent the compromise of multiple customers through the use of a single set of credentials, vendors with remote access accounts to customer environments should use a different authentication credential for each customer. Technologies, such as two-factor mechanisms, that provide a unique credential for each connection (for example, via a single-use password) could also meet the intent of this requirement.”
It is likely that the vendor was trying to get a jump on complying with requirement 8.5.1 in the PCI DSS v3. However, this vendor may have been using such an approach all along to manage customer remote access which is also not uncommon with technology companies.
The first thing to note is that requirement 8.5.1 is a best practice until June 30, 2015 after which it becomes a full requirement. However, as I pointed out in an earlier post, a lot of vendors will likely have to start rolling out a remote access solution as soon as possible to minimize service level agreement (SLA) issues.
One of the most likely ways vendors are addressing compliance with 8.5.1 is through services such as LogMeIn, GoToMyPC and similar services. These are inexpensive services available to any organization or anyone. There are also enterprise solutions such as those from Bomgar and the like that purport to have better security. However, all of these solutions share the concept of an address book to make gaining remote access easier for the vendors’ users that rely upon them. And that is their Achilles’s heel. If an attacker gains access to the remote access service, they gain access to the address book and, therefore, to the customers’ credentials stored in that address book. Game over.
It is important to note though that what this vendor was doing fully complies with requirement 8.5.1. But even though this service provider was complying with the intent of 8.5.1, the implementation was flawed. This is just another example of how PCI compliance does not mean that security issues cannot still occur.
How easy is this to happen? Think a spear phishing attack against any vendor that does remote support and maintenance. Regardless of the customer credential management solution (in-house or cloud based), once access to the credential management solution is compromised any concept of customer security is over.
So what should vendors being doing to mitigate this situation? Exactly what our vendor who was breached did, implement two-factor authentication on the credential management system. Spear phishing attacks will not be successful because even with the credentials to LogMeIn or similar, the attacker will need the second factor. Yes, the attacker can still compromise the support person’s desktop, but they will not have access to customer credentials.
Trouble is, some vendors will want a cheap two-factor solution meaning something that sends out codes via SMS, email or telephone, versus RSA SecurID or SafeNet to name a few. Solutions over SMS, telephone and email have a variety of known vulnerabilities and can easily be intercepted or even redirected. In the case of LogMeIn, they indicate that they only support SecurID.
Regardless, all of you service providers out there that have remote access to your customers managed by some enterprise credential management solution, please implement a strong two-factor authentication solution on your customer credential management solution before you too become a newspaper headline.
I would like to believe that this vendor thought they were doing the right thing and got burned because of how they implemented their solution. At least they stepped up and fixed it the right way. Unfortunately, this is how we sometimes learn, from our mistakes.