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

81–90 of 235 posts

Re: Hacker confirms access through infostealer infection [withdrawn]

#81

Post by lesuorac »

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…

But don't you see, we fired the problem so no more worries!

Oh, what's that. How did we change our hiring process to avoid hiring a problem again?

Sorry, my phones buzzing and I need to go.

--

Although obviously yes the problem isn't with hiring, it's with the system where a what should be fairly untrusted device shouldn't be able to exfiltrate a ton of data without setting a flag off somewhere.

Re: Hacker confirms access through infostealer infection [withdrawn]

#82

Post by foobiekr »

c0njecture wrote: post #75

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?

Re: Hacker confirms access through infostealer infection [withdrawn]

#83

Post by rdtsc »

mahogany wrote: post #76
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…

> 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.

Fair point. Doxing the employee is shitty, no doubt. Makes Hudson Rock look bad as well. But at the same time, I was giving them some credibility as it would seems if they completely fabricated the screenshots, they might as well file for bankruptcy, given the market they seem to operate in.

Re: Hacker confirms access through infostealer infection [withdrawn]

#84

Post by c0njecture »

FromOmelas wrote: post #21
abadpoli wrote: post #5

Why in the world would obtaining a Snowflake employee’s credentials allow you to then obtain Snowflake’s customers’ data? Doesn’t this imply that people working at Snowflake can see all of the data that I put in it? Admittedly I don’t have much experience with Snowflake, but as a baseline I expect better from a “cloud storage giant”.

No, that sounds about right. This is a new, agile, cloud-first company that grew very quickly and has faced significant turnover. You don't get such growth by doing everything right. Looking at linked-in, the unlucky employee could be someone in a sales role, with only 7 months of tenure. Every company has a few sysadmins with a scary amount of reach, but that's not what happened here. Edit: A ServiceNow access reque…

It's not a new tiny company. It's about 12 years old with 7000 employees. They know they are dead if they are not hot on security, so at the moment I would take this story with a big pinch of salt. Quite possible certain customer configurations have been attacked, but that is a different thing.

Re: Hacker confirms access through infostealer infection [withdrawn]

#85

Post by senderista »

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.

Have we already forgotten about all the cybercrime originating from Ukraine?

Re: Hacker confirms access through infostealer infection [withdrawn]

#86

Post by NotEvil »

lesuorac wrote: post #81
hn_throwaway_99 wrote: post #65

Earlier quoted context omitted.

> 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…

But don't you see, we fired the problem so no more worries! Oh, what's that. How did we change our hiring process to avoid hiring a problem again? Sorry, my phones buzzing and I need to go. -- Although obviously yes the problem isn't with hiring, it's with the system where a what should be fairly untrusted device shouldn't be able to exfiltrate a ton of data without setting a flag off somewhere.

The problem isn't the employee or the hiring process. It's the security infrastructure! One compromised account, supposedly from sales, shouldn't bring down the whole company.

Re: Hacker confirms access through infostealer infection [withdrawn]

#87

Post by hangtime79 »

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 environment Hudson Rock just published.

As far as I can tell, this is a process issue of clients not expiring an ID of someone who they were sharing data with and a threat actor swiping credentials. There is nothing novel about this as there is no exploit.

Also congrats Hudson Rock you just outed a person who was taken due to having malware on their computer. This is no different then if you gave a contractor credentials and they had those swiped. Dicks.

Re: Hacker confirms access through infostealer infection [withdrawn]

#88

Post by matsur »

aurum wrote: post #71

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…

Very possible there were creds etc accessible in Servicenow that could have been used to move laterally from there. Conjecture, obviously.

Re: Hacker confirms access through infostealer infection [withdrawn]

#89

Post by shrubble »

aurum wrote: post #71

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…

Without knowing exactly how the compromised account is set up, and what access is granted, it may be difficult to say. At "security focused large telecom" I am aware of, you would be surprised what level of tech has access to what (though of course all access is logged).

Re: Hacker confirms access through infostealer infection [withdrawn]

#90

Post by jupp0r »

hangtime79 wrote: post #87

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…

Agreed, mentioning the login name of the compromised account seems really unprofessional and unnecessary.
Post reply on HN