"Mon PC est-il équipé d'une puce TPM ?", c'est peut-être une question que certaines d'entre vous se sont posées ! Dans ce tutoriel, nous allons voir plusieurs méthodes qui permettent de vérifier si un ordinateur est équipé d'une puce TPM 1.0, une puce TPM 2.0 ou s'il n'a pas du tout de puce TPM.
Nous allons effectuer les manipulations directement à partir de Windows, via l'application système "Sécurité Windows", la console "tpm.msc", la console PowerShell ainsi que l'outil tpmtool.
Si la vérification indique que votre PC n'est pas équipé d'une puce TPM, nous vous invitons tout de même à vérifier dans la configuration de votre BIOS/UEFI. En effet, une option peut être intégrée pour permettre d'activer ou désactiver la puce TPM ("TPM Support", "Security Device Support", "TPM On", etc.).
Pour rappel, le système d'exploitation Windows 11 exige la présence d'une puce TPM 2.0 comme prérequis pour pouvoir être installé sur un ordinateur. Toutefois, nous pouvons quand même installer Windows 11 sur une machine sans puce TPM si nécessaire.
II. Vérifier si un PC est équipé d'une puce TPM 2.0
Les manipulations suivantes sont effectuées sur un ordinateur Windows 11, mais elles sont applicables sur Windows 10 (au moins pour les méthodes n°2 et n°3).
A. Méthode n°1 : Sécurité Windows
Sur votre ordinateur, recherchez "Sécurité Windows" pour accéder au centre de gestion des fonctions relatives à la sécurité du système. Sur la gauche, cliquez sur "Sécurité des appareils", et à cet endroit, vous devriez pouvoir localiser la section "Processeur de sécurité" faisant référence à la puce TPM.
Ici, il vous suffit de cliquer sur "Détails du processeur de sécurité" pour obtenir des informations supplémentaires.
Nous pouvons obtenir des informations sur le fabricant, mais aussi, et surtout, la version de la puce TPM grâce à l'instruction "Version des spécifications" où c'est bien indiqué "2.0". Dans cet exemple, il s'agit d'une machine virtuelle Windows 11 sur un Hyper-V.
B. Méthode n°2 : tpm.msc
La seconde méthode consiste à utiliser la console "tpm.msc" accessible de différentes façons. Le moyen le plus direct, c'est de saisir "tpm.msc" dans la zone de recherche de Windows et d'appuyer sur Entrée.
tpm.msc
Cette console indique clairement si votre PC est équipé ou non d'une puce TPM, et nous avons aussi des indications sur le statut de la puce TPM. Ici, nous pouvons voir que le module TPM est prêt à être utilisé. Nous pouvons également voir la version : "Version de la spécification : 2.0", ce qui veut dire que cette machine est équipée d'une puce TPM 2.0.
C. Méthode n°3 : PowerShell
Désormais, nous allons évoquer la commande "Get-Tpm" de PowerShell, qu'il convient d'exécuter dans une console avec des droits d'administrateur. Le simple fait d'exécuter cette commande sans paramètre va permettre de retourner un ensemble d'informations sur l'état de la puce TPM : la puce TPM est-elle présente ? La puce TPM est-elle prête ? La puce TPM est-elle activée ?
Get-Tpm
Toutefois, cette commande ne donne pas de précision sur le numéro de version de la puce TPM (1.2, 2.0), mais à la place, le numéro de version du fabricant, ce qui peut être un peu trompeur dans certains cas, comme celui présenté ci-dessous.
Pour obtenir des informations plus précise, vous devez utiliser la commande Get-CimInstance (ou éventuellement Get-WmiOjbect) pour lire le contenu de la classe Win32_Tpm. Voici la commande à exécuter :
Ici, nous pouvons obtenir la version de la spécification, et il s'agit bien d'une puce TPM 2.0 (tenez compte de la première valeur).
D. Méthode n°4 : tpmtool
La commande native "tpmtool" de Windows permet d'obtenir des informations sur l'état du module TPM présent dans la machine. Ainsi, toujours dans une console, nous pouvons exécuter cette commande :
tpmtool getdeviceinformation
Cette commande retourne plusieurs informations, comme la commande Get-Tpm, à la différence qu'elle indique la version de la puce TPM, ce qui permettra de savoir s'il s'agit d'une puce TPM 1.2 ou 2.0.
III. Conclusion
Grâce à ces différentes méthodes, vous êtes en mesure d'en savoir plus sur la présence d'une puce TPM dans votre machine, et vous pouvez aussi obtenir des informations sur l'état de cette puce TPM.
Un nouvel ensemble de vulnérabilités baptisé "CONTINUATION Flood" a été découvert dans le protocole HTTP/2 ! Dans certains cas, l'exploitation de ces vulnérabilités permet un déni de service sur le serveur web pris pour cible, à partir d'une seule connexion TCP. Voici ce qu'il faut savoir !
Le chercheur en sécurité Barket Nowotarski a fait la découverte des vulnérabilités "CONTINUATION Flood" présente dans HTTP/2, une version du protocole HTTP standardisée en 2015. S'il a choisi ce nom, ce n'est pas un hasard, car ces faiblesses sont liées à une mauvaise gestion des trames HTTP/2 CONTINUATION dans de nombreuses implémentations du protocole HTTP/2. Ces trames sont utilisées pour assembler le flux de données correspondant à différents blocs de messages du protocole HTTP/2, notamment pour l'en-tête.
Lorsque les données ne sont pas correctement limitées ou vérifiées, un attaquant peut exploiter ces vulnérabilités en envoyant des trames extrêmement longues, sans définir l'indicateur "END_HEADERS", ce qui va permettre d'épuiser les ressources du serveur cible et engendrer un déni de service. Dans certains cas, une seule connexion TCP en HTTP/2 peut suffire pour saturer le serveur en mémoire vive et le faire planter.
"Les implémentations sans timeout pour les en-têtes ne nécessitaient qu'une seule connexion HTTP/2 pour faire planter le serveur.", peut-on lire dans le rapport de Barket Nowotarski.
Par ailleurs, il est important de préciser que le protocole HTTP/2 est encore largement utilisé. "Selon Cloudflare Radar, le trafic HTTP/2 représente environ 60 % de l'ensemble du trafic HTTP humain (données excluant les robots)", précise Barket Nowotarski, avec un graphe à l'appui.
Source : nowotarski.info
CONTINUATION Flood, un ensemble de 9 failles de sécurité
Le CERT/CC a également publié un rapport au sujet de l'ensemble de vulnérabilités CONTINUATION Flood. Il référence 9 failles de sécurité correspondantes à cette faiblesse dans différentes implémentations : la bibliothèque nghttp2, AMPHP, Apache HTTP, Arista Networks, Red Hat, SUSE Linux, Node.js, Envoy (version 1.29.2 ou antérieure), ainsi que le langage de programmation Go.
À la fin de l'article du CERT/CC, il y a un tableau récapitulatif, et nous pouvons voir que le statut est actuellement inconnu pour plusieurs dizaines d'implémentations. Voici un extrait :
Source : CERT/CC
Les CVE suivantes sont associées à CONTINUATION Flood : CVE-2024-27983, CVE-2024-27919, CVE-2024-2758, CVE-2024-2653, CVE-2023-45288, CVE-2024-28182, CVE-2024-27316, CVE-2024-31309, CVE-2024-30255.
Si vous utilisez Apache2, sachez que la vulnérabilité CVE-2024-27316, correspondante à CONTINUATION Flood, a été corrigée dans Apache 2.4.59 publiée ce jeudi 4 avril 2024 (voir cette page).
Ceci n'est pas sans rappeler la faille de sécurité "Rapid Reset" présente dans le protocole HTTP/2 et révélée en octobre 2023. À l'époque, elle avait permis de déclencher des attaques DDoS records !
Dans cet article, nous allons nous intéresser à une mauvaise pratique encore très présente au sein des équipes d'administration et des annuaires Active Directory : le stockage de mots de passe dans l'attribut "description" des objets utilisateurs.
Nous allons voir en quoi cette pratique est dangereuse pour le domaine et pourquoi son existence et ses impacts sont souvent méconnus. Également, nous nous intéresserons de façon très pratique à la manière dont attaquants et défenseurs peuvent détecter et exploiter cette faille au sein d'un Active Directory.
Enfin, nous verrons quelles sont les bonnes pratiques et les difficultés de détection, aussi bien lors de l'introduction de la vulnérabilité dans l'Active Directory que lors de son exploitation par un attaquant.
II. Mot de passe dans l'attribut description : quels risques ?
Lorsque l'on administre un système d'information et un domaine, nous avons accès à des outils, interfaces et serveurs auquel personne d'autres n'a accès dans l'entreprise. Ainsi, il est aisé de croire que nous seul avons accès aux différentes informations que nous manipulons : ce n'est pas tout à fait vrai.
Au sein de l'Active Directory, tous les objets ont de nombreux attributs, techniques et métier. Le "dn", "sAMAccountName", les attributs relatifs aux groupes, aux mots de passe, etc. L'attribut "description" en fait partie, il s'agit d'un simple champ texte permettant d'indiquer des informations sur l'objet créé :
Exemple de description d'un objet utilisateur dans l'Active Directory.
Plutôt pratique lorsque l'on souhaite, par exemple, se rappeler pour quel service ce compte a été créé, quel est le nom complet du propriétaire lorsque l'on crée des objets non nominatifs ("XR-23-OP"), etc.
Lorsque l'on combine ces deux constats, les administrateurs peuvent penser que la description peut aussi permettre de stocker les mots de passe des comptes dont ils ne se serviront pas tous les jours ou que plusieurs membres de l'équipe sont susceptibles de manipuler (comptes "communs" ou de services par exemple). Dès lors, quoi de plus pratique que d'établir une convention implicite : "si tu cherches le mot de passe de ce compte, il est dans sa description AD" ?
Cependant, il est souvent oublié que la quasi-totalité des attributs de tous les objets sont lisibles par tous les comptes authentifiés de l'Active Directory (utilisateurs, ordinateurs, etc.). C'est ainsi que fonctionne l'Active Directory et il en va de son bon fonctionnement. Si vous avez déjà parcouru mon cours sur BloodHound, vous verrez que cela permet d'aller très loin dans la découverte d'un domaine et même d'y découvrir des chemins d'attaque complets.
Pour l'attribut "description" par exemple, il pourrait très bien être utilisé par une application de tchat interne se reposant sur l'annuaire pour afficher la description de l'utilisateur avec lequel vous discutez. Il faut donc bien que cet attribut soit accessible en lecture.
Cette mauvaise pratique, très commune d'après mon expérience en tant qu'auditeur cybersécurité et pentester, est souvent exploitée par les attaquants ayant déjà un accès authentifié au domaine afin de compromettre rapidement d'autres comptes. Ce type d'attaque dispose même d'un TTP dans le framework MITRE ATT&CK, qui référence les principales techniques d'attaque (T1552 - Unsecured Credentials) :
TTP T1552 du framework MITRE ATT&CK
III. Point de vue de l'attaquant
A. Depuis Linux
À présent, nous allons voir comment un attaquant disposant d'un accès authentifié au domaine (mode opératoire "boite grise"), peut récupérer les descriptions des objets utilisateurs du domaine depuis un poste Linux. De nombreux outils offensifs ont été développés, notamment en Python et bash, pour les OS Linux.
Utilisation de ldapsearch
L'outil le plus simple pour commencer est bien sur "ldapsearch", un client plutôt classique et légitime pour discuter avec le service LDAP :
Ici, nous obtenons rapidement toutes les descriptions de tous les utilisateurs C'est un début (plutôt verbeux), cherchons maintenant des mots de passe.
D'après mon expérience, certains caractères sont spécifiques à la présence de mots de passe et rarement présents dans des descriptions textuelles simples, c'est notamment le cas du ":" et du "=". C'est aussi le cas de certains mots comme "mdp", "pass" ou "mot de passe".
Nous pouvons ajouter des filtres, bien que ce soit quelque peu fastidieux via "ldapsearch" :
Nous utilisons ici le module "user-desc" de "netexec", celui-ci va tout d'abord nous ressortir toutes les descriptions des objets utilisateurs contenant le mot de "pass".
Utilisation de netexec pour extraire les descriptions des objets utilisateurs.
Comme vous pouvez le voir dans la dernière ligne de la sortie, "netexec" va également sauvegarder toutes les descriptions des utilisateurs dans un fichier de log, dans lequel nous pourrons faire nos propres recherches, exemple :
Récupération d'un mot de passe dans le fichier de log créé par "netexec".
Utilisation de Cypher
Enfin, si vous avez utilisé "SharpHound.exe" pour extraire les données de l'Active Directory et que vous les avez importées dans BloodHound, voici une requête "Cypher" à utiliser dans la base "Neo4j" pour avoir une recherche équivalente à celles faites précédemment :
MATCH (u:User) WHERE u.description CONTAINS "=" OR u.description CONTAINS ":" OR u.description CONTAINS "mdp" OR u.description CONTAINS "pass" OR u.description CONTAINS "mot de passe" RETURN u.samaccountname,u.description
Voici un exemple de résultat obtenu :
Recherche et visualisation des mots de passe dans l'attribut "description" depuis neo4j.
Si vous souhaitez apprendre à utiliser BloodHound, n'hésitez pas à consulter mon cours sur le sujet :
Nous allons à présent voir comment récupérer ces informations en tant qu'attaquant sur un poste Windows, intégré ou non au domaine : la différence n'est pas très importante lorsque l'on dispose d'un compte de domaine valide.
Utilisons pour cela "PowerView" de la suite PowerSploit, un ensemble de scripts PowerShell offensifs (un peu l'équivalent de la librairie "impacket" sous Linux) :
Nous venons de voir que sous Linux comme sous Windows, la récupération des descriptions des objets de l'Active Directory est triviale et même réalisable avec des outils natifs et non "offensifs" ("ldapsearch"). Il faut également savoir que si votre Active Directory est affecté par certaines mauvaises configurations, ces informations peuvent aussi être récupérées sans authentification, par exemple, en cas d'accès anonyme autorisé au service LDAP de l'Active Directory.
IV. Point de vue du défenseur
A. Identifier les mots de passe dans les descriptions
Si vous êtes en charge de l'administration du domaine et avez accès au contrôleur de domaine. La première bonne pratique est déjà de constater si des mots de passe sont présents dans la description de vos objets. Vous pouvez ouvrir la console "Utilisateurs et ordinateurs Active Directory" et trouver la description des objets dans l'affichage central :
VIsualisation des attributs descriptsion des objets d'un OU sur le contrôleur de domaine.
Pour trouver et modifier la description d'un objet, il faut faire un clic droit "Propriétés" sur l'objet en question, puis se rendre sur "Général" :
Accès à l'attribut "description" d'un objet utilisateur au sein de l'Active Directory.
Vous pouvez faire la même opération en PowerShell avec la cmdlet "Get-ADUser", issue du module "Active Directory". Une première requête va nous afficher toutes les descriptions utilisateurs non vides :
Application de filtres de recherche sur le contenu des descriptions utilisateur avec "get-ADUser".
Il s'agit là déjà d'une bonne base de recherche. Si vous souhaitez aller plus loin et être sûr qu'aucun mot de passe n'est présent, il faudra parcourir les données affichées manuellement.
Nous nous limitons aux utilisateurs ici, mais cela vaut peut-être également le coup de chercher dans les descriptions d'autres types d'objets ? Également, maintenant que vous avez ces quelques commandes sous la main, pourquoi ne pas planifier un contrôle régulier du contenu des attributs "description" des objets de l'Active Directory ? Afin de mettre en place cette sécurisation dans la durée.
B. Correctif et bonnes pratiques de sécurité
Nous allons à présent voir comment corriger cette faiblesse si vous la découvrez sur votre domaine. Dans un premier temps, il convient de savoir s'il est légitime de stocker ce mot de passe, doit-il être utilisé par plusieurs personnes (cas d'un compte de service) ? Si c'est le cas, il est recommandé de stocker ce mot de passe dans un coffre-fort numérique, partagé avec votre équipe si besoin est. Ensuite, la correction en elle-même est plutôt simple : Modifier la description.
Via l'interface graphique, il suffit de faire un clic droit "Propriétés" et de modifié la valeur de l'attribut "description", tel que montré plus haut :
Modification de la description d'un utilisateur.
Il est également possible de le faire via PowerShell, en utilisant la CmdLet "Set-ADUser" du module "Active Directory" :
Set-ADUser Topdesk -Description $null
Vous pourrez immédiatement contrôler le résultat de "Set-ADUser" avec la CmdLet "Get-ADUser" :
Modification via "Set-ADUser", puis contrôle de la description d'un utilisateur en PowerShell.
Pour être très pointilleux, vous pouvez même remplacer le contenu de la description par "Description supprimée par XXX le XX/XX/XXXX". Ainsi, il n'y aura pas de mauvaise surprise pour votre collègue qui a l'habitude de récupérer ce mot de passe à cet endroit, et il pourra venir vous demander où est ce fameux mot de passe à présent :).
Évoquons à présent les bonnes pratiques concernant le stockage des mots de passe :
Les mots de passe ne doivent jamais être stockés de manière non sécurisée (chiffrée) et sur des supports, physiques ou numériques, accessibles à tous (même chiffrés).
Lorsque le besoin de partager des mots de passe est présent (cas pour un compte de service, susceptibles d'être géré par plusieurs personnes), il est recommandé d'utiliser des coffres-forts de mots de passe. KeePass est une bonne option, mais peut être limité en ce qui concerne le partage d'information, son usage est d'ordinaire plutôt personnel. Des solutions existent pour le partage de mot de passe, on peut notamment citer le projet Bitwarden qui permet de gérer les permissions et journaliser les accès aux mots de passe (vous pouvez auto-héberger Bitwarden).
Lorsqu'il s'agit de mots de passe de compte utilisateur (dans le sens utilisateur humain du système d'information) : l'administrateur n'a pas à le connaitre, ce mot de passe n'a donc rien à faire dans un attribut quel qu'il soit.
La bonne pratique d'assignation des mots de passe utilisateur consiste à paramétrer un mot de passe (aléatoire et différent à chaque utilisateur) à un compte, et de cocher la case "L'utilisateur doit changer ce mot de passe à la prochaine ouverture de session". L'utilisateur pourra alors paramétrer un mot de passe qui lui est propre ensuite.
Activation de l'option imposant à l'utilisateur de changer son mot de passe à la première connexion.
Si le besoin d'invoquer un argument d'autorité se fait sentir, nous pouvons toujours rappeler la directive n°11 du guide d'hygiène informatique de l'ANSSI :
Directive n°11 du guide d'hygiène de l'ANSSI sur la protection des mots de passe.
Il est également recommandé de changer les mots de passe des comptes concernés. En effet, les mots de passe ayant été exposés "publiquement" par le passé, n'importe qui peut les avoir récupérés et donc continuer de les utiliser. Sans parler de la présence de cette information dans d'éventuels backups de la base NTDS, export des données de l'AD (BloodHound, PingCastle), etc.
Enfin, il convient également sensibiliser et former les administrateurs aux bonnes pratiques de sécurité et risques liés au stockage non sécurisé des mots de passe :
Identifiant de la remédiation dans le framework MITRE ATT&CK : M1017 - User Training
Directive n°1 du guide d'hygiène de l'ANSSI : Former les équipes opérationnelles à la sécurité des systèmes d’information
Les simulations de cyberattaques, telles que les tests d'intrusion ou les opérations Red Team, offrent également une opportunité de mettre en lumière de manière très factuelle les mauvaises pratiques en matière de sécurité. Elles permettent de mesurer concrètement l'impact de ces pratiques sur la sécurité du système d'information et, par extension, sur la résilience de l'entreprise. Cela permet aussi parfois de bousculer certaines certitudes en incitant à une ouverture d'esprit et à une révision des positions figées.
C. Possibilité de détection de l'attaque
Nous allons à présent nous intéresser aux possibilités de détection de l'exploitation de cette vulnérabilité ou de son introduction au sein de l'Active Directory via les journaux d'évènements. Concernant la détection, et sur un Active Directory disposant des règles d'audit par défaut, les choses se compliquent quelque peu.
Pour étudier les évènements produits lors de la récupération des descriptions, j'effectue 10 fois de suite une récupération de la description des 2500 utilisateurs de mon Active Directory depuis un poste Linux, histoire de générer un beau volume de requêtes :
Exécution d'une boucle de 10 itérations récupérant la description des utilisateurs de l'Active Directory.
Voici le volume de logs produits durant le temps de l'attaque, que je visualise dans ElasticSearch :
Vue d'ensemble des journaux d'évènements générés durant l'opération.
59 évènements, ce qui est plutôt faible au regard du nombre d'éléments récupérés et en sachant que mon Active Directory est dans un lab vide, et non dans un vrai SI avec de l'activité. Si j'interroge ELK sur les top évènements générés, voici ce qu'il en ressort :
Pour faire simple : aucun évènement n'est journalisé mis à part l'ouverture et la fermeture d'une session. Autrement dit, cette opération passe totalement inaperçue.
Autre point potentiellement intéressant, nous pouvons tenter de voir si les journaux d'évènement peuvent nous aider à détecter l'introduction de la vulnérabilité sur le domaine par un administrateur. Autrement dit, pouvons-nous avoir un évènement/une alerte lorsqu'un utilisateur est créé ou modifié avec une description contenant des caractères/mots caractéristiques d'un mot de passe ?
Lors de la création d'un utilisateur, l'eventID 4720 A user account was created est journalisé, voici son contenu (vue ElasticSearch) :
Contenu de l'event 4720 suite à la création d'un nouvel utilisateur.
Lors de la modification d'un utilisateur existant et de l'insertion d'un mot de passe dans sa description, l'eventID 4738 A user account was changed est journalisé, voici son contenu (vue ElasticSearch):
Contenu de l'event 4738 suite à la modification de la description d'un utilisateur existant.
Vous ne voyez pas l'attribut description ? C'est normal, il n'est pas journalisé. Autrement dit, nous sommes à nouveau dans le noir et il est impossible de mettre en place une règle de détection basée sur le contenu du champ "description".
Nous venons de voir que l'objectif de détection parait difficile à atteindre, tant lors d'une "exploitation" (récupération des attributs) et que lors de l'introduction de la vulnérabilité sur le domaine. La seule option qu'il nous reste est donc la réalisation d'audits réguliers, manuels ou scriptés, permettant de chercher des mots de passe dans l'attribut "description" des utilisateurs.
Pour répondre à ce besoin, je vous propose un script PowerShell qui peut être utilisé dans le cadre d'une tâche planifiée déclenchée par un évènement 4738 :
Ce script va, lors de sa première exécution, créer une "archive" : un fichier XML contenant les GUID des utilisateurs et le hash de leur description. Lors des exécutions suivantes, les utilisateurs et descriptions seront récupérés auprès de l'Active Directory, comparés à l'archive créée précédemment et les différences de hash découverts (donc, une modification de la description) entrainerons une journalisation du login utilisateur ainsi que de sa description.
Si l'utilisateur n'existait pas dans l'archive précédente (cas d'une création), sa description sera journalisée également. Enfin, une nouvelle archive sera créée et remplacera la précédente, prête pour la prochaine analyse. Le script créera un évènement ID 1000 dans le journal "Application" :
Journalisation d'une description modifiée dans un évènement 10000.
Voici par exemple une requête KQL (pour ElasticSearch) permettant de chercher quelques mots de clés dans les "event.code 10000" :
event.code:10000 and (winlog.event_data.param2: *pass* or winlog.event_data.param2: *mot de passe* or winlog.event_data.param2: *pwd*)
Et enfin un exemple de détection d'un mot de passe dans une description dans grâce aux journaux créés par ce script dans ElasticSearch :
Détection d'un mot de passe dans une description via ELK et d'un event.code 10000.
Identifiant de la remédiation dans le framework MITRE ATT&CK : M1047 - Audit
Si vous connaissez d'autres options, eventID ou moyens de détection concernant cette faiblesse et son exploitation, n'hésitez pas à le signaler dans les commentaires de cet article !
V. Conclusion
Nous avons dans cet article fait le tour de la question concernant la présence de mots de passe dans l'attribut "description" des utilisateurs du domaine. Nous avons notamment vu pourquoi cette faiblesse pouvait être présente sur un domaine, comment elle pouvait être exploitée et corrigée. Également, nous avons vu que la détection de l'attaque en question n'est pas aisée, contrairement au contrôle de sa présence au sein de l'Active Directory. Cela va donc dans le sens d'un contrôle régulier de cet attribut et de la sensibilisation des administrateurs sur les bonnes pratiques de stockage des mots de passe.
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
À partir du 14 octobre 2025, la majorité des éditions de Windows 10 ne seront plus prises en charge par Microsoft. Il sera toujours possible de bénéficier des mises à jour de sécurité grâce au programme Extended Security Updates (ESU). Désormais, nous connaissons le tarif de ces futures mises à jour !
Rappel sur la fin du support de Windows 10
Windows 10 22H2 est actuellement la dernière version de Windows 10, et il n'y en aura pas d'autres puisque Microsoft se concentre sur Windows 11, et prépare surement Windows 12 en toute discrétion. Nous savons depuis longtemps que le support prendra fin le 14 octobre 2025, ce qui signifie que tout le monde peut bénéficier des mises à jour mensuelles, de façon gratuite.
Il y a tout de même des exceptions : les éditions LTSC de Windows, ainsi que celles pour l'IoT, qui sont généralement utilisées sur les appareils médicaux ou industriels. Par exemple, le support de Windows 10 Enterprise LTSC 2019 prendra fin le 9 janvier 2029. Toutes les dates sont fournies sur cette page.
Les tarifs du programme Extended Security Updates (ESU)
Pour les utilisateurs de Windows 10 qui ne peuvent pas ou ne veulent pas passer sur Windows 11, et qui souhaitent rester sur Windows 10 après le 14 octobre 2025, il y a une option payante : le programme Extended Security Updates (ESU). Grâce à lui, votre machine peut bénéficier des mises à jour de sécurité. Ce programme sera accessible pour les particuliers et les professionnels.
Le programme ESU se présente sous la forme d'un abonnement annuel qu'il est possible de renouveler au maximum pendant 3 ans.
Voici les tarifs prévus par Microsoft :
61 dollars par appareil pour bénéficier de 12 mois de support étendu, pour la première année (c'est le même tarif que pour Windows 7)
122 dollars par appareil pour bénéficier de 12 mois de support supplémentaire, soit une deuxième année
244 dollars par appareil pour bénéficier de 12 mois de support supplémentaire, soit une troisième année
"Le prix doublera chaque année consécutive, pour un maximum de trois ans. Si vous décidez d'intégrer le programme au cours de la deuxième année, vous devrez également payer pour la première année, car les ESU sont cumulatives.", peut-on lire sur le site de Microsoft.
Au total, pour un seul appareil Windows 10, il faudra débourser 427 dollars pour bénéficier du support étendu, incluant les mises à jour de sécurité, pendant 3 ans. Un tarif qui devrait dissuader beaucoup d'organisations, mais de toute façon, l'ESU est surtout une solution temporaire.
La stratégie de Microsoft est claire : inciter les utilisateurs à passer sur Windows 11.Ceci vous évitera de jeter de l'argent par les fenêtres.
Si vous utilisez Microsoft Intune ou Windows Autopatch, sachez que Microsoft pourra vous accorder une réduction de 25% sur le tarif. Ainsi, la première année passerait de 61 dollars à 45 dollars par appareil. Par ailleurs, si vous utilisez la solution de Cloud PC "Windows 365" et que vos utilisateurs s'y connectent à partir d'un Windows 10, Microsoft vous offrira les licences ESU pour ces machines.
Google Chrome bénéficie d'une nouvelle mise à jour de sécurité pour combler une faille zero-day découverte à l'occasion de l'événement Pwn2Own 2024, ainsi que deux autres vulnérabilités importantes ! Faisons le point !
Si vous utilisez Google Chrome, oubliez les versions 123.0.6312.86/.87 pour Windows et Mac, ainsi que la version 123.0.6312.86 pour Linux ! Google a mis en ligne de nouvelle version pour corriger 3 vulnérabilités, dont une faille de sécurité zero-day découverte et exploitée le 22 mars 2024 par Edouard Bochin et Tao Yan de Palo Alto Networks, à l'occasion de la compétition de hacking Pwn2Own 2024 de Vancouver.
Associée à la référence CVE-2024-3159, cette faille de sécurité élevée correspond à une faiblesse de type "out-of-bounds read" est présente dans le moteur JavaScript Chrome V8. Elle pourrait être exploitée à partir d'une page HTML dans le but d'accéder à des informations sensibles ou de déclencher un plantage sur l'ordinateur de la victime. Grâce à la découverte de cette vulnérabilité présente aussi dans Microsoft Edge, Edouard Bochin et Tao Yan ont été récompensés par une belle somme : 42 500 dollars.
Par ailleurs, Google a corrigé deux autres failles de sécurité importantes découvertes en mars dernier : CVE-2024-3156 et CVE-2024-3158. La première est également présente dans le moteur JavaScript Chrome V8 tandis que la seconde est présente dans le gestionnaire de favoris.
Comment se protéger ?
Google a publié de nouvelles versions stables pour son navigateur Chrome. Ainsi, vous devez mettre à jour Google Chrome pour passer sur les versions 123.0.6312.105/.106/.107 pour Windows et Mac et 123.0.6312.105 pour Linux. Ces versions sont en cours de diffusion à l'échelle mondiale.
Pour rappel, mardi 26 mars 2024, Google avait déjà publié de nouvelles versions pour Chrome dans le but de corriger 7 vulnérabilités, dont 2 failles de sécurité zero-day découvertes lors du Pwn2Own 2024 de Vancouver. Donc, ces nouvelles versions vous permettent aussi de vous protéger contre ces vulnérabilités.
