Découverte en 2007, une vulnérabilité dans le langage Python reste toujours sans correctif à ce jour. Aujourd'hui, on parle d'elle de nouveau, car elle affecte plus de 350 000 dépôts qui sont vulnérable à une exécution de code arbitraire.
La faille de sécurité associée à la référence CVE-2007-4559 a été découverte en 2007, et bien que ce soit surprenant, elle n'a jamais reçu de correctif ! La seule chose effectuée, c'est une mention dans la documentation pour avertir les développeurs d'un risque éventuel, car tout dépend des fonctions utilisées dans votre code Python. Ce message est un avertissement qui indique "qu'il peut être dangereux d'extraire des archives de sources non fiables".
Cette vulnérabilité se situe dans le package "tarfile" de Python, dont le but est de permettre la lecture et l'écriture d'archives au format TAR. Plus précisément, cette faille de type "directory transversal" est présente dans les fonctions tarfile.extract() et tarfile.extractall(). En l'exploitant, un attaquant peut écraser un fichier système présent sur votre machine. Sur le site officiel de Python, un exemple datant de 2007 est donné : "Si vous mettez dans une archive TAR un fichier nommé "../../../../../etc/passwd" et que l'administrateur décompresser l'archive, alors le fichier /etc/passwd est écrasé.". C'est un exemple, mais il y en a d'autres, notamment une variante qui s'appuie sur un lien symbolique.
Une vulnérabilité ignorée et redécouverte !
Plus tôt cette année, un chercheur de l'entreprise Trellix (issue de la fusion de McAfee Enterprise et de FireEye) a redécouvert la vulnérabilité CVE-2007-4559 alors qu'il enquêtait sur un autre problème de sécurité. Les chercheurs de Trellix ont approfondi leurs recherches vis-à-vis de cette vulnérabilité et il s'avère qu'elle est présente dans des milliers de projets logiciels, certains open source, d'autres non.
Ils ont analysé un échantillon de 257 dépôts Python : au final, 61% des dépôts analysés sont vulnérables à cette vulnérabilité. En utilisant ce taux de positivité, les chercheurs de Trellix estiment qu'il y a au moins 350 000 dépôts vulnérables, sur 588 840 dépôts GitHub qui intègrent du code Python avec la fonction "import tarfile" ! Une grande partie de ces dépôts correspondent à des outils de machine learning comme GitHub Copilot.
Trellix estime également que cette vulnérabilité affecte des entreprises dans de nombreux domaines : aussi bien la sécurité, le Web, la Data Science, etc...
Cette vulnérabilité est exploitable aussi bien sur Linux que sur Windows, comme le montre Kasimir Schulz, chercheur chez Trellix. Dans ce rapport technique, on peut voir deux vidéos de démonstration sur les deux systèmes d'exploitation.
Trellix a également sur 11 000 projets pour qu'ils ne soient plus vulnérables à cette faille de sécurité, en adaptant le code. Dans les semaines à venir, il y a des chances pour que de nombreux projets soient mis à jour afin de patcher : c'est en tout cas ce que l'on peut espérer. Reste à savoir s'il y aura une réaction de la Python Software Foundation, maintenant que cette vulnérabilité refait la une de l'actualité.
Quand un utilisateur d'un domaine Active Directory s'authentifie sur un ordinateur Windows (ou un serveur) membre du domaine, ses identifiants sont mis en cache en local, de manière automatique. On parle de Cached credentials. Ainsi, l'utilisateur peut se connecter à sa session, sur le même ordinateur, lorsque le contrôleur de domaine est injoignable, que l'ordinateur n'est pas connecté au réseau, ou lorsque l'ordinateur est connecté sur un réseau différent et qu'il ne peut pas contacter le contrôleur de domaine (télétravail, hôtel, train, etc.).
La mise en cache des identifiants s'avère très pratique pour les ordinateurs portables, car ils sont susceptibles d'être utilisés dans des conditions diverses et variées lors desquelles l'utilisateur aura besoin d'accéder à sa session et ses données.
Dans cet article, nous allons voir comment fonctionne la mise en cache des identifiants, comment elle se configure et quels sont les risques associés à cette fonctionnalité, autant d'un point de vue de la sécurité que de l'utilisation : la mise en cache à ses limites, comme nous le verrons, mais il existe des solutions.
II. Fonctionnement de la mise en cache des identifiants
Une entrée est ajoutée dans le cache des identifiants lorsqu'un utilisateur se connecte sur un ordinateur Windows ou un serveur Windows Server. C'est vraiment l'action de connexion qui alimente le cache. Si un utilisateur se connecte avec un nouveau mot de passe, l'entrée dans le cache sera également actualisée. Le cache entre en jeu lorsque l'utilisateur veut se connecter à sa session sans que Windows soit en mesure de contacter l'Active Directory. Ces informations sont stockées dans le Registre, sans limites de temps.
De ce fait, si le domaine Active Directory n'est pas joignable au moment où un utilisateur tente de se connecter, Windows vérifie si le nom d'utilisateur et le mot de passe saisi sur la page de connexion du système correspondent à des identifiants disponibles dans le cache local. Si c'est le cas, il accède à sa session.
Puisque le cache permet de s'authentifier en étant déconnecté de l'Active Directory, on peut imaginer le cas suivant. Si un utilisateur se connecte sur un ordinateur intégré au domaine Active Directory, qu'il éteint cet ordinateur, le déconnecte du réseau, et qu'il change son mot de passe depuis un deuxième ordinateur, il pourra toujours s'authentifier sur le premier ordinateur avec son ancien mot de passe (à condition d'utiliser l'ordinateur en mode hors connexion).
A. Où est stocké le cache des identifiants Windows ?
Par défaut, quand on ouvre une session d'un utilisateur Active Directory sur Windows, le système d'exploitation met en cache les identifiants : le nom d'utilisateur et un hash du mot de passe. Ce cache est stocké directement dans le Registre Windows au sein de la clé suivante :
HKEY_LOCAL_MACHINE\Security\Cache
Même avec les droits administrateurs vous ne pourrez pas voir la clé "Cache" dans le Registre Windows. C'est compréhensible. Néanmoins, il est assez facile d'accéder à ces informations en utilisant PsExec qui va nous permettre d'ouvrir le Registre Windows avec les droits Système.
A titre d'information, voici la commande à exécuter :
.\PsExec.exe -s -i -d regedit.exe
Sur mon ordinateur, que ce soit un Windows 10, un Windows 11 ou une autre version de Windows, il me sera possible de visualiser le cache. Chaque valeur "NL$X" correspond à une entrée du cache et le hash de chaque entrée utilise le nom d'utilisateur comme donnée de salage. En supprimant les entrées de cette liste, on purge le cache.
B. Cache des identifiants Windows : la limite d'identifiants
Windows ne va pas stocker dans son cache un nombre illimité d'identifiants. Dans sa configuration par défaut, Windows va stocker dans son cache les identifiants de 10 utilisateurs. C'est en tout cas le comportement depuis Windows 10 et Windows Server 2016, et c'est vrai aujourd'hui avec Windows 11 et Windows Server 2022. On peut même affirmer que Windows stocke dans son cache les identifiants des 10 derniers utilisateurs qui ont ouvert une session sur la machine en question.
Ce seuil de 10 est déterminé dans une valeur du Registre nommée "CachedLogonsCount" et qui se situe à cet emplacement :
Sur l'image ci-dessous, issue d'une machine Windows 10 dans sa configuration par défaut, on voit bien que la limite est définie sur 10.
Même en modifiant cette valeur, vous devez savoir aussi que Windows ne peut pas stocker plus de 50 entrées dans son cache d'identifiants. Ainsi, il faut considérer que la valeur maximale pour cette option est de 50 identifiants, mais personnellement je vous recommande plutôt de revoir cette valeur à la baisse (moins de 10). Je reviendrai sur ce point dans la suite de cet article.
C. Configuration du cache des identifiants par GPO
Que ce soit à partir d'une stratégie de groupe Active Directory ou de la stratégie de groupe locale (gpedit.msc), il y a un paramètre qui permet aux administrateurs de configurer le cache des identifiants sans devoir modifier directement le Registre. Si l'on prend l'exemple de la GPO Active Directory, il faut accéder à cet emplacement :
Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité
Ici, il sera nécessaire de configurer le paramètre "Ouvertures de sessions interactives : nombre d'ouvertures de sessions précédentes réalisées en utilisant le cache (lorsqu'aucun contrôleur de domaine n'est disponible)" en cochant l'option "Définir ce paramètre de stratégie" puis en définissant un seuil.
III. Les risques liés au cache des identifiants Windows
A. Le télétravail et le risque d'être bloqué
Lorsqu'un utilisateur est en télétravail et qu'il se connecte à sa session, il exploite le cache des identifiants et accède à son environnement. Ensuite, dans une majorité de cas, il va chercher à monter une connexion VPN pour se connecter aux ressources de l'entreprise : applications, fichiers, etc... Lorsque l'authentification du VPN est basée sur l'Active Directory, on peut se retrouver bloqué malgré la présence du cache des identifiants. Pourquoi ?
En fait, le cache des identifiants n'empêche pas le compte utilisateur de vivre dans l'Active Directory. Ainsi, il va arriver un jour où l'utilisateur devra changer son mot de passe conformément à la stratégie de mots de passe de l'entreprise. Sauf que le client VPN de l'entreprise ne sera pas en mesure de lui proposer le changement, et l'utilisateur ne pourra pas se connecter.
J'ai pris l'exemple du VPN, mais cela s'applique aussi s'il doit s'authentifier à une application Web basée sur l'authentification Active Directory. Ces tentatives répétées seront considérées comme en échec auprès de l'annuaire Active Directory et cela pourrait déclencher un verrouillage du compte utilisateur. Disons que ce comportement dépend de la stratégie de mot de passe et de verrouillage de comptes, mais dans le cas d'une infrastructure sécurisée, ce sera normalement le cas.
Face à cette problématique, quelle solution pour les utilisateurs et le service informatique ? Tout d'abord, nous pouvons faire en sorte d'avertir les utilisateurs par e-mail quelques jours avant l'expiration du mot de passe afin qu'ils anticipent et procèdent au changement du mot de passe. Cela éliminera sûrement une partie des cas problématiques.
En complément, il est pertinent de s'orienter vers une solution de réinitialisation du mot de passe en libre-service pour l'Active Directory, ce qui permet à l'utilisateur d'être autonome pour changer son mot de passe, de manière sécurisée. Cette solution va permettre au service informatique de ne plus avoir (ou quasiment plus, soyons honnêtes) ces demandes et ces problèmes à gérer.
B. La compromission du cache d'identifiants Windows
Le cache des identifiants représente un risque en matière de sécurité. Un attaquant qui obtient un accès sur un ordinateur avec des identifiants en cache pourra tenter différentes attaques, notamment une attaque de type brute force sur le hash du mot de passe. Ainsi, il devient possible de réaliser une attaque brute force sans être détecté par l'Active Directory en lui-même (ce qui ne déclenchera pas le verrouillage du compte Active Directory), car on cible le cache local, et non ne s'authentifie pas directement auprès de l'annuaire Active Directory.
Si un utilisateur se connecte sur l'ordinateur portable qui lui est affecté, ses identifiants seront mis dans le cache. Ensuite, si un administrateur du domaine se connecte sur la machine (normalement, on ne doit pas se connecter directement avec un compte administrateur du domaine, mais c'est très fréquent), ses identifiants seront aussi inclus dans le cache. De ce fait, un attaquant qui obtient un accès physique sur cet ordinateur peut réaliser un brute force sur le cache des identifiants afin d'espérer récupérer le mot de passe Administrateur du domaine ! La tâche sera plus ou moins compliquée selon la robustesse du mot de passe.
Pour réduire les risques, il convient de limiter le cache des identifiants à "1". Ainsi, si un administrateur se connecte, ses identifiants seront mis en cache, et quand l'utilisateur va récupérer son ordinateur et se reconnecter, cela va écraser l'entrée correspondante aux identifiants de l'administrateur. On peut appliquer cette politique sur les ordinateurs portables et aller plus loin sur les ordinateurs de bureau en désactivant le cache (valeur à "0") : ce sont des machines qui sont utilisées uniquement au bureau, en mode "en ligne" on peut dire. Attention tout de même, cela signifie qu'en cas d'indisponibilité du contrôleur de domaine ou du réseau, l'utilisateur ne pourra pas ouvrir sa session pour travailler.
Néanmoins, il existe une méthode qui ne nécessite pas de réaliser une attaque brute force sur le cache, mais qui consiste à démarrer l'ordinateur en mode récupération du système Windows et à venir écraser une entrée du cache par un nouveau mot de passe, à l'aide de Mimikatz (voir cet article). Ainsi, on change le mot de passe du cache et on peut s'authentifier sur la machine avec le nom d'utilisateur et le mot de passe falsifié.
Pour protéger les comptes avec des privilèges élevés, il convient d'ajouter les comptes au groupe "Protected Users" de l'Active Directory pour activer certaines protections, dont la désactivation de la mise en cache des identifiants pour les membres de ce groupe. Vous pouvez lire ce tutoriel à ce sujet : Active Directory et Protected Users.
IV. Conclusion
Suite à la lecture de cet article, vous en savez plus sur le fonctionnement du cache des identifiants sous Windows, et vous connaissez également les problématiques associées, que ce soit au niveau de la sécurité ou fonctionnellement parlant.
Spécialisée dans la cybersécurité, l'entreprise Imperva a publié un rapport dans lequel elle affirme avoir maîtrisé une attaque DDoS très importante avec un total de 25,3 milliards de requêtes ! Cette attaque s'est déroulée le 27 juin 2022.
Dans son rapport, Imperva précise que c'est une entreprise chinoise spécialisée dans les télécommunications qui était la cible de cette attaque DDoS qui aurait duré 4 heures et atteint un pic estimé à 3,9 millions de requêtes par seconde. Pour une attaque DDoS, 4 heures c'est très long. Le rapport d'Imperva précise : "L'attaque a duré plus de quatre heures, ce qui la place dans une catégorie spécifique d'attaques. Selon le rapport DDoS Threat Landscape d'Imperva, seules 10,5 % des attaques durent entre une et six heures, et la plupart durent moins de quinze minutes."
Le nombre de requêtes étant soutenu tout au long de l'attaque, au total il y a eu 25,3 milliards de requêtes envoyées. Le graphique ci-dessous est relativement parlant.
Cette cyberattaque a été lancée à partir d'un botnet composé d'environ 170 000 adresses IP différentes ! Derrière ces adresses IP, se cachent des équipements divers et variés : des routeurs, des serveurs, des caméras de sécurité, etc.... A chaque fois, il s'agit de machines compromises. Au total, ces adresses IP publiques sont réparties dans plus de 180 pays, avec une majorité aux États-Unis, en Indonésie et au Brésil. Autant dire que ce botnet s'appuie sur des machines situées dans le monde entier, y compris en France.
Afin de parvenir à envoyer autant de requêtes, les cybercriminels ont utilisé le multiplexage, l'une des fonctionnalités du protocole HTTP/2. Ainsi, les attaquants ont pu envoyer plusieurs requêtes à la fois sur des connexions individuelles afin de maximiser la charge sur la cible.
Il y a quelques jours, la société Akamai a mis en ligne un rapport après avoir contenu la plus grande attaque par DDoS que l'Europe ait connu jusqu'ici, avec un nouveau record.
La sortie de cette version majeure est un petit événement dans la vie de Windows 11 puisqu'il s'agit de la première - grosse - mise à jour de fonctionnalités pour ce système d'exploitation.
Comment obtenir Windows 11 22H2 ?
Tout d'abord, Microsoft met Windows 11 22H2 à disposition des "seekers", c'est-à-dire les personnes qui vont rechercher manuellement les mises à jour sur leur machine Windows dans l'espoir de voir l'upgrade vers Windows 11 22H2 arriver ! Néanmoins, il faut utiliser mis à jour Windows 11 avec le correctif de juin 2022 (ou supérieur). Cela s'applique à Windows 10, où vous devez avoir installé à minima le correctif d'avril 2022 (ou supérieur).
Voici un exemple où la mise à niveau vers Windows 11 version 22H2 est proposée sur une machine Windows 10. On peut voir le bouton "Stay on Windows 10 for now" qui permet à l'utilisateur de faire un choix : rester sur Windows 10 ou passer sur Windows 11.
Bien sûr, cette mise à niveau sera effectuée sous réserve que votre matériel soit compatible et que vos applications ne soient pas associées à un problème connu avec Windows 11. Microsoft prend soin de le rappeler : "Si nous détectons que votre appareil peut présenter un problème, tel qu'une incompatibilité avec une application, nous pouvons mettre en place un verrouillage et ne pas proposer la mise à jour tant que le problème n'est pas résolu.".
Au-delà de passer par Windows Update, vous pouvez aussi utiliser l'outil officiel Windows 11 Media Creation Tool pour mettre à jour votre machine vers la dernière version de Windows 11.
Un établissement de santé supplémentaire est victime d'une cyberattaque ! Cette fois-ci, il s'agit de l'hôpital de Cahors, dans le Lot. Cette attaque semble moins importante que celle qui a touché le Centre hospitalier de Corbeil-Essonnes, il y a environ un mois.
Cette attaque s'est déroulée sur la semaine du 12 septembre 2022, en soirée, et elle a touché les services administratifs de l'hôpital. Suite à cette attaque, la direction a déclenché son plan de réponse à incident, notamment en coupant l'accès à Internet et l'accès à la messagerie depuis l'extérieur. C'est ce qu'a précisé Michel Fabrejon, responsable sécurité des systèmes informatiques du Groupement Hospitalier de Territoire du Lot, à France 3 : "Nous avons coupé internet dans tout l'hôpital, en gardant les accès sensibles tels que les laboratoires externes de biologie et le trésor public pour régler les fournisseurs et payer les salaires."
D'après les informations communiquées par l'hôpital, le service informatique interne n'est pas seul sur le coup : "Le service informatique assisté de l'ANSSI (l'Agence Nationale de la Sécurité des Systèmes d'Information) et du CERT Cyberveille met tout en œuvre pour un retour à la normale dans les meilleurs délais".
Les données des patients ne sont pas concernées par cette cyberattaque, ce qui est une bonne nouvelle. Cela s'explique par le fait que les données des patients sont stockées chez un hébergeur qui est certifié pour stocker de la donnée relative à la santé. L'origine de l'attaque n'est pas précisée, ni même s'il s'agit d'un ransomware ou d'une autre souche malveillante.
Cette nouvelle attaque ne fait que renforcer l'idée qu'il est indispensable d'offrir des moyens plus importants et adaptés aux hôpitaux français afin qu'ils renforcent la sécurité. Récemment, le gouvernement a annoncé qu'une enveloppe de 20 millions d'euros supplémentaires était attribuée à l'ANSSI dans le but d'améliorer la sécurité du système d'information dans les établissements de santé français.
