Connexion
Je ne sais pas si vous êtes familier avec NetScaler de Citrix, mais c'est un équipement qui sert de passerelle d'accès à distance pour les salariés des entreprises, et qui peut aussi gérer l'authentification SAML.
Et ces derniers temps, l'équipement est un peu mis à mal. À cause notamment de deux failles 0day sorties fin septembre (surnommées PitScaler par le chercheur Kevin Beaumont), qui ont heureusement été patchées. Mais ces derniers jours, des admins ont vu quand même redémarrer en boucle leur NetScaler pourtant à jour dont des 14.1-73.37, la version censée corriger le problème...
Bizarre, bizarre, vous avez dit bizarre ?
Eh oui c'est bizarre ! Encore une vuln !! C'est la seconde vague en moins d'une semaine et c'est le bulletin de sécurité de Citrix qui le dit avec la CVE-2026-88779, qui est, cerise sur le gâteau, activement exploitée dans des attaques au moment où j'écris ces lignes.
Donc voilà, c'est le gros bordel du côté des entreprises clientes de Citrix !! D'après SecurityWeek, avant l'arrivée des correctifs, les files d'attente du support technique de Citrix duraient des heures... Et les contournements provisoires n'empêchaient pas systématiquement les plantages et autres redémarrages à répétition.
De quoi déprimer sévère... Certains clients de Citrix ont même dû débrancher leur matériel durant la première vague de failles. Et aujourd'hui, même ceux qui ont installé le correctif de PitScaler n'y échappent pas non plus s'ils utilisent SAML, puisque Citrix a sorti un nouveau correctif et leur demande de mettre à jour une seconde fois en très peu de temps.
Alors que se passe-t-il exactement ? Est-ce que c'est un simple déni de service ?
Eh bien en tout cas, c'est ce que dit Citrix.
Ce qu'ils expliquent, c'est que le service peut rester indisponible tant que l'attaque se répète et que pour le moment, ils n'ont pas identifié d'impact sur l'intégrité des données. Sauf que le chercheur en cybersécurité Kevin Beaumont a vu l'un de ses honeypots (qui était pourtant patché) faire tourner un binaire malveillant récupéré depuis le web.
Un autre admin a aussi trouvé dans ses logs des noms d'utilisateurs contenant des commandes shell, censées télécharger un fichier puis l'exécuter. Toutefois, ses logs ne prouvent pas que ces commandes ont réellement tourné.
Donc voilà, on est un peu tous dans le flou...
En juin, Citrix communiquait sur la CVE-2026-8452, consistant en un autre débordement mémoire côté SAML, et pouvant provoquer un "comportement imprévisible" ou un déni de service. Et selon la note de la Cloud Security Alliance , watchTowr a démontré en août que cette faille autorisait en réalité une exécution de code root sans authentification.
Donc même si rien n'indique que ce soit le même bug ici (le plantage d'aujourd'hui, c'est le processus nsaaad qui se vautre en boucle), ce n'est pas la première fois que l'explication "c'est juste un déni de service" se fait démonter. Beaumont rappelle d'ailleurs que la CVE-2025-6543 avait suivi le même chemin...
Voilà... donc côté correctif, Citrix a sorti des mises à jour qui règlent la faille (je vous donne les versions plus bas) et en complément, il propose aussi des listes de blocage d'adresses IP malveillantes. La CISA a également ajouté la faille à son catalogue le 4 octobre, avec une échéance de correction exigée pour le 7 octobre pour les agences fédérales américaines. C'est la sixième faille NetScaler exploitée qu'elle y inscrit cette année, d'ailleurs...
Maintenant, voici comment savoir si vous êtes concerné.
En fait, la faille ne touche que les appliances configurées comme fournisseur de service (SP) ou comme fournisseur d'identité (IdP) SAML. Cherchez donc dans votre config une ligne add authentication samlAction ou add authentication samlIdPProfile.
Et si vous en avez une, il faudra installer au minimum la 14.1-73.41 ou la 13.1-64.28 selon votre branche (ou la 14.1-73.41 FIPS, ou la 13.1-37.282 pour les FIPS et NDcPP en 13.1) de NetScaler, comme l'indique le bulletin de Citrix .
Voilà, bon courage à tous.
Merci à Thomas pour l'info !
Source : SecurityWeek
ShieldBreak est un nouvel exploit qui vise l'antivirus livré avec Windows. Cela permet à un compte utilisateur limité de passer SYSTEM sur un Windows entièrement à jour, grâce notamment à Windows Defender qui lui sert de marchepied.
Le chercheur Nightmare Eclipse a sorti le code de son exploit en public y'a 2 jours, quelques heures après un Patch Tuesday qui corrigeait plus de 400 failles. Mais pas celle-ci évidemment... Une machine parfaitement à jour reste donc exposée.
Kevin Beaumont, ancien de chez Microsoft, a testé l'exploit et confirme qu'il fonctionne sur un Windows 11 à jour. Sa lecture technique, en revanche, diffère de celle du chercheur. Nightmare Eclipse présente ShieldBreak comme un contournement complet du correctif de RoguePlanet, sa faille précédente, alors que Beaumont souligne que les deux reposent sur des mécanismes très différents.
L'attaque réclame un accès local et l'exécution du programme, elle ne s'attrape pas en visitant une page web. Elle a été testée sur Windows 11 25H2 et Windows Server 2025, Windows 10 étant déclaré vulnérable sans être pris en charge par le code publié. Et il faut que Defender soit activé pour que ça marche.
Cette publication sans préavis n'arrive pas de nulle part. En mai, Microsoft a publié un billet qualifiant d'injustifiables les divulgations non coordonnées qui mettent du code d'exploitation entre les mains d'acteurs malveillants, en rappelant que sa Digital Crimes Unit continuerait à poursuivre ces acteurs. Le texte ne visait pas nommément les chercheurs. Le milieu de la sécurité l'a quand même reçu comme une menace.
Microsoft a fait ensuite machine arrière sur les réseaux sociaux, en assurant ne pas vouloir s'en prendre à ceux qui publient de la recherche. Le billet d'origine, lui, est toujours en ligne et les publications n'ont pas ralenti pour autant : une dizaine de zero-days Windows depuis avril, dont BlueHammer et GreatXML dont je vous ai déjà parlé.
Microsoft dit avoir connaissance de la vulnérabilité signalée et enquêter sur la validité des affirmations mais pour le moment, la faille n'a même pas d'identifiant CVE à elle, et reste rattachée au correctif qu'elle est censée contourner. Bref, si ça vous fait flipper comme faille, désolé, il n'y a rien à installer pour l'instant pour fixer le problème.
En attendant, Beaumont a mis en ligne des requêtes de "chasse" pour Defender for Endpoint qui repèrent quand un processus étranger à Defender charge ses bibliothèques, ou qu'un processus non validé charge celles de l'API Cloud Filter. Tout ça via le même processus.
Mais c'est de la détection, et pas un correctif...
BitLocker, je le rappelle c'est quand même le truc censé protéger vos données en cas de vol de votre bécane. Sauf que voilà, la théorie et Redmond, ça fait parfois deux... Le chercheur en sécurité Chaotic Eclipse (déjà à l'origine de BlueHammer ) vient de balancer une nouvelle vulnérabilité zero-day baptisée GreatXML , qui réduit cette promesse en miettes.
Le truc tourne autour de la façon dont Windows Recovery Environment (WinRE) traite les fichiers de configuration lors du démarrage. Plus précisément, la faille exploite des résidus laissés par l'outil d'analyse hors ligne de Microsoft Defender.
Cela signifie que si vous avez déjà lancé un scan Defender Offline, votre machine conserve des artefacts sur la partition de récupération. C'est là que le piège se referme car en manipulant des fichiers XML de configuration (notamment unattend.xml) sur la partition de récupération, un attaquant peut forcer le système à ouvrir un terminal avec les privilèges SYSTEM lors du passage en mode WinRE. Le tout sans avoir besoin de se connecter à la session, bien sûr...
Le résultat ?
Un accès complet et sans restriction au volume protégé par BitLocker. Pas besoin de fer à souder ou de bidouiller la carte mère avec un Raspberry Pi comme pour d'autres exploits TPM, là c'est une simple faiblesse logique logicielle qui permet de tout déverrouiller.
Alors oui, l'attaque nécessite un accès physique à la machine (ou un autre accès permettant de modifier la partition de récupération). Mais comme le rôle même de BitLocker est de protéger un appareil volé physiquement, c'est une sacrée épine dans le pied des administrateurs système ! D'autant plus qu'aucun correctif officiel n'a encore été publié par Microsoft.
Cette divulgation publique intervient dans un contexte tendu puisque Chaotic Eclipse multiplie les dumps de zero-days Windows suite à un différend avec le programme de bug bounty MSRC de Microsoft. On a déjà eu le droit à YellowKey et RoguePlanet ces dernières semaines et y'a peu de chances que ça s'arrête.
Bref, c'est la guerre ouverte !
Maintenant, même s'il n'y a pas encore de recommandations officielles de Microsoft pour cette faille spécifique, quelques mesures de bon sens permettent de limiter la casse. D'abord, configurer un mot de passe UEFI pour bloquer le boot externe. Ensuite, activer le mode TPM + PIN pour BitLocker car sans ce code pré-boot, la clé de déchiffrement n'est pas libérée, même si l'attaquant arrive à faire pop son shell.
Et si vous voulez couper court à toute exploitation de ce type, il reste l'option de désactiver complètement WinRE via la commande reagentc /disable.
Bref, en attendant que Microsoft sorte un patch, vous savez ce qu'il vous reste à faire.
Ce week-end, pendant qu'on se gavait d'oeufs de Pâques au Cadmium, un chercheur en sécu a balancé un zero-day Windows dans la nature... et tout ça d'après ce que j'ai compris, à cause de Microsoft qui l'a vraiment poussé à bout. L'exploit s'appelle BlueHammer et il permet à quiconque ayant un accès local sur une machine Windows 11 25H2 de passer SYSTEM. Et vous vous en doutez y'a toujours pas de patch.
Il s'agit d'une d'une escalade de privilèges locale (LPE) qui exploite une race condition de type TOCTOU (time-of-check to time-of-use), combinée avec une confusion de chemins dans le processus de mise à jour des signatures de Windows Defender. Je sais, il est trop tôt pour ces conneries mais disons que c'est le bug classique où un programme vérifie un truc, puis l'utilise, mais entre les deux quelqu'un a changé le truc en question.
En gros, l'exploit profite d'une fenêtre de temps entre le moment où Defender vérifie un fichier et celui où il l'utilise pour glisser un lien symbolique qui redirige vers la ruche SAM, le fichier C:\Windows\System32\config\SAM (là où Windows stocke les identifiants locaux). Et là, après ça devient open bar sur les hash de mots de passe de tous les comptes locaux.
Le chercheur derrière tout ça opère sous les pseudos Chaotic Eclipse et Nightmare-Eclipse et le 3 avril 2026, il a publié le code source complet sur GitHub , signé PGP, avec ce message assez salé : " I was not bluffing Microsoft, and I'm doing it again. "
Son reproche ? D'abord le MSRC (Microsoft Security Response Center) qui lui a demandé une vidéo de démonstration pour valider son rapport, et ensuite une réponse sur ce bug Windows Defender qui ne l'a visiblement pas satisfait : "I'm just really wondering what was the math behind their decision"
Will Dormann, analyste principal chez Tharros (ex-Analygence) et référence dans le milieu, a confirmé que l'exploit fonctionne, même s'il précise que l'exploitation n'est pas triviale. Une fois les privilèges obtenus, l'attaquant a les clés du royaume et peut lancer un shell avec les privilèges SYSTEM comme si c'était chez lui... Donc pas trivial, certes mais bien réel. D'ailleurs, c'est pas la première fois que Windows se fait éplucher par des chercheurs qui trouvent sans difficultés des failles d'escalade de privilèges en série.
Après, sous le capot, c'est quand même bien foutu. Un développeur (0xjustBen) a réimplémenté le PoC de manière modulaire et ça montre bien la mécanique : un module télécharge une vraie mise à jour Defender, un autre surveille les Volume Shadow Copies, un troisième enregistre un callback via l'API Cloud Files.
Et le cœur du truc joue la race condition avec un swap de lien symbolique pour lire la ruche SAM.
Notez quand même que le PoC original contient des bugs (le chercheur l'admet lui-même dans le README) et ne fonctionne pas sur Windows Server... ce qui ne veut pas dire que c'est inoffensif, attention. Et la réimplémentation de 0xjustBen, elle, n'a fonctionné que sur Windows 11 25H2, les versions 22H2, 23H2 et 24H2 n'étant pas affectées. Pas de CVE attribuée non plus pour l'instant, ce qui veut dire que Microsoft n'a même pas encore catalogué officiellement le problème.
Côté protection, c'est pas simple vu qu'il n'y a pas de correctif officiel mais comme l'attaque nécessite un accès local à la machine, ça limite pas mal les scénarios. Faut déjà être sur le poste Windows, que ce soit via un malware, du social engineering ou un accès physique. Après on sait bien qu'en entreprise, un poste partagé ou un stagiaire un peu curieux, c'est pas rare...
Premier réflexe donc : allez vérifier votre version de Windows (Paramètres > Système > À propos, ou winver dans Exécuter). Si vous n'êtes pas sur 25H2, vous n'êtes pas concerné. Sinon, vérifiez que vos comptes locaux ont des mots de passe costauds (pas "admin123"), désactivez les comptes inutilisés et gardez un œil sur les processus qui tournent avec des privilèges élevés. Côté entreprise, les solutions EDR devraient pouvoir détecter le comportement suspect (création de service temporaire, accès SAM inhabituel).
Bref, je pense que Microsoft finira bien par patcher... un jour.
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 