27C3 : We come in peace !

27c3  : We come in peace
D’année en année, la conférence berlinoise du Chaos Computer Club amène son lot de surprises et de révélations aux amateurs de sécurité, professionnels ou non, et aux bricoleurs de toutes tendances. Cette fois-ci, pour sa vingt-septième occurrence, le Chaos Communication Congress, a vu l’intérêt pour l’analyse de sécurité du protocole GSM se confirmer, et de nouveaux sujets d’inquiétude apparaître au grand jour. Un tour d’horizon des sujets des conférences auxquelles nous avons pu participer.

GSM, hacking et analyse
En quelques années, une sorte de tradition s’est établie qui consiste à faire de fracassantes révélations sur l’état actuel des implémentations du protocole GSM, toujours utilisé dans la téléphonie mobile. Cette année ne fait pas exception, et c’est avec plaisir que nous avons pu suivre les présentations respectives de Harald Welte et Steve Markgraf sur l’état actuel de l’implémentation open-source de la pile GSM, et de Karsten Nohl et Sylvain Munaut à propos d’un système de «  sniffing  » GSM. La conférence de Welte et Markgraf abordait ainsi le projet osmocomBB, qui permet de remplacer le logiciel propriétaire de certains types de téléphones mobiles par un firmware complètement ouvert, et représente la dernière brique manquante de l’édifice GSM libre composé également des projets OpenBTS et OpenBSC. Nohl et Munaut, utilisaient d’ailleurs osmocomBB dans leur démonstration  : avec l’aide de quelques téléphones à 10~15€ la pièce, ont montré la capture et le décryptage quasiment en temps réel d’une conversation téléphonique entre eux-deux  ! Relevant au passage que les fournisseurs d’accès téléphoniques dans leur grande majorité ne changent pas assez souvent les clefs de chiffrages utilisées dans leurs réseaux, ce qui rend le décodage d’autant plus facile. Sans citer de noms, Nohl signale quand même que certaines compagnies de téléphones ne changent tout simplement jamais de clefs de chiffrage, ce qui avait été révélé l’année passée dans d’autres conférences, et aurait du être corrigé. Un outil de déboguage comme celui-ci, lorsqu’il sera publié, représentera une menace sérieuse pour ces compagnies.

Les cartes de paiement à puce, un problème à venir
EMV est le protocole le plus fréquemment utilisé pour les paiements par carte à puce dans le monde entier, avec plus de 730 millions de cartes en circulation. Dans son exposé, Steven Murdoch a montré comment l’utilisation d’une faille du protocole permet aux criminels d’utiliser une vraie carte pour effectuer un paiement sans en connaître le PIN. Le fraudeur effectue une attaque man-in-the-middle pour tromper le terminal et lui faire croire que le code PIN a été vérifié correctement, tout en faisant croire à la banque émettrice qu’aucun code PIN n’est nécessaire ( ce cas est inclus dans les spécifications, exemples : handicapés, péages, …). Le point est mis sur le fait que par ce moyen la banque a l’impression que la carte a été utilisée avec un code PIN mais ce n’est pas le cas, la responsabilité retombe donc sur l’établissement banquaire, ce que l’orateur aide réguliérement à prouver en cas de litige. À noter qu’en date de la conférence, une seule banque a corrigé cette faille depuis sa communication ( private advance disclosure ), mettant ainsi en lumière l’immobilisme de l’industrie surtout si celle-ci n’a que la moitié de la facture à payer le reste étant à la charge du client.

DNSSEC, le dernier «  rant  » de D.J. Bernstein
Daniel J. Bernstein (DJB) est connu comme le loup-blanc dans le milieu de la sécurité informatique. Depuis plusieurs années, il publie du code minimisant les vulnérabilités (qmail, djbdns, etc.) allant même jusqu’à promettre une récompense substantielle à ceux qui démontreraient des failles dans ses logiciels. Il publie aussi des recherches sur les algorithmes de chiffrage et son algorithme Salsa20 figure dans le quartet final du projet eSTREAM (une initiative destinée à remplacer les plus anciens algo de chiffrage utilisés par exemple en téléphonie). En bref, quelqu’un dont les mérites ne sont plus à prouver. Il est aussi connu pour son discours acide, et sa tendance à bouter le feu à tout ce qu’il perçoit comme une idiotie. Cette année, c’est à DNSSEC qu’il a choisi de s’attaquer, ironisant avec talent sur les défauts de ce protocole et expliquant chiffres à l’appui que les pirates et autres vandales du web ont vraiment tout intérêt à supporter l’adoption universelle de DNSSEC, tant elle leur simplifie la mise en place d’un déni de service. DJB ensuite décris une collection de solution, prenant chaque fois DNSSEC comme contre-exemple, et finalement dévoile le but de son discours, qui est bien entendu la promotion sans honte d’une de ses propres créations, DNSCurve. Rien d’inhabituel là non plus, DJB ayant coutume de joindre le code à la parole, surtout lorsqu’il a l’occasion de revêtir son costume de chevalier blanc, pourfendeur de la sécurité par l’obscurité et défenseur des solutions simples… Ceci étant dit, le coté histrion de DJB ne doit pas cacher qu’il a eu très souvent raison et que la majorité, si ce n’est l’ensemble, de ses prévisions en matière de sécurité s’est révélée exacte. En quelques mots, qu’est-ce que DJB reproche à DNSSEC et qu’est-ce que DNSCurve est supposé apporter  ? La page web du projet ( www.dnscurve.org ) entre dans le détail des avantages de DNSCurve sur une collection d’attaques types, et documente la manière dont le protocole est supposé fonctionner. Il y a aussi quelques avantages de DNSSEC qui sont cités, mais par contre il n’y a pas encore d’implémentation de référence. Ce qui peut avoir des effets négatifs sur l’image de ce projet.

Ingénierie inverse de circuits intégrés
La conférence donnée par Michael Steil traitait de la reconstruction du schéma électronique d’un circuit intégré en partant du circuit lui-même et de quelques données connues à son sujet. La conférence s’intitulait «  Reverse Engineering the MOS 6502 CPU  » et démontrait et expliquait comment une équipe de mordus a reconstruit un modèle physique de l’historique MOS 6502 alors que la documentation d’ingénierie de ce chip a été perdue dans la débâcle Commodore. L’intérêt de cette présentation, hormis le pur facteur «  hacking  », est que ces techniques d’investigations peuvent être appliquées à n’importe quels circuits intégrés, et dans le futur probablement même aux plus récents d’entre eux. Reconstruire un modèle physique d’un processeur historique comme le 6502 (qui équipait entre autres les premiers ordinateurs Apple, Commodore et Atari) pour ensuite émuler son fonctionnement avec des FPGA ou un logiciel ad-hoc parait peut-être un peu ridicule et vain, mais si on peut le faire avec un circuit inoffensif comme celui-ci, on peut parfaitement imaginer reconstruire de la même manière les composants propriétaires équipant nos téléphones, ou n’importe quel équipement où la norme est de sécuriser les données en cachant dans le silicium la manière dont la «  sécurité  » est assurée. Par exemple, les circuits propriétaires des consoles de jeu, les chips de zonage des lecteurs DVD, les circuits de chiffrage de donnée des disques durs auto-cryptés du commerce, etc. Cette démonstration est dans la même lignée de la vulnérabilité de la non moins fameuse OysterCard.

Les vulnérabilités de PDF
Cette dernière décennie, le Portable Document Format, ou PDF, est devenu clairement le format le plus commun dans la publication de documents électroniques. Il est utilisé dans l’industrie du livre comme format de référence tant pour l’impression que pour la publication de ebooks. Et l’implémentation de référence de PDF est encore et toujours le célèbre Adobe Acrobat, dans ses deux éditions, Writer ou simple «  reader  ». Malheureusement, comme Julia Wolf l’a rappelé durant sa conférence, PDF est un standard qui a plus ou moins été aggloméré au fil des besoins de son éditeur d’origine, et Acrobat est le reflet de cette évolution organique  : à plus de 15 millions de lignes de code, Acrobat est plus lourd que Mozilla Firefox, plus lourd que le kernel Linux et la majorité de son code a été écrit dans les années ’90, dans le secret des laboratoires de Adobe. Le résultat est qu’il est possible de tromper Acrobat très facilement. La syntaxe de PDF et parmi d’autres le fait que la norme ne décrit explicitement aucune méthode de validation des documents PDF permettent de manufacturer des documents PDF qui sont en même temps des exécutables, qui contiennent du code malicieux ou qui se font passer pour toute une collection de formats de données. Dans un PDF, on peut appeler des commandes systèmes, exécuter des programmes arbitrairement, former des documents qui affichent des contenus différents selon le programme de lecture PDF utilisé, etc. Julia Wolf c’est concentrée sur Acrobat, parce qu’il est encore aujourd’hui le client PDF le plus fréquent, mais la norme sur laquelle ces programmes sont construits est suffisamment confuse et complexe pour que des exploitations de failles soient envisageables avec chacune des implémentations indépendantes.

Analyse de code par optimisation et déobfuscation
Deux autres conférences ont parlé respectivement de la déobfuscation de code par l’utilisation d’outils d’optimisation, et d’identification de primitives de chiffrage dans des exécutables à l’aide de techniques similaires. Dans la première, Branco Spasojevic a présenté l’utilisation conjointe d’un dés-assembleur scriptable (IDA Pro) et des fonctions d’optimisation de code d’un compilateur pour éliminer d’un code obscurci les obfuscations les plus courantes utilisées aujourd’hui. Puis, utilisant les possibilités de script du dés-assembleur, a montré comment personnaliser le décodage d’un binaire obscurci. Dans la seconde conférence, c’est Felix Grobert qui a montré comment les bibliothèques génériques de chiffrage partageaient plusieurs caractéristiques inhérentes qui pouvaient être identifiées dans des binaires, par exemple dans des malwares, et comment avec un outil développé dans ce but il est possible d’analyser le comportement d’un programme même si certaines de ses parties sont encodées. Un aspect intéressant propre à ces deux conférences est qu’il a été question les deux fois de théorie des compilateurs, et surtout de graphes d’exécution  : les programmes analysés sont décrits sous forme de graphes de flux et c’est sur ces graphes que les opérations d’analyse fonctionnelle sont faits. L’utilisation de graphes de flux semble se généraliser, c’est quelque chose qui est très utilisé dans l’écriture de compilateurs pour des langages dynamiques, par exemple dans le projet PyPy, un générateur de compilateur JIT pour le langage Python.

Pour l’avenir  ?
Une nouveauté dans l’organisation de 27c3 par rapport aux éditions précédentes est qu’il y avait cette fois ci un système de pré-location, et que les salles étaient limitées au nombre exact de places assises qu’elles comportaient. Pour compenser, le CCC a aussi mis en place des canaux TV accessibles avec une carte tuner, et des streaming vidéo visibles si on acceptait de prendre le risque de se connecter au réseau. Il y avait également des écrans de diffusion devant les portes des salles, donnant ainsi aux malchanceux la possibilité de suivre les démonstrations. Le même système d’écran était aussi supposé informer le public de l’organisation et du planning actuel des conférences, mais ce dernier point a été un échec particulièrement frustrant à observer  : non seulement les conférences changeaient de position dans le planning de manière encore plus aléatoire que les années précédentes, mais en plus les informations relatives étaient contradictoires entre les écrans, les affichettes imprimées à la minute, les corrections au marqueur sur les affichettes et le site web du congrès. Les locaux ont également montré leurs limites, avec seulement trois salles à disposition les conférences en anglais étaient particulièrement prises d’assaut. Si 28c3 (la prochaine édition) veut espérer se passer dans de meilleures conditions, les organisateurs reconnaissent qu’ils doivent chercher de nouveaux locaux, plus spacieux, et s’assurer que les affichages soient pertinents.
Dans tous les cas, si le succès du Chaos Communication Congress grandit encore, les conférences et les activités qui y seront présentées mériteront qu’on y fasse à nouveau un tour. L’ambiance du congrès reste bon-enfant, malgré le sérieux de la plupart des conférences, et on reprend toujours contact avec plaisir avec ce coté anarchiste défenseur des libertés individuelles qui fait son charme. Une fois de plus, toutes les tranches d’âges sont représentées, avec une participation féminine en augmentation et une très nette préférence pour les téléphones à système Android, par opposition à la concurrence de la marque à la pomme. Un point peut-être, c’est qu’on ressent de plus en plus un agacement des hackeurs vis à vis du comportement «  l’argent passe avant tout  » de la plupart des acteurs industriels. Des protocoles confus, des implémentations misérables, des interlocuteurs muets, tout ça devient la cible de l’ironie à peine déguisée de certains orateurs, surtout lorsque le silence ne fait que masquer le peu d’intérêt que les grandes compagnies ont réellement pour leurs clientèles. Par exemple dans sa présentation Karsten Nohl souligne que les clefs propriétaires du protocole GSM sont très bien protégées, contrairement à celles qui chiffrent les données des utilisateurs. Il dit, avec un sourire en biais, que c’est normal, les clefs propriétaires protègent l’argent des compagnies, tandis que les autres ne protègent que nos données personnelles… Un symptôme seulement, mais comment est-ce que cette situation évoluera  ?

En guise de conclusion
Nous n’avons malheureusement pas pu suivre toutes les conférences que nous aurions voulu, soit pour des raisons d’horaire, soit parce que la salle était déjà pleine. Ainsi nous n’avons pas pu suivre les conférences sur l’état des lieux du monde OpenSSL et la situation actuelle en matière de sécurité dans Ipv6. Il a fallu faire des choix.

Pour terminer, il est possible de visionner les conférences de 27c3 et de lire tout ou partie des présentations. L’organisation publie sur son wiki les liens vers tous les documents de référence, à l’adresse http://events.ccc.de/congress/2010/wiki/Documentation

Auteurs : Lantoane + LeLouac