Attaque de Lapsus$ : Okta tente de répondre aux questions

Ce mardi 22 mars, peu après 4h du matin, le groupe dit Lapsus$ a revendiqué, sur son canal Telegram, une cyberattaque contre Okta, partageant 8 captures d’écran pour étayer ses allégations. Après un début de communication de crise pour le moins brouillon, l’éditeur s’évertue à rassurer au mieux ses clients.

David Bradbury, responsable de la sécurité chez Okta, a ainsi multiplié les publications et organisé une conférence via Zoom en ce mercredi 23 mars, non sans reconnaître au moins un manquement de l’éditeur.

Comme le suggéraient les captures d’écran publiées par Lapsus$, « un attaquant a obtenu un accès distant via RDP » à un poste de travail, et plus précisément celui d’un ingénieur support du sous-traitant Sitel – ou plutôt Sykes, qui a été racheté par celui-ci. De là, l’assaillant a pu utiliser une application interne à Okta, dite SuperUser. Mais selon Okta, celle-ci « ne donne pas un accès de niveau “divin” à tous ses utilisateurs » : « c’est une application construite suivant le principe du moindre privilège, pour assurer que les ingénieurs support disposent des accès spécifiques nécessaires afin de remplir leurs fonctions. Ils ne sont pas capables de créer ou effacer des utilisateurs. Ils ne peuvent pas télécharger les bases de données des clients. Ils ne peuvent pas accéder à nos entrepôts de code source », explique David Bradbury.

En fait, tout a commencé le 20 janvier. À cette date, l’équipe de sécurité d’Okta reçoit une alerte : quelqu’un a tenté d’ajouter « un nouveau facteur de MFA au compte Okta d’un ingénieur de support client de Sitel ». La tentative a échoué, mais le compte a été réinitialisé et le sous-traitant a été notifié. Tout cela survient en l’espace d’une heure, au milieu de la nuit. Okta informe Sitel après un peu plus de 17 heures.

Mais l’incident ne semble pas inquiéter Okta plus que ça. Un tiers enquête auprès de Sitel jusqu’au 28 février 2022. Son rapport à ce dernier est daté du 10 mars. Une semaine plus tard, Okta ne reçoit qu’un rapport « résumé ». Ce n’est que le 22 mars, après les revendications de Lapsus$, que l’éditeur recevra le rapport complet.

David Bradbury se dit « déçu » de tout ce temps écoulé entre la notification à Sitel et la fourniture du rapport d’enquête complet. Pour lui, Okta aurait dû être plus réactif « une fois que nous avons reçu le rapport résumé ». Mais peut-être l’éditeur aurait-il aussi dû s’avérer plus pressant avec le sous-traitant dès la notification initiale…

La chronologie fournie par David Bradbury soulève d’autres questions : pourquoi Lapsus$ a-t-il attendu deux mois pour faire ses revendications ? La date retenue par le groupe, cinq jours après la livraison du rapport d’enquête résumé à Okta, relève-t-elle pleinement de la coïncidence ? La question apparaît d’autant plus légitime que Microsoft indique que Lapsus$ a été vu « se joindre aux appels et aux forums de discussion internes (Slack, Teams, téléconférences, etc.) pour comprendre le workflow de réponse à incident ».

Okta n’est pas seulement un incontournable leader de la gestion des accès dans le quadrant magique Gartner : de rapides recherches suggèrent le recours à ses solutions par de nombreuses entreprises et administrations, parfois critiques, du monde entier, à l’instar d’Engie, Rapid7, Concur, Backmarket ou encore Deloitte, Blablacar, et Imerys.

David Bradbury assure que l’examen des traces d’activité des collaborateurs de Sitel, les logs, a permis de « déterminer que l’impact potentiel maximum est 366 clients », soit 2,5 % de sa base installée. Il ne précise pas la nature de l’impact possible. Mais il indique que les clients concernés « recevront un rapport montrant les actions réalisées sur leur tenant Okta par Sitel », durant la période où Lapsus$ a pu avoir accès au poste de l’ingénieur de support, à savoir entre les 16 et 21 janvier derniers.