Good. So, welcome to Clark. We will be hearing Sehesta Hain, 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 will be hearing about, in Soviet Russia, smart card hacks you.

Looking forward to the talk, answer 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 Wiesbaden,

or formerly Mines member, and come to 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. It's fabulous. Thank you for all the help us. Smart cards 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 searching 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 smart card hacking,

most of the attacks focus on the smart card, 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

helped 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

to this because a friend of mine has to use a certain smart card 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 helped to illustrate some concepts. That's why I present them here.

What are smart cards or where are they used? Most of the few probably know them from EC cards, from your credit card. The younger generation may be more from the SIM cards they use in their mobile phone. Sometimes for the older generation here, you use them

in the pay phone. In Germany, we also use them for health care, and another use case for smart cards 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 smart card. And 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 smart card, they need to capture both. And that's harder, so the whole setup is considered to be more secure. And I looked mostly at this login scenario, and

an interesting part of this login process is that it completely runs as root. So if you find bugs there, you can instantly log in as root instead of just one single user for which you maybe have captured a password. And there's a certain interesting psychological

element to it as well. The programmers for the smart cards, they also see this secure device, this trustworthy device, and they trust it as well when passing the responses. So they tend to make mistakes they maybe might not make when programming, for example,

network drivers. And yeah, why not abuse that? In order to do so, we have to understand the whole smart card stack, what layers are there, what parts are there to the whole communication. And we will now go through each of these layers, and I'll give you a few words to this.

In general, you have a tamper-proof device. The vendors who build those smart cards try to ensure that all the secrets that are stored in the microchip on the smart card remain there. And in the past, most attacks were like trying to glitch the smart card or trick it somehow into revealing the secrets that

are stored on the smart card. And you have some pins that power on the chip in the smart card and have an IO pin to communicate. And for this communication, you need a certain protocol that the smart card and the computer understand.

And this protocol consists of APDUs. It's basically small packets or small commands you send to the smart card. The first byte is a class byte that specifies whether the command is from the standard or whether it's vendor-specific. The ins byte, 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 smart card 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 smart card 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 some errors that encode, something went wrong, I can't give you more information. And others tell you, okay, you tried to log in and you failed and you have one try left to do so.

On top of this, you need an abstraction layer for the smart card reader. And this is PCSC, that's an API you can use to send those APDs to the smart card. 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 smart card, and the other one is the buffer with the data that you retrieve from the smart card.

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 smart cards anymore, but about cryptographic tokens. And you can use a smart card there, you can use

a soft token, and this one is also standardized, your browser uses it, OpenSSL uses it, wire another abstraction layer, and it's also quite generic. And if you write a driver for a

smart card, you can use the PCSC interface to talk to the smart card. Each smart card, when inserted, sends a certain command string, an answer to reset, and this

encodes some basic information about the smart card, how to talk to it, but also some historic bytes, which you can use to see which vendor the smart card belongs to, or what kind of smart cards it is. And the driver uses this information to know whether the driver is

responsible to handle the smart card, or is able to handle a certain smart card. How does the lock-in process usually work? Usually you have something like PEN that your

graphical console uses, or your shell lock-in uses to handle certain ways to do authorization, and the PEN library first tries to enumerate all the certificates on the smart card. And if one of the certificates matches a certain user that is allowed to log in on the system,

the revocation check is performed to see if the certificate is really still valid or if it's maybe revoked by the CA. If the certificate is valid and the user that matches it is allowed to log in on the system, the computer generates a noun that's a number only used once,

and is usually a random bit string, and the smart card is asked to generate a signature for this noun. If the smart card was able to do this, we know that the smart card contains the private

key matching the certificate. And if that's the case, the user is allowed to log in. Let's start with the proprietary driver I looked at a bit. In Spain there is a national ID card, they have a smart card 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 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 binaries they ship, it's a library, it's not really hardened, or as you can see there are no canneries, so it's technology from like 10 years ago.

The library uses two open source libraries as well. One is a crypto library that has known vulnerabilities. I'm not sure if any of them really matter for the use case, but at least they did not bother to create an update. The other one is an ASN1 parser,

and from the size of those two additional libraries you see there's a lot of attack surface in the driver, right? There's a lot the driver does to do its work. At least for the open source crowd, I guess it's interesting that they don't have a copyright notice explaining that they use open source. I toyed around a bit with it. I didn't do

extensive fuzzing or something, but just tried some easy things. For example, sometimes the driver asks 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 sounds serious, but I guess there might be a case 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 work with, right? So the next thing I tried was to say, okay, I have

255 bytes for you, and did it in an endless loop, and whenever 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 seemed 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 9000 response code that everything worked and is fine, you can, at least for this driver, generate a 9-point ID reference and a crash. Not really interesting, but it shows where things can go wrong, right?

Yeah, 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 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 or 30 people where everybody has two different smart cards and want to do a new release and want

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 do a change log entry that is security-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.

What happens here? It's a while loop that continues to loop until the card signals that it no longer has additional data left. And as long as the card sends data, the data is copied into

a buffer by the memcpy. 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 them into heap. One of the issues I think are interesting in the OpenSC stack is in the Cryptoflex tool. They have a fixed size buffer of 2048 bytes, and they use a 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 five 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 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 the nicest case. Another vendor is UbiCode. They also

generate or they ship or sell small devices where you have a smart card, and the smart card reader basically combines, 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 memcpy of the retrieved data into the buffer, the caller 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 PAM 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 we trigger the error message. That's now the error message. The output buffer is small. And I keep continue to write stuff.

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 the wild?

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 this 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 can say or can have every driver accept your card, which is not the case with all the smart cards. 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 APDUs. In this case, in the upper case, if you have a class byte of C0 and an instruction

byte of A4, the my select file function is called. And there I can pass the parameters and also generate a response if I want to. This is the select file where I 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 smart card driver, it's available for you.

How do you find bugs in 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 bogus data to a driver until it scratches.

And most helper tools for that are file-oriented. 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 SCAR transmit wrapper actually tells you how much data the receiving end the driver wants to read.

So what I did was simply 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 programmed a library that you can preload on Linux or on Windows

and have the smart card driver interact with your code 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'll try to help you. Yeah, this is what the AFL looks like when you do fuzzing. I had run it for, yeah, I think 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 takes like 10 commands or so before the interesting stuff happens, like the enumeration

of certificates, right? So I was kind of quite surprised that it got that far. And yeah, on the lower case, there are several things that have zero coverage. But in this case, these are PKCS15 functions which 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,

basically found its way to be able to fasten 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 wrap 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

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 do 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? That's 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 or 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 says, 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 as a good two-factor model. But never really thought about this increase of tech service that happens when you deploy smart card authentication.

It's a bit similar with antivirus, right? Antivirus helps you for your security. But if your antivirus has a bug, that's also quite serious. If you use OpenSC, there is a config option that you can use to

blacklist or whitelist drivers. So you only run the driver that you actually use in your setup. And this would greatly reduce your tech service. And the Yubico guys did the right thing. They

write the new 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 is 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 bit weird, but maybe try such a thing with a 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 fuzzes 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. And for those of you leaving, please leave quietly so that we do the Q&A. There is another question from 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 released a 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. So come to me later and we can talk. And there's a question from 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 seems still secure? That's not what I looked at. I'm not a hardware guy. There were people in the past, the talk of Karsten Knoll at one of the camps was quite good about where he talks about decapping the chip and adding probes.

But I'm a software guy, sorry. Question from 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 the 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 from microphone number one, two. But if you have a second question and didn't get time to ask it before,

there's time enough to stand up behind the microphone and ask it again. Microphone number two. Thank you very much for the talk. One question you showed that the vulnerabilities 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 well they aren't. On Windows sometimes it's quite hard to actually get access to 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 out behind the microphones if you have more questions. Question from microphone number one. Regarding this RFID cards, I'm just thinking there are some applications where you can use a NFC controller in your Android phone to simulate an NFC card. 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, so you want to trigger as many

code paths as quickly as possible. And how do you interface it? So I guess you can do that. I think the basic card guys also sell a contactless version. I don't have it, but I guess the attack surface with this is quite huge. You could think about

attacking the firmware on your mobile phone via a bed sim card, maybe to unlock it. 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.