24
Sep 14

Jimmy John’s Confirms Breach at 216 Stores

More than seven weeks after this publication broke the news of a possible credit card breach at nationwide sandwich chain Jimmy John’s, the company now confirms that a break-in at one of its payment vendors jeopardized customer credit and debit card information at 216 stores.

jjohns On July 31, KrebsOnSecurity reported that multiple banks were seeing a pattern of fraud on cards that were all recently used at Jimmy John’s locations around the country. That story noted that the company was working with authorities on an investigation, and that multiple Jimmy John’s stores contacted by this author said they ran point-of-sale systems made by Newtown, Pa.-based Signature Systems.

In a statement issued today, Champaign, Ill. based Jimmy John’s said customers’ credit and debit card data was compromised after an intruder stole login credentials from the company’s point-of-sale vendor and used these credentials to remotely access the point-of-sale systems at some corporate and franchised locations between June 16, 2014 and Sept. 5, 2014.

“Approximately 216 stores appear to have been affected by this event,” Jimmy John’s said in the statement. “Cards impacted by this event appear to be those swiped at the stores, and did not include those cards entered manually or online. The credit and debit card information at issue may include the card number and in some cases the cardholder’s name, verification code, and/or the card’s expiration date. Information entered online, such as customer address, email, and password, remains secure.”

The company has posted a listing on its Web site — jimmyjohns.com — of the restaurant locations affected by the intrusion. There are more than 1,900 franchised Jimmy John’s locations across the United States, meaning this breach impacted roughly 11 percent of all stores.

pdqThe statement from Jimmy John’s doesn’t name the point of sale vendor, but company officials confirm that the point-of-sale vendor that was compromised was indeed Signature Systems. Officials from Signature Systems could not be immediately reached for comment, and it remains unclear if other companies that use its point-of-sale solutions may have been similarly impacted.

Point-of-sale vendors remain an attractive target for cyber thieves, perhaps because so many of these vendors enable remote administration on their hardware and yet secure those systems with little more than a username and password — and often easy-to-guess credentials to boot.

Last week, KrebsOnSecurity reported that a different hacked point-of-sale provider was the driver behind a breach that impacted more than 330 Goodwill locations nationwide. That breach, which targeted payment vendor C&K Systems Inc., persisted for 18 months, and involved two other as-yet unnamed C&K customers.

Tags: , , , ,

94 comments

  1. TheOreganoRouter.onion.it

    Does this ever end? Obviously it time that credit card companies, credit unions, banks and store branded charge cards start moving to Chip and Pin (EMV) as quick as possible.

    • A couple key glossary terms

      EMV (aka Chip and Pin) – fixes cloning of cards – but only if the company accepting the card doesn’t just use the mag stripe. Which in the US is still common.

      Liability shift – this is a merchant issue. In the US it is federal laws that limit consumer liability related to fraud. However, retailers aren’t protected and next year that liability will shift.

      Point-2-P0int Encryption (P2PE) is the best option as this secures the data at the devices. Specialty companies like VeriFone and Ingenico and others provide dedicated devices readers. Combined with another technology (Tokenization) takes the retail/restaurant companies out of the credit card loop

      Tokenization – This combined with P2PE means that the retailer never sees a copy of the customer credit information. The retailer is essentially given a token that allows them to find and cancel a transaction – but they don’t know what card its associated with – they just have an id for a transaction.

      While EMV and NFC tend to take up the headlines because guests can see them. The real change is using P2PE and never actually having any customer payment information on the POS or corporate systems.

      • Correct. Additionally while EMV reduces point of sale fraud it can increase online fraud where the chip is not used to verify the transaction.

        • How can it possibly “increase” online fraud compared to the magstripe cards?

          • As POS systems get harder to hack, the card thieves currently targeting POS systems will switch to relatively easier targets, such as websites that take credit card information.

          • EMV cannot increase online card fraud. Data thieves will refocus their efforts on e-commerce as it will be more difficult to create counterfeit cards because of the random data used by the chip.

            Also note, the US will not be implementing chip-and-PIN like the rest of the world. Visa is pushing chip-and-signature for the US market. And because automated fuel dispensers (gas pumps) will not incur the liability shift in the US until 2017, it will be a long time before the unencrypted magnetic stripe goes away.

      • Bill – You hit on a lot of the points in discussion, but missed some major elements of those points.

        You wrote “EMV (aka Chip and Pin) – fixes cloning of cards”. I’d agree that it makes it harder, but not impossible. Further EMV is of limited use in other than card present transactions. To get the benefit for electronic (via computer) and mobile (from your cell phone when not at the merchant) commerce consumers need their own EMV reader. Don’t take my word for it. see http://www.smartcardalliance.org/publications-emv-faq/#q12 Which is growing faster? B&M retailing or e/m-commerce? We need to look to the future and find protections for all forms of commerce.

        You wrote “Liability shift – this is a merchant issue. In the US it is federal laws that limit consumer liability related to fraud. However, retailers aren’t protected and next year that liability will shift.” It is more than a merchant issue. See http://nc3.mobi/references/emv/ in the May 2014 section about a change in the presumption of innocence. Read about Mr. Gambin, “who was refused a refund for a series of transactions that were billed to his card and which HSBC claimed must have been made with his card and PIN at an ATM in Palma, Majorca on the 29th June 2011. In such cases we advise the fraud victim to demand the transaction logs from the bank. In many cases the banks refuse, or even delete logs during the dispute process.” Read the study at http://www.cl.cam.ac.uk/~sjm217/papers/oakland14chipandskim.pdf

        You wrote: “Point-2-P0int Encryption (P2PE) is the best option” End-to-End Encryption (E2EE) is sometimes mentioned as the last security element to make the EMV enabled process completely secure. The fallacy in that thinking is that the information from the chip enabled card and the personal identification number (PIN) are entered into a point-of-sale (POS) terminal. As demonstrated in the Target compromise those terminals can be infected with a RAM scraper and the information compromised prior to encryption. If true tokens (which are not a function of the underlying credentials) are provided by the consumer, that alone would do the job. Unfortunately some “tokens” are functions of the underlying credentials as they can be “un-tokenized” to reveal the actual information. That is properly called encryption and it can be compromised.

        You wrote: “While EMV and NFC tend to take up the headlines because guests can see them. The real change is using P2PE and never actually having any customer payment information on the POS or corporate systems.” CONCUR 100%: A true token, transmitted via the merchant, means the data does not exist to be compromised. Simply put”

        What Merchants don’t have, Crooks can’t steal.

        Bill, what you didn’t mention was the __cost__ of implementing EMV, E2EE, or NFC which lands on the merchant, but gets passed to the consumer. Target alone is looking at $100M to implement EMV. Consider a true token combined with encryption from the consumer (in all commerce modes) that uses existing transaction and communications infrastructure reducing the barriers to entry (just as the NRF about the costs!) as merchants need no additional hardware. There is at least one out there.

        • Jonathan,
          There were several things I didn’t mention.
          Some of what you have added is correct some less so.

          I will quickly respond on two points.
          The first is that no a POS isn’t required for P2PE encryption. I believe I specifically mentioned a stand alone card reader. When configured the information is never delivered to the POS. Note having one of these doesn’t mean a merchant can’t configure it for less security.

          As for costs – you have stated one side of the equation. The other side is fines for failing compliance. Mastercards published fine structure is 25K in Q1, 50K in Q2, 125K in Q3, 250K in Q4 – by which time they will prevent processing. Visa’s fines are typically monthly and most run around 25K per month. MasterCard recently published that companies who can’t identify exactly which terminal ran a transaction will face 15K per month starting in November. Any card process can choose to refuse a merchant if fines aren’t enough – most businesses are sitting between 70% and 95% of transactions via credit – imagine losing even half that percentage of your transactions as a merchant.

          The cost for the compatible reader paled in comparison. That’s aside of cost of an actual breach. Most companies that are being breached won’t survive the event.

          The calculation for the cost of an ~$800 terminal in comparison to those costs is pretty easy.

          Finally I was asked if I would provide my twitter handle. I would prefer not to publicly identify myself.

          • Bill,

            > The first is that no a POS isn’t required for P2PE encryption.
            There are many links in a card-present transaction. PCI standards (v3 and v2 at least) already require encryption for point-to-point. E2EE is the concept of encryption from one end to the other, not just between two points.

            > I believe I specifically mentioned a stand alone card reader.
            A device that has to be connected to the POS, yes? You didn’t mention a specific model or other example. How is it updated? Remotely? Then it can be hacked. Does tech come visit the machine? Expensive. How does that help in the growing venues of computer and mobile commerce?

            >The other side is fines for failing compliance.
            Yep, those are severe fines. On the other hand you can be PCI compliant and still get hacked. Here are five major examples: “Neiman Marcus noted it had met PCI standards when it said in January that customer cards may have been compromised from July to October. Target (TGT), which suffered a record-breaking hack in November, had been certified as compliant two months earlier. Grocery chain Hannaford Brothers (DEG) and payment processors WorldPay and Heartland Payment Systems (HPY) were also hacked shortly after receiving passing marks from PCI assessors,” Not my words, see
            http://www.businessweek.com/articles/2014-03-20/credit-card-data-security-standards-dont-guarantee-security and http://www.forbes.com/sites/sungardas/2014/05/01/can-your-company-be-pci-compliant-and-still-get-hacked/

            > The calculation for the cost of an ~$800 terminal in comparison to those costs is pretty easy.
            ABSOLUTELY! The question isn’t “is prevention cheaper than cure”, but will that prevention work?

            > I would prefer not to publicly identify myself.
            This alone makes you a wise man. Look at what has happened to BK over the years!

            And now for something completely different (but on a related topic) read about “JackPotting” of ATMs without ever touching the ATM. http://www.wired.com/2010/07/atms-jackpotted/

        • Jonathan,

          Just a couple of comments here:

          If a system is using E2EE, then the only place to steal the unencrypted data is before it hits the mag stripe (or potentially between the mag stripe and encryption chip, but the E2EE devices have the encryption happen between the MSR and any storage mechanism). In Target’s case, they were using software encryption, so the card data was swiped using an MSR that didn’t encrypt the data (or encrypted it just to be decrypted on the PC), then the data would be loaded into the PC’s memory where a software application would encrypt it for decryption by the processor. So the RAM scrapers were collecting all data that was loaded into memory, before it was encrypted. As you point out, this is not E2EE, but P2PE. E2EE is from the swipe to the processor, using the processor’s encryption key. This way, the merchant never has access to the card data.

          As far as tokenization goes, the PCI allows for 3 ways to generate tokens:

          1) A mathematically reversible cryptographic function, based on a known strong cryptographic
          algorithm and strong cryptographic key (with a secure mode of operation and padding
          mechanism)
          2) A one-way non-reversible cryptographic function (e.g., a hash function with strong, secret
          salt)
          3) Assignment through an index function, sequence number or a randomly generated number
          (not mathematically derived from the PAN)

          However it is derived, they also state that “the recovery of the original PAN must not be
          computationally feasible knowing only the token or a number of tokens.” (https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf)

          Also, only the card number (PAN) is tokenized. This is usually for the purpose of charging the customer again, for example on “house accounts” and “recurring payment” scenarios. The cardholder name and expiration date can be stored unencrypted, and the PAN and expiration date is usually all that is needed to get an authorization.

          One important note about tokenization: the card number must be transmitted to the processor at least once, in order to get a token back. The token just makes it so the merchant doesn’t have to store the card number. Also, for returns (complete or partial voidsale), neither card number nor token is needed, but this sometimes depends on the exact scenario. For most processors, this is accomplished by sending transaction numbers and/or authorization or reference numbers. The token may be needed if a creditsale is being performed, which is done in the event the original transaction can no longer be voided or cannot be partially voided, however this usually happens if more than 30/45/90 days have passed since the original transaction, and in that case, tokens will have often expired in that time. Unless a token is acquired for long-term use, many processors limit their validity, but their validity time is renewed if they are used again before they expire. (Sorry if I got a little technical on the integration side near the end. Also, much of this can be specific to certain processors’ policies; I’m just going by the processors that I’ve dealt with.)

          • You wrote> E2EE is from the swipe to the processor, using the processor’s encryption key. This way, the merchant never has access to the card data.

            I agree with what I think you wrote but there was a supposition in the statement about “swipe” that I’m not sure I agree. If the consumer is using a smart phone enabled process, the encryption can occur before it ever leaves the smart phone (substitute card).

            > As far as tokenization goes, the PCI allows for 3 ways to generate tokens:
            > 1) A mathematically reversible cryptographic function
            > 2) A one-way non-reversible cryptographic function (e.g., a hash function with strong, secret salt)

            These two are __not__ tokenization. A true token is random to content.
            #1 is __encryption__ based on content. #2 is __not__ tokenization as it is also based on content. “Cryptographic hash” functions make it “infeasible” to convert the “digest” to the “input” (reversible), but not impossible. See http://en.wikipedia.org/wiki/Cryptographic_hash_function (I just used that one in a patent case)

            > 3) Assignment through an index function, sequence number or a randomly generated number (not mathematically derived from the PAN)
            Not sure about “index function”, but sequence number is a really bad idea. Look at the EMV pre-play attack at http://nc3.mobi/references/emv/ under September 2012.

            Of all of the above, only the randomly generated number (or alpha numeric) is a true token. Even so, “random number generators” have had some non-randomness in them.

            > However it is derived, they also state that “the recovery of the original PAN must not be
            computationally feasible knowing only the token or a number of tokens.”
            https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf

            Emphasizing the NOT and I have to wonder why they allow function 1 for “token” generation? Especially if there is a common encryption key.

            > Also, only the card number (PAN) is tokenized. This is usually for the purpose of charging the customer again, for example on “house accounts” and “recurring payment” scenarios. The cardholder name and expiration date can be stored unencrypted, and the PAN and expiration date is usually all that is needed to get an authorization.

            Per current PCI, I agree. NC3 generalizes that some so the token (called NC3_ID) is a “consumer token” which identifies the consumer (unique in the universe), not the account number. NC3 also allows for authorized recurring transactions WITHOUT having to store the cardholder expiration date and including user valued codes for same-amount recharges (ex: consistent contract payments), amount-not-to-exceed recharges (ex: store purchases), recharge-frequency limits (ex: 1x/month), recharge-count limits (ex: 10 times only), authorization expiration dates (ex: all the other codes used and not past a date) and more.

            > One important note about tokenization: the card number must be transmitted to the processor at least once, in order to get a token back.

            Under current the current environment, but not under NC3. The true-token is transmitted from the provider (who already has it) __direct__ to the consumer. The consumer provides the true-token to the merchant, who passes it on to gateways and intermediaries to the processor until it reaches the provider (or the provider’s authorized processor). Readable within the NC3 “message” is information on how to reach the provider. This means that the card number (what we call the Underlying Charge Card Number or UCCN) is never in a smart phone. What the smart phone does not have can’t get passed to the merchant and what the merchant does not have can’t be stolen.

            As for returns – not a problem. The NC3_ID can be used to identify the customer and link back to the transaction. Even if the NC3_ID is reprovisioned (which can be done by consumers without human intervention) the date range of each NC3_ID is stored so a merchant can refer to an “old” one and a date and process a credit.

            Sorry to run on, but I’ve spent nearly three years on this.

            Jonathan

            • I definitely understand that the first 2 methods are not tokenization. However, for some reason, PCI allows “tokens” to be generated in this manner.

              As far as this true-token that you mentioned, if the consumer provides it to the merchant for processing, isn’t it just replacing a card number, becoming just as big a liability to be stolen?

              I, too, have many years of experience in the POS and electronic payments industry.

              • David – Sorry for the delay in getting the 10/2 reply posted. My understanding is KOS got slammed by miscreants and BK was kind enough to fish my reply from the spam folder along with thousands of others that land there each day (!). Apparently I include too many URLs!

                The token I designed can’t authorize a transaction. It is a true-token, random to the underlying charge card credentials. Each is unique in the universe (which isn’t as hard as it sounds). Merchants can keep the token to help them with chargebacks or other problems. Even if the token is changed by the consumer (easy for them to do) the old ones are kept at the provider and, given the old one, plus the transaction date, the consumer can be identified and the new charge (or refund) properly applied.

                The transaction authorization is a separate part of the transaction. The whole package is very short (I used a base-64 alphabet without high value ASCII, now that was difficult!) and can be presented as a low-res QR code (a trademark of Kabushiki Kaisha Denso, www dot nc3 dot mobi / references has a link to where I get permission to use the term) for easy optical transmission using existing coupon scanners in card present transactions. No new hardware for most merchants. Also can be used with NFC. For E&M-commerce and non-present commerce, the non-lossy graphic file or the underlying string of b-64 information can be transmitted. Oh yeah, it is encrypted in a special way even before the PCI transmission encryption is applied. Start with the PDF at the bottom of the home page at www dot nc3 dot mobi. It is 16 pages, but in large print, designed to be printed as a pamphlet on four pages of paper (save the trees you know).

          • DavidA – KOS under heavy DOS attack at 13k requests per minute __apparently__ from FaceBook and other reasonable sources. Been trying to post reply to you for days. URL provided at submission was
            http://krebsonsecurity.com/2014/09/jimmy-johns-confirms-breach-at-216-stores/comment-page-1/#comment-296762 Which does not yet appear. Will keep trying.

            If you mouse hover over my post name you will see a web site. The footer there shows an email address which gets routed behind the scenes to another place where it comes to met. If you choose send something and I’ll send back the reply.

            Have a good weekend.

      • (This may be a double post. The first one “evaporated”, maybe I timed out in my slow typing. My apologies – Jonathan)

        Bill –

        You wrote “EMV (aka Chip and Pin) – fixes cloning of cards”. I’d agree that it makes it harder, but not impossible. Further EMV is of limited use in other than card present transactions. To get the benefit for electronic (via computer) and mobile (from your cell phone when not at the merchant) commerce consumers need their own EMV reader. Don’t take my word for it. see http://www.smartcardalliance.org/publications-emv-faq/#q12 Which is growing faster? B&M retail or e/m-commerce. We need to look to the future.

        You wrote “Liability shift – this is a merchant issue. In the US it is federal laws that limit consumer liability related to fraud. However, retailers aren’t protected and next year that liability will shift.” It is not only a merchant issue. See http://nc3.mobi/references/emv/ in the May 2014 section. Read about Mr Gambin, “who was refused a refund for a series of transactions that were billed to his card and which HSBC claimed must have been made with his card and PIN at an ATM in Palma, Majorca on the 29th June 2011. In such cases we advise the fraud victim to demand the transaction logs from the bank. In many cases the banks refuse, or even delete logs during the dispute process.” Read the study at
        http://www.cl.cam.ac.uk/~sjm217/papers/oakland14chipandskim.pdf

        You wrote: “Point-2-P0int Encryption (P2PE) is the best option” End-to-End Encryption (E2EE) is sometimes mentioned as the last security element to make the EMV enabled process completely secure. The fallacy in that thinking is that the information from the chip enabled card and the personal identification number (PIN) are entered into a point-of-sale (POS) terminal. As demonstrated in the Target compromise those terminals can be infected with a RAM scraper and the information compromised prior to encryption. True tokens (which are not a function of the underlying credentials) alone would do the job. Unfortunately some “tokens” are functions of the underlying credentials as they can be “un-tokenized” to reveal the actual information. That is encryption and that can get compromised.

        You wrote: “While EMV and NFC tend to take up the headlines because guests can see them. The real change is using P2PE and never actually having any customer payment information on the POS or corporate systems.” CONCUR 100%: A true token, transmitted via the merchant, means the data does not exist to be compromised.

        What Merchants don’t have, Crooks can’t steal.

        Bill, what you didn’t mention was the cost of implementing EMV, E2EE, or NFC which lands on the merchant, but gets passed to the consumer. Target alone is looking at $100M to implement EMV. Consider a true token combined with encryption __from the consumer__ (and in all commerce modes) that uses existing transaction and communications infrastructure reducing the barriers to entry (just as the NRF about the costs!) as merchants need no additional hardware. There is at least one system out there.

        • Since other readers here may not know – I’d like to announce to KOS readers that Jonathan E. Jaffe is quite a source of expert information on the subject.

          Not bragging on you Jon, just the facts!

          • Thanks for the accolade, but “expert” is a bit strong. “Better than average” suits me fine.

            Now if Ajaypal Singh Banga (CEO MasterCard) learns there is a more secure and less expensive way, that would make him a hero: to billions of consumers, millions of merchants, the National Retail Federation, and perhaps more importantly, his shareholders. Then we (consumers, merchants, providers, and state and federal governments who $pend on crime-fighting after-the-fact instead of on crime prevention) might finally see light at the end of this very dark tunnel.

            Sorry for the rant and thanks again.

            • Well you certainly seem to know what your talking about more than many commenters on KOS – also a lot of us fellow commenters(or comment-tards as detractors might say) have a lot of respect for your knowledge.

              • Thanks for the comment. I’ve been working on a “solution” for a few years now and seen lots of ways to do it wrong. BK was also kind enough to tell me why some of my comments wound up in the site spam filter which gets (are you ready?) almost 10k messages … EACH DAY. KOS also got slammed by miscreants which is why the comment got submitted on 9/27 but didn’t go public until just recently. BK was kind enough to retrieve them.

                10/9 and 10/10 – DQ and K-Mart. Is nothing sacred?

                Be well.

      • BillS, excellent information. Do you have a twitter feed we could follow?

    • Unfortunately Chip and Pin will not be required here in the US like it is in Europe. The US will only be requiring chip and signature.

  2. I think Subway, then Barnes and Noble were among the first to experience these types of attacks in 2011-12. I know Subway has since returned to using the POS but I remember B&N saying that the would only use the card readers on the register, although if you can hack the POS vendor it doesn’t matter where you slide the card.

    So Brian, in your opinion, where do you see this style of attack going and what type of impact will it\should it have on PCI and even VISA Master Card as they are at the top of this PCI food chain?

  3. Their sandwich delivery may be freakishly fast but their incident response is horribly slow (and ineffective)

  4. Where’s the list of stores on their site? I don’t see it, and I don’t believe you included a link.

    • Thanks. When I published this story, they hadn’t yet updated the site. Jimmy John’s sent me the statement in advance as a courtesy for the heads up on July 31.

      • If all the card numbers were taken from swiping the cards, the hackers would not have the CVV. It is not in any of the tracks. It is only written on the back, and is only used (should only be used) for card not present (e.g. web)

        So the story is incomplete. Storing the CVV is against PCI rules

        • @Bart –not entirely true. PVV and CVV data can be stored within the “discretionary data” portions of both Track 1 and Track 2 card data.

          • The CVV2 is the data that is never stored on the mag stripe and only on the back of the card. CVV can be stored on the mag stripe.

  5. This is crazy. Hackers are making so much money now, maybe I should let them have my credit and bank accounts. They’re sure to have more $$ than me, and maybe better credit, too.

    Update on Home Depot “major media” coverage: AOL Huffpost had the leering headline, “Hack Is Draining Money From People’s Bank Accounts.” No real or new info, a so-called story with a whopping 148 words (including the Reuters tag). The mainstream print press used to complain about online news; now I think that mainstream online so-called news is reaching the end of its usefulness in reporting anything except major scoops on 3-headed calves.

    Thank goodness for KOS, but I’ve had people tell me I didn’t know what I was talking about when I passed on Krebs’ stories, until they troubled to read for themselves, got hit in a reported hack or scam, or read on AOL Huff and others, weeks after the fact. Thanks again, Brian! I’m sticking with you…

  6. Any word of these cards showing up on Rescator, et al? Nice work, as usual!

  7. Perhaps they need to move back to dial-up connections.

  8. Every time Mr. Krebs puts another breach story up, someone asks “How many more?” or “How much longer will this kind of thing happen?”…

    I think the answer is all of them… all the stores… all retail major and minor. Anywhere a credit card is used. The world is one big juicy oyster for these guys.

    • +100. Couldn’t agree more.

      • I’ll add that in some cases I expect to see multiple breaches from the same stores and vendors. The reason? Too often, the response does not appear to address the root cause. In Home Depot’s case, they implemented “security enhancements” including “enhanced encryption of payment data”. Has anyone addressed the total life-cycle of said payment data? What about the data in memory? The root cause to me has to do with compliance based vs. risk based security strategy. PCI-DSS compliance won’t fix the problem. Holistic and adaptive security will help make a company less juicy of a target.

        • @Andrew

          Either PCI or Risk based can do the job. Both are hard to do with the current state of technologies that are out there and what needs to be protected. It’s all about how these get implemented. It depends on the business leaders and the management. Some organizations do it well and others make the news.

          The often asked question “What is the real risk here?” is often the lead it to an exercise in denial and creative writing used to avoid securing things. No one likes expensive repairs or tearing out and replacing things. And lots of organizations think things are too fragile as is and that it shouldn’t be their problem.

          Better technologies are coming along but they are barely here and not ubiquitous. The reality is that this is currently a long game being played out.

          Card beaches are getting attention because they are both monetized and measured. The problem is really much larger than cards and retail.

          • Indeed, at my last employer we sat down and wrote the security policy and got everyone to sign off on it. The two important bits were no direct access to sensitive information from the internet, and everyone has to go through a tightly-secured VPN concentrator to access the internal networks (some of which – conditionally – could access the networks with no direct internet access).

            What’s the first thing my supervisor gutted? Direct access to sensitive information from the internet – in violation of policy. Other supervisors quickly gutted other parts of the system, like the VPN concentrator (it was “too complicated”).

            Thankfully I got laid off as they spiraled down the drain, but before the inevitable data breaches. According to office scuttlebutt, apparently I was to blame for the breaches – because getting on the list of people being laid off, because I repeatedly pointed out they were breaking policy, and therefore were breaking contract, wasn’t enough.

      • Yep. That’s how it looks to me too, with many more to come. Fuck me *sideways!*

    • The Human Defense

      Andrew,
      I completely agree with you and I personally have been impacted by the Home Depot and PF Changs breaches. But I wonder how the attackers are identifying some of these vulns. Just wondering if there is another intrusion that occurred in the Jimmy John case where the attackers sniffed around to determine the stores they would target. Why only hit the self check out locations at Home Depot? Must have had some intel. I don’t think the entire naked truth is coming out of these press releases. Information is knowledge and knowledge = disruption of the attackers future plans.

      • > I don’t think the entire naked truth is
        > coming out of these press releases.
        I’d really doubt that anywhere near the truth, the whole truth and nothing but the truth is being revealed. All too frequently the first public statement from an effected entity is AFTER KOS breaks the news. What comes out seems to be as little as possible. This is as much human embarrassment as it is business politics. How many laws had to be passed to require disclosure? Without them we’d all be easier pickings than we are now.

        Ordered data is information
        Knowledge is digested information
        Power comes from knowledge.

        Not sure where that chain got broken but Albertson’s (Kroger, Osco etc) appears to have been compromised twice in two months.

        GAK
        @NC3mobi

  9. I had fraudulent charges on my credit card twice in six months, including one after the card was re-issued. In both incidents the cards were used at a nearby gas station, then the individual drove up one major road/highway or another, stopping at big box retailers along the way making purchases until the credit limit was reached. I assume they were buying gift cards.

    The common thread to both incidents was a previous purchase with Jimmy Johns. ONLINE purchases with Jimmy Johns. Since this second reissue (which, let me tell you, they were none too happy about – the day of the fraud I had paid off the card, so the criminal got a large haul) I haven’t placed any CC orders with Jimmy Johns and the card hasn’t had any fraudulent charges.

  10. @TheOreganoRouter.onion.it

    Chip and PIN is certainly better from a technical security standpoint, but I do wonder about some of the consequences. What I mean is if Chip-and-PIN shifts fraud liability to the consumer, is it actually in the best interest of the consumer? Nothing is hacker proof forever, so how can the consumer have confidence if they are going to be stuck with the liability?

    • You will always be protected by Reg E and evenVisa. Consumer liability is a non-issue as long as you notify your FI in a timely manner.

      That being said, fraud is everyone’s loss in the end.

      • Holly, you wrote: “You will always be protected by Reg E and evenVisa. Consumer liability is a non-issue as long as you notify your FI in a timely manner. ” I spent 9 years as a bank director (before the collapse!) and I’d agree about the protections … TODAY.

        Take a look under the May 2014 section of http://nc3.mobi/references/emv/ on what is happening in Europe under EMV. That page has lots of links, but here is the relevant text.

        Change in Presumption of Innocence
        An article in The Register (whose slogan is Biting the hand that feeds IT) is rather critical of chip-and-pin citing established weaknesses and some new ones referred to in the new paper Chip and Skim: cloning EMV cards with the pre-play attack from the Computer Laboratory, University of Cambridge, UK (16 page PDF) presented at the 2014 IEEE Symposium on Security and Privacy in San Jose, California 5/19/2014.

        In this paper paper it is worth looking at the change in what we call presumption of innocence as it describes the case of a Mr Gambin, “who was refused a refund for a series of transactions that were billed to his card and which HSBC [ his bank ] claimed must have been made with his card and PIN at an ATM in Palma, Majorca on the 29th June 2011. In such cases we advise the fraud victim to demand the transaction logs from the bank. In many cases the banks refuse, or even delete logs during the dispute process, leaving customers to argue about generalities.” [ The bank deleted the evidence that would have shown the fraud. highlighting ours, see right column page one of the 16 page PDF -ed]

        Axiom: Prevention is cheaper than cure.

        • Have you ever seen MagnePrint or Passwindow, and if so, do you think it is a cheaper viable alternative to Chip-N-Pin. I am thoroughly disgusted with chip-n-pin, and I think I have quoted you here on KOS before trying to advocate against it, because IMO of the hugh expense – and I see it as another too-big-to-fail technology that is now obsolete.

          • Sorry for delay in replying.

            MagnePrint is an enhanced magnetic strip which can improve card-present transaction security, but does zippo for E&M commerce. It also (might, I’m not sure) introduces a fourth party as the reference source. If true, that makes for a more complex environment. Not being helpful in the growing commerce venues and a 4th party, are not good things.

            Passwindow is a modern application of a very old cypher mechanism called the Cardan Grille (Wikipedia has a good article). Unfortunately it appears to require transactional internet to generate challenge images which means it has no application in non-present transactions such as making purchases from a magazine ad without transactional internet or person-to-person transactions.

            If the images are generated from a local system of the merchant, that system has to know the right answer which means that local system knows what pattern is on the consumer’s Grille which kinda defeats the concept. As we’ve seen the merchant systems, even large banks, are vulnerable. The whole process is also time consuming which means for high-value, low-frequency applications it might be acceptable. In line at StarBucks? Fer-Gedda-Boud-It!

            Confidential consumer credentials (like the consumer’s Grille pattern) need to be transmitted via the merchant, but not understandable by the merchant. What Merchant’s Don’t Have, Crooks Can’t Steal.

            Again, my apologies for the delay.

            • Thanks – now I know they aren’t a true replacement – I’m thinking about the complexity and multi-channel vendor comments. If I’m ever in a discussion with them again, I’ll ask the original developers to defend these arguments. Many of us didn’t have the whole picture to bring to the table.

              I won’t quote you unless I get permission.

      • Anyone know the definition of “timely manner”?

        This weekend I Discover’ed that my credit card was billed twice for the same Hotels.com stay (once by hotels.com, once by the hotel) — with hotels.com charging me the full amount, even though I had assigned a guest rewards credit to it.

        Discover seems to be quite willing to let me challenge it a bit late, but I personally do *not* check my accounts regularly, because my act of *checking* my account would be more activity than my accounts typically get, and would thus increase the likelihood of someone intercepting the information needed to do stuff to my account.

        • Timeless – timely manner is specifically defined in the agreement you signed. The can differ from provider to provider. It is generally 30 days or so from the event, and/or some number of days from the statement date.

          Reviewing the statement is your responsibility. It sounds like you get e-statements. If you get them via email you are right to be concerned. If you have to go to the web site and the connection is https you are better protected. Certainly not perfectly protected. see http://www.zdnet dot com/has-the-nsa-broken-ssl-tls-aes-7000020312/

          How do you get your bill so you know how much to pay? Isn’t that part of the statement? So, if you pay your bills then you already have the statement, right?

  11. I want to make sure I understand the timeline here:
    – KOS reports a suspected breach on 7/31
    – At that time Jimmy Johns indicated they were working with authorities on an investigation
    – The use of the compromised credentials was allowed to continue until 9/5?

    Not impressed by the incident response.

    Thank you to Mr. Krebs for the timely reporting! You’re a very busy man these days!

    • Looks like they were mopping them up as they found a problem and/or could get in touch with the right owners in conjunction with technical staff.

      Look at the date end ranges. Some were cleaned up as soon as Store #0257 on July 15, 2014 (probably the POS was replaced due to glitching or some other reason). Most were mopped up in early August. I see only one store that was fixed in Sept, Store #0496 on Sept 5, 2014.

      https://www.jimmyjohns.com/datasecurityincident/storedates.html

      • Yeah, that seems like the right explanation.

        What amuses me more is that this data is apparently maintained by hand, note the presence of a ‘0’ in the second of these two entries (but not the first):

        STORE 0660 Tucson , AZ 5411 E Broadway Blvd. — 6/16/2014 – 8/8/2014
        STORE 9034 Tempe , AZ 681 E. Apache Ste. 102 — 6/16/2014 – 8/03/2014

  12. To those working for CC processors….wake up!

    The miscreants have figured out that you’re the weakest link and you’ve become the most lucrative target EVER!!

    Time to quit waiting for something to break and take a good hard look at your code, security and business practices.

    Of course, the subsequent lawsuits I’m sure will serve as your wakeup call. (Got your deniability team in place?)

  13. Are there any Americans left who haven’t had their credit/debit/personal details stolen? It’s really seems to be getting to that level.

    As an aside – I needed to update my office – new computers, phones, backup hard drives etc and went to my bank to get the money in cash as I needed to shop at a few places to get everything I needed. The teller refused to give me the entire amount being asked for as she stated I would clean the bank out of available cash…. just have to love fractional reserve lending!

    I had to go back the next day to get the rest of the money. But I do feel better spending cash instead of using my business credit card at so many different locations and having to deal with any fallout if the card is pilfered. Still easier to deal with the bank than dealing with a stolen credit card. Makes accounting a bit more of a pain for the accountant but that’s her problem! 😉

    • Cash can be stolen, lost, counterfeited. With a credit card you are not liable for the charges you didn’t make. You do have to deal with waiting for a new card – but at least you can get a new one. With cash if it’s gone or fake, you’re out of luck.

      In most cases (point of sale transactions) they only get your card number and pin. Nothing personally identifying you.

      Of course an online retailer breach may leak more information about you depending on level of the compromise.

  14. I work in the PCI Compliance industry, and not a day goes by that I see a merchant failing a vulnerability scan due to cleartext logins, usually associated with admin logins or DVR systems. The industry could do a better job educating their merchants as well.

  15. I’m guessing 2-factor authentication wasn’t implemented to access the stuff from the Internet.

  16. It’s quite obvious now that every retailer or card processor is or will be facing this. I’m certain that the hackers and criminals are going all out to get as much as they can before the changeover to chip & signature systems that the industry is pushing towards.

  17. The fact is that if Mastercard and VISA were the ones taking the actual losses there would have been changes long ago.

  18. Unless I am missing something, the article above shows us a way to use our current credit cards with less risk. According to Brian, Jimmy John’s said in the statement, “Cards impacted by this event appear to be those swiped at the stores, and did not include those cards entered manually or online.” In other words, people who for whatever reason had the clerk write their cc number and expiration date on the charge slip weren’t impacted. So…. Don’t let anyone swipe your cards anymore. Demand they write by hand the info they need. Yes that will slow things down and yes that will be more laborious but which is easier on YOU, the CUSTOMER? Taking 2 minutes to process a sale instead of 20 seconds or going through the hassle of card replacement and risk of identity theft? Certainly merchants and cardholders alike would find this procedure to be cumbersome, but it would short-circuit the kind of breaches we’ve been seeing. Thieves would be reduced to hacking into the servers of the CC companies themselves, not just the POS devices of retailers.

    • The “manual entry” method means that the card info is entered into the POS device by hand, no info needs be written down.

      • @DfJo
        I was going to let your comment go unanswered because whether the info is hand written and later entered on a POS device or actually entered at the time of the sale is irrelevant. However, since at least one reader was influenced by you, I guess I have to respond after all.

        My point was that when the CC # and expiration date are all the info gleaned from the customer, that is insufficient data with which to clone a card. Ergo, as the article stated, “Cards impacted by this event… did not include those cards entered manually or online.”

    • Maybe by demagnetizing your card’s magstripe, so the clerk has to manully enter the info into the POS.

    • I, the CUSTOMER find that a new cc magically showing up in my mailbox once in a blue moon is much easier than waiting an extra 2 minutes for each of the 10 people ahead of me in line, for every transaction.

      • @Jeff
        “I, the CUSTOMER find that a new cc magically showing up in my mailbox once in a blue moon is much easier than waiting an extra 2 minutes for each of the 10 people ahead of me in line, for every transaction.”

        Perhaps, but you haven’t factored in the considerable pain and expense of identity theft. The credit card data stolen in these breaches is an excellent starting point for this crime. Furthermore…

        Since credit companies view the new Chip n Pin technology as virtually fraud-proof, they are transferring the responsibility for fraudulent purchases from the merchants to the cardholders. I agree that waiting 20 minutes would be a pain, still, even if each CC theft resulted in only one $300 charge, that works out to $900/hr, pretty good compensation for just standing in line.

        • DianeT you are comparing the “pain” of compromise to the “pain” of waiting in line. You are correct, being compromised is more painful, but the comparison is specious (deceptive).

          The ExpectedValue of an event is the probability of its occurrence times the value of the event. EV=p(e) x v(e). In this case “value” is “pain”

          The probability of waiting in line is 100% (you are waiting in line) and, for discussion, the value of the pain is 2 so the expected value of pain from that event is 100% x 2 = 2.

          The probability be having your identity theft is more painful. Let us say it is just 4. To be equal the probability of your identity stolen (it is a “maybe” event) would have to be 50% (50% x 4 = 2). Is it? Is your identity stolen every other time you make a purchase? I think not. At a 1% probability (which still seems high to me) that makes the expected value of identity theft (1% x 4 = .04) which is a lot less than the pain of waiting in line.

          Perhaps the real question is how to prevent “pain of identity theft” without causing more pain in the form of “pain in waiting”.

          I think there are several ways that won’t take even half a minute at checkout.

    • Diane,
      You are wrong on two counts. For starters CC companies don’t support merchants writing down CC numbers at any time. In fact in a dispute – having a full copy of the CC number as opposed to only the last 4 digits means the merchant loses the dispute.

      Secondly as one person points out – in that scenario you still have your CC number entered – it’s just done manually. At the most secure establishments you’ll need to use the number keypad on the CC capture device since the POS doesn’t handle CC numbers – and by the way the cashier in those locations can’t enter it for you.

      • @Bill
        You stated that I am “wrong on two counts.”
        1) “CC companies don’t support merchants writing down CC numbers at any time,” and
        2) “in that scenario you still have your CC number entered – it’s just done manually.”

        1) Clearly you don’t do much shopping. While it is true that some large scale MERCHANTS forbid their employees taking down a customer’s CC number (or entering it manually on a POS device), that has nothing to do with whether or not the CC company will accept a manually collected number. In truth, all online purchases are “manually” entered if “manually” is defined as “not entered as the result of a CC being swiped.” Whenever a merchant is unable to access a CC company’s phone number, or if their POS device malfunctions, they do NOT tell all the customers in the store, “Sorry, only cash or checks today. If you want to use a CC, I’m not going to sell you that $1500 flat screen you want to buy.”

        2) You imply that I think taking a CC number manually somehow magically stops that number from being transmitted to the CC company. I made no such declaration. What I suggested was that manually entering a CC number and ID would fail to transmit all the OTHER data that is on the mag strip. If all the crooks got were a list of CC numbers and exp dates, the only data that would be captured at the POS if the CCs were entered manually, they couldn’t manufacture a working clone of the customer’s CC.

  19. As others have pointed out, each time there is an improvement in the technology of the cards, the thieves upgrade their level of sophistication too. I have a different idea. Instead of relying on more and more sophisticated cards to outwit more and more sophisticated crooks, why not rely on the ability of the clerk making the sale to identify the customer?

    A clerk needs to know only two things. 1) The card being presented belongs to the customer presenting it and 2) the customer is also the person authorized by the CC company to use that card. What better way for the clerk to know that the customer owns the card than that the card contains a clear, digital image of its owner, a picture not unlike that on a driver’s license? The POS device could scan the CC and project its owner’s picture onto a screen for the clerk to compare to the customer’s face. Simultaneously, that digital image and the card number are sent to the CC company, the image compared to the one on record and if it matches, the purchase is authorized.

    Yes this would require new POS devices and new cards but that seems to be in the future of retail sellers anyway. Once in place, with cards inextricably linked to the face of the person who owns them, the cost to implement the fraud would be prohibitive. Hacking the CC servers that contained customer images wouldn’t be any more difficult than today and yes the thieves could then replicate the cards and sell them by the thousands. But how could you use those cards if you had to look like the person whose picture is stored in the card?

    • That would be costly. Big box retailers may look at it, but you kill convenience or small dollar retailers. Plus how many $7.50 clerks have you seen that will even look? Biometrics would be the way to go – take it out of the clerks hands. Then you only have to worry about bad guys using a dead digit for a few days. Current VISA rules don’t even allow asking for photo ID anyway so I can’t see them embracing this. And any purchases made with a cloned card are not eligible for charge back rights by the financial institution nor is the card reissue if you want to stay in business. Sorry to share the burden of the cost of these breaches, but as it was pointed out, even the giant companies have trouble with the cost of a breach.

      • @tami
        Those $7.50/hr clerks don’t “even look” because that is how they are instructed to process CC transactions. If they were required to verify that a customer was the same one as shown on some sort of photo identification, that is what they would do. Do it imperfectly? Yeah, probably. But here’s were you and I diverge.

        You think, “Biometrics would be the way to go – take it out of the clerks hands.” My thought is that as soon as we have a purely electronic transmission of biometrics, the crooks will figure out a way to get around that. That’s how it’s been up till now. Crooks figure out how to hack a card’s info – CC company comes up with a new something to block that hack – crooks figure out a way around the new something.

        The one thing the crooks cannot “hack” are the cognitive skills of the sales clerk. Clerks can be bribed, can be stupid, can be careless, but there is no software foreseeable in the next 100 years that will be able to cause a clerk to think that the person standing in front of her/him is the person whose image is embedded in the CC’s mag strip when it clearly is not.

        One company that actually implements a primitive version of this concept is CostCo. Every membership card has a picture of the member embedded in the card’s plastic. Over time, this image can be degraded to the point of being worthless. When that happens, the cash register clerks are EXPECTED to require the member to show a photo ID that is clear, for instance one’s driver’s license.

        As for the small retailers, if they couldn’t afford the new POS devices, they could revert to entering the CC # and exp date “manually.” Not as effective a safeguard against a person using someone else’s card but quite effective at preventing the cloning of CCs, not to mention that this info alone is insufficient to be used for identity theft.

        • DianeT wrote: “My thought is that as soon as we have a purely electronic transmission of biometrics, the crooks will figure out a way to get around that.”

          Already been done, several times. Any biometric requires the submitted to be compared to a reference exemplar. The comparison process can be hacked three ways (depending on where the exemplar is located). The submitted has been hacked too.

          That is “Fingerprint Spoofing” and was demonstrated back in 2007, again in 10/2013 and 4/2014. See http://nc3.mobi/references/biometrics/ under “Fingerprint Spoofing” section which has many links.

          There is a new section on how the Constitutional protections you have in refusing to divulge a combination, but may not have in refusing a fingerprint. Something to consider if there is something in your phone you don’t want exposed.

    • Diane,
      A picture on the back of the card is nice and convenient for the consumer, but otherwise mostly worthless. Yes merchants will ask for id – but this is why people talk about leaving the mag stripe behind.

      A sophisticated criminal has CC blanks on which they emboss all the data and layer in their own photo.

      A less sophisticated criminal has a card with their photo and some random set of embossed numbers and they just reprogram the mag stripe to a stolen number.

      • @BillS
        I apologize for not stating my suggestion more clearly. “A picture on the back of the card is nice and convenient for the consumer, but otherwise mostly worthless.” I was not suggesting that a picture be ON the BACK of a card. My suggestion was that a picture be DIGITALLY recorded in the mag strip of the card.

        • Unfortunately, a merchant should not trust *ANY* information on a card.

          If the magstripe is a magstripe, then the evil actor presenting it could encode their own picture into that stripe. If it’s a chip, then the evil actor presenting it could encode their own picture in that chip.

          OTOH, the idea of customers authenticating merchants would be interesting.

          One of the PayPal payment systems (the check-in one) sort of works this way.

          Unfortunately, most customers aren’t in a position to configure a whitelist of acceptable payees. And when customers do have the ability to do it, we see a different kind of fraud (fake employees) — Brian, we haven’t seen a Payee mule article in a few months… should we expect another one soon? :)

          • @timeless
            “If the magstripe is a magstripe, then the evil actor presenting it could encode their own picture into that stripe.”

            In my original post above I stated, “The POS device could scan the CC and project its owner’s picture onto a screen for the clerk to compare to the customer’s face. Simultaneously, that digital image and the card number are sent to the CC company, the image compared to the one on record and if it matches, the purchase is authorized.”

            If the picture embedded in the mag strip didn’t match the one on file with the CC company, the purchase would be rejected Another benefit, ie, money-saving aspect of this is that there would be no need to send out replacement cards since the counterfeits would be unusable at POS devices. Only the real owner’s card being used by the real owner would be accepted.

            Admittedly this procedure, without refinements, would not be adequate to combat ATM fraud since there’d be no clerk to verify that the face of the person withdrawing the cash was also the person whose image was stored on the CC. However, by simply adding to ATMs a camera capable of scanning the face of the person trying to withdraw cash and transmitting that image along with the other verifying info normally transmitted by the ATM, whenever there was an incomplete match between the face of the person trying to get cash and the image on file with the CC company, the transaction would be rejected and depending on how good the technology, the card could be immediately confiscated by the ATM machine.

  20. It is our own government (America, local, state, federal) that are behind some of this tomfoolery. Otherwise, my suggestion is the death penalty and/or nuking the SOBs that are perpetrating these hacks/scams.

    Why should we recognize the rights of these scumbags when they don’t recognize the rights of those they rip off.

    Death to them all!

  21. Here is a report that a video camera captured pictures of credit card fraud criminals using the target exit camera.
    $11,600 for gift cards.
    And they will likely be caught.
    Why not just put cameras at each POS terminal?
    Seems that would reduce incentive.

    http://finance.yahoo.com/news/medical-record-worth-more-hackers-182251412.html

    • Gordon, the camera record is well used to catch the crook after the crime. That serves as a deterrent, but it has to be enforced and (it appears) that providers don’t pursue. Maybe the cost of enforcement is more than the value of the crime?

      From my personal experience (3 electronic compromises and 1 time my physical card was taken from my wallet) only the physical compromise was prosecuted as theft and the thief went to jail.

      We have cameras at intersections and people still run red lights. Yes, they get tickets, but they still run red lights.

      Crime prevention is better than prosecution. IMHO it is cheaper too.

  22. It’s worth noting: JJ has indicated on its FAQ that customer names were also compromised. This means state laws should kick in and allow state AG’s to actually prosecute. I hope and pray at least one state follows thru and takes JJ or the POS vendor to court.

  23. If you ordered online, will this still apply if your store is on the list?

  24. It looks like signature systems PCI compliant payment system certification expired about 1 year ago. Not good.

    Verify here. Look for signature systems, inc.

    https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true

  25. So what is the recommended course of action if we think our card may have been one of those stolen? I have gone several times to one of the Jimmy John’s listed on their website, although I am not exactly sure if it was within the time window specified, but let’s assume it was.

    Do I call my bank and request a new card or just keep an extra close eye on my account and only report and request a new card if I see an unauthorized transaction?

    • Call your bank and get a new card is a must. Also, you need to review you bank records. If you find an unauthorized transaction then you will need to see your bank about filing a charge back. Most banks have some small paperwork to fill out for this and the money is replaced within 1-3 days.

  26. Are these far too regular compromises primarily due to vendor negligence or a flaw in the POS system itself?

    What steps should be taken to prevent or greatly reduce the problem?

  27. E. Coli and card theft available in one place, awesome!