Piratage de LastPass : la situation en trois points
On en sait davantage sur le piratage de LastPass. Que s'est-il passé, quelles données ont filtré et que faire ?
Quelles causes, quels effets et quelles suites ? Pour ce qui est du piratage de LastPass, on en sait un peu plus depuis la semaine dernière. Le point en trois questions.
Que s'est-il passé ?
LastPass distingue deux incidents, le premier ayant posé les bases du second.
À l'origine, il y a une alerte de sécurité le 12 août 2022. Motif : une activité suspecte dans un environnement de développement cloud utilisé en préprod. Cela fait alors quatre jours qu'elle dure, à l'appui de la compromission de l'ordinateur portable d'un développeur.
LastPass affirme aujourd'hui encore ne pas connaître le vecteur initial d'intrusion. Entre autres parce qu'une mise à jour système, planifiée pendant l'incident, a écrasé des journaux et d'autres pièces à conviction.
Lire aussi : Six enseignements clés sur les mots de passe tirés de la mise à jour du cadre de cybersécurité du NIST
L'EDR sur le poste de travail a été manipulé et n'a pas déclenché d'alerte. En usurpant l'identité du développeur en question, l'attaquant a pu se connecter à l'environnement cloud sans élévation de privilèges. Il a pu exfiltrer 14 dépôts de code source. Des scripts issus de ces dépôts contenaient des secrets et des certificats. Dont certains stockés en clair. (pour les autres, il fallait une clé qui n'était pas accessible au développeur).
Une faille logicielle... et un keylogger
Les éléments dérobés ont pu être utilisés avant que LastPass les réinitialise. Ils ont permis d'identifier des cibles. Parmi elles, un ingénieur DevOps dont l'ordinateur domestique a constitué le point d'entrée de la deuxième phase d'attaque.
Une vulnérabilité dans un « paquet logiciel média » a permis de déployer un keylogger. Et ainsi de récupérer le mot de passe maître après que l'ingénieur se fut authentifié par MFA. Cela a ouvert la porte à son « coffre-fort corporate ». Lequel contenait les clés nécessaires pour accéder aux compartiments S3 hébergeant des backups de prod et déchiffrer.
Le service de détection des menaces AWS GuardDuty a fini par signaler un comportement anormal. En l'occurrence, lorsque l'attaquant, usurpant l'identité de sa victime, a tenté d'utiliser les rôles IAM à des fins non autorisées.
Quelles données ont filtré ?
Le deuxième incident a exposé trois grandes catégories de données :
- Secrets et clés d'API
- Informations relatives aux clients
- Coffres-forts des clients
Lire aussi : Sécurisation des identifiants et protection contre les attaques par déplacement latéral
Secrets et clés d'API
Les clients de l'offre LastPass Business recourant à leur propre fournisseur d'identité (service de fédération) sont a priori moins exposés. Une partie de la « clé » vers les coffres-forts des utilisateurs finaux se trouve effectivement chez ce fournisseur et non chez LastPass.
Dans les grandes lignes, les utilisateurs finaux n'ont pas de mot de passe maître à saisir. Celui-ci est « caché », assemblé à partir de deux ou trois fragments aléatoires stockés séparément. L'un de ces fragments se trouve, donc, chez le fournisseur d'identité.
Pour les autres, c'est plus compliqué. LastPass a pu invalider certains des éléments qui ont filtré, dont les hashs des jetons TOTP (temporaires, à usage unique) et rOTP (permanents, de récupération). Il n'a pas, en revanche, la main sur d'autres, comme les clés d'intégration d'annuaires tiers ou les authentifiants éventuellement « poussés » vers les utilisateurs ou les groupes par les administrateurs.
Informations relatives aux clients
Le backup que l'attaquant a pu copier contenait de multiples éléments en clair. En particulier :
- Noms des entreprises, numéros fiscaux, adresses de facturation
- Noms et adresses e-mails des utilisateurs
- Adresses IP d'appareils de confiance
- Numéros de téléphone pour la récupération par SMS
- Identifiant unique des appareils mobiles utilisés pour accéder à LastPass
- Nombre d'itérations PBKDF2 (cet indicateur peut être important ; nous y reviendrons)
Données des coffres-forts
Le base de données hébergeant les coffres-forts est divisée en de multiples partitions (shards). Les informations sont agrégées dans un format sérialisé avant d'être communiquées aux clients LastPass, qui les décodent et les déchiffrent avec une clé dérivée du mot de passe maître.
Les structures ainsi stockées ne sont pas chiffrées, mais certains des champs qu'elles contiennent le sont (en AES-256). Au dernier pointage, c'est le cas pour 23 d'entre eux. Dont l'essentiel (21) peuvent être considérés comme critiques. Parmi eux, les logins/mots de passe enregistrés dans le coffre-fort, les clés de chiffrement des pièces jointes ajoutées aux notes sécurisées et les chemins d'installation des applications LastPass (Windows, Mac).
L'attaquant a pu récupérer, entre le 8 et le 22 septembre, cinq des partitions de la base de données, datés du 20 août au 16 septembre.
Que faire ?
Ce que LastPass a entrepris
À l'issue du premier incident, LastPass a pris des mesures parmi lesquelles :
- Déployer un EDR supplémentaire
- Ajouter des contrôles de sécurité sur les laptops et affiner la journalisation
- Déployer une solution SASE et remplacer son accès VPN par du zero-trust
- Installer des canaris (déclinaison du pot de miel) dans ses environnements de dev et de prod
À l'issue du deuxième incident :
- Activer, dans le nouvel environnement de dev, une stratégie empêchant la création d'utilisateurs IAM à long terme
- Durcir les restrictions fondées sur les adresses IP
- Activer l'étiquetage systématique des ressources IAM, avec un reporting de conformité régulier
Ce que LastPass conseille aux entreprises
Longueur et complexité des mots de passe
On définira une stratégie qui n'accepte pas les mots de passe de moins de 12 caractères (longueur recommandée : 16 à 20) et exige au moins deux types de caractères (voire trois). Un mot d'ordre : « La longueur l'emporte sur la complexité ».
On définira aussi de quoi détecter lorsqu'un mot de passe stocké dans un coffre-fort est utilisé comme mot de passe maître. Et de quoi empêcher d'utiliser un ancien mot de passe (Microsoft, par exemple, conseille de bloquer les 24 derniers mots de passe Active Directory).
Randomisation du mot de passe maître
Pour compliquer les attaques par force brute, LastPass utilise la fameuse fonction PBKDF2. Cette fonction de hachage qui génère une clé à partir du mot de passe maître. Plus on la répète, plus la clé est robuste, en théorie.
En janvier, l'OWASP (Open Web Application Security Project) a mis à jour ses recommandations en la matière. Il conseille désormais 600 000 itérations au minimum.
Sur LastPass, depuis 2019, la valeur par défaut est de 100 100 itérations. En l'état, la seule façon de modifier ce paramètre est de le configurer manuellement pour chaque coffre-fort. Dans les prochaines semaines, promet LastPass, une stratégie fera son apparition dans la console d'admin. En parallèle, le compteur sera par défaut à 600 000 itérations pour tous les nouveaux utilisateurs.
Bonnes pratiques pour les superadministrateurs
Un message : assurez-vous que ces populations respectent les bonnes pratiques de définition de leurs mots de passe.
Si ce n'est pas le cas et que les superadmins sont autorisés à réinitialiser les mots de passe, on envisagera :
- Pour ceux qui l'ont activée, de réinitialiser la fédération des utilisateurs, puis de leur demander de modifier leurs authentifiants
- Pour les « non fédérés », tout simplement de réinitialiser les authentifiants des utilisateurs
On vérifiera aussi les droits d'accès dont ces superadmins disposent sur les dossiers partagés. Et en fonction des risques, on changera les authentifiants de ces dossiers.
Secrets MFA partagés
Ce conseil s'applique aux utilisateurs « non fédérés » qui ont activé le MFA sur les coffres-forts. LastPass suggère de réinitialiser ces secrets, peu importe l'application d'authentification utilisée.
Pour les utilisateurs de Duo Security, Symantec VIP, RSA SecurID ou SecureAuth, il faudra regénérer les secrets directement dans ces solutions et les ajouter dans la console d'admin LastPass.
Intégration avec Splunk
Pour qui a fait la connexion avec ce SIEM, il faut réinitialiser les jetons d'instance. À défaut, ce sera fait automatiquement le 30 avril 2023.
Exposition de données non chiffrées
Les données exfiltrées, notamment au niveau des URL, pourraient permettre des actions de phishing, de social engineering, etc. On fera donc preuve de vigilance, quitte à communiquer auprès des utilisateurs de LastPass.
Photo d'illustration © Meghna - Adobe Stock
Sur le même thème
Voir tous les articles Cybersécurité