Des hackers ont volé des jetons d’accès au service support d’Okta
(krebsonsecurity.com)- Une compromission du système de support client d’Okta a exposé certains fichiers téléversés par des clients dans des dossiers de support, et les attaquants semblent avoir eu accès à la plateforme de support pendant au moins deux semaines avant d’être bloqués
- Les attaquants ont utilisé des identifiants volés pour entrer dans le système de gestion des dossiers de support, où ils ont pu consulter des fichiers HAR soumis par les clients pour le dépannage
- Les fichiers HAR peuvent contenir des cookies et des jetons de session ; s’ils sont dérobés, des attaquants risquent de réutiliser la session comme s’ils étaient des utilisateurs légitimes
- BeyondTrust a détecté le 2 octobre une tentative de création d’un compte administrateur dans son environnement Okta, et avait partagé avec Okta, 30 minutes plus tôt, un fichier HAR contenant un jeton de session Okta valide
- Okta a notifié environ 170 clients, soit près de 1 % de ses plus de 18 000 clients ; 1Password et Cloudflare ont également révélé une compromission de leur plateforme d’authentification Okta, tout en affirmant qu’aucune donnée client ni aucun système n’avaient été affectés
Fichiers clients exposés dans le système de gestion des dossiers de support
- Okta est une entreprise qui fournit à des milliers de sociétés des outils d’identité incluant l’authentification multifacteur et le single sign-on, et l’incident a commencé par une compromission de son service de support client
- Dans un avis envoyé à certains clients le 19 octobre, l’entreprise a indiqué que des identifiants volés avaient été utilisés pour accéder au système de gestion des dossiers de support
- Les attaquants ont pu voir des fichiers téléversés récemment par certains clients Okta dans leurs dossiers de support
- L’ampleur de l’incident a d’abord été décrite comme touchant un « très petit nombre » de clients, avant qu’il soit confirmé qu’environ 170 organisations, soit près de 1 % de la base clients, avaient été notifiées
Pourquoi les fichiers HAR sont devenus dangereux
- Okta demande parfois des fichiers HTTP Archive (HAR) — un historique de session du navigateur web — pour résoudre des problèmes clients
- Les fichiers HAR sont sensibles, car ils peuvent contenir des cookies et des jetons de session de clients
- Des attaquants peuvent utiliser les cookies ou jetons présents dans ces fichiers pour se faire passer pour un utilisateur légitime
- Okta enquête avec les clients concernés et a pris des mesures de protection, notamment la révocation des jetons de session intégrés
- Avant de partager un fichier HAR, il faut en supprimer tous les identifiants, cookies et jetons de session
Le déroulé de l’attaque repéré par BeyondTrust
- L’entreprise de sécurité BeyondTrust faisait partie des clients ayant reçu l’alerte d’Okta le 19 octobre
- Le CTO de BeyondTrust, Marc Maiffret, a indiqué que cette notification était arrivée plus de deux semaines après que BeyondTrust avait signalé à Okta un problème potentiel
- Le 2 octobre, l’équipe sécurité de BeyondTrust a détecté qu’une personne tentait de créer, dans son environnement Okta, un compte administrateur puissant à partir d’un compte Okta attribué à l’un de ses ingénieurs
- En examinant l’activité de ce compte employé, l’entreprise a constaté que 30 minutes avant l’activité non autorisée, l’ingénieur support avait partagé avec Okta, à la demande d’Okta, un fichier HAR contenant un jeton de session Okta valide
- Les attaquants ont tenté un détournement de session à l’aide des cookies présents dans l’historique du navigateur, afin d’agir à la place de cet utilisateur
- BeyondTrust a averti Okta dès le 3 octobre qu’il était très probable qu’Okta ait subi une compromission, et a répété cette évaluation lors d’appels les 11 et 13 octobre
- BeyondTrust a précisé avoir détecté l’attaque pendant son déroulement, et que ses propres clients n’avaient pas été affectés
La réponse d’Okta et les questions qui restent
- La Deputy CISO d’Okta, Charlotte Wylie, a déclaré qu’au départ, l’alerte de BeyondTrust du 2 octobre n’avait pas été interprétée comme la conséquence d’une compromission de ses propres systèmes
- Au 17 octobre, Okta avait identifié et bloqué l’incident, désactivé le compte compromis de gestion des dossiers clients et invalidé les jetons d’accès Okta associés
- Wylie n’a pas donné le nombre exact de clients ayant reçu une alerte de sécurité potentielle, mais a parlé d’une « toute, toute petite partie » des plus de 18 000 clients
- La durée pendant laquelle les intrus ont eu accès au compte de gestion des dossiers de l’entreprise, ainsi que leur identité, n’ont pas été rendues publiques
- Wylie a indiqué que les attaquants étaient un acteur de menace connu ayant déjà ciblé Okta et certains clients spécifiques d’Okta
Compromissions liées et révélations ultérieures
- La révélation d’Okta est survenue quelques semaines après les attaques contre Caesar’s Entertainment et MGM Resorts
- Dans les incidents touchant les deux groupes de casinos, les attaquants avaient manipulé des employés par ingénierie sociale pour leur faire réinitialiser les exigences d’authentification multifacteur sur les connexions des comptes administrateur Okta
- En mars 2022, Okta avait révélé une compromission liée au groupe de hackers LAPSUS$, spécialisé dans les attaques par ingénierie sociale
- Selon le rapport post-incident d’Okta, LAPSUS$ avait obtenu par ingénierie sociale l’accès au poste de travail d’un ingénieur support de Sitel, un prestataire tiers disposant d’un accès à des ressources Okta
- Okta a ensuite publié un article de blog sur l’incident contenant des indicateurs de compromission permettant aux clients de vérifier s’ils étaient affectés
- L’entreprise a indiqué avoir notifié tous les clients touchés
- Elle a souligné que les environnements Okta et tickets de support des clients n’ayant pas reçu de contact séparé n’avaient pas été affectés
- BeyondTrust a également publié les résultats de sa propre enquête
- Dans une mise à jour du 24 octobre, 1Password et Cloudflare ont révélé que leur plateforme d’authentification Okta avait été compromise à la suite de l’incident chez Okta
- Les deux entreprises ont indiqué que leurs enquêtes n’avaient révélé aucun impact sur les données clients ni sur leurs systèmes
- Un porte-parole d’Okta a déclaré à TechCrunch qu’environ 170 clients, soit près de 1 % de sa base clients, avaient été notifiés
1 commentaires
Avis sur Hacker News
Ce qui est drôle dans cet article, c’est qu’Okta a été averti par un tiers d’une activité suspecte sur un tenant et, dans un premier temps, n’a trouvé aucune preuve de compromission ; ce n’est qu’après que BeyondTrust a continué à insister qu’Okta a rouvert l’enquête et confirmé la compromission.
Okta a publié ce billet de blog ici : https://sec.okta.com/harfiles
La phrase d’ouverture est « Okta Security has identified adversarial activity », mais il n’y a aucune mention de la notification par un tiers. Belle transparence
Le titre est horrible, ni transparent ni direct. Le fait qu’Okta ne mentionne même pas que BeyondTrust les avait alertés le 2 octobre, 30 minutes après avoir envoyé le fichier HAR au support Okta, est vraiment lamentable
« Charlotte Wylie, vice-CISO d’Okta, a déclaré qu’Okta avait d’abord estimé que l’alerte de BeyondTrust du 2 octobre n’était pas le résultat d’une compromission de ses systèmes. Mais elle a indiqué qu’au 17 octobre, l’entreprise avait identifié et bloqué l’incident »
Autrement dit, une entreprise censée être experte en cybersécurité et en authentification a été informée du piratage en moins de 30 minutes, a répondu que c’était faux, puis a mis 15 jours à le reconnaître, pendant que l’attaquant se baladait librement
Wylie, il faut faire mieux
Il suffit de lire ce billet de blog lié depuis l’article original. Une société de sécurité, cliente d’Okta, a détecté une activité suspecte sur son réseau juste après avoir partagé un fichier HAR avec Okta, puis a signalé la compromission à Okta
https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...
J’imagine que c’est une manière compliquée de dire que l’IP a changé après la connexion. Bien sûr, la solution la plus simple est de ne pas partager volontairement des fichiers HAR de sessions actives
Ce ne sera pas populaire, mais je me demande si la passerelle centrale de SSO fondée sur OAuth, SAML et la 2FA ne devrait pas être opérée on-premise plutôt que via le « bouton facile » du SaaS
Cela inclut non seulement Okta, mais aussi Auth0 (racheté par Okta), Authy et Duo
Tous les logiciels ont des bugs de sécurité, et les logiciels on-premise ne font pas exception. Beaucoup d’organisations IT n’ont pas l’expertise nécessaire pour exploiter et protéger des annuaires. Il ne s’agit pas d’installer un logiciel, de créer quelques comptes et de le laisser dans un coin : c’est une tâche très difficile, qui implique reprise après sinistre, tests de sauvegarde et capacité à déterminer s’il y a eu compromission
Personne n’a démontré que la sécurité IT on-premise était meilleure que celle des fournisseurs cloud. Parmi les services IT on-premise que j’ai vus directement, certains avaient une sécurité vraiment catastrophique : un VPN utilisant des certificats MD5 même entre 2010 et 2020 ; un service web donnant à des utilisateurs non authentifiés accès à des données personnelles comme numéro de sécurité sociale/numéro fiscal, adresse, nom et numéro de téléphone ; un éditeur de texte financé par la publicité fourni à des infirmières pour rédiger des notes sur les patients ; ou encore une version de Redcap en fin de support, avec des bugs de sécurité connus, qui n’était pas mise à jour
À ma connaissance, Redcap est un logiciel qui stocke des informations utilisées pour la recherche médicale et les statistiques de santé publique, avec beaucoup de données sensibles
Le point essentiel est que passer du cloud à l’on-premise peut améliorer la sécurité, ou pas. Cela dépend des compétences de chaque organisation IT, et beaucoup d’entre elles n’ont pas la capacité d’exploiter des services d’identité comme Okta. De plus, les fournisseurs cloud ont généralement des budgets bien plus importants et peuvent répartir les coûts sur de nombreux clients, ce qui leur permet d’investir davantage dans les experts sécurité, la protection des systèmes et la détection des compromissions
Ces managers et dirigeants ne reçoivent aucune question
On peut réellement écrire et tester des logiciels sur des systèmes qui ne sont jamais connectés. Étonnant, mais vrai
Les fournisseurs d’identité, les gestionnaires de mots de passe et les sociétés de VPN ne devraient absolument jamais se faire pirater. Ce sont des entreprises qui gagnent de l’argent avec des produits de sécurité, et je n’utiliserais pas celles qui ont été compromises. Il y a probablement un problème plus profond
L’hypothèse de départ, c’est qu’ils peuvent tous être compromis, et c’est à eux qu’il revient de prouver qu’ils ne le seront pas. Plutôt que d’accorder le bénéfice du doute à des acteurs qui ont montré à plusieurs reprises leur incompétence, il paraît plus prudent d’attendre des preuves positives étayant l’affirmation extraordinaire selon laquelle ils ne se font pas pirater
S’ils sont suffisamment compétents et responsables, ils le détecteront et le rendront public, mais j’ai l’impression que la plupart ne le feront pas. Parce que des gens comme vous cesseraient aussitôt de les utiliser. Donc toute personne un tant soit peu inquiète devrait utiliser des alternatives hors ligne, auto-hébergées ou faites maison
Le défi pour Okta : tenir un mois sans se faire pirater. Niveau de difficulté : impossible
Blague à part, Okta semble aimer se faire dévaliser. On pourrait s’attendre à ce que, si ce genre d’incident faisait continuer de chuter le cours de l’action, cela provoque des changements, mais apparemment non
Le diable est dans les détails. Ils fonctionnaient probablement en mode zero trust
D’un côté, ce n’était pas une compromission du produit cœur. De l’autre, toute compromission d’un produit cœur s’accompagne d’une compromission indirecte d’un élément non cœur
Heureusement qu’on leur a permis de racheter leur concurrent Auth0
Un jour, lors d’une conférence, je mènerai une expérience consistant à payer des gens pour qu’ils se fassent embaucher à des postes de support dans plusieurs entreprises, puis à compromettre ces entreprises avec les accès système qui leur auront été accordés
Il était écrit ceci en bas de l’e-mail
« Ces informations sont confidentielles pour Okta et ne doivent pas être partagées en dehors de votre organisation »
Franchement, c’est assez drôle