Live data from Hacker News

Git ransom campaign incident report

about.gitlab.com

51–60 of 76 posts

Re: Git ransom campaign incident report

#51
post #16

Earlier quoted context omitted.

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

Sounds like we need a review site for extortionists.

Would you charge the extortionists to remove their negative reviews?

Re: Git ransom campaign incident report

#52
post #41

Seems like no one fell for this though. https://www.blockchain.com/btc/address/1ES14c7qLb5CYhLMUekct...

Probably a unique wallet in each message. It seems to be that way in scam email ransoms.

Doesn't seem that way: https://github.com/search?q=1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9...

Re: Git ransom campaign incident report

#53

How does one withdraw bitcoin to fiat or even use it without it being traceable? Are there laundering or anonymizing services for bitcoin withdrawals to fiat?

The BTC could be used as payments for services or products which don't require identification (and holding "dirty" BTC is now the problem of the sand celler if they ever want to take it to traditional businesses in jurisdictions that enforce KYC for BTC payments).

Criminals can also trade BTC for physical cash.

They could also by some means (for example permissionless decentralized exchanges) convert it to a cryptocurrency with private transaction properties such as ZCash, Monero, Beam or GRIN and then back again.

The "laundering services" you refer to (generally called "mixers") are still around but most of them have been shown reversible with high degrees of confidence. CoinJoin is the state of the art here, with the most well-known implementations being JoinMarket and Wasabi Wallet.

But in general law enforcement and investigators are definitely wising up to cryptocurrencies and to be fully untraceable one has to go through a lot of hoops and not make a single mistake in the process. Even the above mentioned approaches can leak information that can be used to tie an individual to the transactions if not executed properly.

Most likely they will use the same tried and true approach they would have used for stolen fiat funds; identity theft. I personally know people who have been drawn into a criminal investigation for money laundering because they had been initiated a transaction selling BTC on LocalBitcoins via bank transfer (unwise unless you know and trust the person), turned out already stolen BTC had been converted into fiat on a compromised bank account, which was then supposed to be converted into "clean" BTC again. Fortunately the investigation was already underway when the transaction happened, my friends bank account was blocked as a result when the transfer was initiated and the whole thing was sorted out in the end.

Re: Git ransom campaign incident report

#54
post #16

Earlier quoted context omitted.

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

Sounds like we need a review site for extortionists.

Or maybe an escrow service for extortionists who makes sure the amount is refunded if the extortionist does not deliver.

Re: Git ransom campaign incident report

#55

Earlier quoted context omitted.

Sounds like we need a review site for extortionists.

Would you charge the extortionists to remove their negative reviews?

No, they just have to prove they're the real person with photo ID and admit they are the person being referred to as the criminal.

Re: Git ransom campaign incident report

#56

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

In the Cybersecurity field, yes!

You'd be surprised how often you'll be rolling up to your competition to compare the virus files you pulled from each of your networks and reverse engineering on VMs together... then next week you have to pretend you hate them until something else goes wrong again.

Re: Git ransom campaign incident report

#57
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…

In my experience there's enough people who don't understand how git works for a shotgun approach to find plenty of marks to fool.

Your experience converges with mine.

Re: Git ransom campaign incident report

#58
post #7
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.

For what it's worth, I really hope people don't pay if they can avoid it. Guy I know consults for a company which recently got ransomware. They had insurance, payed $1.5 million, got their files back. FBI came in and figured out it was the north koreans. This is happening more and more often, and will increase as we continue sanctions pressure.

This is a classic prisoners' dilemma: if no one payed, every one would be better off, but it is very hard to be that one guy or company who loses all his files for the "greater good".

Re: Git ransom campaign incident report

#59
post #39

Earlier quoted context omitted.

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

Do you rely on just one 3rd party like gitlab/bitbucket/github to keep your _only_ copy of your non-current projects? That seems unwise. I don't have many local repos on this 128GB MacBookAir, but as well as BitBucket all the projects I have ever worked on are on other several machines and/or hard drives I have locally, and also zipped up in S3 buckets and on tarsnap. Like they say, there's two kinds of people. Peopl…

> Through immediate independent investigations, all three companies observed that user accounts were compromised using legitimate credentials including passwords, app passwords, API keys, and personal access tokens.

Part of your backup strategy depends on external services. Not necessarily in your case, but people who only have their backups externally on a service could be affected.

> all the projects I have ever worked on are on other several machines and/or hard drives

And depending on your strategy, since they're so distributed it could mean they're outdated repos. If not, and they pull automatically, they could be affected.

Local backups also have issues. The disk might die, the data might be corrupted or any other myriad of things could happen.

> People who've lost important data because they didn't back it up properly, and people who haven't yet.

Is there such a thing as a perfect backup strategy?

Re: Git ransom campaign incident report

#60

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.

Why are people using passwords instead of keys?

"Stupid corporate firewall blocks SSH connections" would be my guess.
Post reply on HN