Développement et évaluation d’obsfucations de
protocoles basées sur la spécification

Domaines d’application de la rétro-conception de protocoles 

Un des projets majeurs de rétro-conception de protocoles est le projet Samba [Samba Team 2018b] qui offre une implémentation open-source des protocoles SMB et CIFS pour des clients Linux permettant l’interopérabilité entre les systèmes Windows et Linux. En effet, la documentation d’origine n’était pas complète et en partie inexacte [Samba Team 2018a]. Cela a impliqué un lourd travail de rétroconception. Ainsi, à ses débuts en 1992, ce projet se basait principalement sur une rétro-conception manuelle du protocole, un travail complexe, fastidieux et chronophage, dont les résultats dépendaient fortement du niveau de compétence des analystes. De plus, pour rester pertinent le projet a dû suivre les nombreuses évolutions du protocole. Toutefois, l’interopérabilité n’est qu’un des domaines concernés par la rétro-conception de protocoles. La simulation de protocoles réseau [Leita 2005, Cui 2006, Newsome 2006, Caballero 2007a] est également un domaine pour lequel la rétro-conception peut être utile. Elle permet dans ce cas de créer des simulateurs de services réseau. Les intérêts de l’application de la rétro-conception à cette fin sont nombreux. Par exemple, un simulateur permet de réaliser rapidement des tests alors que communiquer directement avec le véritable composant peut être lourd voire impossible dans certains cas. Il permet également d’analyser le comportement de tous les composants sur un réseau en menant des études statistiques. Pour finir, il permet de rejouer, dans des environnements variés, des traces réseau en adaptant le contenu des messages. Le rejeu est utile, par exemple, pour analyser une attaque réseau dans un environnement contrôlé. Plus concrètement, la rétro-conception pour obtenir un simulateur peut être utile dans le cas de pots de miels qui vont ainsi pouvoir entrer en interaction avec des attaquants et enregistrer leur comportement. La rétro-conception de protocoles peut également être utilisée pour l’audit de sécurité de logiciels [Guihery 2012b, Caballero 2007b, Cui 2008]. Cette application est très proche de la précédente mais se distingue par son objectif qui est de solliciter un composant avec une grande variété de communications différentes pour vérifier que le composant se comporte normalement quelque soit le contexte de la communication. Ainsi, le modèle du protocole peut être utilisé pour fabriquer des fuzzers intelligents qui permettent de tester la robustesse de l’implémentation du protocole. Ces fuzzers génèrent des messages à destination du composant en modifiant certains champs des messages. Les messages qui déclenchent une vulnérabilité peuvent être traduits en signatures et ajoutés à un système de détection d’intrusion, par exemple. L’analyse de protocoles de malware [Bossert 2011, Caballero 2009, Caballero Bayerri 2010] s’appuie sur la rétro-conception. En effet, bon nombre de malware, comme les bots, utilisent des protocoles pour communiquer avec leur serveur de Command & Control. La rétro-conception de ces protocoles peut être particulièrement utile dans la mesure où elle peut permettre d’identifier des informations cruciales concernant la localisation du maître du botnet, une date, un type d’attaque imminente, ses cibles, etc. Elle permet d’anticiper sur l’occurrence proche d’attaques et ainsi d’améliorer la réponse à incident. Enfin, la rétro-conception peut être utile pour le test de conformité de protocoles réseau. Il s’agit de vérifier qu’un logiciel implémente correctement un protocole réseau dont les spécifications sont connues. La rétro-conception permet d’obtenir un modèle du protocole, tel qu’il est utilisé par le logiciel à l’étude, et de vérifier que ce modèle est en accord avec la spécification

Challenges de la rétro-conception de protocoles

 Les défis imposés par la rétro-conception de protocoles sont nombreux et variés. Ils ne sont pas tous traités systématiquement par chaque étude et il n’existe pas de solution ultime capable de traiter à la fois tous ces défis. Cette section est destinée à énumérer ces défis, identifiés en parcourant la littérature ou identifiés par notre propre expérience dans ce domaine. Pour débuter cette section, nous présentons les étapes classiques suivies lors de la rétro-conception de protocoles. Ensuite, pour chacune de ces étapes, nous identifions un défi principal qui influence la qualité globale de l’inférence. Ces défis seront ensuite utilisés pour déterminer de nouvelles obfuscations de protocoles. La rétro-conception ne débute pas directement par les activités de reconstruction du protocole. Ces activités sont précédées d’une identification et d’une caractérisation de l’environnement. Le bon déroulement de cette préparation dépend grandement du niveau de l’analyste, comme pour les étapes de la rétro-conception et elle est primordiale pour aboutir à une rétro-conception efficace, rapide et complète. Cependant, ces aspects ne sont pas développés dans ce manuscrit et nous nous focalisons sur les étapes de la rétro-conception elle-même. Sur la base de la connaissance de l’environnement, l’analyste peut débuter cette rétro-conception, en commençant par une étape d’observation qui consiste à mettre en place l’outillage et récupérer les données qui permettront de réaliser la rétro-conception du protocole. La seconde étape vise à pré-traiter les observations pour les associer aux différents messages du protocole. La dernière étape permet d’inférer le format des messages ou la grammaire du protocole directement à partir de ces données. Bien entendu, ces étapes ne sont pas exécutées en boucle ouverte. Autrement dit, un résultat d’une de ces étapes peut amener l’analyste à revoir sa stratégie concernant les premières étapes. De plus, l’expérience et l’intuition de l’analyste peuvent réduire l’effort dédié à certaines de ces étapes. Par exemple, la rétro-conception d’un vers qui utilise un canal Command & Control sur IRC sera réalisé rapidement par un analyste qui connaît déjà ce type de protocoles. La Figure 1.2 illustre les étapes de la rétro-conception en mettant en évidence les sous-étapes pour lesquelles nous avons identifié des défis majeurs. La suite est consacrée à la présentation de ces étapes. 

Étape d’observation

 L’inférence se base sur l’obtention d’un ensemble de traces par observation du système. L’obtention de ces traces amène deux défis importants. Le premier concerne le placement de la sonde et le second concerne la génération de ces traces. Le placement de la sonde est déterminant pour l’obtention des données indispensables à la rétro-conception des protocoles. Les défis ne sont pas les mêmes pour l’approche d’inférence réseau ou pour l’approche d’inférence applicative. Pour l’inférence réseau, le placement de la sonde peut sembler évident mais il peut aussi devenir délicat lorsque le protocole utilise plusieurs canaux de communication. Dans ce cas, il faut identifier le canal qui va véhiculer les messages liés au protocole à rétro-concevoir et il peut même être nécessaire d’envisager l’usage de plusieurs sondes, ce qui nécessite la synchronisation des différentes sondes pour conserver l’ordre des messages. Le placement doit également permettre de collecter tous les messages nécessaires à la reconstruction de tout le protocole ou de la partie intéressante. Une faiblesse au niveau de ce placement peut se traduire par des messages non observés, la reconstruction du protocole sera donc partielle. Si dans certains domaines d’application, cette faiblesse n’est pas forcément gênante, elle peut empêcher son application dans d’autres domaines où le rejeu, par exemple, est un objectif. De plus, la difficulté du placement est accentuée par l’usage de mécanismes cryptographiques qui rendent l’interprétation des traces difficile voire impossible. Il est alors nécessaire soit de casser le mécanisme cryptographique, soit de se placer aux extrémités du canal de communication, c’est-à-dire de créer une sonde placée dans l’application aux interfaces des librairies cryptographiques pour retrouver les messages en clair. Ainsi, outre le placement de la sonde, une difficulté technique s’ajoute parfois à ce défi et concerne le développement de la sonde pour l’observation. Cette difficulté est plus poussée encore lors de l’inférence applicative qui s’appuie sur des traces d’exécution de l’application. Ainsi, la sonde doit produire la séquence des instructions exécutées par l’application lors du traitement de messages, mais aussi l’état de la mémoire du système. Plusieurs solutions existent (débogage, instrumentation, virtualisation. . .) mais elles doivent toutes faire face à différents défis tels que : la présence de protections contre l’analyse (contrôle d’intégrité du code, anti-debogue. . .), ou tout simplement le ralentissement de l’application qui peut provoquer des pertes de messages suite à un dépassement de délai. La trace (réseau ou d’exécution) constitue la donnée principale pour rétroconcevoir le format du message ou la grammaire du protocole. La qualité de cette trace dépend du positionnement de la sonde, comme abordé dans le paragraphe précédent. Par contre, cette qualité peut également être influencée par la durée de l’observation. Évidemment, pour un même protocole, une observation courte fournira probablement une trace plus courte qu’une observation longue. Cela ne veut pas pour autant dire qu’une observation courte est insuffisante. Effectivement, il suffit simplement qu’elle ait capturé l’ensemble des états possibles de la communication et les liens entre ces états, de sorte à inclure tous les formats possibles de messages et tous les scénarios d’échange des messages possibles. Une trace trop pauvre amène à ne reconstruire qu’une partie de la spécification du format du message ou de la grammaire du protocole. La question est donc de savoir à partir de quel moment la trace est assez riche et diversifiée. Bien entendu, cela dépend de la nature des composants qui communiquent et de la fréquence des communications. Dans certains cas, l’analyste peut avoir une approche active : soit en forçant les échanges, soit en perturbant l’environnement (ce qui lui donne des indications sur la nature des échanges), soit en employant son propre composant pour communiquer.