ImunifyAV, le scanner AV qui protège 56 millions de sites Linux, vient de se faire pwn par le malware qu’il essayait de détecter. Et c’est pas la première fois…

En effet, Patchstack vient de révéler une faille RCE critique dans ImunifyAV, qui je le rappelle est un scanner antivirus gratuit ultra répandu dans l’hébergement mutualisé. Le problème en fait c’est que AI-bolit, le composant qui déobfusque le code PHP malveillant pour l’analyser, utilise la fonction call_user_func_array sans vérifier les noms de fonctions qu’elle exécute.

Boooh ! Du coup, vous uploadez un fichier PHP malveillant spécialement conçu pour l’occasion par un attaquant, ImunifyAV le scanne pour voir si c’est un malware, le déobfusque pour comprendre ce qu’il fait, et hop, le code malveillant s’exécute avec les privilèges du scanner.

Game over.

Hé pour qu’un antimalware détecte un virus, il doit analyser son code mais si les cybercriminels obfusquent leur malware pour cacher le code, l’antimalware doit alors le déobfusquer avant d’analyser. Mais déobfusquer du code PHP, ça veut dire aussi l’exécuter partiellement pour voir ce qu’il fait vraiment… d’où cette RCE.

La faille affecte donc toutes les versions avant la 32.7.4.0 et le correctif apporte juste une fonctionnalité de whitelist de fonctions autorisées pendant la déobfuscation. Il était temps, même si maintenir une whitelist de fonctions safe, à terme c’est un cauchemar car y’a des centaines de fonctions dans PHP. Certaines sont safe seules mais dangereuses combinées et je pense que les cybercriminels trouveront toujours un moyen de contourner cette whitelist.

En tout cas, comme je le laissais entendre en intro, c’est pas la première fois qu’AI-bolit se fait avoir sur la déobfuscation. En 2021, Talos avait déjà trouvé une faille sur unserialize dans le même composant. C’est la même blague car pour analyser du code malveillant sérialisé, il faut le désérialiser. Et désérialiser du contenu malveillant sans validation, ça fait “pwn” !

Voilà, 2 fois en 4 ans sur le même composant, c’est pas ce que j’appelle un accident. C’est un problème structurel car détecter du malware sans l’exécuter, c’est quasi impossible avec du code dynamique. Les signatures statiques ça marche bien pour les virus classiques mais face à du PHP obfusqué qui se reconstruit à l’exécution, vous êtes obligé de lancer le code pour voir ce qu’il fait vraiment. Et là, on est forcement en zone grise…

Même si on exécute du code potentiellement malveillant dans un environnement censé être isolé, si celui-ci “fuit” ou si le code malveillant trouve un moyen de sortir de la sandbox, vous avez une RCE. Et comme ImunifyAV tourne avec les privilèges nécessaires pour scanner tous les fichiers d’un serveur mutualisé, si vous compromettez cet antivirus, vous avez potentiellement accès à tous les sites hébergés sur la machine.

Si vous voulez tester, voici le proof of concept :

<?php
$data = "test";

$payload = "\x73\x79\x73\x74\x65\x6d"("\x74\x6f\x75\x63\x68\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74\x20\x26\x26\x20\x65\x63\x68\x6f\x20\x22\x44\x45\x46\x2d\x33\x36\x37\x38\x39\x22\x20\x3e\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74");
eval("\x70\x61\x63\x6b"($payload));
?>

php ai-bolit.php -y -j poc.php

Je vais vous raconter la meilleure de la semaine… Microsoft vient quand même de passer 5 ans à gueuler sur tous les toits que BinaryFormatter est dangereux (ça servait à sérialiser/desérialiser des objets en binaire ave .NET) et qu’il faut arrêter de l’utiliser… et pourtant, on vient d’apprendre qu’ils continuent secrètement de l’utiliser dans WSUS (Windows Server Update Services), leur système censé sécuriser les mises à jour Windows.

Et bien sûr, ce qui devait arriver, arriva… Une magnifique faille critique dans WSUS vient d’être rendue publique, ce qui met en danger environ 500 000 serveurs WSUS actuellement accessibles via le net.

L’histoire commence en réalité en 2020. A cette date, Microsoft déclare officiellement que BinaryFormatter est dangereux, ce qui ne les empêche pas de se faire poutrer Exchange, Azure DevOps, SharePoint en 2021/2021 justement à cause de ça. Du coup, en 2023, ils annoncent le bannissement total de BinaryFormatter en interne. En 2024, ils effectuent même une mise au rebus complète de .NET 9.

Mais c’était sans compter sur cette jolie CVE-2025-59287 d’octobre 2025 qui exploite à son tour BinaryFormatter dans WSUS !

Un oubli ? Pas si sûr, car Microsoft l’utilisait toujours pour déchiffrer les cookies d’authentification de WSUS, rendant ainsi ce système de mises à jour censé protéger Windows vulnérable. La faille, c’est donc une désérialisation non sécurisée. Un attaquant non authentifié envoie une requête SOAP craftée au endpoint GetCookie de WSUS, avec un cookie AuthorizationCookie contenant un payload malveillant. Et de son côté le serveur déchiffre ce truc avec AES-128-CBC, puis passe le résultat directement à BinaryFormatter pour désérialisation.

Et là, bim bam boum, une magnifique exécution de code arbitraire avec privilèges SYSTEM !

Techniquement, la vulnérabilité touche donc les Windows Server 2012 à 2025 qui ont le rôle WSUS activé. Le score CVSS de cette faille est quand même de 9,8 sur 10 ce qui est fait une faille super critique.

L’exploitation de cette faille débute le 24 octobre soit juste après la publication du patch d’urgence de Microsoft sortie la veille c’est à dire le 23 octobre, pour corriger lui-même un autre patch publié juste avant le 8 octobre. Bref un vrai bordel et il faut croire que les attaquants ont attendu la sortie de ce patch d’urgence pour comprendre comment fonctionnait la faille ( l’exploit est ici ).

De son côté, Google Threat Intelligence traque l’acteur cybercriminel UNC6512 qui a ciblé plusieurs organisations et les chiffres font pas plaisir puisque ce sont environ 100 000 tentatives d’exploitation en 7 jours qui ont eu lieues, et 500 000 serveurs WSUS exposés sur le net sur les ports par défaut (8530 HTTP, 8531 HTTPS).

Microsoft a dû sentir la douille arriver puisqu’ils ont déprécié WSUS en septembre de l’année dernière au profit d’autres solutions comme Intune ou WUfb, soit un an avant la sortie de la CVE. Mais bien sûr, comme l’outil reste dans Windows Server 2025 avec ses 10 ans de support réglementaire, des centaines de milliers d’entreprises l’utilisent encore…

Le chaos était garanti ! Maintenant vous me connaissez, je n’aime pas vous laisser sans solution, alors pour les admins sys qui lisent ça, sachez qu’il existe un script PowerShell baptisé Find-WSUS qui permet de détecter tous les serveurs WSUS configurés dans vos GPO. C’est pratique pour faire l’inventaire et vérifier que tout est patché. Et notez aussi que le patch d’urgence c’est le KB5070883. Et si vous ne pouvez pas patcher immédiatement parce que la vie est injuste, désactivez quand même le rôle WSUS de vos Windows Server, ou bloquez les ports 8530/8531 directement dans votre firewall.

Le vrai problème en fait, c’est que WSUS n’est qu’un symptôme car une grosse partie du code en entreprise est constitué de dette technique. C’est à dire du code “mort” qui continue de tourner car personne n’ose y toucher. Brrr… ça fait peur c’et sûr ! Surtout que même Microsoft n’arrive pas à tuer sa propre création 5 ans après l’annonce de sa mort officielle, donc autant dire qu’on a tous un sérieux problème.

Bref, patchez au plus vite !

Source