Un chercheur en sécurité a mis en ligne le code d’exploitation de BlueHammer, une faille d’élévation de privilèges locale signalée à Microsoft mais toujours non corrigée. Le PoC n’est pas parfaitement stable, mais plusieurs spécialistes ont confirmé qu’il fonctionnait.
L’affaire a pris une tournure très embarrassante en quelques jours. Début avril, la découverte d’une vulnérabilité Windows a quitté le circuit habituel des signalements privés pour se retrouver sur GitHub, exploit à l’appui. À l’origine de cette publication, un chercheur opérant sous les pseudonymes Chaotic Eclipse et Nightmare-Eclipse, qui reproche à Microsoft la manière dont son dossier a été traité. D’après BleepingComputer, BlueHammer, de son petit nom, avait bien été remontée à l’éditeur avant cette mise en ligne, mais aucun correctif n’était encore disponible au moment où le code a été rendu public.
Un exploit imparfait, mais bien fonctionnel
BlueHammer appartient à une catégorie de failles particulièrement utiles dans une chaîne d’attaque. Il ne s’agit pas d’un bug permettant de pénétrer à distance sur une machine, mais d’une vulnérabilité capable de faire basculer une compromission déjà engagée vers un niveau de contrôle beaucoup plus élevé. Autrement dit, un attaquant qui dispose déjà d’un accès local peut s’en servir pour renforcer très nettement ses droits sur le système, jusqu’aux privilèges SYSTEM dans certains cas.
D’après Will Dormann, analyste chez Tharros cité par BleepingComputer, l’exploit combine un TOCTOU (un décalage exploitable entre une vérification et l’action qui suit) et une confusion de chemin d’accès (qui permet de tromper le système sur le fichier réellement visé). L’ensemble permettrait notamment d’accéder à la base SAM de Windows, qui contient les empreintes des mots de passe des comptes locaux, puis d’élever les privilèges jusqu’à ouvrir un shell SYSTEM, soit le niveau de contrôle le plus élevé sur la machine.
Le code publié sur GitHub n’est toutefois pas irréprochable. Son auteur a lui-même reconnu que le PoC contenait des bugs susceptibles d’en limiter la fiabilité, et plusieurs essais ont montré qu’il ne se comportait pas de manière identique selon les configurations, en particulier sur Windows Server. Il reste néanmoins exploitable dans certains scénarios, ce que plusieurs chercheurs ont confirmé.
Mais comment BlueHammer a-t-elle fini sur GitHub ?
BlueHammer avait d’abord été signalée à Microsoft en privé, comme c’est normalement le cas pour ce type de vulnérabilité. Quelques jours plus tard, son auteur publiait pourtant sur GitHub un exploit visant cette faille encore non patchée, accompagné de messages laissant peu de place au doute sur son état d’esprit. Le ton est sec, amer, parfois sarcastique, et vise directement le Microsoft Security Response Center, que le chercheur tient visiblement pour responsable de la tournure prise par l’affaire.
La chronologie exacte des discussions n’est pas connue, pas plus que le point de désaccord qui a fait basculer le dossier. On sait en revanche que le MSRC demande notamment une vidéo de démonstration lors d’un signalement. Pour Microsoft, ce type d’élément permet de vérifier un bug, de le reproduire et d’en mesurer plus rapidement la portée. Pour un chercheur, la demande peut aussi donner le sentiment qu’il faut encore démontrer longuement un problème déjà trouvé, déjà documenté, et ici déjà exploité.
Bref, entre le signalement privé et la publication publique, il suffit parfois que les échanges se bloquent pour que tout le cadre de la divulgation coordonnée vole en éclats. C’est manifestement ce qui s’est produit ici.
Une LPE permet à un attaquant déjà présent sur une machine (compte standard, service compromis, accès RDP, etc.) d’obtenir des droits plus élevés. Elle ne sert généralement pas à “entrer” depuis Internet, mais à transformer un accès limité en contrôle quasi total du système. Sous Windows, l’objectif est souvent d’atteindre des privilèges administrateur ou, mieux, le compte SYSTEM. Dans une chaîne d’attaque, ce type de faille facilite la persistance, le désarmement des protections et l’accès à des données sensibles. C’est pour cela qu’une LPE non corrigée peut être très recherchée, même sans vecteur d’intrusion à distance.
Que signifie TOCTOU et pourquoi ce bug est-il exploitable ?TOCTOU (“Time Of Check To Time Of Use”) décrit une course entre le moment où un programme vérifie une condition et celui où il effectue l’action correspondante. Si un attaquant parvient à modifier l’état du système entre ces deux étapes (fichier remplacé, lien modifié, chemin réorienté), l’action peut s’exécuter sur une cible différente de celle vérifiée. Dans le monde Windows, cela peut permettre de faire écrire ou lire un composant privilégié sur un objet contrôlé par l’attaquant. L’exploitation repose souvent sur la synchronisation (timing) et peut donc être instable selon la charge machine et la configuration.
À quoi correspondent la base SAM et un “shell SYSTEM” sur Windows ?La SAM (Security Account Manager) est une base locale qui stocke notamment des informations d’authentification des comptes Windows locaux, dont des empreintes (hash) de mots de passe. Obtenir un accès non autorisé à la SAM peut permettre de récupérer ces hash et, dans certains cas, de les réutiliser pour s’authentifier ou déplacer la compromission. Un “shell SYSTEM” signifie une ligne de commande ou un processus lancé avec les privilèges du compte SYSTEM, plus élevé qu’un administrateur classique. Avec ce niveau, un attaquant peut généralement lire/écrire presque partout, manipuler les services, et contourner de nombreuses restrictions. C’est un jalon critique, car il ouvre la voie au contrôle complet de la machine.
