Open Source Leaders Warn of XZ Utils-Like Takeover Attempts

The OpenSSF and OpenJS Foundations have issued a warning to open source maintainers regarding a series of social engineering attacks reminiscent of the xz Utils campaign. These attacks involve suspicious emails sent to the OpenJS Foundation Cross Project Council, requesting urgent updates to popular JavaScript projects under the pretext of addressing critical vulnerabilities. The emails demand that the senders be appointed as new maintainers to handle these updates.

To raise awareness within the open source community, OpenJS released warning signs of suspicious activity. These include aggressive pursuit by relatively unknown community members, requests for elevation to maintainer status by new or unknown individuals, endorsements from dubious sources using false identities, unreadable pull requests containing blobs instead of source code, intentionally obfuscated code, and an increase in security issues to slip malicious activity under the radar. They also noted deviations from standard project practices to insert external malicious payloads and a false sense of urgency to bypass thorough review processes.

Security Officer Comments:
Endor Labs, emphasized the severity of these attacks, highlighting the underfunded nature of many open source projects and the vulnerability of maintainers to social engineering tactics. He warned that these attacks pose a significant threat to the open source and software community, as malicious actors may already have successfully infiltrated projects by exploiting the pressures and limitations faced by maintainers.

Suggested Corrections:

  • Consider following industry-standard security best practices such as OpenSSF Guides.
  • Use strong authentication.
    • Enable two-factor authentication (2FA) or Multifactor Authentication (MFA).
    • Use a secure password manager.
    • Preserve your recovery codes in a safe, preferably offline place.
    • Do not reuse credentials/passwords across different services.
    • Enable branch protections and signed commits.
    • If possible, have a second developer conduct code reviews before merging, even when the PR comes from a maintainer.
    • Enforce readability requirements to ensure new PRs are not obfuscated, and use of opaque binaries is minimized.
    • Limit who has npm publish rights.
    • Know your committers and maintainers, and do a periodic review. Have you seen them in your working group meetings or met them at events, for example?