 Good. So, welcome to Clark. We will be hearing Sehestahin, who has been working as an IT consultant for more than 15 years, mostly in source code auditing and penetration testing. Already this year, he has spoken at Nulcon, Defcon, and the climax of the year must definitely be here at the CCC. We'll be hearing about in Soviet Russia, Smartcard hacks you. Looking forward to the talk and to your questions later. Give him a big round of applause. Thank you. Yeah, she already introduced me. My name is Eric. I'm a long time CCC v-spardon or formerly Mainz member and come to a congress since a while. I have to confess this is the first time I'm scared and nervous. So, yeah, and it's wonderful how all the CCC congress thing grew all the years and evolved and it's so nice being here each year. So, it's fabulous. Thank you for all the helpers. Smartcards have been a topic at congress since even before 19 C3, but before then there are no recordings and also the early ones you might not really want to watch them. But it's a reoccurring topic and if you are thirsty for more information, go to the media recordings. Some of the talks are very interesting and very good. When you look at the history of Smartcard hacking, most of the attacks focus on the Smartcard and this talk is about the different approach. So, the issues I'm presenting have been fixed. I reported them to the proper projects and help them to close the issues and I mostly looked at open source projects because I think if you are a proprietary vendor and make money by selling software, you should also pay somebody to have the software secured. There's one exception. There's one exception through this because friend of mine has to use a certain Smartcard driver, so I had a quick peek at it, but in the few evenings I didn't find any serious security issues, but some crashes, but those help to illustrate some concepts. That's why I present them here. What are Smartcards or where are they used? Most of the few probably know them from EC cards, from your credit card. The younger generation maybe more from the SIM cards you use on your mobile phone. Sometimes for the older generation here, you use them in the pay phone. In Germany, we also use them for healthcare. Another use case for Smartcards is authentication. So, you use them as a second factor. If you log into your Linux system, you use a password and you use a Smartcard. The password somebody can steal from you if they look over your shoulder or if they have a key locker installed, but if you have the second factor, the Smartcard, they need to capture both. That's harder, so the whole setup is considered to be more secure. I looked mostly at this lock-in scenario. An interesting part of this lock-in process is that it completely runs as root. If you find bugs there, you can instantly log in as root instead of just one single user for which you maybe have captured the password. There's a certain interesting psychological element to it. The programmers for the Smartcards, they also see this secure device, this trustworthy device, and they trust it. When parsing the responses, they tend to make mistakes they maybe might not make when programming, for example, network drivers. Yeah, why not abuse that? In order to do so, we have to understand the whole Smartcard stack, what layers are there, what parts are there to the whole communication. We will now go through each of these layers. I give you a few words to this. In general, you have a tamper-proof device. The vendors who build those Smartcards try to ensure that all the secrets that are stored in the microchip on the Smartcard remain there. In the past, most attacks were like trying to glitch the Smartcard or trick it somehow into revealing the secrets that are stored on the Smartcard. You have some pins that power on the chip in the Smartcard and have an IO pin to communicate. For this communication, you need a certain protocol that the Smartcard and the computer understand. This protocol consists of APDUs. It's basically small packets or small commands you send to the Smartcard. The first byte is a class byte that specifies whether the command is from a standard or whether it's vendor-specific. The inspite, that's the instruction, basically encodes the, yeah, says, okay, this is the following command. For example, if you have hex 20, that's a verify command. You send the pin to the Smartcard and tell it, okay, this is my pin. Please unlock yourself. You have two parameters where you can specify additional information and can also send further data. The Smartcard then answers those commands with a blob of data, usually. And at the end of the data, there are two bytes telling the computer whether this command executed successfully, that's 9,000, or if there occurred a certain error. And one of the responses that's interesting, for example, is 6.1, because it says, okay, I have sent you something, but I still have more bytes to you. Others say or encode that there are, yeah, some errors that encode something went wrong. I can't give you more information. And others tell you, okay, you try to login and you failed and you have one try left to do so. On top of this, you need an abstraction layer for the Smartcard reader. And this is PCSC, that's an API you can use to send those APD use to the Smartcard. There are some more functions that allow you to query the reader, whether a card is inserted or get notified if a card is removed. But the most interesting for me was the transmit function, where you basically pass two buffers, two lengths, and one buffer is the one with the data that is sent to the Smartcard and the other one is the buffer with the data that you retrieve from the Smartcard. And the nice thing is this abstraction layer is the same on Windows and on Linux. On top of that, you usually have another abstraction layer that doesn't talk about Smartcards anymore, but about cryptographic tokens. And you can use a Smartcard there, you can use a soft token. And this one is also like standardized, your browser uses it, open SSL uses it, wire another abstraction layer, and it's also quite generic. And if you write a driver for Smartcard, you usually implement this interface and use the PCSC interface to talk to the Smartcard. And each Smartcard, when inserted, sends a certain command string and answers the reset. And this encodes some basic information about the Smartcard, how to talk to it, but also some historic bytes where you can, which you can use to see which vendor the Smartcard belongs to or what kind of Smartcard it is. And the driver uses this information to know whether the driver is responsible to handle the Smartcard or is able to handle a certain Smartcard. How does the lock-in process usually work? Usually you have something like PEM that your graphic console uses or your shell lock-in uses to handle certain ways to do authorization. And the PEM library first tries to enumerate all the certificates on the Smartcard. And if one of the certificates matches a certain user that is allowed to lock in on the system, the revocation check is performed to see if the certificate is really still valid of it, maybe revoked by the CA. If the certificate is valid and the user that matches it is allowed to lock in on the system, the computer generates a notice that's a number only used once and is usually a random bit string and a Smartcard is asked to generate a signature for this nonce. If the Smartcard is able to do this, we know that the Smartcard contains the private key matching the certificate. And if that's the case, the user is allowed to lock in. Let's start with the proprietary driver I looked at a bit. In Spain, there is a national ID card and they have a Smartcard chip on this as well. And as far as I understood, my friend, they are forced to use this for certain actions. I'm not sure what legal issues there are, where you have to use it, but yeah, he complained quite a lot that he's forced to use it. So I took a quick look. The stuff was released at least for Linux like 10 years ago. So the binary stays shipped, it's a library, it's not really hardened or as you can see, there are no canneries. So yeah, it's technology from like 10 years ago. The library uses two open source libraries as well. One is the Crypto library that has known vulnerabilities. I'm not sure if any of them really matter for the use case, but yeah, at least they did not bother to create an update. The other one is an S and one parser. And from the size of those two additional libraries, you see there's a lot of a tax office in the driver, right? There's a lot of driver dust to do its work. And yeah, at least for the open source crowd, I guess it's interesting that they don't have copyright notice explaining that they use open source. So yeah. I toyed around a bit with it. I didn't do extensor fuzzing or something, but just tried some easy things. For example, sometimes the driver asked for a response and tries to retrieve data from the card. And what happens if the card answers with, yeah, I have more data for you. Please request another zero bytes from me. The driver will happily do that. And so you can create an endless loop where you play this ping-pong all the time, right? It's not serious, but I guess there might be cases where you could do a denial of service by just inserting a smart card that always replies with, I have zero more data for you and just keep the device busy, right? But usually when doing security, denial of service is not interesting. So you try to give the system some bytes to do work with, right? So the next thing I tried was some say, okay, I have 255 bytes for you and did this in an endless loop. And whenever the card, the driver requests more data, I gave them another 252 bytes of bogus shit. At a certain point it just crashed because it tried to allocate a buffer that was too big. But that was, yeah, nothing that seems to be exploitable. But in other cases it might have been, right? Another issue there is if you reply, hey, this command worked and you don't send any data but signal with the 9,000 response code that everything worked and is fine. You can, at least for this driver, generate a nine-pointer dereference and a crash. Not really interesting, but it shows where things can go wrong, right? There's a lot of other issues I found where things don't go the way they should. None of them seem to be exploitable. That's why I'm easy about talking here without having the vendor notified. But yeah, it shows that in, if you look a bit at proprietary software they seem to have similar issues. But my main focus was on open source software. These are the different drivers I looked at. The OpenSC one stands out a bit, but that's because they support a whole range of smart cards. They have drivers for a lot of different smart cards, so the attack surface is quite huge. And I think the project exists for 20 years or something like that. So some of the code is quite old as well. For OpenSC, I have to thank Frank Morgner for doing all the coordination and fixing and everything because with this wide range of smart cards you can imagine that there's not one single developer with a huge stack with all of the smart cards, but it's like, I don't know, 20, 30 people where everybody has two different smart cards and want to do a new release and want to do the QA for the new release. It's a lot of work to coordinate all this. Yeah, Apple was quite interesting when I notified them about the bug, they silently patched it. As far as I understand the code is not used in the current machines they are shipping. Apparently it was used in the past. And yeah, I had to ask them again to at least to change the entry that it's securely related. And I tried to query them if it's actually new somewhere or not, but I didn't get a response out of them. And what happens here? It's a Y loop that continues to loop until the card signals that it no longer has additional data left. And as long as the cards and the status copied into a buffer by the mem copy. So, and yeah, the whole trust, the developer who wrote that, he put a lot of trust in the smart card to stop sending when it's done and basically trust it with what it does. But the card can just continue to say, hey, I still have more data for the certificate and heap overflow in this case. And corrupt the heap. Another, one of the issues I think, I think is that the OpenSC stack is in the crypto flex tool. They have a fixed size buffer of 2,048 bytes. And the user helper function, the select file function to get some meta information about the file. And one information is the file size. And when they read the binary, they use the size that the card said the file has instead of the size of the buffer. So if the card says the file is 5 kilobytes, then the buffer will obviously overflow. And for this, I have a small demonstration. The tool is a helper tool that's used to, for example, list the keys that are on the card or, yeah, for other stuff. So as you can see, if you try to read the key from the card, the memory gets corrupt and it's possible to execute arbitrary code. It's not a scenario that you would think somebody would exploit in the wild. But yeah, it's a nice case. Another vendor is Ubicode. They also generate or they ship or sell small devices where you have a smart card and a smart card reader basically combined so they have a nice form factor of a USB stick. And one of their drivers, they have this code that's a helper function for all the times where data is retrieved from the smart card. And they also do a mem copy of the retrieved data into the buffer, the color supplies. And as you can clearly see, they have a check whether the data already received is bigger than the size of the buffer. And if that's the case, they print a nice error message and continue to copy the data into the buffer, right? So, yeah, the fix is obviously easy. But yeah, those are mistakes that commonly happen during programming, right? And I hope the second proof of concept is, you can read most of it. This is now for the classical Linux login. We don't care about username. As soon as PEM starts to query the smart card, the driver gets active and copies data. And I have the debug output on and also slowed it down a bit to help me while doing all this. And after a while, you see that, you see that the error message, that's now the error message, the output buffer is small. And I keep continue to write stuff. And at the end, I also get a code execution. And the nice thing is, if you can read it, I'm rude since the whole login runs as rude. How do you exploit this in white? The easy way would be to use custom hardware that allows you to interact with the smart card reader and everything. But this would also require you to have maybe some wires that leave the reader, which would be fine for the Linux login. But if you think about ATMs or something that might not work or access control systems, so what I used is basic card. Yes, you have to write in basic, but you can do all the smart card stuff that you want to do. And the most important thing is that you can fully customize the RTR. So basically, you can say or can have every driver accept your card, which is not the case with all the smart cards. Used, yeah, just some things. On the lower part, you declare the historical bytes of the ATR. In this case, for the OpenSC driver. And you also declare the functions that are the APD use. In this case, if you have a uppercase, if you have a class byte of C0 and an instruction byte of A4, the MySelectFile function is called. And there can pass the parameter and also generate the response as I want to. This is the Select file where I can, where pass which file the driver wants to select and select my, in this case, static response automatically. The code is, of course, kind of silly for this command. But if you want to see how it works and how to interact with a smart card reader or a smart card driver, it's available for you. How do you find Buxen smart card drivers? One way is to do manual source code auditing. That's part of what I did. The other part was fuzzing. In a very easy way, fuzzing is like sending lots of, lots of bogus data to driver until it's gracious. And if most helper tools for that are file oriented, right, they are not designed to work with protocols where you send several packets to a card and get a response and send another packet. So you have the challenge of converting the file input, the fuzzer generates to something that looks like protocol data. And here the nice thing is that the S card transmit wrapper actually tells you how much data the receiving end, the driver wants to read. So what I did was simply get, always fill this buffer to the end with data from a file. And since it's network oriented, you don't need to take care of polling or something similar, you can just copy the buffer. And that's what it looks like for OpenSC. I generated virtual reader and this virtual reader interacts with the fuzzer. So I used AFL for fuzzing, which also does code coverage to see whether an input file is interesting or not. And yeah, that's what I ran most of the time to find bugs in the OpenSC project. I also tried to, or another try, I did, I programmed library that you can preload on Linux or on Windows and have the smart card driver interact with your code instead of the real smart card, instead of the real reader. And you can also use this to fuzz more or less arbitrary smart card drivers. But not enough. Last year, somebody, Tavis, ported parts of Windows Defender, the antivirus to Linux. And basically, he tried to get the code he wanted to fuzz run in a very small environment so you don't have much overhead. When fuzzing, it's always nice to be able to do a lot of iterations in a short time because the faster you can fuzz certain code, the more likely you are to find bugs because you can just try more random data. And I have beaten this library enough to be able to load Windows drivers or Windows smart card drivers on Linux for fuzzing. There are some exceptions. If you have a .NET driver, it will not work because it depends on lots of additional other libraries, but everything that's plain C should work more or less. Yeah, all the fuzzers are released. You can download them, play around with them, and if something does not work, just send me an email. I try to help you. Yeah, this is what the AFA looks like when you do fuzzing. I had run it for, yeah, I think a total of 28 days or something and was able to shake a lot of bugs out of OpenSC. But when you look at the coverage report, the coverage is 30%, which I think is not too shabby when you think about that, the answers have to be correct for a lot of different requests, right? At the beginning, the smart card driver usually tries to verify that the card is really something he's allowed to interact with, tries to open some files and reads them, and it all, it takes like 10 commands or so before the interesting slide happens like the animation of certificates, right? So I was kind of quite surprised that it got that far. And here on the lower case, there are several things that have zero coverage, but in this case, these are PKCS15 functions that I didn't touch at all. Some of them are drivers that are not enabled by default in OpenSC. But on the lower end, for some of the drivers, the code coverage was quite high. I was actually quite surprised that I was able to reach it with a simple setup. I didn't hand tune the input corpus. I just drew in two sample files, and from there, it basically found its way to be able to fast a lot of different and reach a lot of different functions. So it's not only the drivers that are interesting in this whole setup, but also the helper or the upper layers, for example, the PEM functions, the PEM modules. One of them that you can use to log in with a smart card is PEM, PKCS11, and the whole process looks quite similar, but it differs in one point. And that's where the nonce is generated. When you generate a nonce, you want good randomness, because if an attacker is able to replay a nonce or rep a nonce, and this nonce and the signature is used again later, it's possible to replay this and abuse that. And what the programmer did here was, yeah, he needed a lot of good entropy, so he had this small security module that is able to generate entropy, right? So basically he asked or they asked the smart card to generate the random data, and then asked the smart card again to the signature. So if an attacker controls a computer that the victim logs into, the attacker gets a nonce and a signature for this nonce, and then can modify his own smart card to replay this at another machine, right? So yeah, that was also an interesting bug where you can see the psychology of the developer trusting the small device, but not thinking about what he does. There are some roadblocks when you want to do exploitation against the drivers. One is that the data sent to the card is usually quite small, and if you need an information leak for exploitation, for example, this is not easy to do. You don't have interaction because you have no keyboard on the smart card or no display, but if you can get wires out of the reader, Thimtrace is something that you can use. There's a firmware that allows you to not only do a man in the middle on the communication, but send whatever you like. But the advantage you have is that you don't need necessarily to do full code execution. In the end, you just need to flip the few bytes of memory that say, okay, this user is logged in. So that's an advantage for the attacker. What I learned from all this is I always advocated smart cards as a good thing and always thought of it of a good two-factor model, but never really thought about this increase of tech surface that happens when you deploy smart card authentication. It's a bit similar with antivirus, right? Antivirus helps you for your security, but yeah, if your antivirus has a bug, that's also quite serious. If you use OpenSC, there's a config option that you can use to blacklist drivers or whitelist drivers. So you only run the driver that you actually use in your setup, and this would greatly reduce your tech surface. And here at the Ubico guys did the right thing. They write the newer drivers in Python instead of C, and there you don't have all those memory corruption bugs that lead to code execution. So if you have the possibility to do that, go for it. Yeah, thank you. If you have any questions and yeah, I don't use Twitter, the only social network somebody tricked me into using a LinkedIn, so sorry for that. And we have five microphones for questions and we have about five minutes. So get up and stand behind the microphones if you have any questions. There is one microphone number one, two, four, three and five. And the exits are the two ones to the left. There is a question from microphone number one. Yes, I have a question that's maybe it's a little bit weird, but maybe try such a thing with RFID card because there are many places that have smart card readers, they have like your doors for example. You need to present a card and then maybe you have a card that fuses the reader of the door. As far as I know for the connected smart cards, the whole protocol is similar, but I didn't play around with that. I'm too old fashioned to use the wireless technology if I can avoid it. Okay, good. And for those of you leaving, please leave quietly so that we do the Q&A. There is another question for microphone number one. Maybe haven't you tried putting a simple microcontroller to do your bidding easier than a basic card? Do you know maybe a kind of framework that could be used instead of this one? Yeah, I think the SIM trace stuff is what you want to do. I have not tried the firmware, they just release the second version of it. I guess that's what I would go for. A friend is also thinking about doing a custom PCB. Yeah, I guess there are a lot of options. We have a couple of more questions waiting. Come to me later and we can talk. And there's a question for microphone number two. Yes, your talk is mostly about malicious cards attacking a compromised reader. Is there any possibility at this point to get an RSA key or anything like this out of a card or so far this SIM is still secure? That's what I looked at. I'm not a hardware guy. There were people in the past, the talk of Castanol at one of the camps was quite good about where it talks about decapping the chip and adding probes. But I'm a software guy, sorry. Question for microphone number one. Is the PKCS protocols and the PCSC software stack too complicated? And could it be replaced with something simpler? I don't think it's a software stack. The problem is that you have a lot of weird data that the cards send to the driver. In some cases it's ASN1 encoded. Sometimes it's sometimes the vendor does proprietary whatever. And all this parsing is I guess where a lot of problems happen. We have a second question for microphone number two. But if you have a second question and didn't get time to ask it before, there's time enough to stand up by on the microphone and ask it again. Microphone number two. Thank you very much for the talk. One question you showed that the vulnerability is in the driver. Would that mean that every PC which allows smart card authentication even if you don't use it is vulnerable to a root lock in by this vulnerability? No, usually you have to install the drivers. On Linux they are not installed by default on Windows as where they aren't. On Windows sometimes it's quite hard to actually get access to the drivers because the vendors are very often keeping them only for selling customers and stuff like that. I don't know why they do that, but it seems like a business model for them. But usually the stuff is not installed by default, you have to actually enable it. At least on Windows and Linux. I don't know about MacOS. We still have time for a few more questions, so please get up behind the microphones if you have more questions. Question from microphone number one. Yes, another thing is regarding this RFID cards, I'm just thinking there are some applications where you can use an NFC controller in your Android phone to simulate an NFC card. You just use the basic card to simulate the smart card. So it should be possible to use this NFC smart card emulator to do this fuzzing with RFID cards. Would you think this would be a good approach? I didn't do the fuzzing from the basic card. The basic card was only used to exploit it because when doing fuzzing you want to do a lot of iterations. You want to trigger as many code paths as quickly as possible. So I guess you can do that. I think the basic card guys also sell a contactless version. I don't have it. But yeah, I guess the text surface with this is quite huge. You can think about attacking the firmware on your mobile phone via a bad SIM card, maybe to unlock it if it's, I don't know, right? Good. Do we have any more questions? Please get up behind the microphones. Seems like we've all run out and there are no questions from the Internet either. So please give Eric a big round of applause. Thank you.