2FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
Git ransom campaign incident report
11–20 of 76 posts
Re: Git ransom campaign incident report
#12Seems like no one fell for this though. https://www.blockchain.com/btc/address/1ES14c7qLb5CYhLMUekct...
Re: Git ransom campaign incident report
#13Is it common that companies share intelligence like this? I think it's a wonderful idea, given they all operate on essentially the same service (git) they share similar security concerns.
Re: Git ransom campaign incident report
#142FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
Exactly. PATs are designed to circumvent human intervention (MFA) for authentication in order to support automation. I am very curious if there's a better way than PATs.
Re: Git ransom campaign incident report
#15[deleted]
Re: Git ransom campaign incident report
#16Since 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.
”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.
Re: Git ransom campaign incident report
#17I didn't see it mentioned in the article, but did any of the 3 companies confirm that the repos have been actually cloned as the attackers suggest?
Re: Git ransom campaign incident report
#182FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
[deleted]
Re: Git ransom campaign incident report
#19Earlier 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.
Very fair point.
Re: Git ransom campaign incident report
#202FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
Exactly. PATs are designed to circumvent human intervention (MFA) for authentication in order to support automation. I am very curious if there's a better way than PATs.
ssh keys with a passphrase?