Compte rendu BlueHat v8

Fri 24 October 2008 by jj

Nous avons eu le privilège d'être conviés à la conférence de sécurité informatique BlueHat, organisée par Microsoft dans ses locaux de Redmond.Voici un résumé des différentes interventions de ces deux jours.

Keynote

La keynote souligne d'une manière générale l'implication de Microsoft dans le domaine de la sécurité informatique.

En tant qu'acteur principal sur ce marché, Microsoft se doit d'être exemplaire dans la gestion notamment des failles.Cette prise de conscience a eu lieu il y a quelques années, et a donné naissance à différentes initiatives, notamment le SDL (Security Development Lifecycle).Il s'agit d'un guide de bonne pratiques pour la gestion de la sécurité d'un projet informatique, accompagné d'un ensemble de programmes relatifs à chaque phase de ce processus.

Le guide et les outils sont destinés aussi bien aux développements internes de Microsoft que pour tout acteur extérieur.

Crimeware behind the scenes

Iftach Amit nous présente l'évolution des menaces informatiques, qui sont passé du virus qui efface votre disque dur au 'crimeware', ces systèmes espion utilisés par des groupes de type mafieux.

Ces nouvelles générations sont marquées par un développement logiciel beaucoup plus poussé, de niveau professionnel.Ces programmes sont très discrets, il est même assez difficile de se rendre compte que l'on a été infecté.

Leur but est de récupérer des informations ayant une valeur financière, en général il s'agira de récupérer des numéros de carte de crédit.Pour cela une technique répandue consiste à modifier les pages affichées par un navigateur internet lorsque l'on se connecte à sa banque, en insérant une page qui va par exemple demander des informations supplémentaires (code PIN, 'question secrète' et sa réponse, utilisées dans les liens "j'ai oublié mon mot de passe"...).

C'est là que l'on constate le degré de sophistication des malware : car la page insérée va être parfaitement intégrée à la charte graphique du site détournée, traduite impeccablement... De plus l'injection ayant lieu dans le navigateur même de la victime, celle-ci ne peut même pas se fier à l'authentification SSL utilisé par la banque, car l'attaquant va modifier les informations affichées à l'écran, sans intervenir sur les données transmises par le réseau.L'auteur nous indique que les numéros de carte de crédits se vendent plus ou moins cher suivant les informations disponibles, la devise de la carte, etc.

Mais il existe d'autres informations ayant une valeur marchande :Les fichiers de logs de chevaux de Troie contiennent également une très grande quantité d'informations, trop grande pour être intégralement traitée par son opérateur: ceux-ci peuvent également se monnayer sur le marché.Certaines informations spécifiques peuvent valoir jusqu'à plusieurs milliers de dollars, mais relèvent plus de l'espionnage industriel, comme des informations de conception de softwares, ou des données financières.

Ces différents logiciels sont souvent installés par le biais de failles dans les navigateurs.Il existe des frameworks pour la gestion de ces failles, dont certains utilisent des mécanismes commerciaux ou le framework va se connecter au site de son auteur pour vérifier qu'il n'est pas piraté, et que son numéro de licence est valide...Pour fonctionner, ces failles nécessitent que l'utilisateur visite un site malveillant qui va alors exploiter le navigateur.Ceci se fait par divers moyens :Soit par l'utilisation de spam pour que l'utilisateur navigue sur un site malveillant, soit par l'injection du code malveillant dans un site légitime.Cette dernière attaque peut se faire en exploitant le serveur web ciblé, ou bien tout simplement en utilisant le login/pass du gestionnaire du site, que l'on aura peut-être trouvé dans les logs d'un cheval de Troie, ou trouvé par bruteforce.Il est même possible d'exploiter une faille XSS pour insérer dynamiquement le code malveillant dans un site légitime, cette attaque pouvant être mené a bien en manipulant les résultats des moteurs de recherche (pagerank) de sorte qu'une recherche anodine provoque l'infection.

Des recherches montrent que l'on trouve aujourd'hui plus de sites légitimes compromis que de sites malveillants crées directement.La plupart des exploits utilisés sont connus et les failles déjà patchées, mais la plupart des utilisateurs ne disposent pas de la dernière version du navigateur - notamment dans le domaine professionnel, ou les mises à jour doivent être validées avant d'être déployées.

Une excellente présentation, regorgeant d'exemples très explicites.

Investigating Individuals and Organizations Using Open Source Intelligence

Roelof Temmingh réalise une présentation en deux parties sur la vie privé sur internet.

La première partie est une présentation de son outil, 'Maltego'.

Celui-ci est un moteur d'agrégation de données, qui est capable de lier de nombreuses sources d'informations disponibles librement sur le net.

On peut par exemple partir d'un nom de domaine (www.microsoft.com):

  • récupérer les plages d'adresses IP utilisées pour ce domaine,
  • trouver des informations sur les possesseurs du domaine (nom, adresse, téléphone)
  • retrouver ces personnes sur les sites de réseaux sociaux, y récupérer leur photo, leurs amis...
  • retrouver leurs adresses email, et donc éventuellement de nouveaux domaines à inspecter
  • lister les clés PGP, les e-mail, et les connaissances (en listant les signatures des clés)
  • lister les autres noms de domaines servis par les serveurs DNS de la zone.

et bien plus encore.

Un outil très puissant, ayant une interface agréable et intuitive... Bref le bonheur pour Big Brother.Le développement de cet outil s'est heurté à heurté à différents écueils, notamment le fait que l'information sur internet n'est pas structurée : il est par exemple difficile de retrouver un numéro de téléphone dans une page web, sachantque le format de ceux-ci varie par pays...Une autre difficulté rencontrée est que de plus en plus de sites interdisent les requêtes automatisées : google, facebook, ...

Ceci amène à la deuxième partie de la présentation : la création d'identités virtuelles pour des bots.

Un moyen pour contourner les limitations imposées par ces sites est de faire passer les requêtes automatiques pour des requêtes d'utilisateurs légitimes.Ceci peut se faire en ayant une phase de préparation de quelques mois ou l'utilisateur virtuel va se créer une identité, par exemple en commentant des films sur IMDB, en créant un blog, en commentant sur des blogs aléatoires, en effectuant des requêtes bénignes sur un moteur de recherche de manière à entretenir son 'cookie' de traçage...On a déjà vu des textes générés aléatoirement être accepté pour des conférences scientifiques, on peut donc penser que ce type de simulation est réalisable.Ceci étant entièrement automatique, il serait possible de générer une population virtuelle conséquente.

Cela s'apparente a de la 'click fraud', mais on peut aussi imaginer d'autres cas d'usage : l'auteur signale par exemple le "DoS social", ou un beau matin un bloggueur reçoit des centaines de commentaires négatifs. Avec l'effet de masse, certaines personnes bien réelles pourraient être tentées de suivre le mouvement de lynchage ; ce qui pourrait avoir des conséquences morales sur la victime.On a déjà signalé un bot russe qui aborde des humains dans un chat pour adultes, pour récupérer des informations personnelles sur eux, dresser leur profil, et les diriger vers un "site perso" malveillant...

Seconde excellente présentation, avec un outil très impressionnant.

Black Ops 2008 . It's the End of the Cache As We Know It

Une re-présentation de Dan Kaminski sur la faille DNS, similaire a celle de BlackHat de cette année.

Sans s'étendre dessus, les paquets DNS incluent un numéro de transaction (TXID) sur 16 bits qui, si on le devine, permet d'injecter une réponse arbitraire pour un serveur de cache récursif.16 bits sont trop facilement bruteforceable, d'autant plus que l'attaquant peut contrôler le moment ou le serveur victime va faire la requête légitime, et mettre a profit cette information pour envoyer de nombreuses tentatives de réponses (autour de 200 d'après Dan) ; ce qui permet d'injecter une réponse malicieuse en quelques secondes sur internet.

Il détaille également comment utiliser le champs "authority" des réponses pour réécrire l'entrée correspondant au NS (authoritative nameserver) d'un domaine a partir de requêtes sur des sous-domaines inexistants, ce qui permet de prendre le contrôle de l'intégralité du domaine.Pour cela, on s'arrange pour que la victime fasse des requêtes pour 1.malicious.com, domaine que nous contrôlons.On va alors répondre CNAME 1.inexistant.target.com, et immédiatement envoyer une série de réponses pour ce nom, contenant une IP arbitraire, et une section AUTHORITY qui nous permet d'écraser l'entrée NS target.com avec l'ip de notre serveur malveillant, de sorte que par la suite toutes les requêtes pour target.com soient faites auprès de notre serveur.

Il explique aussi pourquoi firewaller le serveur DNS ne sert a rien : il existe de nombreuses facons de faire faire une requête DNS arbitraire par un client légitime de ce DNS :

  • des liens img dans une page HTML
  • un HELO sur un serveur mail
  • une IP dont on contrôle le reverse DNS
  • ...

CSS: The Sexy Assassin

Cette présentation, par 3 chercheurs indépendants, montre différentes techniques avancées de CSS, le langage utilisé pour décrire l'apparence d'une page web.

On voit tout d'abord que CSS peut être obfusqué de manière assez efficace.On peut utiliser par exemple "toto", "tot\o", "tot&#6f", "@charset 'utf-7' +AHQAbwB0AG8"...

Ils introduisent ensuite les "overlay attacks", ou une page malicieuse affiche un iframe contenant une page légitime, et utilise des éléments HTML en les positionnant par-dessus le contenu de l'iframe, de manière à dessiner dans l'espace normalement réservé à la page cible.

La présentation poursuit sur un plan plus théorique, en montrant comment il est possible d'obtenir une structure de contrôle de type boucle en CSS.Cela se fait en rechargeant la feuille de style, par exemple en rafraichissant la page. On peut pour cela utiliser le tag CSS "-moz-binding", qui change l'url de la page courante. Ce tag est spécifique à Firefox, il existe des équivalents pour les autres navigateurs.Couplé aux capacités de calcul dues aux compteurs CSS, on se rapproche ainsi d'un langage Turing-complet.

De nombreux exemples de programmes sont disponibles sur http://p42.us/css/: une calculatrice faisant addition/multiplication, un jeu du pendu... Sans aucun JavaScript !

D'un point de vue plus offensif, l'usage de l'attribut :visited de liens est très intéressant.

On peut grâce a lui savoir si vous avez déjà visité une url particulière : il suffit de créer une page contenant un lien vers celle-ci, ce lien ayant un attribut "background-image: monserveur" pour l'attribut :visited. Quand le navigateur affiche cette page, il effectuera une requête vers notre serveur si l'url du lien est dans son historique de navigation.Il permet en particulier de sortir l'intégralité de votre historique depuis un site donné : il suffit de parser la page principale du site coté serveur, d'en extraire tous les liens et de créer une page contenant tous ceux-ci, avec pour chacun un attribut background-image spécifique s'ils ont été visités. Une fois chaque lien visité déterminé, on recommence l'opération pour chacun, reconstituant ainsi pas a pas l'historique de l'utilisateur.En fait cela permet même de suivre en temps réel la navigation, car l'attribut :visited est honoré à la seconde où le lien est cliqué. Un proof-of-concept est disponible sur le même site.

Une autre application est la conception d'un scanner de ports : pour savoir si un port est ouvert, il suffit de créer un iframe essayant d'ouvrir http://<ip cible>:<port cible>/. Si le port est fermé, un lien ayant cette même URL n'aura pas l'attribut :visited, par contre si le port est ouvert il l'aura : ce qui nous permet de récupérer cette information.Il suffit ainsi de créer une page contenant une série de constructions de ce type, pour chaque ip/port qui nous intéresse.

Enfin, il est possible de récupérer le contenu d'un champs texte (comme un mot de passe), en utilisant un sélecteur CSS qui matche le début de la valeur d'un élément HTML "input" : on peut énumérer toutes les premières lettres possible, remonter la lettre trouvée au serveur qui va mettre à jour la CSS pour rechercher la deuxième lettre etc.Sachant que la future norme HTML5 devrait permettre aux styles CSS de passer d'une page à une sous-page (iframe), cela pourrait permettre des attaques évoluées.La norme HTML5 a récemment été modifiée de ce point de vue, en n'autorisant ce comportement que si la sous-page fait partie du même domaine que son conteneur. Gare aux cross-site scripting...Une évolution probable de CSS permettra d'appliquer cette technique au texte même de la page, ce qui pourrait par le même moyen leaker par exemple un mail depuis un webmail dont on contrôle le style.

Au final une présentation un peu brouillon, mais dont les résultats sont édifiants.

Au passage, on notera que IE8 est doté d'une contre-mesure pour les attaques :visited, comme le fait remarquer un auditeur : il suffit de désactiver l'historique :)

Visualizing software security

Richard Johnson revient ici sur les différents types de graphes existants, et leur adéquation pour visualiser différents éléments relatifs à la sécurité.

La présentation fut très visuelle, avec de nombreux exemples montrant les forces et les faiblesses des histogrammes, arbres hiérarchiques pondérés, 'force-directed graphs'...Dommage que les slides ne soient pas disponibles.

On notera un mode particulier permettant de visualiser l'évolution d'un code source en colorant les lignes suivant leur auteur (à partir d'informations du gestionnaire de versions), utile pour voir quelles sections ont été manipulées par de nombreux auteurs, et donc potentiellement plus buggées.

Probing the Far Corners of Windows ? Using Code Characteristics to Find Security Bugs

Ian Hellen, de l'équipe sécurité Microsoft, nous montre une méthodologie pour essayer d'évaluer la probabilité d'existence de bugs dans un code source de manière automatique.

Elle est basée sur un système de notation suivant différents critères, permettant de déterminer quelles sont les éléments de code à auditer en priorité.Ces critères sont assez variés. On retrouve le nombre d'auteurs du code d'une fonction, l'age des lignes de code, une note suivant le prototype des API utilisées (utilisation de pointeurs, de tokens de sécurité, de buffers, utilisation de fonctions RPC...).Le rôle du code entre aussi en compte : s'il s'agit de code manipulant des données reçues depuis le réseau par exemple, ou s'il s'agit du code d'un module de sécurité (comme le firewall), celui-ci se verra attribué dès le départ une noteplus élevée.

Cette méthodologie semble efficace, car les résultats montrent une forte corrélation avec les vulnérabilités découvertes auparavant : les sections de codes responsables sont généralement marquées avec un haut score.Une possibilité d'évolution serait d'utiliser uniquement la base de donnée des bugs corrigés pour construire une sorte d'oracle, par exemple au travers d'un réseau de neurones, mais ceci permettra uniquement de donner une note sans pouvoir expliquer cette notation, ce qui peut être gênant.

Lightning talks

Une courte séance de lightning talks a clôturé cette première journée.

Introduction d'un framework de fuzzing de site web (injection automatique de SQL ou de JS), mais sans détection d'erreur du serveur, bizarre.

Une proposition pour renforcer la fonction rand() de la libc, que les programmeurs s'acharnent à utiliser pour des tâches requérant de l'aléas fort.Il est facile de remplacer rand() par une fonction utilisant par exemple rc4, le problème vient de la seed utilisée. Or une étude (sur google codesearch) montre que très souvent srand() est appelé avec un argument non reproductible, comme le PID du processus, ou la date courante, ou la somme des deux.Il pourrait donc être intéressant de modifier srand() pour détecter ces patterns d'initialisation, et dans ce cas utiliser une source d'aléas cryptographique, de manière à sécuriser beaucoup de programmes tout en restant compatible avec le code existant.

Enfin une rump complètement décalée, intitulée 'ode to calc'. Deux hackers nous chantent un ode à calc.exe, devant un slideshow de capture d'écrans où l'on voit défiler les PoC d'exploits exécutant des calc.exe à tout va. Très émouvant.

La deuxième journée est consacrée au SDL, et aux solutions concrètes pour les développeurs.

La journée commence par une série de rappels génériques sur la sécurité informatique :

  • La sécurité n'est pas binaire : on peut être plus ou moins sécurisé, chose qu'il est nécessaire d'évaluer
  • L'importance du risk managment
  • La perception du risque dans le monde virtuel : dans le monde réel, on sait que si une grosse voiture vous fonce dessus, il y a danger. Un utilisateur moyen

aujourd'hui sur internet n'aura pas du tout ce mécanisme de perception inhérente des risques, que ce soit face à un mail de spam, un site de phishing...

  • Les trois façons de traiter le risque :
  1. l'accepter (on vit avec),
  2. le mitiger (on essaye de le réduire),
  3. le transférer (on l'accepte, mais on reporte les conséquences financières sur un tiers, une compagnie d'assurance par exemple).

Pour mitiger efficacement les risques au niveau applicatif, il faut pouvoir passer à l'échelle, et pour cela automatiser les mécanismes de mitigation. En effet, on ne peut pas envisager de faire encadrer chaque développeur par un expert en sécurité.Cela passe donc par la création d'outils, et de partenariats avec des compagnies capables de délivrer l'expertise qui restera nécessaire.

Les deux présentations qui suivent sont des retours d'expérience sur certains de ces outils.

Leur but est de mettre la sécurité à la portée de tous les développeurs, contrairement à la plupart des méthodologies existantes qui nécéssitent de bonnes connaissances en sécurité, et souvent aussi la capacité à penser comme un attaquant, que ne possèdent pas forcément le développeur lambda.

Le protocole développé par l'entreprise EMC est destiné à l'établissement d'un threat model.La première étape est l'identification de la surface d'attaque, qui se fait ici au moyen d'un diagramme du dataflow dans le programme.Il faut ensuite identifier les menaces, ce qui se fait au moyen d'une checklist.Enfin, ces menaces sont classées suivant leur score CVSS, en répondant pour chacune à une courte série de questions.On peut alors passer à la phase de mitigation.

Il s'avère que cette méthodologie est efficace, et s'intègre assez bien dans l'arsenal du développeur. La sécurisation n'est alors plus vue comme une contrainte, ce qui est un point très positif.

Le même type de réflexion est appliqué aux logiciels SDL de Microsoft, et montre une convergence assez forte avec la méthodologie précédente.L'identification des menaces est ici réalisée en utilisant STRIDE, une méthode un peu plus complexe, mais avec laquelle les industriels sont déjà familiers, et qui est plus complète.

Mitigations Unplugged

Une présentation de Matt Miller, sur l'évolution des techniques de mitigation génériques déployées par Microsoft.

Ces moyens de mitigations sont destinées à contrer les techniques d'exploitations génériques existant sur les OS Windows. Ces techniques génériques permettent d'exploiter de manière fiable, pour un faible coût et peu d'expertise, une faille d'une catégorie donnée : stack overflow, heap overflow...

Les contre-mesures ont pour but de rendre fausses les assomptions faites par ces techniques génériques.

La première de ces contre-mesures est l'option de compilation /GS, ajoutée au compilateur C++ de Visual Studio 2002.Elle consiste en l'ajout d'un security cookie sur la pile des fonctions utilisant un buffer de données.Ce cookie est mis en place au début de la fonction, et vérifié avant que la fonction ne rende la main à son appelant.Ceci permet de contrer l'exploitation triviale des stack overflows, où l'attaquant réécrit l'adresse de retour de la fonction, ou bien manipule le frame pointer de la fonction appelante.

Cependant cette implémentation souffrait de deux problèmes principaux :

  • Un attaquant pouvait réécrire des variables locales à la fonction, ou ses arguments ; ceux-ci étant utilisés avant le retour de la fonction, l'exploitation restait possible (bien que moins générique). Ceci a été corrigé dans une nouvelle version de /GS, dans Visual Studio 2003, qui réordonne les variables locales des fonctions, et recopie ses arguments, avant les éventuels buffers, de manière à les immuniser contre l'écrasement.
  • Un attaquant peut également réécrire plus loin sur la pile, jusqu'à trouver un pointeur de gestionnaire d'exception (SEH). Ce handler étant celui-là même qui est appelé en cas de détection d'overflow par la vérification du sécurity cookie... La correction de ce problème arrive également dans Visual Studio 2003, sous le nom /SAFESEH : chaque module inclut une liste de gestionnaires d'exceptions, qui est vérifiée lors du dispatch des exceptions.

Ces deux contre-mesures sont activées pour les modules du système d'exploitation à partir de la version XP SP2.

Un problème subsiste, dans le cas où il existe dans l'espace d'adressage un module non compilé avec /SAFESEH. Dans ce cas un attaquant peut utiliser un 'trampoline' dans ce module pour parvenir à l'exécution de code arbitraire.La contre-mesure est /SEHOP, "SEH Overwrite Protection", disponible dans Visual Studio 2008. Là, le dispatcher d'exceptions va vérifier la validité de la liste chaînée de SEH, qui est réécrite lors de l'exploitation décrite précédemment. La vérification exige que cette chaîne se termine dans ntdll, par un pointeur prédéfini. Cette option est activée dans l'OS Windows Server 2008 (mais pas dans Vista SP1).

Pour lutter contre l'exploitation des heap overflows, plusieurs contre-mesures ont été déployées, cette fois au niveau du système d'exploitation (gestionnaire de mémoire), et non pas au niveau du compilateur.

  • La validité des pointeurs de liste doublement chaînée est vérifiée avant l'unlink() de chunks mémoire, contrant l'exploitation basique des heap overflows.
  • Des heap cookies de 8 bits sont introduits dans les look-aside buffers, pour contrer une technique plus sophistiquée d'exploitation.
  • Enfin les pointeurs des chunks mémoire sont carrément chiffrés maintenant.

DEP est également introduit en 2004, tirant avantage des fonctionnalités offertes par les nouvelles générations de processeurs pouvant rendre des pages mémoire non-exécutables.C'est une avancée très importante dans le domaine de la mitigation, qui peut toutefois être contrée par différents moyens :

  • return-to-libc: au lieu d'exécuter un shellcode que l'on injecte, on va exécuter une fonction existante dans l'espace d'adressage du processus (par exemple system("cmd")).
  • On peut également utiliser le return to libc pour exécuter VirtualProtect() sur la zone mémoire où l'on aurait injecté notre shellcode, de manière à la rendre exécutable.
  • Enfin on peut retourner sur NtSetInformationProcess(0x22), une fonction non documentée qui permet de désactiver complètement DEP pour le processus courant. Cette dernière attaque peut être contrée en bootant avec l'option /AlwaysOn, qui interdit la désactivation de DEP.

La réponse à ces problématiques est l'ASLR (Adress Space Layout Randomization, Randomisation de l'espace d'adressage).Cette technique, qui nécessite de recompiler les binaires en utilisant l'option /DYNAMICBASE, va modifier au moment de leur chargement (une fois par boot de la machine en général) l'adresse de base des modules (dlls et exécutable), en y introduisant un aléa de 8 bits dans les octets de poids fort. Comme la stack, et la plupart des adresses importantes (le heap, le PEB et le TEB) sont également placés à des adresses randomisées, il est alors impossible à un attaquant de connaître l'adresse exacte d'un élément en mémoire.La seule possibilité restante est de deviner cette adresse, et Vista intègre une service restart policy qui permet de limiter le nombre de fois où un service se terminant (par exemple à cause d'une exception causée par une tentative d'exploitation) est relancé, ce qui contre le bruteforce.Les limitations de l'ASLR sont l'existence éventuelle de modules non compilés avec l'option nécessaire, les attaques ne réécrivant que les deux octets de poids faibles d'une adresse (comme les off-by-one), et les programmes qui rattrapent toutes les exceptions, autorisant ainsi le bruteforce de la disposition de l'espace d'adressage. Il faudra également prendre garde aux programmes présentant des failles de type leak (fuite d'information), qui pourraient par exemple renseigner un attaquant sur une adresse particulière qui lui servira lors de la phase d'exploitation.

Matt termine cet exposé par une liste de pistes étudiées pour améliorer cet arsenal de défenses :

  • améliorer l'heuristique déterminant si une fonction à besoin d'être protégée par un security cookie,
  • augmenter l'entropie utilisée par l'ASLR sur les architectures 64bits,
  • interdire le mappage de l'adresse 0 (qui permet actuellement d'exploiter les Null pointer dereference),
  • porter certaines de ces techniques au mode noyau (notamment le kernel pool safe unlinking).

Il est également important de populariser au maximum l'utilisation de ces différentes techniques, car elles sont transparentes pour le développeur et renforcent énormément la sécurité d'une application. Il serait sans doute souhaitable d'activer toutes les options de sécurité par defaut dans Visual Studio.

Une excellente présentation, durant laquelle Matt montre une fois de plus son expertise sur le sujet.

L'intervention suivante vise à rappeler l'importance des race conditions dans les applications web, et la difficulté à les prévenir dans un monde où de telles applications tournent souvent sur de nombreuses plateformes en parallèle (pour le load balancing), et dépendent en même temps d'un backend lui-même multiple (ferme de bases de données).Une présentation assez générique sur le sujet, qui n'aidera pas forcément le programmeur à résoudre ce problème, mais qui aura au moins le mérite de lui rafraichir la mémoire.

Suit un retour d'expérience d'une team chargée du fuzzing au sein de Microsoft, plus particulièrement dans le domaine des parseurs.Il semble que les fuzzers intelligents ne soient pas beaucoup plus efficaces que les fuzzers triviaux (notamment les fuzzers utilisant des mutation d'un ensemble de templates). Par contre différents fuzzers vont souvent trouver un ensemble disjoint de bugs, il est donc important de ne pas se limiter à un seul fuzzer.L'expérience révèle que souvent une même section de code contiendra plusieurs bugs, donc si vous trouvez un problème à un endroit, n'hésitez pas à ausculter également le code environnant.Enfin un certain nombre d'astuces pour les auteurs de fuzzers :

  • utiliser un hash de la pile d'exécution (ou du sommet de la pile) pour essayer de rassembler les plantages liés à un même bug mais atteint par différents cheminements dans le code,
  • utiliser un allocateur mémoire patché de manière à détecter le plus tôt possible les heap overflows,
  • logguer les first-chance exceptions, de manière à détecter les comportements douteux du programme qu'il pourrait vouloir cacher à l'auditeur.

La dernière présentation, de Vinnie Liu, auditeur professionnel, nous révèle sur un ton ironique et souvent désabusé la réalité de la sécurité informatique au sein des entreprises.En général celle-ci n'est pas du tout prises en compte, sauf quand un jour quelqu'un va proposer l'idée de sécuriser le produit.Ce quelqu'un se retrouve alors souvent promu chef de l'équipe sécurité, qui comporte un membre, n'a pas de budget, et rarement d'outils adaptés.Il nous montre ensuite l'exemple d'un audit de portail Web, pour lequel différents outils lui ont été utiles :

  • Un analyseur statique pour trouver des failles de type injection SQL dans un site dynamique.
  • Un outil de bruteforce de path traversal.
  • Sa propre expertise, afin de trouver par exemple des backdoors, des faiblesses conceptuelles dans le produit, ou encore des erreurs de configuration, comme des questions "j'ai perdu mon mot de passe" trop simples à deviner ou bruteforceables ("quel est mon continent préféré", ...) ; choses qu'un outil automatique ne pourra jamais relever.

La journée se termine par un débat que j'ai eu un peu de mal à suivre, où il était notamment question d'un IPS très peu efficace, et des dégâts provoqués par la désinformation faite par les vendeurs de ce produit, ce qui conduit les DSI à prendre de mauvaises décisions dans la gestion de risques.

Au final, cette conférence fut très intéressante, avec une grande variété de sujets et d'auteurs de qualité, et un attachement au côté 'pratique' de la sécurité qui fait parfois défaut dans d'autres lieux. Et tout cela dans un cadre remarquable.