The OpenJS Foundation was formed from the merging of the Node.js Foundation and the JS Foundation and hosts many JavaScript projects and technologies that are used by millions of websites and applications including Appium, Electron, jQuery, Node.js and webpack. In addition to detecting the social engineering attempt targeting one of its own projects, the Foundation also found similar suspicious patterns in two other popular JavaScript projects that are not managed by itself and alerted the US Cybersecurity and Infrastructure Security Agency (CISA) and OpenSSF.

“Open-source projects always welcome contributions from anyone, anywhere, yet granting someone administrative access to the source code as a maintainer requires a higher level of earned trust, and it is not given away as a ‘quick fix’ to any problem,” the two Foundations said in their alert.

What project maintainers should be aware

Projects maintainers, as well as companies and organizations that oversee, fund and host open-source projects should watch for signs that could indicate a potential social engineering attempt. These include:

• Friendly yet aggressive and persistent pursuit of maintainer or their hosted entity (foundation or company) by relatively unknown members of the community.
• Request to be elevated to maintainer status by new or unknown persons.
• Endorsement coming from other unknown members of the community who may also be using false identities, also known as “sock puppets.”
• Pull requests (PRs) containing blobs as artifacts. For example, the XZ backdoor was a cleverly crafted file as part of the test suite that wasn’t human readable, as opposed to source code.
• Intentionally obfuscated or difficult to understand source code.
• Gradually escalating security issues. For example, the XZ issue started off with a relatively innocuous replacement of safe_fprintf() with fprintf() to see who would notice.
• Deviation from typical project compile, build, and deployment practices that could allow the insertion of external malicious payloads into blobs, zips, or other binary artifacts.
• A false sense of urgency, especially if the implied urgency forces a maintainer to reduce the thoroughness of a review or bypass a control.

Maintainers should scrutinize interactions with users and contributors that seem to be aimed at creating self-doubt and feelings of inadequacy. Attackers will often try to make maintainers feel guilty for not doing enough for the project or not fixing issues fast enough because they know that many open-source projects lack development resources and it’s not unusual for them to be maintained by a single individual in their spare time.

Other recommendations include following security best practices like those found in the OpenSSF guides; using strong authentication and enabling two-factor authentication; using a password manager to ensure passwords are complex and unique for each account; maintaining a security policy and a process for reporting vulnerabilities; enabling branch protections in repositories and as well as signed commits; enforcing mandatory code reviews by a second person before merging code, even if the code comes from a trusted maintainer; enforcing code readability standards and limiting the use of binaries (compiled code) inside pull requests; and periodically reviewing maintainers and trying to set up meetings in order to get to know them.

“The pressure to sustain a stable and secure open-source project creates pressure on maintainers,” the two Foundations said. ‘For example, many projects in the JavaScript ecosystem are maintained by small teams or single developers who are overwhelmed by commercial companies who depend on these community-led projects yet contribute very little back. To solve a problem of this scale, we need vast resources and public/private international coordination.”