Cliquez sur la couverture pour découvrir le sommaire et des extraits du magazine !
En savoir plus9,00 € TTC
De la vuln à l'exploit : faites votre marché !
Il y a un peu plus d’une quinzaine d’années, alors que du lait coulait du coin de mes lèvres, je luttais pour comprendre l’article d’Aleph One sur les buffer overflows, Smashing The Stack For Fun And Profit [1]. Quelques années plus tard, le Cacolac au bord des lèvres, je me délectais <mode=je me la pète>en avant-première</mode> du savoureux Vudo malloc tricks de MaXX [2].
Entre les deux, j’avais pas mal bossé pour comprendre toutes ces choses qu’on n’expliquait pas en cours, le userland, le kernel, les débordements mémoire, et surtout, comment on pouvait jouer avec pour produire des effets non prévus par les développeurs. Et quand on y arrive, c’est Chambourcy oh oui !!!
À l’époque, c’était mieux avant (ou pas) : il suffisait d’un grep strcpy pour trouver 3 vulnérabilités remote pre-authentification et il n’y avait pas de protection mémoire, canary et autres ASLR. Restait juste à faire le Tree(ts).
Ami lecteur, si ces mots ne te parlent pas, continue à lire ce magazine, et bienvenue dans le 21ème siècle. Évidemment, il est beaucoup moins simple actuellement de trouver des vulnérabilités.
Quoi qu’il en soit, comme avec le pentest il y a quelques années, aujourd’hui les gens qui font de la recherche de vuln apparaissent à la croisée entre le martien et la religieuse : quand ils s’expriment, ça ressemble au yaourt Bio de la nonne. Techniquement, il ne suffit plus de se spécialiser en Windows ou Linux, mais aussi sur un logiciel donné (Acrobat, IE, Chrome, etc.) tellement ils sont devenus complexes. Et même la partie recherche de vuln se sépare de plus en plus de la partie exploitation.
Outre les aspects techniques traités dans les pages de ce magazine, la recherche de vuln pose aussi des questions éthiques. Déjà, pourquoi en chercher ? Parce que d’autres le font, et si on ne les trouve pas avant eux, il y aura toujours des méchants pour en tirer parti. Laissez des 0 days aux bad guys et ils ne sauront résister à l’appel du Banga. En agissant au plus tôt, c’est pour aider à deux doigts de couper la fin (vous ne voulez pas un whisky d’abord, elle est raide celle-là). Toutefois, cela suppose que les bugs trouvés soient rapportés et corrigés dans un délai raisonnable, ce qui est loin d’être certain.
D’autres considèrent aussi que ce n’est pas aux clients de faire le travail qui devrait être réalisé par les éditeurs et que tant que ceux-ci ne paieront pas pour un rapport de vuln, il est hors de question de signaler quoi que ce soit. Aujourd’hui, de nombreux éditeurs ou logiciels open source proposent un Bounty quand on rapporte une vulnérabilité. C’est pas le goût du paradis et les sommes payées restent inférieures à celles distribuées par des boîtes qui font on ne sait trop quoi avec les vulns. Chez elles, ce n’est pas la politique du Prix Unique, et on y trouve tout pour l’habillement des opérations offensives.
Bref, le secteur est encore éthiquement très instable, et techniquement en (r)évolution perpétuelle.
Je regrette encore la défiance vis-à-vis de cette discipline. Pendant des années, en France, on se prenait un vent dès qu’on évoquait un sujet offensif : Mamie écrase les prouts comme disait Coluche. À SSTIC en 2005, des officiels avaient failli avoir une crise cardiaque, la vache, qu’on a ri et appris !
Je tiens particulièrement à remercier les auteurs impliqués dans ces pages de partager leur expérience. J’espère donc que ce hors-série contribuera à détendre l’atmosphère quant aux vulnérabilités et autres exploits : la connaissance réduit la méfiance. Mais si vous ne savez pas quoi faire des trouvailles de votre Free Time, n’hésitez pas à me contacter, je vous mettrai au parfum Bic-ause I know.
Fred Raynal
@fredraynal
@MISCRedac
[1] http://phrack.org/issues/49/14.html
[2] http://phrack.org/issues/57/8.html
04 Limites et mérites de l'évaluation des logiciels
10 Revue de code : à la recherche de vulnérabilités
18 Fuzzing, de la génération au crash
25 Analyses de code et recherche de vulnérabilités
33 Introduction au Return-Oriented Programming
41 Redécouverte et exploitation du Pwn2Own 2012 Android
53 Protections des systèmes Windows
60 Java Card dans tous ses états !
69 Oracle : de la base au système
77 Analyse de firmwares : cas pratique de la backdoor TCP/32764
Face à la transformation digitale de notre société et l’augmentation des cybermenaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 20 années de publications et de retours d’expérience, MISC apporte un vivier d’informations techniques incontournable pour mieux appréhender ce domaine. Précurseur sur ce terrain, MISC a été fondé dès 2002 et s’est peu à peu imposé dans la presse française comme la publication de référence technique en matière de sécurité informatique. Tous les deux mois, ses articles rédigés par des experts du milieu vous permettront de mieux cerner la complexité des systèmes d’information et les problèmes de sécurité qui l’accompagne.
Les militaires ont été les premiers à tenter « d'industrialiser » un processus permettant d'évaluer la sécurité des systèmes informatiques. Ces travaux ont été à l’origine en 1984 de la parution du « livre orange » dont l'impact sur ces sujets fut déterminant. D'autres travaux en ont découlé avec la parution en 1991 des ITSEC puis des Critères Communs. Ces approches « normalisées » de l'évaluation et de la certification sécuritaire imposant répétabilité et reproductibilité des analyses ont souvent été accueillies avec un certain scepticisme, voir un certain rejet de la part des « experts » informatiques pour qui l'expertise pure, avec toute la subjectivité qu'elle comporte, est la seule approche valable. En pratique, ces deux approches sont indissociables. C'est du moins ce que tente de démontrer l'article qui suit.
L'année 2013 a été une année assez « riche » en termes de découverte et d'exploitation de 0-day dans la nature en ce qui concerne la famille Java (1). Java Card fait tout aussi bien partie de cette famille. Néanmoins, son processus d'évaluation suit un tout autre chemin et les attaques découvertes jusqu'à maintenant n'en sont pas moins intéressantes.
La recherche de vulnérabilités est généralement menée en plusieurs étapes : identifier des parties du code potentiellement dangereuses puis étudier la possibilité de les exploiter, par exemple pour corrompre la mémoire. Dans cet article, nous montrons comment des techniques d'analyse statique de code apportent une aide significative à ces étapes.