Application security

Open Source Groups Warn of Social Engineering Backdoors

An unknown hacker(s) has attempted to vandalize the Javascript program language deployed by billions of websites worldwide by trying to insert a socially engineered backdoor.

Two open source groups, the Open Source Security Foundation and the OpenJS Foundation, said the hacker(s) move to insert a backdoor into XZ Utils baked into the Linux operating systems was likely not a one-off.

In a jointly written blog, Robin Bender Ginn, the OpenJS executive director, and Omkhar Arasaratnam, the Open Source Security Foundation (OpenSSF) general manager, said the “recent attempted XZ Utils backdoor (CVE-2024-3094) may not be an isolated incident as evidenced by a similar credible takeover attempt intercepted by the OpenJS Foundation.”

Hacking Attempt Examined

Ginn and Arasaratnam said this about the hacking attempt:

  • In addition to the recent attempt, two other JavaScript projects were targeted by unnamed individuals demanding suspicious updates or asking to be made maintainers of the targeted software.
  • Granting 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 email author(s) wanted OpenJS to designate them as a new maintainer of the project despite having little prior involvement.
  • Open source maintainers have been alerted to look for social engineering takeover attempts, to recognize the early threat patterns emerging and to take steps to protect their open source projects.
  • The OpenJS Foundation Cross Project Council received a suspicious series of emails with similar messages, bearing different names and overlapping GitHub-associated emails.
  • The approach bears strong resemblance to the manner in which “Jia Tan” positioned themselves in the XZ/liblzma backdoor.

The emails urged OpenJS to take action to update one of its popular JavaScript projects to “address any critical vulnerabilities,” the groups said. Ginn and Arasaratnam declined to identify the JavaScript projects by name.

“Social engineering attacks like the ones we have witnessed with XZ/liblzma were successfully averted by the OpenJS community,” the Foundations said. “These types of attacks are difficult to detect or protect against programmatically as they prey on a violation of trust through social engineering.”

Suspicious Script Patterns Spotted

The Foundations listed suspicious patterns in social engineering takeovers:

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

Ginn and Arasaratnam warned maintainers to "pay attention to how interactions make you feel. Interactions that create self-doubt, feelings of inadequacy, of not doing enough for the project, etc. might be part of a social engineering attack."

Best Practice Recommendations

Maintainers should consider following industry-standard security best practices such as OpenSSF Guide, the Foundations said:

  • 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.
  • If you run an open source package repository, consider adopting Principles for Package Repository Security.

“Together with the Linux Foundation, we want to raise awareness of this ongoing threat to all open source maintainers, and offer practical guidance and resources from our broad community of experts in security and open source,” the authors said.

Related