Source Address Validation Improvements (SAVI)
Conférencier : Jean-Michel Combes (Orange)
Le troisième et dernier jour du SSTIC commence par une présentation assez technique sur les contre-mesures possibles aux attaques basées sur l’usurpation d’adresses IP. Pas forcément facile à absorber un lendemain de social event, mais il est toujours possible de consulter les ressources une fois le mal de crâne passé à tête reposée.
La conférence s’ouvre sur une présentation des attaques les plus répandues, comme l’empoisonnement (ARP, DNS…) ou le déni de service (flood TCP…). Elle décrit ensuite les différentes propositions de contre-mesures publiées par l’IETF, ainsi que leurs limites.
Le corps de la présentation se concentre sur le dernier standard de ce type en date (SAVI) : son mode de fonctionnement, son niveau de déploiement actuel et les limites de la technique.
Très succinctement, le protocole se positionne en coupure au niveau des switchs. Il détermine le propriétaire légitime d’une adresse en se basant sur plusieurs éléments (adresse MAC, port de switch, etc.) et peut établir des zones de confiance pour le trafic.
Il est notamment déployé sur un réseau universitaire chinois où il agit sur un million d’équipements.
On peut remarquer que les limites du protocole vont au delà de la technique : en permettant de localiser les adresses IP, on entre par exemple dans les problématiques de vie privée.
Utilisation malveillante des suivis de connexions
Conférencier : Eric Leblond (OISF)
La présentation démarre avec un bref rappel sur l’implémentation du suivi des connexions avec netfilter : le système conntrack, qui fonctionne à merveille pour fournir un filtrage stateful avec les protocoles « simples » (ceux qui font transiter toutes leurs données sagement entre deux ports ; typiquement HTTP).
Vient ensuite le tour des protocoles moins dociles qui ont tendance à ouvrir des connexions un peu arbitrairement (FTP, SIP, etc.). Dans ces cas là, netfilter se base sur des helpers : des modules développés à part, qui inspectent le canal de contrôle des protocoles en question pour gérer les ouvertures de flux.
La question est simple : si ces helpers sont codés avec les pieds – comprendre « s’ils ne valident pas la légitimité des requêtes sur les canaux de contrôle » – le firewall ne devient-il pas un gigantesque open bar ? (spoiler : oui, mais ce n’est pas la fin du monde non plus)
Le problème vient des méthodes de contrôle des helpers. Au-delà des failles d’implémentation, on peut se retrouver dans des situations où la conception même d’un protocole ne permet pas de valider efficacement la légitimité d’une requête ; comme par exemple le DCC d’IRC.
Il est donc effectivement possible d’exploiter les helpers pour ouvrir des flux arbitrairement au travers d’un firewall. Par contre, les rêves d’accéder à un 3306 depuis Internet peuvent être étouffés dans l’oeuf. D’une part, les helpers dangereux sont désactivés par défaut. D’autre part, il est généralement nécessaire d’être sur le réseau local pour pouvoir exploiter les exploiter quand ils sont actifs.
En bref, un sujet très intéressant, qui vaut le coup d’être retenu. Et essayé en pentest interne, vu que le conférencier a publié son outil, et qu’il existe un script nmap qui permet de tester le comportement des helpers FTP.
Influence des bonnes pratiques sur les incidents BGP
Conférenciers : Sarah Nataf (Orange), François Contat (ANSSI), Guillaume Valadon (ANSSI)
En guise de hors d’oeuvre, les conférenciers annoncent avec une touche d’humour que cette année, il y a l’ANSSTIC, et… l’ANSSTIC par Orange :
La présentation commence avec une brève introduction à BGP : les prérequis pour le mettre en oeuvre (numéro d’AS, préfixes IP, la grosse tuyauterie qui fait transiter le tout entre les opérateurs) et le fonctionnement du protocole en lui-même (ouvertures de sessions entre les routeurs, annonces de préfixes).
La suite décrit les détournements possibles, et les bonnes pratiques à suivre pour s’en protéger. Les exemples présentent l’absence de protection par défaut sur les annonces de préfixes – donc la possibilité de les usurper ou d’annoncer des tables de routage contenant un nombre virtuellement illimité de préfixes. On cite le cas du Pakistan qui, en souhaitant bloquer YouTube au sein du pays avait annoncé des préfixes redirigés vers un « trou noir »… préfixes qui avaient été propagés aux routeurs au-delà des frontières, avec pour effet de rediriger pendant un temps le trafic mondial visant YouTube vers le Pakistan.
La dernière partie présente la vision des choses côté opérateur, et les mesures appliquées pour surveiller les réseaux et répondre aux incidents.
En conclusion, BGP est un protocole robuste, mais qui repose sur la confiance entre les opérateurs ; l’application des bonnes pratiques est donc indispensable pour assurer son bon fonctionnement. Les incidents sont d’ailleurs plus souvent causés par des maladresses et effets de bord imprévus que par des actes malveillants.
La matinée se poursuit avec une série de présentations courtes.
Netusse, par Clément Lecigne (Google)
Présentation d’un outil développé sur le temps libre de l’orateur : un fuzzer de sockets qui fonctionne de manière simple et efficace. Simple, parce qu’il se contente d’initialiser les sockets avec des opérations valides pour les placer dans un état favorable au fuzzing. Efficace, parce qu’il trouve des bugs exploitables : la fin de la présentation montre la découverte d’un bug dans le kernel FreeBSD et son exploitation jusqu’à obtenir une élévation de privilèges en local… non patchée au moment de la conférence.
Le conférencier a publié plusieurs de ses outils sur github.
Vérification de code par typage statique, par Etienne Million (EADS Innovation Works)
Description d’une méthode d’analyse statique. L’idée est d’identifier les pointeurs contrôlés par l’utilisateur qui accèdent à la mémoire noyau pour détecter les constructions dangereuses.
Site présentant l’outil et les projets connexes.
Blocage de canaux C&C de botnets par interception de requêtes DNS, par Ronan Mouchoux (TELECOM Bretagne)
L’idée d’interception des requêtes DNS vient du constat que les antivirus et autres protections habituelles sont inefficaces pour lutter contre l’ouverture des canaux C&C sur une machine infectée lorsque les malwares utilisent des noms de domaine générés pseudo-aléatoirement.
Le projet est toujours en développement, le but est d’implémenter plusieurs algorithmes d’identification de noms de domaines suspects et de les combiner afin de maximiser le taux de détection.
La matinée se termine par une conférence en anglais : Successes (and limitations) of (static) binary analysis
Conférencier : Halvar Flake (Zynamics)
L’orateur commence par résumer son propos : au cours des dix dernières années, d’énormes progrès ont été faits sur l’analyse automatisée de binaires et l’adoption de cette démarche a probablement aidé à corriger des millions de bugs… mais (il y a forcément un « mais ») il existe une quantité de morceaux de code en apparence simple qui peuvent présenter des bugs difficiles à comprendre, corriger, et sont évidemment indétectables par les outils d’analyse automatique.
La présentation montre l’exemple d’une fonction très simple (pas de multithreading, pas d’allocation sur le tas, etc.), mais qui présente trop de chemins d’exécution possibles pour être correctement analysée. Dans un autre registre, les navigateurs Web sont mentionnés. Ils représentent déjà des centaines de milliers de lignes de C++ très complexes à analyser… et intègrent un interpréteur JavaScript, qui permet de contrôler le chemin d’exécution du code dans le navigateur. Cette partie se termine par un mot sur l’analyse manuelle de binaires : il n’est pas toujours évident d’identifier les morceaux de code pertinents lors d’une analyse ; plonger dans un binaire est une tâche non triviale et hautement chronophage.
Au final, la meilleure méthode reste – sans surprise – une analyse manuelle aidée par les outils. On constate également qu’en 2012, on devrait être en mesure de produire du code propre, facile à analyser. Mais qu’on ne le fait pas. Je laisse Nicolas Ruff résumer la situation à sa manière.
Miasm : Framework de reverse engineering
Conférencier : Fabrice Desclaux (CEA)
L’après-midi commence fort avec quarante slides abattus en moins de trente minutes et un débit de parole moyen qui devait avoisiner les six mots à la seconde. Cette conférence était une expérience à vivre qu’aucun compte rendu ne pourra retranscrire. Mais on peut quand même dire de quoi ça parle.
L’objectif de Miasm est d’offrir une couche d’abstraction avec l’assembleur et de proposer un langage intermédiaire générique. D’une part, cela permet d’éviter de réapprendre la tétrachiée de spécificités lorsque l’on passe d’une architecture à une autre. D’autre part, cela permet d’appliquer des algorithmes (par exemple de recherche de vulnérabilités) directement sur ce langage intermédiaire.
Le framework intègre plusieurs fonctionnalités pouvant encore faciliter les démarches d’analyse : application de règles de simplification pour éliminer les premières couches d’obfuscation, reconstruction du flot d’exécution, recherche de code qui valide des contraintes pour trouver des sections propices au ROP, etc.
Les slides ; l’article. Et l’outil en question.
Rétroconception et débogage d’un baseband Qualcomm
Conférencier : Guillaume Delugre (Sogeti ESEC)
Un peu de contexte pour commencer : les basebands sont les puces intégrées aux téléphones qui gèrent les communications (GPRS, entre autres). Elles sont complètement séparées du processeur « système » des téléphones. Il s’agit d’un environnement difficile d’accès pour le reverse engineering : l’industrie est fermée, les spécifications s’étalent sur des millions de pages, les microcodes sont fermés… de manière générale, l’analyse nécessite de connaître l’environnement alors que la documentation manque. La recherche et l’exploitation de vulnérabilités est tout de même facilitée par la nature des environnements embarqués, qui ne bénéficient pas des techniques habituelles de protection comme l’ASLR.
Les techniques d’exploitation présentées montrent qu’il est possible d’envoyer des commandes de diagnostic au baseband, qui peuvent bénéficier généralement d’un accès arbitraire en lecture/écriture à l’ensemble de la mémoire.
Au final, les basebands sont utilisés pour gérer une grande quantité de fonctionnalités alors que les aspects sécurité sont négligés. Les nouvelles versions des systèmes embarqués commencent toutefois à intégrer certaines fonctionnalités anti-exploitation (canaries, etc.).
Protéger et défendre le cyberespace militaire : la démarche nationale
Conférencier : Arnaud Coustillière (état-major des armées)
Cette dixième édition du SSTIC s’achève par une présentation de la doctrine suivie par l’armée dans le cadre de la lutte informatique défensive.
Les besoins de sécurité au niveau de l’Etat peuvent se résumer à deux éléments : le Ministère de la Défense représente 295 000 personnes, tandis que les attaques visent de plus en plus les personnes avant de s’attaquer à l’infrastructure informatique, comme on a pu le voir avec RSA ou le Ministère des Finances. Les malveillances à l’origine des utilisateurs – volontaires ou pas – deviennent le point d’attention principal.
L’application de la doctrine est transverse aux théâtres d’opérations (terre, mer, air, espace) et concerne une multitude d’environnements : les infrastructures traditionnelles, l’informatique embarquée, les systèmes SCADA des plateformes de combat, les réseaux de surveillance, etc.
Les opérations (surveillance, protection, réaction sur incident, etc.) sont menées en collaboration entre le Ministère de la Défense et le SGDSN.
L’enjeu majeur reste la sensibilisation des utilisateurs, car chacun est une source de risque mais aussi un acteur de sécurité.
Les slides.
