Répercutions des bancs d’essai dynamiques

Répercutions des bancs d’essai dynamiques

La problématique liée aux répercussions des bancs d’essai est familière à quiconque se trouve impliqué de près ou de loin dans la lutte contre la malveillance informatique – dernièrement, ce sujet est au centre de l’attention, en particulier depuis la création de l’AMTSO (Anti-Malware Testing Standards Organization), en début d’année.

Cet article ne prétend pas donner une nème explication sur ce que doit être une procédure d’essai correcte. En revanche, il cherche à souligner un effet collatéral possible de la médiatisation des essais dynamiques, à savoir, que la publicité donnée à cette méthodologie peut inciter les auteurs malveillants à vouloir contourner directement les mesures de protection proactive des produits testés, plutôt que d’échapper simplement aux fonctions de détection.

Cet article présente des exemples et des scénarios permettant d’évaluer les risques associés aux essais dynamiques. Nous l’enrichissons également de suggestions sur la façon dont les testeurs peuvent réduire ce genre de risque.

Méthodes d’essai

Avant d’évaluer les risques associés aux essais dynamiques, commençons par faire un tour rapide d’autres méthodes.

Bancs d’essai statiques

La méthode d’essai statique est la plus simple : une analyse à la demande est effectuée sur une collection de logiciels malveillants. Pour obtenir des résultats significatifs, de nos jours, un essai statique qui se respecte doit utiliser des milliers d’échantillons malveillants. Les procédures des laboratoires d’essai AV-Test et AV-Comparatives en comptent habituellement des centaines de milliers, parfois même, plus d’un million.

Avec un nombre d’échantillons aussi important, les résultats des tests n’offrent que peu (ou pas du tout) d’informations utiles, susceptibles d’aider les auteurs malveillants à mettre au point leurs créations.

Une autre précaution à prendre au cours d’un banc d’essai statique concerne la présentation des résultats. Certains tests peu crédibles semblent utiliser un grand amas d’échantillons non-triés, et même si les résultats énumérés sont obtenus à partir de sous-catégories à usage interne, cette pratique doit être considérée comme mauvaise.

D’autres bancs d’essai, un peu plus dignes de confiance, publient leurs résultats selon une division adéquate. Les tests sont classés par sous-ensembles (virus, vers, chevaux de Troie…) et des résultats sont publiés pour chacun d’entre eux. Certains vont encore plus loin et introduisent des nuances à l’intérieur des chevaux de Troie, par exemple, en différenciant les portes dérobées et les logiciels espions.

Malgré un niveau de détail plus grand, cette méthode n’apporte pas davantage de renseignements utiles aux auteurs malveillants. Le seul risque qu’on puisse reprocher aux essais statiques concerne leurs explications sur les méthodes de détection de code polymorphique ou métamorphique. Les faiblesses de certains produits deviennent évidentes dans des tests de ce genre.

Quoi qu’il en soit, du code polymorphique ou métamorphique implique par nature une difficulté de détection bien supérieure à celle du code statique – autrement dit, il est peu vraisemblable qu’un auteur capable d’écrire ce genre de code en soit réduit à étudier les résultats d’un banc d’essai pour se faire une idée. Cela dit, quelqu’un de trop incompétent pour créer du code polymorphique pourra alors se tourner vers le milieu de la cybercriminalité, pour y chercher ou acheter un logiciel de ce genre, ou pour inciter quelqu’un d’autre à le créer à sa place.

Bancs d’essai sur les délais de réponse

Ces derniers temps, les tests sur les délais de réponse sont devenus rares, mais il n’est pas inutile de revenir sur eux. Leur plus grand succès remonte à l’époque des grandes épidémies provoquées par les vers de messagerie – Netsky, Bagle, Mydoom, Sober et Sobig sont des exemples classiques de cette période.

Contrairement aux essais statiques, les essais sur les délais de réponse font appel à des groupes d’échantillons de très petite taille. Un premier type de test consiste à mesurer la réactivité globale des fournisseurs AV, dans le cadre d’un ensemble de tests plus large, mais toujours relativement réduit 1 – ce type de test ne fait donc pas ressortir des résultats qui soient directement liés à des échantillons en particulier. En revanche, le deuxième type de test mesure le taux de détection échantillon par échantillon 2.

L’obtention de résultats directement liés aux échantillons testés, peut se transformer en une aide précieuse pour les auteurs malveillants. On peut d’ailleurs supposer que la publication des temps de réponse a conduit certains de ces auteurs à modifier leur code afin de minimiser les chances de détection. Un bon exemple est le ver W32/Sober.K 3, qui ajoutait des données de remplissage en fin de fichier pendant son installation, dans le but délibéré de ralentir la détection par l’AV. Il y a fort à parier que son auteur a introduit cette fonctionnalité après avoir été déçu par des délais de détection très bas des variantes Sober.

Aujourd’hui, les essais sur les délais de réponse sont présentés de manière plus générique, et contiennent peu de références à des échantillons concrets. Le risque que les auteurs malveillants puissent en tirer trop d’informations est donc très réduit.

Bancs d’essai rétrospectifs

Dans un banc d’essai rétrospectif, on teste des échantillons malveillants récents sur un produit qui n’est plus à jour. Mis à part l’intérêt intrinsèque du test (mesurer la capacité du produit à détecter des échantillons inconnus) et l’ancienneté des mises à jour, il n’y a pas de différence entre un essai rétroactif et un essai statique. Comme pour les essais statiques, le niveau de risque introduit par les essais rétrospectifs est très bas.

Bancs d’essai dynamiques

Dans un banc d’essai dynamique, des échantillons malveillants sont exécutés dans un environnement spécial de test. En raison du temps requis par ce processus d’exécution, seul un petit nombre d’échantillons peut être utilisé. L’AMTSO a publié un document qui décrit avec abondance de détails les principes méthodologiques des bancs d’essai dynamiques (http://www.amtso.org/documents.html).

Dans l’idéal, les échantillons sont introduits dans l’environnement de test de la manière « correcte » – par exemple, à travers un téléchargement sur disque. Même automatisée, une telle tâche prend énormément de temps, et le fait qu’il soit nécessaire d’éviter l’utilisation de machines virtuelles pour obtenir des résultats valables n’accélère en rien le procédé.

Le nombre d’échantillons inclus dans les essais est actuellement de quelques dizaines. Au fur et à mesure de l’amélioration des matériels et de l’optimisation des procédés, on peut espérer que le nombre d’échantillons utiles soit de l’ordre de la centaine. Toutefois, l’apparition des bancs d’essai dynamiques suppose un risque bien plus important pour le secteur, comparé aux autres méthodes.

Notre secteur investit beaucoup de temps dans la publicité des (nouvelles) technologies proactives, et l’AMTSO a réalisé un travail considérable dans l’élaboration de son manuel de mise en œuvre de scénarios dynamiques (http://www.amtso.org/documents.html). D’une manière générale, le message transmis aux responsables des bancs d’essai revient à dire que la seule comparaison des taux de détection ne suffit plus, qu’il faut désormais prendre en compte les technologies proactives des divers produits.

Il va sans dire que les auteurs malveillants en sont les tous premiers intéressés.

Les temps évoluent

Il y a cinq an environ, Symantec a incorporé une fonction proactive appelée « Anti-worm » dans les produits Norton. Il s’agissait d’un système d’analyse du comportement permettant la capture rétroactive des vers de messagerie. Symantec s’attendait à devoir mettre à jour sa technologie au plus tard six mois après son introduction, afin de lui conserver toute son efficacité, compte tenu de l’évolution des programmes malveillants. Pourtant, les développeurs n’ont jamais eu à mettre à jour leur procédé 4. Soit les auteurs malveillants n’ont pas eu vent de cette technologie, soit ils n’ont pas essayé, ou même été capables de la contourner.

En Mai 2006, la version 6 de la gamme de produits Kaspersky Lab introduisait une technologie comportementale de nouvelle génération. Six mois plus tard, un correctif était déjà nécessaire parce que de nouvelles variantes du cheval de Troie LdPinch étaient parvenues à contourner le bloqueur de comportement, initialement capable de les capturer.

En quoi ces deux bloqueurs de comportements étaient-ils différents ? La fonction Anti-worm date de l’époque des grandes épidémies virales, où l’objectif essentiel des auteurs malveillants était la renommée personnelle. En revanche, en 2006, le mobile de la plupart des logiciels malveillants est devenu l’appât du gain, y compris dans le cas de LdPinch. Un autre aspect dont il faut tenir compte, c’est que Kaspersky Lab est une société implantée en Russie, que LdPinch était une création russe, qui visait donc principalement le marché russe.

Mais il y a une troisième raison qui pourrait expliquer cette différence (sous toute réserve, l’auteur de cet article n’étant en aucune façon expert en marketing) : il semble en effet que l’effort publicitaire de Kaspersky Lab sur son bloqueur de comportement en 2006 avait été supérieur à celui réalisé à l’époque par Symantec pour la fonction « Anti-worm ». Ce qui explique que les auteurs malveillants, plus réceptifs à la campagne organisée pour les produits Kaspersky, ont fait l’effort de le contourner.

Multi-analyseurs

Les sites multi-analyseurs sont un autre exemple intéressant de comment les auteurs malveillants détournent des services légitimes pour en tirer des informations utiles pour eux. Les sites multi-analyseurs connaissent un grand succès dernièrement, avec en tête JottiScan et VirusTotal.

Le service que ces sites offrent aux utilisateurs consiste à transférer un fichier pour le faire examiner par un éventail de moteurs d’analyse, afin de déterminer ce que les différents produits parviennent à détecter (et s’ils en sont capables).

Ces services ont également du succès auprès des auteurs malveillants, qui les utilisent pour tester leurs dernières créations et vérifier qu’ils parviennent à éviter la détection. Certains fournisseurs de logiciels antimalware proposent leurs moteurs les plus récents, et demandent aux responsables de ces sites d’utiliser les paramètres permettant de détecter un maximum de logiciels malveillants. Mais tous ne fournissent pas des produits récents. Il arrive qu’ils demandent à l’administrateur de préférer une configuration plutôt moins performante du produit, pour que celui-ci détecte moins de logiciels malveillants qu’il n’en est capable en contexte d’exploitation réelle 5, et donc pour ne pas révéler toutes ses capacités.

Répercussions dans le milieu

Ces derniers temps, les logiciels malveillants capables de contourner les caractéristiques proactives sont loin d’être rares. Mais la plupart des auteurs malveillants continue encore de se concentrer sur le contournement des mécanismes de détection uniquement.

Parfois, certains produits anti-malware sont peu sophistiqués, et quand un logiciel malveillant évite la détection, c’est en pratique tout le produit qu’il contourne. En ce sens, rien d’étonnant à ce que l’on rencontre des échantillons malveillants du type Win32 PE, dont le code est à ce point obscurci que le démêler peut prendre jusqu’à deux minutes sur un Core 2 Duo fonctionnant à 2500 MHz. Pourtant, cela fait deux ans qu’il est possible d’identifier ces mêmes échantillons selon des procédés proactifs, moyennant les technologies propres aux bloqueurs de comportements 6.

Cela ne fait aucun doute que la publicité actuelle autour des technologies proactives et des essais dynamiques finiront par attirer l’attention des auteurs malveillants. Compte tenu du buzz qui entoure ce sujet, il est probable que les auteurs de malware se sentiront piqués au vif.

Plusieurs scénarios sont susceptibles de se produire : en premier lieu, il est probable que de nouveaux groupes, dans les milieux de la malveillance, unissent leurs efforts pour produire des logiciels capables de contourner ces technologies proactives. En second lieu, un nouveau marché s’ouvre pour les sites multi-analyseurs, qui testent les technologies proactives et les capacités de détection de différents produits. La grosse difficulté que supposent les technologies proactives, c’est le colmatage des brèches que les logiciels malveillants parviennent à exploiter. Alors qu’un fournisseur peut mettre à jour une base de signatures en quelques heures, voire quelques minutes, une brèche dans la sécurité proactive exige beaucoup plus de temps – le délai de réaction se mesure ici en semaine(s), et non en jours et encore moins en heures.

Que peuvent faire les testeurs ?

Communiquer certains détails des tests, comme des résultats par échantillon par exemple, dans le contexte de bancs d’essai dynamiques, se révèle une idée encore plus désastreuse que pour des tests sur les délais de réaction. Si le risque de fournir un excès de détails reste faible dans le cas des délais de réponse, il est au contraire très élevé dans le cas d’essais dynamiques.

Plus le jeu d’échantillons utilisé est restreint, et plus les échantillons retenus gagnent en pertinence. Quand des résultats de tests publiés portent sur des échantillons aussi stratégiques, en y décrivant les performances de chaque produit, les responsables des bancs d’essai fournissent en réalité des renseignements extrêmement précieux aux auteurs malveillants. Cela revient à leur expliquer quels sont les produits dont ils doivent se servir pour améliorer leurs propres créations.

Virus Bulletin ne publie plus de résultats d’essais dynamiques, mais prévoit d’utiliser des informations obtenues de tables de prévalence (en préparation) afin d’y choisir les échantillons destinés aux tests. Mais en mentionnant au départ seulement les familles de logiciels malveillants, les testeurs peuvent finir par communiquer des noms concrets de logiciels malveillants 7.

AV-Comparatives a lui aussi cessé de publier des résultats d’essais dynamiques, mais a l’intention de communiquer les noms des échantillons qui seront utilisés lors des tests futurs.

Comme nous l’avons fait remarquer, il convient d’éviter ce genre d’approche. AV-Test qui organise déjà des essais dynamiques, a adopté pour sa part une approche préférable. Les magazines se sont vu interdire la communication des noms de logiciels malveillants ou les panachages de fichiers utilisés pour les tests. Malgré tout, AV-Test communique ces informations aux fournisseurs AV qui participent aux bancs d’essai 7.

En dépit d’une moindre transparence pour les utilisateurs finaux, cette approche est de loin préférable pour mitiger les risques, et elle permet aussi au fournisseur d’informer le testeur, si les échantillons introduits s’avèrent peu pertinents pour la procédure de tests.

Conclusions

L’adoption des essais dynamiques introduit des défis nouveaux. Plus que jamais, les bancs d’essai peuvent avoir une influence réelle sur les auteurs malveillants et leurs agissements. Les fournisseurs de sécurité doivent tempérer leur vocation divulgatrice, s’ils ne veulent pas perdre de vue l’essentiel, à savoir, la protection des utilisateurs.

Il faut éviter de créer une situation dans laquelle une pédagogie mal comprise peut accélérer l’évolution des logiciels malveillants et produire plus de problèmes que de solutions. La première règle énoncée par l’AMTSO dans son document sur les principes fondamentaux des bancs d’essai précise bien que ces derniers ne sauraient mettre en danger le public (http://www.amtso.org/documents.html).

La divulgation des tests de technologies proactives et des bancs d’essai dynamiques entraîne inévitablement le progrès de tous les savoir-faire, y compris ceux des auteurs malveillants. Il appartient donc à l’industrie dans son ensemble, éventuellement dans le cadre de l’AMTSO, de minimiser les risques et de veiller à ce que trop de détails sur les résultats des bancs d’essai ne soient communiqués au public.



  1. AV-Test – banc d’essai sur les délais de réponse 2005.

  2. AV-Test -résultats sur les délais de réponse sur les variantes de W32/Sober .

  3. F-Secure – étude sur W32/Sober.K.

  4. Kennedy, M. – communications de l’auteur.

  5. Bosveld, J.; Canto, J. — communications des auteurs.

  6. Le nom exact de l’échantillon est disponible auprès de l’auteur de cet article.

  7. Clementi, A.; Hawes, J.; Marx, A. – communications des auteurs.

Cet article est paru dans le journal Virus Bulletin en décembre 2008.

Posts similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *