Snowflake au cœur d’une campagne de cyberattaques

Snowflake a-t-il une responsabilité dans la vague d’attaques survenues ces derniers temps contre ses clients ?

Voilà environ trois semaines que l’entreprise américaine a pris connaissance de cette campagne. Elle se défend aujourd’hui de toute faille sur ses systèmes.

Les premières accusations dans ce sens étaient tombées fin mai. Le déclencheur : la mise en vente, sur une marketplace du darkweb (BreachForums), de données présentées comme provenant de Ticketmaster.

À défaut de confirmer l’authenticité des données en question, la maison mère avait reconnu avoir identifié une activité non autorisée dans un environnement tiers de base de données cloud.

A-t-on volé des identifiants à Snowflake ?

Il n’avait pas fallu longtemps pour que soit cité Snowflake. En toile de fond, les déclarations d’un autre de ses clients. En l’occurrence, Santander. Mi-mai, le groupe bancaire avait déploré un accès non autorisé, à une « base de données hébergée par un fournisseur tiers ». En avait résulté le vol de données de clients dans trois pays (Chili, Espagne, Uruguay), ainsi que d’employés (actuels et anciens).

Hudson Rock, entreprise américaine qui donne dans le renseignement sur les menaces, avait fini par publier un rapport pointant clairement Snowflake. La communauté infosec lui avait accordé un certain crédit, entre autres au vu des sources avancées. En l’occurrence, un contact direct avec « l’acteur à l’origine de la faille massive chez le géant du stockage cloud », pour reprendre les termes employés.

Sur la foi de ce rapport, les leaks chez Ticketmaster et Santander découlent du piratage Snowflake. Plus précisément, de la connexion au compte ServiceNow d’un des employés en utilisant des authentifiants volés et en contournant Okta. La source interrogée aurait cherché – et échoué – à convaincre Snowflake de lui racheter les données.

Le rapport n’est plus en ligne à l’heure actuelle. Comme d’autres publications qui tendaient à le confirmer.

Ni MFA ni filtrage réseau sur les instances ciblées

Aux dernières nouvelles, Snowflake maintient que les attaques ne sont pas la conséquence d’une vulnérabilité ou d’une mauvaise configuration sur sa plate-forme. Il affirme aussi qu’on n’a pas compromis d’authentifiants d’employés… sinon ceux d’un ancien, mais ils ne donnaient accès qu’à un compte de démo non connecté à la prod (on ignore, en revanche, ce qui se trouvait dans ce compte).

La campagne semble cibler les utilisateurs n’ayant pas mis en place le MFA, ajoute Snowflake. L’éditeur assure préparer un programme pour rendre obligatoire cette technologie ou d’autres « contrôles de sécurité avancés » comme les stratégies de filtrage réseau, « surtout pour les comptes à privilèges ».

Impliqué dans l’enquête, Mandiant recense « environ 165 organisations » potentiellement touchées. Il confirme ne pas avoir de preuve d’une faille chez Snowflake. Les authentifiants utilisés ont été principalement obtenus via des infostealers, à partir de 2020. Parfois sur des postes de sous-traitants mutualisés entre clients voire utilisés pour des activités personnelles… dont des téléchargements illégaux.

Les instances visées n’avaient ni MFA, ni filtrage réseau. L’accès initial s’est souvent fait à travers l’UI web SnowSight et/ou le CLI SnowSQL, sur Windows Server 2022. Mandiant a aussi identifié un outil de reconnaissance dont les versions Java et .NET interagissent avec les pilotes Snowflake correspondants. L’utilitaire de gestion de bases de données DBeaver Ultimate a aussi servi, pour exécuter les requêtes ayant mené à l’exfiltration. La procédure a impliqué des VPS d’un hébergeur moldave et du stockage, entre autres, sur MEGA.

Illustration principale © Tada Images – Adobe Stock