A l’occasion de l’iAwacs (International Alternative Workshop on Agressive Computing and Security), trois jours durant, enseignants, étudiants, responsables sécurité, chercheurs indépendants ou du monde de l’industrie se sont réunis dans les locaux parisiens de l’Esiea (Ecole Supérieure d’Informatique Electronique Automatique). Une série de conférences cordonnée par le désormais traditionnel challenge Pwn2kill, exercice de pentesting visant une quinzaine d’antivirus.
Challenge à la fois étonnant et sans grande surprise, placé, comme les années précédentes, sous la houlette d’Eric Filiol, Directeur de la Recherche et du Développement Industriel de l’école. Sans surprise car depuis les dernières grandes attaques de botnet dont certaines sont passées totalement inaperçues par bon nombre d’A.V., plus personne ne s’étonne que les outils de protection périmétrique soient imparfaits « eux aussi ». Etonnant également, car si certains « proof of concept » étaient d’une subtilité remarquable (polymorphisme, chiffrement de données à clef constamment modifiée, infections multiples doublées d’un contrôle mutuel d’intégrité des virus par eux-mêmes…), certaines vieilles ficelles ou comportements antédiluviens continuent à « passer », malgré les nombreuses communications effectuées à ce sujet : installation d’un code suspect dans le menu démarrer, consommation de ressources anormalement brutale, inscription d’un exécutable par lui-même dans la clef Run de la ruche, passivité étonnante face à certaines macros particulièrement actives, assassinat de processus en userland avec des privilèges « user » (les accès « administrateurs » n’étaient plus tolérés cette année, et la seule plateforme acceptée était un Windows 7 « à jour »)… Sur 15 antivirus testés et 7 « virus concept », une seule attaque s’est avérée globalement inefficace pour de simples problèmes d’adaptation du code aux conditions « locales » du concours. Les autres sont généralement parvenues au terme de leur exécution sans éveiller l’antivirus ni lors de l’examen du fichier « infecté » ni à l’exécution du code. Le résultat final de la campagne de test montre que certains logiciels ont parfois signalé un comportement suspect en laissant à l’utilisateur, pour certains, la possibilité de passer outre. Rares ont été les protections capables de bloquer ces assauts sans donner à l’usager la possibilité de passer outre (le syndrome des UAC Microsoft ayant « dressé » bon nombre d’utilisateurs à cliquer sans réfléchir sur toute fenêtre de pop-up).
Nul besoin d’être devin pour distinguer les programmes d’attaque les plus élégants : ce sont également les plus efficaces (attaques numéro 6, 4 et 1 par ordre d’appréciation du jury, voir sur le site Web de l’Esiea). Mais mêmes brutaux et sans finesse, certains codes se sont révélés d’une efficience digne du cheval d’Attila. L’attaque numéro 5, par exemple, un simple batch lançant une boucle consommatrice de ressources s’avère diablement efficace et n’est bloquée que par deux antivirus. Résultat guère encourageant pour un bout de code que l’on peut écrire sous Notepad en 5 minutes et qui pourrait agenouiller toutes les stations de travail d’une entreprise en un instant. Avec toutefois un léger bémol : il est rare que dans une entreprise correctement gérée, l’administrateur laisse à ses utilisateurs les droits d’écriture sur la registry ou dans le menu « programme-démarrer ».
Faut-il en conclure que les antivirus ne servent à rien ? Ce serait aller vite en besogne. Ils protègent des principales attaques provenant d’Internet, autrement dit une impressionnante quantité de menaces bien réelles. Mais leur absolue efficacité doit être remise en question au moins dans deux cas de figure précis : lorsque l’attaque est totalement nouvelle et n’a pas encore été détectée par les honeypots ou les « retours de logiciels clients » des éditeurs d’antivirus, et lorsque l’on est confronté à une agression ciblée qui n’a par définition aucune « chance » de se répandre sur Internet… et donc d’être détectée. Contre de telles menaces, le principe de fonctionnement (détection « in the wild »+autopsie du programme+rédaction de signature+diffusion et enrichissement de chaque A.V. installé) doit rapidement évoluer, s’enrichir à la fois de nouveaux mécanismes d’analyse comportementale et d’outils bien plus intelligents en matière d’examen de la structure des binaires douteux. Le système d’exploitation lui-même pourrait fort bien prendre le relais dans certaines circonstances. Quelques activités pourraient ainsi être interdites d’exécution par les UAC… notamment les écritures sauvages en BDR provenant d’un programme cherchant à s’inscrire lui-même, ou au moins demander une confirmation d’exécution exigeant un privilège plus élevé. Voilà qui serait bien plus utile que de demander inlassablement à l’usager d’autoriser le lancement d’un driver de souris non signé à chaque démarrage de l’ordinateur. Ceci en attendant l’avènement des systèmes n’acceptant d’exécuter que des exécutables « signés/certifiés »… ce qui posera à son tour la question de l’indépendance, de la compétence et du « coût » de l’autorité délivrant lesdites signatures.
Le regard que l’on porte sur les antivirus au terme d’une telle journée de tests ressemble un peu à celui d’un parent sur sa progéniture adolescente : la confiance sans illusion. Contre une attaque « non répertoriée », même utilisant des techniques connues, voir d’un classicisme désuet, les solutions de protection antivirales ne servent pratiquement à rien. Une rapide lecture de Millw0rm (même dans son état actuel d’abandon), du Bugtraq ou de la liste F.D. montre que c’est probablement aussi le cas des autres outils de protection périmétrique.
NdlR : L’auteur précise, par souci de transparence, que la Rédaction de CNIS-Mag faisait partie du jury du concours P0wn2kill. Une fonction presqu’uniquement « honorifique » puisqu’elle se limitait à vérifier l’absence d’éventuelles tricheries et à constater, test après test, la réaction ou l’absence de réaction des logiciels de protection et des « user access control »du noyau.
2 commentaires