オープンソース・プロジェクトの乗っ取りを試みる

The OpenJS Foundation Cross Project Council received a suspicious series of emails with similar messages, bearing different names and overlapping GitHub-associated emails. These emails implored OpenJS to take action to update one of its popular JavaScript projects to “address any critical vulnerabilities,” yet cited no specifics. The email author(s) wanted OpenJS to designate them as a new maintainer of the project despite having little prior involvement. This approach bears strong resemblance to the manner in which “Jia Tan” positioned themselves in the XZ/liblzma backdoor.

[…]

The OpenJS team also recognized a similar suspicious pattern in two other popular JavaScript projects not hosted by its Foundation, and immediately flagged the potential security concerns to respective OpenJS leaders, and the Cybersecurity and Infrastructure Security Agency (CISA) within the United States Department of Homeland Security (DHS).

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

• 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.
• Have a security policy including a “coordinated disclosure” process for reports.
• Use best practices for merging new code.
  • 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?
• If you run an open source package repository, consider adopting Principles for Package Repository Security.
• Review “Avoiding social engineering and phishing attacks” from CISA and/or “What is ‘Social Engineering’” from ENISA.