Snowflake’s security woes following a recent spate of customer data thefts are, for lack of a better word, snowballing.
After Ticketmaster was the first company to link its recent data breach to cloud data company Snowflake, loan comparison site LendingTree has now confirmed that its subsidiary QuoteWizard had data stolen from Snowflake.
“We can confirm that we use Snowflake for our business operations and were informed by them that our affiliate, QuoteWizard, may have had data impacted by this incident,” LendingTree spokeswoman Megan Greuling told TechCrunch.
“We are taking these matters seriously and immediately upon notification [Snowflake] an internal investigation has been launched,” the spokesperson said. “As of this time, it does not appear that consumer financial account information was affected, nor is information from the parent entity, LendingTree,” the spokesperson added, declining to comment further, citing its ongoing investigation.
As more affected customers emerge, Snowflake has said little beyond a brief statement on its website reiterating that there was no data breach of its own systems, but that its customers were not using multi-factor authentication, or MFA — a security measure that Snowflake does not enforce or require its customers to enable by default. Snowflake himself was caught off guard by the incident, saying a former employee’s “demo” account was compromised because it was only protected by a username and password.
In a statement on Friday, Snowflake held tight to its response so far, saying its position “remains unchanged.” Citing his earlier statement on Sunday, Snowflake chief information security officer Brad Jones said this was a “targeted campaign targeting users with single-factor authentication” and using credentials stolen from information-stealing malware or obtained from previous breaches. data.
The lack of MFA appears to be how cybercriminals downloaded massive amounts of data from Snowflake customer environments that were not protected by the added layer of security.
TechCrunch earlier this week found hundreds of Snowflake customer credentials online that had been stolen by password-stealing malware that infected the computers of employees accessing their employer’s Snowflake environment. The number of credentials suggests that there is still risk for Snowflake customers who have not yet changed their passwords or enabled MFA.
Throughout the week, TechCrunch sent more than a dozen questions to Snowflake about the ongoing incident affecting its customers as we continue to cover the story. Snowflake refused to answer our questions at least six times.
These are some of the questions we ask and why.
It is not yet known how many Snowflake customers are affected or if Snowflake knows yet.
Snowflake said that to date it has notified a “limited number of Snowflake customers” that the company believes may have been affected. On its website, Snowflake says it has more than 9,800 customers, including technology companies, telecommunications and healthcare providers.
Snowflake spokeswoman Danica Stanczak declined to say whether the number of affected customers was dozens, dozens, hundreds or more.
It’s likely that despite the few reported customer breaches this week, we’re only in the early days of understanding the scale of this incident.
It may not even be clear to Snowflake how many of its customers are still affected, as the company will either have to rely on its own data, such as logs, or learn directly from an affected customer.
It is not known how soon Snowflake could have learned about the hacks on its customers’ accounts. Snowflake’s statement said it became aware on May 23 of the “threat activity” – accessing customer accounts and downloading their content – but then found evidence of intrusions dating back to no more specific time frame than mid-April, indicating the company has some data to rely on.
But that also leaves open the question of why Snowflake didn’t at the time detect the export of large amounts of customer data from its servers until much later in May, or if it did, why Snowflake didn’t publicly notify its customers sooner.
Incident response firm Mandiant, which Snowflake called on to help reach its customers, he told Bleeping Computer in late May that the company had already been helping affected organizations for “several weeks.”
We still don’t know what was in the ex-Snowflake employee’s test account or if it’s related to the customer data breaches.
A key line from Snowflake’s statement reads: “We did find evidence that a threat actor obtained personal credentials and accessed test accounts belonging to a former Snowflake employee. It did not contain sensitive data.”
Some of the stolen customer credentials linked to information-stealing malware include those belonging to a then-Snowflake employee, according to a TechCrunch review.
As we previously noted, TechCrunch is not naming the employee, as it’s not clear they did anything wrong. The fact that Snowflake was tricked by its own lack of MFA enforcement into allowing cybercriminals to download data from a then-employee’s “demo” account using only his username and password highlights a fundamental problem in Snowflake’s security model .
However, it remains unclear what role, if any, this test account played in the theft of customer data, because it is not yet known what data it was stored on or if it contained data from other Snowflake customers.
Snowflake declined to say what role, if any, the then-Snowflake employee’s demo account played in the recent customer breaches. Snowflake reiterated that the test account “did not contain sensitive data,” but repeatedly declined to say how the company defines what it considers “sensitive data.”
We asked whether Snowflake believes that individuals’ personally identifiable information is sensitive data. Snowflake declined to comment.
It is unclear why Snowflake has not proactively reset passwords or required and enforced the use of MFA on its customers’ accounts.
It’s not uncommon for companies to be forced to reset their customers’ passwords after a data breach. But if you ask Snowflake, there was no breach. And while that may be true in the sense that there hasn’t been an apparent compromise of its core infrastructure, Snowflake’s customers are heavily compromised.
of the snowflake advice to its customers is to reset and switch Snowflake credentials and enforce MFA on all accounts. Snowflake previously told TechCrunch that its customers are prepared for their own security: “Under Snowflake’s shared responsibility model, customers are responsible for enforcing MFA with their users.”
But because these Snowflake customer data thefts are linked to the use of stolen account usernames and passwords that are not protected by MFA, it is unusual for Snowflake not to have intervened on behalf of its customers to protect their accounts with password resets or MFA enforcement.
It’s not unheard of. Last year, cybercriminals hacked 6.9 million users and genetic records from 23andMe accounts that weren’t protected by MFA. 23andMe reset user passwords without caution to prevent further scraping attacks and then required the use of MFA on all of its users’ accounts.
We asked Snowflake if the company planned to reset the passwords of its customers’ accounts to prevent any further hacks. Snowflake declined to comment.
Snowflake seems to be moving towards MFA deployment by default, according to Runtime news technology website, citing Snowflake CEO Sridhar Ramaswamy in an interview this week. This was later confirmed by Snowflake’s CISO Jones in Friday’s briefing.
“We are also developing a plan to require our customers to implement advanced security controls, such as multi-factor authentication (MFA) or network policies, specifically for privileged Snowflake customer accounts,” Jones said.
No timeline was given for the plan.
Do you know more about Snowflake account hacks? Getting in touch. To contact this reporter, please contact Signal and WhatsApp at +1 646-755-8849 or via email. You can also send files and documents via SecureDrop.
