Un contournement de la signature des pilotes Windows pourrait permettre l’installation de rootkits noyau
(bleepingcomputer.com)- Même sur un Windows apparemment à jour avec les derniers correctifs, si le processus Windows Update est pris sous contrôle, il peut être ramené à d’anciens composants noyau, ce qui peut conduire à un contournement de Driver Signature Enforcement et au déploiement de rootkits noyau
- Alon Leviev, chercheur chez SafeBreach, a présenté à BlackHat et DEFCON des attaques par downgrade/retour de version, et la prise de contrôle de Windows Update n’est toujours pas entièrement corrigée
- Un attaquant disposant de droits administrateur peut, même sur la dernière version de Windows 11, remplacer ci.dll par une version non corrigée afin de permettre le chargement de pilotes noyau non signés
- Virtualization-based Security s’appuie sur le verrouillage UEFI et des paramètres du registre ; dans les configurations dépourvues du drapeau Mandatory, la modification du registre ou le remplacement de fichiers essentiels peut constituer une voie de contournement
- Microsoft développe une mise à jour de sécurité visant à retirer les anciens fichiers système VBS, mais la date de publication reste incertaine en raison de l’analyse des versions affectées, des tests de compatibilité et de la prévention des régressions
Des attaques par downgrade qui neutralisent l’état « à jour »
- Un attaquant peut contrôler le processus Windows Update pour réintroduire des composants vulnérables anciens dans un système qui semble à jour
- Le système d’exploitation paraît toujours entièrement corrigé, mais il est en réalité de nouveau exposé à des vulnérabilités déjà corrigées
- Les cibles du downgrade incluent des DLL, des pilotes, le NT kernel, entre autres
- Alon Leviev a publié l’outil Windows Downdate, montrant qu’il est possible de créer des downgrades personnalisés
Contournement de Driver Signature Enforcement et risque de rootkit
- Leviev a démontré qu’il reste possible de contourner Driver Signature Enforcement(DSE) même après le renforcement de la sécurité du noyau
- Une fois le contournement de DSE réussi, l’attaquant peut charger des pilotes noyau non signés
- Ces pilotes peuvent servir à déployer des malwares rootkit capables de désactiver des contrôles de sécurité et de rendre la détection d’une compromission plus difficile
- Leviev appelle sa méthode
"ItsNotASecurityBoundary" DSE bypass- Elle consiste à downgrader l’exploit ItsNotASecurityBoundary
- Cet exploit s’appuie sur une catégorie de vulnérabilités Windows de fausse immutabilité des fichiers(false file immutability) identifiée par Gabriel Landau d’Elastic, permettant l’exécution de code arbitraire avec des privilèges noyau
Remplacement de ci.dll et condition de redémarrage
- Dans ces nouveaux travaux, Leviev montre qu’un attaquant disposant de droits administrateur peut exploiter le processus Windows Update pour contourner la protection DSE même sur un Windows 11 entièrement mis à jour
- L’idée centrale consiste à remplacer ci.dll, qui applique DSE, par une version non corrigée qui ignore la signature des pilotes
- Une fois le composant downgradé vers une version vulnérable, un redémarrage du système est nécessaire, comme dans un processus de mise à jour normal
- Leviev a publié une démonstration sur un système Windows 11 23H2 entièrement corrigé, où il annule par downgrade le correctif DSE avant d’exploiter le composant concerné
Des voies de contournement ouvertes lorsque les paramètres VBS sont faibles
- Leviev traite aussi des moyens de désactiver ou de contourner Virtualization-based Security(VBS) de Microsoft
- VBS crée un environnement isolé pour protéger les ressources essentielles et les actifs de sécurité de Windows
- Les éléments protégés incluent skci.dll, le mécanisme d’intégrité du code du noyau sécurisé, ainsi que les identifiants d’utilisateurs authentifiés
- VBS s’appuie généralement sur des protections comme le verrouillage UEFI et la configuration du registre
- Si VBS n’est pas configuré avec le niveau de sécurité maximal, le drapeau “Mandatory”, il peut être désactivé en modifiant des clés de registre ciblées
- Lorsque VBS n’est activé que partiellement, il est possible de perturber son fonctionnement en remplaçant des fichiers VBS essentiels comme SecureKernel.exe par des versions corrompues
- Cet état peut ouvrir une voie menant au contournement “ItsNotASecurityBoundary” et au remplacement de ci.dll
Réponse de Microsoft et zones d’ombre restantes
- CVE-2024-21302 et CVE-2024-38202, utilisées dans les attaques par downgrade présentées à BlackHat et DEFCON, ont été traitées, mais le problème de prise de contrôle de Windows Update demeure
- Microsoft a considéré que ce problème ne franchissait pas une frontière de sécurité définie, et que l’obtention de l’exécution de code noyau avec des droits administrateur ne constituait pas une violation d’une frontière de sécurité
- Leviev souligne que, tant que Microsoft n’aura pas corrigé le problème, les solutions de sécurité doivent surveiller et détecter les attaques par downgrade
- Microsoft indique développer activement des mesures d’atténuation pour contrer ce risque
- L’entreprise prépare une mise à jour de sécurité qui retirera les anciens fichiers système VBS non corrigés
- Ce processus inclut l’analyse de toutes les versions affectées, le développement de la mise à jour et les tests de compatibilité
- Pour protéger les clients et minimiser les interruptions d’exploitation, il faut éviter les échecs d’intégration ou les régressions
- En raison de la complexité du problème, le calendrier de disponibilité de la mise à jour reste incertain
- Une mise à jour du 27 octobre a clarifié que l’attaque nécessite des droits administrateur, et a ajouté des informations pour réduire la confusion autour de l’idée que Microsoft ne prendrait pas de mesures d’atténuation
1 commentaires
Avis sur Hacker News
MS affirme que l’UAC n’est pas une frontière de sécurité, ce qui concerne le problème de certains utilisateurs qui obtiennent des privilèges administrateur.
Mais, comme dans ce cas, elle dit aussi que le passage d’administrateur au noyau n’est pas une frontière de sécurité, tout en affirmant en même temps que l’application obligatoire de la signature des pilotes est une fonctionnalité de sécurité.
Ici, c’est précisément cette fonctionnalité qui est contournée, et pourtant on nous dit qu’aucune frontière de sécurité n’a été franchie ; j’aimerais qu’ils expliquent cela de façon cohérente.
L’UAC est destiné aux utilisateurs qui font déjà partie du groupe Administrators, pas à « faire de certains utilisateurs des administrateurs ».
La frontière de sécurité se situe autour de l’utilisateur standard, pas autour de l’utilisateur administrateur.
Cela peut ne pas vous plaire, mais si vous voulez une frontière de sécurité, il suffit de ne pas mettre l’utilisateur dans le groupe Administrators.
Dans les désaccords, on trouve généralement des divergences de définition et des divergences de système de valeurs.
Dans ce cas, Microsoft accorde de la valeur au fait de minimiser ce problème, et si c’est sa priorité absolue, sa décision peut paraître cohérente selon ce critère.
Les divergences de définition sont relativement faciles à résoudre. Par exemple, dans la conception de systèmes logiciels, tout le monde peut parler en termes de design patterns, mais si chacun comprend A comme A′ ou A″, cela peut créer une grande confusion.
C’est pareil pour les logiciels open source gérés par des entreprises.
La vraie question est de savoir pourquoi des gens dépensent leur énergie intellectuelle à faire de la recherche en sécurité gratuite pour Microsoft au lieu d’améliorer Linux sur desktop.
L’UAC et sudo ressemblent tous deux à des fenêtres de consentement aux cookies au niveau de l’OS, et je pense qu’il vaudrait mieux se débarrasser des trois.
Il faut abandonner les mécanismes d’élévation de privilèges basés sur l’utilisateur comme UAC/sudo, et mettre les apps en sandbox, comme Android et iOS, plutôt que les utilisateurs.
Il est aussi intéressant de noter que, sous Windows comme sous Linux, un compte local aux privilèges ordinaires se comporte en réalité presque comme un compte aux droits équivalents à root.
Sous Linux, on entraîne les utilisateurs à mettre sudo devant les opérations liées au système ; sous Windows, on les entraîne à cliquer pour passer les invites UAC.
Je me demande quand sudo a dit « non » à quelqu’un pour la dernière fois pour une raison autre qu’une faute de frappe dans le mot de passe.
L’UAC est légèrement meilleur en ce sens que son UI est gérée par le système, tandis que sudo n’est qu’un programme : un attaquant peut remplacer sudo par un alias shell malveillant pour voler le mot de passe.
Dans la configuration par défaut, il serait plus confortable pour l’utilisateur, et plus conforme à l’état réel de la sécurité, de supprimer sudo et l’UAC, et d’arrêter de faire comme s’il existait une frontière de sécurité solide entre root et le compte local de l’utilisateur principal.
Même dans le terminal, on peut utiliser pkexec au lieu de sudo.
Au lieu d’exécuter des commandes arbitraires en root, une application peut utiliser des actions prédéfinies comme
org.freedesktop.udisks2.filesystem-mount, et afficher à l’utilisateur un message localisé indiquant ce que l’app essaie de faire afin qu’il décide de l’autoriser ou non.L’administrateur système peut aussi configurer certaines actions, comme les mises à jour flatpak, pour ne pas exiger d’authentification, ou au contraire bloquer complètement certaines actions.
Il semble y avoir comme principe que l’utilisateur qui a effectué l’installation doit contrôler le système. Après tout, il aurait aussi pu ne pas l’installer.
sudo, comme l’UAC, n’est pas un mécanisme destiné à dire « non » à une personne. Les deux sont conçus pour permettre à une personne de dire « non » lorsqu’une tâche d’administration inattendue est sur le point d’être effectuée.
Une personne qui n’a pas de droits administrateur mais qui a besoin d’effectuer ce type d’opération doit obtenir l’approbation de l’administrateur.
Si ce n’est pas une machine mono-utilisateur, la personne qui configure la machine doit créer un compte limité pour l’usage quotidien.
Je n’ai pas souvent besoin de devenir root, et quand c’est nécessaire, c’est généralement pour enchaîner plusieurs opérations.
Je pense que sudo est utile sur les ordinateurs multi-utilisateurs, comme les machines détenues et administrées par une entreprise, lorsque l’administrateur veut autoriser certains utilisateurs à effectuer uniquement des tâches privilégiées limitées.
La principale raison d’utiliser en permanence un compte autre que root est d’éviter les erreurs plus que pour la sécurité : ne pas supprimer ou écraser des fichiers involontairement.
Donc devoir saisir un mot de passe pour changer ponctuellement de rôle me semble tout à fait justifié.
Il n’y a simplement pas l’astuce « appuyez sur ctrl+alt+delete pour confirmer ».
Windows a l’avantage de ne pas exiger que tout soit scripté.
Si on le souhaite, on peut envelopper tous les outils avec
runas/System.Management.Automation.PSCredential, mais dans la plupart des cas ce n’est pas nécessaire.Il semble que le noyau applique les règles de partage de fichiers en parcourant tous les handles de fichiers ouverts lors de l’ouverture d’un fichier pour vérifier les verrous obligatoires conflictuels, mais qu’il ne vérifie pas les mappings mémoire disposant de droits conflictuels.
C’est bien une erreur, mais la correction paraît relativement simple.
Fait intéressant, Linux vient de supprimer les derniers vestiges du verrouillage obligatoire. Désormais, écrire dans un exécutable chargé ne renvoie plus EBUSY.
Il est intéressant de voir qu’une même fonctionnalité peut être, dans un système d’exploitation, une pièce qui supporte le poids de l’infrastructure de sécurité, et dans un autre, un vieux reliquat legacy à supprimer.
Je ne suis pas spécialiste de la sécurité et je ne comprends que les bases, mais j’ai l’impression qu’il me manque un modèle conceptuel
Je me demande pourquoi Windows est si facile à pirater
Windows est une cible rentable, en particulier parce que c’est le système d’exploitation de bureau le plus largement déployé dans les environnements d’entreprise, donc beaucoup de temps et d’investissements sont consacrés à le compromettre
Les investissements nécessaires pour construire une plateforme informatique réellement sûre n’ont pas été suffisants
Une plateforme de sécurité idéale devrait fournir des builds reproductibles depuis une infrastructure vérifiable publiquement, comme fdroid, virtualiser toutes les applications non fiables dans un bac à sable et mettre en œuvre un modèle de moindre privilège
Aujourd’hui, on est dans le pire état possible en matière de sécurité. À tous les niveaux, du ME du CPU aux composants UEFI, en passant par les pilotes tiers de l’OS, du code opaque, probablement insuffisamment testé et non sûr s’exécute dans tous les anneaux
SeL4 dispose d’un noyau entièrement vérifié, mais ne fait pas encore de virtualisation
Une bonne partie des malwares Windows s’appuie, à un moment ou à un autre, sur un pilote noyau tiers vulnérable
À l’inverse, sous Linux, les modules noyau tiers sont rares et mal vus, et sous macOS ils sont carrément interdits
Et il est trop facile de convaincre l’utilisateur d’exécuter n’importe quoi avec des privilèges élevés
Le sujet n’a été traité qu’en 2022, après que l’analyste du CERT Will Dormann a demandé pourquoi
Il est désormais mis à jour régulièrement, mais c’est vraiment aberrant https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
Sur ce point, je suis plutôt d’accord avec la position de Microsoft
Un administrateur peut faire arbitrairement ce qu’il veut sur un ordinateur, ce n’est pas nouveau
Je ne sais pas s’il existe une nuance qui augmenterait la gravité
L’article de Raymond Chen qui résume ce type d’attaque vaut aussi le détour
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Si quelqu’un peut déjà remplacer une DLL arbitraire du système, les prérequis nécessaires au fonctionnement de cet « exploit » sont déjà réunis, et à ce stade tout est déjà perdu
La capacité à contourner la signature des pilotes est probablement l’une des moindres préoccupations dans la liste
L’attaque paraît suspectement simple
Elle consiste à tromper le processus de mise à jour pour lui faire installer un ancien composant noyau présentant une vulnérabilité connue
Même sans être expert, on pourrait penser que Microsoft aurait déjà anticipé ce cas et disposerait d’une liste de blocage ou d’un mécanisme de révocation ; je me pose donc la question
La question clé est de savoir si la cause profonde est un problème de conception de l’OS, ou un échec de processus — une casse, ou l’incapacité à enregistrer les mauvais hash au bon endroit
Dans le second cas, ce serait beaucoup plus facile à corriger, mais, comme toujours, le bulletin de sécurité un peu emballé semble plutôt suggérer le premier
Il y a une démo, donc j’ai du mal à croire que Microsoft conteste
Ce compte Vimeo contient aussi beaucoup d’autres découvertes de sécurité. Par exemple, il y en avait une où WhatsApp exécutait un script Python ; je me demande si c’est réel ou une arnaque
Leur critère dit que « les processus et utilisateurs administrateurs sont considérés comme faisant partie de la base informatique de confiance (TCB) de Windows et ne sont donc pas fortement isolés de la frontière du noyau » [0]
Il existe aussi un autre exemple récent
https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Cela me rappelle toutes les galères que tout le monde a connues chez [1] lorsque Microsoft a commencé à exiger la signature des pilotes sous Windows
Nous développions un pilote d’inspection approfondie des paquets pour [2] et, au premier abord, la procédure paraissait encore plus exigeante que l’approbation d’une app sur l’Apple Store, avec une documentation pas du tout claire
Quand on pense aux ressources que les entreprises ont consacrées pour satisfaire aux exigences de Microsoft, voir cela exploité de cette manière donne l’impression d’un gros retour en arrière
Il y aura toujours des vulnérabilités, mais j’aurais été rassuré si quelqu’un l’avait trouvée plus tôt
Bravo à Alon Leviev et à SafeBreach pour la découverte
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
Dire que c’est « possible en obtenant l’exécution de code noyau en tant qu’administrateur », au fond, c’est simplement dire qu’un utilisateur root peut installer un rootkit
Il ne faut pas oublier de lui donner un nom qui claque. Ah, le chercheur a déjà publié un outil appelé Windows Downdate
Il a assuré ses 0xF minutes de célébrité, donc c’est plutôt réussi
Les comptes utilisateur ne sont eux aussi que des objets dans le système d’exploitation, et on peut concevoir un OS qui impose certaines règles à tous les comptes utilisateur, même en limitant le compte superutilisateur
Par exemple, il peut y avoir des raisons légitimes de protéger certains secrets, comme avec un TPM, même si le compte administrateur est compromis, ou d’empêcher un administrateur de rendre le système impossible à démarrer par erreur
Parmi les objectifs plus controversés, il y a aussi l’application forcée de DRM
C’est précisément ce que Microsoft essaie de faire dans Windows. Le système d’exploitation cherche à empêcher le compte administrateur d’interférer avec le noyau ou d’installer un rootkit
Dans cette discussion, il est toujours important de distinguer le compte utilisateur administrateur à l’intérieur du système d’exploitation de la personne « administrateur » disposant d’un accès physique et matériel
0xFCe n’est pas une erreur, mais c’est un choix un peu étrange qui pique ma curiosité. Je me demande si c’était juste une question de style
Quand je dois utiliser Windows, je pars toujours du principe que cette machine est déjà compromise