Hudson Rock yanks report fingering Snowflake employee creds snafu for mega-leak Hudson Rock, citing legal pressure from Snowflake, has removed its online report that claimed miscreants broke into the cloud storage and analytics giant's underlying systems and stole data from potentially hundreds of customers including Ticketmaster and Santander Bank. More specifically, the infosec house reported criminals …
Anyone else find it bemusing that (a) Snowflake wants to censor things and threaten legal action? How unusual!
Meanwhile, let us ponder this...
Scenario 1: Miscreants obtain credentials for one highly privileged central account and use it to steal data from multiple clients, or
Scenario 2: Miscreants simultaneously obtain credentials for multiple unrelated client accounts, all coincidentally hosting on the same platform.
Hmmm...
I thought the original Lumma speculation was interesting....and more than plausible.
I can tell you that Snowflake session handling leaves a lot to be desired - session cookies have decent lifetimes and don't appear to distinguish between multiple user logons being used in parallel (think dev credentials and prod credentials for the same user) But that does require a user level breach at a snowflake client to grab the session cookies in the first place.
https://www.theregister.com/2024/01/02/infostealer_google_account_exploit/
This post has been deleted by its author
To be fair, if we were told that the TicketMaster and Santander breaches were due to misconfigured S3 buckets, no one would have a problem with blaming those two organizations rather than Amazon. (Or perhaps in addition to Amazon, though in recent years they've made it harder to screw up permissions quite so badly.)
I can believe two significant Snowflake customers had poor security practices and it's just a coincidence two high-profile breaches involving data stored with Snowflake happened in a short period. I can also believe this is a Snowflake problem. The explanation I find most likely is that Snowflake make it too easy for their customers to have poor security practices, and everyone involved shares in the blame.
why should they tolerate the misinformation that HudsonRock posted? Some random tool calls them and asserts something that aligns with their bias and suddenly it's fact? It was a leap too far. What's interesting is that they didn't need to do it. The most likely scenario (#2 BTW) still supports using the sorts of services they proffer, and they could have spun it as such.
https://techcrunch.com/2024/06/05/snowflake-customer-passwords-found-online-infostealing-malware/?mkt_tok=MTg4LVVOWi02NjAAAAGTjBVGRcoMzjmNgpYpzlyBhJsvYZBItEx8jo7cL8tHZmyqiRK1XwlsAeQZKhQlox6EJXHj-hY8mdLcY1C5FBAie1kuhwu8eNunOXXyi-ZbX2U&guccounter=1&guce_referrer=aHR0cHM6Ly9nby5zY21hZ2F6aW5lLmNvbS8&guce_referrer_sig=AQAAAIuannCSeAxd8KVCiCgGCLK_6wtJFFgb48KlFi7gcw2lQNgyDs3k5jrtCvvMW_uUbDn5G4bpFzsMWyu8hQnDp5VZfnlFZXzxI5Nr_r-GMjvdBt7z2q6S3C51qjr-q23t-gTXMZyKh0V3QzWt5ZV5oUO9tYI4acnykABkDgca5r4v
"This assumes that Snowflake employees can see customer DATA rather than just offering a hosting service."
I have no idea what infrastructure they're using, but it would stand to reason that if you have root access (as anyone higher than level 1 support likely has - definitely above level 2) you'll be able to do anything right down to bare metal.
Even if the container's contents are somehow locked down, you still have access to the container itself (comparable to having physical access to HDDs in a classic environment) as well as the backups.
I've no doubt there might be some mitigations which could be put into place by the client to protect themselves from a potentially malicious (or in this case compromised) host, but there's not much you can do when they effectively have access to the hardware - and how many people do you think have actually given any thought to defending against the host?
afaik know the only way to be certain snowflake dont have access is to provide your own Encryption keys... this is an option that most people DONT take up.
FWIW - you have to explicitly enable Snowflake support user access to your account via a flag on one of your existing users accounts. Whether this is "real" or PR I dont know.
If the data you upload is already encrypted1 locally, then Snowflake can't see anything useful.
On the other hand, that would also mean you couldn't do much in the way of analytics, which I gather is the point of uploading data to Snowflake in the first place.
In principle, a customer could use some variety of format-preserving or search-preserving encryption, which is popular in some database applications. That seeks to conceal some information while revealing enough to perform some operations.2 It's controversial, but it would at least increase the work factor for a Snowflake employee to extract most of the sensitive information. (That could be quantified, within some error bounds, by using the attack from Grubs et al and applying differential-privacy analysis.)
1For suitably large values of "encrypted", such as IND-CCA.
2Prolepsis: No, this is not homomorphic encryption. Homomorphic encryption is going to be mostly useless in an analytics-as-a-service use case. Don't even bring it up, OK?
If Snowflake continue down the route they are pushing it is passing the failure to the customer, not them. It is all about risk and fine mitigation.
They, just like many other tech providers will do anything to make a security breach someone else's fault.
As others have commented it does seem a little coincidental to have two breaches from the same platform.
But on the other hand we are mere techy mortals who try to make stuff work. It is not our job to reason how secure a platform is because all that matters is manglement have told us to use it so it muse be okay.
Hopefully they don't run afoul of California law. I imagine some customer of theirs is based there? If anything vaguely like what Hudson Rock says happened happened, AND they are going around trying to suppress it -- well, they would take a VERY dim view of that there. They have probably the strictest laws in the country requiring breaches to be disclosed, and prohibit trying to minimize the extent of it or sweeping the cause under the rug.
The intent of these laws was twofold -- first, to prevent a company behaving like TJ Maxx did years ago. They decided it was less expensive to spend 0 effort on security, have their credit card info stolen multiple times and just not tell the public, than to spend any efforts on security. I don't recall how it finally became public, but it certainly blew up in their faces once it did, since by then it'd been ongoing for years. Now, they are now breaking the law if they find out about a breach and don't make it public fairly quickly.
Second, the description of what happened is so people can make an informed decision -- I mean, if a company was broken into by a sophisticated group using sophisticated techniques, the breach was rapidly detected, the data they got was encrypted anyway and likely unusable, and they have plans on how to prevent it in the future.... that's a lot different than having all the stuff stored on a file share (or cloud bucket) accessible by everyone in the company (or why not, maybe public to the world!), no firewalls, no compartmentalization of info, no encryption or access controls, and in fact maybe they don't even know how long the bad actors were going through the data. People may wish to quit doing business with a company that is that cavalier with their data security.
In the past, companies with good security that got broken into anyway would happily give a description of what happened (since it partly showed how their security limited the amount of data pulled and possibly means none of it is useable); companies in the second category, once they were required to disclose a breach, would be vague and evasive since admitting to having no internal security would be bad for business (I mean, my recollection is TJ Maxx lost quite a bit of business, and they are a department store, not in IT.)
In this case, I doubt Snowflake is as remiss as all that. But they may want to be careful about trying to shift blame if that is inaccurate.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
