Lors de la conférence DEF CON 33, une méthode d'attaque sur les extensions de navigateur a été présentée, permettant d'insérer des éléments d'interface dans la page consultée. L'application de cette attaque aux extensions de gestion de mots de passe peut entraîner la fuite d'informations stockées dans ces gestionnaires, telles que les paramètres d'authentification, les informations de cartes de crédit, les données personnelles et les mots de passe à usage unique pour l'authentification à deux facteurs. Le problème concerne tous les gestionnaires de mots de passe testés, y compris 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass et Keeper.
La méthode d'attaque repose sur le fait que les extensions de navigateur intègrent une boîte de dialogue avec une demande de saisie automatique de mot de passe directement sur la page affichée, intégrant ainsi leurs éléments dans le DOM (Document Object Model) de cette page. Si l'attaquant a la possibilité d'exécuter son code JavaScript sur la page, par exemple en exploitant une vulnérabilité XSS sur le site, il peut manipuler tous les éléments du DOM, y compris ceux intégrés par les extensions de navigateur.
Parmi d'autres, il est possible de rendre la boîte de dialogue de confirmation transparente et d'aligner spatialement le bouton dans cette boîte avec le bouton de la boîte de dialogue factice créée par l'attaquant, incitant l'utilisateur à cliquer. Des dialogues factices peuvent consister en de fausses demandes d'autorisation de cookies, des bannières publicitaires ou des formulaires avec CAPTCHA. En plaçant la boîte de dialogue factice sous la boîte de dialogue transparente du gestionnaire de mots de passe et en alignant les emplacements des boutons à l'écran, on peut amener l'utilisateur à cliquer sur le bouton de confirmation pour remplir les paramètres d'authentification dans la boîte de dialogue du gestionnaire de mots de passe, alors que l'utilisateur croira qu'il a cliqué, par exemple, sur le bouton de fermeture de la fenêtre publicitaire.
L'attaque se résume aux étapes suivantes :
- Création d'un élément intrusif sur la page incitant à un clic.
- Ajout d'un formulaire web à la page pour la connexion ou le remplissage de données personnelles.
- Application de transparence pour le formulaire web (« opacity: 0.001 » en CSS).
- Utilisation de la méthode focus() pour mettre le focus sur un champ du formulaire, entraînant l'activation de la boîte de dialogue d'autocomplétion du gestionnaire de mots de passe.
- Recherche de la boîte de dialogue du gestionnaire de mots de passe dans le DOM et application de transparence à celle-ci.
- Attente d'un clic de l'utilisateur sur un élément visible et intrusif de la page, qui, avec une bonne combinaison d'éléments visibles et invisibles, conduira à cliquer sur un bouton dans une boîte de dialogue transparente et à remplir les champs par le gestionnaire de mots de passe.
- Extraction des données d'un formulaire web rempli et envoi de celles-ci sur le serveur de l'attaquant.
Puisque le remplissage automatique des paramètres d'authentification dans le gestionnaire de mots de passe ne s'active que pour les sites sur lesquels ces paramètres ont été enregistrés, pour organiser une attaque, il est nécessaire d'avoir la possibilité d'exécuter son code JavaScript sur le site ciblé ou sur un sous-domaine. Ainsi, pour mener l'attaque, il faut soit obtenir un sous-domaine du même domaine que le site ciblé, soit trouver une vulnérabilité XSS sur le site permettant d'injecter son code dans le contenu affiché à l'utilisateur.
Il est à noter que de nombreux utilisateurs utilisent un seul gestionnaire de mots de passe tant pour stocker les paramètres de connexion que pour générer des mots de passe à usage unique pour l'authentification à deux facteurs, ce qui permet d'appliquer la méthode d'attaque évoquée lors du remplissage automatique des mots de passe à usage unique. Par exemple, une attaque a été démontrée sur le site issuetracker.google.com, contenant une vulnérabilité XSS. Pour obtenir les paramètres de connexion et le code pour l'authentification à deux facteurs, il suffit d'envoyer à l'utilisateur un lien exploitant la vulnérabilité XSS et de provoquer trois clics grâce à des substituts de requêtes intrusives (autorisation du traitement des cookies, autorisation de la personnalisation et acceptation de la politique de confidentialité).
En plus des sites avec des vulnérabilités XSS, l'attaque peut être effectuée sur des services fournissant des sous-domaines à quiconque — la plupart des gestionnaires de mots de passe, dans leur configuration par défaut, remplissent les paramètres de connexion non seulement pour le domaine principal, mais également pour les sous-domaines.
Une attaque peut également être utilisée pour déterminer les données personnelles de l'utilisateur et les paramètres de carte de crédit enregistrés dans le gestionnaire de mots de passe. Pour une fuite de ce type de données, il n'est pas nécessaire d'exécuter du code JavaScript dans le contexte d'un site tiers ; il suffit d'attirer la victime sur la page d'un site de l'attaquant. En ce qui concerne les données personnelles, le remplissage des formulaires web se fait en fonction de leur type (adresse, numéro de carte de crédit, nom complet), sans lien avec un domaine. La fuite des paramètres de carte de crédit est la plus dangereuse, car les gestionnaires de mots de passe remplissent non seulement le numéro de carte, mais aussi la date d'expiration et le code de vérification.
Le chercheur qui a découvert le problème a testé 11 extensions de navigateur avec des gestionnaires de mots de passe, totalisant 39,7 millions d'installations actives, et toutes se sont avérées non protégées contre ce type d'attaque. Certains fabricants ont publié des mises à jour (NordPass 5.13.24, ProtonPass 1.31.6, RoboForm 9.7.6, Dashlane 6.2531.1, Keeper 17.2.0, Enpass 6.11.6, Bitwarden 2025.8.1) qui ont tenté de bloquer l'attaque par des moyens détournés. D'autres extensions (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) n'ont pas encore été corrigées. Un ensemble de pages de test a été publié pour vérifier l'apparition de la vulnérabilité dans différents gestionnaires de mots de passe.
La position des développeurs de 1Password, qui n'ont pas publié de correctif, est que la vulnérabilité est fondamentale et n'est pas directement liée à une extension de navigateur spécifique. Par conséquent, les tentatives de la corriger au niveau de l'extension ne bloquent que certains vecteurs d'attaque, mais ne résolvent pas le problème lui-même, qui doit être abordé dans le navigateur ou par une demande de confirmation distincte avant le remplissage automatique des champs. Il est mentionné que 1Password prend déjà en charge l'affichage d'une demande de confirmation avant le remplissage automatique des paramètres de paiement, et qu'une option pour afficher une telle demande pour tous les types de données à remplir automatiquement sera ajoutée dans la prochaine version (en raison d'une diminution de la commodité d'utilisation, cette option ne sera pas activée par défaut).
Parmi les méthodes de protection proposées par l'auteur de l'étude, on mentionne le suivi des modifications de style des éléments insérés sur la page à l'aide de l'API MutationObserver, le blocage des modifications via le Shadow DOM en mode « closed », la surveillance de la transparence des éléments, l'utilisation de l'API Popover pour afficher des dialogues, la vérification des superpositions de couches et la désactivation temporaire du traitement des événements de pointeur (pointer-events:none) sur tous les éléments flottants lors de l'affichage du dialogue du gestionnaire de mots de passe. Ainsi, pour bloquer complètement cette classe décrite. des attaques, il est recommandé de mettre en œuvre un API distinct au niveau du navigateur pour la protection. contre le clickjacking.
Comme méthode universelle de protection dans les navigateurs basés sur le moteur Chromium, les utilisateurs sont invités à activer le mode de confirmation d'accès des extensions au site (Paramètres des extensions → « accès au site » → « au clic »), où l'extension n'obtient l'accès au site qu'après un clic sur l'icône à droite de la barre d'adresse. Comme solution de contournement pour la protection, il est également mentionné de désactiver le remplissage automatique des formulaires et de copier les mots de passe manuellement via le presse-papiers, mais cela pose le problème des fuites de données depuis le presse-papiers partagé et le risque de passer à côté des tentatives de phishing.
Source : opennet.ru
