1Password détecte une « activité suspecte » dans son compte Okta interne
(arstechnica.com)- 1Password a détecté le 29 septembre une activité suspecte dans son instance Okta interne, utilisée pour gérer l’accès des employés aux applications, et n’a constaté aucune compromission des données utilisateur ni de systèmes sensibles
- Cet accès était lié à la compromission du système de gestion du support client d’Okta, et l’attaquant a pu obtenir des cookies d’authentification et des jetons de session à partir de fichiers HAR téléversés par des clients
- Un rapport Notion interne de 1Password indique que l’attaquant a récupéré un fichier HAR créé par un employé IT alors qu’il travaillait avec le support Okta, et que ce fichier contenait du trafic Okta ainsi que des cookies de session
- Dans le tenant Okta de 1Password, l’attaquant a demandé un rapport sur les utilisateurs administrateurs et a mis à jour puis activé l’IDP utilisé pour l’authentification de l’environnement de production Google, mais une tentative ultérieure de réutilisation a échoué car l’IDP avait été supprimé
- La compromission d’Okta est devenue un exemple d’attaque en aval, où l’intrusion chez un fournisseur mène à des attaques contre ses clients, et 1Password est devenu le deuxième client Okta connu à avoir été ciblé
Détection d’un accès Okta interne chez 1Password
- 1Password est un gestionnaire de mots de passe utilisé par des millions d’utilisateurs et plus de 100 000 entreprises
- L’entreprise a constaté le 29 septembre une activité suspecte dans l’instance Okta qu’elle utilise pour gérer les applications destinées aux employés
- Le CTO Pedro Canahuati a déclaré que cette activité avait été immédiatement stoppée et examinée, et qu’aucune compromission des données utilisateur ni des systèmes sensibles destinés aux employés ou aux utilisateurs n’avait été constatée
- 1Password a ensuite enquêté avec Okta sur la manière dont un attaquant inconnu avait accédé au compte
Compromission du système de support Okta et risques liés aux fichiers HAR
- Il a été confirmé que l’incident chez 1Password provenait de la compromission du système de gestion du support client révélée par Okta
- Okta a déclaré qu’un acteur malveillant avait accédé sans autorisation à son système de gestion des dossiers de support client et consulté des fichiers téléversés par certains clients Okta
- Les fichiers obtenus comprenaient des fichiers HAR, utilisés par les équipes de support d’Okta pour reproduire l’activité du navigateur d’un client lors du dépannage
- Les fichiers HAR peuvent contenir des informations sensibles, comme des cookies d’authentification et des jetons de session, que des attaquants peuvent exploiter pour se faire passer pour des utilisateurs légitimes
Deuxième cible connue après BeyondTrust
- L’entreprise de sécurité BeyondTrust a découvert l’intrusion après qu’un attaquant a tenté d’accéder à son compte Okta avec un cookie d’authentification valide
- Chez BeyondTrust, l’attaquant a pu effectuer « quelques actions limitées », mais les contrôles de politique d’accès ont bloqué l’activité et empêché l’accès au compte
- Après la compromission d’Okta, 1Password est devenu le deuxième client Okta connu à être ciblé par une attaque en aval
Déroulé de l’incident dans un rapport Notion interne
- Un rapport daté du 18 octobre et partagé dans l’espace de travail Notion interne de 1Password indique que l’attaquant a obtenu un fichier HAR créé par un employé IT de l’entreprise
- Cet employé avait récemment créé ce fichier en travaillant avec le support Okta
- Le fichier contenait l’enregistrement de tout le trafic entre le navigateur de l’employé de 1Password et les serveurs Okta, ainsi que des cookies de session
- 1Password n’a pas répondu à une demande de confirmation de l’authenticité des documents fournis sous forme de texte et de captures d’écran par un employé anonyme
- Selon le rapport, l’attaquant a également accédé au tenant Okta de 1Password
- Un tenant Okta sert à gérer les droits d’accès aux systèmes et les niveaux d’autorisation attribués aux employés, partenaires et clients
- L’attaquant a consulté les affectations de groupes et effectué d’autres actions, mais certaines n’ont pas été enregistrées dans les journaux d’événements
- Il a mis à jour l’IDP (identity provider) utilisé pour l’authentification de l’environnement de production fourni par Google lors de la connexion
Actions effectuées par l’attaquant et nouvelle tentative bloquée
- Le 29 septembre, l’équipe IT de 1Password a été alertée de l’accès après avoir reçu un e-mail inattendu laissant entendre qu’une liste des utilisateurs 1Password disposant de privilèges administrateur avait été demandée
- Les membres de l’équipe ont déterminé qu’aucun employé autorisé n’avait effectué cette demande et ont prévenu l’équipe de réponse sécurité de l’entreprise
- Les actions effectuées par l’attaquant sont les suivantes :
- Il a tenté d’accéder au tableau de bord Okta de l’employé IT, mais a été bloqué
- Il a mis à jour l’IDP existant relié à l’environnement Google de production de 1Password
- Il a activé cet IDP
- Il a demandé un rapport sur les utilisateurs administrateurs
- Le 2 octobre, l’attaquant s’est de nouveau connecté au tenant Okta de 1Password et a tenté d’utiliser l’IDP Google précédemment activé, mais a échoué car l’IDP avait été supprimé
- Les deux accès provenaient de serveurs de l’hébergeur cloud américain LeaseWeb et utilisaient une version de Chrome sur une machine Windows
- Après l’incident, 1Password a modifié la configuration de son tenant Okta afin de refuser les connexions via des fournisseurs d’identité autres qu’Okta
Quand la compromission d’un fournisseur mène à des attaques contre ses clients
- La compromission d’Okta fait partie d’une série d’attaques menées ces dernières années contre des fournisseurs de logiciels et de services disposant de grands portefeuilles de clients
- Les attaquants s’introduisent chez un fournisseur, puis exploitent cette position pour mener des attaques en aval contre ses clients
- D’autres clients Okta pourraient être identifiés à l’avenir
1 commentaires
Avis sur Hacker News
Confier le SSO à un prestataire externe n’est pas seulement une question de savoir si c’est techniquement plus simple ou si l’on dispose des compétences opérationnelles. Un facteur important est de pouvoir écrire dans les contrats clients que l’on utilise un fournisseur de SSO réputé, et que ce fournisseur assume aussi la responsabilité de la documentation sur la méthode de gestion des clés et la protection du matériel cryptographique
1Password a probablement déjà mis en place ce type de dispositif, ce qui rend le cas un peu particulier, mais en général il est beaucoup plus facile de dire « personne dans l’organisation n’a accès aux clés » que « Bob est la seule exception : il exploite le serveur SSO et nous lui faisons confiance »
Il est intéressant de voir que les failles de sécurité mémoire en C sont celles dont on parle le plus, mais dans les faits, ce qui a souvent le plus d’impact relève plutôt de l’effondrement de la lucidité provoqué par une complexité excessive en suivant de prétendues bonnes pratiques de conception
À mon avis, la cause fondamentale est la limite humaine à appréhender une complexité gigantesque
Ce dernier aspect est probablement complexe parce qu’il implique des humains, ce qui rend plus facile la tentation de chercher le salut dans la technologie
En voyant le passage « nous avons remplacé tous les identifiants système du membre de l’équipe IT, et modifié la MFA pour n’autoriser que les Yubikey », j’espère que cela deviendra l’occasion de faire utiliser à tout le personnel une authentification à deux facteurs basée sur Yubikey. Tout ce qui est en dessous de FIDO2 est vraiment faible
Je me demande pourquoi les gens choisissent encore Okta. Personnellement, utiliser GSuite comme fournisseur d’identité me semble bien plus pratique. Okta a subi des compromissions assez graves et, franchement, même avant cela, je n’avais pas entendu grand-chose de positif sur ses pratiques de sécurité
Imposer une MFA matérielle est une bonne pratique et peut empêcher à l’avenir des attaques comme le spear phishing, mais cela n’a rien à voir avec cet incident précis
Si les gens choisissent Okta, c’est un peu le « personne n’a jamais été viré pour avoir acheté IBM ». Si je fais tourner mon propre Keycloak et qu’il se fait compromettre, c’est ma responsabilité ; avec Okta, le fait que ce ne soit plus mon problème grâce à l’externalisation joue aussi un rôle
Je me demande si vous avez déjà utilisé sérieusement Google Workspace pour un usage réel. C’est l’un des fournisseurs d’identité les moins riches en fonctionnalités, tandis qu’Okta fait partie des plus complets. Les comparer parce qu’ils ont tous les deux deux roues, c’est comme comparer un vélo et une moto
Je ne pensais pas voir un jour Google Workspace recommandé comme fournisseur d’identité sur un forum technique
Avec Yubikey, tout le support client lié aux problèmes de mots de passe revient au service IT interne, et non à un prestataire externe
La MFA comporte des problèmes techniques et des problèmes sociaux ; l’aspect sécurité technique des implémentations comme les clés, jetons, téléphones ou SMS est presque secondaire, tandis que les problèmes sociaux — support client, mots de passe perdus, clé passée à la machine à laver, impossibilité de recevoir des e-mails — sont de loin les plus lourds
Tout le monde veut externaliser l’énorme et stupide rôle de support client en sécurité, mais une fois que c’est fait, tout le monde est incité à réduire les coûts. Le résultat, c’est Okta
Par exemple, dans une organisation où tous les employés sont dans GSuite, la méthode recommandée pour fournir l’accès à une organisation AWS est AWS SSO[1]. Une fois la connexion configurée, l’accès est possible, mais il reste des angles morts
Il n’existe pas de fonction permettant de provisionner ou de supprimer automatiquement des utilisateurs dans AWS SSO à partir des groupes d’utilisateurs GSuite. Avec la prise en charge de SCIM par SSO, on peut écrire son propre code, mais il faut ensuite le maintenir
Il n’y a aucun moyen d’imposer une vérification MFA lors de la création d’une session SSO, ni côté GSuite ni côté AWS SSO. GSuite ne peut pas exiger une vérification MFA avant l’authentification d’une application SAML, et AWS SSO, contrairement au cas où l’on utilise son Directory interne, ne peut pas non plus imposer une vérification MFA quand on utilise un fournisseur d’identité
Okta et les produits similaires font ce genre de choses, et permettent apparemment aussi de conditionner la vérification MFA à l’endpoint utilisé. Je ne l’ai pas testé moi-même ; c’est d’après les supports marketing et les explications commerciales
En résumé, Okta fournit beaucoup plus de colle d’automatisation et de sécurité entre le fournisseur d’identité et les applications utilisées
[1] Ici, AWS SSO désigne le produit AWS « AWS IAM Identity Center (Successor to AWS Single Sign-On) »
Les preuves visibles aujourd’hui se limitent à peu près à ceci : Okta a subi une compromission l’an dernier, en a subi une autre cette fois-ci, et cette dernière compromission a eu lieu dans le service ou les systèmes de support client. La divulgation de la compromission a peut-être été tardive, mais il est aussi possible qu’ils n’aient pas trouvé de preuves jusqu’à récemment à cause du grand nombre de faux signalements. Ils n’ont pas crédité le client qui a fait le premier signalement, et ils ont peut-être mal communiqué avec lui après son signalement
Ce que nous ignorons est bien plus vaste. Nous ne savons pas à quel point les attaquants étaient compétents, combien de fois chaque fournisseur d’identité a été compromis, combien de fois il l’a détecté, s’il l’a détecté puis étouffé, combien de bugs de sécurité chaque service comporte, leur gravité, leur facilité de découverte, quelles sont leurs capacités de détection d’intrusion, à quel point les employés sont bien formés, ni quelle proportion des employés se soucie réellement de la sécurité
On ne peut pas conclure que le produit est pire simplement parce qu’Okta a signalé une compromission. Nous ne savons pas à quel point les autres produits sont bons, et il est possible qu’Okta soit meilleur que certains, voire tous ses concurrents ; bien sûr, il pourrait aussi être pire
Autrefois, on achetait 1Password au prix fort, et le logiciel fonctionnait entièrement hors ligne, en stockant le coffre chiffré localement ou dans Dropbox. Comme il n’y avait rien à voler en ligne, on n’avait pas non plus à se soucier des hackers
Puis quelqu’un a sorti sa calculette et a décidé que la voie vers une meilleure rentabilité consistait à déplacer les données de tout le monde dans le cloud et à facturer un abonnement. Et maintenant, nous nous demandons si nos données ont fuité
Et, à ce que l’on sait aujourd’hui, en quoi est-ce si différent de mettre son coffre dans Dropbox ? Dropbox peut aussi être piraté, et ses données sont notoirement non chiffrées. À ma connaissance, il n’y a pas encore eu de cas réel de compromission d’un coffre 1Password, si ?
https://blog.1password.com/okta-incident/
Rapport d’incident original : https://blog.1password.com/files/okta-incident/okta-incident...
Par la suite, un acteur inconnu a accédé au portail d’administration Okta avec la même session Okta que celle utilisée lors de la création de ce fichier HAR
Comme les banques le disent toujours, il ne faut pas donner son mot de passe au support
Cette fois, la responsabilité incombe clairement à Okta. En demandant des sessions encodées en HAR en clair pour résoudre les problèmes, ils comptent simplement sur les utilisateurs finaux pour les nettoyer correctement.
Pourquoi ne pas nettoyer les données HAR au moment de l’upload, de façon à ce qu’une fois entrées dans le système, les techniciens support sous-payés et en sous-effectif ne voient que les parties pertinentes et sûres ?
Le HAR est une donnée structurée, donc très facile à nettoyer par programme. Ce n’est pas de la science spatiale.
Les gens demandent sans cesse pourquoi utiliser un gestionnaire de mots de passe auto-hébergé et auto-synchronisé plutôt qu’un service en ligne ultra-simple et ultra-convivial ; la raison est la même. C’est comme ne pas jeter les clés de son appartement dans un coffre à la gare du quartier.
Ces organisations corrigent les problèmes des semaines, parfois des mois, avant de publier un communiqué.
Si vous utilisez de l’open source et qu’un bug critique est découvert, vous recevrez le correctif en même temps que le communiqué de presse, alors que les grands services auront probablement déjà corrigé le problème. Pour l’utilisateur moyen, le rapport risque/bénéfice penche du côté des solutions en tant que service.
On peut aussi l’utiliser dans des scripts.
Pas de compromission de serveur, pas de vulnérabilité d’extension web, pas de risque de perdre tous ses mots de passe à cause d’une erreur serveur. Ça fonctionne, tout simplement.
La phrase « 1Password est devenu le deuxième client Okta connu à être visé par une attaque ultérieure » est étrange. Ars ne sait-il pas que Cloudflare a aussi été victime ?
https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...
Je me demande quelles sont les bonnes pratiques pour surveiller les comportements suspects dans une application. Je connais les bases, comme vérifier le taux de requêtes ou le taux d’erreurs à l’échelle du service, mais jusqu’où va-t-on en pratique en matière de sophistication ?
Je me demande s’il existe des outils intelligents qui, une fois alimentés par un flux d’événements, détectent les comportements anormaux, ou s’il faut prévoir à l’avance tout ce qu’on veut surveiller et ajouter des règles.
Une fois qu’on dispose de ce flux d’événements, on peut lancer des outils d’analyse de données. Il faut établir une ligne de base normale à partir de plusieurs jours, semaines ou mois d’activité, puis déclencher des alertes sur des comportements qui sortent du lot, comme des changements massifs de mots de passe ou d’adresses e-mail.
Cela dit, ce n’est qu’une hypothèse de profane de salon ; je serais curieux de savoir si quelqu’un a réellement travaillé avec des journaux d’audit et leur exploitation.
Encore une détection ?
https://news.ycombinator.com/item?id=37991863