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

Repositories held for ransom by using valid credentials

about.gitlab.com

Post reply on HN
Print view View original

91–100 of 158 posts

Re: Repositories held for ransom by using valid credentials

#91

Post by floatboth »

2T1Qka0rEiPr wrote: post #55

Weird aside question: I notice the article says "at approximately 10:00pm GMT". Can someone explain why GMT might be chosen as a reference point here? Is there something I'm missing about the usage of GMT (and not UTC). It just seems particularly odd given that GMT is not (to my knowledge) actually being used as a concrete time-zone at the minute (BST is in effect for daylight savings).

I guess people who aren't overly pedantic say "GMT" to mean "UTC", just like everyone says "SSL" when it's actually "TLS". Older but better sounding names stick around.

Re: Repositories held for ransom by using valid credentials

#92

Post by avar »

lostmyoldone wrote: post #40
avar wrote: post #17

> We believe that no data has been lost, unless the [...] GitLab copy was the only one. One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings. As a result they won't have the data in question anymore in many cases[1]. Well, I don't 100% know that for sure, but it's the default configuration of their software, and I'm assuming th…

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…

If you ask nicely they'll run a one-off "gc expire" for you.

It also requires an attacker to know at least the partial SHA-1 anyway. It's infeasible to start brute-forcing that without being banned for dDoSing them, and if you know what the SHA-1 is you probably had access to the data already.

But yeah. It definitely creates security caveats peculiar to git, e.g. a hostile actor guessing that a force push in an IRC commit announcement clobbered secret data, and the accessing the old commit in the web UI.

Re: Repositories held for ransom by using valid credentials

#93

Post by mikeash »

avar wrote: post #17

> We believe that no data has been lost, unless the [...] GitLab copy was the only one. One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings. As a result they won't have the data in question anymore in many cases[1]. Well, I don't 100% know that for sure, but it's the default configuration of their software, and I'm assuming th…

That is a crazy-ass quote. “We believe that no data has been lost... well, except for the data we keep. But you weren’t actually relying on us to save any data, right?”

I know, back up everything at least twice. But still, when somebody loses one of your copies, they don’t get to say “it’s cool, no data was lost, you have other copies, right?”

Re: Repositories held for ransom by using valid credentials

#94

Post by asdfasgasdgasdg »

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…

The criminal code? I doubt there's anything in there that criminalizes a failure to follow an employer's secret revocation policies.

Re: Repositories held for ransom by using valid credentials

#95

Post by paulddraper »

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.

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.

Re: Repositories held for ransom by using valid credentials

#96

Post by sytse »

the_duke wrote: post #27
avar wrote: post #17

> We believe that no data has been lost, unless the [...] GitLab copy was the only one. One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings. As a result they won't have the data in question anymore in many cases[1]. Well, I don't 100% know that for sure, but it's the default configuration of their software, and I'm assuming th…

They do keep disk snapshots for 2 weeks though (created twice a day). https://about.gitlab.com/handbook/engineering/infrastructure...

Thanks for linking to that. I’m asking inside the company about the comment that the repositories are lost. I think it is a lot of work to restore individual repositories as opposed to restoring a disk, so maybe that is why we said that.

Re: Repositories held for ransom by using valid credentials

#97

Post by JeremyBanks »

soulofmischief wrote: post #88
JeremyBanks wrote: post #84

Earlier quoted context omitted.

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.

deleted

Re: Repositories held for ransom by using valid credentials

#98

Post by trickstra »

asdfasgasdgasdg wrote: post #94
trickstra wrote: post #81

Earlier quoted context omitted.

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…

The criminal code? I doubt there's anything in there that criminalizes a failure to follow an employer's secret revocation policies.

No, I wasn't referring specifically to this case. Generally, if people don't "follow the protocol", we have criminal code. If machines don't follow protocol, they end up with wrongly decrypted garbage data. It was to highlight the point that we have different measures to deal with people than we have with computer security, because math cannot prevent people from deviating from their protocols.

Re: Repositories held for ransom by using valid credentials

#99

Post by mkagenius »

soulofmischief wrote: post #85
_II__II_ wrote: post #77

Earlier quoted context omitted.

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.

You are just hacking the leaves. Once the secret is posted. It is public, it has multiple copy elsewhere on the internet. Even if you delete there is a copy kept somewhere on the internet -- and that's not an assumption. For example, iirc, Github copy is dumped to google every some-x-time.

Re: Repositories held for ransom by using valid credentials

#100

Post by soulofmischief »

JeremyBanks wrote: post #97
soulofmischief wrote: post #88

Earlier quoted context omitted.

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.

deleted

I think you're confused about what absolutism means. Just because I want 100% coverage when achievable does not mean I am being absolutist.
Post reply on HN