Hackers Attempted To Takeover JavaScript Project From OpenJS Foundation

Attackers tried to take over the JavaScript project from OpenJS Foundation, which is home to JavaScript projects utilized by billions of websites globally. 

This is similar to the incident that was recently disclosed and targeted at the open-source XZ Utils tracked as (CVE-2024-3094).

The XZ Utils software supply chain breach was the outcome of a highly skilled social engineering operation in which the attacker gained the project’s maintainer’s trust over several years by making valid code contributions.

The Open Source Security Foundation (OpenSSF) and OpenJS published a joint alert on a similar credible takeover attempt, advising users to identify developing attack patterns and take precautions to secure their open-source projects.

Specifics Of The Additional Credible Takeover Attempt

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

Free Live Webinarfor DIFR/SOC Teams: Securing the Top 3 SME Cyber Attack Vectors - Register Here.

Despite having little past involvement, the email author(s) requested that OpenJS designate them as a new maintainer of the project.

The way that “Jia Tan” positioned themselves in the XZ/liblzma backdoor is quite similar to this strategy. 

None of these individuals have been granted special access to the project hosted by OpenJS. 

In this case, administrative access to the source code as a maintainer is not given out as a “quick fix” for any issue and instead demands a higher degree of earned trust.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) stated last week that the XZ Utils backdoor event also emphasizes the “fragility” of the open-source ecosystem and the risks brought about by maintainer weakness.

The report advised paying attention to how interactions make you feel. A social engineering attack could involve interactions that foster self-doubt, feelings of inadequacy, the idea that you’re not doing enough for the project, etc.

• Relatively unknown community members have been politely but aggressively and persistently pursuing the maintainer or their hosted entity.
• Request from new or unidentified individuals to be promoted to maintainer status.
• Endorsement from more unidentified community members who might likewise be acting under pretenses—a.k.a. “sock puppets”.
• PRs with blobs included as artifacts.
• Purposefully obscured or challenging to comprehend source code. 
• Gradually escalating security issues.
• Deviation from standard project deployment, build, and compilation procedures can make it possible for malicious payloads from the outside to be inserted into binary artifacts like zip files or blobs. 
• A delusion of urgency, particularly if it compels a maintainer to skip a control or do a review with less care.

In addition, OpenSSF recommends following industry-standard security best practices, strong authentication, a security policy including a “coordinated disclosure”, and emerging best practices for merging new code.

Looking to Safeguard Your Company from Advanced Cyber Threats? Deploy TrustNet to Your Radar ASAP.