Very big cyber incident playing out at Snowflake, who describe themselves as “AI Data Cloud”. They have a free trial where anybody can sign up and upload data… and they have.
Threat actors have been scraping customer data using a tool called rapeflake, for about a month.
The tl;dr of the Snowflake thing is mass scraping has been happening, but nobody noticed.. and they're pointing at customers for having poor credentials. It appears a lot of data has gone walkies from a bunch of orgs.
Snowflake is a big AI data company with a conference in the US next week, chances of that going ahead are interesting.
IOCs: https://community.snowflake.com/s/article/Communication-ID-0108977-Additional-Information
Snowflake admin users need to check their Snowflake environment, not sec departments check their on prem.
Snowflake: there is absolutely no cybersecurity incident.
Also Snowflake: Please run these commands and look for "threat activity" logins with the user agent "rapeflake" using this knowledge base article we haven't listed on our website.
https://community.snowflake.com/s/article/Communication-ID-0108977-Additional-Information
Live Nation said its stolen database was hosted on Snowflake, a cloud storage and analytics company.
The deleted Hudson Rock post on Snowflake breach: https://web.archive.org/web/20240531140540/https://hudsonrock.com/blog/snowflake-massive-breach-access-through-infostealer-infection
For the record I don't think all the content is accurate - however Snowflake did have a security incident via their former employee, they have full IR stood up. They didn't follow their own best practices.
I also know multiple orgs who've had their full databases taken from Snowflake.
The Snowflake authentication setup is terrible.
MFA can’t be enabled org wide, each user has to manually log in and enable it. There’s no policy to block users without MFA. And it uses Duo MFA rather than your orgs MFA. (You can bring your own MFA with SAML).
Also all users log in via a Snowflake domain, so you can just pull creds from info stealer marketplaces or logs.
That’s why they’re being targeted as a platform.
IMHO it's fair to call out Snowflake's authentication isn't very good - it's the worst SaaS MFA solution I've seen as it has no top level, easy switch for org wide MFA enforcement.
Combined with putting all customers under *.snowflakecomputing.com sub domain is why their customers are getting owned - infostealers are just full of creds ready to go.
I gather Snowflake are discussing changes to fix, don't tell the fanboys (and yes, they're all dudes).
Mandiant have informed 165 organisations they may have had data exfiltration from their Snowflake hosted databases
https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion/
@GossiTheDog
@Johnhultquist
Even if Snowflake had "proper" MFA authentication across the board, would that have significantly changed the outcome?
That is, if an info stealer is what's at play, and it steals my authentication cookie, I can't really rest at night knowing that MFA is keeping me safe, right?
@jawnsy @wdormann @GossiTheDog @Johnhultquist
How do you device bound credentials? I have only heard of IP bounding them (so if it’s suddenly being used from a different location a new login is required)
And that is already being used by some companies afaik.
> putting all customers under *.snowflakecomputing.com sub domain
How else would you have them handle it? Nearly all SaaS providers do exactly this.
A popular one you might have come across is *.github.io.
(Not a fanboy; I just work for another SaaS vendor and would like to know if we’re doing anything terribly wrong.)
Oh fuu....you're right! This just keeps getting worse and worse.
I got to this point in your write-up, and I don't think it can be emphasized enough:
Note that in the age of SaaS, your providers will throw you under the bus to save themselves. When you transfer your security risk to a provider, they don’t accept your risk — they just take the money.[EDIT: typo]Snowflake observed:
+ "malicious traffic"
+ "cyber threat activity targeting some of our customers’ accounts"
Snowflake has not observed
- "a security incident"
- "vulnerability, misconfiguration, or malicious activity within the Snowflake product"
🤔 Threading a mighty fine needle there
To be clear: I'd like to see Snowflake own up to responsibility for creating security capabilities with secure defaults that are hard to misuse in a way that creates severe unintended consequences
Sounds currently like the leaky data lake version of the classic public S3 bucket misconfiguration
I hope they're bringing humility to their customers now, and public acknowledgement later
I'm still trying to parse this statement. A non-exclusive list of meanings is: (a) someone gained access to a trusted part of the Snowflake network and made off with customer credentials or (b) there were credential stuffing attacks that gained access to Snowflake customer accounts.
In either case, the Snowflake statement that management does "not believe this activity is caused by any vulnerability, misconfiguration, or malicious activity within the Snowflake product" would be true.
Does this sound possible to you?
Kevin Beaumont
Anthropy
devopscats
Will Dormann
Jonathan Yu
Euph0r14
Brian Clark
Ankit Pati
Gordon
Ricky Boone
Samofhearts
Alan Miller 
🇺🇦
Ben Brockert
Nick
Bill
Vinny Troia 
Sam J Sharpe
Paul Bailey
patryko
JA
Chris Bussard
agarithil
Stuart Gray
Cali
raspberryswirl
Jerry 🦙💝🦙
Hacker Memes
Miri
chebra
Jean
Thibug
Chris Farris 
Insecurity Princess 🌈💖🔥
Dan Goodin
Loren Kohnfelder
Daniel Reich 🇺🇦