Live data from Hacker News

Repositories held for ransom by using valid credentials

about.gitlab.com

101–110 of 158 posts

Re: Repositories held for ransom by using valid credentials

#101

Earlier quoted context omitted.

Security isn't rendered in absolutes. We have to assume some sheepish new employee somewhere is scared of approaching management about a mistake they made committing a secret, so they reverse the commit and pretend nothing ever happened. We have to try and mitigate damage from lapses in communication and protocol like that.

Yes and this is why Github handicapped their search so much. But at the end of the day, any secret you post publicly is compromised.

Thankfully the guys over at Sourcegraph feel differently about how searchable projects should be.

Re: Repositories held for ransom by using valid credentials

#102
post #48

Earlier quoted context omitted.

Re GitHub keeping unreachable data, if I understand it right, isn't that GitHub painting a giant target on their back? Wouldn't that that imply every secret accidentally committed and then 'deleted' is still accessible, when one would expect it not to be? It's one thing to have your source code in the wild, but pairing it up with thought-to-be-deleted secrets would be an absolute disaster. Certainly one should not ev…

> Wouldn't that that imply every secret accidentally committed and then 'deleted' is still accessible This should be a moot point because anyone (in IT) should realize that an accidentally committed secret is now 100% public for all eternity and needs to be rendered irrelevant to restore secure operations.

And a hundred times so for any public repos. There are bots feeding on the GitHub firehose, scavenging for accidentally committed credentials.

A few years back (2015 or so) the average time from push-to-repo to AWS account compromise was 6 minutes. Surely that time has only gone down, and the number of different credentials identified has gone up.

Re: Repositories held for ransom by using valid credentials

#103
post #33

Earlier quoted context omitted.

This tendency of Hacker News users to want to monetize everything is sickening.

This is curious to me. You either run a charity or a business. Is that sickening? OSS is huge on HN, and a ton of HN users release OSS all the time. Yet, we all have bills to pay, and a lot of us look for ways to make money as well. Food and whatnot. I'm not really sure what you're objecting to here? You make it sound like because a user talked about monetizing a feature to a hypothesized product that they're the sam…

The irony of people using fast Internet (often on a fast mobile network), using fast computers, on sites like HN/FB/Twitter, etc, typically with a full belly and in an air conditioned room, to speak about the evils of the capitalistic spirit, always amuses me.

Re: Repositories held for ransom by using valid credentials

#104
post #33

Earlier quoted context omitted.

This tendency of Hacker News users to want to monetize everything is sickening.

Yeah. But it's not surprising considering the site is being run by a VC fund.

Host 10m, add a feature that 10k need. Charge each customer enough to cover the 999 who aren’t willing to pay.

Re: Repositories held for ransom by using valid credentials

#105
post #90

The title on HN is clickbait, the article mentions Gitlab users storing their own Gitlab password/tokens insecurely. It doesn't look like "Gitlab was compromised" to me. The original title is "Critical security announcement: Suspicious git activity detected".

Correct, users across GitLab and GitHub as been affected and in all cases valid credentials were used. Also see https://www.bleepingcomputer.com/news/security/attackers-wip... We are updating our title to better reflect what happened.

Sorry but the title still doesn't reflect the actual issue which per your link is : "Attackers Wiping GitHub and GitLab Repos, Leave Ransom Notes"

Re: Repositories held for ransom by using valid credentials

#106

Mandated 2FA should really be a thing, especially on tech-oriented sites with such importance.

Someone I know had one of their private repos on GitHub replaced despite having 2FA enabled so it may have been from a leaked personal access token somewhere. What's odd was that this user has push access to multiple active private repos yet only one was hit with the ransom.

Re: Repositories held for ransom by using valid credentials

#108
post #90

Earlier quoted context omitted.

Correct, users across GitLab and GitHub as been affected and in all cases valid credentials were used. Also see https://www.bleepingcomputer.com/news/security/attackers-wip... We are updating our title to better reflect what happened.

Sorry but the title still doesn't reflect the actual issue which per your link is : "Attackers Wiping GitHub and GitLab Repos, Leave Ransom Notes"

Did you see our new title? https://gitlab.com/gitlab-com/www-gitlab-com/commit/447f2330...

Re: Repositories held for ransom by using valid credentials

#109
post #19
post #10

>The breaches seem to rely on the attacker having knowledge of the affected users passwords in order to wipe their Git repositories and hold them for ransom. Yeah, until I go to my computer and use "git push" again. No? Also gitsbackup.com is registered but has no A/MX records so...

"Also gitsbackup.com is registered but has no A/MX records so..." Gitlab should really note that in their blog posts and emails to users. Just in case someone is thinking of paying the ransom.

We agree that paying a ransom doesn't guarantee any further actions on the part of the attackers. But in our blog post we want to stick to what we know and can influence and not talk about an external DNS record that can be added at any time.

Re: Repositories held for ransom by using valid credentials

#110
post #102
post #48

Earlier quoted context omitted.

> Wouldn't that that imply every secret accidentally committed and then 'deleted' is still accessible This should be a moot point because anyone (in IT) should realize that an accidentally committed secret is now 100% public for all eternity and needs to be rendered irrelevant to restore secure operations.

And a hundred times so for any public repos. There are bots feeding on the GitHub firehose, scavenging for accidentally committed credentials. A few years back (2015 or so) the average time from push-to-repo to AWS account compromise was 6 minutes . Surely that time has only gone down, and the number of different credentials identified has gone up.

> the average time from push-to-repo to AWS account compromise was 6 minutes.

Wow, I didn't realize it had become so efficient, but I shouldn't be surprised. I never really understood the value in hosting non-public software in the public, and if it's open source, it shouldn't be getting anywhere near secrets that can be used to extract money from its developers.

I remember thinking, back when it became trendy for people to upload their personal dotfiles to Github, that it would be a source of endless suffering. Who knows what information you're leaking in your ".profile" or ".bashrc"? Is that risk justified by the dubious benefit of storing your dotfiles on the internet for everyone to see, forever?

Post reply on HN