Breaches Due to Credential Stuffing: Who’s Accountable? – Source: www.databreachtoday.com

Cybercrime
,
Fraud Management & Cybercrime
,
Multi-factor & Risk-based Authentication

The Theft of Snowflake’s Customers’ Data Shows That Vendors Need Robust Defenses

Mathew J. Schwartz
(euroinfosec)

•
June 28, 2024    

Who’s responsible for the data breaches experienced by customers of the data warehousing platform Snowflake?

See Also: Identity Security Clinic

The short version of how this attack unfolded can be told in two words: credential stuffing. This refers to taking usernames – often email addresses – and password pairs from a public or private data leak and trying them across a range of other sites to see where they might work.

In a joint report about the data breaches, Mandiant and CrowdStrike, which were hired to assist with incident response, said that attackers built a tool, classily named “rapeflake” – now tracked by Google’s Mandiant as “Frostbite” – to automate this process.

Multiple accounts of Snowflake’s customers were breached, and some victims received ransom demands for the stolen data. Investigators say about 165 organizations have been affected. While most haven’t been publicly named, known victims include Santander Bank, automotive parts supplier Advance Auto Parts, the Los Angeles Unified School District and luxury retailer Neiman Marcus.

Another victim, Live Nation Entertainment’s Ticketmaster, in its latest data breach notification said the breach of its Snowflake account began April 2 and was discovered May 23.

The joint Snowflake report released earlier this month says: “We have not identified evidence suggesting this activity was caused by a vulnerability, misconfiguration or breach of Snowflake’s platform.”

“Snowflake’s enterprise environment has not been breached,” a spokesman said. Snowflake CISO Brad Jones said in a blog post: “We believe this is the result of ongoing industrywide, identity-based attacks with the intent to obtain customer data.”

Accountability Question

So, who is responsible when credential-stuffing attacks result in data breaches?

“It’s difficult to define proportions of accountability, but what is clear is that security is a joint responsibility,” said data breach expert Troy Hunt, founder of the free Have I Been Pwned? breach notification service. “If credentials have been obtained by shortcomings on behalf of the customer then that’s on them but equally, platforms like Snowflake need to work on the assumption that these attacks are common and provide resilience against them.”

A sad fact of life for an organization whose customers’ accounts are breached in such an attack is that they’re often held responsible, at least in the public’s perception. Credential swapping attacks have been rife for years, and aficionados regularly swap credential stuffing lists on hacking forums.

What should an organization do to show that it did everything it could to combat credential stuffing?

Hunt, who’s long advised firms on required defenses, told me that for him, a modern approach would include “a combination of controls including blocking known breached passwords, anti-automation and recognizing anomalous authentication attempt behavior.”

Here’s my fuller list of suggested defenses:

• Support strong MFA. The U.S. Cybersecurity and Infrastructure Security Agency says “‘phishing-resistant’ MFA, like a smart card or FIDO security key, is the gold standard of MFA protection,” and users should always use “the strongest level of MFA you can.” But MFA won’t solve everything – especially “when we’re talking about keys used to communicate between app and cloud platform,” Hunt said.
• Make MFA mandatory. Give administrators the ability to require that their users employ strong, phishing-resistant MFA.
• Reject reused passwords. Around 2016, sites such as Facebook and Netflix began forcibly expiring user passwords if they found that customers reused them on another site. They continually review data leaks for such information.
• Block reused passwords. In 2017, Hunt launched the free Pwned Passwords service that sites can use to help users never pick a password that’s appeared in a known data breach, shortly after the U.S. National Institute for Standards and Technology began recommending that practice.
• Combat suspicious behavior. Per Hunt’s admonition to monitor for “anomalous authentication attempt behavior,” block unusual or high volumes of login requests or activity, which could be attackers using malicious tools such as Frostbite.
• Verify clients. MFA won’t protect every type of connection, such as via APIs or directly to databases. “Better controls around verifying the legitimacy of the client consuming the service are needed in these situations,” Hunt said.

In the wake of approximately 165 Snowflake customers seeing their Snowflake data go missing due to credential stuffing attacks, the data warehousing platform has promised to refine its approach to MFA and network-based defenses.

Snowflake currently supports only one type of MFA: Cisco Duo, “and only that instance which is managed by Snowflake,” the company said, although last August it said it was weighing adding other options. Each user must self-enroll in this MFA, and customers cannot make using MFA mandatory. Duo can be used to authenticate not only to Snowflake’s web-based front end, Snowsight, and its command-line interface tool, but also with the company’s SnowSQL and the Snowflake JDBC and ODBC drivers.

Snowflake also supports a variety of SAML-compliant vendors for single sign-on. Okta and Microsoft Active Directory Federation Services offer native support – as well as OAuth and using a cryptographic hardware key that generates a key pair. “For service accounts (i.e., non-human interactive use cases), use key pair authentication or OAuth for machine-to-machine communication in lieu of static credentials,” Snowflake said.

Whether accessing any of these features incurs additional Snowflake costs isn’t clear; the vendor didn’t immediately respond to my request for comment.

Mandiant said the fact that not all of Snowflake’s customers’ users employed MFA was a factor in the data breaches. “The broad impact of this campaign underscores the urgent need for credential monitoring, the universal enforcement of MFA and secure authentication, limiting traffic to trusted locations for crown jewels, and alerting on abnormal access attempts,” it said.

Snowflake has promised to give customers additional MFA and other options. “We are developing a plan to require our customers to implement advanced security controls, like multifactor authentication or network policies,” it said Monday. Ideally, the company will also start to support the gold standard of phishing-resistant MFA that CISA advocates.

Because vendors and service providers store data pertaining to or on behalf of their customers, they should be seeking phishing-resistant MFA by default, plus extra security controls to block credential stuffing attacks perpetrated by APIs or other avenues.

Anything less, and vendors risk owning the inevitable customer data breaches that will follow.