Last week, we believed the huge Ticketmaster breach came via AWS. But now, Ticketmaster says the 1.3TB database was actually hosted on Snowflake. And reports are coming in of several more massive leaks from other Snowflake customers.
Some reports also blame Snowflake for lax security, including an employee losing control of a powerful authentication credential that gave access to the whole kit and caboodle. A security firm, Hudson Rock, made the allegation and quickly felt the ire of Snowflake’s lawyers.
Snowflake denies it’s been hacked. In today’s SB Blogwatch, we’re told it’s the customers’ fault.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Influencers.
What’s the craic? TechCrunch’s Zack Whittaker reports: The ticketing giant said its stolen database was hosted by Snowflake
“Declined to comment”
Ticketmaster [parent] Live Nation confirmed the data breach in a filing with government regulators [and] that it “identified unauthorized activity within a third-party cloud database.” … A spokesperson for Ticketmaster, who would not provide their name but responded from the company’s media email address, told TechCrunch that its stolen database was hosted on Snowflake, a Boston-based cloud storage and analytics company.
…
Snowflake spokesperson Danica Stanczak declined to comment on the record. … Live Nation’s communications chief Kaitlyn Henrich also would not comment on the record.
Oh, so it’s Snowflake’s fault? Recorded Future’s Jonathan Greig passes on the company’s denial: Hackers hawk stolen info of 560 million
Snowflake confirmed that some of its customers have been under attack by threat actors. The company … said the attacks appear to be a targeted campaign “directed at users with single-factor authentication,” [and] denying that there was any vulnerability or issue with the company’s products.
All of which makes Jessica Lyons scratch her head: Hudson Rock yanks report fingering Snowflake employee
“Enable MFA ASAP”
Hudson Rock … has removed its online report that claimed miscreants broke into [its] systems and stole data from potentially hundreds of customers including Ticketmaster and Santander Bank. More specifically, the infosec house reported criminals got hold of a Snowflake employee’s work credentials … and used that privileged access to exfiltrate tons of data from Snowflake’s customer cloud accounts. Snowflake said that didn’t happen.
…
Snowflake … denied its underlying security was breached. … Snowflake said if any customer data was taken from its servers, it may have been obtained by thieves who got hold of individual customers’ account credentials … where those accounts did not have two-factor authentication … and not by a general compromise of Snowflake’s security.
…
Snowflake is walking a tightrope: … It doesn’t want people to think its servers were compromised at a fundamental level, [but] it has to tell customers to enable MFA ASAP. … You’d hope that MFA would be forced on for customers going forward.
Is this the Streisand Effect? Kevin Beaumont says Snowflake is “having a bad month … in terms of optics:”
We have what appears to be the world’s biggest data breach. … 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. [They] make various claims which sound questionable, but … 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. … Despite Snowflake saying the … blog is inaccurate (and parts most probably are), the Snowflake credentials bit is accurate.
…
Snowflake themselves fell into this trap, both by not using multi factor authentication on their demo environment and by failing to disable a leaver’s access. … They can point out customers messed up, but they messed up too. … Something is wrong at Snowflake. … They need to, at an engineering and secure-by-design level, go back and review how authentication works: … Given the number of victims and scale of the breach … the status quo hasn’t worked.
…
I feel bad for Snowflake on a human level. … 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. … When you transfer your security risk to a provider, they … will throw you under the bus to save themselves. … There’s more to this story than disclosed. I know … and all eyes are on Snowflake.
Ouch. Whichever version of events is true, skilled says Snowflake screwed up:
– Credentials acquired for a Ticketmaster account. …
– Log-in effortlessly because of single-factor auth.
– Gain immediate access to a production environment.
…
If the process outlined above is how the [database] was dumped, then what the hell? That’s the most ridiculous and crazy and easily the dumbest blunder of all time, is it not?
Could someone explain what Snowflake does? Kevin McMurtrie has a good go:
It’s a big database. Say you have two antiquated databases that will drop dead from a single gust of wind plus 40 disorganized microservice databases. You can’t query that for analytics and marketing. You write scripts to extract data updates, convert the format, and send it to Snowflake. ETL scripts – extract, transform, load. Now it’s all on a system optimized for analytics.
…
If your company is handling data correctly, you drop all personal data in the ETL scripts. You send only IDs that you need to correlate everything for your analytics. This means Snowflake and your analytics departments can dig through all the data all they want without any privacy issues. If customers need to be contacted, it can be through a secured/restricted system that looks up the IDs.
That “if” is doing a lot of hard work. u/Cold-Estimate613 is concerned:
I’m not a direct customer but concerned about supply chain. … Looks to be either incidents on the customer sides or indeed a corporate breach, depending on whom you believe. Personally, I’d sooner trust Snowflake over a threat actor and some security company … trying to sell me something, but something to track closely.
Yes, it’s right to be suspicious of Hudson Rock’s motivation. gregates speculates:
This is just pure speculation, but it kind of looks like the hacker was being ignored by Snowflake, so they somehow got in touch with Hudson Rock and offered them this promotional opportunity … with the goal of retaliating against Snowflake for failing to pay the ransom. And Hudson Rock agreed to play along and hype up the story.
Whom to believe, though? I think ThinkingMonkey isn’t sure:
I’m not sure who to believe. The crooks could be lying of course, since they’re mad Snowflake wouldn’t pay up, but Snowflake has a whole lot … to lose if it looks like they can’t be trusted to secure data, so a denial is probably in order, true or not. … It’s dizzying.
Meanwhile, this Anonymous Coward makes the obvious gag:
Well, what else would a snowflake say? It is never their fault—their parents told them so.
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites—so you don’t have to. Hate mail may be directed to @RiCHi, @richij, @[email protected], @richi.bsky.social or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Image sauce: Aaron Burden (via Unsplash; leveled and cropped)
Recent Articles By Author