- Hello to everyone.
Is a real pleasure to be part of DefCon 29.
My name is Salvador Mendoza
and I'm a Security Researcher at Metabase Q.
And I'm proudly member of
Ocelot Offensive Security Team.
Today, I'm going to talk about the Pinata attack,
or PIN Automatic Try Attack,
regarding EMV technology.
So let's start with the agenda for today.
We're going to have an introduction to terminology.
Also we're going to talk about the EMV transaction flow,
which basically is how the card data goes
from the terminal
to the bank institutions,
and how it's processed.
After that we're going to talk about
the inadequate implementation regarding this attack.
How someone could exploit it.
Finally we're going to have a demo
implementing a internal tool, named Elma.
And after that,
we're going to have some conclusions regarding
this research.
Let's analyze some terminology that we're going to use
throughout this presentation.
Some of them are going to be very important
for the demos, for example,
or to understand a little bit more in depth, how,
how the issue, how the bad practices are implemented.
So let's start with a secure element, or SE,
which is basically a responsible to sign the transaction,
but to keep the secrets in the card, on the physical card,
to sign the transactions, when is processing it.
There's CVM, is the cardholder verification method,
which could be different, right?
It could be that you verify the transaction by signing it,
or it could be by PIN entry mode.
Also, we have the APDU, application protocol data unit,
is a protocol in charge to communicate
or to conduct the communication between the card
and the terminal.
Also, we have the ICC, or integrated circuit card.
We know these cards, as well as smart cards, for example,
but we're going to talk specifically
to the EMV transactions.
That's to be clear.
The PRC is the PIN retry counter.
One of the most important terms that we're going to use
during this presentation
and also the ARC or ARPC, authorization response code,
how the bank institution responds back to the transaction
into a terminal.
The EMV contact payment is one of the most common,
un-secure technology that we implement
and use every day to make transactions.
Because it implements a secure element.
The secure element is in charge to sign the transactions
or to sign the challenge
that terminal is sending to the card.
Basically a contact payment.
It's when we insert the card into a terminal,
and we'll leave it there until the transaction finish.
Sometimes the user will require to insert,
or to enter the PIN, for the transaction.
Sometimes it will require to sign a paper
to verify the transaction.
When the card is in inserted into a terminal
is going to be detected
and after that is going to be reset.
Is going to be the list applications,
and is going to be different the steps until
the transaction is complete.
During these steps.
One of the most important is if the transaction
is going to be processed online
or is going to be processed offline mode.
It will depend on different factors.
And of course,
is going to depend on the verification method.
If we take a look into different details
regarding the terminal on card communication,
we can see in the protocol phases, how,
how this transaction goes through.
For example, we have the card authentication,
we have the cardholder verification method,
and also we have the transaction authorization.
It is going to be the last phase,
after the verification in the transaction.
When the terminal starts sending commands to the card,
the card must answer back for that specific command.
But for example,
let's say if the terminal sends a command
that is not properly right,
the card will answer back that that command wasn't right.
So the terminal is going to prepare a new command
and send it back to the card.
So basically, it's when you're typing something
to a terminal and every command you're getting
a response back, it's the same thing with a terminal
and the card.
It's like a, sending a command and getting a response back
very quickly.
One of the most important parts and this protocol phase
is the cardholder modification method
that we're going to implement for the Pinata attack.
Many people think that the communication between the card
and the terminal is encrypted, but is not, sadly is not.
And they use the ISO 7816,
which basically, many other technologies use it as well.
Such as NFC, for example.
NFC implements the application APDU layer
to communicate with a terminal, as well.
And also the same technology
that we use for our cell phones.
This chip that you put in cell phone,
it communicates implementing the same APDU layer
with a cellular phone.
So it's not encrypted the communication,
but you need to follows a format and we're going to analyze
what is the format? What is the APDU command format?
And also what is the APDU answer format?
So how they know how to answer back
and which format is going to be.
And take a look into the different details of parameters
inside of this, of this APDU protocol.
So let's analyze one of the most important parts
in the APDU protocol,
which are the commands and the responses.
So basically let's start with the APDU command,
which is literally different from the card response.
We have a header,
and we have a body.
And the body we have the length of the command.
And also we have the data from the commands
or the command, basically.
On the response, we have the data and we have the trailer.
The trailer basically is the status
of the previous command from a terminal,
which basically that it tells if the command
was secured correctly, or if there is something wrong.
Something in the answer
is going to be in the status of this trailer.
So to have a better idea,
let's analyze a APDU command example.
This one on the, is going to be the first command
that the terminal sends to the card.
We analyze it separately.
We can see what is a class,
what is the instruction,
we have a parameter one, parameter two,
and we have the command length
and after that, we have the command
that is going to be sent to the card.
The same way, we have the card response,
which basically is the data. And after that is a trailer.
So in this particular example,
we have the data and the
trailer is going to be 90 00,
which basically is that the previous command was,
it secured correctly.
So now to analyze the data, for example, in this response
we need to decode it.
To decode this data, we need to use a TLV decoding method.
Or we can use the emvlab.org, decoding tool,
which basically you put the APDU
is going to break apart each,
each command or each answer
that they print to the card,
which is very straightforward.
For this type of responses, or commands we can analyze
very quickly to see what is inside of the APDU protocol.
But essential to understand the process
and to understand the communication between the terminal
on the card.
As a security researcher,
sometimes you need to find a way
to test some implementations,
but sometimes even when you have the idea,
you need to design or create hardware or software,
depending on what you want to test.
This was the case
when we need to design a tool to analyze APDU protocol
between the contact card, or EMV card, and the terminal.
Because we know that these security cards,
but one thing is, what they mentioned
saying that they are security cards
and another thing very differently
is the implementation.
So we decide to create or to design the Elma technology.
This Elma tool is a EMV Laboratory Middleware Assistant,
which basically is what it does.
It assist to analyze the EMV protocol between the terminal
on the card.
We're going to go into it tells about
how we design this hardware and what are the capabilities
that we have in the laboratory
to analyze these technologies.
So this is the Elma board.
Is based on Simtrace 2, which is a open hardware project.
Is specifically designed for the same technologies
implemented in the cellular phones, or the GSM network.
So the idea of Simtrace 2 is that you can sniff
or emulate traffic using the same adapter on the board,
or using the USB cable connect to a client in the computer.
On the other hand,
the Elma board is specifically designed,
using adapter, flexible adapters, on both ends.
But also it has a capability to implement the USB,
to feed the board or to analyze the traffic
between the terminal on the EMV card.
Also, it's capable to connect to a server,
implementing the wifi connectivity, using the ESP 32.
And it help us a lot in the laboratory
to understand the protocol and to understand the features
in the EMV cards.
These are some of the characteristics of the Elma board.
We have the USB-C connector, which basically is for,
for flexibility.
Also, we have the ESP 32 that we implemented
for wifi connectivity to the server
or to external server where we can send data
from the board, process it.
And after that, send them back to the board.
So the board can emulate it directly to a terminal.
Of course, where you have different adapters to connect,
like for example, EMV cards or SIM cards,
we have different modes that they could be, eh,
sniffing modes, fuzzers or emulation specifically for,
for a task.
Let me show you how it looks a,
a connection for the sniffing traffic.
We have the EMV card in one side
and we have the Elma in the middle.
And after that,
we implement another connector
with a physical physical board
that simulates a physical EMV card to the terminal,
which basically, it sends the data through the Elma.
And it simulates a transaction. Let's say, for example.
Basically this idea is to sniff the traffic from the card
to the terminal and read the responses from the,
from the card.
The idea of seeing the commands from the terminal
and seeing the response from the card is to analyze
how they interact with each other and after that
we can analyze their responses.
And to see there is something where
putting this communication process.
So let's analyze the Elma tool set.
Elma has different capabilities in the client.
And also in the board.
For example, we can use a sniffer
or emulator depending on the task.
Let's say for example, that we want to sniff some traffic.
We can run the sniffer,
the sniffer platform, or the sniffer firmware.
Or we want to emulate something
we can use the emulator for that task specifically.
Inside of the emulator,
we have different features like man-in-the-middle.
The man-in-the-middle can alter the CVM,
or basically the cardholder verification method.
Imagine that we have the list
of the cardholder verification method
that in this list, depending on the order,
it could be the verification method.
So we can change that implementing this,
this type of man-in-the-middle emulation mode.
Also we can change the terminal commands,
we can adapt the card response,
but one of the most important parts is that
we can modify any EMV type value.
This is to test the environment, basically.
Also, we have APDU fuzzer is to send random data
to a terminal or to the card
to see if we can break something. Right?
Of course, we have the Pinata attack.
And in these, in these features,
which is basically this presentation is based on.
And above all of that,
we have the option to implement a relay.
This means that for example, we can have,
the Elma board and one computer,
and even the physical card could be in another location.
And we can start data from that card,
implementing the client for, for this, for this Elma
is my work.
So the virtual smart card
is the core of the Elma technology.
Basically, I can relate it to a software emulator
of smart cards,
but you have the capabilities
to connect physical card readers to your computer
and move the data between these,
virtual smart card readers,
change the data and send it back.
And it could be sending back over a relay for example,
or you can send it back locally to another device
that is connected to the device.
It's very easy to use it.
And we implemented a lot in the Elma design.
So after we analyze the APDU protocol
and how we design the Elma prototype, or Elma technology.
Let me talk a little bit
about this inadequate implementation
to reset the PIN retry counter in the EMV cards,
or bank cards, let's say.
So let's talk a little bit about what is a process
in the protocol
when a transaction starts in the terminal
Initially, we have the card authentication.
After that we have the cardholder verification,
and then we have the transaction authorization.
So let's start with the card authentication.
In this step,
the terminal start sending commands
to list the applications.
Basically this point the terminal knows what kind of card
you are using. Let's say visa, MasterCard, American express,
something else.
So in the next, in the next step
is going to be the cardholder verification method.
It's where the terminal is going to prompt to enter a PIN.
Or it's going to ask you to sign, to sign in terminal,
or is going, is going to depend,
depending of the terminal technology.
And of course, comparing to the card technology.
All this process is going to finish
with the transaction authorization.
And this part, the terminal sends,
all the data to the backend,
to the financial institution.
And the financial institutions,
the financial institutions sends back the IRC,
which basically is the authorization response code.
And this is applied to the card or on of course,
applied to the, to a transaction.
So at this point,
the transaction can go through or it could be declined.
Is going to depend in all of these, all of these forms.
So let's focus in on the cardholder verification phase,
which is one of them,
one of the important steps in this research.
Do you know how many cardholder verification methods
do we have,
to make a transaction, for example?
So let's focus and read a little bit about
how many this verification methods, implements,
in the terminal on the card,
when you're making a transaction.
So we have a kind of list inside of the card
that it tells the terminal,
what kind of verification methods is capable of.
Some of them are like,
no CVM required, signing the paper,
plaintext PIN by ICC,
plaintext PIN on paper,
also encrypt PIN by ICC, or encrypt by ICC and sign paper.
And one of the most important is encrypted PIN
and is verification online,
which is one of the normal verification
when you're using an ATM for example,
the verification is encrypted PIN
and verify online all the time.
So this some of the most common
cardholder verification methods that we use
with the transactions.
So let's analyze this card response,
where we need to take a look at the CVM list,
especially putting attention to the 8E tag value.
So the first step is to decode it, to see how it's,
how it's implemented
or what kind of value the 8E attack contains.
So after we decode it,
we can see the cardholder verification method list.
Inside of the list we have all the values,
all the possibilities that the physical card has
to verify a transaction.
Specifically, I'm talking about the 8E EMV tag.
If we split the values we can understand them individually.
So let's do that.
So we have this list and we are going to separate
each value to understand what exactly,
what exactly means.
So we have encrypt, encrypted PIN, in the first row,
if terminal supports CVM.
The second row, is encrypted PIN by ICC.
And the third row is plain PIN by ICC.
And the next one is a sign.
Under that one, is no CVM required.
You can see this list is in order.
Do you might what happened if I flip the values, let's say,
if I put the 1F03 on the top of the list?
That could be another attack of another research,
but let's say we're going to be focused on
the plain Pin by ICC.
What this verification method does?
What exactly does is that you can verify a PIN
against the ICC.
So for example, I want to verify a PIN 1, 2, 3, and 4.
So I can send this 1, 2, 3, and 4
to the card implementing this command.
On the EMV card has different possibilities to respond.
Let's say if it is that the right thing,
you're going to be a 90 00,
which is going to be the trail of the EMV card response.
But also they have no more options
like 63 C2, which means there is a wrong PIN,
but you have two more attempts left.
And after that is going to be 63 C1,
which means is a wrong PIN,
and one more attempt left.
And 63 C0, which means wrong PIN and no more attempts left.
So you imagine, this is a counter, PIN retry counter,
which basically it counts how many attempts left
inside of the ICC.
So if this counters goes to zero,
that means that we don't have any more possibilities
to attempt with another PIN,
which is a mechanisms to protect
against brute force attacks.
So to be able to send these commands to the,
to the card, or to the EMV card,
first of course, the card has to support
plain PIN by ICC.
And another thing is, if we go through the EMV flow chart,
we can see that to send PINs to the card,
we need to go through the card identification.
And after that, we're going to be
in the cardholder verification.
At this point is where is,
where we able to send commands to the card.
So let's say that we start sending
to check their retry PIN counter.
And at this point,
the retry PIN counter has three more attempts left
to try different PINs.
So we start sending the PIN 07 18.
We got a response back, which is 63 C2,
which basically means is a wrong PIN.
And we have two more attempts left.
After we sent the last PIN,
which is going to be the 07 20,
we can notice that we got the 63 C0,
which means the PIN retry counter is equal to zero.
That means that we don't have more attempts left.
We are not able to try more, more PINs.
So here, the question is,
how can we reset this PIN retry counter to three, again?
We have two common ways to reset the PRC,
or the PIN retry counter.
One of the most common is when, do you remember the PIN?
And you can go to any ATM from the,
from the financial institution.
And when you insert the card to the ATM,
using the correct PIN,
the ATM internally is going to run the scripts
specifically to do the card management.
And it's going to reset this PRC
to the value that it has before.
Another way to do it is when the card
contains the encryption key
on the MACE scripts
inside of the card.
So when the terminal basically generates
the application cryptogram
and response with the ARPC,
basically for online approval,
the financial institution is going to response
with the ARPC,
which basically is for the approval
or rejection of the transaction.
But inside of this data, we're going to have the CSU,
which basically is the card status update,
which contains some data that could update the,
the card internally,
which could be a command to reset the PRC specifically.
Let's imagine that we have a card
and we already try three different PINs.
So we don't have any more attempts left in the EMV card.
That means that we need to try to make a transaction,
to see if the financial institution resets
the PIN retry counter.
So how we can do this?
We can try to make a transaction with no CVM required,
or we can try to make a transaction
implementing the signature CVM.
We can do this in different ways,
but normally, like the mobile POS's,
many of them implement no CVM
or signature CVM here in United States.
So the idea is that after generating
the application cryptogram,
the financial institution returns the ARPC.
We can verify if the PIN retry counter is set to three,
for example, or to five, depending of the configuration.
And we can notice this in the last step
of the transaction when the ARPC is applied to the card.
After this step we can verify the PIN retry counter
is sets to the back, to the previous value,
which it should be three or five,
depending on the implementation.
But, of course, this is a inadequate implementation,
bad practice to do it.
The best way to reset the PIN retry counter
is by using an ATM in the financial institution,
or by calling a representative from the bank, for example,
to assign a new PIN to the card.
And after they used that card in the ATM,
they are going to reset the PIN retry counter,
but doing,
doing this type of reset after a transaction,
it could be very dangerous,
I'm going to show you why.
So let's imagine that we have a normal ARC from the,
from the bank, which basically I can see some,
some changes between each responses.
So this one is a normal transaction
when you didn't receive
any order to change the PIN retry counter.
But in this slide, we can see a different,
different bytes that I can relate it to,
to the PIN retry counter, basically
to change it to the to the previous value.
So to be able to use the Pinata attack,
the card has to implement two different features.
One is the plain PIN by ICC cardholder verification method,
and also the PIN retry reset by the user
when the PRC is zero.
With these two characteristics,
we can run the Pinata attack against the EMV card.
And we are going to show you how I did my setup
to do this and to run this Pinata attack.
To run the Pinata attack we need to
make a special Elma set up project.
For this specific case,
I'm going to use the GPD pocket 2, a small computer
or pocket computer is one of the most powerful devices
in this size specifically to do different things.
But I mean, you can use any, any other device
that you have available to do this type of setup.
Also, we're going to use a cheapest card reader
that you can find on the internet, is the SCR3310,
which basically what is going to do is
we're going to extract the original EMV data
from this reader. So our card, our financial card
is going to be inserted in this reader.
So basically with the pocket computer,
we're going to start reading the card
and we're going to process the data.
And after that, we're going to send it,
send it to the Elma board.
So ultimately we're going to need the Elma board, of course,
and we're going to need the SumUp payment system.
Basically is a, is a payment system that you can,
that you can run implement in a cellular phone.
So you have an application and you can,
you can make payments directly to this, to this device.
The idea to have this device is to,
to be able to control the payment environment, basically.
So the idea of the Elma at this point is going to simulate
a real EMV card to SumUp,
but it's going to process the data that we are going to
extract from the card reader, basically.
Because we're going to use a mobile payment system
and we are going to have this application
for the SumUp payment system in our cellular phone,
we need to implement the Auto Clicker application.
The Auto Clicker, basically, what is going to do
is going to play an important role to make,
or to help us to automatize different different tasks.
For example,
let's say that we try three different PINs
and we need to make a new transaction
to reset the PIN retry counter.
So the Auto Clicker is going to that automatically for us.
So that's one of the most important parts in this,
in this Pinata attack.
So this is my set up.
I have the Pocket 2, basically in the middle,
we have the card reader, SCR3310,
where from where we are going to strike data,
the original data from the card.
On the other side, we have the Elma board connected by USB.
This could be a relay or an internet, but for this,
for this demo, we are using a locally, locally connection.
The Elma is going to simulate the transaction,
implementing the, the connector to the SumUp.
So when the SumUp sends the first command,
Elma is going to process it,
is going to send it to the client in the pocket computer.
And the pocket is going to send the last command to the,
to the card.
What's going to do on the client side
is going to start checking for some kind of flags.
Let's say, if I activate the Pinata attack
is going to detect when we are going to be
in the verification mode.
And after that, we're going to start
making the brute force attack against the PINs.
After we have a zero on the PIN retry counter,
we're going to start a new transaction
to reset this PIN retry counter.
And after, we have another three attempts in the counter.
We are going to start the process again,
to make the brute force attack against this EMV card.
Internally in the computer is going to be running
a virtual card reader, which is going to expect data
from the card reader or the physical reader.
And it's going to send this data to the Elma board.
Basically is to process the data internally.
And after that, to present this data to a terminal.
the idea of implementing virtual card reader
is to be able basically to emulate a card reader,
but simultaneously to be able to modify data in real time.
To visualize that Pinata attack.
So what it does basically is after a transaction,
it checks if the plain PIN by ICC verification method
is available. If it is, it checks the PIN try counter.
If it is greater than zero means that we have possibilities
to make a brute force attack.
If we couldn't find a PIN,
basically we repeat this cycle until we get the correct PIN.
So mentioning this, we can go directly to the demo slide.
So first I went to run the client software
to start to make a first,
the first transaction.
Here is a where the Auto Clicker is very handy.
So it's going to help,
help a lot with all the transaction
that we are going to need.
After we, we made the first transaction,
we are going to check the PIN retry counter
to see if it's greater than zero.
If it is, we're going to try to brute force the PIN,
implementing a list of possible PINs to try.
If we couldn't find any correct PIN,
we're going to make a new transaction
to reset the PIN retry counter.
And after we reset, we try to make a brute force attack
against the EMV card.
If, we couldn't find, we'll repeat the cycle until we,
we are able to, to find the correct PIN.
And in this last try, we find we'll be able to find
the correct PIN. And is the 07 22,
which basically is the PIN that we can use
to make a transaction with the card, basically.
On this point, we can use this card in the ATM,
or to make a purchase in any store implementing,
implementing the correct PIN.
I want to say thank you to these people.
They helped me a lot in this research,
especially the Metabase Q team for all the details
and support.
Thank you for being part of DefCon 29.
Hope you guys keep enjoying this event.