Fuite de données chez Snowflake : des hackers confirment un accès via une infection par infostealer
(hudsonrock.com)- Le 31 mai 2024, l’entreprise cloud Snowflake a subi une fuite massive de données
- Les hackers ont confirmé à Hudson Rock qu’ils avaient obtenu l’accès via une infection par infostealer
- Les hackers ont vendu sur des forums cybercriminels russophones les données de plusieurs grandes entreprises, dont Ticketmaster et la banque Santander
Méthode de piratage
- Les hackers se sont connectés au compte ServiceNow d’un employé de Snowflake en utilisant des identifiants volés.
- Ils ont contourné Okta pour générer un jeton de session et exfiltrer un grand volume de données.
- Les hackers affirment qu’environ 400 entreprises ont été touchées.
Éléments de preuve supplémentaires
- Les hackers ont partagé avec les chercheurs de Hudson Rock un fichier CSV montrant leur accès aux serveurs de Snowflake.
- Ce fichier documente plus de 2 000 instances clients liées aux serveurs européens de Snowflake.
Objectif des hackers
- Les hackers ont réclamé 20 millions de dollars à Snowflake pour récupérer les données.
- L’entreprise n’a pas répondu.
Hausse des infections par infostealer
- Les infections par infostealer ont augmenté de 6 000 % depuis 2018, devenant un vecteur d’attaque initial majeur.
- Elles sont utilisées pour mener des cyberattaques, notamment des ransomwares, des fuites de données, des détournements de comptes et de l’espionnage d’entreprise.
L’avis de GN⁺
- Importance de la cybersécurité : cet incident montre que les entreprises doivent accorder encore plus d’attention à la cybersécurité. La gestion des identifiants des employés est particulièrement cruciale.
- Menace des infostealers : les infostealers se propagent très rapidement, et les entreprises doivent mettre en place des mesures de préparation adaptées.
- Stratégie de réponse : en cas de piratage, une réaction rapide et une stratégie de limitation des dommages sont nécessaires. La réponse tardive de Snowflake a aggravé l’impact.
- Formation à la sécurité : il est important de renforcer la formation des employés afin d’améliorer la gestion des identifiants et la sensibilisation aux attaques de phishing.
- Solutions alternatives : il peut être pertinent d’envisager d’autres solutions de stockage cloud offrant des fonctions similaires à Snowflake, comme AWS S3 ou Google Cloud Storage.
1 commentaires
Avis Hacker News
L’URL actuellement liée effectue une redirection 302 vers
/. @dang, il vaudrait mieux la remplacer par le lien d’archive ci-dessoushttps://web.archive.org/web/20240531140540/https://www.hudso...
Cela dit, le fait que Hudson Rock ait retiré son billet de blog est aussi un signal intéressant, donc il ne faut pas simplement passer au lien archivé et tourner la page. Qu’est-ce qui a changé ?
Mise à jour : la réponse officielle de Snowflake semble, en pratique, nier presque toutes les affirmations centrales de l’article original. Hudson Rock s’est peut-être fait berner par une source malhonnête et a retiré l’article après s’être rendu compte de son erreur
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Ici Felipe de Snowflake. La position la plus récente de Snowflake sur ce sujet est ici : https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Nous continuerons à mettre cette URL à jour s’il y a du nouveau
Or la phrase de Snowflake — « De façon similaire aux comptes clients affectés, nous avons trouvé des preuves qu’un acteur malveillant avait obtenu et utilisé des identifiants personnels pour accéder à un compte de démonstration appartenant à un ancien employé de Snowflake. Il ne contenait aucune donnée sensible » — se lit comme si Snowflake considérait la version de Hudson Rock comme fausse. Est-ce bien la bonne interprétation ?
À l’inverse, le billet de Snowflake donne l’impression que des identifiants de comptes clients ont fuité, point final, sans accès à un compte central ni à d’autres comptes. Il ne dit rien sur l’utilisation d’identifiants d’un compte employé sans authentification à deux facteurs
Il est évident que Snowflake veut imposer l’authentification à deux facteurs pour tous les identifiants d’accès de ses employés internes. Auparavant, si un client le souhaitait, il pouvait créer seulement un nom d’utilisateur/mot de passe pour se connecter à ses données, sans authentification à deux facteurs
La capture d’écran des logs de chat est vraiment frappante. Cette société affirme communiquer avec de vrais criminels, et le criminel dit que, s’ils avaient utilisé cette société, cela aurait aidé à empêcher l’intrusion
J’ai donc révisé mon jugement sur la crédibilité de cette société
Hudson Rock semble s’être engouffré là-dedans et avoir gonflé l’histoire pour la présenter comme une compromission plus importante qu’elle ne l’était. Je me demande aussi si le hacker est allé voir Hudson Rock en premier, ou si Hudson Rock a simplement été la première société à accepter
« Vous auriez dû acheter la protection de Hudson Rock, cela aurait pu empêcher cette affaire »
« Exact, cela aurait certainement aidé »
« Félicitations. Votre entreprise a passé un audit de sécurité surprise et est devenue victime d’un ransomware. »
[...]
Services fournis : 1) assistance complète au déchiffrement 2) preuve de suppression des données 3) rapport de sécurité sur les vulnérabilités découvertes 4) garantie de ne pas publier ni vendre les données 5) garantie de ne pas mener de futures attaques
Au final, ce n’est qu’une société de conseil en sécurité dont vous ignoriez qu’elle figurait sur votre masse salariale
Au passage, quand j’ai regardé ce qu’ils donnaient comme preuve de suppression des données, ce n’était littéralement que la sortie standard de
rm -vrf data. Je comprends qu’il est impossible de fournir la preuve d’une absence et que la victime n’a aucun pouvoir de négociation, mais cette mise en scène me plaît assezMême si c’était réel, le bon sens aurait voulu de supprimer le message de Hudson Rock. J’ai mis cette société sur ma liste noire mentale
À en croire les propos de l’auteur, Snowflake semble avoir conçu son système de sorte qu’un unique compte administrateur dispose de tous les pouvoirs sur tout
Le fait que Snowflake ait déclaré, dans son communiqué du 31 mai, enquêter sur une « attaque basée sur l’identité à l’échelle du secteur » ayant touché certains clients renforce aussi la crédibilité des récits concernant Ticketmaster et Santander
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Si l’acteur malveillant a bien fait les choses, cela pourrait devenir l’une des plus grandes fuites de données de l’histoire
Les données semblent provenir du compte Snowflake de cette personne, utilisé pour créer des démos destinées à des clients ou prospects. Il est possible que des clients lui aient donné accès à une partie de leurs données réelles pour les utiliser dans des démos, mais on est loin d’un accès illimité aux bases de données Snowflake des clients elles-mêmes
Il est tout à fait possible que le hacker ait exfiltré de fausses données de démo, crédibles mais factices, et qu’il ne sache pas faire la différence
Un sales engineer gère plusieurs comptes. Les sales engineers de Snowflake ne construisent généralement pas dans l’environnement client ; ils configurent un compte de démo à 400 dollars de crédits, que n’importe qui peut créer. Comme les comptes de démo expirent au bout d’un certain temps, ils en créent continuellement de nouveaux
Le sales engineer construit dans le compte de démo qu’il a créé et le présente au client. Au bout de 30 jours, Snowflake verrouille le compte s’il n’y a pas de carte bancaire, puis supprime ensuite l’instance de démo et les données
Pour travailler, le client peut partager des données depuis sa propre instance Snowflake vers l’instance de démo créée par le sales engineer, ou lui accorder un accès via SSO
Dans les deux cas, cela ressemble surtout à un problème d’organisations qui n’appliquent pas une posture de sécurité suffisamment restrictive. Ce n’est pas une attaque nouvelle, hormis le fait qu’ils ont trouvé un sales engineer travailleur et des clients qui n’ont pas correctement limité le périmètre des droits de leurs employés/contractants/invités
Fait intéressant, on trouve aussi en première page un article voisin sur l’utilisation de Pegasus contre des ONG d’Europe de l’Est. Le principe du moindre privilège est important, mais la sécurité des appareils l’est aussi
https://news.ycombinator.com/item?id=40535912
Je ne suis pas employé de Snowflake, mais j’ai beaucoup travaillé avec Snowflake et son organisation de sales engineers
Quand ils créent une démo avec un client, les sales engineers montent un environnement de démonstration avec un compte de démo Snowflake à 400 dollars que n’importe qui peut créer. Pour construire la démo, le client donne un accès au sales engineer, qui récupère une partie des données dans l’environnement de démo pour travailler. Les noms d’environnements publiés par Hudson Rock vont aussi dans ce sens
À mon avis, c’est un problème de processus : le client n’a pas fait expirer l’identifiant de la personne avec qui il partageait les données, et l’acteur malveillant a volé les identifiants. Ce n’est pas l’exploitation d’une vulnérabilité, donc rien de nouveau
Et bravo à Hudson Rock d’avoir publiquement exposé une personne victime d’un malware sur son ordinateur. Ce n’est pas différent d’un cas où l’on donne des identifiants à un prestataire et où ceux-ci sont volés. C’est vraiment dégueulasse
Snowflake a des identifiants de sales engineer qui peuvent être volés, ces identifiants peuvent contourner la MFA, et, d’après l’article, ils n’expirent pas. Strike 1, 2 et 3
Les pratiques de sécurité de Snowflake ont créé une situation où les clients sont tenus, ou au moins encouragés, à partager l’accès à de larges jeux de données avec des employés de Snowflake. Strike 4
Les clients sont aussi responsables d’avoir accordé des accès trop larges, mais Snowflake porte également une part de responsabilité pour ne pas avoir conçu de meilleurs systèmes évitant ce type d’accès, ou au minimum pour ne pas avoir mieux supervisé et contrôlé cet accès transitif
Dès qu’un tel compte reçoit un accès aux données client, ce n’est plus un « compte de démo ». C’est un vrai compte, avec des données réellement très précieuses, et il doit être traité comme tel
Ajout : Snowflake affirme que ce compte de démo n’avait pas accès aux données client et n’était pas la source de la fuite, ce qui contredit les affirmations de l’attaquant
« Imaginez avoir accès à une plateforme de prospection regroupant des centaines de milliers d’entreprises compromises dans le monde entier, avec des vulnérabilités actives, que vous pouvez convertir en clients. »
J’ai vu et eu affaire à quelques entreprises de ce type : ce sont des tactiques assez bas de gamme, et techniquement le niveau de compétence ou d’effort est faible
La réponse officielle de Snowflake dit ceci :
« Nous estimons qu’il s’agit du résultat d’une attaque en cours, à l’échelle du secteur, fondée sur l’identité et visant à obtenir des données clients. D’après notre enquête, ces attaques sont menées au moyen d’identifiants utilisateur de clients exposés lors d’activités de cybermenace sans lien avec Snowflake. À ce jour, nous ne pensons pas que cette activité soit due à une vulnérabilité, à une mauvaise configuration ou à une activité malveillante au sein du produit Snowflake. »
[0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Il semble que l’article ait été passé en privé, mais il est encore disponible sur la Wayback Machine : https://web.archive.org/web/20240531140540/https://www.hudso...
Cet article affirme que la compromission de Ticketmaster survenue il y a quelques jours était en réalité un piratage beaucoup plus vaste, touchant plus de 400 entreprises, via des identifiants volés d’un employé de Snowflake.
Pour l’instant, cela ressemble à une grosse affaire rapportée uniquement par hudsonrock.com. Je n’avais jamais entendu parler de Hudson Rock ; quelqu’un sait-il si c’est une source fiable ?
Plusieurs comptes ont été bannis par les opérateurs et administrateurs de Reddit. Personnellement, je ne considère pas cela comme une source fiable ou digne de confiance.
https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
Snowflake semble dire que ce n’est pas de sa faute, mais celle des clients.
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Si https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... n’est pas une histoire entièrement inventée, Snowflake présente les faits d’une manière un peu moins qu’honnête.
La formulation « d’après notre enquête… » est ambiguë : s’agit-il de leur propre enquête ou de recherches de sécurité en général ? La phrase disant qu’ils ne pensent pas que ce soit dû à « une vulnérabilité, une mauvaise configuration ou une activité malveillante au sein du produit Snowflake » énumère aussi les scénarios possibles pour les écarter, tout en omettant habilement d’expliquer ce qui s’est réellement passé.
Si l’on croit Hudson Rock, Snowflake a été contacté par l’acteur malveillant, donc ils savaient très probablement assez bien comment cela s’était produit.
Elle dit que cela a été « mené au moyen d’identifiants utilisateur de clients exposés lors d’activités de cybermenace sans lien avec Snowflake » ; si ce n’est pas inventé, ils semblent donc considérer que les identifiants ont été obtenus ailleurs.
À la fin, ils demandent aux clients de vérifier la configuration de leurs comptes, ce qui va dans le sens d’un transfert de responsabilité hors de chez eux. Cela dit, les sources actuelles sont l’entreprise qui a été piratée et une entreprise qui profite de l’affaire pour promouvoir son produit tout en doxxant sans vergogne un employé, donc il vaut probablement mieux attendre davantage d’informations.
Le hacker affirme aussi qu’ils n’ont même pas révoqué les refresh tokens ; si c’est vrai, c’est un problème énorme et évident.
L’article ne semble pas vraiment cohérent avec son titre évoquant des « centaines de clients compromis ».
Premièrement, le mot de passe lift/okta semble seulement donner accès au portail ServiceNow, et non aux comptes clients ; le problème des refresh tokens paraît donc limité au portail ServiceNow et sans rapport avec l’exposition de données dans de vrais comptes clients Snowflake.
Deuxièmement, la capture d’écran indiquant que les comptes de 10 entreprises ont été compromis montre quatre jeux d’identifiants Snowflake différents, dont l’un ressemble à un compte de démo personnel. Cela permettrait donc d’expliquer au maximum trois compromissions de clients, mais il n’y a aucun détail montrant d’autres compromissions de clients.
Même en supposant que tous les identifiants de tous les clients sur lesquels travaillait l’ingénieur avant-vente aient été compromis, le nombre de clients touchés serait probablement dans le bas des deux chiffres. Chaque compte client aurait en effet dû accorder individuellement un accès à cet ingénieur avant-vente.
Dire que l’ensemble des clients de Snowflake a été compromis sur la base d’un problème de refresh token dans le portail Okta interne est un énorme raccourci, et ce problème n’est lié à aucun compte client Snowflake.