Social engineering takeovers of open source projects • Hacker News Board

Re: Social engineering takeovers of open source projects

#111

Post by leeoniya » Mon, May 06, 2024, 2:03 AM UTC

WanderPanda wrote: post #70

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

Wasn't a key thing of the xz attack vector that people where encouraged to download the custom source release instead of the autogenerated Github one? I don't know if that is a pattern but it seems like best practices in the (source) supply-chain could prevent a large class of these attacks.

yep.

same with npm. i publish releases of my OSS libs to npm, but there's no guarantee that what is uploaded is what you see on github. that's a lot of trust you have to put into my opsec, etc. not good.

Re: Social engineering takeovers of open source projects

#112

Post by arp242 » Mon, May 06, 2024, 2:03 AM UTC

Invictus0 wrote: post #103

arp242 wrote: post #71

Earlier quoted context omitted.

[flagged]

You're really going to pretend like there have been no socially-engineered cybersecurity attacks in the last 30 years...? And by the way, stabbings happen all the time, at least 3 per day. Stabbings hurt a few people, cybersecurity incidents can hurt millions.

This is about "social engineering takeovers of open source projects", not "socially-engineered cybersecurity attack", which is much much broader.

I've been pretty clued up on open source for the last 20 years, and I don't really recall any other similar incidents other than the two I mentioned. I tried to find other examples a few weeks ago and came up empty-handed. It's certainly not common. So please do post specifics if you know of additional incidents, because from what I can see, it's exceedingly rare.

Re: Social engineering takeovers of open source projects

#113

Post by Invictus0 » Mon, May 06, 2024, 2:07 AM UTC

We need KYC for open source--call it know-your-maintainer. It's only a matter of time before there's a really serious hack and this becomes imperative.

Re: Social engineering takeovers of open source projects

#114

Post by nyokodo » Mon, May 06, 2024, 2:08 AM UTC

emodendroket wrote: post #91

nyokodo wrote: post #89

Earlier quoted context omitted.

> consider the route of getting "kompromat" on a developer to make them "help" them I suppose that’s an option, but it also introduces an additional risk of exposure for your operation as it doesn’t always work and makes it much more complicated to manage even when it does work.

Does it matter though? They don’t have to say “I am so and so of the Egyptian intelligence service and would like to blackmail you”

> “I am so and so of the Egyptian intelligence service and would like to blackmail you”

No, but practically by definition the target has to know they’re being forced to “help” and therefore know someone is targeting the project. Some percentage of the time the target comes clean about whatever compromising information was gathered about them, which then potentially alerts the project to the fact they’re being targeted. When it does work you have to keep their mouth shut long enough for your operation to succeed which might mean they have an unfortunate accident, which introduces more risks, or you have to monitor them for the duration which ties up resources. It’s way simpler just to insert a trusted asset into a project.

Re: Social engineering takeovers of open source projects

#115

Post by nyokodo » Mon, May 06, 2024, 2:14 AM UTC

andix wrote: post #104

emodendroket wrote: post #91

Earlier quoted context omitted.

Does it matter though? They don’t have to say “I am so and so of the Egyptian intelligence service and would like to blackmail you”

They might not even use blackmail, they might just "help out" in a difficult financial situation. Some people are in severe debt, have a gambling problem, are addicted to expensive drugs, or might need a lot of money for a sick relative. There are many possibilities. The trick is finding the people that can be compromised.

> They might not even use blackmail, they might just "help out"

If the target knows or suspects what you’re asking them to do is nefarious then you still run the same risks that they talk before your operation is complete. It’s still far less risky to avoid tipping anyone else off and just slip a trusted asset into a project.

Re: Social engineering takeovers of open source projects

#116

Post by Mtinie » Mon, May 06, 2024, 2:14 AM UTC

WanderPanda wrote: post #66

andix wrote: post #47

Earlier quoted context omitted.

One follow up to compromising existing maintainers: This makes the creators or long-term good faith maintainers maybe even more "dangerous" than new maintainers.

Are we facing a Byzantine generals kind of situation now?

We have always faced it, it’s just that there's more awareness of the potential issues.

Re: Social engineering takeovers of open source projects

#117

Post by Mtinie » Mon, May 06, 2024, 2:19 AM UTC

arp242 wrote: post #107

josephg wrote: post #100

Earlier quoted context omitted.

If someone gets stabbed in the eye, we find out about it. So our statistics on eye-stabbing are probably accurate. We literally have no idea how many xz-style compromises are out there in the wild. We got really lucky with xz - it was only found because the backdoor was sloppy with performance and a microsoft employee got curious. But we have no data on all the times we got unlucky. How many packages in the linux eco…

You can always use the "we have no idea" argument because you can't prove something doesn't exist. Go find evidence. It's been over a month since xz and thus far we have zero additional incidents. And if you look at the specifics of xz attack: that wouldn't work for most projects because most don't have binary test files.

Are people really looking though? Are all open source libraries being run through extensive performance profiling to look for known heuristics? Are they being looked at line by line for aberrations?

I don’t have confidence that people are looking for evidence of potential exploitation because of reasons like the ones you bring up.

So we’re back to we just don’t know.

Re: Social engineering takeovers of open source projects

#118

Post by emodendroket » Mon, May 06, 2024, 2:21 AM UTC

nyokodo wrote: post #114

emodendroket wrote: post #91

Earlier quoted context omitted.

Does it matter though? They don’t have to say “I am so and so of the Egyptian intelligence service and would like to blackmail you”

> “I am so and so of the Egyptian intelligence service and would like to blackmail you” No, but practically by definition the target has to know they’re being forced to “help” and therefore know someone is targeting the project. Some percentage of the time the target comes clean about whatever compromising information was gathered about them, which then potentially alerts the project to the fact they’re being targete…

I would guess there are many projects they could target at any given time.

Re: Social engineering takeovers of open source projects

#119

Post by SlightlyLeftPad » Mon, May 06, 2024, 2:21 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?"

I’m in it for a free t-shirt.

Re: Social engineering takeovers of open source projects

#120

Post by MenhirMike » Mon, May 06, 2024, 2:27 AM UTC

tschwimmer wrote: post #50

andix wrote: post #33

Earlier quoted context omitted.

That's great that you are considering this more now. But the xy story taught us, that every contributor is dangerous, the most dangerous ones are probably the most helpful and most skilled contributors. If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor. Another thing that was not talked about a lot: There are many ways to compromise existing maintainers. Compromising…

>If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor. Unforuntately it's easy to sandbag being dumb. Just because someone submits a PR defining constants for 0-999 does not mean they're actually bad at programming.

> defining constants for 0-999

That person might just be an old school Java <5 developer.