A holiday-weekend card data scare

Last Wednesday, Brian Krebs reported that Target was investigating a breach of its card payment systems. Target confirmed it the next day: around 40 million cards used in its US stores between November 27th and December 15th, so most of the busiest shopping weeks of the year. The details aren’t public yet. The reporting suggests the registers themselves were compromised, though nobody has said how.

If it does turn out to be malware on the registers, that kind of thing isn’t new. There have been write-ups over the past year on memory-scraping POS malware like Dexter and vSkimmer, which read card data out of RAM as it’s swiped. What would be new is the scale.

On Thursday evening I got a text from a friend who owns a handful of retail stores: “Saw the Target thing. Should I be worried?” My honest answer was that I had no idea, and neither did he. So I spent the Friday before Christmas finding out.

The setup

My friend’s stores are typical of small retail. Each one has a couple of card terminals at the counter, a point-of-sale system, and a Windows PC in the back office that runs inventory, email and whatever else has been installed over the years. The POS system was sold, installed and supported by a local reseller. My friend’s view, which I suspect is most small business owners’ view, was that the reseller handled “the computer stuff” and the card processor handled “the card stuff”, and that was that.

So the question I wanted to answer was: if someone had malware on one of those back-office PCs, what could they see, and where could they send it?

What we found

I got remote sessions to the back-office PCs in his five stores and went through them with the usual Sysinternals suspects: Autoruns for anything starting automatically that I didn’t recognize, Process Explorer to check signatures and where things lived on disk, TCPView and netstat -abno for every open connection and listening port, and the router logs for outbound traffic wherever the router actually kept any.

Four machines were clean, or at least boring. The fifth had a process I didn’t recognize, listening on a high port and with an established connection to an IP address overseas. It ran from a folder under ProgramData with a vague name. That got my attention fast.

It took about two hours to identify. It was a remote-support agent that the POS reseller had installed so their technicians could connect when something broke. That is a legitimate thing to do. The problem was everything around it:

It was reachable from the internet, because the store’s router forwarded a port to it.
It used a default password shared across the reseller’s customers. I found the password in the reseller’s own setup guide, which was online.
The overseas connection was the agent checking in with the vendor’s relay server, which was hosted abroad. That made it look scarier than it was, but it didn’t make it any less exposed.

As far as we could tell, nobody had abused it. The access logs we could get from the reseller showed only their own technicians. But anyone who’d found that guide could have logged in to that machine, and from there they could reach the POS system on the same flat network.

The card data question

The next step was checking whether card data could reach those machines at all. On a call with the reseller and the terminal vendor, we confirmed that his terminals encrypt the card data at the reader, and that the data the POS system receives can’t be used without the processor’s keys. So even a compromised back-office PC shouldn’t have exposed card numbers, and in his stores, it appears it couldn’t have.

That’s a good result, but I want to be honest about how we got it. It was luck: the hardware he happened to buy. A store with older terminals, of which there are plenty, would have been in a completely different position.

What we changed

An inventory of remote access. Every remote-support tool in every store, who controls it and how it logs in. My friend has asked the reseller to move to unique passwords per store and to stop forwarding ports from the internet. Until that’s done, the agents stay switched off unless a technician is actively working on something.
Network segmentation. The card terminals and POS system are going onto their own network segment, separate from the back-office PC and the guest Wi-Fi, which until now had all been on one network. The new PCI DSS 3.0, published last month, makes segmentation testing an explicit requirement, so this was coming anyway.
Egress filtering. Nothing on the POS segment has any reason to talk to arbitrary IP addresses, so outbound traffic from it is now limited to the processor and the reseller. Malware that can read card data is much less useful if it has no way to send that data anywhere.
A quarterly check. Not a holiday-weekend scramble. I’ve written the checklist up so he or anyone else can run it.

Why I’m writing this up

I spend my working life on SaaS products, where we control the servers, the network and the code. This was a reminder of how different it is at the edge. My friend had done nothing wrong. He’d bought reputable equipment and paid a reseller to manage it. His security still depended on a default password in a PDF that he’d never seen and wouldn’t have understood.

If you’re the technical friend that small business owners text when something like this hits the news, this is a good week to offer them an afternoon. Most of what we found is invisible unless you go looking for it.