Live data from Hacker News

Hacker confirms access through infostealer infection [withdrawn]

hudsonrock.com

151–160 of 235 posts

Re: Hacker confirms access through infostealer infection [withdrawn]

#151
post #77

Earlier quoted context omitted.

Or they had no idea and assumed that customers had a breach, so blamed them without doing a proper in-depth analysis. The hacker alleges that they weren't even expiring refresh tokens, that is pretty huge if true, it's just a massive, glaring issue.

I think it's unlikely: * If Hudson Rock is to be believed, with the chat screenshot, Snowflake was notified and asked for a ransom. It would seem odd that all their 400 customers were all hacked randomly at the same time, by only one hacker group just based on those customers' own bad credentials * They enumerate all the possible ways they were not hacked, and seems to skips the exact one way they were hacked. It's l…

I think the following is also totally possible:

1. The attacker quoted in the Hudson Rock article did breach the sales engineer's account as described.

2. The data in those accounts, however, was just demo data (Snowflake unambiguously says the compromised employee account did not have sensitive data) and it seems possible the attacker is overstating the impact of their specific breach.

3. I've seen no evidence elsewhere that "400 customers" of Snowflake were breached. So it at least seems plausible that just Ticketmaster and Santander had their accounts breached because their own employee creds were stolen and that gave access to their Snowflake data.

I definitely agree the Snowflake announcement had too much corporate speak but from my plain reading of it they are explicitly denying that their employee's stolen creds resulted in a breach of real PII.

Re: Hacker confirms access through infostealer infection [withdrawn]

#152
post #99

Snowflake internal staff do not have access to read customer data, unless a customer grants it. Customers can use their own KMS to generate table keys. Snowflake has a lot of security features. But still, customers may well misconfigure their own Snowflake accounts and therefore be vulnerable. A well configured Snowflake account: - does not allow any access from the public Internet. Network policies set by the custom…

> Snowflake internal staff do not have access to read customer data By default, no. But it is standard operating procedure for sales engineers to request and be given access to customer data so they can build demos.

It is not standard operating procedure, and demos wouldn't be done with production data. In fact, most enterprises would have contracts in place with Snowflake that explictly state that Snowflake staff can not be granted access to their Snowflake accounts (this is actually the default in the Snowflake enterprise professional services contract now).

You can understand it: Snowflake lawyers are naturally reluctant to have their staff be granted access to any customer's accounts.

It is however quite common to have Snowflake PS guys have limited access to customer dev environments.

However, such access, even in dev, should always be network restricted.

Re: Hacker confirms access through infostealer infection [withdrawn]

#153

Earlier quoted context omitted.

Yes, that's also what I think must have happened—missing 2FA. But it seems it's also not mandatory within Snowflake accounts also, from what I understand from the general message. I've never used Snowflake and assumed that because you push all your data into it, it probably has 2FA enabled by default. Is it optional?

I don't quite understand how Snowflake works. My understanding was that you had to grant storage access (e.g. S3) and compute access (e.g. EC2) from your account to Snowflake, which would then use said resources to perform queries that you issue from their hosted web UI. In that case it would mean stealing the Snowflake demo account of a SE should not expose your data unless you forgot to revoke their access to your…

Databricks -does- work that way, iirc.

Re: Hacker confirms access through infostealer infection [withdrawn]

#154

Earlier quoted context omitted.

No, Snowflake runs it's own storage and compute (on either AWS, GCP, or Azure depending on what you pick).

So the customer data is actually stored on Snowflakes AWS accounts? What difference does it make what underlying storage / provider it uses then? Also does that mean every data query to snowflake goes out/in to/from internet at egress/Ingress costs?

At the snowflake size you get custom price lists from cloud operators.

But I think there was also support for peering with client VPCs (or equivalents) which is why they support AWS, Azure, and GCP - you choose the location that is most fitting for linking with your cloud/physical workloads.

Re: Hacker confirms access through infostealer infection [withdrawn]

#155

I don't work for Snowflake but I spend a lot of time working with them and their SE organisation. When working and building demos with clients, SEs create demonstration environments on the same $400 Snowflake demo accounts anyone can. To build demos the client would grant access to that SE. The SE would take some of the data to the demo environment and then work on it. This is further confirmed by the name of the env…

I just had a quick read through a couple more posts on HR, and a lot of them end with something along the lines of "heh, should have bought protection from us", reeks like a racket.

Re: Hacker confirms access through infostealer infection [withdrawn]

#157

Snowflake internal staff do not have access to read customer data, unless a customer grants it. Customers can use their own KMS to generate table keys. Snowflake has a lot of security features. But still, customers may well misconfigure their own Snowflake accounts and therefore be vulnerable. A well configured Snowflake account: - does not allow any access from the public Internet. Network policies set by the custom…

"Snowflake internal staff do not have access to read customer data" Do engineers in Snowflake have access to production systems?

They don't have customer key access and can't assume customer identity but ultimately yes, via a multi-eye approval process there is access to the prod infra - but this is extremely tightly secured, and not something a phishing attack on a single sales engineer could ever achieve.

Many enterprise customers additionally use standard third party crypto libraries to tokenise and/or encrypt sensitive fields before storage in any warehouse/database such as Snowflake or Redshift.

This is a similar principle to using client-side encryption for S3. The infra provider (AWS in that case) can never read the data.

Re: Hacker confirms access through infostealer infection [withdrawn]

#158

"To understand how the hack was carried out, the threat actor explains that they were able to sign into a Snowflake employee’s ServiceNow account using stolen credentials, thus bypassing OKTA which is located on lift.snowflake.com." I'm unfamiliar with ServiceNow and their website seems to be just marketing bable. Can someone explain the role of ServiceNow in this scenario and why it important?

ServiceNow is a system used for many ticketing, CMDB, etc. tasks, including automation.

That said, the quoted sentence boils down "the cookie we stole authorized us to service now instance bypassing SSO prompt".

Re: Hacker confirms access through infostealer infection [withdrawn]

#159
post #104

Hi, Felipe at Snowflake here. Here is the latest from Snowflake on this issue: https://community.snowflake.com/s/question/0D5VI00000Emyl00A... We'll keep updating that URL with any further news.

The salesforce.com servers are temporarily unable to respond to your request. We apologize for the inconvenience. Thank you for your patience, and please try again in a few moments.

Sill down. “…Visit http://trust.salesforce.com for current system status and availability.”

Re: Hacker confirms access through infostealer infection [withdrawn]

#160

I don't work for Snowflake but I spend a lot of time working with them and their SE organisation. When working and building demos with clients, SEs create demonstration environments on the same $400 Snowflake demo accounts anyone can. To build demos the client would grant access to that SE. The SE would take some of the data to the demo environment and then work on it. This is further confirmed by the name of the env…

This is the description of one of Hudson Rock's main products, "Bayonet".

"Imagine getting access to a lead-generation platform featuring hundreds of thousands of compromised companies around the world with active vulnerabilities that you can convert into customers."

I've seen and dealt with a couple of these types of companies. It's a pretty sleazy tactic, and it's low skill/effort from a technical point of view as well.

Post reply on HN