 Hi, Defcom. How's it going? So, thank you guys for joining to this presentation. Contactless Overflow, where we're going to discuss about code execution issues in NFC readers that are used in point of sales and ATMs. So, short introduction about myself. I'm a principal security consultant at IOACTIV. So, I'm a guy that most of his time is doing reverse engineering, basically from bare metal, fingered operating system, whatever that can be reverse in the near. Also, I do some hardware hacking as well, code review, also a lot for finger operating systems, applications, whatever. So, basically, I'm a guy that likes to break stuff and, you know, learn new things. But also, I enjoy to find mitigations and solutions for those findings, because sometimes it's quite challenging as well. So, this is agenda for the presentation where we're going to have some interaction and then we will describe with technical details some of the code execution issues. And then we'll also talk about the ATM scenario more in particular. So, one important thing to take into account here is that all the issues that we'll see here are in different scenarios or devices. For instance, this typical portable or mobile payment device that you use to pay in restaurants or shops are affected, as we'll see later. But also in devices like to pay for the bus or the train station, in ATMs as well, parking machines or even vending machines. So, a lot of different scenarios. We have these devices. Also, for previous research, I wanted to see if there were any, you know, research paper or whatever that was possible to compromise the finger of the device over NFC. And I couldn't see anything like that. So, at least back then, I couldn't find anything like this in this case. So, how these devices work, I'm going to use as an example this device that you have there on the screen. In this case is the ID Tech Kiosk 3, as you can see here. I started with this device during my research because I have many years of experience working with ATMs and I knew that this device, this reader, is using most of the ATMs in the world, in the most important ATM vendors. So, basically, we have here this case is where we have the NFC antenna and also the NFC chip. And then with this serial cable connects to this board where we have the microcontroller that handles all the parsing of the credit card or debit card information. But also, this microcontroller is responsible for the USB communications because this board is connected with this USB cable to a house computer with this device, which could be a Windows computer or a Linux computer. In this case, it would be the ATM computer. So, what we really want to compromise is this microcontroller that is where all the UC stuff is happening and in this case, through the contactless interface. So, we don't need to be experts in E&B transactions and all the details about the protocol, but we just need to know at least that between a transaction when we are using the contactless interface, the reader is the one that starts the communication and then the card in this case will respond back and then, you know, we have these communications back and forth between them. And where we need to focus on is the data that, in this case, the credit card, the data that sends to the reader because we want to send something in particular that allows us to get code execution in the finger of the NFC reader. So, at the application layer, we have what is called APD use. So, basically, at the application layer is what the credit card in this case is sending to the reader. And this is based on TLB, so tag length value. So, basically, we have one byte that indicates the tag, one byte that indicates the length of the packet and then the value itself. So, it's pretty easy to understand the grammar of this packet, of these APD use. There are tools out there where, for instance, this is an APD use for a transaction where you can see like the first byte, SF indicates the file control information. Then the second byte, 6A, is the size of the entire packet in this case. And then the 84 byte in this case is the next tag. So, that's how more or less works. But we, like, again, like I said, we don't need too much in the, you know, the EMV protocol in this case for EMV transactions. So, yeah, if you sniff the communications, like with the Proxmo, for instance, this is what you get during a transaction where you have the NFC low level protocol or on commands. And then you have the APD use that, the communications between the reader and the, and the card at the application layer. Okay, so one of the first things that we need to do is to emulate the card because we want to, you know, attack the reader emulating a card and send something specific. So, at first what I used was this device, the ACR122 device, which contains the NXP PN532 chip that allows emulation. So, yeah, you connect that reader to your laptop over USB and then with some Python framework, you can send some commands like start the emulation mode for that reader. And then with Python as well, you can interact with the APDU layer, with the application layer with the reader and you can send APD use to the reader and receive the APD use from the reader as well. In this case, I was using this framework, the RFID IoT, which is very, very useful for this. But also there's another approach which is, in this case, you create your own Android application using host card emulation that allows you to also interact with emulator card and interact at the application layer with NFC reader in this case. So before jumping to the issues, let's talk about IDTECH. Like I said before, I started with this reader, the IDTECH Kiosk 3 device because it was present in every ATM that has contactless capabilities. So IDTECH is a global leader in payment devices where they make like a lot of different devices, not only this Kiosk 3 device. They also make pin pads, touch screens displays and other devices for payment devices. And something important to understand here as we will see later that all devices from IDTECH are vulnerable to these code issues because they basically use the same code base for the finger. So this particular one device, the Kiosk 3, I bought it in happyATMs.com website where you can buy parts from ATMs that have been in production. You can also buy this in eBay. So this actually was using an ATM. But also I bought brand new devices from IDTECH as well to make sure that they were also, with the newest version of the finger, they were also vulnerable. So yeah, as you can see here in this picture, in the ATMs, for instance, the only part that is exposed to the user, obviously this is the case where the NFC antennas. But also these IDTECH devices are not only in ATMs, they are also in parking machines, vending machines. They have also this device which is also vulnerable in retail and hospitality. So basically it's using a lot of different scenarios. Okay, so let's jump to the issues. So first when I got this device from that website, happyATMs.com, what I wanted to check if JTAG was enabled. So I was able to, surprisingly it was enabled and I was able to extract the finger and gain debugging capabilities with GDB, which is also great because for the reverse engineering process is really helpful, but also for the exploit development process. But also in the devices that I bought from IDTECH, JTAG was enabled as well, which is not great, but yeah, basically JTAG is enabled in all of these devices. So then once I'm able to extract the finger from the microcontroller of this device, I started to reverse it near the finger. In this case it's a bare metal finger where we don't have an operating system, there is no symbols, no strings, and it has more or less around 1600 functions, so it's more or less big. So yeah, it's a bit hard to reverse engineer this kind of finger. So my first goal here is to locate in the finger, in the code of the finger where it starts reading the concept of the credit card in this case. So there are different approaches here, but what I did basically is that when I was learning more about EMV transactions, I knew that there was something called proximity payment system environment, which is basically these bytes, as you can see here, that the reader is sending to the card in the very first communication. So I just needed to find those bytes in the code, and I found it, as you can see here, and then start from here to reverse engineer and understand what the code was doing. Then after some hours I identified, as you can see here, I changed the name of this function because there were no symbols as receive card, because I found that in this function is the function where it starts reading from the card over the NFC interface. So something important to understand also here is that standard APD use are up to 255 bytes size, that's a maximum size. So as you can see here, the code was checking the byte that indicates the length of the packet, so it's only one byte, because it's only 255 bytes as maximum. So yeah, I was getting more familiar with the code, but also I was a bit concerned because with only 255 bytes, you can end up in a situation where you have a stack buffer of flow, for instance, but with that size, 255 as maximum, maybe you can't overflow the other variables in the stack and then overwrite the saved return address in the stack. Of course, you can maybe overwrite some of the other local variables in the stack and achieve code execution in that way, but normally it's harder and that's why I was a bit concerned because of that. But then when I was getting more familiar with the code, I realized that as you can see here in these lines, the code in the firmware was checking if the second byte of the APDU is the byte 82 in X, then it was getting two bytes from the APDU as the size, meaning that then if it's getting two bytes a size, then we can have FFF of size, which is 65,000 more or less bytes. So I was a bit, I didn't understand at the beginning because as far as I knew, the maximum size of an APDU was 255 bytes. But then doing some searching about this and I found that there's something called extended APDU's, which indeed are up to 65,000 bytes and indeed they used two bytes to indicate the size of that APDU. So that was great news because now I can send, I can try to use these extended APDU's. Then I realized in this case that the function that reads the contents of the card, it's using to store that APDU in this stack buffer and if we can send a buffer bigger than 138 hex, which is 312 bytes, if I remember correctly, then you would overflow this buffer and then get a stack buffer flow. So I saw this statically, reversing it in the firmware, but I needed to be able to send an extended APDU and prove that that was possible. But the problem was that the reader I was using to emulate a card didn't support extended APDU's by hardware, so I couldn't use that. And I was looking on the internet like how can I emulate a card, but also be able to send an extended APDU. And the only solution I saw back then was that I found in some Google forums that some Google Pixel phones had hardware support for extended APDU's and also Google released an Android version with support also for extended APDU's. So at least I found something that allowed me to send those extended APDU's. So this is part of the Android application that they created. And here you have the APDU I'm sending, which is these initial bytes are following the protocol, but then the rest of the packet as you can see are 41, 41, 41, the typical A's in ASCII, you know, for the proof of concept, typical proof of concept. So, yeah, as soon as I tried the POC with the reader, as I was expecting, as you can see here in the output of GDB, the stack overflow was working and I was able to have control of the PC register, so in this case code execution is possible in this framework through the NFC interface. But also it's important to clarify that in these particular devices from ID Tech, in this case the Kiosk 3, there is no exploit mitigations at all, which makes it easier the exploitation of this, but also there is no secure boot, so you can make it persistent, which is also better from the attacker's perspective. And also since we are using extended APDU's, which can be 65,000 bytes big, then you have plenty of bytes that you can use for your own ARM instructions to create your own, to inject your own malware in the finger of the device. So, also this stack buffer flow is present in another 21 different functions in the same finger that are reachable on other stages of the transaction, but I just needed one, but yeah, I kept looking and then I found 21 more. So, let me show you a video of this. So, let me make this bigger. All right. So, here we have the Kiosk 3 device. I'm attached with the JTAG interface, so we can see the crash in GDB in real time. And also you can see the USB cable is connected to this laptop. And in the laptop is where the, in this case the ID Tech SDK, the application is running and is sending the commands through the USB cable to the reader to start the transaction. And in the right side we have the GDB. So, first I'm going to start a transaction here and then I'm going to use a credit card. There is no sound apparently, but you should hear a beep there. And then we can see the credit card information in the application. So, it worked the transaction. And now if I use my proof of confidence in this case, well, in this case there is no sound, but you wouldn't hear a beep because the finger is crashing before trying to make the beep. And then we can see the crash in GDB. So, here we have, we can see that the LR register is with our 41.41 bytes. But also if we execute the backtrace command we can see that the return address is 41.41.41 as well. So, there's the bug working with, in this case in the GDB. And like I said before, all the other ID Tech devices were having the same exact issue because they were using the same code base at least at that particular layer of the parsing. Okay, so, at this point I was thinking like, okay, this is, it's pretty clear that the problem here is that this device by hardware and software supports those extended PDUs. But the developers didn't take into account that, yeah, the device can receive more than, in this case, 312 bytes. That was the size of that buffer that it was overflowed with the stack buffer overflow. So, I was thinking like, okay, so maybe this issue is presented in other vendors. They are having the same problem because it's pretty easy to, you know, to have that mistake. And indeed, many vendors were having the same issue. So, basically what I was doing is using the same proof of concept that I created for this ID Tech reader. I was testing it with other vendors. Most of them they were crashing as well. Some of them were stack buffer flow. Some other were heap buffer flow because we were dealing sometimes with bare metal finger like this one. But also sometimes they were real-time operating systems or Android systems or even Linux systems. So, one of the vendors affected this in Genico or in Genico, I don't know how to pronounce that in English, but basically it's a very famous vendor in the world for payment devices and payment applications. And I have another video here to show you. So, basically, since sometimes it's hard to get access to these devices, actually in a production environment where it works and you can perform a transaction and everything, what I did in this case, I have a friend in Spain where he owns a shop and he has these devices. So, he allowed me to test it, the proof of concept. So, basically, as you can see here, it was the device was charging me for 39 euros. And then as soon as I tap my phone, you can see Reboot in progress. So, basically, in this case, it was rebooting because in this case it's a Linux system. So, the issues in a particular library. So, the operating system was detecting the crash and rebooting, but my proof of concept was just crashing it. It wasn't weaponizing this case. So, yeah. And I was doing this with another device and another reader and all of them were crashing. Like, every device was crashing like this. Okay. So, very fun as well. Several very fun devices affected. I was testing them and crashing. Sorry, I forgot to mention that my approach was also like once I found that the device was crashing, then I was trying to get to buy one and get debug capabilities or log access so I can see if it's a stack buffer or flow or heap buffer or flow and then contact the vendor, of course. So, very fun as well. As I was saying, crime payment innovations as well as several devices from them that were affected. BB POST, this is a very big company as well where they have everywhere readers and there were several of these devices were affected. We CC, in this case, a Chinese company, but they have devices everywhere in the world. Several of their devices were affected. And next goal in this case as well, another Chinese vendor, but again, you can find these devices everywhere. Okay, so let's talk about the impact. Like, what the attacker can actually do with these attacks, right? Once the finger of the device is compromised. So, well, it's always up to the imagination of the attacker, but at least in my imagination, I have these approaches. So, the very first one is to remember, we have code execution in the microcontroller of the reader through the NFC, the contactless interface. We have full control so we can install our malware here. So, what we can do is typically in a transaction, as you saw in the other video, is that the host, the Windows computer in this case sends the start transaction command over USB to this guy and the price for the transaction. But my malware in this case that is running here because this device has been already compromised, can change that price instead of $500 for 50 cents, you know? But even the receipt, and if the device has a display, in this case, this device doesn't have a display, but other devices have a display, you can put the $500, but in the end, in the background, it's charging you for 50 cents. And since you can make this persistent, then every future transaction will be 50 cents if you want or one cent or whatever you want to make it. So, that would be one possible attack that the attackers could do with this. Another thing that the attacker could do is in the US, especially, there is something called contactless magnetic stripe data transactions where the full number of the credit card and the expiration date is sent in clear text to the reader, so that would be in clear text in the memory of the NFC reader in this case. So, what my malware could do in this device is to, once the device is compromised, then every future credit card that will be using that type of contactless transaction, the magnetic stripe data transaction, my malware will do is it will store those credit card numbers in the memory or in the flash. And then if the device has internet connection, then send those credit card numbers to my server on the internet. But also, if the device doesn't have internet connection, what the attacker could do is then after a few days or hours, come back to the reader, send an special command to the malware that is actually running in the NFC reader and exfiltrate those credit card numbers over the NFC interface. So, now I have here a demo of a weaponized exploit. So, in this case, it's an Android device. But as you can see, I can't show you some parts of the graphical interface because I can show the name of the bank and some other details. But you will see the pop-up without the blurry image. But basically, this is an Android device in this case. And the weaponized exploit that we will do to prove that color execution is possible in this case and manipulate the firmware is going to show a message on the screen as you will see. So, first, we're using a regular credit card. I don't know why there's no sound, but you should hear, like, how the receipt is, you know, giving me that receipt, but I don't know, sorry, but the sound is not working. But yeah. And after that, then the device is ready for another transaction, and I'm going to use the proof of account set, the weaponized exploit in this case. And then you will see, basically, the exploit will change the screen with an active logo and, like, saying, hey, this device has been compromised, blah, blah, you know. Just to... There you go. So, that will be... Okay. And the last thing, which is probably the most interesting one, is that, like, okay, now the malware that is installed in this microcontroller, what if we can attack the host that is connected over USB? And in this case, it could be the Windows computer that is in the ATM, because, remember, we have a USB cable that is connected to the host machine, okay? So, to do that, what I did was, in the case of the ID-Tech device, ID-Tech, they provide their live ID-Tech SDK to their customers so they can interact with the device and perform transactions. So, what I wanted to do is, you know, reverse-ending this SDK and see if they have issues so we can compromise the host over USB. So, basically, the idea here is that the SDK in the Windows computer will send the command over USB to the reader, and my malware that is already there in the... In the... In the firmware of the reader will send as a response a particular payload that allows me to get code execution in the... In the Windows computer. So, for that, the SDK provides several APIs. And in this case, when I was getting familiar with those APIs, I focused in the device init API because this particular one is always used because it's the one that is used to initialize the device before doing another transaction. So, I was sure there that this one is... It was an important one. So, yeah, I started to reverse-engineer this API in the DLL of the SDK. And I found in the code of the API where the function where it's... It receives the USB payload from the reader. And in this case, as you can see here, there was this mem copy where the size of the mem copy are two bytes that are coming from the USB payload from the reader. So, we can control the size of the mem copy with two bytes. And there were no sanity checks at all. And the source of the mem copy was the actual USB payload that it was receiving from the NFC reader. So, we... I just needed to make sure that the destination buffer, it wasn't too big. So, I was able to overflow it. So, in this case, the buffer in this case was pretty small. It was 56 hex bytes. And I was able to overflow the buffer, but also the other local variables in the stack and then override the saved return others in the stack and, you know, a straightforward stack buffer of flow to get code execution in the host. So, again, so, in this case, we have to change to attacks, right? So, we have first to compromise the finger of the reader through the NFC as we saw. And then we inject that malware in the finger. And then that malware that is running the NFC reader will receive a USB command from the Windows computer. And then my malware will send a specific payload to achieve code execution through that mem copy that we saw in the code of the library. So, to create a proof of concept of this, what I did was instead of creating my own malware and doing it with the NFC reader, which takes some reasonable time, I just... To make it quick, I use a Raspberry Pi with the gadget FS, which allows me to emulate any USB device. So, this Raspberry Pi was acting as the NFC reader. So, yeah, with the gadget FS, I was able to provide the endpoint information and the ID vendor, the product of the USB device. So, in this case, I was emulating the NFC reader as a USB device. And with Python, you can also send over USB whatever you want and receive whatever the... In this case, the SDK running in the host is sending you. And this is actual... This is actually the proof of concept that was triggering the stack buffer overflow. And as you can see here in the Windows computer, in this case, with WinDBug, you can see how it was actually crashing with that mem copy issue. The return address, as you can see here, is 414141, so it's basically my payload. So, yeah. So, this is the way I found a code execution in the SDK that IDTech provides to their customers to communicate with the device. And remember that... So, this SDK from IDTech is present in some ATMs in this case, because it's the SDK that they provide to communicate with the NFC reader. So, also, this SDK is pretty vulnerable. They have more than 20 exploitable stack buffer flows, like the one I described that we don't have time to talk about all of them, but yeah, it was pretty bad. Okay, so let's talk about the ATM scenario. So, like I said, I have many years of experience working with ATM. With ATMs, I've been reverse engineering ATMs drivers. Also, the ATM devices finger, like for instance, the cash dispenser and other devices. Also, doing some USB hacking with ATMs. And also, I have experience working with XFS. XFS is the middle world that most of the ATMs in the world, they used to communicate with the hardware of the ATM, like for instance, the cash dispenser. And using some particular APAs, you can interact with the hardware and perform, for instance, a cash out. And again, remember that this particular reader, the IDTech KOS 3, is present in most of the ATM brands in the world, the most important brands, like some of them NCR, Wincor, Diable, Fujitsu, Hayasu, and maybe more. At least I was able to confirm those some years ago. So, what the attacker can do in the ATM in this particular case? So, one of the first things, like before, is like, especially in the US in this case, if the car supports MSD, magnetic straight data, contactless transactions, then the clear text, the full number of the credit card will be in the clear text and the expiration date, in the memory of the device. So, the attacker could do is compromise the firmware of the reader first over NFC, like we saw, and install the malware. And then, since in the ATMs, these devices doesn't have internet connection, what the attacker would need is to leave the area, then come back after a few hours or days or whatever, and then exfiltrate those credit card numbers from the memory of the device, using the malware that he already installed, like sending a special command to the malware, for instance, and then the malware will send you back to your phone the credit card numbers that have been used in the reader in those days. But then we also have the ATM jack-of-all scenario. So, the idea here is like, once we have our malware running in the NFC reader, microcontroller, we want to, as we saw before, like, compromise the ATM computer. If it's running the IDTech SDK, we know it's possible. If it's running another driver for whatever reason, then you need to, of course, to find if the driver that is using is vulnerable, there's any memory corruption, and then exploit that. And then, once you have code execution in the ATM computer, then you need, as you will see, a special payload or a program, in this case, to interact with the hardware of the ATM, like the cash dispenser, in this case, to perform the cash out, the jackpot. So, yeah, one important thing also to take into account here is that we don't only, if we're working with an ATM, in this case, we are not only limited to the driver or SDK that is used for the NFC reader, because since we have full control of the microcontroller of the reader, we can modify the firmware to act as another USB device. Let's say I want to act as a USB camera, and I know that there is a USB camera driver in the Windows ATM computer, and it's vulnerable, so I want to target that and attack that, so that would be another possible approach. So, then, once you have code execution in the ATM computer, through the SDK or other driver, there are, like, if you guys, someone has experience working with ATMs, you probably know that once you have full control of the ATM computer, without mean rights, in this case, because normally it's Windows, there's just a matter of time to be able to perform the jackpot, because the way they are designed, it's impossible to make this impossible, basically. Of course, sometimes they put some mitigations, like, as we'll see, if you're using XFS, maybe there's some sort of authentication, making sure that your application can't use those XFS APIs and so on. But in the end, it's always, you know, a matter of time to find a way to do it, because the way it's designed, it's impossible to make it 100% secure. So, this XFS, as I was saying before, it's a middleware that is basically in every ATM, that it provides several APIs that you can use to interact with the hardware of the ATM. So, in this case, here, as you can see in example, this is one of my XFS programs that I use many times in ATMs to, you know, perform the cash out. In this case, for instance, as an example, you can see here, we are using the WFS open API to open a session with the device. In this case, the device is the cash dispenser. And then we provide several details, like the number of bills, the number of the cassette, and some other details. And then we use, after these other APIs, like, to execute the actual command and then perform the cash out. So, as this point, you might be wondering, okay, so did you try this with an ATM? So, yes, I tried. It was working, but it was in a lab environment, and there are some NDS involved, so I can't show you videos about it, and I also can't tell you which ATM brand was this particular one. But if you have doubts or concerns about this, I think you hear you have enough technical details so you can do it by yourself if you have the motivation. But also, if you have specifically concerns about this, because you are working an ATM security team or whatever, my recommendation here is that first make sure that the finger of this reader in the ATM is already patched, because there are available patches for these issues. And also check, make sure that the driver or SDK that is using the ATM computer doesn't have any memory corruptions. But the most important thing, obviously, is to make sure that the finger of this reader is already patched, because if the attacker can't compromise this over NFC, then more or less the problem is solved, right? Like, it's going to be really hard to compromise the ATM in this way. So, regarding this closure, so, yeah, we contacted all these affected vendors, as you saw, there were many. All of them told us that they fixed the issues. Some of them, they provided us the fixes, and we tested that, and we were able to confirm that the fix was okay. But not all of them provided us these fixes, so we don't know for some others what happened. And, yeah, in this case we waited almost two years, because this research, I mean, started almost two years ago, because the problem was that, as you saw, many parties were involved here, and the problem is like, since I was testing my proof of concept with another device, oh, this vendor is also vulnerable. Shit, again, another, another. So, you know, we had to wait time, but also the problem is that many of these devices, they don't have remote update capabilities. So, sometimes they have to go physically there to, you know, to update the, the finger of these breeders, which is a problem, right? So, so, yeah, that's a, that's a problem. So, so, yeah, I think that's everything. If you have any questions, I'll be around. Thank you.