Cloud AI Data platform Snowflake are having a bad month. Due to teenager threat actors and cybersecurity of its own customers… and its own cybersecurity, too, in terms of optics.
There are several large data breaches playing out in the media currently. For example, Ticketmaster owner Live Nation filed an 8-K with the SEC for potentially the largest data breach ever, claimed to be 560 million customers.
They finger Snowflake as part of the data breach:
Additionally incidents are running at multiple other companies who are Snowflake customers where full databases have been taken — I have spoken to people in multiple industries at large corporations where they’ve had significant data exfiltration in May via Snowflake.
The Australian security services have issued an advisory:
They say they are “aware of successful compromises of several companies utilising Snowflake environments”.
Snowflake themselves have put out Indicators of Compromise for “threat activity” over the weekend, saying to look for connections into their platform from the user agent “rapeflake”:
Additionally, a threat actor claims they gained access to Snowflake itself and their customers using infostealers:
https://web.archive.org/web/20240531140540/https://hudsonrock.com/blog/snowflake-massive-breach-access-through-infostealer-infection
The threat actor makes various claims which sound questionable… but, well, Snowflake have confirmed some of it is true while crowing to the media and customers the blog isn’t true. It is Schrödinger's Blog.
The threat actors here, from what I’ve managed to establish, are a teen crimeware group who’ve been active publicly on Telegram for a while.
relax, it’s parodyLet’s recap
We have what appears to be the world’s biggest data breach — in terms of impacted individuals — playing out with Snowflake as the vendor linking the victims. A lot of data has gone walkies.
Snowflake, for those won’t know, is an AI data platform where you shove vast amounts of data in and use it. It allows you to do this with effectively no security.
I feel bad for Snowflake on a human level as they’re in a bad situation — this is a potentially business ending event for them — so they have to use every lever possible to point the fingers at their own customers as being negligent over “rapeflake” activity to avoid responsibility. And to be clear, some of this is their customer’s responsibility.
But also.. Snowflake have to own this issue and face straight into it to survive, as there’s an extremely high chance this is going to play out publicly over the coming weeks and months.
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.
What you’re sold vs what you get often don’t align — I’ve worked for a cloud provider, you don’t want to see how the sausage is made (but you can read about it in Microsoft’s CSRB report) — and there’s no real accountability for the provider.
There will be much more of this to come with cloud data providers in the future, is what I’m saying.
So what actually happened?
Despite Snowflake saying the Hudson Rock blog is inaccurate (and parts most probably are), the Snowflake credentials bit is accurate.
Snowflake say:
“we did find evidence that a threat actor obtained personal credentials to and accessed demo accounts belonging to a former Snowflake employee. It did not contain sensitive data. Demo accounts are not connected to Snowflake’s production or corporate systems. The access was possible because the demo account was not behind Okta or Multi-Factor Authentication (MFA), unlike Snowflake’s corporate and production systems.”
Snowflake have incident response stood up, with Crowdstrike (and Mandiant involved).
They say the cause of the malicious activity (read: database downloads) is:
- this appears to be a targeted campaign directed at users with single-factor authentication;
- as part of this campaign, threat actors have leveraged credentials previously purchased or obtained through infostealing malware;
So what happens, essentially, is info stealers were used to gain access to Snowflake databases using their customer’s stolen credentials, using the client name rapeflake (side note to threat actor over that name: really?).
Snowflake themselves fell into this trap, by both not using multi factor authentication on their demo environment and failing to disable a leaver’s access. Shit happens, incidents happen, and while Snowflake may present themselves as having no platform breach, they themselves also fell into the same problem and in terms of optics isn’t great.. as they can point out customers messed up, but they messed up too.
You may know about infostealers as I recently wrote about them being a huge threat when it comes to Microsoft Copilot+ Recall allowing full data threat of everything you’ve ever viewed — a feature you should absolutely disable in Windows 11.
The Copilot+ logo is a warning sign from Microsoft that the PC is insecure. Thanks, Microsoft!Mandiant themselves have this to say about infostealers this weekend:
How to protect yourself
If you use Snowflake, you need to go first of all enable multi-factor authentication and tighten authentication to your database as a top priority. Then, you need to go back and look at the access logs on Snowflake itself and check who has been using your data — you cannot rely on Snowflake doing this for you.
Infostealers are a significant problem — it has long since outpaced botnets etc in the real world — and the only real solution is robust multi-factor authentication (and ideally getting rid of passwords altogether by replacing them with secure authentication).
There are companies offering services where you can buy your own stolen credentials back, and then you can change user’s passwords. I don’t like this approach. The reason is those vendors often buy those credentials from ‘credential brokers’, which translates to funding the criminal hackers who steal them in the first place. As a customer you end up proxy funding the threat actors you’re trying to deal with. Additionally, it is a huge user impact to have their password changed, and it doesn’t fix the problem.
Tightening authentication fixes the problem. Ask the Snowflake victims how they have fixed the problem — it’s through robust MFA.
Wider point
Something is wrong at Snowflake when it comes to authentication. Snowflake themselves fell victim to this incident, albeit with a demo tenant.
They need to, at an engineering and secure by design level, go back and review how authentication works — as it’s pretty transparent that given the number of victims and scale of the breach that the status quo hasn’t worked. Secure authentication should not be optional. And they’ve got to be completely transparent about steps they are taking off the back of this incident to strengthen things.
For cloud providers in general, they need to be more robust in terms of secure defaults or risk being dragged into this kind of situation.
For Microsoft, they need to recall Recall or they will pour petrol onto the flames and make the infostealer problem far worse.
And finally, a song:
Ninja edit just after publishing: people are pinging me to say there’s more to this story than disclosed. I know. It will be a developing story and all eyes are on Snowflake.