La vulnérabilité a été découverte par Tavis Ormandy, chercheur en sécurité membre du programme Project Zero de Google.
Elle résidait dans l’extension pour les navigateurs. Celle-ci, plutôt que d’utiliser la méthode do_popupregister(), se servait de la dernière valeur en cache, via ftd_get_frameparenturl().
Il devenait en théorie possible pour un site frauduleux de créer un iframe lié au fichier popupfilltab.html de LastPass et d’y afficher le dernier mot de passe utilisé. La faille a été signalée confidentiellement à LastPass, qui l’a rapidement corrigée.
Dans un billet publié vendredi, l’éditeur explique qu’il fallait un lot de circonstances bien particulier pour exploiter la brèche, limitant son impact potentiel. Il dit ne pas être au courant d’une quelconque exploitation. Les détails, eux, ont été publiés dimanche par Ormandy.
Une nouvelle version 4.33 de LastPass a été distribuée à l’ensemble des boutiques d’extensions pour les navigateurs. Mieux vaut donc contrôler que vous êtes à jour, même si les extensions sont en théorie automatiquement remplacées quand une nouvelle version est publiée. Les applications mobiles ne sont pas concernées.
Rappelons que les gestionnaires de mots de passe sont des outils pratiques, mais ne représentent pas l’alpha et l’oméga de la sécurité. Ils permettent de stocker des centaines ou milliers de mots de passe, de créer de longues séquences aléatoires de caractères, tout en les rendant disponibles sur presque toutes les plateformes.
Mais en cas de problème de sécurité, cette base de données est en danger. Les mots de passe ne suffisent plus depuis longtemps. Sans remettre en cause ces outils bien pratiques, nous vous conseillons d’activer une protection supplémentaire comme l’authentification à deux facteurs, partout où c’est possible.
Commentaires (36)
#1
Ironique vu le nom de l’outil
" />
#2
C’était documenté de longue date, en effet
" />
#3
Je me pose une question, est-il possible qu’un site se fasse passer pour un autre aux yeux du gestionnaire de mot de passe ?
Pour un humain, il est possible de faire passer faceboook.com pour le site officiel, mais pour un programme, comment ça se passe ? avec un DNS menteur ?
Je pose la question parce que les gestionnaires de mdp se basent sur le nom de domaine renseigné pour remplir automatiquement les champs id/mdp sur le navigateur.
#4
Celà s’appuie, en général, sur l’url. Donc à moins que le site officiel oubli de renouveler son nom de domaine, on devrait être tranquille.
Ensuite, oui un DNS menteur pourrait du coup te faire rediriger vers une copie… mais si la copie est bien faite, gestionnaire ou non, la personne se fait avoir…
#5
Après il faut que tu ton serveur DNS soit compromis, faut y aller quand même ;)
ou un virus qui puisse modifier ton fichier HOST encore, c’est d’ailleurs je pense plus probable.
#6
Se7en474 a écrit :
Je me pose une question, est-il possible qu’un site se fasse passer pour un autre aux yeux du gestionnaire de mot de passe ?
Pour un humain, il est possible de faire passer faceboook.com pour le site officiel, mais pour un programme, comment ça se passe ? avec un DNS menteur ?
Je pose la question parce que les gestionnaires de mdp se basent sur le nom de domaine renseigné pour remplir automatiquement les champs id/mdp sur le navigateur.
Un DNS menteur pourrait tenter de rediriger vers un faux site, mais normalement la connexion au formulaire se fait en https. J’espère ne pas dire de bêtise, mais mon gestionnaire de mot de passe ne remplit pas les champs sur un site http si on les a enregistrés avec du https (ie, le protocole fait partie de la reconnaissance du site). Cela signifie:
Donc oui, en théorie c’est possible d’utiliser un DNS menteur, mais c’est de plus en plus compliqué avec les initiatives actuelles pour répandre le https.
#7
Et on peut aussi ajouter qu’avec le HSTS le propriétaire d’un site peut faire en sorte que l’accès en HTTP soit interdit, même si l’utilisateur tape vers un serveur différent à cause d’un DNS menteur.
Le HSTS peut empêcher :
Il faut par contre que l’utilisateur soit allé au moins une fois sur le site légitime pour que son navigateur ait enregistré la politique HSTS du site (il y a aussi une liste de sites pour lesquels la politique HSTS est péchargée par le navigateur).
#8
C’est pour ca qu’il ne faut jamais activer le remplissage automatique des mots de passe.
#9
Ne jamais utiliser ce genre de gestionnaire, c’est juste la base… et toujours désactiver les mises à jours des modules par défaut… c’est un poil contraignant mais au moins on évite la plupart des merdes de ce genre.
Je viens de vérifier et sur mon Firefox ils ont fait un petit bordel d’ailleurs avec 1 choix inutile en menu pour choisir l’automatisme de ces mises à jour… à corriger !
#10
Les mots de passe ne suffisent plus depuis longtemps. Sans remettre en cause ces outils bien pratiques, nous vous conseillons d’activer une protection supplémentaire comme l’authentification à deux facteurs, partout où c’est possible.
Bah l’intérêt de ces outils est d’avoir un mdp complexe et différent sur chaque site.
Pour le double facteur rien ne permet de prédire si c’est réellement sécurisé : comment sont générés les codes de validations ? L’envoi de SMS est fiable ?
=> Bref faut faire confiance au site ET aux intermédiaires techniques.
=> si c’est par SMS je ne vois pas bien l’intérêt tu perds (on te vole) ton tel tu perds les deux facteurs d’un coup
Moi je dirais l’inverse, par sa complexité le double facteur donne une fausse impression de sécurité, les gens auront tendance à mettre un mot de passe plus simple en se pensant protéger par ce foutu code par SMS.
Là ou je vous rejoins est que le gestionnaire de mot de passe ne doit être ni cloudé, ni une extension de navigateur : c’est de la connerie pure et simple :)
Un bon vieux keepass + le gestionnaire de mot de passe du navigateur aura moins de risque (le gestionnaire du navigateur est plus bas niveau, donc plus difficile à berner). Un keepass peut facilement être synchronisé via un cloud si besoin.
#11
#12
Keepass sait copier/Coller directement dans le formulaire et le valider.
Il suffit de faire ctrl+v sur l’entrée concernée.
#13
J’étais hautement sarcastique :p
J’adore Keepass pour ça : simple, gratuit (merci les devs !), et je choisis de “clouder” mes mots de passe ou non.
Keepass + Cerveau c’est un bon combo ^^
#14
Même punition, si tu as du DNS spoofing et que le site du pirate est bien fait (au moins pour la partie authentification), tu ne vas pas t’en rendre compte et tu vas y mettre ton mot de passe, même en manuel. Dans ce cas, remplissage automatique ou pas, pas de différence.
Pour les sites important, le mieux reste la double authentification, pour peu que le site l’autorise.
#15
En réalité, un DNS menteur est très compliqué a mettre en œuvre.
Par contre, un man in the midle sur un routeur wifi public, c’est déjà bien plus simple. Et lui peut faire ce qu’il veut avec le DNS qu’il va te retourner, ainsi qu’avec les certificats qu’il va associer aux sites en question.
#16
Lastpass est un très bon outil. Keypass aussi, lui aussi à eu son lot de faille.
Les mots de passes ne sont décrypté qu’en mémoire sur ton poste, comme Keypass. Le serveur ne peut pas décrypter les passe sans ton mot de passe maître, si tu le perds, tu ne peux plus le récupérer. Comme pour un Keepass.
Le principale avantage est la possibilité de partager des passes entre en groupe d’utilisateurs, ce que keepass ne sait pas vraiment faire, sauf à tout partager y compris le mot de passe maître. Hors, en entreprise, c’est pas top.
#17
config DNS manuelle, en passant par du DNS over TLS, surtout ne pas utiliser le DNS retourné par le routeur wifi ou le FAI
#18
#19
Il n’y’a pas de pb majeur avec le cloud, tu peux utiliser un cloud publique (drobbox, onedrive…), un simple NAS dispo sur le net voir un hébergement web.
Le pb de lastpass est qu’on parle d’une solution fermée, où l’éditeur gère à la fois le logiciel et le cloud.
Tu peux croire que tout est propre (chiffrement en local, non-connaissance de la clé de déchiffrement…)
=> c’est la parole de LastPass aucun moyen de le vérifier
Demain LastPass subit une pression d’un état quelquonque, ce sera toujours propre ?
N’importe qui peut faire une OPA discrète sur LogMeIn, que deviendront les bonnes paroles de LastPass ? Qui se rendra compte de la supercherie ?
Si LastPass se fait hacker c’est le cloud où sont stockés les bases ET le déploiement du logiciel.
#20
la différence et que tu vas saisir ton mot de passe, l’attaque ici est invisible une iframe masquée quelquepart peut récupérer le mot de passe d’un site en cours de navigation.
#21
OK
#22
J’avais compris le ton, mais comme tu parlais du double clic sur l’entrée (qui est une méthode aussi), j’indiquais le ctrl+v qui est aussi disponible dessus
" />
" />
Seule fois où j’ai rencontré un souci, c’est lorsqu’il colle sur un navigateur qui est dans une session XRDP. Il se retrouvait en qwerty par je ne sais quel truchement.
Mais bon, je pense que c’est un peu trop rare comme cas.
#23
Il est impossible de faire un man in the middle sur du HTTPS sans accès à la machine pour trafiquer les certificats. (c’est l’essence même du SSL)
Ça devient d’ailleurs compliqué de se connecter dans les hôtels, vu que la page de connexion est en fait un man in the middle, tu tapes google.fr ton navigateur vas chercher httpS://www.google.fr : c’est le routeur qui te réponds avec une page de connexion est un certificat erroné, la page de connexion n’est même pas affichée par ton navigateur qui détecte le MITM. La seule façon est d’avoir en favoris une adresse HTTP uniquement http://perdu.com) pour pouvoir accepter le cluff de l’hôtel avant de naviguer tranquillement où tu veux.
#24
En entreprise on utilisera un Vault qui est spécifiquement conçu pour gérer les secrets (mots de passes applicatifs, bdd, tokens diverses, etc) et administré avec une ACL très fine.
Et lorsqu’il s’agit de sessions interactives, un PAM associé à ce coffre fort est de rigueur.
C’est ce dernier qui se charge généralement de récupérer le mot de passe et de le soumettre à l’appli, l’utilisateur n’a même pas à le connaître.
#25
Les failles de KeePass ne sont exploitables que sur le PC : il faut avoir d’abord hacké le PC cible avant de d’exploiter les éventuelles failles de KeePass.
Pour LastPass surfer sur le mauvais site peut suffire à se faire pirater un mot de passe.
#26
En entreprise on active surtout le SSO, pour supprimer les mots de passe inutiles :)
Ta session OS est en double facteur (badge + mot de passe ou empreinte), une fois ouverte les applications t’authentifient automatiquement via SAML2 / OAUTH voir certificats.
Le pb des RSSI c’est que c’est en général le placard d’une fin de carrière d’incompétences. N’y connaissant rien en technique, la plupart raisonne en risque juridique pour leur peau : il suffit de menacer de sanction les employés pour sécuriser un réseau.
#27
Oui effectivement c’est le SSO qui devrait être de rigueur pour la partie utilisateur.
" />
Malheureusement, je n’en ai pas encore vu de manière suffisamment répandue ou insuffisamment mise en place. Du genre l’appli va te rediriger vers le portail SSO et non te connecter de manière transparente.
#28
Je ne suis pas admin réseau, mais il me semble que c’est obligatoire dans les audits sécurités, il faut pouvoir justifier pourquoi le SSO n’a pas été mis en place.
Je l’ai ms e place sur du SAP avec Office365 : c’est absolument invisible : tu lances Fiori dans ton navigateur t’es connecté immédiatement.
En analysant le réseau il y’a effectivement une redirection vers login.microsoft qui trouve un cookie qui traine (d’outlook, de word ou toute autre appli utilisant le SSO) et authentifie immédiatement SAP.
En fait la seule page de connexion que tu peux voir c’est la première appli SSOisé lancé le matin et uniquement si tu as décocher “Rester connecter” dans la page login de Microsoft.
Dans tous les autres cas c’est invisible t’es juste magiquement connecté partout :)
#29
Je ne saurais dire, ce n’est pas un aspect sur lequel je travaille principalement puisque je suis plutôt client de ces solutions.
" />
J’intègre des progiciels (développés en “interne” via société de service, ou produit du marché) dans le SI du client, donc je fais malheureusement avec ce qu’il propose.
Néanmoins, cela se répand de plus en plus, sous pression des différents pôles sécu justement.
Le pire étant quand tu dois composer avec un progiciel du marché dont la notion de sécurité est totalement inexistante. Mais que le client utilise ça depuis des lustres donc fais avec.
Néanmoins il est regrettable d’avoir attendu le RGPD pour en avoir vu bouger… Il n’y a même pas deux ans dans une boîte, demander une ouverture de flux non sécurisé passait encore comme une lettre à la poste. Là où d’autres c’était niet d’office, et demerden sie sich pour sécuriser l’appli.
Les rares exceptions que je vois passer sont plutôt causées par des cas de matériels obsolètes (terminaux mobiles utilisés en entrepôt par exemple, sous Windows CE datant de l’Atlantide) qui ne savent pas gérer des protocoles chiffrés récents. Vu qu’ils sont remplacés progressivement par de l’Android ou autre, ça va aussi heureusement disparaître.
#30
Mieux, un bon vieux VPN de confiance.
#31
Ce n’est vrai que si le poste de l’utilisateur dispose déjà du certificat. Si tu vas vers un site qui t’es inconnu, tu ne peux pas être sûr du certificat retourné par le routeur qui est ta seule communication avec l’extérieur. Il n’est pas, pour cela, nécessaire d’installer un certificat maître.
Par contre, on peut potentiellement s’en rendre compte lors d’une connexion faîte ailleurs. Le mieux reste d’utiliser systématiquement un VPN de confiance (oui, parce qu’en terme de man in the middle, le VPN, c’est un must).
#32
Si toutes les entreprises utilisaient toutes les mêmes protections, on aurait un beau problème de protection. Non, toutes les entreprises ne fonctionnent pas ainsi, en fait, dans les PME qui sont la majorité des entreprises, ce n’est pas le cas.
Et dans cette majorité d’entreprise, un outil comme Lastpass reste bien mieux qu’un fichier excel. Et oui, j’ai déjà rencontré des entreprises qui “sécurisaient” leurs accès dans un fichier Excel… J’ai même vu des entreprises qui le faisaient dans un fichier google sheet.
#33
Pour keypass, en effet, il faut être sur le poste pour exploiter la faille. Comme pour Lastpass qui ne décrypte les données qu’en mémoire sur le poste.
Dans tous les cas (ta mémoire humaine, Keypass, Lastpass, Dashlan et autres), si tu va sur un site suite à un lien de poissonage et que tu mets tes identifiants, ils seront volés. Aucun gestionnaires de mots de passe ne te permetra d’y couper.
#34
#35
Je suis confondu par le niveau de l’argumentation. Devant un tel déploiement d’élément, je ne peux que m’incliner.
#36
Il a pourtant raison.
Le certificat utilisé lorsqu’une connexion TLS est signé par le fournisseur du certificat et est vérifiable par une chaîne de certificats signés à partir d’un certificat racine connu (par construction) par les navigateurs.
Le navigateur vérifie la chaîne de certificat ce qui lui permet de vérifier que le certificat fourni par le site est bon.
Et il t’explique que pour ne pas être détecté comme mauvais, le certificat fourni doit être signé par un certificat racine qui aura été ajouté aux certificats racines légitimes (ce qu’il appelle trafiquer) mais que pour cela, il faut avoir accès à la machine pour ajouter ledit certificat.