\n<\/p>\n
Snowflake\u2019s security problems following a recent spate of customer data thefts are, for want of a better word, snowballing.<\/p>\n
After Ticketmaster was the first company to link its recent data breach to the cloud data company Snowflake<\/a>, loan comparison site LendingTree has now confirmed its QuoteWizard subsidiary had data stolen from Snowflake.<\/p>\n \u201cWe 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,\u201d Megan Greuling, a spokesperson for LendingTree, told TechCrunch.<\/p>\n \u201cWe take these matters seriously, and immediately after hearing from [Snowflake] launched an internal investigation,\u201d the spokesperson said. \u201cAs of this time, it does not appear that consumer financial account information was impacted, nor information of the parent entity, LendingTree,\u201d the spokesperson added, declining to comment further citing its ongoing investigation.<\/p>\n As more affected customers come forward, Snowflake has said little beyond a brief statement on its website<\/a> reiterating that there wasn\u2019t a data breach of its own systems, rather its customers were not using multi-factor authentication, or MFA \u2014\u00a0a security measure that Snowflake doesn\u2019t enforce or require its customers to enable by default. Snowflake was itself caught out by the incident, saying a former employee\u2019s \u201cdemo\u201d account was compromised because it was only protected with a username and password.<\/p>\n In a statement Friday, Snowflake held strong on its response so far, stating its position \u201cremains unchanged.\u201d Citing its earlier statement on Sunday, Snowflake chief information security officer Brad Jones said that this was a \u201ctargeted campaign directed at users with single-factor authentication\u201d and using credentials stolen from info-stealing malware or obtained from previous data breaches.<\/p>\n The lack of MFA appears to be how cybercriminals downloaded huge amounts of data from Snowflake customers\u2019 environments, which weren\u2019t protected by the additional security layer.<\/p>\n TechCrunch earlier this week found online hundreds of Snowflake customer credentials stolen by password-stealing malware<\/a> that infected the computers of employees who have access to their employer\u2019s Snowflake environment. The number of credentials suggests there remains a risk to Snowflake customers who have yet to change their passwords or enable MFA.<\/p>\n Throughout the week, TechCrunch 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.\u00a0<\/p>\n These are some of the questions we\u2019re asking, and why.<\/p>\n Snowflake said it has to date notified a \u201climited number of Snowflake customers\u201d 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.<\/p>\n Snowflake spokesperson Danica Stanczak declined to say if the number of affected customers was in the tens, dozens, hundreds, or more.<\/p>\n It\u2019s 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.<\/p>\n 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.<\/p>\n It\u2019s not known how soon Snowflake could have known about the intrusions into its customers\u2019 accounts. Snowflake\u2019s statement said it became aware on May 23 of the \u201cthreat activity\u201d \u2014 the accessing of customer accounts and downloading their contents \u2014 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.\u00a0<\/p>\n But that also leaves open the question why Snowflake did not detect at the time the exfiltration of large amounts of customers\u2019 data from its servers until much later in May, or if it did, why Snowflake didn\u2019t publicly alert its customers sooner.<\/p>\n Incident response firm Mandiant, which Snowflake called in to help with outreach to its customers, told Bleeping Computer at the end of May<\/a> that the firm had already been helping affected organizations for \u201cseveral weeks.\u201d<\/p>\n A key line from Snowflake\u2019s statement says: \u201cWe 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.\u201d<\/p>\n Some of the stolen customer credentials linked to info-stealing malware include those belonging to a then-Snowflake employee, according to a review by TechCrunch.<\/p>\n As we previously noted<\/a>, TechCrunch is not naming the employee as it\u2019s 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\u2019s \u201cdemo\u201d account using only their username and password highlights a fundamental problem in Snowflake\u2019s security model.\u00a0<\/p>\n But it remains unclear what role, if any, that this demo account has on the customer data thefts because it\u2019s not yet known what data was stored within, or if it contained data from Snowflake\u2019s other customers.<\/p>\n Snowflake declined to say what role, if any, the then-Snowflake employee\u2019s demo account has on the recent customer breaches. Snowflake reiterated that the demo account \u201cdid not contain sensitive data,\u201d but repeatedly declined to say how the company defines what it considers \u201csensitive data.\u201d\u00a0<\/p>\n We asked if Snowflake believes that individuals\u2019 personally identifiable information is sensitive data. Snowflake declined to comment.\u00a0<\/p>\n It\u2019s not unusual for companies<\/a> to force-reset their customers\u2019 passwords<\/a> 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\u2019s customers are very much getting breached.<\/p>\n Snowflake\u2019s advice to its customers<\/a> is to reset and rotate Snowflake credentials and enforce MFA on all accounts. Snowflake previously told TechCrunch that its customers are on the hook for their own security: \u201cUnder Snowflake\u2019s shared responsibility model, customers are responsible for enforcing MFA with their users.\u201d<\/p>\n But since these Snowflake customer data thefts are linked to the use of stolen usernames and passwords of accounts that aren\u2019t protected with MFA, it\u2019s unusual that Snowflake has not intervened on behalf of its customers to protect their accounts with password resets or enforced MFA.<\/p>\n It\u2019s not unprecedented. Last year, cybercriminals scraped 6.9 million user and genetic records from 23andMe accounts that weren\u2019t protected with MFA. 23andMe reset user passwords out of caution to prevent further scraping attacks<\/a>, and subsequently required the use of MFA on all of its users\u2019 accounts<\/a>.\u00a0<\/p>\n We asked Snowflake if the company planned to reset the passwords of its customers\u2019 accounts to prevent any possible further intrusions. Snowflake declined to comment.<\/p>\n Snowflake appears to be moving towards rolling out MFA by default, according to tech news site Runtime<\/a>, quoting Snowflake CEO Sridhar Ramaswamy in an interview this week. This was later confirmed by Snowflake\u2019s CISO Jones in the Friday update.<\/p>\n \u201cWe 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,\u201d said Jones.\u00a0<\/p>\n A timeframe for the plan was not given.<\/p>\n 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.<\/a> You can also send files and documents via SecureDrop<\/a>.<\/em><\/p>\nIt\u2019s not yet known how many Snowflake customers are affected, or if Snowflake knows yet.<\/h4>\n
We still don\u2019t know what was in the former Snowflake employee\u2019s demo account, or if it is relevant to the customer data breaches.<\/h4>\n
It\u2019s unclear why Snowflake hasn\u2019t proactively reset passwords, or required and enforced the use of MFA on its customers\u2019 accounts.<\/h4>\n
\n