Blog: Troisième piratage de LastPass

Auteur: Vlad
Publié le

Patrowl's blog - Troisième piratage de LastPass

Mise à jour 06/01/2022 : SSO, comment cela fonctionne avec LastPass et comment vérifier sur Azure

LastPass a été piraté pour la 6ème fois (3ème fois cette année) et cette fois vos secrets sont dévoilés !

(Non, pas vraiment 😉 )

LastPass est un coffre-fort de mots de passe en ligne, dans le cloud, hébergé par la société éponyme. L'idée est bonne : vous avez un seul endroit pour stocker vos mots de passe, accessible de partout et, en théorie, sécurisée. Cela vous permet d'avoir des mots de passe différents pour chaque site web et tous très forts (longs et aléatoires). Enfin, si vous suivez vraiment toutes les bonnes pratiques 😉 .

Normalement, un coffre-fort de mots de passe sécurisé nécessite un secret (une clé/mot de passe maître) pour déverrouiller (décrypter) tous les autres mots de passe. Par conséquent, l'éditeur du coffre-fort à mots de passe ne connaît pas vos secrets. Notez que puisque vous entrez votre mot de passe (ou clé maîtresse) sur le portail LastPass, en réalité ils l'ont, c'est juste qu'en théorie, ils ne l'enregistrent pas 😉. Si un attaquant parvient à injecter du JavaScript dans la page web de LastPass (ou de tout autre coffre-fort en ligne), il disposera de votre clé maître.

LastPass et la cybersécurité

Ces dernières années :

Août 2022, piratage d'un développeur de LastPass et vol de code source et d'informations sur les développeurs, mais pas sur les clients https://blog.lastpass.com/2022/12/notice-of-recent-security-incident/ . LastPass a fait savoir qu'aucune donnée client n'avait été volée et que tout allait bien "Move on, nothing to see".

Novembre 2022, intrusion dans LastPass grâce aux informations récupérées en août mais pas d'accès aux données des clients. De plus, la maison mère de LastPass, la société "Go to" avait publié un communiqué de presse qu'elle avait rendu "désindexable" pour empêcher les moteurs de recherche de l'indexer et ainsi éviter le bad buzz. C'est ce que l'on voit ici avec les métadonnées "noindex" :

Patrowl's blog - Troisième piratage de LastPass

view-source:https://web.archive.org/web/20221130211551/https://www.goto.com/blog/our-response-to-a-recent-security-incident Dans ce communiqué de presse, il est indiqué que les données des clients n'ont toujours pas été consultées <<Déplacez-vous, il n'y a toujours rien à voir>>.

Décembre 2022, fuite de sauvegardes de coffres-forts de mots de passe d'utilisateurs stockés sur un stockage en ligne (cloud). Ces sauvegardes contiennent :

  • Les noms des entreprises et/ou des utilisateurs, en clair ;
  • Les informations de facturation, y compris les adresses, en clair ;
  • Des courriels, des numéros de téléphone, des adresses IP de connexion, etc ;
  • les voûtes avec :
    • Informations générales (noms de sites, adresses web/URL, etc.), en clair,
    • Informations secrètes (mots de passe, notes, etc.), cryptées.

Le communiqué de presse : https://blog.lastpass.com/2022/12/notice-of-recent-security-incident/

Risque ?

Si vous êtes client de LastPass, les attaquants disposent de vos informations personnelles et des URL des sites dont vous stockez les mots de passe dans LastPass. Mais pas de panique ! Vos mots de passe sont (en théorie 😉 ) cryptés avec une clé, dérivée de votre clé principale par PBKDF2. Cet algorithme va effectuer plusieurs rotations (itération) afin de rendre l'obtention de la clé utilisée très lente. Cela donnerait : MySecret -rotation-> $D_è2 "to -rotation-> %M0"_$ -...-> La vraie clé utilisée pour chiffrer/déchiffrer D'après ce que j'ai lu, il y aurait 100 100 rotations (itérations). Cela rend donc l'opération très lente, plusieurs centaines de millisecondes. Le but est de limiter les attaques par dictionnaire ou exhaustives (brute force). Par exemple, avec la grosse machine que nous utilisons pour craquer les mots de passe, nous ne sommes pas capables de craquer un mot de passe de plus de 8 caractères, protégé par PBKDF2 (avec AES256) si nous testons toutes les possibilités (https://patrowl.io/casser-des-condensats-de-mots-de-passe-sans-violence/). Par contre, à partir d'un dictionnaire, cela prend entre 1 et 5 jours.

Si un attaquant veut décrypter votre coffre-fort, il sera plus enclin à utiliser les mots de passe qu'il a déjà pour vous (trouvés dans d'autres fuites de données) et donc potentiellement un dictionnaire.

Le risque est limité sauf si :

  • Votre clé principale est utilisée ailleurs ;
  • Vous avez une clé principale de moins de 8 caractères.

D'autre part, les attaquants vont sûrement mener des attaques initiales sur ces coffres, en casser une partie puis revendre cette fuite de données à d'autres, qui feront de même puis revendront ou donneront les données... et cela finira par se produire sur des forums comme breached.co ou d'autres et tout le monde y aura accès.

Je n'entrerai pas dans les détails ici, mais avec votre nom, votre email, votre numéro de téléphone, un attaquant peut mener plusieurs types d'attaques allant du phishing aux tentatives de contourner votre authentification forte via le "SIM Swapping" (https://patrowl.io/lauthentication-forte-cest-bien-quand-elle-est-securisee-cest-mieux/).

Que faire ?

Ne pas paniquer

Comme je l'ai dit : pas de panique 😉

Patrowl's blog - Troisième piratage de LastPass

Changer de fournisseur de coffre-fort (de LastPass à un autre) n'a pas vraiment de sens à moins de vouloir s'héberger soi-même car aujourd'hui, c'est LastPass qui est piraté, mais demain ? D'ailleurs, savez-vous si les autres n'ont pas déjà été piratés ?

A votre place, je ferais une communication simple et rassurante pour expliquer le problème.

Je suggérerais la démarche suivante :

  • Je demanderais à ceux qui ont un passe-partout faible ou utilisé ailleurs de prévoir (en leur faisant confiance...) :
    • Rapidement (dans les 5 jours), un changement de tous les mots de passe associés aux comptes sans authentification forte,
    • En janvier, un changement de tous les mots de passe.
  • Je demande à ceux qui ont une clé maîtresse forte de prévoir un changement progressif de tous les mots de passe stockés dans LastPass, dans un délai de 6 mois (voir ci-dessous).

SSO

Le diagramme ci-dessous décrit le fonctionnement du SSO avec LastPass :

Patrowl's blog - Troisième piratage de LastPass

Voici les détails pour Microsoft Azure mais j'imagine que c'est assez similaire avec d'autres fournisseurs d'identité.

Pour chaque compte utilisateur, un attribut étendu est ajouté contenant un secret K1 de 44 caractères aléatoires (j'espère 😉 ) mélangeant minuscules, majuscules, chiffres et caractères spéciaux.

Cet attribut ne peut être consulté qu'en tant qu'administrateur de Microsoft Graph avec une requête de ce type :

https://graph.microsoft.com/v1.0/users/prenom.nom@entreprise.com?$select=id,displayName,mail,mobilePhone&$expand=extensions.

Le résultat ressemblera à ceci, avec l'extension LastPass qui peut être trouvée avec son id "com.lastpass.keys" et contenant la clé K1 dans "LastPassK1" (avec des valeurs anonymisées 😉 ) :

{
    "@odate.context" : "https://graph.microsoft.com/v1.0/users/$metadata#users(id,displayName, mail,mobilePhone,extensions())/$entity",
    "id" : "9ac4e0f4-5477-4198-a1e8-81029e149be9",
    "displayName" : "Bob Smith",
    "mail" : "bob.smith@company.com",
    "mobilePhone" : "+33123456789",
    "extensions@odate.context" : "https://graph.microsoft.com/v1.0/$metadata#users('9ac4e0f4-5477-4198-a1e8-81029e149be9')/extensions",
    "extensions" : [
        {
            "@odate.type" : "#microsoft.graph.openTypeExtension",
            "extensionName" : "com.lastpass.keys",
            "LastPassK1" : "*** clef secrete k1 ***", // <---- la clef K1
            "id" : "com.lastpass.keys"
        }
    ]
}

Un second secret K2 est stocké chez LastPass, ailleurs que là où se trouvaient les coffres volés... je l'espère 😉 . Les 2 secrets sont combinés, itérés (voir ci-dessous avec PBKDF2) et le résultat est la clé pour déchiffrer le coffre. La combinaison se fait de la manière suivante : Base64( SHA256( K1 xor K2 )) Les explications sont ici (pages 12 et 13 pour Azure) : https://support.lastpass.com/download/lastpass-technical-whitepaper

Pourquoi 2 secrets ? Peut-être pour éviter une compromission du coffre-fort en cas de compromission d'un compte Azure, d'un compte administrateur Azure ou de LastPass, car pour cela, il faudrait alors pirater à la fois Azure et LastPass.

Pourquoi changer dans 6 mois ?

Il est défini au hasard mais il y a des chances que d'ici là, les coffres-forts aient cédé et/ou aient atterri sur plusieurs places de marché. De plus, les bonnes pratiques en matière de mots de passe recommandent désormais des mots de passe très longs avec un cycle de vie long également 😉. Ceci afin d'éviter les fameux changements tous les 30 jours avec des utilisateurs qui ne font qu'incrémenter un chiffre à la fin : Toto1, Toto2, Toto3....

Je recommande le guide de l'ANSSI : << Pour les comptes peu sensibles, imposer un délai d'expiration trop court (3 à 6 mois par exemple) peut s'avérer contre-productif>>, page 30 https://www.ssi.gouv.fr/guide/recommandations-relatives-a-lauthentication-multifactor-and-aux-mots-de-passe/.

Les délais recommandés sont les suivants :

  • Comptes non sensibles, pas de limite mais je recommanderais tout de même un maximum de 2 ans (Guide ANSSI page 30, R24).
  • Comptes à privilèges, durée entre 1 et 3 ans (Guide ANSSI page 30, R25).

Et surtout, il faut utiliser un deuxième facteur d'authentification comme un code à usage unique (OTP), une notification sur le smartphone... ( https://patrowl.io/lauthentification-forte-cest-bien-quand-elle-est-securisee-cest-mieux/)

Disons 6 mois, pour changer de mot de passe, cela peut rentrer dans le cycle de vie défini plus haut 😉. Sachant que changer de mot de passe est contraignant car aucun site ne propose la même interface, le même système ou une API standardisée.

Bon courage à vous et joyeux Noël 😉 .

Blog: On voulait parler des attaques cyber pendant les JO mais on n'a rien à dire

Levée de 11 M€ pour Patrowl en série A : Vers une protection continue des actifs numériques

Blog: RegreSSHion, critical vulnerability on OpenSSH CVE-2024-6387