Microsoft Edge conserve tous les mots de passe en clair en mémoire, même lorsqu’il n’est pas utilisé

• Microsoft Edge déchiffre tous les mots de passe enregistrés au démarrage et maintient ces identifiants en clair dans la mémoire du processus
• Ce comportement se produit même si l’utilisateur ne visite aucun site utilisant ces identifiants
• L’interface du gestionnaire de mots de passe d’Edge exige une réauthentification avant d’afficher à nouveau le même mot de passe, mais le processus du navigateur détient déjà tous les mots de passe en clair
• Parmi les navigateurs basés sur Chromium testés, seul Edge fonctionnait de cette manière, tandis que Chrome est conçu pour rendre plus difficile la simple lecture et l’extraction des mots de passe enregistrés depuis la mémoire du processus
• Chrome ne déchiffre les identifiants qu’au moment où ils sont nécessaires et, avec App-Bound Encryption (ABE), lie le déchiffrement à un processus Chrome authentifié afin d’empêcher d’autres processus de réutiliser la clé de chiffrement de Chrome
• Grâce à ce contrôle, les mots de passe en clair n’apparaissent brièvement que lors de l’autoremplissage ou lorsque l’utilisateur les affiche lui-même, ce qui réduit l’efficacité du memory scraping à grande échelle

Scénarios de risque et état de la divulgation

• Dans des environnements partagés, le risque lié au maintien des mots de passe en clair en mémoire augmente
• Si un attaquant obtient des privilèges administrateur sur un terminal server, il peut accéder à la mémoire des processus de tous les utilisateurs connectés
• Lors de la démonstration, un attaquant ayant compromis un compte utilisateur disposant de privilèges administrateur a pu voir les identifiants enregistrés d’Edge de deux autres utilisateurs connectés, ou d’utilisateurs déconnectés, alors qu’Edge était en cours d’exécution
• Ce comportement a été signalé à Microsoft, dont la réponse officielle a indiqué qu’il s’agissait d’un fonctionnement « by design »
• Il a également été indiqué à Microsoft que cette information serait partagée dans le cadre d’une divulgation responsable afin que les utilisateurs et les organisations puissent évaluer leur manière de gérer les identifiants
• Le mercredi 29 avril, ce sujet a été présenté par BigBiteOfTech de Palo Alto Networks Norway, avec une démonstration d’un outil simple permettant de vérifier facilement si des mots de passe sont stockés en clair en mémoire
• L’outil de preuve de concept a été publié sur GitHub, et l’auteur sollicite des retours, ayant encore peu d’expérience avec C# et les déploiements GitHub : EdgeSavedPasswordsDumper

[GN⁺]

Commentaires sur Hacker News

• On est déjà très proche d’une situation où l’ennemi est de l’autre côté du sas étanche. Si on peut lire la mémoire arbitraire d’un processus, on est probablement déjà en position de simplement vider les mots de passe en se faisant passer pour cet utilisateur
  Si un attaquant obtient les droits d’administrateur d’un serveur de terminaux, il peut accéder à la mémoire des processus de tous les utilisateurs connectés, et avec les privilèges administrateur il peut aussi attacher un débogueur à tous les processus Chrome pour forcer le déchiffrement des mots de passe
  La seule vraie différence concerne des attaques de type cold boot, et même là il n’est pas clair si cela rend juste l’attaque un peu plus facile ou si cela permet réellement une attaque auparavant impossible
  [1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
  • Cette logique correspond parfaitement au modèle de menace de Chromium. À partir du moment où l’attaquant a les privilèges administrateur, la partie est par définition terminée
    Il est peu probable que ce soit un problème propre à Edge, et il n’y a aucune raison que Microsoft rende le navigateur moins sûr que le projet amont
    Chrome considère les attaques physiquement locales comme hors de son modèle de menace : si un utilisateur s’est connecté sur mon appareil à ma place, ou peut exécuter des logiciels avec les droits de mon utilisateur système, alors ni Chrome ni aucune autre application ne peut vraiment se défendre
    Un tel attaquant peut modifier les exécutables et les DLL, changer des variables d’environnement comme PATH, modifier les fichiers de configuration, lire les données du compte utilisateur et les exfiltrer ; la position est donc que Chrome ne peut offrir aucune garantie de défense réellement utile dans ce cas
    https://chromium.googlesource.com/chromium/src/+/148.0.7778....
  • Ces dernières années, il y a aussi eu des vulnérabilités de navigateur permettant une lecture mémoire arbitraire avec de simples droits utilisateur, même si c’était lent ou sans contrôle total de l’emplacement. Effacer les identifiants le plus vite possible après usage reste une mesure préventive assez raisonnable, ne serait-ce que comme une couche de défense supplémentaire
  • La sécurité n’est pas binaire. Coller un Post-it avec ses identifiants sur l’écran est clairement plus risqué que les mettre dans un tiroir non verrouillé : il existe des degrés
  • Du point de vue de l’utilisateur, il faut se reconnecter avec une authentification biométrique à chaque fois qu’on veut coller un mot de passe ; et pourtant n’importe quel processus utilisateur pourrait le récupérer en mémoire ?
    J’ai l’impression qu’il me manque quelque chose
  • Vous avez déjà oublié Cloudbleed ?
    [0] https://en.wikipedia.org/wiki/Cloudbleed
• À noter que Google explique que Chrome stocke les mots de passe en mémoire sous forme chiffrée et utilise un service avec élévation de privilèges pour empêcher qu’un autre processus se fasse passer pour Chrome afin d’accéder aux mots de passe en clair : https://security.googleblog.com/2024/07/improving-security-o...
• Pour être clair, un scénario d’attaque possible consiste à laisser son ordinateur déverrouillé le temps d’aller aux toilettes cinq minutes, puis à ce qu’un pirate malveillant vide tous les mots de passe avant votre retour
  Je pense que cela mérite d’être pris en compte. Si les gestionnaires de mots de passe redemandent le mot de passe maître ou la passkey au bout de 10 minutes, ce n’est pas sans raison
  Je pensais que Chrome s’appuyait sur une zone sécurisée chiffrée, donc même avec les droits root il serait assez difficile d’extraire facilement les mots de passe
  Bien sûr, il ne faut pas laisser son ordinateur sans surveillance. Mais cela ne veut pas dire qu’il est acceptable de concevoir un produit de façon à rendre une erreur inévitable facile à exploiter de manière catastrophique
• Cet outil accède-t-il à une instance d’Edge en cours d’exécution sur la même machine ? Si oui, n’est-il pas alors possible d’exporter simplement les mots de passe enregistrés ?
  https://support.microsoft.com/en-us/topic/export-passwords-i...
  • Les gestionnaires de mots de passe font souvent beaucoup d’efforts pour sécuriser les mots de passe présents en mémoire, mais le modèle d’attaque de ces outils est souvent mal compris
    Par exemple, des outils comme KeePass accordent beaucoup d’attention à l’enregistrement de plugins de navigateur, mais avec de simples droits utilisateur on peut extraire cette clé depuis le navigateur et faire à peu près n’importe quoi
    De la même façon, les mécanismes de type « faire confiance à ce navigateur » dans les applications web paraissent étranges si le stockage des cookies est si facile à lire
• On pourrait sans doute faire quelque chose de similaire avec le PAM de Linux. Il suffirait d’attacher gdb au processus de connexion openssh ou getty
• Il y a un lien vers le code source de ce .exe ? J’aimerais voir comment l’extraction est faite
• La vraie erreur, c’est qu’on utilise encore une authentification par simple mot de passe. Il faudrait utiliser du challenge-response ou de l’authentification par clé publique
• Pour être juste, charger en mémoire et y stocker quelque chose, ce n’est pas la même chose
  • Le titre dit « stocke en mémoire », mais pour moi cela revient presque au même. Peux-tu expliquer comment tu vois la différence entre « charger » et « stocker » en mémoire ?
• Corrigez-moi si je me trompe, mais Chrome aussi conservait les mots de passe en texte brut sous Windows, ou en tout cas le faisait autrefois. J’ai déjà récupéré le mot de passe oublié d’un ami depuis une version de Chrome datant de 2021
  • Ça remonte à quelques années, mais je me souviens avoir vu des développeurs de Google argumenter que si quelqu’un a accès au système de fichiers local, tout est déjà perdu
  • Chrome a ajouté en 2024 le chiffrement lié à l’application pour les fichiers de cookies