DEF CON 29 - Salvador Mendoza - PINATA PIN Automatic Try Attack

00:04 - My name is Salvador Mendoza and I’m a Security Researcher at Metabase Q.

00:08 - And I’m proudly member of Ocelot Offensive Security Team.

00:12 - Today, I’m going to talk about the Pinata attack, or PIN Automatic Try Attack, regarding EMV technology.

00:20 - So let’s start with the agenda for today. We’re going to have an introduction to terminology.

00:25 - 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.

00:37 - After that we’re going to talk about the inadequate implementation regarding this attack.

00:43 - How someone could exploit it. Finally we’re going to have a demo implementing a internal tool, named Elma.

00:54 - And after that, we’re going to have some conclusions regarding this research.

01:05 - Let’s analyze some terminology that we’re going to use throughout this presentation.

01:10 - 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.

01:23 - 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.

01:40 - 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.

01:54 - 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.

02:08 - Also, we have the ICC, or integrated circuit card.

02:13 - We know these cards, as well as smart cards, for example, but we’re going to talk specifically to the EMV transactions.

02:22 - That’s to be clear. The PRC is the PIN retry counter.

02:28 - 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.

02:46 - The EMV contact payment is one of the most common, un-secure technology that we implement and use every day to make transactions.

02:55 - 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.

03:08 - Basically a contact payment. It’s when we insert the card into a terminal, and we’ll leave it there until the transaction finish.

03:17 - Sometimes the user will require to insert, or to enter the PIN, for the transaction.

03:25 - Sometimes it will require to sign a paper to verify the transaction.

03:36 - When the card is in inserted into a terminal is going to be detected and after that is going to be reset.

03:44 - Is going to be the list applications, and is going to be different the steps until the transaction is complete.

03:50 - 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.

04:00 - It will depend on different factors. And of course, is going to depend on the verification method.

04:11 - 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.

04:24 - For example, we have the card authentication, we have the cardholder verification method, and also we have the transaction authorization.

04:32 - It is going to be the last phase, after the verification in the transaction.

04:39 - When the terminal starts sending commands to the card, the card must answer back for that specific command.

04:47 - 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.

05:01 - So the terminal is going to prepare a new command and send it back to the card.

05:05 - 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.

05:16 - It’s like a, sending a command and getting a response back very quickly.

05:22 - 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.

05:35 - Many people think that the communication between the card and the terminal is encrypted, but is not, sadly is not.

05:44 - And they use the ISO 7816, which basically, many other technologies use it as well.

05:51 - Such as NFC, for example. NFC implements the application APDU layer to communicate with a terminal, as well.

06:00 - And also the same technology that we use for our cell phones.

06:05 - This chip that you put in cell phone, it communicates implementing the same APDU layer with a cellular phone.

06:14 - 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.

06:33 - And take a look into the different details of parameters inside of this, of this APDU protocol.

06:43 - So let’s analyze one of the most important parts in the APDU protocol, which are the commands and the responses.

06:50 - So basically let’s start with the APDU command, which is literally different from the card response.

06:58 - We have a header, and we have a body.

07:01 - And the body we have the length of the command.

07:03 - And also we have the data from the commands or the command, basically.

07:07 - On the response, we have the data and we have the trailer.

07:11 - 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.

07:24 - Something in the answer is going to be in the status of this trailer.

07:31 - So to have a better idea, let’s analyze a APDU command example.

07:38 - This one on the, is going to be the first command that the terminal sends to the card.

07:45 - 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.

08:01 - The same way, we have the card response, which basically is the data. And after that is a trailer.

08:09 - 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.

08:22 - So now to analyze the data, for example, in this response we need to decode it.

08:28 - To decode this data, we need to use a TLV decoding method.

08:35 - 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.

08:53 - For this type of responses, or commands we can analyze very quickly to see what is inside of the APDU protocol.

09:04 - But essential to understand the process and to understand the communication between the terminal on the card.

09:15 - 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.

09:33 - 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.

09:46 - 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.

10:00 - So we decide to create or to design the Elma technology.

10:05 - This Elma tool is a EMV Laboratory Middleware Assistant, which basically is what it does.

10:12 - It assist to analyze the EMV protocol between the terminal on the card.

10:20 - 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.

10:34 - So this is the Elma board. Is based on Simtrace 2, which is a open hardware project.

10:42 - Is specifically designed for the same technologies implemented in the cellular phones, or the GSM network.

10:52 - 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.

11:08 - On the other hand, the Elma board is specifically designed, using adapter, flexible adapters, on both ends.

11:17 - 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.

11:31 - Also, it’s capable to connect to a server, implementing the wifi connectivity, using the ESP 32.

11:40 - And it help us a lot in the laboratory to understand the protocol and to understand the features in the EMV cards.

11:52 - These are some of the characteristics of the Elma board.

11:55 - We have the USB-C connector, which basically is for, for flexibility.

12:02 - 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.

12:16 - And after that, send them back to the board.

12:18 - So the board can emulate it directly to a terminal.

12:23 - 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.

12:41 - Let me show you how it looks a, a connection for the sniffing traffic.

12:49 - We have the EMV card in one side and we have the Elma in the middle.

12:55 - 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.

13:13 - And it simulates a transaction. Let’s say, for example.

13:17 - Basically this idea is to sniff the traffic from the card to the terminal and read the responses from the, from the card.

13:27 - 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.

13:40 - And to see there is something where putting this communication process.

13:52 - So let’s analyze the Elma tool set. Elma has different capabilities in the client.

13:58 - And also in the board. For example, we can use a sniffer or emulator depending on the task.

14:05 - Let’s say for example, that we want to sniff some traffic.

14:09 - We can run the sniffer, the sniffer platform, or the sniffer firmware.

14:16 - Or we want to emulate something we can use the emulator for that task specifically.

14:23 - Inside of the emulator, we have different features like man-in-the-middle.

14:28 - The man-in-the-middle can alter the CVM, or basically the cardholder verification method.

14:34 - 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.

14:43 - So we can change that implementing this, this type of man-in-the-middle emulation mode.

14:50 - 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.

15:02 - This is to test the environment, basically.

15:06 - 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.

15:21 - And in these, in these features, which is basically this presentation is based on.

15:29 - And above all of that, we have the option to implement a relay.

15:37 - This means that for example, we can have, the Elma board and one computer, and even the physical card could be in another location.

15:46 - And we can start data from that card, implementing the client for, for this, for this Elma is my work.

15:58 - So the virtual smart card is the core of the Elma technology.

16:05 - 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.

16:26 - 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.

16:36 - It’s very easy to use it. And we implemented a lot in the Elma design.

16:44 - So after we analyze the APDU protocol and how we design the Elma prototype, or Elma technology.

16:53 - 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.

17:08 - 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.

17:23 - After that we have the cardholder verification, and then we have the transaction authorization.

17:29 - So let’s start with the card authentication.

17:34 - In this step, the terminal start sending commands to list the applications.

17:42 - Basically this point the terminal knows what kind of card you are using. Let’s say visa, MasterCard, American express, something else.

17:54 - So in the next, in the next step is going to be the cardholder verification method.

18:00 - It’s where the terminal is going to prompt to enter a PIN.

18:05 - 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.

18:17 - And of course, comparing to the card technology.

18:22 - All this process is going to finish with the transaction authorization.

18:30 - And this part, the terminal sends, all the data to the backend, to the financial institution.

18:39 - And the financial institutions, the financial institutions sends back the IRC, which basically is the authorization response code.

18:50 - And this is applied to the card or on of course, applied to the, to a transaction.

18:58 - So at this point, the transaction can go through or it could be declined.

19:05 - Is going to depend in all of these, all of these forms.

19:13 - So let’s focus in on the cardholder verification phase, which is one of them, one of the important steps in this research.

19:23 - 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.

19:43 - So we have a kind of list inside of the card that it tells the terminal, what kind of verification methods is capable of.

19:54 - 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.

20:13 - 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.

20:33 - So this some of the most common cardholder verification methods that we use with the transactions.

20:43 - 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.

20:56 - 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.

21:09 - So after we decode it, we can see the cardholder verification method list.

21:15 - Inside of the list we have all the values, all the possibilities that the physical card has to verify a transaction.

21:29 - Specifically, I’m talking about the 8E EMV tag.

21:36 - If we split the values we can understand them individually.

21:41 - 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.

21:53 - So we have encrypt, encrypted PIN, in the first row, if terminal supports CVM.

21:59 - The second row, is encrypted PIN by ICC. And the third row is plain PIN by ICC.

22:08 - And the next one is a sign. Under that one, is no CVM required.

22:15 - 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.

22:39 - What this verification method does? What exactly does is that you can verify a PIN against the ICC.

22:52 - So for example, I want to verify a PIN 1, 2, 3, and 4.

22:57 - So I can send this 1, 2, 3, and 4 to the card implementing this command.

23:06 - On the EMV card has different possibilities to respond.

23:10 - 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.

23:24 - But also they have no more options like 63 C2, which means there is a wrong PIN, but you have two more attempts left.

23:36 - And after that is going to be 63 C1, which means is a wrong PIN, and one more attempt left.

23:43 - And 63 C0, which means wrong PIN and no more attempts left.

23:49 - So you imagine, this is a counter, PIN retry counter, which basically it counts how many attempts left inside of the ICC.

24:02 - 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.

24:19 - 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.

24:32 - 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.

24:44 - And after that, we’re going to be in the cardholder verification.

24:47 - At this point is where is, where we able to send commands to the card.

24:56 - So let’s say that we start sending to check their retry PIN counter.

25:02 - And at this point, the retry PIN counter has three more attempts left to try different PINs.

25:10 - So we start sending the PIN 07 18. We got a response back, which is 63 C2, which basically means is a wrong PIN.

25:24 - 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.

25:43 - That means that we don’t have more attempts left.

25:47 - 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.

26:05 - 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.

26:15 - 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.

26:25 - And it’s going to reset this PRC to the value that it has before.

26:34 - Another way to do it is when the card contains the encryption key on the MACE scripts inside of the card.

26:43 - 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.

27:06 - 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.

27:28 - Let’s imagine that we have a card and we already try three different PINs.

27:34 - So we don’t have any more attempts left in the EMV card.

27:39 - That means that we need to try to make a transaction, to see if the financial institution resets the PIN retry counter.

27:51 - 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.

28:05 - 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.

28:18 - So the idea is that after generating the application cryptogram, the financial institution returns the ARPC.

28:28 - We can verify if the PIN retry counter is set to three, for example, or to five, depending of the configuration.

28:36 - And we can notice this in the last step of the transaction when the ARPC is applied to the card.

28:48 - 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.

29:01 - But, of course, this is a inadequate implementation, bad practice to do it.

29:09 - 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.

29:26 - 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.

29:45 - 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.

29:57 - So this one is a normal transaction when you didn’t receive any order to change the PIN retry counter.

30:07 - 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.

30:25 - So to be able to use the Pinata attack, the card has to implement two different features.

30:32 - One is the plain PIN by ICC cardholder verification method, and also the PIN retry reset by the user when the PRC is zero.

30:42 - With these two characteristics, we can run the Pinata attack against the EMV card.

30:48 - And we are going to show you how I did my setup to do this and to run this Pinata attack.

30:57 - To run the Pinata attack we need to make a special Elma set up project.

31:04 - 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.

31:19 - But I mean, you can use any, any other device that you have available to do this type of setup.

31:27 - 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.

31:50 - So basically with the pocket computer, we’re going to start reading the card and we’re going to process the data.

31:56 - And after that, we’re going to send it, send it to the Elma board.

32:02 - So ultimately we’re going to need the Elma board, of course, and we’re going to need the SumUp payment system.

32:09 - Basically is a, is a payment system that you can, that you can run implement in a cellular phone.

32:16 - So you have an application and you can, you can make payments directly to this, to this device.

32:22 - The idea to have this device is to, to be able to control the payment environment, basically.

32:31 - 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.

32:51 - 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.

33:05 - 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.

33:15 - 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.

33:24 - So the Auto Clicker is going to that automatically for us.

33:28 - So that’s one of the most important parts in this, in this Pinata attack.

33:35 - 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.

33:50 - On the other side, we have the Elma board connected by USB.

33:54 - This could be a relay or an internet, but for this, for this demo, we are using a locally, locally connection.

34:02 - The Elma is going to simulate the transaction, implementing the, the connector to the SumUp.

34:09 - 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.

34:17 - And the pocket is going to send the last command to the, to the card.

34:22 - What’s going to do on the client side is going to start checking for some kind of flags.

34:29 - Let’s say, if I activate the Pinata attack is going to detect when we are going to be in the verification mode.

34:36 - And after that, we’re going to start making the brute force attack against the PINs.

34:41 - After we have a zero on the PIN retry counter, we’re going to start a new transaction to reset this PIN retry counter.

34:50 - And after, we have another three attempts in the counter.

34:54 - We are going to start the process again, to make the brute force attack against this EMV card.

35:05 - 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.

35:14 - And it’s going to send this data to the Elma board.

35:17 - Basically is to process the data internally.

35:20 - And after that, to present this data to a terminal.

35:23 - 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.

35:39 - 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.

35:56 - If it is greater than zero means that we have possibilities to make a brute force attack.

36:02 - If we couldn’t find a PIN, basically we repeat this cycle until we get the correct PIN.

36:10 - So mentioning this, we can go directly to the demo slide.

36:19 - So first I went to run the client software to start to make a first, the first transaction.

36:26 - Here is a where the Auto Clicker is very handy.

36:28 - So it’s going to help, help a lot with all the transaction that we are going to need.

36:33 - After we, we made the first transaction, we are going to check the PIN retry counter to see if it’s greater than zero.

36:40 - If it is, we’re going to try to brute force the PIN, implementing a list of possible PINs to try.

36:50 - If we couldn’t find any correct PIN, we’re going to make a new transaction to reset the PIN retry counter.

36:58 - And after we reset, we try to make a brute force attack against the EMV card.

37:05 - If, we couldn’t find, we’ll repeat the cycle until we, we are able to, to find the correct PIN.

37:14 - 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.

37:31 - On this point, we can use this card in the ATM, or to make a purchase in any store implementing, implementing the correct PIN.

38:00 - 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.

38:09 - Thank you for being part of DefCon 29. Hope you guys keep enjoying this event. .