Peut-on faire confiance aux antivirus ?

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 :

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 :

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.

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 :

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.

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