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

141–150 of 158 posts

Re: Repositories held for ransom by using valid credentials

#141

Post by greggyb »

scruple wrote: post #80
greggyb wrote: post #74

Earlier quoted context omitted.

Sure. It probably is. I'm not sure what the point is. It's still something that I see on a regular basis, and it seems clear that I care more about it than others, because in my experience I talk about it more than others. But the frameworks are not using standard IANA time zone names. Those look like "America/New_York". The most recent time zone selection I made was installing OpenBSD on a new laptop yesterday. That…

> I'm not sure what the point is. Believe me, I'm having the same reaction right now. > The most recent time zone selection I made was installing OpenBSD on a new laptop yesterday. That had me choose a proper time zone name. If you don't understand the difference between you selecting "America/Los_Angeles" in an OpenBSD installation and the average user being confronted with a list of country/city names vs. a timezon…

Luckily, I get to avoid building time zone UIs in my day job.

If I were to put it in a UI, I'd try to have locally understandable time zones as the labels, without incorrect offsets. I'd also probably try to give a better than a drop down selection of multiple dozens of options. I might not succeed, in which case I'd fall back to some lowest common denominator based on a survey of popular services. In any event, I agree with you that it is not a high priority for me, and would not be in any app I might develop.

Re: Repositories held for ransom by using valid credentials

#142

Post by justinclift »

soulofmischief wrote: post #89
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…

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.

> the blame lies in GitHub not making this feature optional and more known.

Which feature are you meaning should be optional and more known?

Re: Repositories held for ransom by using valid credentials

#143

Post by justinclift »

mkagenius wrote: post #99
soulofmischief wrote: post #85

Earlier quoted context omitted.

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.

Hmmm, it seems like having layered security, where accidentally exposed credentials aren't automatically "game over" would be better than not.

Not sure how practical that is to implement for every technology, but for many it could probably be done.

Seems like a time+money vs risk trade off thing.

Re: Repositories held for ransom by using valid credentials

#144

Post by mortehu »

paxys wrote: post #3

Gitlab was NOT compromised. Someone found passwords/tokens for Gitlab repositories exposed on the internet and held them for ransom.

Purging user data is one of the most common action attackers take when compromising an account. This makes it prudent for storage service providers to silently delay mass deletions to the extent allowed by their data deletion policy/GDPR to allow time to discover any breaches, or perhaps require second factor verification like a link sent via email.

Re: Repositories held for ransom by using valid credentials

#145

Post by paulddraper »

manigandham wrote: post #131
paulddraper wrote: post #95

Earlier quoted context omitted.

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.

That's a very poor reason to not have good searching functionality considering the uses far outweighs the potential risk. I highly doubt it's the case.

I'm 90% sure it is.

GitHub had great search, then they took it down when they found people we're scraping credentials with it, then they had bad search. I'm connecting the dots.

Re: Repositories held for ransom by using valid credentials

#146

Post by geofft »

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…

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

Because you won't know that a protocol isn't being followed. Your contracts, insurance, and criminal code won't cause you to realize that an employee caused an infosec incident if they don't tell you (and neither will your math and cryptography). And the more you threaten use of the criminal code, the less likely people are to admit that they made a mistake.

You can either build defense in depth (e.g., regular secret rotation, policies on use of GitHub in the first place or better yet automation that only pushes publicly after internal review, DLP via a corporate MITM, segregating your open source dev from your secret dev, etc.) or you can let your single defense get breached and have no idea.

Re: Repositories held for ransom by using valid credentials

#147

Post by rahimnathwani »

s_ngularity wrote: post #58
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).

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.

Whenever someone says GMT/PST/EST during the summer, I need to ask them to confirm whether they mean BST/PDT/EDT.

Whatever I assume, I might be off by an hour.

Re: Repositories held for ransom by using valid credentials

#148

Post by jtl999 »

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…

> One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings.

Does this also apply to self hosted GitLab CE/EE? Also how does Gogs/Gitea handle this?

Re: Repositories held for ransom by using valid credentials

#149

Post by sytse »

the_duke wrote: post #123
sytse wrote: post #96

Earlier quoted context omitted.

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.

Also any commits pushed between the last snapshot and the deletion would be lost too.

Correct

Re: Repositories held for ransom by using valid credentials

#150

Post by lolc »

greggyb wrote: post #62
greggyb wrote: post #59

Earlier quoted context omitted.

I usually attribute it to mild ignorance, not in a bad way. For a long time GMT was a good reference point. Times have changed. I used to work with a gentleman who would always schedule meetings on the phone as: > Great, let's put that on the schedule for 2:00 o'clock Eastern Standard Time. There was always a bit of officiousness to his tone and I think he just liked the idea of being precise. And he certainly was pr…

And an additional observation. Many applications that allow a user to pick their time zone typically show offsets from UTC and a time zone name. It bugs me to no end when I have to select something like "-5:00 Eastern Time (US/Canada)" in those dialogs. I think a lot of people just don't care enough to truly understand time zones and there is enough flexibility in human communication to just absorb the endless ream o…

Few people appreciate the difference between timezones and their UTC offset at a given date. That's because it's very unattractive to learn about DST. Without that, timezone offsets are relatively stable and it wouldn't matter (in the short term) which one you'd work with.

I'm just glad I don't need to have the "DST" talk more often. It takes people a night of sleep to process the level of time fuckery that is DST. Code reviews get delayed for a day when this happens. So yeah, when somebody refers to EST when they mean EDT I wouldn't give them "the talk". It works because people know what is meant.

Just a few days ago I had the understandable reaction of "what do you mean this won't work in India?"

Post reply on HN