Évaluation d’un produit anti-virus
8.5 Plate-forme de tests
8.5.2 Description de la plate-forme de test
Le tableau suivant décrit la plate-forme de test en termes d’architecture matérielle, de système d’exploitation et de logiciels :
Matériel PC Intel ou AMD, comportant au moins un port USB7.
Système d’exploitation hôte Windows 2K/XP/Vista Logiciels de virtualisation VxStripper, VMware [VMw06] Système d’exploitation invité Windows XP SP2
Sondes réseaux module VxStripper, ethereal
Instrumentation des APIs module VxStripper, MS. detours [BH99] Analyse statique de code IDA Pro, HT Editor
Analyse dynamique VxStripper, IDA Pro, Ollydbg
Analyse forensique module VxStripper, Runtime’s DiskExplorer for NTFS [Run08]
Outils de diagnostic système outils Windows Driver Devel Kit (notamment fltmc et devcon [BB97,Mic06a]), outils MS. SysInternals
Autres outils Outils spécifiques de test : alternate data stream NTFS, chemins longs NTFS, client/serveur d’injection à distance de shellcodes viraux, LSD [LSD02], Metas- ploit, conformité du moteur de filtrage des scripts (eSafe [eSa06]), rootkits (fu, klog, hook GLLK, etc.)
La préparation de la base virale de test nécessite les outils suivants :
Packers Armadillo, Asprotect, Petite, Shrinker, UPX, yC, etc.
Outils de compression et d’archivage outils GNU Win32 (formats ARC, ARJ, BASE64, BZIP2, GZIP, LHA, LZO, MIME, MS-CABINET, MS-COMPRESS, RAR, TAR, UPX, UUE et ZIP)
Outils d’unpacking module VxStripper, Import Reconstructor, Relox
Autres outils Outils spécifiques de test : moniteur temps-réel pour la maintenance de la base virale, module VxStripper de gestion de la collection de virus, corruption des formats ZIP et UPX (upxredir), système de ré-écriture de binaires/obfuscateur, VGKs
Nous avons positionné nos tests anti-virus relativement à un contexte d’attaque fixé : les techniques ont été étudiées sur une plate-forme PC Intel/MS. Windows, en raison de la large diffusion de cette plate-forme. Concernant le paramétrage de l’environnement, le système d’exploitation doit être installé depuis peu et mis à jour. Aucun autre antivirus ne doit être installé.
7Les périphériques : lecteur de disquette, lecteur CDROM, carte réseau peuvent être émulés dans la machine virtuelle sans être
présents sur la machine hôte. Ce n’est pas le cas du périphérique USB. Une carte réseau est cependant nécessaire si l’on souhaite évaluer la fonction de mise à jour du produit et/ou de ses signatures virales.
8.5.3
Tests
Nous décrivons dans cette section le plan de test permettant de valider les exigences de sécurité portant sur les fonc- tions de sécurité d’un produit anti-virus, son environnement et les composants d’assurance relatifs à sa conception. Nous présentons de façon résumée les tests, qui sont par ailleurs décrits de manière plus précise dans l’annexeA.
Installation et paramétrage du produit (environnement d’exploitation)
La première tâche de l’évaluateur consiste naturellement à « prendre en main » le produit cible après l’avoir installé et démarré. Cette tâche est effectuée en suivant les instructions de la documentation des procédures de mise en service de la cible d’évaluation et de la documentation d’exploitation, pour chaque rôle défini.
Cette première étape est l’occasion de récupérer de nombreuses informations sur les choix techniques en termes d’ar- chitecture, de conception et d’implémentation. Le jeu de tests TST_INSTALLdécrit la démarche que je propose pour automatiser le plus possible la collecte des informations lors de l’installation et du démarrage du produit cible. Je décrit également dans ce jeu de tests quelques méthodes permettant d’éprouver la robustesse de l’installation des pilotes filtres ou de périphériques, dont le bon fonctionnement et la stabilité sont cruciaux pour la réalisation des fonctions de sécurité du produit.
À l’issue de cette tâche, il est possible de mettre en regard l’information collectée sur l’implémentation du produit et les documents de conception et d’architecture du produit cible. Rappelons qu’un document d’architecture doit décrire le produit en terme de sous-systèmes et de modules (identification, interactions, interfaces). L’évaluateur doit être en mesure de se convaincre de toutes les correspondances entre la représentation de l’implémentation et les spécifications fonctionnelles.
La procédure de mise en service d’un produit antivirus comprend notamment une phase de paramétrage, lors de laquelle les caractéristiques des fonctions de sécurité (ou des sujets/objets qui leur sont soumis) sont modifiées. Cette phase offre une vue d’ensemble des fonctionnalités de sécurité, de leurs interfaces et de leurs paramétrages. Elle permet également de valider le fonctionnement correct de la fonction d’audit, qui doit journaliser les événements relevants de la sécurité. Le testTST_AUDITdécrit la démarche que je propose pour éprouver la robustesse de la fonction d’audit vis-à-vis de la modification ou de la destruction des données d’audit stockées.
La procédure de mise en service d’un produit antivirus comprend une mise à jour immédiate, puis ordonnan- cée, de la base des signatures virales et des moteurs de détection. Le testTST_UPDATEdécrit la démarche que je propose pour automatiser la collecte des informations lors de la mise à jour du produit. Le testTST_INTEG est destiné à éprouver la robustesse de la base des signatures virales, vis-à-vis d’attaques ayant pour but d’en modifier l’intégrité.
CATÉGORIE TESTS RÉSULTATS ATTENDUS Installation et mise en service du
produit
TST_INSTALL Un instantané de l’installation du
produit antivirus et une trace de ses interactions avec plusieurs des com- posants du système d’exploitation. Une idée de la robustesse du pro- duit antivirus, concernant sa pile de pilotes.
TST_AUDIT La fonction d’audit doit être
conforme au profil de protection, concernant le type d’événements et l’information qui doit être enregis- trée. Les mécanismes de protection en disponibilité et en intégrité des données d’audit stockées doivent être efficaces.
TST_UPDATE La fonction de mise à jour à la de-
mande ou ordonnancé du produit antivirus doit s’appuyer sur des mé- canismes et protocoles cryptogra- phiques permettant d’assurer sa sé- curité.
TST_INTEG Les mécanismes assurant la protec-
tion de la base des signatures virales doivent être robustes vis-à-vis d’at- taques visant à atteindre à son in- tégrité.
Ces tests sont décrits en détail dans l’annexeA.1.
Tests de conformité des fonctions de sécurité
La seconde tâche de l’évaluateur consiste à tester les fonctions de sécurité sur la base des spécifications fonction- nelles (et à documenter les résultats). L’objectif est de fournir des éléments de preuve montrant la couverture des spécifications fonctionnelles par les tests.
Remarquons qu’un certain nombre de tests de conformité doivent être effectués lors de la mise en service du produit. L’application de notre plan de test permet de ne pas avoir à ré-effectuer les procédures de mise en service.
Le test des interfaces de tous les sous-systèmes et de tous les comportements décrits dans la documentation de dé- veloppement du produit ne doit pas être obligatoirement exhaustif. L’objectif est seulement que l’évaluateur soit en mesure de comprendre précisément les aspects des fonctions de sécurité qui ont été testés. L’évaluateur va repasser un échantillon des tests passés par le développeur, puis concevoir et passer des tests indépendants de conformité des fonctions de sécurité sur la base des spécifications fonctionnelles.
J’ai spécifié un ensemble de tests permettant de valider la conformité et la fiabilité de la fonction de détection concernant :
CATÉGORIE TESTS RÉSULTATS ATTENDUS Efficacité de la fonction d’analyse
du système de fichiers
Alternate Data Streams NTFS (TST_FS.1)
Le produit antivirus est capable de détecter un code viral caché dans un flux NTFS
Chemins longs NTFS (TST_FS.2) Le produit antivirus est capable de détecter un fichier dont le nom dé- passe les 260 caractères
Analyse sur plusieurs systèmes de fichiers (TST_FS.3)
Le produit antivirus détecte l’in- fection sur tous les supports (FAT, NTFS, CIFS, CDFS) et notifie l’uti- lisateur
Analyse des clusters défectueux (TST_FS.4)
Le produit antivirus détecte un code viral dissimulé dans un bad cluster du système de fichier NTFS – l’analyse des mails entrants et sortants (TST_MAIL) :
CATÉGORIE TESTS RÉSULTATS ATTENDUS
Analyse des mails Envoi et réception d’un mail com- portant un fichier viral en pièce jointe
Le produit antivirus détecte (et dés- infecte ou supprime) la pièce jointe et notifie l’utilisateur
– l’analyse des formats de documents et d’archives (TST_FMT) :
CATÉGORIE TESTS RÉSULTATS ATTENDUS
Support et gestion des formats Format d’archive, format d’archive corrompu (TST_FMT.1)
Le produit antivirus détecte le fi- chier sur la majorité des archives et notifie l’utilisateur
Virus de macro (TST_FMT.2) Le produit antivirus détecte l’exé- cution d’un script seul, l’exécution d’un script intégré à un document MS Office et notifie l’utilisateur – l’analyse de la mémoire (TST_MEM) :
CATÉGORIE TESTS RÉSULTATS ATTENDUS
Analyse de la mémoire, exploitation de vulnérabilité mémoire
Exploitation d’un débordement de tampon, en local et via le réseau (TST_MEM.1)
Le produit antivirus détecte le dé- bordement de tampon
Analyse de la mémoire (TST_MEM.1)
Le produit antivirus détecte la pré- sence d’une infection informatique en mémoire
À ces tests s’ajoute un jeu de tests (TST_EFF) permettant de valider
– l’efficacité de la fonction de détection au regard de transformations d’obfuscation, – et la complétude de la base des signatures virales :
CATÉGORIE TESTS RÉSULTATS ATTENDUS
Efficacité de la fonction de détection Base virale (TST_EFF.1) Taux de détection global (virus toutes plates-formes)
Exécutables packés (TST_EFF.2) Le produit antivirus détecte la to- talité des exécutables packés Exécutables polymorphes, Entry
Point Obscuring (TST_EFF.3)
Le produit antivirus détecte toutes les variantes des virus modifiés (par application de techniques élémen- taires d’EPO en particulier)
La méthode d’extraction de schéma de détection [Fil06], dont le principe est rappelé dans la section ??, permet de compléter la qualification de la fonction de détection et de la base des signatures virales.
La méthode de validation de l’efficacité de la fonction de détection [FJL07, JFD08], fondée sur un moteur de polymorphisme fonctionnel, permet de qualifier la robustesse de la fonction de détection vis-à-vis de ce type de transformations.
Constatant que la plupart des éditeurs de produits antivirus proposent un module spécialisé de détection des rootkits, j’ai spécifié un jeu de tests permettant de valider l’efficacité de cette fonction de détection (TST_RK) :
CATÉGORIE TESTS RÉSULTATS ATTENDUS
Détection des rootkits Méthodes conventionnelles (global hook) et non conventionnelles (in- line patching, IAT/EAT, etc.) d’ins- trumentation des fonctions d’API en espace utilisateur (TST_RK.1.1
etTST_RK.1.2)
Le produit antivirus détecte l’ins- tallation et la présence de hooks sur les fonctions de l’API
Méthodes conventionnelles et non conventionnelles pour exécuter du code viral en mode superviseur (TST_RK.2.1etTST_RK.2.2)
Le produit antivirus détecte l’exé- cution de code viral en mode super- viseur
Détection de la corruption des ob- jets du noyau - liste doublement chaînée des DRIVER_OBJECT et/ou EPROCESS, IDT, SSDT, Sy- senter, DRIVER_OBJECT Major Function IRP Hook (TST_RK.3.1
etTST_RK.3.2)
Le produit antivirus détecte la ma- nipulation directe des objets du noyau et notifie l’utilisateur
Ces tests sont décrits en détail dans l’annexeA.2.
Analyse de vulnérabilité
La troisième tâche de l’évaluateur consiste à rechercher de manière méthodique, répétable et systématique les vulnérabilités potentielles du produit antivirus pouvant être exploitées par un attaquant.
8.6
Conclusion
Nous avons proposé dans ce chapitre une démarche et des outils permettant à un particulier ou à une entreprise d’obtenir un certain niveau d’assurance lorsqu’il choisit un produit anti-virus sur étagère.
L’utilisation conjointe d’un profil de protection (validé par la démarche méthodologique des critères communs) et la spécification de tests permettant de rendre compte de la couverture des exigences de sécurité nous semble être une base saine pour mesurer la confiance que l’on peut accorder à un produit anti-virus.
La principale limitation induite par cette approche est l’interprétation objective des tests. Même si les tests de notre plate-forme sont automatisés, les résultats sont parfois d’abord prévus pour permettre une étude plus approfondie des rouages internes du produit. Le verdict n’est pas un verdict binaire réussite/échec, mais plutôt un commentaire élaboré de l’analyste de sécurité sur la manière dont des caractéristiques internes du produit atteignent l’état de l’art dans le domaine de la détection d’intrusion basée sur l’hôte et les exigences de sécurité de cette catégorie de produit.
Notre démarche peut naturellement être optimisée. Le jeu de tests doit évoluer constamment, afin de prendre en compte les évolutions techniques des deux adversaires en présence. Une veille académique et technologique constante doit donc être maintenue, concernant en particulier :
– les nouvelles techniques et architectures logicielles antivirales ;
– les vulnérabilités liées à la conception et à l’implémentation du produit anti-virus et de son environnement.
Le profil de protection (utilisé comme base méthodologique dans ce chapitre) est également amené à évoluer pour renforcer le niveau des exigences de sécurité et donc permettre une augmentation du niveau de confiance corres- pondant. Un jeu de tests pertinent devra permette sa mise en oeuvre.
Nous avons développé dans la troisième partie de cette thèse une approche méthodologique et une plate-forme de tests permettant d’évaluer un produit antivirus sur la base de critères objectifs et partagés par une large com- munauté de professionnels de la sécurité informatique. Fondée sur une cible de sécurité générique, permettant de définir la problématique de sécurité et de spécifier le besoin de sécurité de cette catégorie de produit, notre approche permet de définir le niveau de confiance dont on peut créditer un produit antivirus et de comparer les offres de différents constructeurs sur la base des Critères Communs.
L’analyse de sécurité d’un produit antivirus se fait au regard d’une menace virale identifiée. Dans la première partie de cette thèse, nous avons centré notre étude de la menace sur les mécanismes cryptographiques et sur les aspects techniques liés au blindage logiciel et à la protection contre la rétro-ingénierie. Nous avons en particulier :
– démontré la pertinence de la cryptographie boîte blanche dans le contexte viral, – défini des axes d’amélioration des implémentations boîtes blanche de l’AES et du DES,
– donné une première contribution dans l’élaboration d’un schéma de chiffrement symétrique fondé sur la géné- ration aléatoire de S-Boxes et adapté au contexte viral.
Utilisés seuls, les mécanismes cryptographiques adaptés au contexte WBAC ne sont pas suffisants pour protéger un programme viral contre la rétro-ingénierie. Nous avons complété notre panorama de la menace virale par l’étude des mécanismes non cryptographiques (que l’on trouve typiquement dans les chaînes de compilation spécialisées dans la protection logicielle) susceptibles d’être utilisés par un virus pour asseoir la robustesse des mécanismes cryptographiques qu’il implémente et parer la rétro-ingénierie. Nous avons en particulier :
– introduit les concepts clés liés à la protection et à la rétro-ingénierie logicielle,
– effectué une revue des critères permettant l’évaluation d’une solution de protection logicielle, – proposé une démarche pour leur évaluation.
Ayant identifié les menaces à contrer et les objectifs de sécurité à atteindre, le but d’une évaluation est de contrôler, vérifier ou confirmer la conformité des fournitures aux exigences sur le contenu et la présentation des éléments de preuve. Le suivi des vulnérabilité potentielles et la mise en oeuvre de tests de conformité et de robustesse font partie des tâches fondamentales du processus d’évaluation. La couverture des objectifs de sécurité par les fonctionnalités de sécurité est au coeur de cette analyse. Nous avons privilégié l’analyse de la fonction de détection et défini des critères techniques et théoriques appropriés à l’analyse en boîte noire et en boîte blanche (c’est à dire sur la base des spécifications et/ou des informations de conception) du moteur de détection.
Nous avons donc étudié dans la seconde partie de cette thèse les moyens dont dispose la lutte anti-virale pour parer la menace virale. Nous avons étudié en premier lieu le cadre formel de l’interprétation abstraite et proposé une formalisation de la rétro-ingénierie dans ce cadre. Nous avons posé les premières bases d’une réflexion per- mettant de définir des critères objectifs pour qualifier les transformations de désobfuscation dans le contexte de l’analyse statique et de les étendre au cas de l’analyse dynamique. Nous avons en particulier :
– proposé une définition alternative de l’obfuscation dans le cadre de l’interprétation abstraite et une caractéri- sation de la désobfuscation en terme de correction et de complétude au regard d’une classe de transformations d’obfuscation,
– étudié les relations entre :
– la caractérisation d’une transformation de désobfuscation en terme de correction et de complétude vis-à-vis d’une classe de transformations d’obfuscation,
– ces mêmes notions appliquées à la caractérisation d’un moteur de détection viral.
Concernant la formalisation de la rétro-ingénierie dans un cadre théorique adapté, nous avons constaté que les méthodes dynamiques d’extraction d’information d’un programme protégé sont aujourd’hui encore mal formalisées. Nous avons étudié ensuite une méthode dynamique d’extraction d’information et discuté de son efficacité d’un point de vue technique. Nous avons en particulier développé un outil, appelé VxStripper, dédié à l’analyse de code viral, fondé sur un CPU logiciel. Cet outil est adapté à l’analyse automatique de programmes aussi dangereux que les programme viraux et permet l’instrumentation furtive des API natives et Win32. En nous appuyant sur cet outil, nous avons implémenté un algorithme d’unpacking permettant de récupérer le corps d’un virus protégé et de reconstruire l’exécutable.
Nous avons complété l’exposé des fonctionnalités de VxStripper par la présentation de son module spécialisé dans l’analyse des programmes furtifs. Ce module permet de récupérer d’informations d’intégrité et de cohérence de certaines parties du système d’exploitation depuis l’extérieur de la matrice. Nous avons en particulier étudié la transposition des méthodes de détection des hooks par contrôle de modèle et proposé une modélisation statistique de ces méthodes.
De nombreux prototypes de moteurs de détection implémentent des algorithmes de classification ou d’appren- tissage probabilistes utilisés plus traditionnellement dans le domaine de la détection d’intrusion et fondé sur une approche comportementale. Cette algorithmie s’applique à l’analyse de comportements viraux sur la base d’infor- mations statistiques et permet notamment de capturer certains aspects liés aux interactions du programme avec son environnement ou à la distribution du spectre de ses instructions. Pour analyser ce type de détecteurs, nous avons développé une modélisation statistique du problème de la détection virale, permettant de qualifier en boîte blanche les schémas de détection utilisés et de mesurer leur robustesse.
Nous avons en particulier :
– établi que les techniques de détection connues peuvent être modélisées par un ou plusieurs tests statistiques, – établi que tout test ou ensemble de test peut être contourné, en vertu du principe de simulabilité des tests
statistiques,
– proposé une reformulation en termes statistiques le résultat d’indécidabilité de F. Cohen.
Nous avons étudié dans ce cadre formel le cas de l’analyse spectrale par utilisation des réseaux bayésiens au travers de deux exemples :
– la classification « naïve » de Bayes, – le modèle de Markov caché.
Nous avons donc identifié plusieurs formalismes complémentaires applicables à la modélisation des différents com- posant d’un moteur de détection :
– la fonction d’extraction d’information ;
– la fonction de normalisation de l’information extraite ;
– la fonction d’élaboration d’un schéma de détection et son stockage dans une base d’information ; – la fonction de détection.
Nous avons pris le parti de focaliser sur les méthodes dynamiques d’extraction d’information fondées sur une émulation du matériel supportant le système d’exploitation. Notre principale contribution relative au problème d’extraction d’information concerne l’opération d’unpacking. Nous avons en outre défini un ensemble de techniques