
Git ransom campaign incident report - brntn
https://about.gitlab.com/2019/05/14/git-ransom-campaign-incident-report-atlassian-bitbucket-github-gitlab/
======
gumby
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 am I missing?

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

~~~
Someone
_”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.

~~~
skrebbel
Sounds like we need a review site for extortionists.

~~~
saalweachter
Would you charge the extortionists to remove their negative reviews?

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

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

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

------
heelhook
Seems like no one fell for this though.
[https://www.blockchain.com/btc/address/1ES14c7qLb5CYhLMUekct...](https://www.blockchain.com/btc/address/1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA)

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

~~~
kristofferc
Doesn't seem that way:
[https://github.com/search?q=1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9...](https://github.com/search?q=1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA&type=Code)

------
Ancient
Repo's with remaining ransom file:
[https://github.com/search?q=1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9...](https://github.com/search?q=1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA&type=Code)

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

~~~
ralph84
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).

~~~
jredmond
This is the safer bet. The host should offer to restore from their own
backups, but some customers may have already taken care of their own stuff.

------
rossdavidh
"All of this has happened before, and it will all happen again." \- Peter Pan
movie, Battlestar Galactica, and should be every security incident report
ever.

Not saying they shouldn't have issued their analysis, of course they should
have, it mostly looks on target. But...it will all happen again.

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

~~~
benburleson
Why are people using passwords instead of keys?

~~~
jwilk
"Stupid corporate firewall blocks SSH connections" would be my guess.

------
chrischen
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?

~~~
leethargo
AFAIK there have been bitcoin laundering services for years (bitcoin in,
bitcoin out).

As for spending, there used to be pre-loaded credit cards that you could from
bitcoin.

~~~
chrischen
Wouldn't the credit cards be traceable (record of where you spent it). It
wouldn't necessarily tie you exactly but it'd create a large paper-trail.

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

~~~
nhumrich
An ssh key _is_ 2FA

~~~
michaelmior
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."

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

~~~
wnevets
Having two different static passwords on an account isn't actually two
different factors, whether you can recite them or not.

The fact that one time passwords expire and change is what makes them a
different factor than a static password.

~~~
thaumasiotes
> The fact that one time passwords expire and change is what makes them a
> different factor than a static password.

If you're getting your 2FA code by SMS message or the like, this can be true.

If you're using TOTP (e.g. Google Authenticator), that's just as static as
your other passwords. The TOTP code never expires nor changes. What changes is
the code you're supposed to send over the wire.

~~~
theamk
Eh? TOTP usually expire in 60 seconds, so in most cases even if you
accidentally leak it, it will be safe.

(and you are not likely to leak it anyway -- with something that changes that
often, you are not going to have an incentive to write it to files)

~~~
thaumasiotes
A 60-second TOTP code is a fully deterministic function of a permanent,
unchangeable secret. That's why you and the server can agree on what the code
should be without needing to communicate beyond setting up the code
originally.

This makes it identical to a password from a theoretical perspective. There's
really no difference between a TOTP secret that you keep in a TOTP app and
haven't memorized, and a password you keep in your password manager and also
haven't memorized. Both are "something you know", and nothing else.

You're correct that leaking a temporary code from a single login attempt
doesn't compromise the TOTP secret. That is an artifact of the login process,
not of whether the mechanism is labeled "2FA" or "password". You can do the
same thing while calling the secret a password:
[https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)

~~~
theamk
I disagree, I believe TOTP belongs firmly in the "something you have"
category. You cannot memorize TOTP password, nor you can store in your
password manager. You also cannot pass that knowledge to another person. So
this is more like a public key than a password.

Ultimately, everything is "permanent, unchangeable secret", including private
key and biometric data. Where the data is stored and how is it accessed makes
all the difference.

I could not find the original definition of "something you have", but modern
standards like PCI actually give OTP auth as an example of "something you
have" (p. 4 of [1])

(I am not looking at the degenerate case of running TOTP app on the same
device / same security domain -- it does not describe most cases, and there
are some fairly straightforward technical measures to defeat this)

[1] [https://www.pcisecuritystandards.org/pdfs/Multi-Factor-
Authe...](https://www.pcisecuritystandards.org/pdfs/Multi-Factor-
Authentication-Guidance-v1.pdf)

~~~
thaumasiotes
> You cannot memorize TOTP password, nor you can store in your password
> manager. You also cannot pass that knowledge to another person.

But none of these things are true. For example, my most recent job involved
sharing a 2FA-protected online account. We all had the code.

~~~
theamk
Sorry, "none of these things are true" in your environment. They are certainly
true for other people, in fact, I bet they are true for majority of them.

I think analogy to physical house keys is very helpful. What did your work do?

Did you show the enrollment QR code, and multiple people scanned it --> this
is like duplicating house key.

Did you put the key into password manager -> this is like that combination
lockbox that releases house key if you enter the right combination.

People do all sorts of unusual things, this does not change the properties of
intended usage.

~~~
thaumasiotes
> They are certainly true for other people, in fact, I bet they are true for
> majority of them.

Well, no. Everyone who uses TOTP, without exception, has their secret stored
in a password manager. That's what the TOTP app or device is.

~~~
theamk
There is a big difference between TOTP app/device and a password manager.

The password manager returns passwords directly. They can be viewed,
memorized, passed to another person, copied to another device, or checked into
git.

With TOTP, there is a private key inside, but it is not accessible to user.
You cannot view it, or memorize it, nor can you pass it to another person or
check it into git. It is purely implementation detail which is not exposed in
any way.

Disclaimer: this is the case with classical TOTP devices, like RSA SecurID
hardware token, or un-rooted Android phone running Google Authenticator. I
have those, and everyone I know have them as well.

There are exceptions, like people using LastPass 2FA or people who store TOTP
secret on their PC. This is not intended usage, and it does not matter for
most users.

------
falsedan
> _Otherwise, you can still clone the repository and make use of: git reflog
> or git fsck to find your last commit and change the HEAD._

I don't understand: when I clone a repo, I get a copy of all the branches/tags
and the commits they point to & the trees/blobs from those commits. If the
repo is wiped, I get a single master branch with a single commit with a single
tree and a single blob, and no reflog because that is local to the repo, and I
(as a fresh cloner) haven't updated any refs.

Perhaps they are thinking about a mirror clone? That still won't include the
reflog, but you can at least find dangling commits and guess which one was
master.

~~~
falsedan
Oops, mirror clone only includes reachable commits. No idea what the
'Otherwise' clarification means then, it sounds bogus

------
shapov
I 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?

------
jedberg
I just have to say, props to Gitlab for being included in this. For a lot of
enterprises that use Github and Bitbucket, this may be their first into to
Gitlab.

