In Soviet Russia Smart Card Hacks You
Sesterhenn, Eric
The classic spy movie hacking sequence: The spy inserts a magic smart card provided by the agency technicians into the enemy's computer, … the screen unlocks … What we all laughed about is possible!
 Good. So welcome to clock. We will be hearing a big round of applause. Thank you. Yeah. She already introduced me. My name is Eric. I'm a long time Vise or formerly minds 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 involved and it's so nice being here each year. So it's fabulous. Thank you for all the helpers. 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 real current topic and if you have if you are thirsty for more information go through 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 project 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 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 help 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 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 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 lock 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. 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 the password. 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 parsing 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 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. Right 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 I.O. 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 in spite 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 you send the pin to the 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 9000 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 other save for or encode that there's yeah some errors that encode something went wrong I can't give you more information and others tell you okay you try 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 for the smart card reader and this is PCSC that's an API you can use to send those APD use to the smart card there there are some some more functions that allow you to query the reader whether 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 like you have 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 smart card you usually implement this interface and use the PCSC interface to talk to the smart card and each of each smart card when inserted sends a certain command string and then answer to reset and this encoders some basic information about the smart card how to talk to it but also some historic bytes where you can which you can use to see which vendor the smart card belongs to or what kind of smart card it is and the driver uses this information to know whether the driver is responsible to handle the smart card was able to handle a certain smart card how does the lock-in process usually work usually you have something like PEM that your gd that your your graphical console uses or your shell lock-in uses to handle certain ways to do authorization and the PEM library first tries to animate 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 of it's maybe revoked by the by the CA if the certificate is valid and the user that matches matches it is allowed to log in on the system the computer generates a nonce that's a number only used once and it's usually a random bit string and a smart card is asked to generate a signature for this nonce 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 and 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 yeah he complained by the 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 ship it's 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 no 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 as in one puzzle 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 and yeah 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 so yeah I toyed around a bit with it I didn't do extensor fuzzing or something but just tried some some easy things for example sometimes the the driver asked for a response and tries to retrieve data from the card and what happens if the card answers with some 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 who do work with right so the next thing I tried was some say okay I have 255 bytes for you and did it in an endless loop and whenever the the card the driver requests more data I gave them another 252 bytes of bogus shit at a certain point it just crashed because the 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 nipointer 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 the OpenS C1 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 some project has existed for 20 years or something like that so some of the code is quite old as well for OpenS C 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 the want to do a new release and want to do the QAA for the for the new release it's it's a lot of work to coordinate all this yeah Apple Apple was quite interesting when I notified them about to bug they silently patched it as far as I understand the code is not used in in the current current machines they are shipping apparently it was used in the past and yeah I had to ask them again to to um yeah at least to change the entry that it's securely related and I try to query them if it's actually in use somewhere or not but I didn't get a response out of them and what happens here it's a while loop that continues to loop until the the card signals that it no longer has additional data left and as long as the cards and data the status copied into a buffer by the mem copy so um as and yeah the the whole trust the the developer who wrote that um he put a lot of trust in the smart card to stop sending when it's done and basically trusted with what it does but the card can just continue to um say hey I still have more um more data for the certificate and do a heap overflow in this case and corrupt them into heap another one of the the issues I I think are interesting and the OpenSC stack is in the crypto flex tool they have a fixed size buffer of 2048 bytes and they um using helper function the select file function to um 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 um the the file has instead of the size of the buffer so if the card says the file is um five kilobytes then the buffer will obviously overflow and um um for this I have a small demonstration the the tool is um a helper tool that's used to um for example list the keys that are on the card or um yeah for for other stuff so as you can see if you try to read the key from the card the the um the memory gets corrupt and it's possible to execute arbitrary code it's not a not a scenario that you would think somebody would exploit in the wild but um yeah it's a nice case um another um vendor is cubico they also um generate or um they they ship or sell small devices where you have a smart card and the smart card reader basically combines or they have a nice form factor of a new speed stick and one of their drivers they they have this code um that's a helper function for all the times where data is retrieved from the smart card and um they also do a mem copy of the retrieved data into the the buffer the the caller supplies and um as you can clearly see they 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 um yeah the the fix is obviously easy um but uh yeah those are mistakes that commonly happen during programming right and um I hope the second proof of concept is uh you can read most of it um this is now for for the classical linux login um we don't care about username um as soon as uh PEM starts to query the the smart card the the driver gets active and copies data and um I have the the debug um output on and um also slowed it down a bit to help me while doing all this and um after a while you see that uh we trigger the the error message that's now the error message the output buffer is small and um I keep continue to write stuff and at the end um I also get a code execution and the nice thing is if you can read it um I'm rude since the whole login runs is rude how do you exploit this in white um the the easy way would be to um um to um yeah use custom hardware that allows you to interact with the smart card reader and everything but um this would also require you to have maybe some wires that leave the the reader which would be fine for the linux login but if you think about atm's or something that might not work or access control systems so um what I used um this basic card um yes you have to write in basic but um you can do all the smart card stuff that you want to do and um the most important thing is that you can fully customize the the rtr so um basically you can um can say or can have every driver accept your card which is not the case with all smart cards um used um yeah just um on the lower part you declare the historical bytes of the atr um in this case for the for the op-ed c driver and you also declare the the functions um that uh are the the apd use um in this case if you have a in a uppercase if you have a class byte of c zero and an instruction byte of a4 the my select file function is called and there can pass the parameters and also generate a response as i want to um this is the select file where i can um where pass which file the driver wants to select and um select my in this case static response automatically um the code is um of course kind of silly for for this um for this command but um if you want to see how it works and how to interact with a smart card reader or a smart card driver um it's available for you um how do you find bugs in smart card drivers one one way is to um do manual source code auditing that's part of what i did um the other part was fuzzing um in a very yeah easy way fuzzing is like sending lots of lots of bogus data to driver until it's gracious and um if most helper tools for that are file oriented right they are not um designed to work with protocols where you send several packets um to a card and get a response and send another packet so you have the challenge of um converting the the file input the fuzzer generates to something that looks like protocol data and here the nice thing is that a scard transmit uh wrapper actually tells you how much data the the receiving end the the driver wants to read so what i did was um simply get uh always fill this buffer to the end with um with data from a file and um since it's uh you don't since it's not network oriented you don't need to take care of polling or something similar you can just copy the buffer and um that's what it looks like for for OpenSCE I generated um virtual reader and this virtual reader interacts with the fuzzer so um i used AFL for fuzzing um which also does code coverage to see whether an input file is interesting or not and um yeah that that's what I um ran most of the time to find bugs in the OpenSCE project um I also tried to uh another tried I um did I um 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 uh of the instead of the real reader and um you can also use this to um fuzz uh yeah more or less arbitrary smart card drivers um but not enough um last year somebody Tavis ported parts of windows defender the antivirus to linux and um basically he tried to get um the code you 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 fuzz um the faster you can fuzz certain code um the more likely you are to find bugs because you can just try more more random data and um I have beaten this library um enough to be able to load um windows drivers or windows smart card drivers on linux for fuzzing um there are some exceptions if you have a.NET driver um it will not work um because it depends on lots of additional other libraries but um 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 um if something does not work just uh send me an email I try to help you um yeah this is what the AFI looks like when you do fuzzing I had run it for um yeah I think in total 28 days or something and um was able to shake a lot of bugs out of OpenSC but um when you look at the coverage report um the coverage is 30 percent which I think is not too shabby um when you think about that the um the answers have to be correct for a lot of different um requests right at the beginning the the smart card driver usually tries to verify that the card is really something um he is allowed to interact with tries to open some files and um reads them and it um all um it takes like 10 commands or so before the interesting slide happens like um the the the animation of certificates right so I was kind of quite surprised that it got that far and um yeah on the lower case there are several things that um have zero coverage but in this case these are pkcs15 functions which I didn't touch at all some of them are um drivers that are not um enabled by default in OpenSC but on the lower end um for for some of the the drivers the the code coverage was um quite high I was actually quite surprised that um 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 fast a lot of different and reach a lot of different functions so um it's not only the drivers that are interesting um in the so set up but also the the helper or the upper layers for example the the PEM functions the PEM modules um one of them that you can use to log in with a smart card is PEM pkcs11 and um the the whole process looks quite similar but it differs in one point um and that's where the nonce is generated when you generate a nonce you want good randomness because if um an attacker is able to replay a nonce or wrap a nonce and um um the 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 um yeah he needed a lot of good entropy so he had this small security module that is able to generate an 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 um do the signature so if an attacker controls a computer that the victim logs into um the attacker gets the nonce and a signature for this nonce and then can um yeah modify his own smart card to replay this at another machine right so um 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 um if you need an information leak for exploitation for example this is um not easy to do you don't have uh interaction because you have no keyboard on the smart card or no display but um if you can get wires out of the reader, synth rays or something that you can use um there's a firmware that allows you to not only um do a man in the middle on the communication but um send whatever you like but the advantage you have is that you don't need um necessarily to do um full code execution in the end you just need to flip the the few bytes of memory that say okay this user is locked in so that's um an advantage for the attacker. What I learned from um all this is um I um always advocated smart cards as a good thing and um always thought of it of a good two factor model but um never really thought about um this increase of attack surface that happens when you deploy smart card authentication. Um it's a bit similar with antivirus right antivirus helps you for your security but um yeah if your antivirus has a bug um that's also quite serious um if you use OpenSC there's um there's a config option that you can use to blacklist um drive or whitelist drivers so you only run the driver that you actually use in your setup and this would greatly reduce your attack surface and um yeah the ubq guys um did the right thing they they um write the newer drivers in python instead of c and there you don't have all those um memory corruption bugs that um lead to code execution so if you have the possibility to do that go for it um yeah thanks you um if you have any questions and uh yeah I don't use twitter um the only social network somebody tricked me into using a slinkton 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 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 fuzzers the reader of the door um as far as I know for the connected smart cards the the whole protocol is similar but I didn't play around with that um I'm I'm too old-fashioned to use a wireless technology if I can avoid it so it's okay good and for those of you leaving please leave quietly so that we do the q and a there is another question for microphone number one uh 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 um yeah I think the the the sim trace stuff is what you want to do I um have not tried the firmware they just released the second version of it um I guess that's what I would go for um uh friend is um also thinking about doing a custom PCB um yeah I guess there are a lot of options um or maybe even we have a couple of more questions waiting so uh come come to me later and we can talk and there's a question for microphone number two uh yes uh your talk is mostly about malicious cards attacking a compromised reader uh 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 um that's what I looked at um I'm not a hardware guy um there were people in the past um the the talk of uh kastanol at um uh at one of the camps was quite good about where he talks about um decapping the chip and adding probes to yeah but I was off again 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 um you have a lot of weird data that the cards send to the driver in some cases it's um as in one encoded sometimes it's um sometimes the vendor does proprietary whatever and um all this passing is um I guess where a lot of problems happen we have a second question uh for microphone number one of 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 and thank you very much for the talk one question you showed that the vulnerability is in the driver well that means that every pc which allows smart card authentication even if you don't use it is vulnerable to a root lock in why is this vulnerability no usually you have to install the drivers um on linux they are not installed by default on um windows as well they aren't um on windows sometimes it's quite hard to actually get access to drivers because the the vendors are very often keeping them only for selling customers and stuff like that it's I don't know why they do that but um it seems like a business model for them yeah but usually the the stuff is not installed by default you have to actually enable it at least on 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 uh another thing is um regarding this rf ad cards I'm just thinking there are some applications where you can use an nfc controller in your android phone simulate an nfc card so 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 rf ad cards what do you think this would be a good approach um I didn't do the the fuzzing from the basic card the basic card was only used to exploit it because um when when doing fuzzing you want to do a lot of iterations so you want to do uh trigger as many code paths as quickly as possible so um you I guess you can do that um I I think the the basic card guys also sell um um uh contactless version um I don't have it so but yeah I guess the the tech service um with this is quite huge you can could think about um 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
 Good. So welcome to clock. We will be hearing a  big round of applause. Thank you.  Yeah. She already introduced me. My name is  Eric. I'm a long time Vise or formerly minds 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  involved and it's so nice being here each year. So it's fabulous. Thank you for all the helpers.  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 real  current topic and if you have if you are thirsty for more information go through 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 project  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 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 help  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 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 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 lock 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. 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 the password. 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 parsing 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 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.  Right 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 I.O. 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 in spite 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 you send the pin to the 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 9000 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  other save for or encode that there's yeah some errors that encode something went wrong I can't  give you more information and others tell you okay you try 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 for the smart card reader  and this is PCSC that's an API you can use to send those APD use to the smart card  there there are some some more functions that allow you to query the reader whether  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 like you have 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 smart card you usually  implement this interface and use the PCSC interface to talk to the smart card  and each of each smart card when inserted sends a certain command string and then answer to reset  and this encoders some basic information about the smart card how to talk to it but also some  historic bytes where you can which you can use to see which vendor the smart card belongs to  or what kind of smart card it is and the driver uses this information to know whether the driver is  responsible to handle the smart card was able to handle a certain smart card how does the  lock-in process usually work usually you have something like PEM that your gd that your your  graphical console uses or your shell lock-in uses to handle certain ways to do authorization  and the PEM library first tries to animate 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 of it's maybe revoked by the  by the CA if the certificate is valid and the user that matches matches it is allowed to log  in on the system the computer generates a nonce that's a number only used once and it's usually  a random bit string and a smart card is asked to generate a signature for this nonce 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  and 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  yeah he complained by the 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 ship it's  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  no 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 as in one puzzle 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 and yeah 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 so  yeah I toyed around a bit with it I didn't do extensor fuzzing or something but just tried some  some easy things for example sometimes the the driver asked for a response and tries to retrieve  data from the card and what happens if the card answers with some 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 who do  work with right so the next thing I tried was some say okay I have 255 bytes for you and did it  in an endless loop and whenever the the card the driver requests more data I gave them another  252 bytes of bogus shit at a certain point it just crashed because the 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 nipointer 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 the OpenS C1 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 some project has existed for 20 years or something like that  so some of the code is quite old as well for OpenS C 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 the want to do a new release and want to do the QAA for the for the new release  it's it's a lot of work to coordinate all this  yeah Apple Apple was quite interesting when I notified them about to bug they silently patched  it as far as I understand the code is not used in in the current current machines they are shipping  apparently it was used in the past and yeah I had to ask them again to to  um yeah at least to change the entry that it's securely related and I try to query them if it's  actually in use somewhere or not but I didn't get a response out of them and what happens here  it's a while loop that continues to loop until the the card signals that it no longer has additional  data left and as long as the cards and data the status copied into a buffer by the mem copy so um  as and yeah the the whole trust the the developer who wrote that um he put a lot of trust in the  smart card to stop sending when it's done and basically trusted with what it does but the card  can just continue to um say hey I still have more um more data for the certificate and do a  heap overflow in this case and corrupt them into heap another one of the the issues I I think  are interesting and the OpenSC stack is in the crypto flex tool they have a fixed size buffer of  2048 bytes and they um using helper function the select file function to um 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 um the the file has instead of the size of the buffer  so if the card says the file is um five kilobytes then the buffer will obviously overflow and um  um for this I have a small demonstration  the the tool is um a helper tool that's used to um for example list the keys that are on the card or  um yeah for for other stuff so as you can see if you try to read the key from the card the  the um the memory gets corrupt and it's possible to execute arbitrary code it's not a not a  scenario that you would think somebody would exploit in the wild but um yeah it's a nice  case um another um vendor is cubico they also um generate or um they they ship or sell small devices  where you have a smart card and the smart card reader basically combines or they have a nice form  factor of a new speed stick and one of their drivers they they have this code um that's a helper  function for all the times where data is retrieved from the smart card and um they also do a mem  copy of the retrieved data into the the buffer the the caller supplies and um as you can clearly  see they 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 um yeah the the fix is obviously easy um but uh yeah those are mistakes that  commonly happen during programming right and um I hope the second proof of concept is uh  you can read most of it um this is now for for the classical linux login um we don't care about  username um as soon as uh PEM starts to query the the smart card the the driver gets active and  copies data and um I have the the debug um output on and um also slowed it down a bit to help me  while doing all this and um after a while you see that uh we trigger the the error message  that's now the error message the output buffer is small and um I keep continue to write stuff  and at the end um I also get a code execution and the nice thing is if you can read it um I'm  rude since the whole login runs is rude  how do you exploit this in white um the the easy way would be to um um to um yeah use custom  hardware that allows you to interact with the smart card reader and everything but um this would  also require you to have maybe some wires that leave the the reader which would be fine for the  linux login but if you think about atm's or something that might not work or access control  systems so um what I used um this basic card um yes you have to write in basic but um you can do  all the smart card stuff that you want to do and um the most important thing is that you can  fully customize the the rtr so um basically you can um can say or can have every driver accept your  card which is not the case with all smart cards um used um yeah just um on the lower part you  declare the historical bytes of the atr um in this case for the for the op-ed c driver  and you also declare the the functions um that uh are the the apd use um in this case if you have a  in a uppercase if you have a class byte of c zero and an instruction byte of a4 the my select  file function is called and there can pass the parameters and also generate a response as i want  to um this is the select file where i can um where pass which file the driver wants to select  and um select my in this case static response automatically um the code is um of course kind  of silly for for this um for this command but um if you want to see how it works and how to interact  with a smart card reader or a smart card driver um it's available for you um how do you find  bugs in smart card drivers one one way is to um do manual source code auditing that's part of what  i did um the other part was fuzzing um in a very yeah easy way fuzzing is like sending lots of lots  of bogus data to driver until it's gracious and um if most helper tools for that are file oriented  right they are not um designed to work with protocols where you send several packets um to a  card and get a response and send another packet so you have the challenge of um converting the  the file input the fuzzer generates to something that looks like protocol data and here the nice  thing is that a scard transmit uh wrapper actually tells you how much data the the receiving end  the the driver wants to read so what i did was um simply get uh always fill this buffer to the end  with um with data from a file and um since it's uh you don't since it's not network oriented you  don't need to take care of polling or something similar you can just copy the buffer and um that's  what it looks like for for OpenSCE I generated um virtual reader and this virtual reader interacts  with the fuzzer so um i used AFL for fuzzing um which also does code coverage to see whether an  input file is interesting or not and um yeah that that's what I um ran most of the time to  find bugs in the OpenSCE project um I also tried to uh another tried I um did I um 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 uh of the instead of the real reader and um you can also  use this to um fuzz uh yeah more or less arbitrary smart card drivers um but not enough um last year  somebody Tavis ported parts of windows defender the antivirus to linux and um basically he tried to  get um the code you 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  fuzz um the faster you can fuzz certain code um the more likely you are to find bugs because you  can just try more more random data and um I have beaten this library um enough to be able to load  um windows drivers or windows smart card drivers on linux for fuzzing um there are some exceptions  if you have a.NET driver um it will not work um because it depends on lots of additional other  libraries but um 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 um if something does not work just  uh send me an email I try to help you um yeah this is what the AFI looks like when you do fuzzing  I had run it for um yeah I think in total 28 days or something and um was able to  shake a lot of bugs out of OpenSC but um when you look at the coverage report um the coverage is  30 percent which I think is not too shabby um when you think about that the um the answers  have to be correct for a lot of different um requests right at the beginning the the smart  card driver usually tries to verify that the card is really something um he is allowed to  interact with tries to open some files and um reads them and it um all um it takes like 10  commands or so before the interesting slide happens like um the the the animation of certificates  right so I was kind of quite surprised that it got that far and um yeah on the lower case there  are several things that um have zero coverage but in this case these are pkcs15 functions which I  didn't touch at all some of them are um drivers that are not um enabled by default in OpenSC  but on the lower end um for for some of the the drivers the the code coverage was um quite high  I was actually quite surprised that um 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 fast a lot of different and reach a lot of different functions  so um it's not only the drivers that are interesting um in the so set up but also the the  helper or the upper layers for example the the PEM functions the PEM modules um one of them  that you can use to log in with a smart card is PEM pkcs11 and um the the whole process looks quite  similar but it differs in one point um and that's where the nonce is generated when you generate  a nonce you want good randomness because if um an attacker is able to replay a nonce or wrap a nonce  and um um the 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 um yeah he needed a lot of good entropy so  he had this small security module that is able to generate an 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 um  do the signature so if an attacker controls a computer that the victim logs into um the attacker  gets the nonce and a signature for this nonce and then can um yeah modify his own smart card to  replay this at another machine right so um 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 um if you need an information leak for  exploitation for example this is um not easy to do you don't have uh interaction because you have no  keyboard on the smart card or no display but um if you can get wires out of the reader,  synth rays or something that you can use um there's a firmware that allows you to not only um do a  man in the middle on the communication but um send whatever you like but the advantage you have is  that you don't need um necessarily to do um full code execution in the end you just need to flip  the the few bytes of memory that say okay this user is locked in so that's um an advantage for the  attacker. What I learned from um all this is um I um always advocated smart cards as a good thing  and um always thought of it of a good two factor model but um never really thought about um this  increase of attack surface that happens when you deploy smart card authentication. Um it's a bit  similar with antivirus right antivirus helps you for your security but um yeah if your antivirus  has a bug um that's also quite serious um if you use OpenSC there's um there's a config option that  you can use to blacklist um drive or whitelist drivers so you only run the driver that you  actually use in your setup and this would greatly reduce your attack surface and um yeah the ubq  guys um did the right thing they they um write the newer drivers in python instead of c and there  you don't have all those um memory corruption bugs that um lead to code execution so if you  have the possibility to do that go for it um yeah thanks you um if you have any questions  and uh yeah I don't use twitter um the only social network somebody tricked me into using  a slinkton 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 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 fuzzers  the reader of the door um as far as I know for the connected smart cards the the whole protocol  is similar but I didn't play around with that um I'm I'm too old-fashioned to use a wireless  technology if I can avoid it so it's okay good and for those of you leaving please leave quietly  so that we do the q and a there is another question for microphone number one uh 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 um yeah I think the the the sim trace  stuff is what you want to do I um have not tried the firmware they just released the second version  of it um I guess that's what I would go for um uh friend is um also thinking about doing a custom  PCB um yeah I guess there are a lot of options um or maybe even we have a couple of more questions  waiting so uh come come to me later and we can talk and there's a question for microphone number two  uh yes uh your talk is mostly about malicious cards attacking a compromised reader uh 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 um that's what I looked at um I'm not a hardware guy um there were people in the  past um the the talk of uh kastanol at um uh at one of the camps was quite good about where he talks  about um decapping the chip and adding probes to yeah but I was off again 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 um  you have a lot of weird data that the cards send to the driver in some cases it's um as in one encoded  sometimes it's um sometimes the vendor does proprietary whatever and um all this passing is um  I guess where a lot of problems happen we have a second question uh for microphone number one of  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 and thank you very much for  the talk one question you showed that the vulnerability is in the driver well that means that every  pc which allows smart card authentication even if you don't use it is vulnerable to a root lock in  why is this vulnerability no usually you have to install the drivers um on linux they are not  installed by default on um windows as well they aren't um on windows sometimes it's quite hard to  actually get access to drivers because the the vendors are very often keeping them only for  selling customers and stuff like that it's I don't know why they do that but um it seems like a  business model for them yeah but usually the the stuff is not installed by default you have to  actually enable it at least on 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 uh another thing is um regarding this rf ad cards I'm just  thinking there are some applications where you can use an nfc controller in your android phone  simulate an nfc card so 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 rf ad cards what do you think this  would be a good approach um I didn't do the the fuzzing from the basic card the basic card was  only used to exploit it because um when when doing fuzzing you want to do a lot of iterations so you  want to do uh trigger as many code paths as quickly as possible so um you I guess you can do that um  I I think the the basic card guys also sell um um uh contactless version um I don't have it so but  yeah I guess the the tech service um with this is quite huge you can could think about um 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
35c3-9346-in_soviet_russia_smart_card_hacks_you_0_59.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_60_215.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_216_587.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_588_983.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_984_1355.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_1356_1487.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_1488_4991.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_4992_5387.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_5388_5543.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_5544_5783.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_5784_5831.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_5832_5939.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_5940_9815.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_9816_24803.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_24804_27119.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_27120_29915.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_29916_30419.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_30420_30935.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_30936_30983.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_30984_31079.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_31080_31175.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_31176_37931.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_37932_39419.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_39420_42311.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_42312_46667.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_46668_47891.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_47892_48527.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_48528_49223.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_49224_49523.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_49524_49631.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_49632_50063.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_50064_50651.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_50652_50891.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_50892_50963.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_50964_51011.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_51012_51191.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_51192_51695.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_51696_51767.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_51768_52283.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_52284_52343.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_52344_52559.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_52560_52679.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_52680_52763.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_52764_52811.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_52812_53171.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_53172_53795.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_53796_53939.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_53940_54107.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_54108_54623.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_54624_55367.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_55368_55931.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_55932_56411.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_56412_56543.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_56544_56843.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_56844_57251.png 35c3-9346-in_soviet_russia_smart_card_hacks_you_57252_57389.png
Good. So welcome to clock. We will be hearing a big round of applause. Thank you. Yeah. She already introduced me. My name is Eric. I'm a long time Vise or formerly minds 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 involved and it's so nice being here each year. So it's fabulous. Thank you for all the helpers. 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 real current topic and if you have if you are thirsty for more information go through 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 project 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 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 help 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 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 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 lock 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. 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 the password. 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 parsing 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 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. Right 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 I.O. 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 in spite 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 you send the pin to the 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 9000 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 other save for or encode that there's yeah some errors that encode something went wrong I can't give you more information and others tell you okay you try 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 for the smart card reader and this is PCSC that's an API you can use to send those APD use to the smart card there there are some some more functions that allow you to query the reader whether 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 like you have 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 smart card you usually implement this interface and use the PCSC interface to talk to the smart card and each of each smart card when inserted sends a certain command string and then answer to reset and this encoders some basic information about the smart card how to talk to it but also some historic bytes where you can which you can use to see which vendor the smart card belongs to or what kind of smart card it is and the driver uses this information to know whether the driver is responsible to handle the smart card was able to handle a certain smart card how does the lock-in process usually work usually you have something like PEM that your gd that your your graphical console uses or your shell lock-in uses to handle certain ways to do authorization and the PEM library first tries to animate 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 of it's maybe revoked by the by the CA if the certificate is valid and the user that matches matches it is allowed to log in on the system the computer generates a nonce that's a number only used once and it's usually a random bit string and a smart card is asked to generate a signature for this nonce 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 and 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 yeah he complained by the 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 ship it's 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 no 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 as in one puzzle 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 and yeah 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 so yeah I toyed around a bit with it I didn't do extensor fuzzing or something but just tried some some easy things for example sometimes the the driver asked for a response and tries to retrieve data from the card and what happens if the card answers with some 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 who do work with right so the next thing I tried was some say okay I have 255 bytes for you and did it in an endless loop and whenever the the card the driver requests more data I gave them another 252 bytes of bogus shit at a certain point it just crashed because the 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 nipointer 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 the OpenS C1 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 some project has existed for 20 years or something like that so some of the code is quite old as well for OpenS C 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 the want to do a new release and want to do the QAA for the for the new release it's it's a lot of work to coordinate all this yeah Apple Apple was quite interesting when I notified them about to bug they silently patched it as far as I understand the code is not used in in the current current machines they are shipping apparently it was used in the past and yeah I had to ask them again to to um yeah at least to change the entry that it's securely related and I try to query them if it's actually in use somewhere or not but I didn't get a response out of them and what happens here it's a while loop that continues to loop until the the card signals that it no longer has additional data left and as long as the cards and data the status copied into a buffer by the mem copy so um as and yeah the the whole trust the the developer who wrote that um he put a lot of trust in the smart card to stop sending when it's done and basically trusted with what it does but the card can just continue to um say hey I still have more um more data for the certificate and do a heap overflow in this case and corrupt them into heap another one of the the issues I I think are interesting and the OpenSC stack is in the crypto flex tool they have a fixed size buffer of 2048 bytes and they um using helper function the select file function to um 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 um the the file has instead of the size of the buffer so if the card says the file is um five kilobytes then the buffer will obviously overflow and um um for this I have a small demonstration the the tool is um a helper tool that's used to um for example list the keys that are on the card or um yeah for for other stuff so as you can see if you try to read the key from the card the the um the memory gets corrupt and it's possible to execute arbitrary code it's not a not a scenario that you would think somebody would exploit in the wild but um yeah it's a nice case um another um vendor is cubico they also um generate or um they they ship or sell small devices where you have a smart card and the smart card reader basically combines or they have a nice form factor of a new speed stick and one of their drivers they they have this code um that's a helper function for all the times where data is retrieved from the smart card and um they also do a mem copy of the retrieved data into the the buffer the the caller supplies and um as you can clearly see they 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 um yeah the the fix is obviously easy um but uh yeah those are mistakes that commonly happen during programming right and um I hope the second proof of concept is uh you can read most of it um this is now for for the classical linux login um we don't care about username um as soon as uh PEM starts to query the the smart card the the driver gets active and copies data and um I have the the debug um output on and um also slowed it down a bit to help me while doing all this and um after a while you see that uh we trigger the the error message that's now the error message the output buffer is small and um I keep continue to write stuff and at the end um I also get a code execution and the nice thing is if you can read it um I'm rude since the whole login runs is rude how do you exploit this in white um the the easy way would be to um um to um yeah use custom hardware that allows you to interact with the smart card reader and everything but um this would also require you to have maybe some wires that leave the the reader which would be fine for the linux login but if you think about atm's or something that might not work or access control systems so um what I used um this basic card um yes you have to write in basic but um you can do all the smart card stuff that you want to do and um the most important thing is that you can fully customize the the rtr so um basically you can um can say or can have every driver accept your card which is not the case with all smart cards um used um yeah just um on the lower part you declare the historical bytes of the atr um in this case for the for the op-ed c driver and you also declare the the functions um that uh are the the apd use um in this case if you have a in a uppercase if you have a class byte of c zero and an instruction byte of a4 the my select file function is called and there can pass the parameters and also generate a response as i want to um this is the select file where i can um where pass which file the driver wants to select and um select my in this case static response automatically um the code is um of course kind of silly for for this um for this command but um if you want to see how it works and how to interact with a smart card reader or a smart card driver um it's available for you um how do you find bugs in smart card drivers one one way is to um do manual source code auditing that's part of what i did um the other part was fuzzing um in a very yeah easy way fuzzing is like sending lots of lots of bogus data to driver until it's gracious and um if most helper tools for that are file oriented right they are not um designed to work with protocols where you send several packets um to a card and get a response and send another packet so you have the challenge of um converting the the file input the fuzzer generates to something that looks like protocol data and here the nice thing is that a scard transmit uh wrapper actually tells you how much data the the receiving end the the driver wants to read so what i did was um simply get uh always fill this buffer to the end with um with data from a file and um since it's uh you don't since it's not network oriented you don't need to take care of polling or something similar you can just copy the buffer and um that's what it looks like for for OpenSCE I generated um virtual reader and this virtual reader interacts with the fuzzer so um i used AFL for fuzzing um which also does code coverage to see whether an input file is interesting or not and um yeah that that's what I um ran most of the time to find bugs in the OpenSCE project um I also tried to uh another tried I um did I um 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 uh of the instead of the real reader and um you can also use this to um fuzz uh yeah more or less arbitrary smart card drivers um but not enough um last year somebody Tavis ported parts of windows defender the antivirus to linux and um basically he tried to get um the code you 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 fuzz um the faster you can fuzz certain code um the more likely you are to find bugs because you can just try more more random data and um I have beaten this library um enough to be able to load um windows drivers or windows smart card drivers on linux for fuzzing um there are some exceptions if you have a.NET driver um it will not work um because it depends on lots of additional other libraries but um 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 um if something does not work just uh send me an email I try to help you um yeah this is what the AFI looks like when you do fuzzing I had run it for um yeah I think in total 28 days or something and um was able to shake a lot of bugs out of OpenSC but um when you look at the coverage report um the coverage is 30 percent which I think is not too shabby um when you think about that the um the answers have to be correct for a lot of different um requests right at the beginning the the smart card driver usually tries to verify that the card is really something um he is allowed to interact with tries to open some files and um reads them and it um all um it takes like 10 commands or so before the interesting slide happens like um the the the animation of certificates right so I was kind of quite surprised that it got that far and um yeah on the lower case there are several things that um have zero coverage but in this case these are pkcs15 functions which I didn't touch at all some of them are um drivers that are not um enabled by default in OpenSC but on the lower end um for for some of the the drivers the the code coverage was um quite high I was actually quite surprised that um 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 fast a lot of different and reach a lot of different functions so um it's not only the drivers that are interesting um in the so set up but also the the helper or the upper layers for example the the PEM functions the PEM modules um one of them that you can use to log in with a smart card is PEM pkcs11 and um the the whole process looks quite similar but it differs in one point um and that's where the nonce is generated when you generate a nonce you want good randomness because if um an attacker is able to replay a nonce or wrap a nonce and um um the 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 um yeah he needed a lot of good entropy so he had this small security module that is able to generate an 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 um do the signature so if an attacker controls a computer that the victim logs into um the attacker gets the nonce and a signature for this nonce and then can um yeah modify his own smart card to replay this at another machine right so um 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 um if you need an information leak for exploitation for example this is um not easy to do you don't have uh interaction because you have no keyboard on the smart card or no display but um if you can get wires out of the reader, synth rays or something that you can use um there's a firmware that allows you to not only um do a man in the middle on the communication but um send whatever you like but the advantage you have is that you don't need um necessarily to do um full code execution in the end you just need to flip the the few bytes of memory that say okay this user is locked in so that's um an advantage for the attacker. What I learned from um all this is um I um always advocated smart cards as a good thing and um always thought of it of a good two factor model but um never really thought about um this increase of attack surface that happens when you deploy smart card authentication. Um it's a bit similar with antivirus right antivirus helps you for your security but um yeah if your antivirus has a bug um that's also quite serious um if you use OpenSC there's um there's a config option that you can use to blacklist um drive or whitelist drivers so you only run the driver that you actually use in your setup and this would greatly reduce your attack surface and um yeah the ubq guys um did the right thing they they um write the newer drivers in python instead of c and there you don't have all those um memory corruption bugs that um lead to code execution so if you have the possibility to do that go for it um yeah thanks you um if you have any questions and uh yeah I don't use twitter um the only social network somebody tricked me into using a slinkton 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 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 fuzzers the reader of the door um as far as I know for the connected smart cards the the whole protocol is similar but I didn't play around with that um I'm I'm too old-fashioned to use a wireless technology if I can avoid it so it's okay good and for those of you leaving please leave quietly so that we do the q and a there is another question for microphone number one uh 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 um yeah I think the the the sim trace stuff is what you want to do I um have not tried the firmware they just released the second version of it um I guess that's what I would go for um uh friend is um also thinking about doing a custom PCB um yeah I guess there are a lot of options um or maybe even we have a couple of more questions waiting so uh come come to me later and we can talk and there's a question for microphone number two uh yes uh your talk is mostly about malicious cards attacking a compromised reader uh 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 um that's what I looked at um I'm not a hardware guy um there were people in the past um the the talk of uh kastanol at um uh at one of the camps was quite good about where he talks about um decapping the chip and adding probes to yeah but I was off again 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 um you have a lot of weird data that the cards send to the driver in some cases it's um as in one encoded sometimes it's um sometimes the vendor does proprietary whatever and um all this passing is um I guess where a lot of problems happen we have a second question uh for microphone number one of 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 and thank you very much for the talk one question you showed that the vulnerability is in the driver well that means that every pc which allows smart card authentication even if you don't use it is vulnerable to a root lock in why is this vulnerability no usually you have to install the drivers um on linux they are not installed by default on um windows as well they aren't um on windows sometimes it's quite hard to actually get access to drivers because the the vendors are very often keeping them only for selling customers and stuff like that it's I don't know why they do that but um it seems like a business model for them yeah but usually the the stuff is not installed by default you have to actually enable it at least on 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 uh another thing is um regarding this rf ad cards I'm just thinking there are some applications where you can use an nfc controller in your android phone simulate an nfc card so 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 rf ad cards what do you think this would be a good approach um I didn't do the the fuzzing from the basic card the basic card was only used to exploit it because um when when doing fuzzing you want to do a lot of iterations so you want to do uh trigger as many code paths as quickly as possible so um you I guess you can do that um I I think the the basic card guys also sell um um uh contactless version um I don't have it so but yeah I guess the the tech service um with this is quite huge you can could think about um 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
at the history of smart card hacking most of the status copied into a buffer by the mem copy so um into the the buffer the the caller supplies and attacker. What I learned from um all this is um I microphones for questions and we have about five