REbus : un bus de communication facilitant la

coopération entre outils d’analyse de sécurité

Philippe Biondi, Xavier Mehrenberger et Sarah Zennou

philippe.biondi@airbus.com
xavier.mehrenberger@airbus.com
sarah.zennou@airbus.com
Airbus Group Innovations

Résumé L’analyse de sécurité (forensics, pentest, binaires, etc.) nécessite

l’utilisation de nombreux outils. Leurs interfaces sont disparates, ce qui
rend l’automatisation des analyses et la reproduction de leurs résultats
difficile.
Nous présentons ici REbus, un bus de communication libre facilitant la
coopération entre outils d’analyse de sécurité.

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 fichiers 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 symbo-
lique supportant plusieurs architectures ;
— grandalf [4], un framework de dessin et navigation de graphes ;
— des analyseurs statiques ;
— des outils de classification de binaires ;
— des unpackers ;
Ce besoin s’est vite étendu à d’autres utilitaires tels que IDA, BinDiff, gdb,
strace, PEID, libmagic, ou plate-formes telles que cuckoo, FireEye MAS,
IRMA et également à d’autres thématiques que l’analyse de binaires.
2 REbus

Dans le domaine de la découverte de services réseau/pentest, il est en

effet 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’ana-
lyse forensique de disque dur ; l’analyse de certificats ; l’analyse de code
JavaScript.
Ce besoin de croiser les résultats de différents outils pose plusieurs
problèmes :
— comment stocker les résultats intermédiaires ? En effet, ceux-ci
ont un intérêt, particulièrement lors d’une première analyse « à
tâtons » ;
— comment rendre compatibles les différentes interfaces d’entrée et
sortie (stdin/stdout, écriture de fichiers 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ère-
ment 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 ex-

pé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.
P. Biondi, X. Mehrenberger, S. Zennou 3

Un fonctionnement décentralisé. REbus privilégie l’exhaustivité de l’ana-

lyse et la simplicité des interfaces à l’efficience 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 afin 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 flot de
contrôle) du binaire obtenu, et un troisième qui l’affiche ;
— en mode infrastructure, mettant à disposition les services des agents
sur une durée indéfinie,
— 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’authentification, de contrôle d’accès, ni de

vérification 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 recom-
mandé de manipuler des données potentiellement dangereuses (ex. malware,
fichiers produits par un tiers non de confiance) dans des environnements
isolés (machines virtuelles, docker, conteneur LXC, seccomp, etc.). L’utili-
sation 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
4 REbus

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 effectuer des requêtes vers le composant de stockage
à travers le bus master.
Ces éléments sont résumés à la figure 1.

interface de l’outil
interface de stockage
interface du bus

Outil Agent Bus master Stockage

Figure 1. Interfaces entre les composants de REbus

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, fichier, 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,
fichier binaire, etc.
— décrire le format de la donnée (ex. JPG ou PNG pour une
image, PE ou ELF pour un binaire, etc.),
P. Biondi, X. Mehrenberger, S. Zennou 5

— identifier 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 identifiant 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 effectuer le traitement.
Un sélecteur peut avoir la forme suivante :
/signature/md5/%6e1d5169661a50(...)f989129a583f92b9dee. Le
préfixe /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.
6 REbus

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 notifie 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 filtrage en disposant du descrip-
teur 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 fils ayant pour sélecteur
/md5_hash/ et pousse ce descripteur ainsi que le hash dans le bus.

from rebus . agent import Agent

import hashlib

@Agent . r eg i s t e r
class Hasher ( Agent ) :
_name_ = " hasher "
_desc_ = " Return md5 of a binary "

def s e l e c t o r _ f i l t e r ( self , s e l e c t o r ) :
# I n d i c a t e that this agent is only i n t e r e s t e d in d e s c r i p t o r s
# whose s e l e c t o r starts with "/ binary "
return s e l e c t o r . s t a r t s w i t h ( " / binary / " )

def process ( self , desc , s e n d e r _ i d ) :

# Compute md5 hash value
md 5 _ h a s h = hashlib . md5 ( s ) . h e x d i g e s t ( desc . value )

# Create a new child d e s c r i p t o r

ne w _ d e s c = desc . s p a w n _ d e s c r i p t o r ( " / md5_hash " ,
unicode ( m d 5 _ h a s h ) ,
self . name )

# Push the new d e s c r i p t o r to the bus

self . push ( n e w _ d e s c )

Listing 1. Agent REbus calculant le hash MD5 de fichiers binaires

P. Biondi, X. Mehrenberger, S. Zennou 7

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.
Enfin, 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 filtrage 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 sys-
tème de stockage. Ce système possède une API offrant 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 configuration donnée.
L’écriture d’une implémentation de cette API effectuant un stockage
distribué sur plusieurs machines est prévue.
8 REbus

2.5 API du bus de communication

Le bus expose une API qui rend les services suivants :
— permettre aux agents de diffuser des descripteurs à tous les autres
agents ;
— permettre aux agents de recevoir les nouveaux descripteurs dispo-
nibles ;
— enregistrer l’historique de traitement des descripteurs pour chaque
agent ;
— répartir des descripteurs entre plusieurs instances du même agent
(ex. : agents effectuant 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.

Stockage

get* add search*

put notify

get
REbus Local get
Agent Agent
Bus Master
notify put

Figure 2. Composants du bus LocalBus

REbus au dessus de D-Bus Le bus utilisant D-Bus permet une utili-

sation plus interactive du bus :
P. Biondi, X. Mehrenberger, S. Zennou 9

— chaque agent s’exécute dans un processus séparé ;

— les agents s’arrêtent lorsque le Bus Master est arrêté par l’utilisa-
teur ;
— les agents peuvent être exécutés sur des hôtes distants.

get*
add
Bus Master Stockage

search*
push requests to storage
put notify
put notify
get
get get
Agent REbus DBusBus REbus get Agent
notify put
notify put

Figure 3. Composants du bus DBusBus

2.6 Agents disponibles

L’ajout de capacités d’analyse au bus se fait à travers l’ajout d’un en-

semble 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 diffé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’effectuent pas de traitement spécifique
à un type de problème à résoudre. Ils servent principalement à interagir
avec le bus comme listé ci-dessous et résumé à la figure 3 :
inject : injecte des fichiers dans le bus.
unarchive : extrait les archives et fichiers compressés (zip, tgz, tbz2,
etc.), injecte leur contenu sur le bus.
ls : liste les sélecteurs connus correspondant à la regex fournie.
10 REbus

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_finder : 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 : effectue 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’ap-

puyant sur plusieurs outils pour afficher sur la sortie standard le hash
MD5 des fichiers contenus dans une archive tgz.

$ r e b u s _ a g e n t -m r e b u s _ d e m o . agents hasher u n a r c h i v e \
inject ~/ apt1 . tgz -- \
return -- short m d 5 _ h a s h

Listing 2. Lancement de REbus et agents pour calcul de MD5

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

— importe les agents présents dans le package python
rebus_demo.agents ;
P. Biondi, X. Mehrenberger, S. Zennou 11

— le lancement de l’agent inject comportant un argument ; les tirets

marquent la fin de la liste des arguments de cet agent, dont le
nombre n’est pas fixé (il est possible d’injecter plusieurs fichiers
avec le même agent inject) ;
— le lancement de l’agent return affichant 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 :

unarchive hasher

return /signature/md5 inject apt1.tgz

master / storage

Étape 1 : Mise en place des agents

unarchive hasher

return /signature/md5 inject apt1.tgz

master / storage
apt1.tgz

Étape 2 : Envoi de apt1.tgz au Bus Master par l’agent inject

unarchive hasher

/compressed/gzip/%1234abcdef

return /signature/md5
master / storage
apt1.tgz

Étape 3 : Annonce du sélecteur du nouveau descripteur par le Bus Master

12 REbus

unarchive apt1.tgz hasher

return /signature/md5
master / storage
apt1.tgz

Étape 4 : Récupération de apt1.tgz par l’agent unarchive

unarchive hasher

return /signature/md5
master / storage
apt1.tgz AURIGA_6B3
Étape 5 : Envoi du fichier extrait AURIGA... au Bus Master par l’agent
unarchive
unarchive hasher

/binary/pe/%abcd1234

return /signature/md5
master / storage
apt1.tgz AURIGA_6B3
Étape 6 : Annonce du sélecteur du nouveau descripteur par le Bus Master

unarchive hasher AURIGA_6B3

return /signature/md5
master / storage
apt1.tgz AURIGA_6B3
Étape 7 : Récupération de AURIGA... par l’agent hasher
P. Biondi, X. Mehrenberger, S. Zennou 13

unarchive hasher

return /signature/md5 master / storage

AURIGA_6B3
apt1.tgz
md5sum(AURIGA)
Étape 8 : Envoi du hash MD5 du fichier AURIGA... par l’agent hasher
unarchive hasher

/signature/md5/%fedcba4321

return /signature/md5 master / storage

AURIGA_6B3
apt1.tgz
md5sum(AURIGA)
Étape 9 : Annonce du sélecteur du nouveau descripteur par le Bus Master

unarchive hasher

return /signature/md5
master / storage
md5sum(AURIGA) AURIGA_6B3
apt1.tgz
md5sum(AURIGA)
Étape 10 : Récupération du hash MD5 par l’agent return et affichage sur
la sortie standard
Enfin, l’agent return affiche son résultat comme illustré sur le listing
3.

apt1 . tgz : A U R I G A _ 6 B 3 1 3 4 4 B 4 0 E 2 A F 9 C 9 E E 3 B A 7 0 7 5 5 8 C 1 4 E =
6 b31344b40e2af9c9ee3ba707558c14e
apt1 . tgz : A U R I G A _ C D C D 3 A 0 9 E E 9 9 C F F 9 A 5 8 E F E A 5 C C B E 2 B E D =
cdcd3a09ee99cff9a58efea5ccbe2bed
apt1 . tgz : B A N G A T _ 4 6 8 F F 2 C 1 2 C F F C 7 E 5 B 2 F E 0 E E 6 B B 3 B 2 3 9 E =
468 f f 2 c 1 2 c f f c 7 e 5 b 2 f e 0 e e 6 b b 3 b 2 3 9 e
14 REbus

...

Listing 3. Sortie de l’agent return

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 fichiers
suivants.
Les préfixes 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 ;
file_identification calcule la valeur de l’import hash ;
link_finder 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’effectuer une requête pour obtenir tous les liens
correspondant aux critères donnés ayant déjà été injectés dans le
bus ;
dotrenderer effectue le rendu de graphes en image SVG ;
return affiche sur stdout l’image SVG produite.
La ligne de commande à exécuter est la suivante :
$ r e b u s _ a g e n t -m bnew . agents l i n k _ f i n d e r -- f i l e _ i d e n t i f i c a t i o n
inject * - -\
:: l i n k _ g r a p h e r ’/ link / link_finder / signature - imphash ’ - -\
d o t r e n d e r e r return ’/ graph / svg ’ -- raw > ~/ links - apt1 . svg

Listing 4. Lancement de REbus et agents pour génération du graphe

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.
P. Biondi, X. Mehrenberger, S. Zennou 15

On obtient les résultats présentés dans le listing 4 pour un corpus

de malware APT1. Les nœuds rectangulaires du graphe correspondent
à des malware du corpus APT1 [11] ; ils sont reliés à des nœuds 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 nœuds, illisible ici, n’a que peu
d’importance.

WEBC2-UGX_sample_56DE2854EF64D869B5DF7AF5E4EFFE3E

BISCUIT_sample_5D8129BE965FAB8115ECA34FC84BD7F0 Old2008-2010__57C69FECFECDCB5288687DF2AC96E44F_iprinp.dll WEBC2-UGX_sample_75DAD1CCABAE8ADEB5BAE899D0C630F8

WEBC2-CSON_sample_D22863C5E6F098A4B52688B021BEEF0A
WEBC2-CSON_sample_4192479B055B2B21CB7E6C803B765D34

WEBC2-AUSOV_sample_A40E20FF8B991308F508239625F275D8 Old2008-2010__7C136A9E8D94BF117288D9B5388019D6_iprinp.dll signature-imphash

signature-imphash

signature-imphash signature-imphash

WEBC2-QBP_sample_CF9C2D5A8FBDD1C5ADC20CFC5E663C21 Old2008-2010__0F77AF7FA673F5B3D36B926576002A1C_winhlp32.exe
WEBC2-QBP_sample_C04C796EF126AD7429BE7D55720FE392 BANGAT_sample_8E8622C393D7E832D39E620EAD5D3B49

signature-imphash signature-imphash

WEBC2-UGX_sample_4B19A2A6D40A5825E868C6EF25AE445E

BISCUIT_sample_7CB055AC3ACBF53E07E20B65EC9126A1 Old2008-2010__A6C1595BD7B1A85C42FBD674460DC35D_iprinp.dll

GREENCAT_sample_E54CE5F0112C9FDFE86DB17E85A5E2C5 GREENCAT_sample_57E79F7DF13C0CB01910D0C688FCD296

GREENCAT_sample_A565682D8A13A5719977223E0D9C7AA4 GREENCAT_sample_390D1F2A620912104F53C034C8AEF14B
GREENCAT_sample_E83F60FB0E0396EA309FAF0AED64E53F

GREENCAT_sample_B3BC979D8DE3BE09728C5DE1A0297C4B
signature-imphash
WEBC2-GREENCAT_sample_1CE4605E771A04E375E0D1083F183E8E

WEBC2-CSON_sample_A38A367D6696BA90B2E778A5A4BF98FD signature-imphash TABMSGSQL_sample_052EC04866E4A67F31845D656531830D

WEBC2-CSON_sample_F1E5D9BF7705B4DC5BE0B8A90B73A863 TABMSGSQL_sample_002325A0A67FDED0381B5648D7FE9B8E

signature-imphash signature-imphash signature-imphash

TARSIP-MOON_sample_C91EACAB7655870764D13BA741AA9A73
GREENCAT_sample_BA0C4D3DBF07D407211B5828405A9B91

GREENCAT_sample_871CC547FEB9DBEC0285321068E392B8

GREENCAT_sample_55FB1409170C91740359D1D96364F17B
GREENCAT_sample_6D2320AF561B2315C1241E3EFD86067F
GREENCAT_sample_30E78D186B27D2023A2A7319BB679C3F
GREENCAT_sample_B8F61242E28F2EDF6CB1BE8781438491

signature-imphash GREENCAT_sample_36C0D3F109AEDE4D76B05431F8A64F9E
COOKIEBAG_sample_989B797C2A63FBFC8E1C6E8A8CCD6204
COOKIEBAG_sample_DB2580F5675F04716481B24BB7AF468E
WEBC2-HEAD_sample_973F4A238D6D19BDC7B42977B07B9CEF
TARSIP-MOON_sample_6808EC6DBB23F0FA7637C108F44C5C80 signature-imphash
signature-imphash
TARSIP-MOON_sample_95F25D3AFC5370F5D9FD8E65C17D3599
WEBC2-HEAD_sample_B74022A7B9B63FDC541AE0848B28A962
WEBC2-HEAD_sample_C9172B3E83C782BC930C06B628F31FA5

HACKFASE_sample_0D0240672A314A7547D328F824642DA8

HACKFASE_sample_BCBDEF1678049378BE04719ED29078D2 NEWSREELS_sample_BAABD9B76BFF84ED27FD432CFC6DF241

WEBC2-HEAD_sample_F627990BBE2EC5C48C180F724490C332
signature-imphash
WEBC2-HEAD_sample_EC8C89AA5E521572C74E2DD02A4DAF78 TARSIP-MOON_sample_A5D4EBC0285F0213E0C29D23BC410889 NEWSREELS_sample_A639F598D4C0B9AA7A4691D05F27D977
signature-imphash

WEBC2-CSON_sample_575836EBB1B8849F04E994E9160370E4 signature-imphash
WEBC2-CSON_sample_73D125F84503BD87F8142CF2BA8AB05E

signature-imphash
TARSIP-ECLIPSE_sample_0B506C6DDE8D07F9EEB82FD01A6F97D4 MINIASP_81B03CBCFC4B9D090CD8F5E5DA816895
MINIASP_77FBFED235D6062212A3E43211A5706E
WEBC2-HEAD_sample_C4C638750526E28F68D6D71FD1266BDF
WEBC2-HEAD_sample_88C7C50CD4130561D57A1D3B82C5B953 signature-imphash

HACKFASE_sample_9E860622FEE66074DFE81DCFCC40C4E2 WEBC2-HEAD_sample_7B42B35832855AB4FF37AE9B8FA9E571

NEWSREELS_sample_AF2F7B070245C90BD2A0A0845314173A

TARSIP-ECLIPSE_sample_8934AEED5D213FE29E858EEE616A6EC7
signature-imphash
TARSIP-ECLIPSE_sample_4A54D7878D4170C3D4E3C3606365C42C

WEBC2-YAHOO_sample_0149B7BD7218AAB4E257D28469FDDB0D

GREENCAT_sample_1F92FF8711716CA795FBD81C477E45F5

WEBC2-YAHOO_sample_1415EB8519D13328091CC5C76A624E3D STARSYPOUND_sample_2DD892986B2249B5214639ECC8AC0223
STARSYPOUND_F8437E44748D2C3FCF84019766F4E6DC GREENCAT_sample_AB208F0B517BA9850F1551C9555B5313

STARSYPOUND_99A39866A657A10949FCB6D634BB30D5
signature-imphash
STARSYPOUND_sample_D9FBF759F527AF373E34673DC3ACA462
STARSYPOUND_6FAA4740F99408D4D2DDDD0B09BBDEFD TARSIP-ECLIPSE_sample_3107DE21E480AB1F2D67725F419B28D0
AURIGA_sample_6B31344B40E2AF9C9EE3BA707558C14E
AURIGA_sample_CDCD3A09EE99CFF9A58EFEA5CCBE2BED

STARSYPOUND_65018CD542145A3792BA09985734C12A signature-imphash signature-imphash

STARSYPOUND_A316D5AECA269CA865077E7FFF356E7D GREENCAT_sample_3E6ED3EE47BCE9946E2541332CB34C69

signature-imphash
STARSYPOUND_sample_CA6FE7A1315AF5AFEAC2961460A80569
WEBC2-YAHOO_sample_F7F85D7F628CE62D1D8F7B39D8940472 GREENCAT_sample_3E69945E5865CCC861F69B24BC1166B6
STARSYPOUND_sample_6576C196385407B0F7F4B1B537D88983 WEBC2-YAHOO_sample_A8F259BB36E00D124963CFA9B86F502E

STARSYPOUND_sample_C0A33A1B472A8C16123FD696A5CE5EBB
WEBC2-YAHOO_sample_2B659D71AE168E774FAAF38DB30F4A84
STARSYPOUND_650A6FCA433EE243391E4B4C11F09438 WEBC2-YAHOO_sample_36D5C8FC4B14559F73B6136D85B94198
GREENCAT_sample_5AEAA53340A281074FCB539967438E3F
MAPIGET_sample_F3C6C797EF80787E6CBEEAA77496A3CB
Old2008-2010__C57902ACE7FF4173AE41F1292EA85E2A_MAPI.exe

signature-imphash STARSYPOUND_785003A405BC7A4EBCBB21DDB757BF3F
STARSYPOUND_sample_2BA0D0083976A5C1E3315413CDCFFCD2
STARSYPOUND_sample_8B75BCBFF174C25A0161F30758509A44

STARSYPOUND_33DE5067A433A6EC5C328067DC18EC37 NEWSREELS_sample_2C49F47C98203B110799AB622265F4EF
signature-imphash

WEBC2-YAHOO_sample_CC3A9A7B026BFE0E55FF219FD6AA7D94 NEWSREELS_sample_B8277CCE81E0A372BC35D33A0C9483C2
WEBC2-YAHOO_sample_AA4F1ECC4D25B33395196B5D51A06790

BANGAT_sample_4C6BDDCCA2695D6202DF38708E14FC7E signature-imphash

Old2008-2010__1966B265272E1660E6F340B19A7E5567_irmon32.dll

WEBC2-YAHOO_sample_7A670D13D4D014169C4080328B8FEB86
Old2008-2010__423A30C077B12354A4A5C31D4DE99689_irmon32.dll WEBC2-YAHOO_sample_4C9C9DBF388A8D81D8CFB4D3FC05F8E4

signature-imphash WEBC2-BOLID_sample_5FF3269FACA4A67D1A4C537154AAAD4B

Old2008-2010__F10D145684BA6C71CA2D2F7EB0D89343_rasauto32.dll NEWSREELS_sample_0496E3B17CF40C45F495188A368C203A
signature-imphash
BANGAT_sample_EF8E0FB20E7228C7492CCDC59D87C690

STARSYPOUND_B07322743778B5868475DBE66EEDAC4F

STARSYPOUND_sample_EC8AA67B05407C01094184C33D2B5A44

Old2008-2010__43CE605B2584C27064FEBB0474A787A4_irmon32.dll WEBC2-BOLID_sample_1EA61A0945BDE3C6F41E12BC01928D37
signature-imphash
WEBC2-BOLID_sample_D8238E950608E5ABA3D3E9E83E9EE2CC
STARSYPOUND_8442AE37B91F279A9F06DE4C60B286A3
Old2008-2010__995B44EF8460836D9091A8B361FDE489_rasauto32.dll

signature-imphash
COOKIEBAG_sample_543E03CC5872E9ED870B2D64363F518B
COOKIEBAG_sample_321D75C9990408DB812E5A248A74F8C8

signature-imphash

STARSYPOUND_1F2EB7B090018D975E6D9B40868C94CA

WEBC2-RAVE_sample_BF0EE4367EA32F8E3B911C304258E439 WEBC2-BOLID_sample_53B263DD41838AA178A5CED338A207F3

STARSYPOUND_sample_9EA3C16194CE354C244C1B74C46CD92E
WEBC2-RAVE_sample_9F11BC08AF048C5C3A110E567082FE0B

GREENCAT_sample_FAB6B0B33D59F393E142000F128A9652 STARSYPOUND_F6655E39465C2FF5B016980D918EA028 BOUNCER_sample_D2F1BE7E10ED39AA8BC0F7F671D824D2

signature-imphash

GREENCAT_sample_F4ED3B7A8A58453052DB4B5BE3707342 BOUNCER_sample_6EBD05A02459D3B22A9D4A79B8626BF1

TABMSGSQL_sample_001DD76872D80801692FF942308C64E6
signature-imphash signature-imphash

TABMSGSQL_sample_55886D571C2A57984EA9659B57E1C63A

WEBC2-RAVE_sample_BDD2AD4C0E1E5667D117810AE9E36C4B BANGAT_sample_E1B6940985A23E5639450F8391820655
signature-imphash

BANGAT_sample_DB05DF0498B59B42A8E493CF3C10C578

GREENCAT_sample_7388D67561D0A7989202AD4D37EFF24F BOUNCER_sample_CF038194F0FE222F31EC24CB80941BB1
TARSIP-ECLIPSE_sample_4F763B07A7B8A80F1F9408E590F79532 signature-imphash
TARSIP-ECLIPSE_sample_123505024F9E5FF74CB6AA67D7FCC392

signature-imphash

TABMSGSQL_sample_2F930D92DC5EBC9D53AD2A2B451EBF65
COOKIEBAG_sample_F3611C5C793F521F7FF2A69C22D4174E GETMAIL_sample_E81DB0198D2A63C4CCFC33F58FCB821E
COOKIEBAG_sample_0C28AD34F90950BC784339EC9F50D288 GETMAIL_sample_E212AAF642D73A2E4A885F12EEA86C58

signature-imphash signature-imphash

BANGAT_sample_BD8B082B7711BC980252F988BB0CA936
BANGAT_sample_468FF2C12CFFC7E5B2FE0EE6BB3B239E GOGGLES_sample_A5B581C0600815B1112CA2FED578928B
BANGAT_sample_727A6800991EEAD454E53E8AF164A99C GOGGLES_sample_BCB087F69792B69494A3EDAD51A842BB

signature-imphash signature-imphash
NEWSREELS_sample_02C65973B6018F5D473D701B3E7508B2
NEWSREELS_sample_933B11BC4799F8D9F65466FB2E3EA659

signature-imphash

Figure 4. Lien entre malware APT1 ayant la même valeur d’import hash

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].
16 REbus

Pour utiliser REbus en mode infrastructure, il faut commencer par

lancer le bus master :

$ r e b u s _ m a s t e r _ d b u s -- help
usage : r e b u s _ m a s t e r _ d b u s [ - h ] [ - f LOGFILE ] [ - v LEVEL ]
{ diskstorage , r a m s t o r a g e } ...

Rebus DBUS master

positional arguments :
{ diskstorage , r a m s t o r a g e }
Storage b a c k e n d s

optional arguments :
-h , -- help show this help message and exit
-f LOGFILE , -- logfile LOGFILE
D e s t i n a t i o n log file
-v LEVEL , -- verbose LEVEL
Verbosity , 0 is most verbose , 50 least

Uses the r a m s t o r a g e backend if none is s p e c i f i e d .

$ r e b u s _ m a s t e r _ d b u s d i s k s t o r a g e -- help
usage : r e b u s _ m a s t e r _ d b u s d i s k s t o r a g e [ - h ] [ - - path PATH ]

optional arguments :
-h , -- help show this help message and exit
-- path PATH Disk storage path ( d e f a u l t s to / tmp / rebus )

# lancement du bus master

$ rebus_master_dbus

Listing 5. Aide de rebus_master_dbus et lancement du 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.

for agent in w e b _ i n t e r f a c e u n a r c h i v e l i n k _ f i n d e r hasher s t r i n g e r

do r e b u s _ a g e n t -m r e b u s _ d e m o . agents -- bus dbus -- daemon $agent
done

Listing 6. Lancement des agents

L’interface web est alors accessible à l’adresse

http://localhost:8080.
On peut utiliser l’agent inject pour injecter le contenu d’un fichier
sur le bus. Cette opération peut être effectuée avant ou après le lancement
des agents.

$ r e b u s _ a g e n t -- bus dbus inject / tmp / foo . tgz

Listing 7. Injection de foo.tgz

P. Biondi, X. Mehrenberger, S. Zennou 17

$ r e b u s _ a g e n t -- bus dbus -m r e b u s _ d e m o . agents grep 12345

foo . tgz : cpio = 0123456789 ABCDEF
foo . tgz : bash = 0123456789 abcdef
foo . tgz : bash = 0123456789 ABCDEF

Listing 8. Recherche de la chaine 12345 parmi les strings injectées

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 enfin
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
offrant une API cohérente ou unifié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 diffé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’uti-
lisation d’un mécanisme de transport « sans intelligence », n’ayant pas
connaissance des interactions entre les agents :
— systèmes de fichiers (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]).
18 REbus

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 flots 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éfinir 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
filtrage effectué 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 différents outils avec lesquels il
va coopérer.
L’ajout d’un nouvel outil à un écosystème existant est aisé : il suffit
d’écrire un agent se chargeant de récupérer les données traitables par l’outil
depuis le bus, au format défini 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 fins d’analyse et de classifica-

tion 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 modula-
rité : la classification 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 classification.
REbus facilite l’expérimentation : la modification d’une des étapes de
traitement (ex. extraction de nouvelles caractéristiques) ne nécessite pas
de modification sur les autres étapes.
Notre participation à un concours de classification de malware [10] a
montré la robustesse de l’implémentation de REbus à l’injection de 21 757
listings assembleur.
Cependant, les fichiers 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 à
P. Biondi, X. Mehrenberger, S. Zennou 19

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 fichiers 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 na-
mespaces 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 fichiers de grande taille ;
— indexation et recherche intégrée à l’interface web.

Références

1. Airbus Group Innovations. Viper – binary management and analysis framework.

http://viper.li/, 2014.
2. Airbus Group Innovations. Dépôt de code amoco. https://github.com/bdcht/
amoco, 2015.
3. Airbus Group Innovations. Dépôt de code elfesteem. https://bitbucket.org/
LouisG/elfesteem, 2015.
4. Airbus Group Innovations. Dépôt de code grandalf. https://github.com/bdcht/
grandalf, 2015.
5. Airbus Group Innovations. Dépôt de code rebus. https://bitbucket.org/
iwseclabs/rebus, 2015.
6. Airbus Group Innovations. Dépôt de code rebus_demo. https://bitbucket.org/
iwseclabs/rebus_demo, 2015.
7. Airbus Group Innovations. List of public REbus agent sets. https://bitbucket.
org/iwseclabs/rebus/wiki/Sets%20of%20rebus%20agents, 2015.
8. CEA IT Security. Dépôt de code miasm. https://github.com/cea-sec/miasm,
2015.
20 REbus

9. Mandiant. Tracking Malware with Import Hashing. https://www.mandiant.com/

blog/tracking-malware-import-hashing/, 2014.
10. Microsoft Kaggle. Microsoft Malware Classification Challenge (BIG 2015). www.
kaggle.com/c/malware-classification, 2015.
11. Parkour, Mila. Mandiant APT1 samples categorized by malware families. http://
contagiodump.blogspot.fr/2013/03/mandiant-apt1-samples-categorized-by.
html, 2013.
12. Zalewski, Michał. PSA : don’t run ’strings’ on untrusted
files (CVE-2014-8485). http://lcamtuf.blogspot.fr/2014/10/
psa-dont-run-strings-on-untrusted-files.html, 2014.