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

61–70 of 76 posts

Re: Git ransom campaign incident report

#61

Post by theamk »

thaumasiotes wrote: post #45
wnevets wrote: post #34

Earlier quoted context omitted.

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.

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

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)

Re: Git ransom campaign incident report

#62

Post by falsedan »

falsedan wrote: post #48

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

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

Re: Git ransom campaign incident report

#63

Post by vokep »

johnday wrote: post #43
cwkoss wrote: post #25

Earlier quoted context omitted.

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?

It's pretty obvious that it's worse to be an actual criminal, than someone who goes around and pretends to be one. In the same way that it's worse to shoot someone with an actual gun than to threaten to shoot them with a Nerf gun. The negative network effects on other scammers are also nice.

I'm not so sure.

An "honest cryptolocker" helps support more cryptolocker use, as people trust that if they pay the criminal they'll get their stuff

If dishonest ones were the norm, than maybe cryptolocking would cannibalize itself as nobody would pay since they know its useless. So in a sense the dishonest one while having less ethical intention has more ethical results. But only at scale. Hmmm.

Re: Git ransom campaign incident report

#64

Post by michaelcampbell »

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.

If I remember correctly, WannaCry had a small customer support call center =D

Re: Git ransom campaign incident report

#65

Post by thaumasiotes »

theamk wrote: post #61
thaumasiotes wrote: post #45

Earlier quoted context omitted.

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

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)

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

Re: Git ransom campaign incident report

#66

Post by theamk »

thaumasiotes wrote: post #65
theamk wrote: post #61

Earlier quoted context omitted.

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)

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…

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

Re: Git ransom campaign incident report

#67

Post by chrischen »

leethargo wrote: post #50
chrischen wrote: post #46

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?

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.

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.

Re: Git ransom campaign incident report

#68

Post by bigiain »

rovr138 wrote: post #59
bigiain wrote: post #39

Earlier quoted context omitted.

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 wo…

> Is there such a thing as a perfect backup strategy?

At work, there's "Can meet contractually agreed RPO and RTO with 99.99% certainty". Automate the standard setup, and sleep well at night. Perfect.

At home, there's "I've done enough that I think the next improvement is an unfeasibly large amount of extra time&money for an unreasonably small improvement".

I've, for myself at home, settled on Apple's Time Machine backing up my Macs (and their phone/ipad iTunes backups) to a raid 10 set, that raid 10 set rsynced to another one at the opposite end of the house, and a weekly backup of that stored on a single drive that only powers up for 6 hours every Sunday night then powers back down again - so if my whole network gets breached and cryptolockered (for example) I'll still have at most 7 day old data at home. I also push that weekly backup out to S3 and tarsnap for off-site in-case-my-house-burns-down, or I've set it all on fire and moved to Belize scenarios...

I've been running most of that for ~8 years now. I've called it "done", while not "perfect", its certainly good enough against "not-Mossad threat models". If Mossad or The NSA want to delete my backups, so be it - I'll go be a carpenter or a gardener or something.

Re: Git ransom campaign incident report

#69

Post by thaumasiotes »

theamk wrote: post #66
thaumasiotes wrote: post #65

Earlier quoted context omitted.

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…

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…

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

Re: Git ransom campaign incident report

#70

Post by michaelmior »

theamk wrote: post #66
thaumasiotes wrote: post #65

Earlier quoted context omitted.

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…

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…

> nor you can store in your password manager

Some 2FA apps also allow you to back up your codes to a cloud service.

Post reply on HN