Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacker confirms access through infostealer infection [withdrawn]

hudsonrock.com

Post reply on HN
Print view View original

71–80 of 235 posts

Re: Hacker confirms access through infostealer infection [withdrawn]

#71

Post by aurum »

The article doesn't seem very consistent with the headline of "hundreds of breached customers"

1. The password for lift/okta is only allowing access to a servicenow portal and not customer accounts, so the refresh token issue seems restricted to the servicenow portal and unrelated to any actual customer data being exposed from customer Snowflake accounts

2. The screenshot with 10 corporate accounts compromised shows 4 different Snowflake account credentials (one of which appears to be a personal demo account) so that might explain up to 3 customers being compromised but there's no details showing other customers being compromised.

Assuming all of the SE's credentials were compromised for all of the customers they were working with, we can probably say the total customers compromised would be in the low double digits (each customer account would have had to provision access to the SE individually)

Big leap to say that literally the entirety of Snowflake's customer base is compromised from a "refresh token issue" (in the internal Okta portal) that isn't even linked to any customer Snowflake account

Re: Hacker confirms access through infostealer infection [withdrawn]

#72

Post by oasisbob »

squigz wrote: post #61
WhackyIdeas wrote: post #47

Earlier quoted context omitted.

Great, so these companies do not give a flying fuck about their customer data in making sure the data stored at cloud storage companies are end to end encrypted. To think these random cloud storage companies can access your bank information is utterly shocking.

> To think these random cloud storage companies can access your bank information is utterly shocking. Honestly this sort of thing shouldn't be shocking at all.

Not surprised at all. Doesn't even depend on cloud vendors - I'm thinking back to the 2023 MOVEit vulnerability which resulted in the release of a ton of customer info from banks' own internal infrastructure.

Re: Hacker confirms access through infostealer infection [withdrawn]

#73

Post by Booleans »

WhackyIdeas wrote: post #51
cabirum wrote: post #37

Earlier quoted context omitted.

The screenshot shows the post in English. The website domain is Indian. The seller contact xmpp.cn in China. But no, we'll keep blaming Russia for everything.

I agree. Every single security thing that happens is put on Russia. Typical propaganda. If we were pre-Ukraine, it’d be China getting all the blame (like it used to be). I’m not pro-Russia, I’m just anti-bullshit.

There’s a reason a lot of malware won’t install on a user’s computer if it detects they’re using a Russian keyboard.

Re: Hacker confirms access through infostealer infection [withdrawn]

#74

Post by halfcat »

WhackyIdeas wrote: post #47
proactivesvcs wrote: post #4

Earlier quoted context omitted.

BBC News report of a substantial hack of Santander bank; linked to Snowflake. https://www.bbc.co.uk/news/articles/c6ppv06e3n8o

Great, so these companies do not give a flying fuck about their customer data in making sure the data stored at cloud storage companies are end to end encrypted. To think these random cloud storage companies can access your bank information is utterly shocking.

Can a tool like Snowflake work if it doesn’t have access to the unencrypted data?

Re: Hacker confirms access through infostealer infection [withdrawn]

#75

Post by c0njecture »

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 customer should restrict access to corporate networks only. - does not allow authentication unless with MFA or via corporate IDP / SAML - has dynamic masking / tokenisation

Snowflake seems to have most of the Fortune 500 as customers. If Snowflake itself was somehow penetrated and all controls circumvented, it would certainly be huge and you'd be reading about a lot more than Santander and Ticketmaster.

At this point it seems more like the "AWS Hack" that affected CapOne back in the day (that was CapOne's fault, not AWS!).

Re: Hacker confirms access through infostealer infection [withdrawn]

#76

Post by mahogany »

rdtsc wrote: post #63

Snowflake says it's not their fault, it's customer's fault apparently: https://community.snowflake.com/s/question/0D5VI00000Emyl00A... If https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... has not completely fabricated the story, Snowflake are tiny bit less than truthful. > Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelate…

Don’t they hint at how it happened in what you quoted?

> performed with our customers’ user credentials that were exposed through unrelated cyber threat activity

Unless they are just making this up, they seem to think that credentials were obtained elsewhere. They also say at the end that they told customers to review their account settings. So they are directing the blame away from themselves.

You’re right that this seems to conflict with Hudson Rock. Unfortunately our sources are the company that allegedly was hacked and a company that shamelessly doxed an employee in the course of using this event to promote their product. I think we’ll need to wait for more details.

Re: Hacker confirms access through infostealer infection [withdrawn]

#77

Post by rdtsc »

ActionHank wrote: post #67
rdtsc wrote: post #63

Snowflake says it's not their fault, it's customer's fault apparently: https://community.snowflake.com/s/question/0D5VI00000Emyl00A... If https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... has not completely fabricated the story, Snowflake are tiny bit less than truthful. > Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelate…

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 like saying: "It wasn't A, C, D, E, or F" as the causes. Hmm, they skipped B it seems, I wonder why...

Re: Hacker confirms access through infostealer infection [withdrawn]

#78

Post by c0njecture »

tomashertus wrote: post #10
skilled wrote: post #7

At least based on the wording of the perpetrator, Snowflake really did have the system designed in a way where a single administrator account gives you carte blanche to everything. > On may 31st, Snowflake released a statement in which they claim that they are investigating an industry-wide identity-based attacks that have impacted “some” of their customers. https://community.snowflake.com/s/question/0D5VI00000Emyl00…

If the threat actor has played it right, there is a high possibility that this will be the largest data breach in history.

There's no evidence of that at all. The screenshot shows a few Snowflake professional services demo accounts only. These are accounts used by the sales engineer to demo features to customers.

It's possible the attacker was able to deduce some information about certain customers, but they would not then be able to connect to those accounts to extract data as those accounts should not be accessible from the public Internet at all, and should require corporate authentication.

Re: Hacker confirms access through infostealer infection [withdrawn]

#80

Post by foobiekr »

hn_throwaway_99 wrote: post #65
gregates wrote: post #25

Earlier quoted context omitted.

That's what the article implies, but I think it's overblown. They provide enough information (unfortunately) to identify the employee whose credentials were stolen, and she's a Sales Engineer. The data seems to have come from her own Snowflake account, which was used to build demos for customers or prospective customers. It's quite possible that those customers granted her access to some of their actual data, which w…

> They provide enough information (unfortunately) to identify the employee whose credentials were stolen, and she's a Sales Engineer. I'm not previously familiar with Hudson Rock, nor how "standard" disclosures around this work, but identifying the breached employee felt like an extremely shitty move to me. If a single infected laptop of a sales engineer (i.e. not even an admin with extensive access rights) resulted…

Exactly, how is an SE privileged enough to cause a problem? Or for the activities to go unnoticed?

Like I would be very humiliated to have a system under my care that had this problem.

Post reply on HN