Quelque 165 clients de Snowflake auraient déjà été la proie de pirates. Ils se sont introduits dans les comptes Snowflake grâce à la mauvaise sécurité de ces clients eux-même.
La société de sécurité Mandiant, en collaboration avec le spécialiste des données cloud Snowflake, a déjà contacté 165 organisations qui ont été victimes de pirates. Les criminels ont piraté les comptes Snowflake des clients et volé leurs données. Ils essaient maintenant de faire du profit en extorquant les cibles ou en revendant ces données.
Les clients ont été ciblés par des attaquants d’un groupe identifié sous le nom de UNC5537. Ce groupe cible actuellement les clients de Snowflake, mais n’exploite pas de bogues ou de vulnérabilités dans Snowflake lui-même pour le faire. Les comptes Snowflake sont une cible facile, car Snowflake se présente justement comme un lieu central pour les données d’entreprise de tous les utilisateurs.
Données de connexion volées
Selon Mandiant, dans tous les cas détectés, la source de l’intrusion se trouve chez le client lui-même. Plus précisément, les pirates de l’UNC5537 se sont introduits dans le système grâce à des identifiants de connexion volés pour des comptes sans sécurité AMF. Pour obtenir ces identifiants, ils ont utilisé une variété de logiciels qui volent des données, mais souvent aussi parce qu’ils étaient disponibles sur le dark web après avoir été volés par d’autres pirates.
La plus ancienne combinaison de nom d’utilisateur et de mot de passe volée date de novembre 2020, note Mandiant. Les données utilisées par UNC5537 ne sont généralement pas nouvelles et sont connues des milieux criminels depuis un certain temps. Les victimes n’ont pas modifié les identifiants de connexion de leurs comptes Snowflake depuis le vol du mot de passe initial, mais ils ne savaient probablement pas qu’ils couraient un risque.
Utiliser la porte d’entrée
L’attaque d’UNC5537 n’est donc pas très sophistiquée. Les criminels se connectent simplement avec un compte dont les identifiants sont disponibles et qui leur donne des droits suffisants, puis utilisent de divers outils. Ils examinent les données auxquelles ils ont accès, puis les volent.
Mandiant remarque aussi que les comptes concernés non seulement n’ont pas d’AMF, mais n’utilisent pas non plus les listes d’autorisation du réseau (« Network Allow »). Ces listes permettent de restreindre l’accès à un compte à des lieux connus (comme le réseau de l’entreprise).
En fait, les clients concernés de Snowflake ont perdu leurs clés quelque part au cours des quatre dernières années, n’ont pas remplacé la serrure ou n’ont pas installé de serrure supplémentaire, et les voleurs ont maintenant utilisé la clé pour entrer par la porte d’entrée.
Pas de bogue de plateforme
Le service clientèle de Snowflake coopère avec les clients concernés pour atténuer l’impact de l’attaque. Snowflake elle-même insiste sur le fait que la sécurité de la plateforme Snowflake ou de ses propres systèmes est tout à fait satisfaisante. Le fait qu’au moins un compte de démonstration sans AMF de Snowflake lui-même ait été piraté n’y change rien, selon l’entreprise. Ce compte de démonstration n’est rien d’autre que ce que suggère son nom, et il n’avait pas accès aux systèmes de production.
Mandiant ajoute que, dans certains cas, UNC5537 a pu accéder aux données de partenaires clients qui géraient plusieurs systèmes. Cela amplifie évidemment l’impact de l’attaque. Les quelque 165 clients aujourd’hui identifiés comme victimes ne représentent probablement pas l’ensemble des victimes ciblées par UNC5537.
Modèle d’attaque lucratif
Mandiant en conclut aussi qu’UNC5537 poursuivra vraisemblablement sa stratégie, et ne restera pas forcément focalisé sur Snowflake. Après tout, il n’est pas trop difficile d’attaquer des services SaaS via des identifiants de connexion volés, tant que les utilisateurs n’activent pas l’AMF. Selon Mandiant, le groupe UNC5537 comprend des membres en Amérique du Nord et au moins un pirate en Turquie.
Pour l’instant, Snowflake ne requiert pas de ses clients qu’ils activent l’AMF. Toutefois, elle le recommande aux utilisateurs. À la suite de l’attaque, l’entreprise étudie également la possibilité d’exiger de ses clients qu’ils mettent en œuvre des mécanismes de sécurité avancés à l’avenir. Plusieurs fournisseurs de SaaS et spécialistes cloud le font déjà.