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.
PCI Guru 
“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.”
For this recommendation, they says we can use the two-factor authentication for the vendors:
– we can still use the same username + password for vendors to access to all customer environments.
– but we need to implement the second authentication (like send the OTP code via SMS which is the unique credential for each connection).
With the second authentication like above, do we pass the PCI DSS?
Sorry, but two-factor authentication for remote access is already required.
The problem that the Council is trying to fix is that attackers are using the similar credentials to get in everywhere you have your solution installed. The attackers are stealing the two-factor fob/certificate/etc. and then breaching systems and networks using the common credentials.
The fix for most vendors is to implement an Enterprise Password Vaulting solution. However, you must then be careful to protect that vault from being attacked because we have already seen breaches where the vendor’s cloud-based vault were broken into and customers’ credentials stolen. This typically occurs because the vendors are not careful in disabling credentials of former employees or they stupidly share the same credentials for the vault because they cheaped out on a non-enterprise solution.
For me it’s not clear if the Requirement 8.1.5 and 8.3 apply just for access to the CDE or for the organizations entire network. If some IT personnel allow access to their workstations using GoToMyPC and from there the support vendor accesses another non-CDE system (all while the IT tech is monitoring) is the client OK?
I am not happy with any sort of remote access to PCs but some of my clients are.
Remote access is remote access regardless of the method and where you gain remote access. Two factor authentication is required in all instances.
Thought provoking as always. I think 8.5.1 is also relevant here. It requires that vendor access is only enabled when needed and is monitored in use. Granted that won’t help if the entire POS process has been outsourced to a service provider. But if we are talking about support for systems managed by the merchant then I think it would apply and it ought to stop this sort of attack.
Agreed. But that is the problem in today’s outsourced world. The outsourser is in control, not the merchant because the merchant knows nothing about the POS and does not want or need to know. That is the outsourcer’s responsibility.
What about remote services not provided by people? Remote managed Windows patching or AV updates that flow from machine to machine over a VPN? 2 factor is only required with a human is involved?
Dedicated connectivity over a VPN from a vendor for management only requires two-factor if it is an on-demand connection versus a dedicated connection. Dedicated VPNs are done using IPsec, so the vendor and the customer have control over that connectivity. Such connections are usually done on a router-to-router or firewall-to-firewall basis and require certificates at both ends.
SSL and SSH VPNs are on-demand in nature and it is on-demand VPNs that require two-factor authentication because they are on-demand, not dedicated. I have encountered a number of instances where SSL and SSH VPNs are created by file transfer processes and the like without human intervention. However, if that connectivity through the on-demand VPN could potentially compromise the cardholder data environment (CDE) then it needs two-factor authentication.
This has really made me think about a service provider I use (in a non-PCI context). I’ll be pointing them here and asking what their approach is…
The problem is that the “expert” isn’t one in security, which is what PCI addresses. It seems like the number of breaches that result from service providers providing security services that they are not qualified to do. Also the merchant has the responsibility to enforce 2 factor authentication for remote access to the CDE (PCI DSS req 8.3). POS support I would consider in this category. I totally agree with your response to the comment above about franchisee operators wanting to outsource everything possible but ultimately PCI compliance falls to the merchant. They need to make sure they are meeting all the applicable PCI DSS requirements and also ensure their service providers are qualified for the services they are providing.
Another complementary approach to address this issue might be to monitor remote connections by vendors. If connections come up outside of service hours, or without any ticket requiring such connections, the merchant might detect the attack early on and be able to disable the compromised account for instance. Of course, it depends on the nature of the service being provided.
Just a thought…
Good idea and recommendation. But remember, in a typical franchisee environment, that is probably more than the franchisee wants to take on. The reason is that most franchisees are not large operations. They may have only a single store or they may have up to five. They outsource for the vendor’s expertise with POS, changing fry oil, etc. as well as to get one more problem off their plate. They trust that the “expert” knows what they are doing.