Organizations need to ensure they have essential security layers like multi-factor authentication (MFA) enabled after hundreds of compromised Snowflake credentials have been uploaded to the dark web.
Following high-profile breaches at Santander and Ticketmaster that involved using stolen credentials to compromise poorly secured Snowflake instances, authorities have warned organizations to reassess how they are securing their cloud-hosted infrastructure.
Moreover, this week TechCrunch claimed it has observed over 500 Snowflake credentials listed on an unnamed underground forum hosted on the dark web.
The credentials include usernames, passwords, email addresses, and the web addresses of the login pages for the corresponding Snowflake accounts.
In a statement acknowledging the incidents, Brad Jones, CISO at Snowflake said preliminary findings from the company’s ongoing investigation indicated the credentials being leveraged in these attacks were obtained through infostealer malware deployed on the computers of employees who had access to their organization’s Snowflake environment.
Along with names already known to be linked to this event, there are also credentials linked to various unnamed organizations, according to TechCrunch.
These include at least two major pharmaceutical companies, a publicly run freshwater supplier, and a number of other firms.
It’s unclear exactly when the credentials were stolen, how long they have been available online, and whether or not they are currently in active use.
Users are choosing forgo MFA and put themselves at risk
As testing the stolen credentials would constitute a cyber crime, the outlet was unable to guarantee their authenticity, but it did attempt to verify them using other methods.
This included confirming the web addresses of the Snowflake environments included in the cache of information published online corresponding to the companies whose employees’ logins were compromised. This was possible as each login page offered users two different sign in options.
The first uses Okta’s single sign-on platform to allow users to sign in using their company’s corporate credentials using MFA.
The second option lets users use just their Snowflake username and password to get access to the database, depending on whether the company had chosen to apply an MFA layer on the account.
Snowflake’s Jones stressed in his statement that these attacks were only possible because the compromised instances did not have MFA applied, urging organizations to ensure they have enforced it on all of their accounts.
Snowflake’s MFA policies give users too much freedom to leave themselves unsecured
Ofer Maor, cofounder and CTO at Mitiga, outlined how Snowflake’s policies gave customers the ability to forgo extra authentication security protections.
“While Snowflake offers users the ability to turn on MFA, this is a feature that is not enabled on users by default and, furthermore, it cannot be enforced on users by the admin of the tenant. According to Snowflake’s support site: ‘No, MFA can’t be enforced for a role. MFA is enabled on a per-user basis; however, at this time, users are not automatically enrolled in MFA. To use MFA, users must enroll themselves.’”
He noted that while other vendors might allow this to provide a smoother initial adoption phase, they often insist MFA is applied everywhere afterwards.
“While other vendors may also offer the ability to start without MFA (this is a common practice to remove friction during the initial adoption, especially for freemium solutions), most SaaS vendors, once deployed as an enterprise solution, allow administrators to enforce MFA. That is, require every user to enroll in MFA when they first login and make it no longer possible for users to work without MFA,” he explained.
“This would be common expected behavior, as users are used to from their Office 365 or Google Workspace environments, but also from other enterprise applications they use, such as Salesforce, Slack, and others.”
As such, Snowflake’s policy gives users the choice to use MFA or not, which Maor said could lead to accounts being left unsecured.
“This means Snowflake leaves it up to every user to decide whether they want to enroll with MFA or not. This naturally leads to many Snowflake users not having MFA turned on. It appears that the current campaign is leveraging this weakness and is targeting users which do not have MFA turned on.”
