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

Télécharger le fichier original (Mémoire de fin d’études)

Évolution des outils de rétro-conception de proto-coles

De nombreuses contributions ont fait évoluer la rétro-conception de protocoles. Les outils présentés par la suite se basent principalement sur deux contributions majeures. Le premier outil, PI Project [Beddoe 2004b], a introduit les algorithmes de bio-informatique pour l’inférence réseau de format de messages. Le second outil, Polyglot [Caballero 2007b], a présenté une nouvelle technique d’inférence de format de message à partir de traces d’exécution d’une application traitant une entrée. Le tableau 1.1 présente les différentes publications associées aux outils d’inférence réseau et applicative respectivement. Les outils en gras sont ceux utilisant une approche active. Ces diagrammes montrent que ces outils se sont majoritairement concentrés sur l’inférence de format de messages, l’argument principal développé dans la littérature est qu’avant de pouvoir inférer la grammaire du protocole, il faut que le format des messages soit connu. De plus, nous constatons que l’inférence active commence tout juste à voir le jour dans ce domaine.

Inférence réseau

Dans [Beddoe 2004a, Beddoe 2004b], l’auteur présente l’outil, PI Project 1 pour réaliser la rétro-conception du format de messages à partir de traces réseau. Cet outil laisse donc de côté l’inférence de la grammaire du protocole. Il emploie l’algorithme Needleman & Wunsch [Needleman 1970] pour aligner les séquences d’octets entre les messages pris deux à deux. L’alignement optimal permet d’identi-fier les parties communes entre deux messages qui correspondent, selon l’outil, aux mêmes champs. Ce résultat est utilisé pour construire un arbre correspondant à la classification hiérarchique des messages en fonction de leur degré de similitude (les messages les plus similaires se trouvent sur des feuilles voisines de l’arbre). L’algorithme employé est UPGMA [Nei 1983]. Par contre, l’utilisateur de cet outil doit partitionner manuellement cet arbre pour identifier les classes des messages. La majorité des outils d’inférence réseau de format de messages, parus par la suite, s’appuie sur ces travaux.
Peu après, Leita et al. ont proposé l’outil ScriptGen [Leita 2005, Leita 2008], qui a pour objectif de générer des scripts de simulation réseau du comportement d’un serveur, pour le pot de miel Honeyd. Contrairement à PI Project, l’inférence de la grammaire du protocole est nécessaire à cet outil pour atteindre cet objectif. Tout d’abord, ScriptGen opère une phase de pré-traitement correspondant d’une part au filtrage des paquets réseau pour conserver uniquement les paquets TCP des communications à simuler et d’autre part à la reconstruction des messages à partir de ces paquets. Concernant l’inférence du format des messages, l’approche player [Cui 2006] qui a pour but de rejouer des communications dans un nouvel environnement, notamment pour étudier plus en détail le déroulement d’une attaque réseau. Le rejeu nécessite d’adapter une trace aux caractéristiques de l’environne-ment (par exemple, changement d’adresses IP, de numéro de séquencement, etc.). Il s’agit donc d’avoir une connaissance précise des champs des messages et de leurs dépendances. Pour traiter ce défi, Roleplayer utilise une inférence active durant laquelle des communications sont initiées par l’outil lui-même pour identifier ces dépendances. En appliquant également un algorithme d’alignement, il est capable d’apprendre des dépendances entre les champs d’un message (par exemple, la taille, les valeurs cookies, etc.) sans pour autant être capable d’identifier les encapsulations de champs. S’appuyer sur les résultats de cet apprentissage permet d’analyser plus finement les attaques qui ne contiennent pas beaucoup d’échanges.
Face aux difficultés rencontrées pour identifier correctement les champs d’un message, Cui et al. ont proposé une nouvelle approche dans l’outil Discove-rer [Cui 2007a]. Leur inférence ne repose plus sur l’algorithme de bio-informatique Needleman & Wunsch. Ils supposent à présent connus les délimiteurs des champs (espaces, retours à la ligne, indentations, virgules, etc.), ce qui simplifie grandement le problème. Suite à ce découpage, l’outil enchaîne avec une classification hiérar-chique et récursive des messages qui présente l’avantage de reconnaître des situations d’encapsulation des champs. Pour finir, une série d’heuristiques est appliquée pour retrouver des dépendances entre les champs.
Alors que la recherche sur l’inférence de protocole se focalisait sur l’inférence du format des messages, l’outil Veritas [Wang 2010, Wang 2011] vise principalement
à construire la grammaire du protocole. Sans nécessiter le format des messages, il lui est indispensable de connaître la classe de chaque message. Pour identifier ces classes, l’outil se base sur les séquences d’octets les plus fréquemment observées dans leur en-tête (les n premiers octets). Les auteurs font ainsi l’hypothèse que l’en-tête d’un champ est localisée au début du message et que celui-ci contient des séquences d’octets caractéristiques de la classe du message. Non seulement cette hypothèse est généralement vérifiée pour faciliter l’interprétation du message, mais de plus, en procédant de cette manière, il réduit considérablement le volume des données à traiter. Les séquences d’octets fréquentes servent donc à classer les mes-sages. Il enchaîne ensuite avec l’inférence de la grammaire du protocole. Pour cette étape, les auteurs supposent que les messages qui peuvent être émis dépendent uni-quement du dernier message observé et non de tout l’historique des échanges. Le modèle construit par cet outil est donc naturellement un automate étiqueté avec les classes de messages. Notons qu’avec cette approche, Veritas exclut volontairement les séquences d’octets rares qui peuvent correspondre à des données ou à un com-portement inhabituels du serveur. Dans ce dernier cas, la grammaire du protocole obtenue est partielle et ne représente pas tous les comportements inclus dans les échanges observés.
Pour leur part, Krueger et al. ont développé l’outil ASAP [Krueger 2010] pour aider l’analyse de données issues de pots de miel, la conception d’IDS (systèmes de détection d’intrusions) et l’analyse de malware. Dans ce contexte, cet outil se  focalise plus sur la classification des messages qu’à l’obtention du format exact de ces messages. Il utilise aussi un découpage des messages en champs, en fonction de délimiteurs prédéfinis pour des messages au format texte ou en séquences d’octets de taille fixe pour les messages au format binaire. Chaque message peut alors être caractérisé en fonction des champs qu’il contient et représenté sous la forme d’un vecteur. Les classes de messages sont identifiées comme étant des messages types qui constituent une base pour la génération de tous les messages observés, au sens algébrique. Au delà des choix concernant les outils statistiques et la manière de découper les messages, ASAP se distingue donc principalement des autres outils par l’usage d’une approche algébrique. Par contre, le format obtenu n’est pas très précis et ne met pas en évidence les liens entre les champs ni leur ordre d’apparition ou les champs qui seraient à cheval sur deux lignes ou deux séquences d’octets.
Par la suite, les développeurs de ASAP ont étendu leur outil en y ajoutant une capacité d’inférence de la grammaire de protocole, ce qui a donné lieu à la création de l’outil PRISMA 2 [Krueger 2012]. Cet outil emploie globalement la même stratégie que ASAP. Par contre, l’analyse algébrique des messages est remplacée par une classification basée sur une distance pour regrouper les messages en classes. Ensuite, l’outil analyse les séquences de classes de messages pour en déduire une chaîne de Markov cachée. L’usage de ce modèle présente l’avantage de pouvoir représenter des changements d’état du protocole qui ne se traduisent pas nécessairement par l’envoi d’un message.
À l’opposé des approches précédentes, l’outil ReverX 3 [Antunes 2011] utilise une approche unique : il traite le format des messages de la même manière que la grammaire du protocole. À l’instar de Discoverer, cet outil se base sur une liste connue de délimiteurs pour découper les messages en champs. Ces séquences sont assemblées sous la forme d’un arbre qui est à son tour replié sur lui-même. Ce repli aboutit à un automate contenant des boucles qui sont utiles pour généraliser le mo-dèle à des messages non observés. Cet automate correspond ainsi aux formats des messages. La grammaire du protocole est reconstruite de la même manière, en par-tant des séquences de classes de messages. Cet outil offre des résultats intéressants, notamment au niveau de la généralisation du format des messages, qui constitue un défi important. Par contre, la stratégie qu’il emploie pour découper les messages en champs ne le rend pas adapté à l’analyse de messages binaires.
Pour terminer, citons l’outil Netzob 4 qui a fait l’objet de nombreux travaux différents et qui a connu de multiples évolutions ces dernières années. Il a dans un premier temps été conçu pour la modélisation de botnets [Bossert 2011]. Les auteurs utilisent une variante d’une machine de Mealy pour représenter la gram-maire du protocole, en enrichissant cette machine par des informations sur le temps d’attente entre deux messages observés. Cette grammaire de protocole est apprise de manière active à partir de l’algorithme L∗ [Angluin 1987]. Cet auto-mate est ensuite rendu non-déterministe en incorporant des probabilités

Table des matières

Liste des Abréviations
Introduction
1 La rétro-conception de protocoles
1.1 Définitions pour la rétro-conception de protocoles
1.2 Domaines d’application de la rétro-conception de protocoles
1.3 Challenges de la rétro-conception de protocoles
1.3.1 Étape d’observation
1.3.2 Étape de pré-traitement
1.3.3 Étape d’inférence
1.4 Évolution des outils de rétro-conception de protocoles
1.4.1 Inférence réseau
1.4.2 Inférence applicative
1.5 Conclusion
2 Obfuscations de logiciels et de protocoles
2.1 Terminologie
2.2 Obfuscation logicielle
2.2.1 Obfuscations appliquées sur le code source : pre-build
2.2.2 Obfuscations appliquées sur le binaire : post-build
2.2.3 Obfuscations appliquées sur les données
2.3 Obfuscation de protocoles
2.3.1 Randomisation
2.3.2 Imitation
2.3.3 Tunneling
2.3.4 Programmable
2.3.5 Cryptographie
2.4 Conclusion
3 Obfuscations de spécification de protocole
3.1 Modèle de format de messages
3.1.1 Définitions
3.1.2 Exemple
3.1.3 Parseur et serialiseur
3.2 Obfuscations des GFM
3.2.1 Contraintes sur les transformations
3.2.2 Les transformations d’agrégation
3.2.3 Les transformations d’ordonnancement
3.2.4 Composition et application des obfuscations
3.3 Validation Coq
3.3.1 Coq : validation du parser et du serializer
3.3.2 Coq : validation des obfuscations
3.4 Conclusion
4 Implémentation de ProtoObf
4.1 Architecture de ProtoObf
4.2 Implémentation
4.2.1 Spécification du format de message : DSL
4.2.2 Implémentation des obfuscations
4.2.3 Génération de code par des templates
4.2.4 Intégration dans un projet continu : CMake
4.3 Différences avec le modèle
4.4 Conclusion
5 Expérimentations
5.1 Exemples de protocoles
5.1.1 Tcp-Modbus
5.1.2 HTTP
5.1.3 Running test
5.2 Évaluation du fonctionnement du prototype
5.3 Évaluation des performances du prototype
5.3.1 Mode opératoire
5.3.2 Benchmark
5.4 Conclusion
Conclusion
A Parse et serialize
A.1 Parse
A.2 Serialize
B Spécification de protocoles dans le DSL
B.1 Protocole TCP-Modbus
C Détails sur les templates de génération de code
C.1 Exemple de référence pour la génération du code
C.2 Les prototypes
C.3 Structures internes
C.4 Code
C.4.1 Allocate et Free
C.4.2 Initialize et Finalize
C.4.3 Parse, Serialize et GetSize
C.4.4 accesseurs directs
C.4.5 CMake
C.4.6 Project code

Télécharger le rapport complet