BlueHammer les fenêtres Zero Day qui vous permet de grimper des privilèges sans patch et de menacer les réseaux d'entreprise

Ces derniers jours, une émeute est apparue dans la communauté de sécurité lorsque le code d'exploitation public pour un privilège grimpant vulnérabilité sur Windows est apparu qui, jusqu'à présent, n'a pas de patch officiel. Cet échec, connu dans les milieux techniques tels que BlueHammer, a été rapporté en privé à Microsoft, mais l'auteur a décidé de le rendre public après avoir exprimé sa frustration avec le processus de gestion de la divulgation par le centre de réponse Microsoft.

La situation est compliquée parce que Microsoft n'a pas encore publié de correction et, selon la propre définition de l'entreprise, cette vulnérabilité tombe dans la catégorie zéro jour.. Vous pouvez voir la définition officielle dans la documentation de Microsoft sur les vulnérabilités de zéro jour: Microsoft : vulnérabilités de zéro jour. Dans le même temps, la personne qui a rendu l'enquête publique a publié un billet de blog expliquant, à sa façon, son désenchantement avec le chemin suivi pour signaler le problème: entrée de l'enquêteur.

Techniquement, les spécialistes qui ont examiné le matériel - y compris les analystes renommés dans la communauté - pointent vers BlueHammer combinant une condition de carrière du type temps de vérification au temps d'utilisation (TOCTOU) avec une confusion des itinéraires. En pratique, l'opération permet à un attaquant local d'accéder à la boutique de comptes Windows (SAM), où les hachages des mots de passe locaux sont conservés, et de là grimpent les privilèges pour obtenir des identifiants de haut niveau ou exécuter des commandes avec des privilèges SYSTEM.

Pour comprendre le scénario, il faut se rappeler que TECTOU est une famille de défaillances dans laquelle le système valide une condition et, entre vérification et utilisation, un acteur externe manipule l'état pour modifier le résultat. Il y a des ressources qui expliquent clairement le concept, par exemple l'entrée dans l'OWASP sur ce type d'attaque: TECTOU - OWASP. Et si vous voulez revoir ce qu'est le SAM et pourquoi il est si sensible, cette référence générale est utile: Gestionnaire de comptes de sécurité - Wikipedia.

Il est important de ne pas faire deux choses : d'abord, l'explosion publiée n'est pas banale à courir. Des analystes comme Will Dormann ont confirmé que la technique fonctionne dans des conditions spécifiques, mais qu'elle n'est pas nécessairement fiable dans toutes les éditions Windows; son analyse technique peut être consultée dans la publication publique où elle commente ses tests: commentaire de Will Dormann. Deuxièmement, le code publié par le chercheur contient des erreurs qui rendent difficile l'exécution dans certains environnements, et certaines tentatives de test n'ont pas réussi sur les serveurs Windows, suggérant que l'opération peut dépendre de paramètres et de versions spécifiques.

Bien que cette vulnérabilité nécessite un accès local pour l'activer, elle ne la rend pas inoffensive. Un attaquant peut obtenir un accès local par de multiples moyens : phishing qui conduit à l'exécution de code malveillant, exploitation d'autres vulnérabilités pour obtenir une cale à feu, ou vol d'identités. Alors, une escalade locale qui se termine par des privilèges SYSTEM peut rapidement entraîner des engagements de machines et des mouvements latéraux sur les réseaux d'entreprises.

La personne responsable de la divulgation a expliqué dans ses communications que la publication était motivée par son mécontentement à l'égard du traitement du rapport. Il a également souligné que le code de test présente des échecs, un point qu'ils acceptent de signaler à d'autres chercheurs. Microsoft, pour sa part, n'avait pas émis de commentaire public à la fin de l'actualité, ni distribué de patch; dans ces cas, l'entreprise émet habituellement un avis et publie des corrections par son canal de sécurité et des patchs mensuels, le cas échéant. Plus d'informations sur la réponse de Microsoft et son canal de communication sont disponibles sur le site de MSRC: Centre de réponse de sécurité de Microsoft.

Que peuvent faire les organisations et les utilisateurs tant qu'il n'y a pas de patch officiel? Il n'y a pas de solutions parfaites, mais il existe des mesures de réduction des risques qui aident à limiter l'exposition. Maintenir les systèmes et les applications à jour, minimiser le nombre de comptes avec des privilèges locaux, appliquer les principes de privilège minimum, et utiliser des solutions de détection et de réponse des paramètres (EDR) qui peuvent identifier des comportements anormaux liés à l'accès aux MAS ou aux tentatives de levage sont des étapes prudentes. Il convient également de vérifier et de renforcer les comptes locaux et de surveiller les activités des services et des processus qui tentent de modifier des domaines critiques du système.

La divulgation publique d'exploitations non par lots génère toujours un dilemme : d'une part, elle pousse le fabricant à agir rapidement ; d'autre part, elle accélère la possibilité d'adapter et de masser la technique aux acteurs malveillants.. C'est pourquoi une communication responsable entre chercheurs et fournisseurs de logiciels est essentielle, bien que la tension entre transparence et sécurité mène parfois à des scènes comme celle que nous voyons avec BlueHammer.

Si vous êtes administrateur, prioriser l'évaluation des systèmes qui ne sont pas protégés par le contrôle des comptes et examiner la télémétrie de sécurité pour détecter l'accès étranger aux bases de données d'identification locales. Si vous êtes un utilisateur domestique ou professionnel sans rôle de gestion, évitez d'exécuter des logiciels téléchargés à partir de sources peu fiables, et gardez la sauvegarde hors ligne. Dans tous les cas, être au courant des avis officiels de Microsoft et de son fournisseur de sécurité: quand une correction est publiée, l'appliquer le plus rapidement possible.

Pour suivre la couverture et les parties techniques liées à cet événement, vous pouvez consulter les moyens de référence en cybersécurité et technologie, ainsi que les canaux Microsoft officiels et les analyses de chercheurs reconnus. Parmi les sources utiles pour élargir l'information figurent le site Web Microsoft mentionné ci-dessus, l'entrée du chercheur qui a rendu l'opération publique ( blog de l'auteur), le commentaire d'un analyste qui a testé l'explosion ( publié par Will Dormann) et les portails spécialisés qui ont suivi l'affaire, tels que Calculateur.

La recommandation finale est claire : faire confiance à la prudence opérationnelle pendant qu'un patch officiel arrive. Ces types de vulnérabilités se souviennent qu'en plus des patchs, la défense en profondeur et l'hygiène numérique restent nos meilleurs outils pour empêcher un échec isolé de devenir un écart majeur.