Peut-on faire confiance aux antivirus ?

Magazine
Marque
MISC
Numéro
47
Mois de parution
janvier 2010
Domaines


Résumé

Un produit antivirus est un logiciel comme un autre, conçu et réalisé par des êtres humains, et donc susceptible de contenir des bogues. Plus ou moins graves, ces derniers peuvent donner lieu à l’absence de détection des menaces voire, dans le pire des cas, à la compromission du système par un attaquant. Cet article vous propose de découvrir dans plusieurs failles des antivirus et leurs conséquences pour l’utilisateur final. Finalement, nous donnerons quelques recommandations pour renforcer la sécurité d’un système Windows.


Body

1. DeviceIoControl m’a tuer

De façon générale, un logiciel antivirus se compose de trois parties : un pilote de périphériques destiné à intercepter les appels système, un service fonctionnant avec un niveau de privilèges élevé et finalement l’interface graphique qui s’exécute avec les privilèges de l’utilisateur.

Nous nous intéressons ici aux vulnérabilités relatives au système de communication entre l’espace utilisateur et pilote situé dans l’espace noyau, qui fait intervenir plusieurs points d’ancrage :

- la gestion des interruptions processeur ;

- l’instruction SYSENTER (méthode d’appel rapide vers le noyau) ;

- les requêtes de communication (ioctl) par l’appel DeviceIoControl() qui permettent de communiquer directement avec un pilote.

Les communications par ioctl sont principalement consacrées à l’envoi de commandes ou à la demande d’informations à un pilote. Ces requêtes proviennent potentiellement d’un processus quelconque en espace utilisateur, en particulier d’un processus qui n’est pas de confiance ; par exemple, un code malveillant ayant contourné les mécanismes de détection à base de signatures. Il est donc crucial que le pilote de l’antivirus s’assure de l’origine de l’ioctl et vérifie correctement les données qu’elle contient. Dans le cadre de la recherche de vulnérabilité, deux approches sont envisageables :

- l’ingénierie à rebours, pour comprendre le fonctionnement interne du pilote et identifier des faiblesses dans le traitement des données d’entrée ;

- l’analyse en boîte noire. Pour cela, un brouilleur automatisé d’ioctl, nommé ioctl_fuzzer [1], a été utilisé. Ce programme intercepte les appels à un ou plusieurs pilote(s) pour altérer de façon aléatoire le contenu de la requête.

Appliquons donc ce logiciel d’altération de données à avast, installé dans une machine virtuelle sous Windows XP. Le fichier de configuration XML d’ioctl_fuzzer doit être édité, soit pour cibler le pilote de périphériques aswMon2.sys, soit pour altérer la totalité des requêtes ioctl. Une fois lancé, on génère des ioctl diverses et variées en exerçant manuellement les options de l’interface utilisateur d’avast. On voit le système s’interrompre de façon inopinée (écran bleu, « blue screen of death ») lors de la modification du niveau de sécurité. Dans un déboggueur WinDbg connecté à la machine virtuelle, l’exception suivante apparaît :

'C:\Program Files\Alwil Software\Avast4\ashServ.exe' (PID: 1580) '\Device\aswMon' (0xffaf4358) [\SystemRoot\System32\Drivers\aswMon2.SYS]

IOCTL Code: 0xb2c8000c, Method: METHOD_BUFFERED

    InBuff: 0x0267b600, InSize: 0x00001448

   OutBuff: 0x00000000, OutSize: 0x00000000

Access violation - code c0000005 (!!! second chance !!!)

57523c00 ??              ???

kd>

Point très intéressant, nous remarquons que le système essaye d’exécuter avec le niveau de privilèges du noyau un code situé dans l’espace utilisateur. Chose un peu déroutante et qui n’est pas visible ici, l’application ayant généré l’erreur est explorer.exe et non ashServ.exe. Nous devons donc faire une analyse plus approfondie du bogue afin de découvrir ce qui se passe vraiment.

1.1. Analyse de la faille

En étudiant la pile des adresses de retour (« call stack »), on remarque que le bogue survient lors d’un accès à la fonction NtCreateFile(). Cela établi, nous avons écrit une preuve de concept exécutant l’ioctl déclenchant la vulnérabilité, puis immédiatement après un appel quelconque aux fonctions du système de fichiers. Résultats concluants, l’arrêt inopiné du système se produit effectivement.

On sait maintenant que le comportement du pilote d’avast peut être contrôlé pour faire exécuter du code situé à l’adresse 0x57523c00, et ce depuis un processus utilisateur arbitraire. En plaçant un shellcode à cette adresse, nous pouvons donc contrôler le flux d’exécution afin de contourner les mécanismes de sécurité de Windows et d’avast.

Un point majeur est d’assurer la stabilité du noyau après l’exploitation de la vulnérabilité. En effet, si le système fait un écran bleu dans la seconde suivant l’attaque, nous n’irons pas bien loin. Avant d’appeler le pointeur de fonction compromis, le pilote aswMon2.sys fait le test suivant :

00010356   cmp   byte ptr [00019E30], bl

0001035C   jz    short 000103BC

Si l’octet à l’adresse mémoire relative 19E30 est à 0, le pilote continuera son chemin normal. Dans le cas contraire, il exécutera le code en espace utilisateur pointé par la variable réécrite (fonc_19E24 ci-dessous). Pour rendre l’exploit complètement stable, c'est-à-dire que le système ne plante pas après l’exécution de la charge finale, il ne reste plus qu’à repositionner cet octet à 0. Ainsi, on sera sûr que les prochains appels à NtCreateFile ne seront pas redirigés.

si octet_19E30 différent de 0 {

   si mot_19E20( i1, &c5 ) positif ou nul {

      si c5 différent de 0 {

         c4 = fonc_19E24( c5, &data_181CC, &c6, 0 );

Le contenu de fonc_19E24 n’est pas directement contrôlable lors du dépassement de mémoire tampon. Mais le fait qu’il soit toujours réécrit par 0x57523c00, valeur inférieure à 0x80000000 (limite supérieure de l’espace utilisateur 32 bits) offre de manière fiable la maîtrise du code exécuté en cartographiant une page mémoire à cette adresse modulo 4096.

1.2. Implémentation de la charge finale

A ce stade, nous avons une preuve de concept qui fonctionne, il ne reste plus qu’à déterminer quelles actions devra effectuer le shellcode. Dans un premier temps, il doit réinitialiser à 0 l’octet à l’adresse relative 19E30 pour assurer que le code vulnérable d’avast n’est plus appelé. Ensuite, le jeton décrivant les privilèges du processus courant sera échangé avec celui du processus « SYSTEM » (lequel a les droits les plus élevés). Il faut enfin retourner en mode utilisateur et exécuter une charge finale classique, ici, le lancement d’une invite de commandes. La capture d’écran ci-après illustre le lancement de l’exploit :

 

MISC_47_AV

 

On constate effectivement l’élévation de privilèges du processus système ; pour plus de détails sur l’exploitation, nous référons le lecteur au code source de la preuve de concept [2].

Le logiciel avast est loin d’être un cas unique : deux vulnérabilités similaires ont été récemment découvertes dans Kaspersky [3] et GMER, et communiquées aux éditeurs respectifs. L’installation d’un logiciel de sécurité peut donc introduire de nouvelles vulnérabilités.

2. Regarde les signatures tomber

Les anti-virus se reposent principalement sur la recherche de signatures pour identifier un code malveillant. Une signature virale est plus qu’une simple suite d’octets recherchée : en 2006, Eric Filiol a montré comment définir formellement un motif de détection et faire en sorte que celui-ci soit difficile à extraire et robuste face à l’apparition de variantes (copycats). Les tests menés sur quatorze produits ont montré la fragilité de ces derniers face à l’analyse en boîte noire de leurs algorithmes de détection [4] et leur manque de robustesse vis-à-vis de souches virales dérivées. Ces résultats furent entérinés en 2008 par le concours Race To Zero [5] ; la meilleure équipe a réussi à rendre dix échantillons de codes malveillants indétectables par les antivirus majeurs du marché, ce en moins de six heures. En pratique, il est assez aisé de prendre un empaqueteur dont le code source est disponible, tel qu’UPX, pour le modifier légèrement et faire devenir l’échantillon de code malveillant compressé invisible par l’antivirus.

Qui plus est, la détection à base de signatures n’assure aucune protection contre une attaque ciblée faisant intervenir un code développé sur mesure. Ainsi, fin novembre 2009, une vulnérabilité non corrigée (dite 0-day) dans Acrobat Reader se voit exploitée durant près de deux semaines avant de devenir publique [6]. La société Adobe prévoit la sortie du correctif un mois plus tard (au plus tôt !). Faut-il pour autant arrêter d’utiliser Acrobat ? Dans les faits, le vecteur d’intrusion le plus utilisé est l’interpréteur JavaScript, il est donc conseillé de désactiver cette option depuis le menu Edition / Préférences.

3. On achève bien les antivirus

La conférence iAWACS, organisée par l’ESIEA Recherche, a eu lieu à Laval du 23 au 25 octobre 2009. iAWACS favorise le point de vue de l’attaquant pour améliorer la sécurité des systèmes. Les articles retenus pour la première édition s’inscrivent dans cet état d’esprit, avec par exemple la démonstration d’attaques réseau passives comme actives depuis une connexion satellite. Lors de la conférence a été organisé le concours « PWN2RM » ayant pour but de démontrer qu’il est possible de désactiver de manière furtive différents logiciels antivirus dans un temps limité (trois sessions d’une heure chacune). Les participants incluent l’un des auteurs du présent article ainsi que Samir Megueddem, étudiant à l’Université de Valenciennes.

Deux machines physiques disposant du logiciel VMware ont été fournies, avec pour chaque antivirus un snapshot pris après son installation et sa mise à jour. De cette manière, il est possible de changer rapidement d’antivirus lors des tests et reproduire à l’identique les résultats d’un test donné. Sept produits, dans leur dernière version, étaient en lice : McAfee, Norton, G-DATA, Kaspersky, DrWeb, AVG et ESET.

Tous les produits testés incluent un niveau minimal de protection vis-à-vis d’appels système compromettant leur intégrité : terminaison des processus de l’antivirus, suppression des bases de signatures, etc. Au terme du concours, seul DrWeb a résisté dans le temps imparti aux tentatives des participants ; tous les autres produits ont pu être désactivés par différentes méthodes (voir tableau ci-après). Il faut noter que les règles du concours interdisaient de redémarrer le système et de désactiver l’antivirus par des moyens conventionnels, c’est-à-dire depuis l’interface graphique du logiciel.

 

Anti-virus

Technique employée

McAfee

Désactivation du service de scan à la demande depuis un processus ayant élevé ses privilèges au niveau « SYSTEM ».

Norton

Création d’un partage réseau pour le répertoire des signatures ; accès au partage \\127.0.0.1\virusdefs en tant que SYSTEM et suppression des fichiers.

ESET

Modification des pages mémoire de la bibliothèque utilisée par le processus de scan en accédant au fichier spécial \Device\PhysicalMemory (technique documentée en 2002 par crazylord dans phrack).

G-DATA

Scan à la demande désactivé en stoppant le périphérique noyau via le « Service Control Manager ».

Kaspersky

Même méthode que pour ESET. A noter que Kaspersky affiche un message d’avertissement lors de la tentative d’accès à la mémoire physique ; l’attaque n’est donc pas complètement furtive.

AVG

Même méthode que pour ESET.

Ces résultats ont eu un écho notable en créant un certain « bourdonnement » sur Internet. Les détracteurs du concours avancent principalement que les conditions des tests sont trop faciles (les comptes utilisés sous Windows XP disposant des droits d’administration) et que la durée présentée dans les résultats pour chaque antivirus n’est pas une métrique fiable.

Ces objections sont valides en soi. Rappelons néanmoins qu’à l’heure actuelle, Windows XP reste encore largement utilisé, le plus souvent depuis un compte avec des droits administrateur. Par ailleurs, les vulnérabilités identifiées lors du concours sont réelles et pourraient être utilisées par un code malveillant pour désactiver l’antivirus de façon automatisée. Les détails techniques pour reproduire les tests ont ensuite été communiqués aux développeurs d’antivirus en ayant fait la demande.

La seconde édition de la conférence iAWACS aura lieu en avril 2010 [7]. Elle sera de même orientée sur la sécurité informatique considérée du point de vue de l’attaquant et la formalisation théorique de résultats expérimentaux. Un nouveau concours, dénommé « PWN2KILL », aura lieu durant la conférence. Cette fois, les conditions retenues seront plus contraignantes car les codes de désactivation seront lancés sous Windows 7 depuis un compte sans privilège d’administration.

Conclusion

Au terme de cet article, on pourrait croire que les antivirus sont peu efficaces, et donc qu’il est inutile d’en installer un sur son poste de travail. Bien au contraire : un antivirus n’est pas inutile, et nous conseillons d’en avoir un installé et régulièrement mis à jour. Mais ce ne doit pas être la seule ligne de défense ; plusieurs autres mesures permettent de renforcer la sécurité globale du système :

- l’utilisation d’une version légitime de Windows et l’application régulière des correctifs de sécurité ;

- la mise à jour des applications tierce partie, en particulier Acrobat Reader, Flash et Microsoft Office. Il est bon de désactiver les fonctionnalités non utilisées, comme le JavaScript dans Acrobat Reader et les macros d’Office ;

- si possible, employer des logiciels open source en lieu et place de leur équivalent propriétaire : OpenOffice, SumatraPDF, VLC, etc.

- l’activation de l’option de prévention d’exécution pour tous les processus (par défaut, seuls les services système de Windows sont concernés) ;

- pour les utilisateurs de Firefox, l’installation du module complémentaire « noscript ».

Finalement, ces mesures ne sont rien sans la sensibilisation du public pour inciter le plus grand nombre à faire preuve de vigilance lors de leur utilisation de l’outil informatique.

Références

[1] http://code.google.com/p/ioctlfuzzer/

[2] http://www.sysdream.com/LocalEscalation_Avast.rar

[3] http://sysdream.com/article.php?story_id=323&section_id=78

[4] FILIOL (Eric), « Malware pattern scanning schemes secure against black-box analysis » ; Journal of Computer Virology, vol. 2, no. 1, pages 35–50, (2006).

[5]http://www.racetozero.net/

[6]http://contagiodump.blogspot.com/

[7]http://www.esiea-recherche.eu/iawacs_2010.html

 



Articles qui pourraient vous intéresser...

Introduction aux TPM (Trusted Platform Modules)

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Les TPM (Trusted Platform Modules), brique de base du Trusted Computing, ont été imaginés il y a une vingtaine d’années, et pourtant ils ne sont pas très utilisés malgré leurs réelles qualités. Comment expliquer cela ? Cet article tend à fournir de premiers éléments de réponse.

Identification automatique de signaux grâce à la fonction d’autocorrélation

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Vous connaissiez la chasse au trésor… Initiez-vous maintenant à la chasse au signal (signal hunting en anglais). La chasse au signal consiste à rechercher les signaux qui nous entourent dans l’espace invisible du spectre électromagnétique. Mais plus besoin de rester l’oreille collée sur un haut-parleur à tourner le bouton pour régler la fréquence. La SDR (Software Defined Radio) a révolutionné tout cela : une radio numérique et un PC est vous voilà armé pour découvrir ce monde que les professionnels dénomment le SIGINT (SIGnal INTelligence).

Avec le Spanning Tree Protocol, suis-je en sécurité dans mon réseau ?

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Dans le cadre des hors-séries sur les retours aux fondamentaux, cet article aura comme sujet le protocole STP (Spanning Tree Protocol). Inventé en 1985 par Radia Perlman, il permet principalement d’assurer une liaison réseau redondante et sans boucle. Ce protocole étant primordial au sein d’un réseau de moyenne à grande envergure, s’il n’est pas correctement configuré, cela pourra alors permettre à des attaquants de compromettre le réseau.

Return oriented programming 101

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Le Returned Oriented Programming (ou ROP) est une technique permettant d'exploiter des programmes disposant de la protection NX (No eXecute) ou DEP (Data Execution Prevention). L'objectif de cet article est de vous présenter les bases du ROP, ainsi que l’exploitation pas-à-pas d’un programme d’entraînement via l'utilisation de la bibliothèque python pwntools [1]. Dans un souci de simplicité, la démonstration sera réalisée sur un programme s'exécutant sur un système Linux 64 bits. Bien entendu, cette démonstration reste applicable sur d'autres architectures (ARM, MIPS, etc.).

Use-After-Free dans le noyau Linux

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Pièce logicielle qui a accompagné les deux dernières décennies, le noyau Linux est un système relativement complet qui dispose d’un allocateur de mémoire dynamique. Comme tous les logiciels classiques, le noyau est ainsi régulièrement sujet à des vulnérabilités de type Use-After-Free via cet allocateur.