Figure 1: Architecture globale
De nos jours, faire reposer la sécurité d'un système uniquement sur un anti-virus est un pari osé. Même si les anti-virus restent un outil nécessaire dans la détection des vecteurs d'attaque génériques, leur e cacité reste encore à démontrer.
L'idée pour les exploiter au mieux n'est pas nouvelle. Elle consiste à combiner les résultats d'un ensemble d'anti-virus permettant ainsi de réduire la menace de codes malveillants qui pèse sur les systèmes. D'ailleurs, faire analyser un code par plusieurs anti-virus est souvent la première étape pour un analyste de malware. Celui-ci va vouloir, par la suite, pousser son analyse en le désassemblant, en l'exécutant dans une sandbox, mais aussi en appliquant des outils internes.
Cet article décrit IRMA 1 (Incident Response and Malware Analysis), une plate-forme privée et open-source d'analyse de chiers. Nous allons rappeler les objectifs de cette plate- forme. Puis, nous détaillerons le fonctionnement de celle-ci en mettant en avant son aspect modulaire. Cet article est aussi l'occasion de faire un retour sur son développement (problématiques techniques rencontrées), de présenter quelques statistiques sur les anti-virus, mais surtout d'expliquer comment l'enrichir facilement.
La lutte contre les malwares ne fait que s'intensi er au cours du temps. En e et, même si leur typologie a changé, leur nombre a, quant à lui, considérablement augmenté. Nos systèmes sont, de plus en plus, sous la menace des nouveaux codes malveillants qui apparaissent quotidiennement (390000 nouvelles menaces par jour selon AV-TEST 2 ).
En outre, la diversité des anti-virus a également un coût organisationnel et nancier :
De plus, une organisation est souvent liée contractuellement avec un éditeur d'anti-virus. Or un même malware est rarement unanimement reconnu par tous les anti-virus. En terme de sécurité, mettre un seul anti-virus sur un poste n'est pas satisfaisant.
Pour ces di érentes raisons, disposer d'une solution anti-virale multi- vendeurs est une brique de réponse à ces problèmes et c'est à cette problématique que s'attaque la plate-forme IRMA.
Actuellement, IRMA est, uniquement, une solution d'analyse de chiers : il est possible de soumettre plusieurs chiers simultanément a n de détecter certains codes malveillants ou de faire une recherche sur le nom ou le hash d'un chier déjà connu du système.
Dans sa philosophie, IRMA tente de se rapprocher de Metasploit. En e et l'objectif, plus que de fournir une plate-forme dans laquelle vous avez un contrôle total de vos données, est de fournir un framework d'analyse de chier. N'importe qui peut, grâce à une courbe d'apprentissage très faible, y ajouter son propre outil d'analyse tout en ignorant les problèmes de soumission, d'archivage, de distribution des tâches. La plus-value est grande pour un analyste de malware. En e et, grâce à cela, il sera très facile pour ce dernier d'automatiser les di érentes étapes de son analyse.
L'architecture a été découpée en trois parties distinctes :
Dans la suite de l'article, on parle de module d'analyse et de probe. Le module d'analyse est la partie du code en charge du support d'une analyse (un antivirus, un site externe…) dans IRMA et la probe désigne l'application complète qui exécute ce module.
En se référant aux numéros de la gure 1 le parcours d'un chier dans IRMA est le suivant :
1. Un utilisateur soumet via l'interface web un ou plusieurs chiers à analyser. Les chiers sont stockés sur le frontend et indexés en base de données.
2. Une tâche asynchrone sur le frontend transfère les chiers sur le serveur FTP et déclenche à son tour une tâche asynchrone sur le brain qui lance l'analyse.
3. Le brain divise cette analyse en sous-tâches pour chacun des chiers soumis et chacune des probes demandées.
4. Chaque probe renvoie son résultat d'analyse au brain qui gère l'avancement de la tâche globale d'analyse.
5. Le brain renvoie les résultats vers le frontend qui les stocke en base de données et les met à disposition de l'utilisateur à travers l'API.
IRMA est un projet développé principalement en python qui s'appuie sur de nombreux composants standards (API web servie par Nginx et uWSGI par défaut), un serveur FTP pour le transfert des chiers (Pure-FTPd par défaut), une base de donnée hybride SQL et NoSQL (PostgreSQL et MongoDB par défaut) et en n Celery pour la gestion des tâches asynchrones. La partie Celery gère les les d'attentes au niveau du frontend, du brain ou des probes, permettant à un processus de traitement d'avoir une le de tâches, avec la possibilité de les gérer (gestion des priorités, annulation, reprise après échec).
La première version publique d'IRMA (version 1.0.2) date du 2 juin 2014 et a été annoncée en RUMP session de l'édition du SSTIC de la même année. Elle supportait quelques modules d'analyses et demandait un e ort conséquent de la part de l'utilisateur pour son installation. Le code source d'IRMA pour chacun des rôles logiques devait être récupéré sur les dépôts github éponymes. Il fallait ensuite installer tous les composants annexes (serveur FTP, RabbitMQ, uWSGI, Nginx, Redis, MongoDB) et con gurer chacune des machines hébergeant un rôle avec les adresses et données d'authenti cation pour chacun de ces services.
La version 1.0.4, sortie le 28 août 2014, a grandement facilité l'installation en s'appuyant sur le système de packaging Debian. Tous les serveurs requis étaient installés en tant que dépendance des paquets sources et des scripts de post-installation proposaient à l'utilisateur de générer les fameux chiers de con guration évoqués plus haut.
Malgré l'amélioration du processus d'installation en 1.0.4, la génération des chiers de con guration restait une étape trop fastidieuse. La version 1.1.0 a introduit une toute nouvelle méthode d'installation automatisée, en utilisant Ansible 3 , un logiciel open- source de déploiement de con guration au travers d'une connexion ssh.
De plus, et a n de faciliter le développement du projet, nous avons mis en place plusieurs environnements (développement, production ou test) à l'aide de Vagrant 4 , un logiciel open-source facilitant la création, la con guration et l'administration d'environnements virtualisés (utilisant VirtualBox, VMWare, Libvirt …).
Une fois l'environnement initialisé à l'aide de Vagrant, c'est Ansible qui va se charger d'installer tous les composants nécessaires au bon fonctionnement d'IRMA. C'est aussi lui qui va générer les chiers de con gurations et assurer ainsi la synchronisation des mots de passes entre les di érents clients et serveurs. Un autre avantage d'Ansible est qu'il peut être piloté directement par Vagrant, ainsi la création des machines virtuelles et leur con guration se fait en une seule commande.
Par défaut, Celery recommande l'utilisation d'un serveur d'ordonnancement AMQP (Advanced Message Queuing Protocol 5 ), RabbitMQ dans le cas d'IRMA, et de Redis 6 , une base de donnée clé-valeur, comme gestionnaire d'état et d'archivage des résultats des tâches.
Les versions d'IRMA avant 1.1.0 utilisaient Celery dans cette con guration et Redis était déployé sur la machine hébergeant le brain, tout en étant accessible depuis le frontend ou les probes. Laissant ouvert un problème de sécurité important. Redis n'a e ectivement aucun schéma d'authenti cation et sur le site o ciel est indiqué que Redis est supposé tourner dans un environnement de con ance 7 .
Outre les aspects sécurités, la suppression de Redis permet aussi de réduire le nombre de dépendances, déjà importantes, du projet. La partie permettant le cache des résultats a été migré vers AMQP (un autre mode de fonctionnement courant de Celery) et la partie permettant l'annulation des tâches, et donc la connaissance à tout moment, de l'état de toutes les sous-tâches a été ré-implémenté en SQLite, composant déjà présent sur le brain.
De même dans les versions d'IRMA inférieures à 1.1.0, toutes les informations étaient stockées dans une base de données MongoDB. Le principal avantage à utiliser une base NoSQL, était de ne pas devoir ger le format des résultats issus des modules d'analyses. Le problème est que les données sont très fortement liées, une analyse comporte plusieurs chiers et plusieurs résultats pour chacun de ces chiers. Une nouvelle analyse doit être capable de lier les chiers de celle-ci avec ceux déjà présents en base, indiquer de quelles analyses chacun fait partie et de retrouver les résultats liés à chacune des analyses. Toutes ces relations peuvent être implémentées dans une base NoSQL mais au prix de recopie inutile et de surcoût en espace de stockage et performance. L'approche a donc été de séparer la partie fortement relationnelle de celle qui ne l'est pas. Stocker dans la base de données SQL, les données relatives à l'analyse nommée Scan, aux chiers nommés ScanFile, à leurs résultats nommées ScanResults. Et stocker dans la base de données NoSQL les données qu'on ne voulait pas contraindre dans leur format : les résultats bruts d'analyses.
Toutes les instructions de cet article sont données pour une machine Linux. Le but est d'installer un environnement de développement pour guider le lecteur dans la création d'un nouveau module d'analyse. Les instructions sont également valables pour le lecteur qui voudrait simplement tester IRMA.
L'installation automatisée de l'environnement de développement décrite est réalisée à l'aide de Vagrant et Ansible, la partie virtualisation repose sur VirtualBox (ce sont les trois seules dépendances à installer sur la machine hôte). Dans la suite de l'article, la machine hôte sera notée host et la machine virtuelle hébergeant IRMA vm.
Pour installer Vagrant dans une version récente, se référer directement à leur documentation 8 .
Pour installer Ansible dans une version récente, il su t d'utiliser le gestionnaire de paquets de python (ou votre package manager, mais attention à la version disponible qui doit être supérieure à 1.8) :
Avant de lancer l'installation d'IRMA, il faut cloner les dépôts sources depuis la branche stable (master) :
et le dépôt github contenant les scripts d'installation IRMA pour Vagrant et Ansible :
Une fois cette étape faite, il faut installer les rôles Ansible, qui peuvent être vus comme des plugins facilitant la con guration des serveurs classiques (web, ftp…). Cette installation se fait via la commande ansible- galaxy installée avec Ansible, les rôles requis étant listés dans le chier ansible-requirements.yml :
Des modèles de con gurations (plus précisément des environnements Vagrant) permettent de facilement passer d'une con guration à une autre. Les con gurations fournies par défaut sont les suivantes :
Pour lancer l'installation, il su t de lancer Vagrant en précisant l'environnement choisi :
Au premier lancement, l'image de référence qui va servir de base pour toutes les machines virtuelles Linux est téléchargée depuis le dépôt o ciel des images Vagrant de référence nommé VagrantCloud (ou récemment renommé en Atlas 9 ). Cette image de référence, une Debian 7.7 64 bits, a été générée et mise en ligne par nos soins (les sources de génération sont accessibles à l'adresse https://github.com/quarkslab/debian). On obtient ainsi une machine virtuelle complètement installée, accessible à l'adresse 172.16.1.30, nommée brain.irma dans le chier de con guration Vagrant. À l'aide d'un navigateur, on peut véri er que le système est fonctionnel et connaître la liste des probes activées en a chant les réglages avancés comme sur la gure 2.
Après un test du système en soumettant un ou plusieurs chiers à analyser le lien vers les résultats détaillés d'un chier ressemble à la gure 3.
La partie installation est terminée et la partie développement commence. Dès qu'un des répertoires sources du frontend, du brain ou d'une probe sera modi é, il faudra le synchroniser avec la machine virtuelle en utilisant la commande Vagrant 3.1.
Si vous ne souhaitez pas avoir à retaper cette commande à chaque changement, l'alternative revient à dédier un terminal à la commande :
Pour se connecter facilement à la machine virtuelle créée on peut utiliser la commande Vagrant :
De même pour éteindre ou allumer la machine virtuelle la commande :
L'organisation du code source des probes est le suivant :
La partie intéressante de ce chier tasks.py est la suivante :
Le répertoire modules est parcouru à la recherche de modules d'analyses capables de se lancer. À chaque démarrage de la probe, les modules sont automatiquement découverts et activés pour ceux qui peuvent l'être.
Dans le répertoire modules on retrouve le code de tous ceux supportés dans la version stable 1.1.1 :
On peut noter la présence d'un module d'exemple, nommé skeleton qui peut servir de modèle dans le développement d'un nouveau module. Prenons l'exemple du module clamav :
Le chier clam.py, spéci que au module, renseigne toutes les particularités de l'antivirus : le nom de l'exécutable en ligne de commande, les options à utiliser, la liste des chiers de signatures impliqués dans la détection (pour pouvoir suivre l'évolution des détections indépendamment de la version retournée par l'éditeur) et les expressions régulières capables de traiter la sortie standard.
Le chier plugin.py fait l'interface avec IRMA en gérant les dépendances, et les formats des entrées / sorties. Par exemple, avant de charger la probe clamav, on va tester que l'environnement est bien un Linux et que le binaire clamdscan est présent.
Pour décrire toutes les dépendances d'un module d'analyse, l'utilisateur dispose des classes de dépendances suivantes :
Pour clamav on trouve donc :
Il faut aussi spéci er les dépendances python en ajoutant un chier requirements.txt. Cela facilitera l'automatisation de l'installation avec Ansible.
Le format des retours est libre mais oblige la présence de certaines valeurs :
avec comme type pour chacune des sous-clés :
Pour commencer l'écriture d'un nouveau module, le plus simple est de partir de l'exemple fourni situé dans le répertoire irma-probe/modules/custom/skeleton, les métadonnées du nouveau module sont les premières choses à modi er. Ensuite il faut lui donner un nom, remplir la partie auteur, et lui assigner une des catégories (existante de préférence pour être prise en compte par l'interface). Ces métadonnées sont renseignées dans la partie suivante :
Une méthode verify permet de rajouter un test avant le chargement d'un module. Un exemple concret est la véri cation d'un chier de con guration. La dépendance FileDependency va s'assurer que le chier de con guration existe et la méthode verify s'assurera que le chier contient bien les valeurs requises. Notez que le module d'exemple lève systématiquement une exception pour ne pas être chargé :
Pour faciliter la création des retours on peut instancier un objet de type PluginResult et le mettre à jour avec les données issues de notre analyse notamment la durée (duration), le code de retour (status) et les résultats (results).
Une fois que l'écriture de notre nouveau module est terminée, on peut facilement le tester, après avoir synchronisé le code source avec la machine virtuelle et en s'y connectant :
Une fois connecté, si nécessaire, on installe les dépendances du nouveau module
spéci é dans le chier irma-probe/modules/
Si le résultat est correct, le module est prêt à être intégré dans une probe. Pour cela, il su t de relancer la partie applicative correspondante à l'aide de Supervisord :
Et de véri er que notre module
Si le nouveau module d'analyse utilise des outils particuliers, il est tout a fait possible d'utiliser Ansible pour en automatiser l'installation.
Commencez par créer un nouveau rôle dans le répertoire irma-ansible/roles. La convention est de le nommer NomAuteur.NomRole.
Dedans, il va falloir créer un chier tasks/main.yml, qui est le chier d'entrée utilisé par Ansible pour l'exécution du rôle.
Celui-ci contiendra un ensemble de tâches qui seront exécutées à la suite les unes des autres.
Chaque tâche est organisée de la façon suivante :
Prenons par exemple l'installation de ClamAV :
La première tâche va installer à l'aide d'apt les paquets requis, la deuxième tâche va lancer une mise à jour des signatures et la dernière tâche redémarrera le service clamav-daemon.
Après avoir construit votre rôle selon vos besoins, il faut maintenant l'ajouter à la liste des rôles à exécuter lors de l'installation d'IRMA. Pour cela, il faut modi er le chier playbooks/provisioning.yml.
La dernière étape consiste à informer Vagrant de quelles machines devront exécuter ce rôle. Dans notre cas, le chier à modi er se trouve dans le répertoire environments. Il s'agit du chier allinone\_dev.yml que nous avons utilisé tout au long de cet article. Il su t d'y ajouter, avant "probe:children": :
Le nouveau module sera déployé automatiquement lors de la prochaine installation. Pour tester, on peut détruire notre environnement et le recréer :
L'API web qui tourne sur le frontend permet de créer son propre client IRMA. Par défaut, le projet est livré avec deux exemples de clients de cette API :
Une documentation dynamique, décrivant les routes accessibles de cette API ainsi que les paramètres associés, est accessible sur la machine virtuelle à l'adresse http://172.16.1.30/swagger (cf. gure 4).
Les résultats donnés dans cet article ont été obtenus sur notre serveur de test (cpu Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (8 c urs), 32Go de mémoire vive). Les tests ont été e ectués avec 2465 malwares publics téléchargés sur virussign 10 . L'environnement repose sur 23 machines virtuelles : un frontend, un brain et 21 probes linux.
| probe | min | max | moyenne |
| FSecure | 0.04s | 37.57s | 0.483s |
| VirusTotal | 0.16s | 59.78s | 0.572s |
| EScan | 1.08s | 22.57s | 1.488s |
| AvastCoreSecurity | 0.01s | 1.32s | 0.039s |
| ClamAV | 0.01s | 12.21s | 0.087s |
| ComodoCAVL | 1.14s | 8.36s | 1.342s |
| McAfeeVSCL | 13.73s | 33.33s | 18.307s |
| StaticAnalyzer | 0.0s | 22.19s | 0.196s |
| AVGAntiVirusFree | 1.36s | 4.39s | 2.119s |
| BitdefenderForUnices | 2.91s | 36.78s | 4.097s |
| Zoner | 0.0s | 31.01s | 0.078s |
| VirusBlokAda | 2.13s | 31.31s | 2.81s |
Pour pallier la lenteur d'antivirus comme McAfee, dans les 21 probes, 4 sont des probes McAfee.
| probename | infected | errors | ratio |
| FSecure | 2357/2465 | 0 | 95% |
| VirusBlokAda | 2298/2465 | 16 | 93% |
| EScan | 2455/2465 | 0 | 99% |
| AvastCoreSecurity | 2456/2465 | 0 | 99% |
| ClamAV | 1605/2465 | 0 | 65% |
| ComodoCAVL | 2454/2465 | 0 | 99% |
| McAfeeVSCL | 2152/2465 | 0 | 87% |
| AVGAntiVirusFree | 2373/2465 | 0 | 96% |
| BitdefenderForUnices | 2441/2465 | 0 | 99% |
| Zoner | 1151/2465 | 3 | 46% |
L'intérêt d'un outil comme IRMA est aussi de pouvoir évaluer sur un jeu d'exemples donné, les capacités de détection d'un antivirus. Toujours en notant, que le test est réalisé sur une base de malwares publics assez vieux et donc, normalement, assez bien détectés.
| Nb. détection | Nb. chiers |
| 0 | 1 |
| 2 | 5 |
| 3 | 2 |
| 4 | 4 |
| 5 | 14 |
| 6 | 103 |
| 7 | 178 |
| 8 | 503 |
| 9 | 798 |
| 10 | 857 |
En n on peut aussi, par exemple, dé nir des seuils de faux positifs, faux négatifs en observant la répartition des malwares ayant été détectés par un nombre donné d'antivirus. En donnant à ceux qui ont détecté seul un malware, meilleure réputation que ceux qui se contentent de détecter les chiers qui le sont aussi par tous les autres.
D'autres retours d'expériences seront abordés lors de la conférence et seront accessibles dans la présentation associée.
IRMA est un framework open-source d'analyse de malwares, facilement extensible et adaptable. S'il ne constitue pas la réponse ultime face aux menaces, il en constitue dé nitivement une brique indispensable autant pour une entreprise désireuse de renforcer la sécurité de son système, que pour un analyste de malware.
