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

Git ransom campaign incident report

about.gitlab.com

Post reply on HN
Print view View original

21–30 of 76 posts

Re: Git ransom campaign incident report

#21

Post by caprese »

NateEag wrote: post #7
gumby wrote: post #4

Since literally everybody who has cloned a repo has a full copy of it, and since git is a decentralized revision control system, what on earth can it mean to hold a repo for ransom? The write up even says so: to recover, just push your code back up to our repo. I really don't understand what they are talking about. It's as if someone showed me a photo of my child and said, "pay me or I'll burn this photograph". What…

The threat cited in the article said not just that the code would remain deleted, but that it would be "leaked" - presumably many of these were private repos. You could never trust that the attacker actually deleted their copy of the repo, but then, the whole cryptolocking business model falls down if the attacker isn't at least moderately honest, so I can see why people would respond to that threat.

its easier to trust private hackers than organizations that have the law on their side

society works with mutual cooperation and hackers seem to understand that more than the "technically cooperating in this context" that the legal field would employ

Re: Git ransom campaign incident report

#23

Post by michaelmior »

nhumrich wrote: post #22
ralph84 wrote: post #11

2FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.

An ssh key is 2FA

How so? An SSH key is a single factor. You could argue that a password-protected private key provides a second factor, but that still falls in the category of "something you know."

Re: Git ransom campaign incident report

#24

Post by cwkoss »

NateEag wrote: post #7
gumby wrote: post #4

Since literally everybody who has cloned a repo has a full copy of it, and since git is a decentralized revision control system, what on earth can it mean to hold a repo for ransom? The write up even says so: to recover, just push your code back up to our repo. I really don't understand what they are talking about. It's as if someone showed me a photo of my child and said, "pay me or I'll burn this photograph". What…

The threat cited in the article said not just that the code would remain deleted, but that it would be "leaked" - presumably many of these were private repos. You could never trust that the attacker actually deleted their copy of the repo, but then, the whole cryptolocking business model falls down if the attacker isn't at least moderately honest, so I can see why people would respond to that threat.

Vast majority of cryptolockers are fake, they just keep asking for more and more money but never unlock.

(This is probably not true, but society would benefit from "cryptolockers are usually fake" being in the zeitgeist)

Re: Git ransom campaign incident report

#25

Post by cwkoss »

Someone wrote: post #16
NateEag wrote: post #7

Earlier quoted context omitted.

The threat cited in the article said not just that the code would remain deleted, but that it would be "leaked" - presumably many of these were private repos. You could never trust that the attacker actually deleted their copy of the repo, but then, the whole cryptolocking business model falls down if the attacker isn't at least moderately honest, so I can see why people would respond to that threat.

”the whole cryptolocking business model falls down if the attacker isn't at least moderately honest” Nitpick: it only requires most attackers to be somewhat honest. Having a few unscrupulous ones may make life harder for the “honest” ones, but they themselves can be better of, e.g. by, after receiving payment, demanding more money.

Is it more unethical to release an "honest cryptolocker" or one that lies and never gives the files, degrading the trust the entire cryptolocker grift relies on?

Re: Git ransom campaign incident report

#26

Post by rileymat2 »

gumby wrote: post #4

Since literally everybody who has cloned a repo has a full copy of it, and since git is a decentralized revision control system, what on earth can it mean to hold a repo for ransom? The write up even says so: to recover, just push your code back up to our repo. I really don't understand what they are talking about. It's as if someone showed me a photo of my child and said, "pay me or I'll burn this photograph". What…

I don't keep all my git code local, only the projects I am currently working on.

Re: Git ransom campaign incident report

#28

Post by mlindner »

1. Stop using 'git add .' This is a bad habit I see people keep suggesting to new git users. Stop recommending it and stop doing it.

2. Never store your password in .git/config. Why are you doing that? That shouldn't be stored in .git/config.

Re: Git ransom campaign incident report

#29

Post by will4274 »

michaelmior wrote: post #23
nhumrich wrote: post #22

Earlier quoted context omitted.

An ssh key is 2FA

How so? An SSH key is a single factor. You could argue that a password-protected private key provides a second factor, but that still falls in the category of "something you know."

How many people can recite their SSH key? Surely an SSH key is "something you have".

Re: Git ransom campaign incident report

#30

Post by ralph84 »

sverhagen wrote: post #27
Ancient wrote: post #8

Repo's with remaining ransom file: https://github.com/search?q=1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9...

Weird, weren't GitHub and friends restoring these repositories for these unlucky users?

I assume they're trying to contact the repo owners to see how they want to proceed. Even if the change seems obvious, changing the contents of a repo is definitely a case where the git host should involve the owner of the repo (barring ToS violations).
Post reply on HN