Making network protocols go crazy

Aller au contenu | Aller au menu | Aller à la recherche

Compte-rendu CanSecWest 2010 - jour 1

Wednesday March 24

La matinée de cette première journée est consacrée à l'enregistrement des participants. Environ 500 personnes présentes dans la salle.

13:00 - 14:00 Internet Nails Marcus Ranum, Tenable

Une histoire de bad software engineering et de bad design ; où comment une petite erreur de design peut couter très cher. En 1971, FTP est inventé et codé. Les premières versions de transport d'email était faite via FTP. En 1976, NCP. Qui était l'ancêtre de TCP. Fonctionnement a sens unique, pas encore de full-duplex. Suivi d'une explication sur le fonctionnement de FTP.

Question clé : peut-on parler de design pour FTP dans un monde de software a cet époque ?

Puis, description sur la difficulté de faire fonctionner FTP au travers d'un firewall. Blabla sur l'introduction des firewalls. Le premier produit commercialisé en 1991 coutait $175,000. L'idée est que le design de FTP de l'époque coute des millions aujourd'hui, a cause de la difficulté de filtrage de ce protocole au niveau firewall. Puis une autre histoire : pour décharger le noyau, les Sockets BSD furent introduit. Le but était d'accepter un plus grand nombre de connections. Mais il fallait garder une table des sockets ouvertes, et cela n'a pas protégé contre le SYN flooding. En 1995, le protocole HTTP a été imaginé pour être stateless, aussi pour décharger le noyau. HTTP fonctionne en ouvrant de nombreuses connections TCP short-lived. Ce fut lent, et les codeurs de navigateurs Web décidèrent de faire ces connections en parallèle ...

Résultat : du surf plus rapide, mais plus de load sur le réseau et le serveur.

Aujourd'hui, on a amélioré le code gérant les short-lived connections pour résoudre ces problèmes. En 1997, le E-commerce. Problème avec HTTP, aucun état n'est maintenu, et c'est devenu nécessaire (gestion de l'authentification, garder la liste des courses ...). Ainsi des frameworks de développement furent introduit pour garder l'état des connexions via un session management. Tout cela, parce que HTTP a été designé pour être stateless. Quel coup pour tout ceci ? Sans compter les erreurs de codage menant à toutes les failles que l'on connait. Vient ensuite la gestion de la charge. Chaque load balancer doit garder l'état pour savoir où rediriger les requêtes et éviter de briser l'état de la session. Tout cela alors que TCP/IP sait déjà gérer l'état d'une session ... et en plus de ré-implémenter une gestion de session, nous avons de nouvelles classes de vulnérabilités (XSS, XSRF, ...).

Conclusion : un mauvais design coute extrêmement cher. D'où l'idée de développer le "design intelligent" mais par un visionnaire omniscient. Le soft est au coeur de tout, on doit faire mieux, être moins concernés par le "backward compatibility" et être plus au fait des conséquences d'une petite décision de design.

14:00 - 15:00 Under the Kimono of Office Security Engineering - Tom Gallagher & David Conger, Microsoft

Respectivement Senior Security Test leader et Software Design Engineer. Historique des menaces : macro virus principalement. Avant 2006, tèrs peu d'attaques sur le format des documents eux-même. Quand Microsoft a vu que les failles commençaient a être commercialisées, ils ont décidé d'investir pour éviter les failles dès le début. Nouvelles organisation : chaque produit à une liste de contacts sécurité. Chaque produit à une liste de feature owner.

1. Harden the attack surface : suivre le SDL, automatiser la revue de code, SafeInt?, suppression des vieux parseurs (exemple : 3 parseurs différents pour JPEG), fuzzing distribué (300+ formats de fichier à supporter, certains n'étant pas simples et nécessitant des fuzzers particuliers). Suivi d'une explication sur le fuzzing distribué, qui pourrait être utilisé pour les tests en général. L'idée est de centraliser la gestion du fuzzing : les tests, les résultats, les erreurs et les rapports. Le but est aussi de répartir la charge pour exploiter les machines non utilisées. Microsoft a developé un client de fuzzing distribué facile à utiliser par tous les dveloppeurs. Un serveur avec interface Web centralise le tout. Une fonction intéressante permet de re-tester contre les régressions, en prenant par exemple une call stack d'erreur en input. Également la possibilité de tester les même bugs sur différents produits. Pour chaque bug trouvé, toutes les infos sont disponibles (état des registres, call stack complète ...). En gros, ils ont fait un botnet sur leur réseau qui sert à faire du fuzzing. Ils ne se posent pas la question de l'exploitabilité d'un bug quand ils en trouvent un, ils le patch (au minimum, ca rendra le produit plus stable).

2. Reduce the attack surface : File Block (exemple: bloquer les formats non utilisés) et Gatekeeper (évaluation de la 'correctness' des fichiers à l'ouverture, avec mécanisme de mise à jour des informations de 'correctness'). Demo. En gros, ils ont mis un anti-virus dédié aux formats de fichier dans Office.

3. Mitigate the Exploits : Création d'un Office 'Protected Viewer' qui classe toutes les sources venant d'Internet comme untrusted. Architecture avec un processus Host et un processus Client. Utilise des composants de sandboxing (isolation des processus). Ceci est géré par wwlib.dll, qui lance une instance de winword.exe dans une sandbox.

4. Improve the User Experience : l'améliorer en rapport avec la confiance. A l'avenir, en prenant l'exemple de l'ouverture d'un attachement mail : Open > Gatekeeper Validation > Sanboxed Viewer > User Clicks enable > Document Opened. Ensuite, le user peut le sauvegarder, et le rouvrir sans ces checks. Option très intéressante pour regarder les "conneries" envoyées par les potes, les documents sont vus dans la Sandbox, et ne doivent pas pouvoir abimer le système (exemple pris tel quel par l'orateur).

Conclusion : Ils ont d'abord décris un processus de tests bien fait, pas forcément orienté uniquement sécurité. Ensuite, ils ont décrits les améliorations apportées à Office qui elles ont été pensées pour la sécurité.

15:00 - 15:30 Break

Quelqu'un s'est amusé à broadcaster le SSID "CanSecWest". C'était évidemment un faux.

15:30 - 16:30 Automated SQL Ownage Techniques - Fernando Federico Russ, Core

Description d'une méthode blackbox automatisée d'intrusion SQL. La vulnérabilité est exploitée de manière à éviter les "False Positives". Première étape de reconnaissance. Un web spider utilisant un MitM proxy. Reconstruction des QUERY_STRING et parfois du chemin de l'URL (cas mod_rewrite). Parcours aussi les champs HTML <form>. Fonctionne en mode fuzzing, et peut potentiellement abimer l'application. Détection des erreurs (HTTP error codes, error strings, redirections ...). Pour déterminer la présence d'une injection, une liste de test retournant true/false est jouée. Si true, alors on contre-test par une autre méthode pour confirmer. C'est une technologie de type système expert. Une autre fonction est de déterminer le type de la base de donnes (produit, version). La méthode retenue : du brute-force sur les fonctions possibles (HEX() pour DB2, HOST_NAME() pour SQL Server, VERSION() pour MySQL, ...). L'implémentation tourne autour d'une couche d'abstraction nommée "channel". Elle fournit une API (UNION, Scalar, Blind, ...).

ooo Le téléphone rouge sonne, Charlie Miller semble avoir exploité avec succès une faille dans l'iPhone. Il gagne un truc ^^ ooo

L'outil permet de savoir si la requête exploitée est de type SELECT. Il détecte la morphologie (nombre de colonnes, leur type, la visibilité dans le HTML, ...). Un exemple d'utilisation : remplacer la vrai requête par la notre (SELECT user,pass FROM credentials). Pour que cela marche, il faut détecter le nombre d'élément de la requête d'origine (ici 2), et leur type (ici string). Si c'est le cas, nous pouvons construire la requête de l'exemple. Si les types ne sont pas les mêmes, on peut utiliser des fonctions pour "caster" les valeurs. Pour extraire toutes ces informations, une requête SQL CASE est utilisée (CASE WHEN ... THEN ... ELSE). Mais cela permet uniquement d'extraire bit par bit (un bit étant true/false).

ooo Le téléphone rouge sonne de nouveau, une nouvelle faille a été trouvée (IE? 64-bit). ooo

16:30 - 17:30 Can you still trust your network card? - Yves-Alexis Perez & Loïc Duflot

Yves-Alexis et Loïc travaillent pour l'ANSSI (Agence Nationale de SSI). Tout type de carte réseau. Leur hardware est complexe (plusieurs processeurs, différents types de mémoire, ...). Leur firmware est complexe (gestion de la segmentation TCP en offloading, remote management, ...). Ça n'a rien a voir avec les bugs drivers ou les vulnérabilités de l'OS. Description de l'architecture. PHY (send/recv sur le réseau), DMA-engine (send/recv sur le bus interne), negociation and link control (full-duplex, ...). Explication pour la carte Broadcom intégrée sur certains NIC. La carte possède un processeur MIPS, le firmware permet une customisation pour processer des paquets propriétaires par exemple. La mémoire interne de la carte est mappée sur la mémoire de la machine hôte. Protocole ASF. La carte réseau reçoit les évènements des autres devices de la machine via SMBus. Utilisation du protocole RMCP pour rebooter et autres actions ... ASF n'a aucune interface sécurité de prévu, et les fabriquant ne sont pas vraiment incités à en faire.

ooo Le téléphone rouge sonne : Firefox sous Windows 7. ooo

ASF 2.0 ajoute un nouveau protocole : RSP. Des extensions sécurité pour RMCP, comme l'authentification et le contrôle d'intégrité. Mais pas de chiffrement. RMCP est en écoute sur 623/UDP. La version secure sur 664/UDP. Broadcom fournit un outil de configuration ASF. Ces paquets UDP ne sont jamais vu par l'OS, puisque interceptés par la carte réseau avant.

Vulnérabilité potentielle sur le protocole d'authentification (réduction de l'entropie). Problème d'implémentation sur le username (CVE-2010-0104), limité à 16 caractères sans null byte avec 1 byte pour spécifier sa longueur. Nécessité de déboguer la carte réseau par un débogueur de NIC (accès aux registres du processeur MIPS). Ils ont développé un débogueur NIC maison. Ils ont ensuite pu écrire un exploit pour la faille trouvée dans la gestion du champ username. Comme il n'y a que 255 octets (moins le padding) pour placer le shellcode de l'exploit, ils utilisent l'accès aux network buffers pour placer leur shellcode. En effet, le NIC est le mieux placé pour accéder aux network buffers. NIC utilise le DMA engine ; il peut donc lire et écrire la mémoire de la machine hôte. Un paquet réseau exploitant une faille peut donc être utilisé pour écrire des données dans la mémoire de la machine hôte sans contrôler son OS.

Suivi d'une démo sur l'amélioration de leur exploit : lancement des paquets RMCP exploitant la faille. Puis d'un message ICMP magique. Enfin, un rootshell en écoute sur le port 2 est activé. De plus, faire un ps sur la machine victime montre juste un shell, et un khelper (donc, attaque assez stealth).

Note : Le débogueur accède aux registres de la NIC via le driver local qui lui, à accès aux registres du processeur de la carte NIC via un mapping mémoire. Pas besoin de JTAG et compagnie.

Conclusion : Ce n'est pas encore le moment de paniquer. Peu de cartes supportent ASF, et encore moins l'ont activé par défaut.