Signature Systems Inc., the point-of-sale vendor blamed for a credit and debit card breach involving some 216 Jimmy John’s sandwich shop locations, now says the breach also may have jeopardized customer card numbers at nearly 100 other independent restaurants across the country that use its products.
Earlier this week, Champaign, Ill.-based Jimmy John’s confirmed suspicions first raised by this author on July 31, 2014: That hackers had installed card-stealing malware on cash registers at some of its store locations. Jimmy John’s said the intrusion — which lasted from June 16, 2014 to Sept. 5, 2014 — occurred when hackers compromised the username and password needed to remotely administer point-of-sale systems at 216 stores.
Those point-of-sale systems were produced by Newtown, Pa., based payment vendor Signature Systems. In a statement issued in the last 24 hours, Signature Systems released more information about the break-in, as well as a list of nearly 100 other stores — mostly small mom-and-pop eateries and pizza shops — that were compromised in the same attack.
“We have determined that an unauthorized person gained access to a user name and password that Signature Systems used to remotely access POS systems,” the company wrote. “The unauthorized person used that access to install malware designed to capture payment card data from cards that were swiped through terminals in certain restaurants. The malware was capable of capturing the cardholder’s name, card number, expiration date, and verification code from the magnetic stripe of the card.”
Meanwhile, there are questions about whether Signature’s core product — PDQ POS — met even the most basic security requirements set forth by the PCI Security Standards Council for point-of-sale payment systems. According to the council’s records, PDQ POS was not approved for new installations after Oct. 28, 2013. As a result, any Jimmy John’s stores and other affected restaurants that installed PDQ’s product after the Oct. 28, 2013 sunset date could be facing fines and other penalties.
This snapshot from the PCI Council shows that PDQ POS was not approved for new installations after Oct. 28, 2013.
What’s more, the company that performed the security audit on PDQ — a now-defunct firm called Chief Security Officers — appears to be the only qualified security assessment firm to have had their certification authority revoked (PDF) by the PCI Security Standards Council.
In response to inquiry from KrebsOnSecurity, Jimmy John’s noted that of the 216 impacted stores, 13 were opened after October 28, 2013.
“We understood, from our point of sale technology vendor, that payment systems installed in those stores, as with all locations, were PCI compliant,” Jimmy Johns said in a statement. “We are working independently, and moving as quickly as possible, to install PCI compliant stand-alone payment terminals in those 13 stores. This is being overseen by Jimmy John’s director of information technology, who will confirm completion of this work directly with each location. As part of our broader response to the security incident, action has already been taken in those 13 stores, as well as the other impacted locations, to remove malware, and to install and assure the use of dual-factor authentication for remote access and encrypted swipe technology for store purchases. In addition, the systems used in all of our stores are scanned every day for malware.”
For its part, Signature Systems says it has been developing a new payment application that features card readers that utilize point-to-point encryption capable of blocking point-of-sale malware.
The list of 108 other shops doesn’t contain much City/State info. Have you seen a list with at least the state listed?
A lot of those restaurants are in Northern Virginia.
Just from top hits of a basic search, it looks like a lot of the shops are in and around New England – NY, NJ, PA, MD, CT, VA – and the Midwest – IL, IN, MO, WI. It’s far from accurate, especially with the generic names and the possibility that some of the stores could have franchises in multiple states. Hopefully Signature Systems will provide more information in the coming week.
Not to detract from the conversation but those states do not constitute New England (except CT, which is debatable). The proper regional term is “Mid-Atlantic”.
Just don’t want any one who doesn’t read thoroughly to get confused.
Since when is PA or NJ in New England?
Why is it debatable that Connecticut is part of New England?
Connecticut is closer to Boston, which is the de-facto capitol of New England than Northern Maine (Prasq Isle, Bangor, etc).
CT is an NYC suburb. Proximity to Boston notwithstanding, there is nothing “New England” about CT.
Why is geography nitpicking relevant to this issue at all? As part of my job I checked the locations of the listed merchants prior to Signature Systems providing them; since I already had them, I thought it might benefit the community if I supplied general areas of impact. Who knew “in and around New England” would be such a hot topic?
Anyway, now that the POS vendor has released more detailed information, my original post is no longer significant.
Here is is.
http://www.pdqpos.com/notice.html
I wasn’t able to find link to this url from their main page. This leaves with impression of a pro-forma approach to informing website visitors of existing situation.
Seems a shame that the Shellshock scare has overshadowed this. If the payment system was compromised at the provider level, then it seems likely that anyone who had it installed may be vulnerable.
If it no longer allowed for -new- installations from October 2013, then that suggests that it may have been installed as new starting in October 2012 if not earlier. Cheap payment system, spread throughout franchises and smaller shops will make it harder to correlate where a breach originated from.
Keep digging Brian!
“We understood, from our point of sale technology vendor, that payment systems installed in those stores, as with all locations, were PCI compliant,” Jimmy Johns said in a statement.
I wonder how much due diligence Jimmy John’s did. Most companies, if they want your business, will be happy to provide you with their PCI Attestation of Compliance (AOC). Regardless of whether or not you get that, if you still want to go with that vendor, you perform more due diligence to ensure that the specific thing they’re facilitating for you is handled in a PCI-compliant fashion (ex: shared data centers that handle both PCI and non-PCI data). It’s burdensome and resource-intensive to institute a due diligence program like this, but is it more burdensome to do a little legwork than it is to show up on the front page of Brian Krebs’ blog?
You don’t expect to have to perform full due diligence on every company you deal with. If you hire a “security expert”, then references and lists of customers are likely to be the standard check.
You are, after all, hiring them so you don’t NEED to know the ins and outs of security.
@Stephen H
While checking references and customer lists is great for getting comfortable with a vendor but it won’t count for PCI.
PCI prescribes the due diligence that you must do if you share credit card data with organizations or outsource functions that can affect the security of the data.
The due diligence is ongoing not just once off and involves contracts and compliance status monitoring.
The latest version of PCI enhanced and clarified this precisely because organizations were getting it wrong.
The PCI-SSC doesn’t issue fines, that is up to the payment brands.
Beat me to it, you are correct.
Non-compliant installations, a audit company’s certificate revoked, lack of due diligence… sounds like a perfect storm to me!
BTW, my government agency has taken down two web-facing customer applications due to Shellshock.
Has anyone looked at the list of non Jimmy John restaurants on the list at http://www.pdqpos.com/notice.html ???
Its just a list of names of restaurants… mom and pop eateries. No addresses, no towns or states. Do you know how many Bella Pizza’s there are?
Add that to the growing trend in restaurants today… that like to keep their patron’s credit card information ‘on file’, to speed up the process of take out phone orders?
This is appalling that no one is calling them out for more information on the exact locations of each store. Its appalling that these mom and pop shops are allowed by law to keep this information ‘on file’.
Combine these 2 things, and consumers should just go back to using cash.
Jackie, agreed about the storage of cc #s for the purpose of future charges, if that’s where the hacks were taking place. However, if you’re doing your transaction online (some delivery places, etc will store your cc#), it’s most likely safe. The problem is the POS devices in the stores themselves, not necessarily storage of the #s on the backend.
From what I see so far, online shopping is a lot safer than swiping your card through an in-store POS.
Jackie, if you are going to ask if any of us noticed something, I would suggest first reading the other comments to see if, perhaps, someone did. Namely, the very…first…comment. By me, incidentally.
I just looked at the list (actually a table) that can be found at the URL you provided and the town and state is provided for every non-Jimmy John restaurant in the table.
I called the phone number listed on the page today. I asked them to provide more information about the restaurants, at least a town and state, to help consumers, as some of the names are generic and can be in multiple towns and states. Hopefully I was not the only person to call.
Glad they included the additional information.
The link I provided is the same as the one in the article above.
“… consumers should just go back to using cash.”
I’m already doing so, but my bank’s most convenient branch rarely has $2 bills and Susan B Anthony dollar coins.
Something is not adding up here or its just missing in the story.
“We have determined that an unauthorized person gained access to a user name and password that Signature Systems used to remotely access POS systems,”
First question is:
“Great I have the username and password to these terminals but how do I access the terminals remotely?” Surely they did not allow direct access to the terminals from any IP on the internets right?
Second question:
“I will assume that what is mean’t is that Signature Systems had direct access to these company’s terminals for administration” If so then where is their two factor auth into the client’s network?
Lastly, are we to believe that these companies allowed ANY IP to connect to their systems instead of just the source IP of Signature Systems if the second assumption is correct?
If they did ACL it to Signature Systems does that mean that Signature Systems entire network was breached? Again no two factor auth into the customer’s networks for vendors/contractors.
There are some missing details here that maybe I just missed or are just not adding up.
Network? Two-factor auth? Firewalls?
One of my local pizzerias is on that list. They’ve got a couple of POS terminals (one for in-store, one for phone orders and as a backup), and their “network” is likely a 5-port switch and a cable modem. There easily could be some commercially-available remote access software on there for the POS vendor to get in without having to send a service tech out to the site.
As far as the merchant is concerned, I’m sure, they bought new POS systems to replace the older models that used dialup, and they got “the new stuff” that just “uses the internet”.
That’s why small stores go with companies that can provide the hardware and the service. There’s no way they can be expected to have the expertise to harden anything – the terminals and the systems they’re connecting to need to be designed with the assumption that they’re being used in an insecure and possibly compromised environment.
“There easily could be some commercially-available remote access software on there for the POS vendor to get in without having to send a service tech out to the site.”
Ding, Ding, Ding….We have a winner (logmein – with joke passwords changed once every five years with service tech turnover, same goes for JJ side of house). This is what happens when you promote the sandwich makers to be in charge of the IT systems. In way over their heads and not trained to be proactive, just reactive.
It looks like the PCI compliant logo that was on the home page (http://www.pdqqsr.com/) two days ago has been removed. I would look at wayback (website catalog over time from May 23, 2014) to see for yourself (http://web.archive.org/web/20140523055842/http://www.pdqqsr.com/).
And yet they still appear to claim PA-DSS compliance…
http://www.pdqqsr.com/pci.html
It just amazes me that these POS systems don’t use the strongest end to end encryption possible right after the card data is read from magnetic strip.
they may very well do that. its possibly some other hack…a buffer overflow, SQL injection, etc…that was used to gain access to the data at rest.
@Billy
Unlikely. Encryption in hardware terminals back to the bank is much safer than letting the cash register POS systems see the data. Most breaches are in the cash register or other store system.
Most hardware terminals pass the data to the register to send to the bank.
Terminals that encrypt the card data are relatively new.
Software has a surprisingly long lifespan at times (Y2K comes to mind).
Doesn’t surprise me at all. It boils down to the bottom line. Good encryption costs a lot of money to implement because it requires a highly competent programming team to code correctly. It wouldn’t even surprise me if the maintainance account used a dictionary password instead of security token keys. For years, I had to fight management at places I worked to get basic passwords used on POS systems AT ALL, including for the administrative accounts.
Why? Mostly because the store proprietors and employees we sold to were considered too dumb to handle proper security procedures. The sad thing, my bosses were largely correct in that regard as the store people often didn’t even make proper backups and would ‘lose it all’ if they had a hardware problem. That still didn’t mean I didn’t keep trying to get them to plan for security.
I’m sure the same thing applies in this case. Encryption systems require a certain amount of competence to implement and maintain. Management is probably not willing to make that kind of expenditure on the ‘off chance’ someone managed to sneak a line sniffer into the system.
Now that it has happened, I’m wondering if that will change anything. The cynic in me says “no”. I doubt they are going to rush to change their installed base’s terminals with terminals that implement end-to-end encryption even if they do implement any such changes.
The strongest encryption possible does do much to protect something that has to be decrypted at some point in order to be read. As an attacker I will just read the portion that is decrypted, in other words you always have to feel the encryption algo plain text data to encrypt at some point.
I was thinking the same thing. Would hardware encryption (right from the swipe reader) work in these cases? Or would malware still be able to get at the plain text somehow. How do ATMs achieve the end to end encryption for the keyed in PIN?
@AL ATMs use a device called an Encrypting PIN PAD or EPP. It’s hardware that goes through rigorous certification.
That would presuppose that the business were using the best devices possible. But look at business operations. The best and brightest is not here anymore. Like all capitalistic systems, IIT has been bleed off for the quick profit as nonessential. After all, they got their piece of the pie, the customer has now gone, we cannot get another dollar from them. Anything else is a waste off good profit.
Capitalism does not necisitate a return of the customer, consumerism, means you have a returning customer and treat their information accordingly. But there is nothing saying which way the company is, until they get hit. Did they protect the customer? Or themselfs .
Interesting! VERIZON does this same thing with its routers for its FIOS systems. I went onto my web account a year ago and there in my web browser was my WPA2 password! So I went and bought a second router and disabled the VERIZON WiFi completely. This is way bad.
Oh, that’s nothing.
Apparently recently a Verizon router owned by a relative had an upgrade and had its password changed (the new software doesn’t allow special characters in the WiFi password). This of course broke all the devices that were paired to the router…
(OTOH, it means that the new software no longer converts ‘&’ into ‘&&’ etc. each time it offers the change password field — which resulted in your password morphing when you visit some main page — and thus locking your devices out.)
It is interesting that the acronym for Point of Sale (POS) is the same acronym for Piece of $hit (POS) and they seem to mean the same thing too.
My, how eloquent.
Sometimes, the truth not only is hurtful, but ugly as well.
Yep – BUTT UGLY as well! >:(
Well in this case, since the attacker had or figured out the admin login for remote access no amount of malware scans will catch “valid” software that gets installed.
Unfortunately onerous in this untrusted generation but we need end to end encryption, perfect-forward secrecy, and meta-system checks for anomalous actions on systems (such as “isn’t it unusual that all this data is going someplace new lately…?” OR “Gee, how come that admin has logged in at this odd time or this many times unusually?” Hmmmm.)
But of course, my cash only payments have yet to be hacked, or stolen, or give access to my bank account, don’t generate spam, can’t give me malware, and unless you use “where’s George” can’t track my movements either 🙂
Where do you get all that cash from? I’d have to go to an ATM to get it. That’s like, out of the frying pan and into the fire.
The bank. Go inside the lobby or use their drive thru teller window. No ATM necessary. Even if you don’t do it for everything you can always try to minimize your attack surface.
That option isn’t easily available to many people who work/commute during the hours their banks are open. The ATM has become an essential part of accessing banking services.
The list of non-JJ stores at http://www.pdqpos.com/notice.html does not appear to be in any order I could discern. Did I miss something?
Also – CSO did the security review on PDQ. Their certification authority was revoked in __2011 __ per https://www.pcisecuritystandards.org/documents/QSA_and_PA-QSA_Revocation_FAQ.pdf
If the quality of their work was poor enough to get their authority revoked should their prior work have been inspected instead of being allowed to continue to 2013?
Based on research, all the POS systems being compromises have at it’s core, been Microsoft embedded systems (http://www.microsoft.com/windowsembedded/en-us/customer-stories.aspx?filter=Industry:Retail#filter=,,), with microsoft providing patchs after each compromise http://www.microsoft.com/windowsembedded/en-us/community-blog.aspx .
My concern, can the same vulnerabilities in the code lead to compromise of health systems, automobiles and ships.
Just saying…
Since it’s embed, aka system on a chip, that’s insecure, you blame MS. Or updates, leave problems blame MS? Just had to update my Linux, I use Mint. Apple just asked me did I want their new update, so maybe I should not update? The most popular system out there would be the one most attacked. Therefore the most hacked. If they didn’t update…the word of mouth would have killed them by now. But, MS should be revered by all Linux fans, and especially by all red ball fanboys, I’m old enough to remember one historical note…MS, Gates saved them by his largesse. Linux got to use dos to create itself off the assembly line. Apple was funded to stay in operation for many years, because of fears of monopoly by the owner of dos.
Those systems owe gates dad for getting IBM to sell to him for a present to his son, DOS.
“Although we know the affected locations and time frames when cards were at risk, we do not have access to transaction information that would let us know how many cards were used in those stores during the at risk times.”
Help me out here — Signature just provides the equipment, so they don’t have the transaction data. But couldn’t they GET that data, or an aggregate count, from the stores or from the credit card processor used by the stores? Seems like they should be doing more to help identify the scope of the breach.
Brian,
There is no PCI sunset date for applications that remain “acceptable for pre-existing deployment”. Basically that means it can’t be sold to a merchant who’s never used it before. It can be replaced/fixed and new stores or lanes can be added if the software was deployed before the expiry.
Just like fines the card brands would be the ones to set any sunset dates. I don’t think there are any right now for applications on the PCI list.
The list means the software can be compliant – not that it is. There is guidance that must be followed by the installers. The vendor must continue to support it in a compliant manner. And the merchant has responsibilities as well.
The company that validated the software as compliant was stripped of their license to perform PCI validations 3 years ago. We don’t know why and since some other products have been delisted in the past, I’ll assume it was not because of this product.
I assume PCI would have notified Signature about the delisting of security company. Signature should have done due diligence at that point about their future. But they may have chosen to wait until they had to revalidate.
PCI contacts software vendors before their products expire to inform them of that and remind them to get a new assessment if they continue to sell the product. Even if they missed the delisting, Signature should have realized their situation at this point. What happened is an important question.
Signature was an exhibitor at the 2014 Restaurant Association Trade Show http://nrashow.restaurant.org/NRA2014/Public/Exhibitors.aspx?Index=S
http://www.pdqqsr.com/press.html
An important question: were they continuing to market a product that they should have known they shouldn’t be?
There appears to have been merchant due diligence failures as well. Existing merchants should have been monitoring this but but were not required to change. But any new PDQPOS customers after the expiry date should never have installed an expired application.
Finally, the banks and processors accepting transactions from merchants would have had to allow existing use of the application but should have stopped any new merchants from using/installing PDQPOS after it expired.
Lot’s of if’s, should’s and questions. And all very timeline sensitive.
Chief Security Officers had their QSA status revoked in 2011, for “failing to meet the high standards required…”.
Why on earth would the PCI Security Standards Council not then ensure that any and all products, systems and services reviewed by CSO were re-validated by another QSA?
If I were Jimmy Johns I would be considering throwing a big fat sueball at the PCI Security Standards Council for their appalling failure to close the loop.
“According to the council’s records, PDQ POS was not approved for new installations after Oct. 28, 2013.”
So, with that said, why wouldn’t the Council add a date for removing those specific terminals, it seems to me
that if there is a problem sufficient enough to warrant a no install\deploy order then the Council should have issued a date for any existing devises to be removed, especially after I read the QSA & PA-QSA Revocation and the answer to “Q Why is this revocation happening?”, and Chief Security Officers “…appears to be the only qualified security assessment firm to have had their certification authority revoked…”… EVER… really! Wow, so it appears that the PCI Security Standards Council has all kinds of faith in every QSA & PA-QSA they’ve ever certified… and correct me if I’m wrong, but isn’t the Council the ONLY organization that can certify?
Applications expire because they are old and the standard changes not because they have flaws.
Applications with flaws can and have been delisted. They also end up on lists so that the processors who are on the hook for their merchants can address problems.
Imagine if you had to rebuild your house for every building code change vs. fixing the occasional item because of a serious problem.
Breaches always happen because there are failures in multiple controls.
I have yet to read one breach press release or news article where it wasn’t abundantly clear that several things broke. Usually in at least three broad ways: a way in, not getting noticed, and a way out.
There’s enough in Brian’s article suggesting there was a way in, a way not to be noticed, and a way out without needing the application to be insecure.
Was just in one of the affected JJ’s today for lunch, and noticed they had stopped using the card swipe on the POS, and were using a smaller one sitting on the counter, with a cable running off somewhere…
…and you paid with cash….. ?
I love those machines. The simplest solution is often the best! It’s a single purpose machine that can’t host malware so the card number is much safer. I’m so happy when they get my total from the register, swipe my card and type it into the stand-alone credit card machine. Correct me if I’m wrong but I don’t think those have been compromised.
A lot of those machines are integrated with the cash register (PC) and pass the card data back to the PC. (See my earlier comment).
That is because the store probably didn’t have encrypted card swipes in place, which indicates that card numbers are either being stored somewhere on the system or there is some form of malware that was one the system. My guess is the hacker used a remote login to gain access to store and installed malware.
In order to be fully PCI compliant, I believe not only does the POS vender need to pass PCI compliance testing, but the company using the POS system needs to have a PCI security and privacy policy in place also. This means the Jimmy John’s should have this document also for how stores need to handle their systems.
Can we verify this (JJ PCI store security policy)?
Am I the only one who thought it was rather suspicious that of the 104 restaurants almost all were Italian or that half were located near the Washington beltway and another 14 in NJ/NY?
Brian, how often do you order from the 14 Paisano’s listed and why aren’t the other 11 Paisano’s on the list?
Does anyone remember the 80s Pizza Connection (heroin distribution, 21 mob defendants convicted)? Hmmmmm.
Where can I find the stores list? Thanks guys
A link to the advisory listing the stores affected is included in the story
http://www.pdqpos.com/notice.html
Robert B from Sept. 26 and Paul C from Sept. 28 are onto something. This is amazing that the only thing protecting those POS systems from the Internet was a default username/password. Makes you wonder what the folks at Signature Systems were thinking.
But Jimmy Johns is not clean – they should not have blindly trusted their POS vendor. Would a restaurant blindly trust, say, an oven manufacturer? An HVAC contractor? But they trust POS vendors because it’s computers and complicated and nobody understands them anyway.
If you’re a restaurant or other business owner and you use a POS system to take credit card payments, segregate your POS systems from the rest of your network and put in some auditing at that boundary. Those POS systems should only talk to a small and well known set of IP Addresses and the auditor at the boundary can tell you if they’re trying to talk to anyone else.
Everyone hates IT words, so let’s explain it this way. Your business is a city. You put a wall around your city with a gate to protect it from the bad guys outside. Now put another wall around your crown jewels with a gate, and a sentry at that gate to alert you when somebody tries to leave with some of your crown jewels for a foreign destination.
Ok the metaphor isn’t perfect but it hopefully explains the idea.
If you’re a small business, stop using lack of tech know-how as an excuse. Take your blinders off and protect yourself!