 Hello, everyone. It's really pleasure to be part of that content 9. My name is Salvador Mendoza, and I'm a security researcher of MetaVisQ, and I'm probably a member of also a lot of FESNIP security team. Today I'm going to talk about the PINAT attack or PINAT 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 and how someone could exploit it. Finally, we're going to have a demo implementing an internal tool named ALMA. 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 the issue or how the bad practices are implemented. So let's start with the secure element, OSE, which is basically responsible to sign the transaction but to keep the secrets in the card, on the physical card, to sign the transaction when it's processing it. The CVM is the card holder verification method, which could be different, right? It could be the uberified transaction by signing it, or it could be by PIN entry mode. Also, we have the APDU, the application protocol data unit. It's the protocol in charge to communicate or to handle 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 and to the terminal. The EMV contact payment is one of the most common and secure technology that we implement and use every day to make transactions, because it implements a secure element, and the secure element is in charge to sign the transactions or to sign the challenge that the terminal is sending to the card. Basically, contact payment is when we insert the card into a terminal and we leave it there until the transaction finishes. Sometimes the user will require to insert or to enter the PIN for the transaction, and sometimes it will require to sign a paper to verify the transaction. When the card is inserted into a terminal, it's going to be detected, and after that it's going to be resetted. It's going to be the list applications, and it's going to be different 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 it's going to depend on the verification method. If we take a look into different details regarding the terminal and card communication, we can see in the protocol phases how this transaction goes through. For example, we have the card authentication, we have the card holder verification method, and also we have the transaction authorization. It's going to be the last phase after the verification in the transaction. When the terminal starts sending comments to the card, the card must answer back for that specific comment. But for example, let's say if the terminal sends a comment that is not properly right, the card will answer back that that comment wasn't right. So the terminal is going to prepare a new comment and send it back to the card. So basically it's when you are typing something to a terminal, and every comment you are getting it responds back. It's the same thing with the terminal on the card. It's like sending a comment and getting a response back very quickly. One of the most important parts in this protocol phase is the card holder verification 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 it's not, sadly it's 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 the terminal as well. And also the same technology that we use for our cell phones. This chip that you put in the cell phone, it communicates implementing the same APDU layer with the cell phone. So it's not encrypted the communication, but it need to follow 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 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 command, or the command basically. And the response, we have the data and we have the trailer. The trailer basically is the status of the previous command from the terminal, which basically that it tells if the command was executed 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 the APDU command and sample. This is going to be the first command that the terminal sends to the card. If we analyze it separately, we can see where is the class, what is the instruction. We have parameter one, parameter two. We have the command length. And after that, we have the command that is going to be sent to the card. In the same way, we have the card response, which basically is the data and after that is the trailer. So in this particular example, we have the data and the trailer is going to be 90-0-0, which basically is that the previous command was executed correctly. So to analyze the data, for example, in this response, we need to decode it. To decode this data, we need to use the TLV decoding method. Or we can use the envlab.org decoding tool, which basically you put the APDU and it's going to break apart each command or each answer that you printed correctly, which is very straightforward. For this type of response or commands, we can analyze very quickly to see what is inside of the APDU protocol. Very essential to understand the process and to understand the communication between the terminal and the card. As 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 the APDU protocol between the contact card or EMV card on the terminal. Because we know that these are 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 decided to create or to design the ELMA technology. This ELMA tool is an EMV laboratory millware assistant, which basically is what it does. It assists to analyze the EMV protocol between the terminal and the card. And we're going to go into details 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. It's based on the SIMTRAGE 2, which is an open hardware project. It's specifically designed for the SIMTRAGE 2 implemented in the cellular phones of the GSM network. So the idea of the SIMTRAGE 2 is that you can sniff or emulate traffic using the SIM adapter on the board or using the USB cable connected to the client and the computer. On the other hand, the ELMA board is specifically designed using flexible adapters on both ends. But also it has the capability to implement the USB to fit the board or to analyze the traffic between the terminal and the EMV card. Also, it's capable to connect to a server implementing the Wi-Fi connectivity using the ESP32. And it helps 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 flexibility. Also, we have the ESP32 that we implemented for Wi-Fi connectivity to the server or to a external server, where we can send data from the board and process an adapter that's sending back to the board so the board can emulate it directly to the terminal. Of course, we have different adapters to connect like, for example, EMV cards or SIM cards. And we have different modes, that they could be sniffing modes, passwords or emulation specifically for a task. Let me show you how it looks, 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 board that simulates a physical EMV card to the terminal, which basically 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 card. The idea of seeing the comments from the terminal and seeing the responses from the card is to analyze how they interact with each other. And after that, we can analyze the responses and to see if there is something weird during this communication process. So let's analyze the ELMA toolset. 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 if we want to emulate something, we can use the emulator for that task specifically. Inside of the emulator, we have different features, like many in the middle. The many 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 type of many in the middle emulation mode. Also, we can change the terminal comments. 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 Fossil is to send random data to the terminal or to the card to see if we can break something. Of course, we have the Piñata attack 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 Alma board in one computer, and even the physical card could be in another location. We can extract data from that card implementing the client for this Alma board. So the virtual and smart card is the core of the Alma technology. Basically, I can relate it to a software emulator of a smart card. 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 Alma design. So after we analyzed the APDU protocol and how we designed the Alma prototype or Alma technology, let me talk a little bit about this in our code implementation to reset the peer retry counter and the EMV card, so bank cards, that's it. So let's talk a little bit about what is the process in the protocol when a transaction starts in the terminal. Initially, we have the card authentication. After that, we have the card holder verification. And then we have the transaction authorization. So let's start with the card authentication. In this step, the terminal starts sending commands to list the applications. Basically, at this point, the terminal knows what kind of card you are using. Let's say it's a Visa, MasterCard, American Express, something else. So in the next step, it's going to be the card holder verification method. It's where the terminal is going to prompt to enter a PIN, or it's going to ask you to sign in the terminal, or it's going to depend on the terminal technology and, of course, comparing to the card technology. All this process is going to finish with the transaction authorization. In this part, the terminal sends all the data to the backend, to the financial institution. And the financial institutions, all the financial institutions sends back the IRC, which basically is the authorization response code. And this is applied to the card, and, of course, applied to the transaction. So at this point, the transaction can go through or it could be declined. It's going to depend on all of these forms. So let's focus in on the card holder verification phase, which is one of the important steps in this research. Do you know how many card holder verification methods do we have to make a transaction, for example? So let's focus and read a little bit about how many these verification methods implement in the terminal and the card when you're making a transaction. So we have a kind of list in style of the card that it tells the terminal what kind of verification methods it's capable of. And some of them are like NOSVM required, signed in the paper, Planted Spin by ICC, Planted Spin and Paper, also Encrypted Pin by ICC or Encrypted Pin by ICC and Change Paper. And one of the most important is Encrypted Pin and its verification online, which is one of the normal verification when you are using an ATM, for example. The verification is Encrypted Pin and verified online all the time. So these are some of the most common card holder verification methods that we use with the transactions. So let's analyze these 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 implemented or what kind of value the 8E tag contains. So after we decode it, we can see the card holder 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 means. So we have Encrypted Pin in the first row. It's a terminal support 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 and the last one is No CVM required. You can see this list is in order. Do you mind what happens if I flip the values? Let's say if I put the 1F03 in the top of the list. That could be another tag for 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 it 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. And the EMV card has different possibilities to respond. Let's say if that's the right pin it's going to be a 90 and 00, which is going to be the trail of the EMV card response. But also they have other options, like SITS-3, C2, which means there is a romping, but you have two more attempts left. And after that it's going to be SITS-3, C1, which means there's a romping and one more attempt left, and SITS-3 is C0, which means one pin and no more attempts left. So if you imagine, this is a counter, pin retry counter, which basically it counts how many attempts left inside of the ICC. So if this counter goes to 0, that means that we don't have any more possibilities to attempt with another pin, which is a mechanism to protect against brute force attacks. So to be able to send these commands to the card, to the EMV card, first of course the card has to support pain pin by ICC. And the other 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 pin the card holder verification. At this point is where we'll be able to send commands to the card. So let's say that we start sending to check the 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, and we got a response back, which is 063-02, which basically means it's 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-Z0, which means the pin retry counter is equal to 0. That means that we don't have more attempts left, and we are not able to try more pins. So here the question is, how can we reset this pin retry counter to 3 again? We have two common ways to reset the PRC or the pin retry counter. One of the most common is when you remember the pin and you can go to any ATM from the financial institution, and when you send the card to the ATM using the correct pin, the ATM internally is going to run the script, 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 and the MACI scripts inside of the card. So when the terminal basically generates the application cryptogram and responds with the ERQC basically for online approval, the financial institution is going to respond with the ARPC, which basically is for the approval or rejection of the transaction. But inside of this data, we are going to have the CSU, which basically is the card status update, which contains some data that could update the card internally, which could be a command to reset the PRC specifically. Let's imagine that we have a card and we already tried 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, many of them implement no CVM or signature CVM here in the United States. So the idea is that after generating the application cryptogram, and the financial institution returns the ARPC, we can verify if the pin retry counter is set to three, for example, or to five, depending on the configuration. 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 if the pin retry counter is set to the previous value, which it should be three or five depending on the implementation. But of course this is an inadequate implementation, a 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 use the card in the ATM, they are going to reset the pin retry counter. But 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 bank, which basically I can see some changes between each responses. So this one is a normal transaction when it didn't receive any order to change the pin retry counter. But in this slide, we can see different bytes that I can relate it to the pin retry counter, basically, to change it to the previous value. So to be able to use the pinnet attack, the card has to implement two different features. One is the plain pin by ARPC card-holded verification method, and also the pin retry reset by the user when the PRC is zero. With these two characteristics, we can run the pinnet attack against the EMV card. And we are going to show you how I did my setup to do this and to run this pinnet attack. To run the pinnet attack, we need to make a special LMAZ setup project. For this specific case, I'm going to use the GPD Pocket 2, a small computer or pocket computer. It's one of the most powerful devices in this size specifically to do different things. But I mean, you can use 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 SGR3310, which basically what it's 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, the 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 to the LMA board. So also, we're going to need the LMA board, of course, and we're going to need the sum up payment system. Basically, it's a payment system that you can implement in a cellular phone. So you have an application and you can make payments directly to this device. The idea to have these devices to be able to control the payment environment, basically. So the idea of the LMA at this point is going to simulate a real EMV card to sum up, 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 sum up payment system in our cellular phone. We need to implement the AutoClicker application. The AutoClicker, basically, what it's going to do is going to play an important role to help us to automatize 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 AutoClicker is going to do that automatically for us. So that's one of the most important parts in this pinata. So this is my setup. I have the pocket two basically in the middle. We have the card reader SCR3010 from where we are going to extract data, the original data from the card. On the other side, we have the LMA board connected by USB. This could be a relay over the internet, but for this demo, we are using locally connection. The LMA is going to simulate the transaction implementing the connector to the sum up. So when the sum up sends the first comment, LMA 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 comment to the card. What's going to do in the client side is going to start checking for some kind of flags. Let's say if I activate the pinata tag, it's 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 and 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, it's 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 LMA board. Basically, it's 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 the pinata tag. 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'm going to run the client software to start to make the first transaction. Here is where the clicker is very handy. So it's going to help a lot with all the transactions that we are going to need. After we made the first transaction, we're 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 a correct pin, we're going to make a new transaction to reset the pin retry counter. And after we reset it, we try to make a brute force attack against the EMV card. If we couldn't find it, we repeat this cycle until we are able to find the correct pin. In this last try, we'll be able to find the correct pin. And it's 0722, which basically is the pin that we can use to make a transaction with the card, basically. At this point, we can use this card in the ATM or to make a purchase in any store, implementing the correct pin. I want to say thank you to these people that helped me a lot in this research, especially the MetabaseQ team for all the details and support. And thank you for being part of TevCon29. Hope you guys keep enjoying this event.