CyberClub

The Open Source Security Foundation (OpenSSF) together with the OpenJS Foundation have identified additional incidents where attackers attempted to social engineer their way into the management of open source projects using similar techniques that recently led to the backdooring of the XZ Utils package.

XZ Utils supply chain compromise

The XZ Utils software supply chain compromise was the result of a sophisticated social engineering effort where an attacker managed to earn the trust of the project’s maintainer through legitimate code contributions over multiple years until they were made co-maintainer and gained direct control over the project’s releases.

The attacker used a fake identity under the name Jia Tan (JiaT75) through which they made contributions to multiple projects in order to gain legitimacy. Their code submissions received positive feedback from other users that are now believed to have been sock puppet accounts also created by the attacker to pressure the XZ Utils maintainer into giving Jia Tan commit access.

Tan’s contributions laid the groundwork for what would eventually turn out to be a very stealthy backdoor that got added to the XZ Utils package in March this year. The backdoor was discovered by accident by a Microsoft software engineer before the poisoned releases made it into the stable versions of Linux distributions — an event that would have impacted millions of servers worldwide.

Additional attempts discovered

The incident, described by security experts as one of the most sophisticated and stealthy software supply chain compromises to date, showed the fragility of the trust-based open-source ecosystem. The open-source community immediately started looking for signs of similar long-term social engineering attacks in other projects, because if it happened to one, it could have happened to more. And it wasn’t long until additional attempts were discovered.

“The OpenJS Foundation Cross Project Council received a suspicious series of emails with similar messages, bearing different names and overlapping GitHub-associated emails,” the OpenSSF and OpenJS Foundation said in a joint alert. “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 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.”