Forced Authorization Attacks Against Chip-and-Pin Credit Card Terminals

Clever:

The way forced authorisation fraud works is that the retailer sets up the terminal for a transaction by inserting the customer’s card and entering the amount, then hands the terminal over to the customer so they can type in the PIN. But the criminal has used a stolen or counterfeit card, and due to the high value of the transaction the terminal performs a “referral”—asking the retailer to call the bank to perform additional checks such as the customer answering a security question. If the security checks pass, the bank will give the retailer an authorisation code to enter into the terminal.

The problem is that when the terminal asks for these security checks, it’s still in the hands of the criminal, and it’s the criminal that follows the steps that the retailer should have. Since there’s no phone conversation with the bank, the criminal doesn’t know the correct authorisation code. But what surprises retailers is that the criminal can type in anything at this stage and the transaction will go through. The criminal might also be able to bypass other security features, for example they could override the checking of the PIN by following the steps the retailer would if the customer has forgotten the PIN.

By the time the terminal is passed back to the retailer, it looks like the transaction was completed successfully. The receipt will differ only very subtly from that of a normal transaction, if at all. The criminal walks off with the goods and it’s only at the end of the day that the authorisation code is checked by the bank. By that time, the criminal is long gone. Because some of the security checks the bank asked for weren’t completed, the retailer doesn’t get the money.

Tags: , , , , ,

Posted on December 7, 2015 at 5:35 AM • 29 Comments

Comments

Paul Renault • December 7, 2015 6:25 AM

Grrr…. The faulty protocol and design is the banks’ fault. They are (supposed to be) the experts and they are supposed to be training the merchants. Why doesn’t the protocol, for example, include asking for the merchant number, something the thief shouldn’t know.
The banks should be taking the hit on this one.

bickerdyke • December 7, 2015 6:32 AM

“The root cause of the problem is having a single device for both security-critical steps”

Sorry, but NO.

If the terminal asks for a security code to confirm an external security check but then accepts any number instead, THAT is the root cause. That is not only the opposite of security, but outright stupid. By design.

CallMeLateForSupper • December 7, 2015 7:08 AM

“Clever” understates it a bit; I would say “delicious”. Think about what is being attacked here – supposedly high-security credential – and what the attacker gains – high-value merch. Lovely.

Evan • December 7, 2015 7:55 AM

There is such obvious potential for fraud here – an authorization code that isn’t checked for authorization?!? – I struggle to believe it isn’t an intentional misfeature. It’s not only trivial to ensure the authorization code is correct, it’s the logical, intuitive thing for the system to do. How hard would it have been to bribe the committee members that designed the thing?

Clive Robinson • December 7, 2015 8:39 AM

Part of the problem is that two different entities are involved with the security.

EVM came up with Chip-n-Spin, but the card issuing banks have their own security considerations and other issues layered into this.

One well known problem is “fall back” issues. In the early days of cards transactions happened without any real time communication, you might still see the old paper slips and manual card impression taking machine. This was open to all sorts of fraud so electronic methods started to come in for larger retailers. However communications were not that reliable and clearing houses offered better rates for batches of transactions not individual transactions, so real time verification was still not in the equation.

To cut out a lot of boring bits –such as SET– what you need to understand is that the merchant, banks and EVM want the transaction to go through, not just because they make money but they don’t want to make the customers think the system is not reliable…

Thus historicaly the systems were not designed for real time verification and to please the customer…

As any con artist knows from hotel crook upwards when people are aiming to please you then those people can be exploited if you have enough front.

Will proper realtime security ever be a built in feature of cards? I don’t think so untill the pain from the occasional bite becomes unbearable, as history has shown so far. Worse history also shows it won’t be “built in” but “layered on” due to the costs involved.

As long as things are layered on, underlying cracks will be at best wall papered over. Which means a little push in the right place will bring the cracks right through with no trouble. You can be sure that when money is involved the crooks are going to find where to push.

Oh and as for “the aim to please” there is another player in the game we seldom consider, and that is “the insurer of last resort” AKA the Surveillance State or Government. At the very least like Ceaser they want to have rendered unto them what they think is due, such as taxes. Therefore they want people for many reasons to stop using untracable cash. They have two routes open the “very expensive to government” make cash tracable –RFID in notes etc– or the “virtually no cost to Government” push people to other payment systems such as cheque or plastic.

The likes of EVM and the issuing banks are not stupid, thus it wont be long before they will put the bite on your local Government one way or another… Thus they may well work out a way by which they profit from card fraud…

Steven Murdoch • December 7, 2015 9:36 AM

@wut

It’s related but not the same. With the scam in the Apple store, the criminal social engineers the shop assistant (with the help of an accomplice on the phone) to bypass the usual authorisation process. It works even when the criminal doesn’t get access to the terminal, but relies on the shop assistant falling for the scam.

With the scam this article talks about, the shop assistant doesn’t have to get tricked into doing anything, because the criminal is holding the terminal, and so can complete the referral process without actually doing the security checks. The fraud opportunity has been created by Chip and PIN because now the terminal is handed to the customer at a critical stage of the transaction.

Bing • December 7, 2015 10:13 AM

If on-line validation of the authorization code is hard, the other solution is to force the system to engage the shop clerk. Rather than silently calling for an authorization code which is blindly accepted, the hand unit should signal that clerk intervention is required; blink lights, beep beepers, flash the screen on the till, any number of ideas come to mind. Even after the fact (entering the bogus auth code), the receipt could clearly show the special authorization (e.g., three rows of asterisks, whatever). One of our local shops has the customer initial the receipt when getting cash back from a debit card transaction and the clerk is responsible to get that. In a similar way, the clerk could be required to place their initials on the receipt when the receipt is flagged to show that the clerk obtained the authorization. This exposes the clerk, and encourages compliance.

Short version: solutions are not that hard to find.

Anura • December 7, 2015 12:14 PM

@Nat

That’s great for people who always have savings and wouldn’t be forced to wait for their next paycheck to be able to go to the grocery store, while having no interest in building their credit.

pos_flogger • December 7, 2015 12:14 PM

There’s a chance this is a point-of-sale software design flaw. There’s a chance it’s an unworkable situation while remaining emv/pci compliant. There’s a chance it’s very complicated programming that never got done.

The retailer should probably decline approving the transaction on such an authorization request. But, that’s an executive decision, not a programmer’s decision.

We get into the deep end of EMV-PCI/POS programming very quickly. Can the POS cache the transaction while it is being sorted out by humans? Does the security request violate the transaction processing period? What about the resend/retry period? Is there POS logic, arguably very interactive to handle it?

It becomes a corner case in business terms. Except when a bad person figures out the vulnerability.

rgaff • December 7, 2015 12:57 PM

@Clive Robinson

All excellent points, except for: “Government… wants people for many reasons to stop using untraceable cash”

What makes anyone believe that cash is untraceable? Think about it. Here’s the travel route that 99% of cash takes:

  1. person withdraws cash from an ATM, in the form of crisp $20 bills.
  2. person spends new crisp $20 bills at a given retailer, gets a tiny amount of change back.
  3. retailer deposits those very same crisp $20 bills back into the bank.

It’s only the tiny amount of change that gets “mixed” at all and thus is slightly harder to trace… the majority of it is easily traced by the banks themselves. All they have to do is record the serial numbers as it’s dispensed and received, and submit them along with associated metadata to a central authority.

What kind of metadata can be traced this way? Well, not likely individual products and transactions… just what retailer every individual has visited, and generally exactly what day the transactions took place, what category of goods that retailer sells, and exactly where it is located… In summary: your exact location, date, and general category of goods you buy CAN be traced through big data even with cash! It is not with 100% accuracy, but with extremely high accuracy in most cases.

Douglas Knight • December 7, 2015 1:27 PM

rgaff, even if it were true that the government were tracing that 99%, it probably cares more about the 1%. Eliminating the 99% makes the 1% more visible.

trsm.mckay • December 7, 2015 1:44 PM

@Clive

Good point about impact of EMV’s offline features. I think of them as something akin to weak protocol negotiations in TLS. Even when you think you have gotten rid of them, clever attackers figure out to leverage the vestigial functionality and assumptions.

Question, what era of communication reliability are you talking about? I am more familiar with the US’s timeline (where everything was pretty much online by the early 90’s). I do recall as late as 2000, hearing that offline transactions were still the norm in Europe.

SoWhatDidYouExpect • December 7, 2015 2:49 PM

Due to processing costs (from card providers & banks), debit cards and credit card purchases are batched in groups that are typically run overnight. Immediate feedback is generally not available to the merchant (unless they pay more for it). With that in mind, the ACTUAL authorization is typically hours after the card is used, whereby the card issuers then hit the merchant with the problem. Eventually, the real cardholder gets hit as wsll by having to fight with card issuers/banks about who is responsible.

Oh, but for responsible card users, there is a (costly) way out…go to an ATM, insert your chip&pin card, enter that card’s pin number, withdraw cash, and spend that. However that type of cash withdrawal is considered a cash advance, or immediate interest bearing loan, at a VERY HIGH interest rate.

Damned if you do and damned if you don’t.

Jacob • December 7, 2015 3:32 PM

On the lighter side of the CC verification business, Brian Krebs reports the following:

“I recently heard from a source in law enforcement who had a peculiar problem. The source investigates cybercrime, and he was reaching out for advice after trying but failing to conduct undercover buys of stolen credit cards from a well-known underground card market. Turns out, the cybercrime bazaar’s own security system triggered a “pig alert” and brazenly flagged the fed’s transactions as an undercover purchase placed by a law enforcement officer.”

k14 • December 7, 2015 4:38 PM

How can I tell if my chip-and-pin card is the legitimate one I was supposed to have received, in a manner that will neither expose it to criminals nor expose me to being mistaken for one?

LessThanObvious • December 7, 2015 4:56 PM

@bickerdyke

They pretty much deserve what they get with the level careless stupidity. Good thing this isn’t anything important like a financial transaction,…oh wait.

Clive Robinson • December 7, 2015 6:50 PM

@ trsm.mckay,

Question, what era of communication reliability are you talking about?

Oh last century 🙂

Let me think SET was done dusted and consigned to the dumpster in the late 1990’s, and one of my last involvments with payment systems involved going through it’s thousand odd turgid pages of ASN.1 looking for and finding potential vulnerabilities. Even though we new SET was doomed due to the fact it would upset customers greatly, it still had to be shown to be of less use than a one legged race horse.

That was prior to the UK’s BT “Phone2000” plan of going fully VoIP in it’s exchanges and trunks.

A little while prior to that I’d come up with a system to authenticate online transactions. The UK banks were moving badly into OnLine banking over the Internet and were terminating the old 0800 dial in systems for customers.

But most small retailers were still using the manual impression machines and paper transaction slips in the mid 90’s. Part of the problem was finding a private network supplier who could meet the requirments at a price the clearing houses would accept. Previous attempts at “dial-up” had proved problematic for many reasons, not least the connect time was adding 30s to a minute to a transaction which customers did not want to put up with, and line noise caused other problems. Thus they stuck with batch processing for quite a while.

As for other parts of Europe credit cards often earnt the sign of the cross from retailers, and much US tourist money was lost in Western Europe. I was in Germany when the wall came down and back then credit cards were held by maybe 1-2% of the population, who mainly traveled on business. I was tasked with integrating EPoS devices from IBM with Hotel checkin and hospitality systems and the whole thing was a compleate dogs dinner. The joke of it was the hotel central computer systems worked better than the CC system which appeared hamstrung by EPoS managment deciding to use their prefered communications supplier for each hotel in a chain rather than let the hotel use their centralised system.

But as you moved eastwards CC’s were unknown at all but airports and top of the line Hotels. In a way these countries were lucky, because they leapfrogged over from barely working manual phone systems to ISDN etc digital exchanges, and thus missed five or ten years of pain, and later still some went almost directly to mobile missing out crossbar and other equipment still in use in the West of Europe that was EoLing.

My memories of those times are not happy ones and occasional wake me during the night even to this day with dreams of strangling certain managers from back then. One such had worked in the fasion industry and naturaly assumed that engineers were “creative types” that responded well to being screamed and abused… Needless to say they resigned on mass after first removing all drawings, CCTs and source code, being brought in to clear that mess up was no great bundle of laughs.

Chris S • December 7, 2015 9:12 PM

@Clive – “the connect time was adding 30s to a minute to a transaction”

On that tangent – one of the possible mistakes to make when designing a terminal is thinking that a faster modem is a better choice. That would only be true for extremely large data volumes.

Any CC authorization will be small enough that a 1200bps modem is a far better choice. They are cheaper, connection setup is much faster, but still fast enough that a even a kilobyte of transfer will only take seven seconds. That should be lots of data for even a chip card check.

Much like the mistake at the top of this posting, designers need to think through the whole system, not just their little piece. And management needs to make that possible, not block it.

Clive Robinson • December 8, 2015 4:42 AM

@ Chris S,

Yup, you’ve got one asspect of the problem. But also poor line quality effects highspeed modems more than low speed modems, so often the errors would cause the data rate to be actually slower than 1200baud as well.

But as one embitered engineer was heard to comment at a meeting “Don’t let practical issues get in the way of nice new shiny toys”.

He had a point, and it was interesting to note how managment ignored the evidence including the much worse ROI on the shiny toys at the recomendation of marketing…

Gianluca • December 8, 2015 6:41 AM

Well, actually the protocol works fine from the bank’s point of view because it protects its real customers (i.e. the real owner of the bank’s credit card). The payment would not be made and the money would not be transferred to the merchant’s account.

The main flaw is that the protocol protects only the banks’ customers, not the merchants. Said that, postponing the check of the authorization code is perfectly fine.

The merchant will receive a slightly different receipt, he/she will not notice the authorization error and he/she will give the goods to the theft!

My question is? Why the bank needs to postpone the check? Why it’s so expensive to check an authorization code such that the bank is forced to do it late at night in bulk?

bickerdyke • December 8, 2015 8:44 AM

OK. That all of this is build on systems optimized for offline processing explains a lot. But it shifts things to just another angle of the same stupid: For some exceptional reason (card unreadable, unusual high amount, merchant thinks customer looks like a crook) online verification is requested.

But instead on online verification, we get a pretended mock-online-verification.

indescendent • December 8, 2015 9:08 AM

This is a flaw in the terminal programming… Terminal software that complies with (for example) the ZVT protocol (http://www.zvt-kassenschnittstelle.de/wp-content/uploads/PA00P015_13.06_en1.pdf – see commands) for communicating between the cash register and the terminal will fail (with an error message like “CALL BANK”) when a telephonic authorization is needed, and the authorization needs to be restarted with the referral code. This command also requires the cashier password to start, so if no cash register is connected (i.e. authorizations are started via the terminal menu) the attacker would need knowledge of the password to exploit this vulnerability.

Not saying that this affects all terminals, just that it doesn’t affect all of them.

rgaff • December 8, 2015 11:01 AM

@Douglas Knight

Of course the government wants 100% of everything… no matter what treaties or laws or constitutions or rights need to be broken to get it, like a kind of infantile dictator.

But claiming that something that’s 99% TRACEABLE is “untraceable” is kind of… well…

John • December 9, 2015 8:23 AM

So why not change the POS system to prompt for some merchant “passcode” that is locally verified and changable. This would make it so that the merchant has to enter a code they know to verify that they have control again.

You could possibly even set multiple codes to provide one to each cashier. That way you could disable one if an employee quits or gets fired. It would also trace the activity back to a specific employee if there is fraud for this type of transaction (employee working with criminal or lack in keeping their own code secure).

Because it is locally stored it would be a quick real time verificiation, but would have to be strongly hashed for security. Businesses should require changing passcodes every 90 days or so as well.

Elliot • December 12, 2015 5:16 PM

-Gianluca: The recent legislation change in the banks’ favor (that liability for fraudulent charges rests with the merchant, not the bank, with the chip and pin system) means that the banks don’t have to care in this instance. I don’t understand postponing the check, either.

In the case of hand-held terminals (the portables used by delivery drivers etc), I’d think that the request for further check screen would be visible to the merchant, who walks the customer through the process.. perhaps different to the process at a store with a fixed-down terminal. A good question to ask the terminal providers.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.