Live data from Hacker News

Hacker confirms access through infostealer infection [withdrawn]

hudsonrock.com

131–140 of 235 posts

Re: Hacker confirms access through infostealer infection [withdrawn]

#131
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 OP Hudson Rock writes something that I understand is saying: This was more than a breach of one customer's credentials, they got some employee creds and they weren't protected by 2 factor so they got into other customer accounts using that engineer's creds.

The snowflake writeup reads to me as if a customer's account creds got compromised - and it implied to me that was the end of it, no central or other account access on thoes creds. Nothing about this use of some employee account info that didn't have 2 factor auth on it.

1. I'm sure snowflake wants all access creds of any kind for their internal employees to use 2fa.

2. It used to be at least as a customer you could create a name/password without 2fa to log in to your own info there if you wanted to, like say as a customer you create a db or table and want to access it.

Re: Hacker confirms access through infostealer infection [withdrawn]

#132

Was their intent to dox the employee while discussing this beach? They show the employee’s username, which is easily Googleable.

the username is probably the only proof they have that they were talking to an actual member of the hacker group.

Re: Hacker confirms access through infostealer infection [withdrawn]

#133

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…

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

Re: Hacker confirms access through infostealer infection [withdrawn]

#134

Earlier quoted context omitted.

the ad for protection services?

Yes, I know... I've seen that, also the posts on Reddit/HN and so on, but I am just curious if there is some truth to it.

snowflake has released a handful of statements and articles. giving attention to the ad would only be promoting it. unlikely to be allowed.

Re: Hacker confirms access through infostealer infection [withdrawn]

#135

Earlier quoted context omitted.

(new) sales person with an uber account that has access to carte blanche customer data. This is not only a disaster, if true, but also violates probably every certification under the sun, if they had any at all. Reminder Snowflake is a couple of sales persons from Oracle and a techie.

I'm not sure it does, perhaps it violates the spirit but not the letter. You need a way to give your employees access to customer data; for support cases. So you build a "request access" form in your ITSM. Now you can tick off every box related to certification: There is a process. Only authorized persons have access. Every aspect of it can be audited. Later, perhaps sales people (the 1000's of new joiners) start usi…

Aside all things stated that are wrong from security perspective - how about limit the qty and rate any such support account has access to? Breaching an account shouldn't give you access to dump everything out the gate. Even if that is the case, where are other measures alerting there's a stream of egress going on? This sounds like systemic issue which most certs are all about.

Re: Hacker confirms access through infostealer infection [withdrawn]

#136
post #90

Earlier quoted context omitted.

Agreed, mentioning the login name of the compromised account seems really unprofessional and unnecessary.

This was a really effective anti-ad for Hudson Rock.

The entry seems written by someone lacking maturity.

The candor in the screencap'd chat conversation is novel, and will probably drive clicks.

But in its unedited form serves as dirty laundry, and including the language from the threat actor is both unnecessary and inappropriate.

I can't tell if the threat actor agreeing HR would have potentially helped avert this problem is a good endorsement or not.

On one hand testimony from a threat of a product's effectiveness would be good, but on the other, this is a little up close and personal of an endorsement from someone actively ransoming so many companies and putting so much data at risk.

Re: Hacker confirms access through infostealer infection [withdrawn]

#137

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…

I always wondered why snowflake doesn't just install a control plane on customers own cloud resources a la databricks. Seems like they'd be able to mitigate a lot of liability that way.

Re: Hacker confirms access through infostealer infection [withdrawn]

#138
I'm more than disappointed in Hudson Rock. They lead with confirmation of a breach, but detail no more than allegations and swagger. The decision to not redact the login is not just a moral failure, but it shows that they do not understand the subject matter that they purport to be experts in. Shameful.

Re: Hacker confirms access through infostealer infection [withdrawn]

#139
post #92

Earlier quoted context omitted.

This is just pure speculation, but it kind of looks like the hacker was being ignored by Snowflake, so they somehow got in touch with Hudson Rock and offered them this promotional opportunity (to break the news, more than the throwaway line in the article) with the goal of retaliating against Snowflake for failing to pay the ransom. And Hudson Rock agreed to play along and hype up the story, presenting it as a bigger…

It's also possible that the firm is being trolled by the "threat actor."

Are you trying to say that the threat actor is just going up to firms they're trying to extort and telling them lies? Criminals just going around lying to people? Don't they know that's against the law?

Re: Hacker confirms access through infostealer infection [withdrawn]

#140

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…

All storage/compute/networking etc. is handled snowflake side.

For various reasons, you're not getting to touch the actual DB bits.

You can, IIRC, use snowflake-hosted connectors to access external data though.

And there's a "data marketplace" of sorts where clients can publish/consume datasets.

Post reply on HN