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

Re: Repositories held for ransom by using valid credentials

#41

Post by tyingq » Sat, May 04, 2019, 12:51 PM UTC

raverbashing wrote: post #31

Operyl wrote: post #28

Earlier quoted context omitted.

So you’re telling me that if, say, Google’s Search algorithm got leaked it wouldn’t seriously hinder their business? There’s definitely cases where leaking a business’ code can be pretty disastrous.

> So you’re telling me that if, say, Google’s Search algorithm got leaked Google's search algorithm was public for a long time [0], it's been improved now and more under the curtains, but the answer is no. Google wins not only by technology, but also by size of the index [0] https://en.wikipedia.org/wiki/PageRank

I believe Google has also bolted enough ML to search that they couldn't really recreate current search with just code.

Re: Repositories held for ransom by using valid credentials

#42

Post by tyingq » Sat, May 04, 2019, 12:57 PM UTC

kzrdude wrote: post #13

Since the threat is to make the code public, there is nothing more gitlab can do to shut down the attempted blackmail. It seems unlikely to be a real threat to most?

Odd threat in that paying the ransom doesn't assure they wouldn't make it public anyway.

Also, someone else noted the ransom email domain has no MX or A records, so the instructions to email them won't work. They seem to be hoping someone will blindly pay the ransom.

Re: Repositories held for ransom by using valid credentials

#43

Post by ctennis1 » Sat, May 04, 2019, 1:01 PM UTC

yoz-y wrote: post #16

1023bytes wrote: post #14

Some other info: https://www.theregister.co.uk/2019/05/03/git_ransomware_bitc...

Out of all things to hold for ransom git repos seem like a bad idea. Most of the time there are multiple clones lying around anyways. I agree that having the source code leak can be bad news, but the code itself being secret should not be a critical part of the business.

Probably not, but I suspect some people will still pay the ransom anyway. Keep in mind, many people also do keep "secrets" used for other authenticating to other services in their git repos - even though it's a terrible idea.

Re: Repositories held for ransom by using valid credentials

#44

Post by localhostdotdev » Sat, May 04, 2019, 1:04 PM UTC

kinda hoping "testing weak passwords on your existing user's passwords" becomes standard practice at some point.

Re: Repositories held for ransom by using valid credentials

#45

Post by jaden » Sat, May 04, 2019, 1:05 PM UTC

agildehaus wrote: post #29

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

I agree, but read that at least one of the users had 2FA enabled and still lost their repos. They said they received no notification emails either.

Re: Repositories held for ransom by using valid credentials

#46

Post by Boulth » Sat, May 04, 2019, 1:08 PM UTC

avar wrote: post #32

Boulth wrote: post #20

Earlier quoted context omitted.

Just out of curiosity but how do you know about this inner workings of Github and GitLab?

I contribute to git, and I read the mailing list, where people a lot smarter than me comment about this sort of thing. I'm also on a team that runs an in-house enterprise GitLab instance for an S&P 100, so I have experience with it in that configuration, which I understand isn't different from what gitlab.com uses in this regard. None of this is secret or some sort of insider knowledge. If you know how "git gc" works…

I know some git internals including gc, expiration, reflog etc but your description was still very interesting. Thanks for taking the time to write this!

Re: Repositories held for ransom by using valid credentials

#47

Post by pvorb » Sat, May 04, 2019, 1:13 PM UTC

masklinn wrote: post #25

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…

I'm surprised github runs regular git. I'd always assumed they were emulating it, especially with the lag we've observed between github-api and github-git at $DAYJOB (update repo 1 via api, update repo 2 via api, fetch repo 1 and repo 2 via git, we've had cases where the repo 2 update was visible but not the repo 1).

There was a talk about "Scaling Git at GitHub" [1] a few years ago at Git Merge. While it may no longer be accurate, it still gives some insight into how GitHub is run.

[1]: https://youtube.com/watch?v=xK5yaWTt0R0

Re: Repositories held for ransom by using valid credentials

#48

Post by hnarn » Sat, May 04, 2019, 1:16 PM UTC

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…

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

Re: Repositories held for ransom by using valid credentials

#49

Post by davidmurdoch » Sat, May 04, 2019, 1:19 PM UTC

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…

You can permanently delete data from github, but doing requires a bit of work and a message to customer service: https://help.github.com/en/articles/removing-sensitive-data-...

Re: Repositories held for ransom by using valid credentials

#50

Post by cdubzzz » Sat, May 04, 2019, 1:23 PM UTC

blumomo wrote: post #23

Also GitHub users are affected. By the time of writing 379 public GitHub repos have been compromised: https://github.com/search?o=desc&q=1ES14c7qLb5CYhLMUekctxLgc...

I like this threat for open source software published on GH --

If we dont receive your payment in the next 10 Days, we will make your code public or use them otherwise.