Repositories held for ransom by using valid credentials • Hacker News Board

Re: Repositories held for ransom by using valid credentials

#81

Post by trickstra » Sat, May 04, 2019, 3:08 PM UTC

soulofmischief wrote: post #53

hnarn wrote: 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.

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.

Math and cryptography don't care about a sheepish new employee (thankfully). The fact that leaked secrets will cause trouble is not mitigated by git forgetting a deleted commit. It is only mitigated by revoking that secret and creating a new one and not leaking it. So if a sheepish new employee fails to revoke them, why blame git or any other system? We have contracts, insurance and then criminal code for people who fail to follow protocols.

Re: Repositories held for ransom by using valid credentials

#82

Post by stordoff » Sat, May 04, 2019, 3:17 PM UTC

2T1Qka0rEiPr wrote: post #70

s_ngularity wrote: post #58

Earlier quoted context omitted.

In the UK, GMT is often used to refer to "the current British time" both GMT/BST. I've seen the same in the US where people say EST but mean EDT.

Is it? I mean, I'm British and I'm not aware of this.

I've seen a few people do it, but it's also usually corrected as been wrong.

Re: Repositories held for ransom by using valid credentials

#83

Post by wybiral » Sat, May 04, 2019, 3:19 PM UTC

soulofmischief wrote: post #69

iakh wrote: post #60

Earlier quoted context omitted.

In either case, the secret is already out whether the user wants to admit to it or not

But in one case, damage is mitigated because the sys admins didn't assume everyone is infallible and strictly adheres to protocol.

Is it mitigated? Once it's leaked you can't force everyone who may have captured it to delete it. So GitHub deleting it doesn't solve the problem.

Re: Repositories held for ransom by using valid credentials

#84

Post by JeremyBanks » Sat, May 04, 2019, 3:20 PM UTC

soulofmischief wrote: post #53

hnarn wrote: 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.

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.

I agree with the general statement about security absolutism (it's often very dumb and irrational), but in ths case in particular, most keys are swept from GitHub within seconds of being pushed, so the additional harm of not pruning those commits is very low. Data loss concerns are probably a much larger source of harm to weigh against it.

Re: Repositories held for ransom by using valid credentials

#85

Post by soulofmischief » Sat, May 04, 2019, 3:21 PM UTC

_II__II_ wrote: post #77

soulofmischief wrote: post #75

Earlier quoted context omitted.

That doesn't prevent someone from not following protocol.

It's not their job to prevent that.

It is a sys admin's job to mitigate damage from security leaks and to introduce hardened, fault-tolerant security paradigms.

Re: Repositories held for ransom by using valid credentials

#86

Post by soulofmischief » Sat, May 04, 2019, 3:23 PM UTC

wybiral wrote: post #83

soulofmischief wrote: post #69

Earlier quoted context omitted.

But in one case, damage is mitigated because the sys admins didn't assume everyone is infallible and strictly adheres to protocol.

Is it mitigated? Once it's leaked you can't force everyone who may have captured it to delete it. So GitHub deleting it doesn't solve the problem.

The definition of mitigation is to make something less severe. Yes, GitHub making this policy as clear as possible and allowing controls to toggle it per-repository or per-account mitigates the problem.

Re: Repositories held for ransom by using valid credentials

#87

Post by _bxg1 » Sat, May 04, 2019, 3:25 PM UTC

"...to wipe their Git repositories and hold them for ransom."

What an idiotic strategy to take with git repositories. Every local copy is a complete and fully-functioning copy of not just the code, but all history, etc. It's a non-centralized protocol.

Re: Repositories held for ransom by using valid credentials

#88

Post by soulofmischief » Sat, May 04, 2019, 3:26 PM UTC

JeremyBanks wrote: post #84

soulofmischief wrote: post #53

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.

I agree with the general statement about security absolutism (it's often very dumb and irrational), but in ths case in particular, most keys are swept from GitHub within seconds of being pushed, so the additional harm of not pruning those commits is very low. Data loss concerns are probably a much larger source of harm to weigh against it.

Well now I would say that I'm not interested in most keys, and I am interested in figuring out how to mitigate damage from the rest of them. You only need one key to get inside.

99% coverage is not good enough from a security standpoint, not when we can achieve 100%.

Simply, this functionality should be transparent and toggleable.

Re: Repositories held for ransom by using valid credentials

#89

Post by soulofmischief » Sat, May 04, 2019, 3:30 PM UTC

trickstra wrote: post #81

soulofmischief wrote: post #53

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.

Math and cryptography don't care about a sheepish new employee (thankfully). The fact that leaked secrets will cause trouble is not mitigated by git forgetting a deleted commit. It is only mitigated by revoking that secret and creating a new one and not leaking it. So if a sheepish new employee fails to revoke them, why blame git or any other system? We have contracts, insurance and then criminal code for people who…

No need for any git-blame, the blame lies in GitHub not making this feature optional and more known. So well known that a noobish employee is aware of it, so that they do not feel like they are "safe" and no longer need to alert management about their error.

Contracts, insurance and criminal code are responsive measures, not preventative measures. Security is preventative, not responsive.

Re: Repositories held for ransom by using valid credentials

#90

Post by sytse » Sat, May 04, 2019, 3:34 PM UTC

nicolaslem wrote: post #2

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.