Snowflake’s security problems following a recent spate of customer data thefts are, for want of a better word, snowballing.
After Ticketmaster was the first company to link its recent data breach to the cloud data company Snowflake, loan comparison site LendingTree has now confirmed its QuoteWizard subsidiary had data stolen from Snowflake.
“We can confirm that we use Snowflake for our business operations, and that we were notified by them that our subsidiary, QuoteWizard, may have had data impacted by this incident,” Megan Greuling, a spokesperson for LendingTree, told Madconsole.
“We take these matters seriously, and immediately after hearing from [Snowflake] launched an internal investigation,” the spokesperson said. “As of this time, it does not appear that consumer financial account information was impacted, nor information of the parent entity, LendingTree,” the spokesperson added, declining to comment further citing its ongoing investigation.
As more affected customers come forward, Snowflake has said little beyond a brief statement on its website reiterating that there wasn’t a data breach of its own systems, rather its customers were not using multi-factor authentication, or MFA — a security measure that Snowflake doesn’t enforce or require its customers to enable by default. Snowflake was itself caught out by the incident, saying a former employee’s “demo” account was compromised because it was only protected with a username and password.
In a statement Friday, Snowflake held strong on its response so far, stating its position “remains unchanged.” Citing its earlier statement on Sunday, Snowflake chief information security officer Brad Jones said that this was a “targeted campaign directed at users with single-factor authentication” and using credentials stolen from info-stealing malware or obtained from previous data breaches.
The lack of MFA appears to be how cybercriminals downloaded huge amounts of data from Snowflake customers’ environments, which weren’t protected by the additional security layer.
Madconsole earlier this week found online hundreds of Snowflake customer credentials stolen by password-stealing malware that infected the computers of employees who have access to their employer’s Snowflake environment. The number of credentials suggests there remains a risk to Snowflake customers who have yet to change their passwords or enable MFA.
Throughout the week, Madconsole has sent more than a dozen questions to Snowflake about the ongoing incident affecting its customers as we continue to report on the story. Snowflake declined to answer our questions on at least six occasions.
These are some of the questions we’re asking, and why.
It’s not yet known how many Snowflake customers are affected, or if Snowflake knows yet.
Snowflake said it has to date notified a “limited number of Snowflake customers” who the company believes may have been affected. On its website, Snowflake says it has more than 9,800 customers, including tech companies, telcos, and healthcare providers.
Snowflake spokesperson Danica Stanczak declined to say if the number of affected customers was in the tens, dozens, hundreds, or more.
It’s likely that, despite the handful of reported customer breaches this week, we are only in the early days of understanding the scale of this incident.
It may not be clear even to Snowflake how many of its customers are yet affected, since the company will either have to rely on its own data, such as logs, or finding out directly from an affected customer.
It’s not known how soon Snowflake could have known about the intrusions into its customers’ accounts. Snowflake’s statement said it became aware on May 23 of the “threat activity” — the accessing of customer accounts and downloading their contents — but subsequently found evidence of intrusions dating back to a no-more-specific timeframe than mid-April, suggesting the company does have some data to rely on.
But that also leaves open the question why Snowflake did not detect at the time the exfiltration of large amounts of customers’ data from its servers until much later in May, or if it did, why Snowflake didn’t publicly alert its customers sooner.
Incident response firm Mandiant, which Snowflake called in to help with outreach to its customers, told Bleeping Computer at the end of May that the firm had already been helping affected organizations for “several weeks.”
We still don’t know what was in the former Snowflake employee’s demo account, or if it is relevant to the customer data breaches.
A key line from Snowflake’s statement says: “We did find evidence that a threat actor obtained personal credentials to and accessed demo accounts belonging to a former Snowflake employee. It did not contain sensitive data.”
Some of the stolen customer credentials linked to info-stealing malware include those belonging to a then-Snowflake employee, according to a review by Madconsole.
As we previously noted, Madconsole is not naming the employee as it’s not clear they did anything wrong. The fact that Snowflake was caught out by its own lack of MFA enforcement 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.
But it remains unclear what role, if any, that this demo account has on the customer data thefts because it’s not yet known what data was stored within, or if it contained data from Snowflake’s other customers.
Snowflake declined to say what role, if any, the then-Snowflake employee’s demo account has on the recent customer breaches. Snowflake reiterated that the demo account “did not contain sensitive data,” but repeatedly declined to say how the company defines what it considers “sensitive data.”
We asked if Snowflake believes that individuals’ personally identifiable information is sensitive data. Snowflake declined to comment.
It’s unclear why Snowflake hasn’t proactively reset passwords, or required and enforced the use of MFA on its customers’ accounts.
It’s not unusual for companies to force-reset their customers’ passwords following a data breach. But if you ask Snowflake, there has been no breach. And while that may be true in the sense that there has been no apparent compromise of its central infrastructure, Snowflake’s customers are very much getting breached.
Snowflake’s advice to its customers is to reset and rotate Snowflake credentials and enforce MFA on all accounts. Snowflake previously told Madconsole that its customers are on the hook for their own security: “Under Snowflake’s shared responsibility model, customers are responsible for enforcing MFA with their users.”
But since these Snowflake customer data thefts are linked to the use of stolen usernames and passwords of accounts that aren’t protected with MFA, it’s unusual that Snowflake has not intervened on behalf of its customers to protect their accounts with password resets or enforced MFA.
It’s not unprecedented. Last year, cybercriminals scraped 6.9 million user and genetic records from 23andMe accounts that weren’t protected with MFA. 23andMe reset user passwords out of caution to prevent further scraping attacks, and subsequently 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 possible further intrusions. Snowflake declined to comment.
Snowflake appears to be moving towards rolling out MFA by default, according to tech news site Runtime, quoting Snowflake CEO Sridhar Ramaswamy in an interview this week. This was later confirmed by Snowflake’s CISO Jones in the Friday update.
“We are also developing a plan to require our customers to implement advanced security controls, like multi-factor authentication (MFA) or network policies, especially for privileged Snowflake customer accounts,” said Jones.
A timeframe for the plan was not given.
Do you know more about the Snowflake account intrusions? Get in touch. To contact this reporter, get in touch on Signal and WhatsApp at +1 646-755-8849, or by email. You can also send files and documents via SecureDrop.
