Live data from Hacker News

Social engineering takeovers of open source projects

openssf.org

141–150 of 379 posts

Re: Social engineering takeovers of open source projects

#141
post #13

Maybe we need a reporting system for maintainer changes of bigger projects. Some list where they get published and people can keep an eye on it. Those changes of maintainers need to be synced to package distribution sites like npm.js or Debian packages and put in context with versions/releases. In Europe this was introduced for banks after the banking crisis. If a bank does any organizational change, a report is sent…

How about simply paying the maintainers and then getting stuff done like the classical business does.

Did you mean: instead of trying to become a maintainer to a trusted open source project, how about bad actors simply bribe the existing maintainer to do their bidding? There would be no maintainer changes in that scenario.

Related, the motivation for trying to gain privileged access to open source projects is to leverage the existing trust associated with that project. A different long game that could be played is to create a new project with the intent on backdooring it a few years down the road, after it has gained sufficient trust.

Re: Social engineering takeovers of open source projects

#142
post #107

Earlier quoted context omitted.

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.

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

And xz wasn't the first. Several attempts have been made to put garbage in the kernel.

Re: Social engineering takeovers of open source projects

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

what do you look for to prevent this?

Re: Social engineering takeovers of open source projects

#145

There's an awkward reckoning in open source software about inclusivity and protecting the long-term security of projects coming. Authors from several countries were already suspicious, such as Iran. Anyone from Russia and China or unknown places are all potential risks now. Combined with recent inclusive ideologies, it’s gonna cause hard conversations. There will be a furthering in segmenting the Internet. Why fight…

I don't see how blocking contributions from people in Russia etc will help. Malicious actors can simply falsely claim to be American. Is GitHub going to start verifying citizenship? Even if GitHub did that, it likely wouldn't be too hard to fake.

Re: Social engineering takeovers of open source projects

#146
post #107

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.

No. If there is strong incentive to compromise, and little to no chance a compromise is being found, it's statistically most likely to assume compromises happen on a regular basis and only rarely are found out.

Re: Social engineering takeovers of open source projects

#147
post #107

Earlier quoted context omitted.

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.

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.

Re: Social engineering takeovers of open source projects

#148

Earlier quoted context omitted.

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

The more projects they target the more risk of being flagged and preventive measures to be engaged by counter intelligence etc.

Re: Social engineering takeovers of open source projects

#149

[flagged]

I can't begin to state how much of a tinfoil hat theory this is. The issues with the leadership were persistent since years. Just read the recent thread about it here people.

I want to say that, just like that nixpkgs maintainer with 18.000 commits, as a non-US citizen I'd also not contribute to NixOS/nixpkgs. I in no way would support the MIC of a genocidal state.

Re: Social engineering takeovers of open source projects

#150
post #134
post #112

Earlier quoted context omitted.

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

You seem super confident that there have been zero similar attacks that achieved their goals without detection. By definition, almost anyone who pulled off this kind of thing would try really hard not to burn that backdoor by being super obvious (for instance, using it to deface a website). We literally would not know anything about it, in all likelihood. Therefore I feel like it’s a lot more intellectually honest to…

What I'm argueing against is absolutist fear-mongering statements such as "every contributor is dangerous".

I'm not confident about anything, but anything could happen or have happened all the time. We need to operate on the reality that exists, not the reality that perhaps maybe possibly could perhaps maybe possibly exist. And we certainly shouldn't be treating anyone sending you a patch as a dangerous hostile actors by default.

Post reply on HN