Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

7/21/2014
02:00 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Don't Overestimate EMV Protections, Underestimate Card Thief Sophistication

At Black Hat, an AccessData researcher will offer up a crash course in card payment tech and protections to root out security community misconceptions

Even in the wake of massive breaches and losses from credit card merchants and processors, many security practitioners today still hold a lot of misconceptions about how credit card processing systems and protection mechanisms work. Next month at Black Hat, one researcher plans to hold a crash course for security professionals that debunks some commonly held fallacies and clears up why card thieves have been so successful even as card security awareness has risen in the era of PCI.

"I'd say the biggest misconceptions in the security community [are] an overestimation of the protection that EMV provides, an underestimation of the skill of the attackers and a lack of understanding about how many systems that card data passes through when they're processed that are vulnerable to interception of data," says Lucas Zaichkowsky, enterprise defense architect for the forensics and security firm AccessData, who will lead a talk on point-of-sale (POS) architecture and security.

In particular, Zaichkowsky will dedicate a significant chunk of time in his briefing discussing EMV chips, the successor to the traditional magnetic stripes; EMV was introduced in recent years to lower the rate of card fraud.

"Everyone talks about how EMV will save the day, but the truth is that the primary purpose of EMV is just to make it so that the card cannot be cloned. When you do an EMV read of a card on a POS terminal, it will pass your card number and expiration in plain text, your name in plain text," he says, "and even the track two data is almost exactly the same as a mag stripe card, with the only difference being that three-digit CVV code in the middle of the track data."

As he explains, that's not a flaw or an exploitation, it is just how it works by design. To demonstrate this, he'll plan on doing live demos during his talk of magnetic card swipes compared to EMV card swipes and how they look on the back end.

"This is not some kind of big vulnerability that no one knows about," he says. "The proponents of EMV either don't understand it or they're some special interest group that's pushing it through because that's their job and they just kind of skirt around telling people that by the way, you should encrypt this stuff because it has the card number and expiration data in plain text."

He'll also offer up some visual charts of how the data flow works, from USB-powered card reader to POS terminal, to back-end store servers, to processing company systems and HSM modules, to card company systems and finally to banks, and all the way back through the chain again that data must flow through in order for a card to be processed for any given transaction. Through that explanation, he'll point out the weakest points in the ecosystem and sometimes even some strong points that security professionals may not be aware of. For example security pros may not know that PIN pad devices are actually extremely secure on the merchant side because that data is strongly encrypted and the keys are not stored with the merchant but instead are in a hardware security module (HSM) held by the card processor.

However, if attackers can find a way to attack that card processor's HSM, they may hold keys for all of the merchant PIN data held by the processor.

And that's often the exact tack that many sophisticated card-thieving criminals will take, illustrating one of Zaichkowsky's other big points of the briefing. A good example of how this can happen is the breach at RBS Worldpay, where attackers brute-force attacked the HSM there to gain access to PINs processed for customers.

"These criminals understand all this stuff and how these payment system components interoperate," he says. "They get how these HSMs are designed, they'll get the manuals for these components, read them, program to them and they understand point-of-sale environments very well. They're highly skilled and they know what they're doing."

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
macker490
50%
50%
macker490,
User Rank: Ninja
7/23/2014 | 7:44:02 AM
correcting the point of sale terminal and system
Fixing the Point of Sale Terminal (POST)

THINK: when you use your card: you are NOT authorizing ONE transaction: you are giving the merchant INDEFINITE UNRESTRICTED access to your account.

if the merchant is hacked the card numbers are then sold on the black market. hackers then prepare bogus cards -- with real customer numbers -- and then send "mules" out to purchase high value items -- that can be resold

it's a rough way to scam cash and the "mules" are most likely to get caught -- not the hackers who compromised the merchants' systems .


The POST will need to be re-designed to accept customer "Smart Cards"

The Customer Smart Card will need an on-board processor, -- with PGP

When the customer presents the card it DOES NOT send the customer's card number to the POST.  Instead, the POST will submit an INVOICE to the customer's card.  On customer approval the customer's card will encrypt the invoice together with authorization for payment to the PCI ( Payment Card Industry Card Service Center ) for processing and forward the cipher text to the POST

Neither the POST nor the merchant's computer can read the authorizing message because it is PGP encrypted for the PCI service.  Therefore the merchant's POST must forward the authorizing message cipher text to the PCI service center.

On approval the PCI Service Center will return an approval note to the POST and an EFT from the customer's account to the merchant's account.

The POST will then print the PAID invoice.  The customer picks up the merchandise and the transaction is complete.

The merchant never knows who the customer was: the merchant never has ANY of the customer's PII data.

Cards are NOT updated.  They are DISPOSABLE and are replaced at least once a year -- when the PGP signatures are set to expire.  Note that PGP signatures can also be REVOKED if the card is lost.

Transactions are Serialized using a Transaction Number ( like a check number ) plus date and time of origination.    This to prevent re-use of transactions.   A transaction authorizes one payment only not a cash flow.

~~~
catvalencia
50%
50%
catvalencia,
User Rank: Apprentice
7/25/2014 | 2:05:52 AM
Re: correcting the point of sale terminal and system
Now that debit card and credit card spending is growing; the door is open for more fraud and consumers are warned to be careful with what locations they use to withdraw money and pay for items. To protect you from ATM skimming is to watch bank accounts vigilantly. Federal law limits liability for fraud on a debit-card to $50, but only if the lost card or theft is reported within two days of the problem. If you don't report it in time, unauthorized charges could be your responsibility.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...