Il y a deux semaines environ, nos confrères de Neowin rapportaient qu’un mystérieux dossier, nommé « inetpub » apparaissait à la racine du disque sur les systèmes Windows 10 et 11. Un dossier vide, dont la suppression ne semblait entrainer aucun problème. La piste était alors une conséquence des correctifs de sécurité d’avril.
Quelques jours plus tard, Microsoft avait confirmé l’hypothèse. Il s’agissait d’un dossier créé par le correctif contre la faille CVE-2025-21204. Celle-ci pouvait déclencher une élévation de privilèges à partir de liens symboliques, ces derniers permettant de pointer vers un fichier et d’en créer un « reflet ».
« Après avoir installé les mises à jour […], un nouveau dossier %systemdrive%\inetpub sera créé sur votre appareil. Ce dossier ne doit pas être supprimé, qu’Internet Information Services (IIS) soit actif ou non sur l'appareil. Ce comportement fait partie des changements qui augmentent la protection et ne nécessite aucune action de la part des administrateurs informatiques et des utilisateurs finaux », expliquait alors Microsoft.
Cependant, ce nouveau dossier, bien que l’on ne connaisse pas vraiment son fonctionnement, peut être détourné. C’est la découverte du chercheur en sécurité Kevin Beaumont. Dans un billet publié mardi soir, il indique que le correctif, associé au dossier inetpub, crée une opportunité : un déni de service.
L'exemple donné illustre bien le problème. La commande mklink est utilisée pour créer un lien symbolique entre le dossier c:\inetpub et l’application Bloc-notes. En somme, accéder au dossier ouvre l'application.
Ce point de jonction est suffisant pour casser le fonctionnement de Windows Update si ce type de commande est exécuté avant l'installation des correctifs d'avril. Après quoi, plus aucune mise à jour ne peut alors s’installer correctement. « Le correctif de Microsoft pour la vulnérabilité de lien symbolique introduit une autre vulnérabilité de lien symbolique », ironise le chercheur.
Comme le montre la capture fournie par Kevin Beaumont, le système indique que quelque chose s’est mal passé, aboutissant à une erreur ou à un roll back, c’est-à-dire un retour à la situation initiale. La situation est d'autant plus problématique que la commande mklink peut être utilisée par des comptes sans droits administrateurs.
Le chercheur, pourtant connu sur la scène de la cybersécurité, dit avoir contacté Microsoft il y a deux semaines, sans réponse pour l’instant.
Commentaires (21)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 24/04/2025 à 18h04
Le 24/04/2025 à 18h07
Il apparait après la MAJ de sécurité, qui le créer pour contrer une faille de sécu, sauf qu'il en créer une autre par la même occasion.
Tous les postes Windows 11 l'ont, moi-même il a été crée sur mon PC alors que je n'utilise pas IIS.
Le 24/04/2025 à 23h35
Je confirme aussi.
Le 28/04/2025 à 12h12
Le 24/04/2025 à 18h08
Le 28/04/2025 à 12h12
Le 28/04/2025 à 12h38
Qu'est-ce qui justifie techniquement l'apparition de ce dossier sur les PC sans IIS ?
Tant que je n'ai pas cette réponse, il me semble bien mystérieux d'ajouter un dossier qui était alors réservé à IIS.
Modifié le 28/04/2025 à 16h03
- Empêcher la pré-compromission d’un poste qui pourra avoir IIS d’installé plus tard. Un utilisateur non privilégié pouvant créer manuellement le répertoire inetpub/wwwroot, il est possible de pré-créer ce répertoire avec un payload malicieux contrôlé par l’attaquant, par exemple un webshell. Une fois IIS déployé, le site par défaut exposera automatiquement le payload. Comme le service IIS tourne avec les droits LOCAL SERVICE, il est ensuite possible de faire une élévation de privilèges LOCAL SERVICE vers SYSTEM ;
- A priori, certaines tâches planifiées liées à Windows Update font des opérations sur des DLLs présentes dans ce dossier (si elles sont là, évidemment), lors de la recherche de mises à jour. Il n’y a pas de détails publics sur cet exploit, mais il est déjà exploité dans la nature. Comme les exécutables principaux de Windows Update tournent avec des droits SYSTEM (ou TrustedInstaller), implanter une DLL malicieuse au bon endroit l’exécutera avec ces mêmes droits.
Mon avis est que Microsoft crée ce dossier avec la dernière MAJ pour corriger rapidement la faille, et qu’une autre protection arrivera dans une prochaine MAJ. Le durcissement permettant de se prémunir de ce genre d’attaque est connu depuis très longtemps, à savoir empêcher les utilisateurs du groupe Utilisateurs Authentifiés de créer des répertoires dans %systemdrive%.
Modifié le 24/04/2025 à 19h32
Je ne sais même pas par où commencer, alors je resterai sur un euphémisme : M$ ne brille pas par une programmation défensive, ni même décente, ni même tolérable.
Rien de nouveau : je vous l'accorde.
Le 24/04/2025 à 21h29
Le 25/04/2025 à 10h39
Sur desktop : ☠️
Modifié le 28/04/2025 à 12h14
Le 24/04/2025 à 23h40
C'est une technique quasiment infaillible que j'utilise depuis des lustres pour éviter les infections par autorun sur les clés USB : créer un dossier "autorun.inf" à la racine, et lui donner les 4 attributs archive+system+read-only+hidden. De fait, si un virus duplique son exécutable sur la clé, il n'arrivera pas à créer le fichier autorun.inf car ce cas n'est jamais pris en compte dans le code. Et il ne s'exécutera jamais tout seul.
Le 25/04/2025 à 08h29
Le 25/04/2025 à 08h39
Le 25/04/2025 à 12h33
Le 25/04/2025 à 09h50
(je suis déjà dehors)
Le 25/04/2025 à 12h25
Le 25/04/2025 à 12h36
J'aurions dit la même avec un Régis ... TKT
Le 25/04/2025 à 12h30
Le 25/04/2025 à 12h48