Social engineering takeovers of open source projects • Hacker News Board

Re: Social engineering takeovers of open source projects

#271

Post by KronisLV » Mon, May 06, 2024, 9:53 AM UTC

samatman wrote: post #64

kazinator wrote: post #44

> Enable two-factor authentication (2FA) or Multifactor Authentication (MFA). Not on any third party system, where you're locked out forever if you lose your second factor. Fuck that! Only self-hosted, where you can recover via physical access. (That should actually be the first advice: host the stuff yourself. People lose control of projects due to hosting them on third party services. Be the guy who can pull the po…

> Not on any third party system, where you're locked out forever if you lose your second factor. Every two-factor system I've ever seen is actually two-of-three, with an account recovery code that you save elsewhere. I lost all my two-factor auths when my phone got wrecked, it was annoying to reestablish access to those accounts (and I now use a TOTP client which backs the tokesn up), but it was tedious rather than d…

> and I now use a TOTP client which backs the tokens up

What are some good options for this? I think my ideal solution would export an encrypted file, a bit like KeePass does on the desktop, but I don't know of many mobile apps for that.

Re: Social engineering takeovers of open source projects

#272

Post by josephg » Mon, May 06, 2024, 9:54 AM UTC

arp242 wrote: post #147

mikeyouse wrote: post #128

Earlier quoted context omitted.

I'm nobody so you have no reason to believe me - but there have indeed been other, very prominent projects targeted in very similar attacks. We're still inside the responsible disclosure window.. hell, even in the blog post we're commenting on, three JS projects were targeted in failed attempts. That's 4 public projects now..

> three JS projects were targeted in failed attempts. Suspected to be targetted, in a way that seems to have 0% chance of succeeding for almost any project. Which is why nothing happened.

> seems to have 0% chance of succeeding for almost any project.

Its obviously more than 0% given xz was successfully taken over and backdoored. Even a 5% chance of malicious takeover per project would make the situation pretty worrying given how many well funded, motivated government agencies are out there.

Re: Social engineering takeovers of open source projects

#273

Post by smnplk » Mon, May 06, 2024, 10:08 AM UTC

willvarfar wrote: post #168

So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library, so they control it from inception? Great that we'll finally get state-sponsored open-source development :D

The solution is blockchain! /s

Re: Social engineering takeovers of open source projects

#274

Post by Grimeton » Mon, May 06, 2024, 10:08 AM UTC

bsuvc wrote: post #22

I'm a maintainer (one of many) of an open source project, and this topic has been on my mind a lot lately as I review PRs. I am more suspicious of PRs from new contributors by default now. Of course I keep these suspicions to myself, but besides simply reviewing code for all the regular things, I now ask myself "what sort of sneaky thing could they be doing that appears benign on the surface?"

This is what I feared the most. Trust issues that lead to less progress and a community that slowly drowns in suspicions. When the XZ thing happened they were already going after one person accusing them of being part of the whole thing in one of the bug reports on github.

Re: Social engineering takeovers of open source projects

#275

Post by akx » Mon, May 06, 2024, 10:12 AM UTC

KronisLV wrote: post #271

samatman wrote: post #64

Earlier quoted context omitted.

> Not on any third party system, where you're locked out forever if you lose your second factor. Every two-factor system I've ever seen is actually two-of-three, with an account recovery code that you save elsewhere. I lost all my two-factor auths when my phone got wrecked, it was annoying to reestablish access to those accounts (and I now use a TOTP client which backs the tokesn up), but it was tedious rather than d…

> and I now use a TOTP client which backs the tokens up What are some good options for this? I think my ideal solution would export an encrypted file, a bit like KeePass does on the desktop, but I don't know of many mobile apps for that.

Aegis on Android.

Re: Social engineering takeovers of open source projects

#276

Post by akx » Mon, May 06, 2024, 10:13 AM UTC

guappa wrote: post #226

samatman wrote: post #64

Earlier quoted context omitted.

> Not on any third party system, where you're locked out forever if you lose your second factor. Every two-factor system I've ever seen is actually two-of-three, with an account recovery code that you save elsewhere. I lost all my two-factor auths when my phone got wrecked, it was annoying to reestablish access to those accounts (and I now use a TOTP client which backs the tokesn up), but it was tedious rather than d…

It was not difficult because you actually had the recovery codes. How many people have them? Also you're supposed to print them. Where? How many people own a printer? If you print them in a shop they can be considered compromised.

The recovery codes I've seen tend to have been 10 8-digit sequences.

If you don't have a printer and care about recovery codes, those are easy enough to transfer manually onto dead-tree material using a stylus-like handheld device that deposits graphite or ink onto the surface it touches.

Re: Social engineering takeovers of open source projects

#277

Post by guappa » Mon, May 06, 2024, 10:33 AM UTC

akx wrote: post #276

guappa wrote: post #226

Earlier quoted context omitted.

It was not difficult because you actually had the recovery codes. How many people have them? Also you're supposed to print them. Where? How many people own a printer? If you print them in a shop they can be considered compromised.

The recovery codes I've seen tend to have been 10 8-digit sequences. If you don't have a printer and care about recovery codes, those are easy enough to transfer manually onto dead-tree material using a stylus-like handheld device that deposits graphite or ink onto the surface it touches.

Except that you need to decipher your own handwriting years after having written it. And you also need to remember where you safely stored it.

Re: Social engineering takeovers of open source projects

#278

Post by caf » Mon, May 06, 2024, 10:34 AM UTC

josephg wrote: post #270

caf wrote: post #127

Earlier quoted context omitted.

With hindsight it's not the runtime behaviour of the library that you'd want to test - the weakest point in the chain is where the distributed source .tar.gz can't be regenerated from the project repository.

For how many projects is that actually checked? I bet barely any. Its especially difficult because most projects aren't built in a reproducible way. You should be able to uncompress and compare a source tarball. But if you get a binary and the source code used to generated that binary, there's no way to tell that they match.

Luckily the source tarball is the more important one to check, because that's the difference between backdooring one distribution and backdooring them all.

It's still not trivial because there might well be legitimate processing steps that are used to create the tarball, but it should be doable.

Re: Social engineering takeovers of open source projects

#279

Post by andix » Mon, May 06, 2024, 10:38 AM UTC

saagarjha wrote: post #254

somenameforme wrote: post #162

Earlier quoted context omitted.

I think you're going overboard on what's required. Take anybody who is simultaneously offered a substantial monetary incentive (let's say 4 years of total current/vesting comp), and also threatened with the release of something that we'll say is little more than moderately embarrassing. And this dev is being asked to do something that stands basically 0 risks of consequences/exposure for himself due to plausible deni…

This doesn't look intentional at all, because this is basically like how 90% of memory disclosure bugs look

Nobody can tell if they are intentional or accidental.

Re: Social engineering takeovers of open source projects

#280

Post by A1kmm » Mon, May 06, 2024, 10:41 AM UTC

krishadi wrote: post #245

I hope there is a better way to maintain open source projects without being overly cautious and suspicious of every PR someone makes. Maintaining open source projects is hard, and this is going to slow down development on many projects. And, rightly so, it's better to make a good code base, rather than one that is littered with backdoors. I wonder what could make this situation better for the maintainers of open sour…

Designing for safety helps a lot. Memory safe languages, reproducible builds, encoding safety properties in the type systems, and so on.

Sure, an attacker can subvert the types as well as the code, or use unsafe code, or try to tamper with infrastructure, but the more obvious it is that something is unsafe, the harder an attacker's job is.

The xz attacker introduced high-risk features over time and used them to justify weakening security controls and things that might have detected the problem. A culture of safety over the absolute best possible performance might help to make such attempts harder.