Kimpton Hotels, a boutique hotel brand that includes 62 properties across the United States, said today it is investigating reports of a credit card breach at multiple locations.
On July 22, KrebsOnSecurity reached out to San Francisco-based Kimpton after hearing from three different sources in the financial industry about a pattern of card fraud that suggested a card breach at close to two-dozen Kimpton hotels across the country.
Today, Kimpton responded by issuing and posting the following statement:
“Kimpton Hotels & Restaurants takes the protection of payment card data very seriously. Kimpton was recently made aware of a report of unauthorized charges occurring on cards that were previously used legitimately at Kimpton properties. As soon as we learned of this, we immediately launched an investigation and engaged a leading security firm to provide us with support.”
“We are committed to swiftly resolving this matter. In the meantime, and in line with best practice, we recommend that individuals closely monitor their payment card account statements. If there are unauthorized charges, individuals should immediately notify their bank. Payment card network rules generally state that cardholders are not responsible for such charges.”
Assuming a breach at Kimpton is confirmed, the company would join a long list of hotel brands that have acknowledged card breaches over the last year after prompting by KrebsOnSecurity, including Trump Hotels (twice), Hilton, Mandarin Oriental, and White Lodging (twice). Breaches also have hit hospitality chains Starwood Hotels and Hyatt.
In many of those incidents, thieves had planted malicious software on the point-of-sale devices at restaurants and bars inside of the hotel chains. However, the source and extent of the apparent breach at Kimpton properties is still unknown.
Point-of-sale based malware has driven most of the credit card breaches over the past two years, including intrusions at Target and Home Depot, as well as breaches at a slew of point-of-sale vendors. The malware usually is installed via hacked remote administration tools. Once the attackers have their malware loaded onto the point-of-sale devices, they can remotely capture data from each card swiped at that cash register.
Thieves can then sell the data to crooks who specialize in encoding the stolen data onto any card with a magnetic stripe, and using the cards to buy gift cards and high-priced goods from big-box stores like Target and Best Buy.
Readers should remember that they’re not liable for fraudulent charges on their credit or debit cards, but they still have to report the unauthorized transactions. There is no substitute for keeping a close eye on your card statements. Also, consider using credit cards instead of debit cards; having your checking account emptied of cash while your bank sorts out the situation can be a hassle and lead to secondary problems (bounced checks, for instance).
Brian, is there any point of commonality among the breached hotel chains? I don’t mean ownership, but more like a common billing system, payment networks, terminal types?
In general, it would be interesting for breach reports to not only name the business but the kind of software and devices they are using, and whether or not they offer chip or NFC payment options.
My guess is that if (more) customers get hip to the businessness that are still on swipe tech, and the businesses are aware of it, and fear a decrease in business due to wary customers, fires will be lit under some lethargic or stingy c-suite types to open the CAPEX chequebook to upgrade their systems.
I’ve actually been tracking who has EMV/contactless for a while now at https://emvacceptedhere.com/. Anyone can add to the map and request corrections to the data; anything that Krebs readers and others can contribute will definitely be appreciated. 🙂
As long as it’s only banks losing revenue because of this, the only c-suite that cares are those of the banks. Until others have to start absorbing the cost of all this fraud, the c-suite won’t care — until it affects their profitability… same with consumers – the public in general doesn’t worry about it because their bank eats the cost of these security breaches. My bank fees won’t change if one of my credit cards is compromised in a breach. After the Home Depot breach, I went to my bank to get a new ATM card and the bank employee was so flippant about the breach – “Oh if you ever lose money if someone steals your debit card you can just come in and fill out an affidavit and we’ll return the money.” It’ was just “a cost of doing business” for them. This was at a JP Morgan Chase bank. I think banks should be allowed to sue the merchants with poor security measures in place.
JW: In the end consumers, like you and me, pay all the bills. Call it a crook-tax and I’d like to stop paying it.
I don’t know, Robert. Other than what I mentioned in the article, which is these POS terminals tend to be set up so that they can be access remotely. That’s not a POS brand issue, it’s an industry-wide problem
Just finished reading Kingpin by Kevin Poulsen. Sounds like the majority of Max’s carding sources started with remote control software breaches, either through exploits or poor password choices.
Not sure why these payment support companies don’t use a centralized management system, such that only connections from that location are allowed.
I still am perplexed at the amount of places that don’t take EVM. All my cards have a chip now, but I’d say 50% of the places I still frequent require a swipe and many now have a label taped over the chip spot at the bottom saying they require a swipe.
I thought the liability was supposed to move to whomever had the lowest form of security? That is, if a card company has EVM chips and a payment location doesn’t take it, a hack has to be eaten by the payment location. Conversely, if a payment location takes EVM but a card is swipe-only, then the card company eats the fraud. You’d think this would be driving the change, but perhaps it has been delayed (again)?
*EMV
In our Missouri-based retail store, our payment processor only began processing EMV chip transactions in the past 2 weeks or so. We’ve had the hardware in place for over a year, and finally a software update came out that supported it. And our processor actually replaced the terminal hardware; the supposedly EMV-capable device we had bought from them earlier wasn’t going to work out for some reason. Now it’s finally working. And our credit card receipts have this new AID number on them. I wondered what that was, looked it up, and found this:
https://www.level2kernel.com/flow-chart.html
https://www.level2kernel.com/emv-glossary.html
NOW I can better understand what was taking so long to get set up for EMV.
I think a lot of the places that do take EMV are the ones that tend to sell high-dollar easily pawnable stuff. They are the ones that would tend to be hit the hardest by the liability shift.
Then you have the other places where the purchases tend to be small, and they wouldn’t be of as much interest to fraudsters. Examples might be a pizza shop or a dog grooming business. They have little incentive to upgrade unless they change banks or the old equipment breaks. And yet these are the types of places where malware can get installed to collect the credit card numbers.
I suppose the only good news is that as time goes on, it will be harder and harder for the crooks to monetize stolen credit card numbers, but the criminal elements have proven to be very clever and resourceful.
I’ve asked about this very thing before.
For those looking for some extra reading.
http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-pos-system-breaches.pdf
Brian,
Even with a chip on the card is the card number exposed to malware on a POS terminal?
yes if they ask you to swipe it, as most merchants still are — whether or not your card has a chip or the merchant has a chip reader.
Account information is definitely provided when you perform an EMV transaction.
Depending on the EMV system, there might be E2E encryption, in which case it’s possible the malware won’t have access to the unencrypted account ID (maybe).
But! While the account ID is `necessary` to make a cloned credit card, it isn’t complete (`sufficient`).
When you swipe a card, it includes:
[Name]
[Account ID][Expiry]
[CVV1]
When you make a credit card purchase by phone/on the internet, you provide:
[Name]
[Account ID][Expiry]
[CVV2]
When you make an EMV transaction, your card provides:
[Name]
[Account ID][Expiry]
[Signature using AC card key]
CVV1, CVV2, and the AC card key are distinct things.
So, you can’t reproduce a Magstripe (CVV1) for in-person purchases based on a hacked web store (CVV2). Nor can you make a Magstripe based on the Signed information from the EMV transaction.
We utilize this service,and if your open to come aboard with Anovia We would be happy to have you.I know what it feels like when you have money in the account ,but cannot access it becomes your Bank is sending a new card in the mail.
Have I missed something? When will someone begin naming the POS vendors whose systems are being hacked?
Easy answer… Oracle/Micros…
Guess you missed these:
http://krebsonsecurity.com/2016/06/slicing-into-a-point-of-sale-botnet/
http://krebsonsecurity.com/2015/05/harbortouch-is-latest-pos-vendor-breach/
http://krebsonsecurity.com/2015/03/point-of-sale-vendor-nextep-probes-breach/
http://krebsonsecurity.com/2014/09/breach-at-goodwill-vendor-lasted-18-months/
http://krebsonsecurity.com/2015/06/breach-at-winery-card-processor-missing-link/
Those are just the ones I found with 30 seconds of searching this site.
Add Omni Hotels to the 2016 breach list.
It’s important to understand that EMV doesn’t solve payment card breaches. EMV verifies that the card being used n site is valid (not counterfeit) and if it’s a PIN-preferring EMV card (most aren’t), it validates that the person presenting the card is the owner. EMV does not, however, protect data once in-transit. In many cases, EMV terminals transmit clear-text card data to the payment processors which is vulnerable to skimmers, RAM scrapers, etc., These stolen card numbers (EMV or not) are then used online to purchase goods where EMV is a non-issue.
What merchants need to protect against data breaches is a combination of EMV, card encryption (most important) and card tokens (so clear card data isn’t stored on the system for re-occuring transactions).
So, the takeaway is that EMV likely would not have done anything to prevent this or many other breaches. EMV protects the cardholder from card counterfeiters and was designed prior to the rise of ecommerce which has essentially wiped the value proposition of protecting against counterfeited cards at brick and mortar locations.
A stolen card number (PAN) should should by itself not make it possible to internet transaction, at least not in Europe. Here you will have to enter the CVC2, the 3 digits on the rear of the card, as part of the transaction. This number is neither a part of the magstripe nor a part of the EMV data from the chip.
Also, as i understand it, an EMV card has a bit of code in it that gives that has to match a “transaction number” or the amount of times the EMV card has been used, so for someone to counterfeit and EMV card (and use it as such), they’d also have to know how many times the valid customer has used the card. You can encode the info onto a blank chip card, or regular mag card and take advantage of “fall back” transactions (when someone swipes a chip card after a chip attempt), but that will be going away soon after all cards and terminals are upgraded.
Technically, the transaction number doesn’t need to be quite sequential.
You can perform offline transactions and non-purchase transactions.
An interesting read. My take? The read basically says, this is how it is done, not, this is what we have seen, it says this to stop it. Accomplished, it says nothing about system maintance, or re checking the system, after the power outage, of the latest OS update, or the system after the window washer puts in his USB. You found it, you fixed it, end of story. But it’s not.
Initially a short background. I Live in Denmark and have been working with terminals for more than 10 years. We rolled out the first EMV terminal in 2002 and chip read transaction makes more than 98% of the transactions here nowadays. It took however many years before we got the shops and customers converted from magstripe to chip.
An EMV transaction is a lot more complicated than a magstripe transaction but EMV terminal can be fast, very fast. A typical timing is 7 seconds from inserting the card and until the terminal displays ‘Remove card’. This includes the PIN entry.
The terminal will, while reading the card read either the PAN and expiry date or a ‘Track 2 equivalent data’. The latter deviates however from the actual magstripe on the card. You cannot make a swipe transaction based on these data, at least not if the issuer of the card makes some decent checks of the data before approving. You are able to get the PAN and expiry date from the card if you are able to access the plain text data inside the terminal.
Then we are back to the problem with all the Windows based ECR’s. New vulnerabilities are found all the time, and it is an eternal hunt to keep them patched. The way we have tried to handle this problem in Europe is by only submitting the masked PAN to the ECR. The PIN pad and the card reader are Tamper Resistant Secure Modules (TRSM’s). Data are encrypted before they leave the TRSM’s. They are encrypted in the TRSM not in the PC. This seams to limit the fraud.
The software in the (secure part of) terminal is remotely updated, but “don’t call me – i’ll call you!”. You cannot perform remote log in to the ‘terminal’. You must manually request the terminal to log in to the Terminal Service Provider. This can as well be done automatically, but it is always the terminal that connect to the maintenance center.
Do terminals do a decent job of authenticating their Terminal Service Providers and preventing tampering of the data stream from them? Otherwise it seems like a MITM would be easy to implement…
The major fraud area today is the card not present (CNP) area, and it is growing. The figures from the UK are publicly availble on; https://fraudfacts16.financialfraudaction.org.uk/. 70 % of the total losses are now related to CNP transactions. EMV will not make any difference here. Most card schemes here in Europe are starting to require two-way authentication, i.e an SMS is sent to your mobile phone and you have to enter that value on the screen.
Trump got hit by this latest sweep … HAH! But seriously, this is why I pay cash unless the cost upfront is exceptionally high, like in this case. Scary!
As anybody reading on Brian’s comment section knows, I live in Europe (rest of family in USA) and I’m a big fan and user of Apple Pay.
Given all the interesting technical discussion above, it seems to me that tokenized solutions like AP are the most secure of all regardless of terminal security.
It really seems to me that an AP transaction running over any comprimised terminal yields data that is useless for both recoded cards at a POS terminal, and online card not present xactions (because “card” number is unique to each Apple device and is combined with an auto generated 1 time PIN – so reuse is impossible.)
Or am I missing some subtle weakness that is leading to overconfidence in my part?
1. The biggest problem (described by someone earlier) is getting the Payment systems to switch to accepting EMV — it requires certification, which is a slow and painful process almost entirely outside the control of the merchant.
2. Apple Pay when I last checked had a huge risk in that the enrollment process relied on banks not being braindead. And the banks were braindead. — Effectively, w/ minimal (easily collectable) information, someone could activate an Apple Pay account against your bank account. — If you hadn’t set up an Apple Pay account. They could then make secure charges against your account (until you notice and complain).
There’s nothing wrong w/ Apple Pay (or Google Wallet), but:
1. Merchants need to be able to get their EMV+tap terminals enabled / certified — which is a bottleneck well beyond their control.
2. Banks have to not be stupid — This is beyond our control.
(If you read the history of EMV deployment, you’ll see that banks made all sorts of stupid mistakes in their initial EMV deployments, especially not validating the cryptogram, or allowing EMV transactions for cards for which they had not yet issued EMV cards….)
Spam post from Colly Jonathan – advertising a hacker service, no less. Brian, can you remove?
Some thoughts on charge cards and fraud
Fraudsters are very clever and can earn a handsome income.
EMV chips do nothing about CNP (card not present) transactions, for example web site purchases or telephone purchases or recurring/monthly purchases.
Some smaller banks/credit unions have gotten EMV transactions even though they had not issued any EMV cards (yet) …
It is fairly easy to hijack a cell phone number, so large charges should not rely on SMS as two factor authentication.
It is very very very easy to steal a PIN, however some fraud transactions that are PIN based have the financial liability shifted to the card holder.
It is important that the liability be placed on those that have the power to control / change / fix the system. Otherwise, the incentives do not line up properly.