Posté le mars 30, 2022 à 4:02

OKTA DIT QU’ELLE S’EST TROMPÉE DANS SON APPROCHE SUR L’INCIDENT DE PIRATAGE DE LAPSUS$

Suite au dernier incident de piratage de la plateforme de gestion d’identité Okta par le groupe de hackers Lapsus$, la société a déclaré qu’elle avait fait une erreur dans son traitement du rapport de piratage.

Ceci intervient après qu’un chercheur en sécurité indépendant ait partagé ce qui semble être une chronologie détaillée des événements qui ont conduit à l’exposition des données divulguées par Lapsus$.

Okta a été victime d’une violation via une entreprise tierce

Bill Demirkapi a publié une chronologie des événements sur un document de deux pages et l’a partagée sur Twitter. Selon le chercheur, le document a été publié par Mandiant, la société de sécurité qui a enquêté sur l’incident.

La semaine où Lapsus$ a révélé qu’il avait compromis les comptes d’Okta via l’un des tiers de l’entreprise, les organisations et les clients se bousculent pour connaître l’impact réel du piratage. Le tiers concerné, Sykes Enterprises (exploité par Sitel), a confirmé la semaine dernière qu’il avait été victime d’un incident de piratage en janvier 2022. Cependant, le dernier document ayant fait l’objet d’une fuite concernant la notification de la violation montre une chronologie détaillée de la violation à partir du 25 janvier.

Les documents divulgués ont semé le doute sur le système de sécurité de Sykes

Les documents publiés ont maintenant jeté des doutes sur la solidité du système de défense de Sykes avant l’incident de piratage. Ils ont également mis en évidence des failles dans la réponse d’Okta au piratage. Les documents ont été obtenus par le chercheur indépendant en sécurité Bill Memirkapi, mais Okta a refusé tout autre commentaire sur cette affaire.

Dans une déclaration récente, Okta a indiqué qu’elle était au courant de la fuite de ce qui semble être un rapport préparé par Sitel concernant l’incident. La société a ajouté que le contenu du document est cohérent avec la série d’événements concernant l’incident de piratage.

Cependant, Okta a admis qu’elle aurait dû agir rapidement pour comprendre les implications du rapport après l’avoir reçu le 17 mars. « Nous sommes déterminés à tirer des leçons de cet incident et à nous améliorer à la suite de celui-ci », a déclaré l’entreprise.

Okta reconnaît avoir mal géré la situation

Okta a déclaré avoir tardé à prendre des mesures appropriées et rapides après avoir reçu le rapport sur l’incident de piratage avant que le groupe Lapsus$ ne publie la violation le 21 mars.

Okta a gardé le rapport pendant quatre jours avant d’être pris au dépourvu lorsque les hackers ont publié des captures d’écran affirmant qu’ils avaient violé Okta, rendant l’information publique par la même occasion.

L’inaction d’Okta a exposé de nombreux utilisateurs au risque d’être exploités, puisqu’ils n’ont pas été avertis de se préparer à la diffusion de leurs informations en ligne. Okta a même été blâmé pour la rapidité avec laquelle l’attaquant a publié les détails de la violation en ligne. Auparavant, l’entreprise avait déclaré qu’il n’y avait pas eu de violation, assurant aux utilisateurs et aux clients que leurs données étaient en sécurité. Mais la dernière exposition de données par l’acteur de la menace a prouvé qu’Okta avait tort.

Et la « chronologie de l’intrusion » sera très choquante pour une entreprise aussi réputée qu’Okta qui détient des fichiers importants pour des milliers d’organisations. « La chronologie de l’attaque est embarrassante et inquiétante pour le groupe Sitel », a déclaré M. Demirkapi. Il a ajouté que les acteurs de la menace ne se souciaient pas de maintenir un niveau sérieux de sécurité opérationnelle. Selon Okta, cette violation pourrait avoir affecté au maximum 3606 clients.

Des observateurs mettent en cause le système de sécurité d’Okta

Selon la chronologie, qui s’appuie sur les données recueillies par la société de sécurité Mandiant, le groupe Lapsus$ a utilisé un outil de piratage très populaire et largement disponible pour compromettre les serveurs de Sitel.

Ils ont utilisé un outil de saisie de mot de passe comme Mimikatz pour infiltrer les systèmes de Sitel. Dès le début, les acteurs de la menace ont pénétré dans le système et désactivé les outils d’analyse de sécurité, ce qui leur a donné un accès plus large à d’autres zones du serveur. Par conséquent, les systèmes de sécurité n’ont pas été en mesure de repérer les outils de piratage plus tôt pour alerter Sitel.

La chronologie indique également que les acteurs de la menace ont réussi à s’infiltrer dans Sykes le 16 janvier avant d’intensifier leur attaque les 19 et 20 janvier. La dernière connexion des attaquants au système a eu lieu le 21 janvier, ce qu’ils ont appelé une « mission complète ». Cela signifie que les attaquants ont planté leurs outils dans le système et ont collecté toutes les données pertinentes dont ils avaient besoin avant de quitter finalement le système sans être détectés.

En conséquence, le système de sécurité de Sykes a été critiqué, beaucoup se demandant pourquoi une entreprise disposant d’autant de ressources utilise un système de sécurité peu performant.