 Et une session de questions et réponses sera liée, vous pouvez soumettre vos questions sur les canaux IRC sur akind.org, un signal Angel. Éric Cesterhen a travaillé, ça fait que plus de 4 heures qu'il travaille sur des Smart Cards. Cette année il a parlé à Walkon, Defcon et sa meilleure présentation de l'année va certainement être ici au CCC. Je vous présente Éric Cesterhen qui va vous présenter une sauviette rejasse Smart Cards Hakio. Tenez de réplacement s'il vous plaît. Bon, elle m'a déjà présenté, je m'appelle Éric. Je suis un membre depuis longtemps du CCC de Vis-Baden, anciennement Vince et ça fait un moment que je viens au Congrège. Je dois vous confesser que c'est la première fois que j'ai un peu peur et c'est merveilleux la manière dont le Congrès a évolué et grandit dans les années et c'est fabuleux d'être là. Merci beaucoup. Les Smart Cards sont un thème récurrent, même avant le 19-C3. Il y a des vieux enregistrements que vous n'avez pas forcément envie de voir mais c'est vraiment un thème récurrent. Si vous avez soif d'information, allez donc sur les enregistrements sur media.cc.de. Il y a vraiment des présentations très intéressantes et très bonnes. Quand on regarde l'histoire du hacking des Smart Cards, la plupart des attaques se concentrent sur la Smart Cards et là on va parler d'une autre approche. Les problèmes que je présente ont déjà été résolus. Je les ai rapportés au projet Edoine et je les ai aidés à résoudre les problèmes. J'ai essentiellement regardé les projets Open Source parce que je pense que si vous êtes un fournisseur de service propriétaire et que vous faites de l'argent avec vos logiciels, vous devriez aussi payer les gens qui sécurisent vos logiciels. A une exception près, j'ai un ami qui doit utiliser certains drivers donc j'ai vite fait regardé. Mais en quelques soirées, je n'avais pas trouvé de problèmes sérieux de sécurité. Mais bon, pour illustrer les concepts, pourquoi je présente ici ? Pourquoi on utilise des Smart Cards ? Vous les connaissez probablement dans les cartes Rochec, les cartes de crédit, les plus jeunes, probablement les cartes SIM dans les mobiles. Des fois, c'est utiliser les plus vieux dans les téléphones à payage ou pour l'accès aux soins. Un autre cas d'usage des Smart Cards, c'est l'authentification. On peut utiliser ça comme deuxième facteur quand on se loge sur un système Linux. On utilise un mot de passe et de surcroît la Smart Cards. On peut vous voler votre mot de passe si on regarde derrière votre épaule ou qu'on vous met un keylogger. Mais si vous avez un deuxième facteur, il faut qu'il capture les deux facteurs et c'est beaucoup plus difficile. Donc on considère que c'est une configuration plus sécurisée au final. J'ai essentiellement regardé ce scénario-là, donc l'authentification. Ce qui est intéressant, c'est que toute l'authentification est exécutée en route, en super utilisateur. Donc si vous trouvez une vignabilité, vous êtes directement logé en route. Vous n'avez pas besoin de passer par le mode single user pour capturer un mot de passe ou autre. Il y a un élément psychologique assez intéressant. Les programmeurs sur Smart Cards, ils voient ces appareils sécurisés auxquels on peut faire confiance. Ils ont tendance à faire des erreurs qui ne feraient pas quand ils programment un pilote réseau ou autre chose. Autant on t'irait parti. Pour ce faire, on doit comprendre la pile Smart Cards, donc les différentes couches et quelle partie elles apportent à la communication. Donc on va donc faire un tour de toutes ces couches en quelques mots. En général, une Smart Cards, c'est un périphérique qui ne peut pas être modifié ou dans lequel on ne peut pas regarder ce qui est dedans. Ça se permet de s'assurer que les secrets qui sont à l'intérieur ne peuvent pas en être extraits. Et par le passé, la plupart des attaques sur les Smart Cards, ça a été d'essayer en général de trouver des bugs dans les Smart Cards ou d'une façon ou d'autre de faire en sorte que la Smart Cards nous donne les secrets qu'elle contient. Donc il y a des contacts qui permettent d'allumer la puce de la Smart Cards et des d'autres pins qui permettent de communiquer, de faire de l'entrée sortie. Donc bien sûr pour ça, il y a un protocole qui est utilisé par la Smart Cards pour communiquer. Ce protocole consiste d'APDU, des petits paquets, des commandes qui sont envoyées à la Smart Cards. Donc le premier octet, c'est un octet dit de close. Ça, ça dit si la commande fait partie d'un standard ou si elle est spéciale à un fournisseur donné. Ensuite, il y a un octet d'instruction. Ça, ça encote quel est la commande qui va être exécutée. Par exemple, si vous avez Varnes des Asimals, c'est une commande qui permet d'envoyer le pin, le code personnel à la Smart Cards pour la débloquer. Ensuite, il y a des paramètres qui permettent de passer une information supplémentaire et on peut aussi envoyer des données de vérification. Donc des réponses de la Smart Cards sont envoyées aussi sous forme de données et à la fin, ces réponses sont combinées entre elles pour dire à l'ordinateur si la commande est exécutée avec succès ou non. Ou s'il y a eu, par exemple, des erreurs qui sont produites. Donc, une des réponses typiques qui est intéressante, ce serait la réponse 61. Ça, ça dit, c'est ok, je vous ai envoyé quelque chose, je t'ai envoyé quelque chose, mais j'ai encore des octets à t'envoyer. Ça, c'est utilisé, par exemple, pour encoder des codes qui encodent certaines erreurs, par exemple pour dire qu'une allocation a échoué, ou pour dire qu'une vérification a essayé, par exemple, les 63C, quelque chose, disent combien des CRS pour rentrer un code PIN. Donc, on a une autre couche par-dessus ça qui s'appelle PCSC. C'est une interface programmatique qui peut être utilisée pour envoyer les appels-des-vues à la Smart Cards. Il existe d'autres... Il y a d'autres fonctions qui peuvent vous permettre de demander au lecteur s'il y a une carte insérée, de recevoir une notification s'il a la carte est enlevée. Mais pour moi, le plus intéressant, c'est les fonctionnalités de transmission de données. Donc, on passe un buffer, un tampon, un salangueur, et c'est transmis pour les données transmises à la Smart Cards, tout comme les données reçues. Donc, c'est une couche d'attraction qui tourne sous Windows, Linux, etc. Et en général, au-dessus de tout ça, on a encore une couche d'attraction qui ne parle plus de Smart Cards, mais de tokens cryptographiques, de jetons cryptographiques. Donc, on peut utiliser un jeton logiciel, une Smart Cards, et c'est également standardisé. Donc, les navigateurs utilisent ça, SSH utilisent ça. Donc, voilà, encore une couche d'attraction assez générique. Et si vous écrivez un driver pour une Smart Cards, vous allez généralement vous retrouver à implémenter cette interface-là et à utiliser PCSC pour parler à Smart Cards. Et chaque fabriquant, chaque Smart Cards, quand elle est insérée, elle envoie une chaîne de commandes, et c'est un InSphere Tourist, un ATR. Donc, ça envoie des informations sur la Smart Cards, comment communiquer, ainsi que des bits d'intérêt historique qui peuvent être utilisés afin de voir quel est le fabriquant, quel est le type de la Smart Cards en question. Et vous pouvez donc utiliser cette information afin de savoir si le driver responsable à gérer la Smart Cards est capable de gérer cette Smart Cards-là. Donc, regardons maintenant comment ça marche, le système qui permet de se... de se identifier à une Smart Cards. Donc, généralement, on a... de se identifier avec une Smart Cards. Généralement, on a PAM, qui va communiquer avec un vôtre-système de log-ings sur le graphique ou en shell, en console. Et PAM permet d'avoir différentes façons d'autoriser la connexion. PAM a des drivers, et le driver de PAM va récupérer une liste de certificats depuis la Smart Cards. Et si il y a un certificat sur la Smart Cards qui correspond à un utilisateur, PAM va valider le certificat à l'utilisateur, et ensuite va effectuer une vérification de révocation pour s'assurer que, par exemple, ce certificat n'a pas été révocé par l'autorité de certification. Si le certificat est valide et que l'utilisateur correspond à un utilisateur qui peut se connecter sur le système, l'ordinateur génère un NONSE, c'est un nombre aléatoire qui est utilisé qu'une seule fois, donc ça, c'est juste une chaîne de bits aléatoires. Et la Smart Cards, on lui demande de générer une signature pour ce NONSE. Si la carte est capable de faire ça, on sait que la Smart Cards contient la clé privée qui correspond au certificat, et si c'est le cas, l'utilisateur est autorisé à se connecter. Alors, commençons par un système propriétaire donc en Espagne, on a des cartes de l'identité nationale, et elles ont une Smart Card dessus. Et si j'ai bien compris, mon ami, ils sont obligés d'utiliser ces cartes pour certaines choses. Alors je ne suis pas sûr des problèmes légaux autour et qu'ils peuvent conduire quelqu'un à l'utiliser, mais en tout cas, mon ami se plaint beaucoup qu'il doit utiliser cette carte pour diverses choses. Ce qui a été publié, il y a eu des choses publiées pour Linux il y a une dizaine d'années. Le code binaire qui est envoyé, c'est une bibliothèque. Ce n'est pas très compliqué, comme vous pouvez voir. Il n'y a pas de canaries. Donc, c'est une technologie d'il y a dix ans. Donc la bibliothèque utilise deux bibliothèques comme une source, une bibliothèque de cryptographie, cryptopépée, avec des unités connues. Je ne sais pas du tout si ces vulnérabilités sont applicables en l'espace, mais ils ne se sont pas embêtés à publier de mises à jour. Donc ils utilisent aussi un parceur ASN1. Vu la taille de ces bibliothèques, vous pouvez voir qu'il y a énormément de textes dans ce pilote. Il y a beaucoup de poussières. C'est donc intéressant qu'ils utilisent des bibliothèques open source, c'est qu'aucune mention ne se fait dans leur licence, aucun copyright. Donc j'ai joué à faire du fuzzing, essayer d'obtenir des réponses. Par exemple, le pilote demande une réponse à la carte et récupère la carte. Et ce qui se passe des fois, c'est que la carte répond. Oui, j'ai encore des données, demandez-moi encore 0 octet. Donc on recommence. Et voilà, on peut créer une boucle sans fin comme ça, où on fait du ping-pong entre la carte et le lecteur. Donc ce n'est pas très sérieux, mais ça peut être un cas de déni de service en insérant une SmartCart qui renvoie à la carte. J'ai 0 données en plus pour toi et voilà, on part en ping-pong. Mais en général, quand on fait du déni de service, c'est pas intéressant pour la sécurité. On essaie de donner des octets au système et voir ce qui se passe. Donc j'essaie de dire, voilà, j'ai 255 octets pour toi et puis dans une boucle sans fin et à chaque fois que le pilote s'occupe plus de données, je continue à lui donner 255 octets de caca. Et au bout d'un moment, ça a planté parce qu'il a essayé d'allouer un tampon qui était trop grand. Mais c'était rien qui semblait exploitable. Mais bon, c'est pas un comportement juste. Un autre problème, si on répond, hey, la commande fonctionne et que t'en vas pas te donner, mais que tu signales avec un que de réponse 90 000, que tout va bien, tu peux dans ce driver, en tout cas, générer une des références de pointer nul et faire crasher le driver. C'est pas très intéressant, mais ça montre où on peut se planter dans ce genre de choses. Donc il y a beaucoup d'autres problèmes que j'ai trouvés où les choses se passent pas comme ils devraient. Rien qui semblait exploitable. C'est pas très utile d'en parler ici sans notifier les vendeurs. C'est pas facile d'en parler. Mais oui, il semble qu'il y a des problèmes similaires chez d'autres vendeurs. Je me suis essentiellement concentré sur les logiciels open source. J'ai regardé différents drivers et on peut voir que OpenSC se sépare du lot mais c'est parce qu'ils supportent énormément de modèles différents de SmartCard. La surface d'attaque est vraiment énorme et je pense que ce projet existe depuis à peu près 20 ans. Donc il y a une partie du code qui est quand même assez vieux. Je tiens à remercier Frank Morgner qui a fait toute la coordination et toute la résolution des problèmes qu'on a trouvés pour OpenSC. Vous imaginez bien qu'avec le nombre de SmartCards qui supportent OpenSC ce n'est pas un seul développeur qui prend le contrôle de tout. C'est peut-être 20, 30, je ne sais pas, personne. Chaque personne a peut-être 2 SmartCards de modèles différents. Quand on veut faire une nouvelle version d'OpenSC, il faut avant pouvoir vérifier que cette version marche et c'est énormément de travail de coordonner tout ça. Et Apple, c'est intéressant chez Apple, parce que quand je leur ai envoyé notification à propos d'un de leurs bugs, ils ont corrigé le bug silencieusement. Pour autant que je sache, ce code n'est pas utilisé dans les machines qu'ils vendent à leur actuel. C'était utilisé par le passé et donc j'ai dû leur demander à nouveau au moins mettre quelque chose dans le change log pour dire qu'il y avait un patch de sécurité. Et j'ai essayé de leur demander si c'était utilisé quelque part, mais ils m'ont pas répondu. Alors, qu'est-ce qui se passe ici ? Donc c'est une boucle de while qui va s'exécuter jusqu'à ce que la carte retourne à qu'elle n'a plus de données restantes. Et tant que la carte continue à envoyer des données, ces données sont copiées dans un buffer avec même copie. Et toute la confiance ici que le développeur a mis dans le système, il a mis énormément de confiance dans cette smartcard. Et il est parti au principe que la carte fera toujours ce qu'elle doit faire et qu'elle aura toujours des valeurs conditions. Mais ce que faut faire la carte à la plate, c'est toujours de dire non mais j'ai d'autres données, j'ai plus de données maintenant dans mon certificat et ça se permettrait par exemple de corrompre le tas en mémoire. Alors un autre problème qu'on a trouvé qui est intéressant, que j'ai trouvé intéressant, c'est dans OpenSC, dans un outil qui s'appelle CryptoFlex. Ici on a un buffer de type fix de 2048 octaves et ils utilisent ici une fonction qui s'appelle Select File pour aller chercher quelques métadonnées à propos d'un fichier. Et une des informations c'est la taille du fichier. Et quand il lise les données du fichier, il utilise cette taille qui a été fournie par la taille, mais il lissa dans un buffer d'une taille donnée. Donc si le fichier fait 5 kHz, le buffer va y avoir un overflow du buffer. Et pour ça on peut vous montrer une petite démonstration. Donc c'est un outil qui est utilisé par exemple pour lisser les clés d'une carte faire des calculs de maths et d'autres choses. Comme vous pouvez voir, quand vous essayez de lire une clé sur la carte on a une corruption de mémoire et c'est possible d'exécuter du code de manière arbitraire. Donc c'est pas un scénario que vous vouliez penser que quelqu'un s'amuse à exploiter de sito, mais pourquoi pas. Donc Ubiko, un autre fournisseur génère aussi, enfin, des petits appareils dans lesquels vous avez une smartcard et le lecteur donc combiné donc c'est tout petit sur le forme d'une clé USB. Et dans un de leurs pilotes il y a ce code, une fonction utilitaire donc à chaque fois qui récupère des données de la carte ils font aussi une même copie de la donnée récupérée dans un tampon fourni par la plan et vous pouvez clairement voir ici il vérifie si la donnée est déjà reçue et plus grande que la taille du tampon et si c'est le cas il affiche un joli message d'erreur et continue à copier la donnée dans le tampon. Donc voilà donc c'est évident c'est simple à corriger mais bon c'est des problèmes assez communs dans la programmation du coup j'espère donc voilà un deuxième proof of concept donc vous pouvez lire j'espère que vous arrivez à lire donc c'est un login sous Linux classique on se fiche du nom d'utilisateur dès que Pam commence à envoyer des requêtes à la smartcard le driver est activé et copie des données et j'ai la sortie de débeugage activé pour ralentir aussi tout ça ce qui m'aide à suivre ce qui se passe et au bout d'un moment vous pouvez voir qu'on déclenche le message d'erreur donc on a notre message d'erreur le tampon de sortie est trop petit et ça continue à écrire des choses dans la mémoire et à la fin j'obtiens une exécution de code et vous pouvez voir c'est que donc j'ai une exécution de code en tant que super utilisateur comment est-ce qu'on peut exploiter ça dans le monde réel la façon la plus simple ce serait simplement d'utiliser du matériel custom qui permettrait d'attaquer des lecteurs de smartcard mais bon pour ça il faudrait quand même avoir un système qui permettrait d'écrire dans la carte quand elle est connectée dans le lecteur ça peut peut-être marcher pour se connecter à Linux mais si vous essayez de mettre ça dans un distributeur d'argent par exemple ça serait pas forcément très pratique donc à la place où vous pouvez utiliser cette carte qui s'appelle la basic card vous pouvez la programmer en basic mais ça permet de faire tout ce qu'une smartcard peut faire et avec ça vous pouvez complètement customiser les ATR enfin l'ATR donc avec ça vous pouvez avoir tous les drivers tous les pilotes acceptés votre carte alors que ça ne sera pas le cas avec la plupart des smartcards donc on utilise donc en bas ici vous voyez qu'on déclare une suite d'octets de l'ATR dans ce cas si c'est pour le driver de hop messy et ici on peut déclare des fonctions qui seront agressibles et les APDU nécessaires pour les appeler donc par exemple si vous avez un bit de classe de 0 et une instruction qui vaut 4 ça va appeler cette fonction ici et on peut la fonction avec selectfile et on peut lui passer des paramètres on peut passer la fonction selectfile à laquelle on passe quel fichier le pilot veut sélectionner et dans ce cas on fournit ici une réponse statique le code de cet exploit bien sûr peut facilement enfin le code est assez simple mais si vous voulez voir comment il marche vous pouvez prendre un lecteur de smartcard et vous pouvez tester c'est disponible pour vous aussi donc comment est-ce que vous trouvez des bugs dans les drivers de smartcard donc il y a une manière c'est faire de l'audit manual de code source donc j'en ai fait j'ai aussi fait du fuzzing pour simplifier le fuzzing c'est envoyé plein de données malformées au pilot et la plupart des outils sont orientés données ils ne sont pas prévus pour être envoyé des paquets recevoir des réponses envoyer un autre paquet c'est pas trop comme ça donc il y a le challenge de transformer l'entrée sous forme de fichier en quelque chose qui ressemble à des données du protocole donc quelque chose d'intéressant avec un wrapper qui s'appelle smartcard transmite il indique combien de temps à recevoir donc ce que j'ai fait c'est je remplis toujours ce tampon jusqu'à la fin par une donnée lue depuis un fichier et vu que c'est orienté réseau on n'a pas besoin de s'occuper à faire du polling on a juste à faire une copie de tampon donc de mon fichier c'est j'ai généré un lecteur qui interface avec le fuzzer donc j'ai utilisé AFL pour le fuzzing qui fait aussi l'étude de couverture de code qui permet de déterminer si un fichier d'entrée donnée est intéressant ou pas et la plupart du temps c'est comme ça que j'ai trouvé des bugs dans ces projets j'ai aussi essayé enfin j'ai aussi programmé une bibliothèque que vous pouvez précharger sous Linux ou Windows donc dans laquelle il y a le driver SmartTac qui a infecté avec votre code enfin vous intégrer votre code dans le driver vous pouvez utiliser ça pour faire des bibliothèques arbitraires, y compris propriétaires et un truc de plus qui s'est passé l'année dernière quelqu'un a dit que il y a un porté de Windows Defender l'antivirus de Microsoft sous Linux et en gros il voulait faisait du code et il a réussi à exécuter ça dans un environnement vraiment restreint et le fuzzing c'est bien parce que ça permet d'y terrer très vite et le plus vite vous arrivez à faire du code et la probabilité que vous trouviez des bugs parce que vous balancez vraiment de plus en plus et j'ai suffisamment battu cette bibliothèque ce qui fait que j'ai réussi à charger des pilotes Windows pour les faiser il y a des exceptions avec les drivers en dotnet par exemple ça fonctionne pas parce que ça dépend sur un tas d'autres dépendances mais tout ce qui est on sait devrait plus ou moins fonctionner correctement donc tous les fuzzer sont déjà sortis vous pouvez les télécharger sur github et si quelque chose ne fonctionne pas envoyez-moi un email ça me fera plaisir alors ça c'est ça qu'on assemble AFL, American Fuzzilop quand vous êtes en train de faisait du code donc là je crois que ça c'est après 28 jours de fonctionnement et au bout de 28 jours j'ai pu voir j'ai trouvé beaucoup de bugs dans PCSI et quand on regarde les statistiques de couverture de code on est à peu près à 30% je pense que c'est pas trop mal quand on pense au fait que les réponses doivent être correctes pour excuter beaucoup de codes au départ le pilote de smartcard essaye de vérifier si la carte c'est quelque chose qu'il a le droit ou qu'il est censé interagir et ensuite le pilote va lire des certains fichiers et il y a peut-être une dizaine de commandes avant qu'on arrive à la partie intéressante par exemple enumérer les certificats ce genre de choses donc j'étais assez surpris de voir que la couverture était montée aussi haut et dans les cas les plus bas on a des fichiers qui ont 0% de couverture mais dans ce cas par exemple c'est des fonctions pour pkcs15 des choses avec lesquelles on n'a pas du tout interagis il y a aussi des pilotes ici qui sont pas activés par défaut dans opnsc mais de l'autre côté il y a certains pilotes pour lesquels la couverture de code était très élevée et j'étais surpris en fait de voir qu'on arrivait à atteindre des niveaux aussi élevés de couverture de code pour certaines régions j'ai pas vraiment fait quelque chose de très compliqué j'ai juste envoyé des commandes assez simples et j'ai laissé le fesseur voir ce qu'il pouvait trouver et quelle fonction pouvait être atteinte dans le code donc il n'y a pas juste les drivers qui sont intéressants dans cette configuration mais aussi les fonctions d'utilitaire par exemple les fonctions PAM, les modules PAM il y en a un que vous pouvez utiliser pour vous logger avec une Spartkan qui s'appelle Pan pkcslm pkcs11 et c'est un processus assez similaire au précédent mais il y a une différence quand vous générez un once vous voulez un bon Naléa parce que si un attaquant arrive à rejouer un once et bien ce once et cette signature qui est générée par ailleurs c'est possible de rejouer cette question, cette dépense et un des problèmes c'est qu'il nous faut beaucoup d'entropies de bonne qualité et ces petits modules de sécurité ne sont pas nécessairement capables de générer cette entropie donc quand on demande à la smartcard de générer des données aléatoires et qu'on lui demande ensuite de faire la signature si l'attaquant contrôle l'ordinateur de la victime l'attaquant récupère le nom c'est la signature et ensuite il peut modifier sa propre smartcard et rejouer tout ça sur une autre machine c'est il y a aussi un bug intéressant on peut voir la psychologie du développement qui fait vraiment confiance à ce petit périphérique et qui pense pas vraiment à ce qu'il est en train de faire il y a quelques difficultés quand on essaie d'exploiter ce genre de choses dans les drivers l'une d'entre elles c'est qui a vraiment en général peu de données qui sont envoyées à la carte et si vous avez besoin d'une fuite d'information pour faire votre exploit c'est vraiment pas quelque chose de facile à faire vous n'avez pas d'interaction il n'y a pas de clavier, il n'y a pas d'écran sur un smartcard mais si vous arrivez à sortir des câbles du lecteur pour obtenir des traces il y a Simtrace par exemple qui existe avec un firmware qui vous permet de non seulement faire de l'homme du milieu mais d'envoyer ce que vous voulez et l'avantage c'est que c'est pas forcément nécessaire d'exécuter du code il suffit d'inverser certains bits qui indiquent si l'utilisateur c'est bel et bien logé c'est un avantage pour l'attaquant donc ce que j'ai appris de tout ça c'est j'ai toujours dit que les smartcards c'était quelque chose de bien mais j'ai jamais vraiment pensé à cette surface d'attaque quand on déploie une authentication par smartcard c'est un peu le même problème qu'avec les antivirus ça vous êtes pour votre sécurité mais d'un autre côté s'il y a des bugs dans votre antivirus c'est embêtant si vous utilisez OpenSC il y a une option dans la configuration que vous pouvez utiliser afin de blacklister enfin ou de whitelister des pilotes et uniquement exécuter les pilotes dont vous avez besoin dans votre configuration et ça réduirait vraiment beaucoup votre surface d'attaque et les mecs de chez Ubiko qui qui ont écrit des nouveaux drivers en piton au lieu de le faire renseer ils ont pas tous ces problèmes de corruption mémoire qui peuvent entraîner l'exécution de code donc si vous avez la possibilité de faire ça faites-le eh bien merci beaucoup si vous avez des questions alors je n'utilise pas Twitter le seul réseau social qu'on a force à utiliser c'est LinkedIn donc désolé si nous avons des micros pour les questions vous pouvez aussi poser questions par IRC si vous écoutez cette traduction sur 35C3 all C sur le serveur Hackint j'ai une question c'est peut-être un peu bizarre mais vous avez essayé de faire des choses comme ça avec des cartes RFID par exemple parce qu'il y a beaucoup d'emplacements où il y a des lecteurs de smartcard par exemple sur des portes il faut présenter une carte et est-ce qu'on pourrait avoir une carte qui fose le lecteur de la porte donc pour autant de gens sachent en ce qui concerne le son contact les protocoles sont similaires mais je n'ai pas joué avec pour l'instant je recommande aux gens d'utiliser une technologie à câble si ils peuvent est-ce que vous avez utilisé de mettre un petit microcontroller pour faire ce que vous voulez sur les cartes plutôt que d'utiliser la basiccard comme ça vous pourriez avoir un framework un peu plus évolué à la place celui-là je pense que ce qui vous intéresserait c'est Simtrace donc ils viennent de sortir une nouvelle version donc j'utiliserai ce genre de choses j'ai des amis qui parlaient aussi de faire son propre circuit imprimé il y a beaucoup d'options qui sont ouvertes à vous peut-être même venez plus tard en discuter si ça vous intéresse alors votre présentation était surtout sur des cartes malicieuses qui attaquent des lecteurs compromis est-ce qu'il y a la possibilité à l'heure actuelle d'obtenir par exemple une clé RSA à partir d'une smartcard ou est-ce que les smartcards sont suffisamment sûrs j'ai vraiment pas regardé je ne suis pas spécialiste en matériel je sais qu'il y a des gens par le passé genre Carson Knowle a un des camps a fait une présentation qui était assez intéressante il parlait du fait de décaper la puce et de rajouter des points de collect est-ce que le protocole pkcs et la stack pcsc est-ce que ces deux éléments sont trop compliqués est-ce qu'on pourrait peut-être les remplacer de plus simples je ne pense pas que ce soit un problème de logiciel le problème c'est que les données que la carte envoie aux pilotes dans certains cas elle est encodée en SN1 dans certains cas c'est totalement propriétaire et tout ce parsing c'est là qu'on a beaucoup de problèmes merci beaucoup pour cette présentation vous savez montrer des vulnérabilités dans les pilotes est-ce que ça veut dire que tous les ordinateurs qui autorisent une authentication par smartcard même s'ils ne l'utilisent pas est-ce que ces pistes sont vulnérables à des failles qui peuvent obtenir un shell route comme ça donc en général il faut que vous installiez les pilotes, ils ne sont pas installés par défaut sous Linux sous Windows c'est des fois difficile d'accéder aux pilotes parce que les fabricants les réservent à leur client des choses du style donc je ne sais pas pourquoi ils font ça mais apparemment c'est comme ça qu'ils procèdent mais en général il n'y a rien d'activer par défaut il faut l'activer en tout cas sous Windows et Linux je ne sais pas trop comment ça se passe sous ma coS si vous avez plus de questions à propos de ces cartes RFID je me disais il y a des applications qui permettent d'utiliser un contrôleur NFC sur un téléphone en route pour simuler une carte NFC vous avez utilisé une basique carte pour simuler une smartcard je pense qu'il serait possible d'utiliser un émulateur de carte NFC sur un téléphone pour émuler des cartes RFID ce serait une bonne approche je n'ai pas créé le firmware de la basique carte j'ai juste utilisé pour l'exploitation quand vous faites du fuzzing vous voulez vraiment faire le plus d'exécution et exécuter le plus de chemin de code donc j'imagine que vous pouvez procéder comme ça je crois que les développeurs de la basique carte ont aussi une version sans contact je ne l'ai pas personnellement je pense que la surface d'attaque on pourrait penser attaquer le firmware d'un téléphone mobile via une carte malicieuse pour le débloquer je ne sais pas à creuser il semblerait que nous sommes à cours de questions donc tonnerre d'appellissement pourrait s'il vous plaît