Remote access breach via POS system sparks yet more consumer data leak fears

Filed Under: Data loss, Featured, Security threats

POS. Image courtesy of ShutterstockA supplier of point-of-sale (POS) equipment based in northwest US has informed its clients of a security breach in the remote access system it uses to log into clients' networks, meaning hackers could have used the system to intrude into the clients' machines and potentially harvest customer payment card data.

The vendor in question is Information Systems and Supplies Inc. (ISS), operating out of Vancouver, Washington state.

In mid-June ISS sent a letter to some of its clients detailing the breach in its LogMeIn remote access management account and warning them of the risk to their customers.

Although several news outlets have suggested that the breach may have affected a selection of big-brand restaurant chains supplied by the vendor, including Dairy Queen, no definitive details have been released concerning which of ISS' customers may have been affected by the leaked LogMeIn access codes, and there has so far been no evidence that data was indeed taken, let alone used for fraud or identity theft.

The details of potential leak victims seem to be based only on the public list of client testimonials formerly published on the ISS website, which at the time of writing is rather shamefacedly blank but when last archived by the Wayback Machine (January 2013) showed a number of chains including Dairy Queen, Buffalo Wild Wings and Taco Time, as well as several smaller local food outlets.

It seems fairly likely that the breach originated with some sort of phishing attack on ISS to obtain their LogMeIn credentials.

With those in hand, it seems the attackers were then able to access client systems set up for remote access at will, with confirmed breaches on February 28th, March 5th and April 18th.

In their letter to clients, ISS insist they have reset their passwords and enabled "a secondary unique password" (read two-factor authentication) to prevent future intrusions, and advises anyone who suspects their card has been compromised to contact their bank ASAP.

This is pretty good advice at any time, and something people should do whether or not they've been dining at restaurants which may have had their digital backdoors nosed into by strangers.

The problem of third-party providers and contractors is one we've run into repeatedly of late, and has been a big part of the retail and restaurant data-breach bonanza of the past year or so.

There are lots of situations where a company may want to allow a third party to access their computer systems, to install or provision new software or hardware, to maintain or troubleshoot, to monitor and record.

Letting someone else do this means trusting them and requiring of them the same standards of security and caution you yourself uphold.

Letting them do it using an ongoing remote connection should mean the third party firm, their networks and all their employees are considered part of your own security environment, and should be checked and monitored as closely as possible.

In many circumstances this is simply not possible, especially when the client is a small business such as a chain restaurant franchise and the third party is a much larger provider servicing a large number of clients; the larger body tends to use its weight to push its own agenda and preferences, and the smaller party in the arrangement has to simply trust them to do things right.

In this case, it seems things weren't done right at all. Phishing is of course notoriously hard to spot, especially highly focused spearphishing, but with something as sensitive as a remote access tool connected to POS systems security should be given highest priority, and 2FA is a basic requirement in such circumstances.

Quite by coincidence, LogMeIn's company blog, mostly used to promote the company's range of services, has featured a couple of security related posts in the last few days since the ISS story hit the news, one covering the dangers of phishing and how to avoid them, and another listing "Customer Security Tips" with 2FA top of the list.

2FA features are apparently available in all LogMein solutions, and should be enabled and used wherever possible, as they should in all services which provide this vital extra layer of security.

Even if you have every conceivable layer of security turned up to the max at your end, you could still be at risk if you're letting other people mess with your stuff unsupervised.

So make sure you insist on proper security from all contractors and service providers, and check they're doing everything they should be too.

Image of POS machine courtesy of Shutterstock.

, , ,

You might like

6 Responses to Remote access breach via POS system sparks yet more consumer data leak fears

  1. Jason · 463 days ago

    Logmein also sent notification to users that it was vulnerable to heartbleed, so possibly another way the account may have been breached.

  2. Cory · 460 days ago

    LogMeIn has some extensive logging features that should not be ignored on a properly configured setup. I have used LogMeIn Central daily for over 5 years and once it is configured properly, it works wonderfully and logs very well also.

  3. Joe Dirt · 460 days ago

    Why didn't they have 2FA before the breach?

  4. Jim · 459 days ago

    Call me paranoid, but I would require a third-party POS-vendor to use a dial-back verbal hand-off process to get access. This is in addition to normal 2FA.

    Of course, I'm a perfectionist engineer, not a small business owner. This might not work very well in real life.

    On the other hand, one customer-impacting security breach would mean the small business wouldn't be a small business any more. It would be a statistic.

  5. Jim · 459 days ago

    By the way, a second password is NOT 2FA unless a separate validation process is used for the second password. Two passwords are the functional equivalent of one longer password if they both pass through the same validation process.

  6. Simon · 457 days ago

    The new version of PCI DSS V3 requires 2FA such as token and not 2nd password to be PCI Compliant. Another example of security basics and best practice IMO.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

John Hawes is Chief of Operations at Virus Bulletin, running independent anti-malware testing there since 2006. With over a decade of experience testing security products, John was elected to the board of directors of the Anti-Malware Testing Standards Organisation (AMTSO) in 2011.