The case of stolen Snowflake data
What we know and what we don't know
On Friday, May 31, 2024, TechTarget published a story about data that had been stolen from customers’ Snowflake database instance. A threat actor, UNC5537, was observed using stolen customer credentials to steal data from organizations using Snowflake databases. Initially, the threat actor tried to extort Snowflake for $20,000,000 to buy back their own data. When this attempt dd not succeed, the threat actor used the data both to try and extort money from the originating organizations, including Ticketmaster and Santander Bank, and by selling it on the dark web.
Snowflake rapidly issued a response and pointed to a suspected source of the problem – a demo account of a former employee that was used to access usernames and passwords.
It also appears that organizations that use multi-factor authentication are not vulnerable to this attack.
There is a lot unknown about this incident, far too much to draw any conclusions about who bears what responsibility for this unfortunate turn of events. But there are a few points to take away even at this early stage.
· Snowflake database instances were not breached. Snowflake insisted on this from the start, and I believe they are right. The data thefts came when the threat actor was able to obtain user credentials. Logging in with user credentials is not a breach – a user should be able to log in with their credentials. A subsequent revision to their response claims that Snowflake and the two security firms they are working with “have not identified evidence that this activity was cause by compromised credentials of current or former Snowflake personnel”. So not breach. But . . . .
· The bulletin did find evidence that the threat actor obtained personal credentials and access to demo accounts belonging to a former Snowflake employee. They go on to say that demo accounts are not connected to Snowflake’s production or corporate systems. I’m not a security expert, but this seems confusing to me. I can understand how stealing credentials (and their use, which was described in the TechTarget report) may not be classified as a compromise, but to me that seems to be playing with semantics. And, as my colleague expressed to me in a text exchange, “Every company has some boneheaded employees that get compromised”. I agree, but this is exactly the point. If every company is subject to this potential problem, it should be guarded against. Those safeguards at Snowflake do not seem to have been enough.
· Since it appears that multi-factor authentication can protect Snowflake database from this problem, the workaround is fairly straightforward. But it brings into sharp focus what the cloud does and what it doesn’t do. The cloud is opaque – users cannot know for sure what is going on within the cloud, and do not have administrative access to cloud Database as a Service instances. If this had been an exploit that relied on compromised code for the servers, users would be SOL until the cloud vendor fixed things. But the cloud has boundaries too, such as the network and credentials used to access cloud-based services. These are still the responsibilities of cloud users.
There will probably be lots more on this topic, especially since Snowflake’s annual user conference is this coming week. I’m sure we will learn more, and I welcome your comments and corrections.