Table des matières

1 Motivation

1.1 Coopération entre programmes d'analyse

En sécurité informatique, une multitude de programmes existent pour assister l'humain dans la résolution d'un problème. Ces programmes étant très spécialisés, il est souvent nécessaire d'en utiliser plusieurs pour un besoin donné.

Le besoin de les faire travailler de concert s'est d'abord fait ressentir sur nos propres outils. Par exemple, nous utilisons les outils suivants lors du reverse engineering de binaires :

• elfesteem [3] pour la manipulation de chiers ELF et PE ;
• miasm [8] pour de l'assemblage/désassemblage/émulation/JIT/exécution symbolique supportant plusieurs architectures, etc. ;
• amoco [2] pour de l'assemblage/désassemblage/exécution symbolique supportant plusieurs architectures ;
• grandalf [4], un framework de dessin et navigation de graphes ;
• des analyseurs statiques ;
• des outils de classication de binaires ;
• des unpackers ;

Ce besoin s'est vite étendu à d'autres utilitaires tels que IDA, BinDi, gdb, strace, PEID, libmagic, ou plate-formes telles que cuckoo, FireEye MAS, IRMA et également à d'autres thématiques que l'analyse de binaires.

Dans le domaine de la découverte de services réseau/pentest, il est en eet intéressant de faire coopérer les outils suivants :

• un scanner de port (nmap, scapy, etc.)
• un banner grabber (nc, nmap, etc.)
• un outil déterminant des ciphersuites & protocoles supportés (openssl, etc.)

On peut également citer d'autres domaines pour lesquels des travaux d'analyse nécessitent l'utilisation conjointe de plusieurs outils : l'analyse forensique de disque dur ; l'analyse de certicats ; l'analyse de code JavaScript.

Ce besoin de croiser les résultats de diérents outils pose plusieurs problèmes :

• comment stocker les résultats intermédiaires ? En eet, ceux-ci ont un intérêt, particulièrement lors d'une première analyse à tâtons  ;
• comment rendre compatibles les diérentes interfaces d'entrée et sortie (stdin/stdout, écriture de chiers sur le disque, appels REST, etc.) ;
• même question pour les formats des entrées/sorties ?

De plus, certaines tâches sont répétitives et gagneraient à être entièrement automatisées.

1.2 Vue générale de REbus

Nous présentons ici une réponse à ces problèmes, sous la forme d'un bus de communication, nommé REbus. Ce bus est utilisé par les programmes à faire collaborer. Ces programmes seront dénommés agents dans ce qui suit et la communication entre ces agents est appelée message. Les objectifs principaux de REbus sont décrits ci-dessous.

La reproduction et l'enregistrement des analyses. REbus facilite les expérimentations et le développement de nouvelles techniques d'analyse : les expériences peuvent être rejouées et les résultats sont consignés pour pouvoir être étudiés.

L'intégration facile de nouveaux agents. REbus fournit un ensemble de services pour ajouter un agent sans avoir à intervenir sur le bus lui-même ni sur les agents déjà présents, et ce même si ce nouvel outil doit interagir avec eux.

Un fonctionnement décentralisé. REbus privilégie l'exhaustivité de l'analyse et la simplicité des interfaces à l'ecience du traitement : chaque agent prend indépendamment la décision de travailler ou non sur les messages qui lui sont envoyés.

Trois modes d'utilisation. À partir du même ensemble d'agents, REbus peut être utilisé de trois façons :

• en mode outil an de créer un nouveau super-outil rendant un service spécialisé. Par exemple, pour du reverse engineering, en combinant un agent qui unpacke un binaire donné en entrée, un autre qui extrait le CFG (Control Flow Graph graphe de ot de contrôle) du binaire obtenu, et un troisième qui l'ache ;
• en mode infrastructure, mettant à disposition les services des agents sur une durée indénie,
• en mode feu de camp, où plusieurs analystes font tourner des agents sur leur machine, et les connectent à un bus partagé le temps d'un projet (rétro-ingénierie d'une application complexe, caractérisation d'un ensemble de malware, etc.).

Sécurité. REbus n'intègre pas d'authentication, de contrôle d'accès, ni de vérication d'intégrité des messages échangés. L'exploitation d'éventuelles vulnérabilités dans les outils d'analyse utilisés (ex. des vulnérabilités ont déjà existé dans strings [12], antivirus, etc.) est possible. Il est recommandé de manipuler des données potentiellement dangereuses (ex. malware, chiers produits par un tiers non de conance) dans des environnements isolés (machines virtuelles, docker, conteneur LXC, seccomp, etc.). L'utilisation automatique de mécanismes d'isolation lors du lancement d'outils externe est une évolution prévue de REbus.

Le reste de ce document est structuré de la façon suivante : la section 2 décrit REbus ; la section 3 fournit des exemples d'utilisation de REbus et la section 4 conclut cet article avec une comparaison de REbus à d'autres solutions, un exemple de cas d'utilisation réelle, et donne des perspectives de développement de REbus.

2 Description de REbus

2.1 Vocabulaire

Un outil d'analyse est intégré dans le bus de communication par le développement d'un court programme Python nommé agent, qui se charge de piloter l'outil, de lui fournir ses entrées venant du bus et de placer ses sorties dans le bus.

Les entrées/sorties des outils sont transportés dans des messages qui sont des objets Python appelés descripteurs.

Un composant de stockage, également en Python, enregistre tous les descripteurs.

Un composant appelé bus master est responsable de la circulation des messages entre les agents et également à destination du composant de stockage.

Les agents peuvent eectuer des requêtes vers le composant de stockage à travers le bus master.

Ces éléments sont résumés à la gure 1.

2.2 Descripteurs

Un descripteur encapsule une valeur, représentée par une chaine de caractères et quelques métadonnées associées.

Les descripteurs sont produits par des agents, à partir d'une donnée exogène (entrée utilisateur, chier, etc.) ou à partir des données contenues dans un ou plusieurs descripteurs déjà présents dans le bus, appelés les parents du nouveau descripteur.

Les descripteurs sont des objets Python comportant les propriétés suivantes :

selector

chaine de caractères qui remplit plusieurs fonctions :

• décrire le type de la données encapsulée (' type MIME) : image, chier binaire, etc.
• décrire le format de la donnée (ex. JPG ou PNG pour une image, PE ou ELF pour un binaire, etc.),
• identier de manière unique un descripteur par un hash (SHA256) dépendant :
  • de la valeur stockée,
  • du nom de l'agent ayant généré le descripteur,
  • du sélecteur des éventuels descripteurs parents,
  • du début de la chaine du sélecteur (tout sauf le hash).

label

nom compréhensible par un humain.

uuid

identiant unique regroupant les descripteurs liés à un même objet analysé.

value

valeur du descripteur contenu du message transporté.

precursors

liste de sélecteurs des descripteurs parents.

agent name

nom de l'agent ayant généré ce descripteurs.

domain

permet de séparer deux analyses sans rapport dans un même bus.

version

numéro de version.

processing time

temps ayant été nécessaire à la génération de ce descripteur.

Les descripteurs comportent également des méthodes qui permettent de :

• générer un nouveau descripteur, lié à la même analyse (même UUID) ou non ;
• générer une nouvelle version d'un descripteur ;
• créer un lien avec un autre descripteur, en précisant la raison ;
• (dé)sérialiser.

À propos des sélecteurs. Le sélecteur de chaque nouveau descripteur est envoyé à chaque agent, qui l'utilise pour décider s'il souhaite traiter ce descripteur (ex. un agent calculant le hash MD5 peut être intéressé par les binaires au format PE), l'ignorer, ou demander plus d'informations au bus pour déterminer s'il souhaite eectuer le traitement.

Un sélecteur peut avoir la forme suivante : /signature/md5/%6e1d5169661a50(...)f989129a583f92b9dee. Le préxe /signature/md5 décrit le type de données ; le format de la valeur du descripteur n'est pas indiqué ici, et dépendra de l'agent l'ayant généré. Il pourra s'agir d'une valeur brute (128 bits) ou de sa représentation hexadécimale (32 caractères). Dans le jeu d'agents public rebus_demo [6], la seconde option a été choisie.

2.3 Agents

Les agents sont des programmes Python réalisant l'interface entre un outil (module Python, programme externe, etc.) et REbus.

Le bus master notie tous les agents lorsqu'un nouveau descripteur est ajouté au bus. Chaque agent décide alors s'il souhaite traiter le nouveau descripteur, par la surcharge (facultative) des méthodes suivantes de la classe Agent :

• selector_filter qui permet un premier niveau de décision connaissant uniquement le sélecteur du nouveau descripteur ;
• descriptor_filter qui permet le ltrage en disposant du descripteur complet.

Lorsque ces deux méthodes renvoient True (valeur par défaut en l'absence de surcharge), la méthode process de l'agent est appelée. Le traitement peut alors commencer.

Voici à titre d'exemple le code d'un agent très simple calculant le hash MD5 des descripteurs dont le sélecteur commence par /binary/. À l'issue du traitement, l'agent crée un descripteur ls ayant pour sélecteur /md5_hash/ et pousse ce descripteur ainsi que le hash dans le bus.

Lorsque plusieurs instances d'un même agent s'exécutent simultanément, le premier agent commençant le traitement d'un nouveau descripteur empêchera automatiquement les autres instances de le faire.

De plus, les agents peuvent surcharger des méthodes get_internal_state et set_internal_state exécutées lors de l'arrêt du bus et de son redémarrage, pour sauvegarder et restaurer leur état interne.

Enn, deux modes de fonctionnement peuvent être supportés par les agents :

• le mode automatique, dans lequel tous les descripteurs acceptés par les méthodes de ltrage décrites plus haut sont traités ;
• le mode interactif, dans lequel l'agent indique les descripteurs qu'il est capable de traiter, le traitement se faisant sur demande de l'utilisateur.

Le choix de l'un des deux modes est fait au lancement de l'agent.

De plus, lors du lancement de cet agent, le bus master lui communique les sélecteurs de tous les descripteurs déjà présents sur le bus qui n'ont pas déjà été traités par une autre instance du même agent.

2.4 Stockage

Tous les descripteurs envoyés sur le bus sont enregistrés par le système de stockage. Ce système possède une API orant les fonctionnalités suivantes :

• recherche de descripteur par UUID, par regex sur le sélecteur ou la valeur ;
• obtention de liste des analyses (UUID) existantes ;
• enregistrement et restauration de l'état interne des agents (utile lors de l'arrêt/redémarrage du bus) ;
• suivi du traitement de chaque descripteur par chaque agent et en particulier fourniture de la liste des descripteurs non traités.

Deux implémentations de cette API sont disponibles :

RAMStorage

stocke toutes les données en RAM, qui seront donc perdues lors de l'arrêt du bus ;

DiskStorage

enregistre les descripteurs et les états internes des agents sur le disque, ce qui permet l'arrêt puis la reprise des analyses depuis une conguration donnée.

L'écriture d'une implémentation de cette API eectuant un stockage distribué sur plusieurs machines est prévue.

2.5 API du bus de communication

Le bus expose une API qui rend les services suivants :

• permettre aux agents de diuser des descripteurs à tous les autres agents ;
• permettre aux agents de recevoir les nouveaux descripteurs disponibles ;
• enregistrer l'historique de traitement des descripteurs pour chaque agent ;
• répartir des descripteurs entre plusieurs instances du même agent (ex. : agents eectuant des traitements longs) ;
• enregistrer des méthodes pouvant être appelées par d'autres agents pour post-traitements ;
• sauvegarder et restaurer l'état interne des agents lors de l'arrêt ou la reprise du bus ;
• transporter les requêtes vers le système de stockage de descripteurs.

Deux implémentations de cette API sont disponibles : LocalBus et DBusBus.

LocalBus

Le bus LocalBus permet de combiner plusieurs outils pour créer un nouveau super-outil en ligne de commande. Tous les agents et le Bus Master s'exécutent au sein du même processus. Le bus s'arrête lorsque tous les traitements sont terminés.

REbus au dessus de D-Bus

Le bus utilisant D-Bus permet une utilisation plus interactive du bus :

• chaque agent s'exécute dans un processus séparé ;
• les agents s'arrêtent lorsque le Bus Master est arrêté par l'utilisateur ;
• les agents peuvent être exécutés sur des hôtes distants.

2.6 Agents disponibles

L'ajout de capacités d'analyse au bus se fait à travers l'ajout d'un ensemble d'agents portant sur une thématique données (analyse de malware, reconnaissance réseau, analyse forensique d'images disque, etc.) contenus dans un package Python, dont le nom sera passé en paramètre lors du lancement de REbus. Ce découplage permet le développement d'agents indépendamment du développement de REbus. Il est possible d'utiliser simultanément des agents appartenant à des ensembles diérents. La liste des ensembles d'agents publics est consultable sur [7].

Agents génériques fournis avec REbus

Plusieurs agents sont fournis avec le bus. Ils sont génériques, et n'eectuent pas de traitement spécique à un type de problème à résoudre. Ils servent principalement à interagir avec le bus comme listé ci-dessous et résumé à la gure 3 :

inject :

injecte des chiers dans le bus.

unarchive :

extrait les archives et chiers compressés (zip, tgz, tbz2, etc.), injecte leur contenu sur le bus.

ls :

liste les sélecteurs connus correspondant à la regex fournie.

return :

renvoie sur stdout la valeur des descripteurs dont le sélecteur correspond à la regex fournie.

search :

renvoie sur stdout le sélecteur des descripteurs dont la valeur correspond à la regex fournie.

httplistener :

lance un serveur HTTP et injecte sur le bus tout contenu transmis par méthode POST.

link_nder :

crée automatiquement des liens (descripteurs dont le sélecteur commence par /link/) entre les descripteurs ayant la même valeur.

link_grapher :

crée des graphes montrant les liens existants entre descripteurs.

dotrenderer :

eectue le rendu de graphes au format dot vers SVG.

web_interface :

interface web permettant l'interaction avec le bus.

Agents de démonstration

Un ensemble d'agents de démonstration est public [6]. Il comporte les agents suivants :

hasher :

calcul le hash MD5 de binaires

stringer :

renvoie la sortie de strings exécuté sur un binaire

grep :

renvoie sur stdout la valeur des descripteurs de type /string/ correspondant à la regex fournie

3 Exemples d'utilisation

3.1 Cinématique de fonctionnement

Voici un exemple à but pédagogique de super-outil simple s'appuyant sur plusieurs outils pour acher sur la sortie standard le hash MD5 des chiers contenus dans une archive tgz.

Cette ligne de commandes comporte les éléments suivants :

• importe les agents présents dans le package python rebus_demo.agents ;
• le lancement de l'agent inject comportant un argument ; les tirets marquent la n de la liste des arguments de cet agent, dont le nombre n'est pas xé (il est possible d'injecter plusieurs chiers avec le même agent inject) ;
• le lancement de l'agent return achant la valeur des hash MD5 calculés sur la sortie standard ;
• le lancement de plusieurs agents sans argument.

L'exécution de cette commande peut se décomposer en dix étapes comme suit :

Enn, l'agent return ache son résultat comme illustré sur le listing 1.3.

Seul le calcul du premier hash est représenté dans les schémas ci-dessus ; le traitement continue de manière similaire pour le traitement des chiers suivants.

Les préxes de hashs représentés sur les schémas après le symbole % sont ceux des descripteurs.

3.2 Génération d'un graphe reliant les binaires ayant le même importhash

Voici un autre exemple, utilisable en pratique, d'un autre super-outil générant un graphe reliant les binaires ayant la même valeur d'import hash [9]. Il s'appuie sur les agents suivants :

inject

injecte les binaires sur le bus ;

le_identication

calcule la valeur de l'import hash ;

link_nder

déclare des liens entre descripteurs ayant la même valeur (ici, /signature/imphash/) ;

link_grapher

crée un graphe montrant tous les descripteurs reliés par un lien de type /link/link_finder/signature-imphash. Il a la particularité d'eectuer une requête pour obtenir tous les liens correspondant aux critères donnés ayant déjà été injectés dans le bus ;

dotrenderer

eectue le rendu de graphes en image SVG ;

return

ache sur stdout l'image SVG produite.

La ligne de commande à exécuter est la suivante :

On notera sur cette ligne de commande l'utilisation du symbole : : séparant des étapes de traitement : les agents décrits avant ce symbole s'exécutent d'abord ; une fois que tous les descripteurs ont été traités par tous les agents, ceux-ci s'arrêtent. Les agents décrits après ce symbole s'exécutent ensuite.

On obtient les résultats présentés dans le listing 4 pour un corpus de malware APT1. Les nuds rectangulaires du graphe correspondent à des malware du corpus APT1 [11] ; ils sont reliés à des nuds ronds, symbolisant une valeur d'import hash. On peut voir que ce nouveau super-outil permet de relier entre eux tous les malware ayant la même valeur d'import hash. Le texte de ces nuds, illisible ici, n'a que peu d'importance.

3.3 Utilisation en mode infrastructure

Les deux exemples précédents utilisent le bus LocalBus. Voici un exemple d'utilisation du mode infrastructure, basé sur D-Bus, en utilisant les agents de l'ensemble rebus_demo [6].

Pour utiliser REbus en mode infrastructure, il faut commencer par lancer le bus master :

Il faut ensuite lancer les agents que l'on souhaite utiliser. Les agents utilisés ici ont été présentés plus haut.

L'interface web est alors accessible à l'adresse http ://localhost :8080.

On peut utiliser l'agent inject pour injecter le contenu d'un chier sur le bus. Cette opération peut être eectuée avant ou après le lancement des agents.

4 Conclusion

Cet article a présenté REbus un bus de communication facilitant la coopération entre outils d'analyse de sécurité.

Le bus, ainsi que certaines analyses implémentées via le mécanisme des agents sont disponibles respectivement ici [5] et ici [6], sous licence BSD.

Le reste de cette section section est consacrée à l'état de l'art de ce type de problématique (section 4.1) ; à des considérations techniques qui montrent notamment la robustesse de notre solution (section 4.2) et enn des perspectives d'évolution de REbus (section 4.3).

4.1 Comparaison avec des solutions existantes

Il est possible d'envisager d'autres façons de faire coopérer des outils d'analyse de sécurité.

Il est possible de fournir des bibliothèques enveloppant les outils et orant une API cohérente ou uniée. L'ajout de nouveaux outils nécessitent d'étendre ou d'ajouter une bibliothèque. Mais il reste encore à la charge du programmeur de les appeler, de s'occuper de la nouvelle circulation des messages entre les diérents outils et de l'intendance.

L'approche framework dispense tout au moins de l'intendance. La circulation des messages peut être prise en charge par exemple via l'utilisation d'un mécanisme de transport sans intelligence , n'ayant pas connaissance des interactions entre les agents :

• systèmes de chiers (ex. ZeroMQ, RabbitMQ) ;
• RPC (ex. D-Bus) ;
• microservice REST pour chaque outil.

Il est également possible de concentrer toute la logique d'interaction dans un composant central, qui s'occupera d'appeler chaque outil lorsque cela est nécessaire :

• orchestrateur interfacé avec chaque outil ;
• framework interactif (ex. viper [1]).

L'utilisation directe de chacun de ces choix implique la connaissance a priori des agents existants, des types de données échangés ou des graphes de ots de données à respecter.

REbus peut utiliser l'un ou l'autre de ces mécanismes de transport mais y ajoute une couche d'abstraction permettant de dénir la circulation des messages de manière implicite et a posteriori.

À chaque agent est laissé le choix de traiter ou non un message, via un ltrage eectué dans un premier niveau sur le type du message (sur son sélecteur, ou sur toute caractéristique du message dans un second temps). Ainsi, chaque agent a un unique interlocuteur (le bus) et n'a pas besoin de connaitre ni de prendre en compte les diérents outils avec lesquels il va coopérer.

L'ajout d'un nouvel outil à un écosystème existant est aisé : il sut d'écrire un agent se chargeant de récupérer les données traitables par l'outil depuis le bus, au format déni par les agents déjà existants produisant des données de ce type, puis de pousser les résultats obtenus au format attendu par les agents existants consommant des données de ce type, sans se soucier de savoir quels seronts les agents lancés produisant ou consommant des types de données.

4.2 Robustesse de REbus

REbus a été principalement utilisé à des ns d'analyse et de classication de malware. L'objectif est d'évaluer la dangerosité d'un grand nombre de programmes injectés dans REbus, et de les regrouper par familles.

L'avantage principal de REbus pour ce type de travail est sa modularité : la classication de malware repose sur les étapes suivantes :

• extraction de caractéristiques (par exemple, la liste des imports) ;
• calcul de distances entre ces malware en utilisant les caractéristiques extraites ;
• utilisation d'algorithmes d'apprentissage et de classication.

REbus facilite l'expérimentation : la modication d'une des étapes de traitement (ex. extraction de nouvelles caractéristiques) ne nécessite pas de modication sur les autres étapes.

Notre participation à un concours de classication de malware [10] a montré la robustesse de l'implémentation de REbus à l'injection de 21 757 listings assembleur.

Cependant, les chiers ayant une taille supérieure à 150 Mo ont dû être pré-traités pour en réduire la taille en supprimant les informations inutiles : les communications entre agents et bus master via D-Bus échouaient à cause d'expiration de délai D-Bus. Des travaux sont en cours pour résoudre ce problème, cf les perspectives.

4.3 Perspectives

Les améliorations suivantes au bus sont à l'étude :

• l'injection de chiers de grande taille pose problème. Les évolutions envisagées sont : une nouvelle implémentation de l'API Bus le passage des valeurs des descripteurs par référence ;
• la gestion des dépendances de descripteurs : actuellement il n'est pas possible de déclencher un traitement lorsque plusieurs descripteurs liés à une analyse sont présents. Par exemple, extraire les chaines de caractères lisibles (strings) d'un binaire uniquement si l'agent de détection de packer a déterminé qu'il n'était pas packé ;
• l'ajout de méthodes permettant l'exécution de programmes tiers dans un environnement isolé, par exemple par l'utilisation de namespaces linux ou de seccomp ;
• implémentation d'un nouveau Bus, basé sur une technologie plus robuste que D-Bus (peut-être zeromq, services REST ou MPI) ;
• support de la transmission de valeurs par référence, pour faciliter l'analyse de chiers de grande taille ;
• indexation et recherche intégrée à l'interface web.

Références