What Snowflake isn’t saying about its customers’ data breaches

Snowflake’s security problems are, for lack of a greater word, growing after a recent wave of customer data theft.

After Ticketmaster became the primary company to link its recent data breach to cloud computing company Snowflake, loan comparison site LendingTree confirmed that its QuoteWizard subsidiary had data stolen from Snowflake.

“We can confirm that we use Snowflake for our business operations and have been notified by Snowflake that this incident may have impacted data from our QuoteWizard subsidiary,” Megan Greuling, a spokeswoman for LendingTree, told TechCrunch.

“We take these matters seriously and initiated an internal investigation immediately after receiving information from (Snowflake),” the spokesman said. “At this time, there does not appear to be an impact on consumer financial account information or LendingTree’s parent information,” the spokesperson added, declining to comment further, citing the continuing investigation.

As increasingly affected customers come forward, Snowflake has said little other than a brief statement on its website reiterating that there was no data breach on its own systems, but somewhat that customers weren’t using multi-factor authentication, or MFA, a security measure that Snowflake doesn’t implement or require its customers to enable by default. Snowflake itself caught wind of the incident, claiming that a former worker’s “demo” account was compromised since it was only protected by a username and password.

In an announcement Friday, Snowflake firmly stood by its response thus far, saying its position “remains unchanged.” Referring to his earlier statement on Sunday, Snowflake’s chief information security officer, Brad Jones, said it was a “targeted campaign targeting users using single-factor authentication” and using credentials stolen from information-stealing malware or obtained through previous data breaches.

The lack of MFA appears to be causing cybercriminals to download massive amounts of data from Snowflake customer environments that weren’t protected by an extra layer of security.

Earlier this week, TechCrunch found lots of of Snowflake customer credentials stolen online by password-stealing malware that was infecting the computers of employees who had access to their employer’s Snowflake environment. The credential count suggests there’s a risk for Snowflake customers who haven’t yet modified their passwords or enabled MFA.

Over the course of the week, TechCrunch sent Snowflake greater than a dozen questions about the continuing incident affecting its customers as we proceed to report on this story. Snowflake refused to reply our questions a minimum of six times.

These are among the questions we ask ourselves and why.

It shouldn’t be yet known what number of Snowflake customers are affected or whether Snowflake already knows about it.

Snowflake said it has thus far notified “a limited number of Snowflake customers” that the corporate believes could have been affected. On its website, Snowflake says it has greater than 9,800 customers, including technology corporations, telecommunications corporations and health care providers.

Snowflake spokeswoman Danica Stańczak declined to say whether the variety of affected customers was within the tens, tens, lots of or more.

It’s likely that despite several customer breaches reported this week, we’re only just starting to know the dimensions of this incident.

Even for Snowflake, it might not be clear how many shoppers are affected, as the corporate will either should depend on its own data, equivalent to logs, or discover directly from the affected customer.

It is unclear how quickly Snowflake could have learned about the hacking of its customers’ accounts. In an announcement, Snowflake said it became aware of “threat activity” on May 23 – accessing customer accounts and downloading their content – but later found evidence of intrusions dating back to around mid-April, suggesting the corporate had some data on whom he can rely.

But that also leaves open the query of why Snowflake didn’t detect the exfiltration of huge amounts of customer data from its servers until much later in May, and if that’s the case, why Snowflake didn’t publicly notify its customers earlier.

Mandiant, an incident response company that Snowflake called to assist reach customers he told Bleeping Computer in late May that the corporate has been helping affected organizations for “several weeks.”

We still do not know what was in the previous Snowflake worker’s demo account and whether it’s related to customer data breaches.

A key line from Snowflake’s statement reads: “We found evidence that the threat actor obtained personal credentials and accessed demo accounts belonging to a former Snowflake employee. It did not contain sensitive data.”

An evaluation by TechCrunch shows that among the stolen customer credentials related to the information-stealing malware include data belonging to a then-Snowflake worker.

As we have previously noted, TechCrunch shouldn’t be naming the worker since it’s unclear whether he did anything improper. The indisputable fact that Snowflake was caught failing to implement MFA, allowing cybercriminals to download data from a then-employee’s “demo” account using only their username and password, highlights a fundamental problem in Snowflake’s security model.

However, it’s unclear what role, if any, this demo account plays within the theft of customer data, because it shouldn’t be yet known what data was stored on it or whether it contained data from other Snowflake customers.

Snowflake wouldn’t say what role, if any, the then-Snowflake worker’s demo account played within the recent customer security breaches. Snowflake reiterated that the demo account “did not contain sensitive data,” but repeatedly declined to say how the corporate defines what it considers “sensitive data.”

We asked whether Snowflake considers individuals’ personal information to be sensitive data. Snowflake declined to comment.

It is unclear why Snowflake didn’t proactively reset passwords or require and implement the usage of MFA on its customer accounts.

It’s commonplace for corporations to force password resets on their customers after a data breach. But if you happen to ask Snowflake, there isn’t a violation. And while this will be true within the sense that there was no apparent breach of central infrastructure, Snowflake customers are fairly often exposed to security breaches.

Snowflake advises his clients involves resetting and rotating Snowflake credentials and forcing MFA on all accounts. Snowflake previously told TechCrunch that its customers care about their very own security: “In Snowflake’s shared responsibility model, customers are responsible for enforcing MFA against their users.”

However, since Snowflake’s customer data thefts involve the usage of stolen usernames and passwords for accounts that will not be protected by MFA, it’s remarkable that Snowflake didn’t intervene on behalf of its customers to guard their accounts with a reset passwords or forced MFA.

This shouldn’t be unheard of. Last 12 months, cybercriminals deleted 6.9 million user records and genetic data from 23andMe accounts that weren’t protected with MFA. 23andMe fastidiously reset user passwords to forestall further scraping attacks after which required MFA for all of its user accounts.

We asked Snowflake if the corporate plans to reset passwords for its customer accounts to forestall possible further breaches. Snowflake declined to comment.

According to them, Snowflake appears to be moving towards implementing MFA by default Runtime technical news site, quoting Snowflake CEO Sridhar Ramaswamy in an interview this week. This was later confirmed by Snowflake’s CISO Jones in a Friday update.

“We are also developing a plan to require our customers to implement advanced security controls such as multi-factor authentication (MFA) or network policies, especially for privileged Snowflake customer accounts,” Jones said.

No timetable for the implementation of the plan was provided.