Introduction
Bring Your Own Vulnerable Driver (BYOVD) est une technique d'attaque de plus en plus populaire dans laquelle un acteur de la menace apporte un pilote signé vulnérable connu avec son logiciel malveillant, le charge dans le noyau, puis l'exploite pour effectuer une action dans le noyau qu'il n'aurait pas été en mesure de faire autrement. Après avoir obtenu l'accès au noyau, ils peuvent altérer ou désactiver les logiciels de sécurité, extraire des informations d'identification autrement inaccessibles ou modifier le comportement du système d'exploitation pour dissimuler leur présence. Joe Desimone et moi-même avons couvert cette question en profondeur, parmi d'autres menaces en mode noyau, lors de Black Hat USA 2018. Employé par des acteurs de menaces avancées depuis plus de dix ans, le BYOVD devient de plus en plus courant dans les ransomwares et les logiciels malveillants de base.
Driver Signing Enforcement (DSE), déployé pour la première fois sur 2007 par Windows Vista x64, a été la première tentative de Microsoft de limiter le pouvoir des administrateurs. Avec la mise en place du DSE, les administrateurs ne pouvaient plus charger instantanément n'importe quel code dans le noyau. Les restrictions administratives se sont développées au fil du temps avec le déploiement de Boot Guard, Secure Boot et Trusted Boot pour protéger la chaîne de démarrage contre les logiciels malveillants des administrateurs, qui pouvaient auparavant installer leurs propres chargeurs d'amorçage / kits d'amorçage.
Pour limiter encore le pouvoir des administrateurs, Microsoft a récemment déployé la liste de blocage des pilotes vulnérables par défaut, à partir de Windows 11 22H2. Il s'agit d'un pas dans la bonne direction, qui rend Windows 11 plus sûr par défaut. Malheureusement, le modèle de déploiement de la liste de blocage peut être lent à s'adapter aux nouvelles menaces, les mises à jour n'étant déployées automatiquement qu'une ou deux fois par an. Les utilisateurs peuvent mettre à jour manuellement leurs listes de blocage, mais de telles interventions nous éloignent du territoire "sécurisé par défaut".
Limites de sécurité
Pour déterminer les vulnérabilités à corriger, le Microsoft Security Response Center(MSRC) utilise le concept de périmètre de sécurité, qu'il définit comme suit :
Une frontière de sécurité fournit une séparation logique entre le code et les données des domaines de sécurité avec différents niveaux de confiance. Par exemple, la séparation entre le mode noyau et le mode utilisateur est une frontière de sécurité classique et directe.
Sur la base de cette définition, on pourrait être enclin à penser que les logiciels malveillants fonctionnant en mode utilisateur ne devraient pas être en mesure de modifier la mémoire du noyau. La frontière est "simple" après tout. Logiquement, toute violation de cette limite devrait faire l'objet d'une action corrective telle qu'un correctif ou une mise à jour de la liste de blocage.
Malheureusement, la situation se complique à partir de là. Ce document précise ensuite que la relation entre l'administrateur et le noyau n'est pas une limite de sécurité, avec l'explication suivante :
Les processus administratifs et les utilisateurs sont considérés comme faisant partie de la Trusted Computing Base (TCB) pour Windows et ne sont donc pas fortement [sic] isolés de la limite du noyau.
À ce stade, nous avons deux points de vue apparemment contradictoires. D'une part, le CSEM affirme que la relation entre l'administrateur et le noyau est une limite indéfendable qui ne vaut pas la peine d'être corrigée. D'autre part, Microsoft tente de défendre cette frontière avec des mécanismes tels que Driver Signing Enforcement, Secure Boot et Vulnerable Driver Blocklist. La défense étant incomplète, le CSEM parle plutôt de "dispositifs de sécurité en profondeur".
De même, le CSEM ne considère pas l'admin-to-PPL comme une limite de sécurité, mais comme un dispositif de défense en profondeur. Vous trouverez plus d'informations à ce sujet dans la section suivante.
Dans la suite de cet article, nous ferons référence au CSEM et à Microsoft séparément. Bien que le CSEM fasse partie de Microsoft, Microsoft est une entité beaucoup plus importante que le CSEM ; ils ne devraient pas être mis sur le même plan.
Exploiter les vulnérabilités
En septembre 2022, j'ai déposé le dossier VULN-074311 auprès du CSEM, l'informant de deux vulnérabilités de type "zero-day" dans Windows : une vulnérabilité admin-to-PPL et une vulnérabilité PPL-to-kernel. J'ai fourni le code source des deux exploits. La réponse indiquait de manière concise qu'elle comprenait les vulnérabilités et qu'elle refusait de prendre d'autres mesures, comme indiqué ci-dessous :
La recherche décrit une attaque en plusieurs étapes qui exploite un contournement de PPL pour obtenir l'exécution du code du noyau. Notez que toutes les attaques proposées requièrent des privilèges administratifs et que le problème signalé ne répond donc pas à nos critères d'intervention immédiate. Nous n'attendons pas d'autre action et nous allons procéder à la clôture de l'affaire.
Dans ce langage, "entretien" signifie "réparation". Leur réponse est cohérente avec la politique susmentionnée et leur traitement historique de la frontière entre l'administrateur et le noyau. Leur comportement est également cohérent - cela fait plus de 11 mois qu'ils n'ont toujours pas corrigé l'une ou l'autre des vulnérabilités. Je trouve fascinant que Microsoft soit prêt à bloquer les pilotes qui peuvent modifier la mémoire du noyau, mais que le CSEM ne soit pas disposé à gérer les vulnérabilités qui peuvent faire la même chose.
Lorsque j'ai annoncé mon intervention à Black Hat Asia 2023 , PPLdump Is Dead. Vive PPLdump, sur Twitter cinq mois après le rapport du CSEM, l'équipe de Windows Defender m'a rapidement contacté pour en savoir plus. Il semble que le CSEM ait classé l'affaire sans informer l'équipe Defender, dont les produits s'appuient sur PPL pour protéger des centaines de millions de machines Windows, de l'existence d'un contournement de PPL. Ce type d'erreur de communication ne doit pas perdurer.
Outillage clé en main
EDRSandBlast est un outil qui utilise des pilotes vulnérables pour contourner les logiciels AV & EDR. Il peut modifier la mémoire du noyau pour supprimer les crochets installés par AV & EDR, les rendant temporairement ou définitivement aveugles aux activités malveillantes sur le système.
Comme je l'ai expliqué dans mon exposé à Black Hat Asia, le CSEM a de facto montré qu'il n'était pas disposé à s'occuper des vulnérabilités admin-to-PPL et admin-to-kernel et qu'il fallait l'existence d'un outil clé en main sur GitHub pour motiver Microsoft à agir. Cela m'a conduit à publier sur GitHub l'exploit PPLFault pour les administrateurs et la chaîne d'exploitation GodFault pour les administrateurs et le noyau, sous forme d'outils faciles à utiliser. Par souci de concision, nous les appellerons respectivement "vulnérabilité PPL" et "vulnérabilité du noyau".
Dans ce même esprit d'"outil clé en main", pour souligner l'incohérence du blocage des pilotes vulnérables connus tout en refusant de patcher les chaînes d'exploitation de l'administrateur au noyau, je publie une version d'EDRSandBlast qui intègre PPLFault pour démontrer le même résultat, sans les pilotes vulnérables. Vous pouvez le voir ici en désactivant le pilote Windows Defender. Mon objectif en publiant ce document est de motiver le CSEM à traiter les vulnérabilités de PPL et du noyau avec plus d'urgence.
Atténuation
J'ai publié un petit pilote de noyau avec PPLFault et GodFault appelé NoFault qui casse l'exploit PPL. Jusqu'à ce que Windows soit corrigé, les éditeurs de logiciels anti-malveillants peuvent utiliser ce code pour atténuer la vulnérabilité PPL. Nous avons intégré la protection de NoFault dans la dernière version d'Elastic Endpoint/Defend - veuillez mettre à jour vers la version 8.9.0+ si vous ne l'avez pas encore fait. Une solution globale pourrait consister à faire en sorte que le gestionnaire de mémoire impose des hachages de page pour toutes les images exécutables chargées dans PPL, une fonction déjà utilisée pour les processus protégés complets.
GodFault n'est pas le premier outil à exploiter la vulnérabilité du noyau. ANGRYORCHARD l'a utilisé pour la première fois avec la vulnérabilité PPL de KnownDLLs, désormais corrigée. La vulnérabilité de PPL a depuis été corrigée, mais celle du noyau ne l'a pas été. J'ai pu facilement réutiliser la vulnérabilité du noyau dans GodFault - il ne s'agit que de quelques lignes de code. Si ce problème n'est pas corrigé, tous les futurs exploits PPL seront immédiatement chaînables au noyau. Notez que NoFault rompt la chaîne d'exploitation du noyau en empêchant l'exécution du code PPL nécessaire, mais ne corrige pas la vulnérabilité du noyau lui-même.
Discussion
Rendre EDRS etBlast sans conducteur n'est qu'un exemple de ce qu'il est possible de faire avec de tels exploits. Les exploits de type "Admin-to-kernel" permettent d'utiliser toute une série de fonctionnalités malveillantes qui sont normalement impossibles à utiliser en mode utilisateur :
- Désactivez la télémétrie en mode noyau, y compris les rappels de processus, de threads, de gestionnaires d'objets, de systèmes de fichiers et de registres. EDRSandBlast réalise certaines de ces activités.
- Désactiver les enregistreurs ETW du noyau
- Terminer et/ou injecter des logiciels malveillants dans les processus de lutte contre les logiciels malveillants de la PPL.
- Contournement du LSA RunAsPPL pour vider les informations d'identification ou falsifier le Credential Guard.
- Lire/écrire la mémoire des processus de travail blindés de la VM, qui s'exécutent en tant que PPL.
- Exécutez un logiciel malveillant avec des privilèges supérieurs à ceux de l'anti-malware, de sorte qu'il ne puisse pas être analysé ou arrêté en mode utilisateur.
- Mettre en œuvre le comportement d'un rootkit tel que le masquage de processus, de fichiers et de clés de registre.
- Obtenir un accès complet à la mémoire physique en lecture et en écriture
Les criminels utilisent régulièrement ces capacités du noyau, souvent rendues possibles par le BYOVD, pour déjouer et dégrader les produits de sécurité, ce qui leur permet de nuire aux personnes et aux entreprises. Les vulnérabilités de la PPL et du noyau permettent ces mêmes capacités, et le CSEM doit donc les réparer de manière proactive avant que les acteurs de la menace n'en abusent, et non après.
Je ne veux pas sous-estimer la difficulté du problème - défendre le noyau contre les administrateurs est difficile et nécessitera des efforts continus au fur et à mesure que de nouveaux contournements seront découverts. Le problème ne sera pas résolu, mais il s'agira plutôt d'une course aux armements difficile et permanente. Heureusement, Microsoft a récemment adopté une nouvelle philosophie consistant à "ne plus éviter les choses difficiles" (lien horodaté). S'attaquer à ces types de vulnérabilités est une "chose difficile" qui affecte la sécurité de Windows aujourd'hui et sur laquelle Microsoft peut agir tout en progressant vers sa vision d'un avenir sans administrateur. Il s'agit d'une grande entreprise bien financée, composée de personnes intelligentes, capables de traiter plusieurs problèmes à la fois.
Conclusion
Microsoft a créé la liste noire des pilotes vulnérables pour empêcher les administrateurs de manipuler le noyau, mais n'a rien fait au sujet d'une chaîne d'exploitation entre administrateurs et noyau qui a été signalée sur 11 il y a plusieurs mois. En supprimant l'exigence d'un pilote vulnérable dans EDRS etBlast via GodFault, j'espère prouver que les exploits de l'administrateur vers le noyau peuvent être tout aussi dangereux que les pilotes vulnérables et que le CSEM doit les prendre au sérieux. Compte tenu de l'objectif de sécurité par défaut de Windows 11 et du fait que la liste de blocage des pilotes vulnérables est désormais activée par défaut, le CSEM doit reconsidérer sa politique d'indifférence à l'égard des exploits PPL et du noyau.