The OpenSSF (Open Source Security Foundation) organization, created under the auspices of the Linux Foundation to improve the security of open source software, warned the community about detecting activity related to attempts to gain control over popular open source projects, which resembles in its style the actions of intruders in the process of preparing for the introduction of a backdoor into the xz project. Similar to the attack on xz, dubious individuals who were previously not deeply involved in development tried to use social engineering methods to achieve their goals.
The attackers entered into correspondence with members of the governing council of the OpenJS Foundation, which acts as a neutral platform for the joint development of open JavaScript projects, such as Node.js, jQuery, Appium, Dojo, PEP, Mocha и webpack. The correspondence, which was attended by several third-party developers with a dubious history of open source software development, attempted to convince the management of the need to update one of the popular JavaScript projects supervised by the OpenJS organization.
The reason for the update was the need to add "protection against any critical vulnerabilities". However, no details about the nature of the vulnerabilities were given. To implement the changes, the suspicious developer suggested that they be included in the list of maintainers of the project, in the development of which they previously took only a small part. In addition, two other popular JavaScript projects that are not related to the OpenJS organization have identified similar suspicious scenarios for imposing their own code. It is assumed that cases are not isolated and maintainers of open projects should not lose vigilance when accepting code and approving new developers.
Among the signs that may indicate malicious activity, there is a friendly, but at the same time aggressive and persistent, harassment of little-known community members to maintainers or project managers with the idea of promoting their code or providing maintainer status. Attention should also be paid to the appearance of a support group around the promoted ideas, formed from fictional individuals who have not previously participated in the development or have recently joined the community.
When accepting changes, you should take as signs of potentially malicious actions attempts to include binary data in merge requests (for example, in xz, the backdoor was passed in the archives to test the unpacker) or confusing or difficult to understand code. You should pay attention to trial attempts to make changes that slightly reduce security, sent to assess the community's response and check for people monitoring changes (for example, in xz, the Safe_fprintf function was replaced with fprintf). Suspicion should also be caused by atypical changes in the methods of compiling, building and deploying the project, using third-party artifacts, and whipping up a sense of the need for urgent adoption of changes.
The attackers entered into correspondence with members of the governing council of the OpenJS Foundation, which acts as a neutral platform for the joint development of open JavaScript projects, such as Node.js, jQuery, Appium, Dojo, PEP, Mocha и webpack. The correspondence, which was attended by several third-party developers with a dubious history of open source software development, attempted to convince the management of the need to update one of the popular JavaScript projects supervised by the OpenJS organization.
The reason for the update was the need to add "protection against any critical vulnerabilities". However, no details about the nature of the vulnerabilities were given. To implement the changes, the suspicious developer suggested that they be included in the list of maintainers of the project, in the development of which they previously took only a small part. In addition, two other popular JavaScript projects that are not related to the OpenJS organization have identified similar suspicious scenarios for imposing their own code. It is assumed that cases are not isolated and maintainers of open projects should not lose vigilance when accepting code and approving new developers.
Among the signs that may indicate malicious activity, there is a friendly, but at the same time aggressive and persistent, harassment of little-known community members to maintainers or project managers with the idea of promoting their code or providing maintainer status. Attention should also be paid to the appearance of a support group around the promoted ideas, formed from fictional individuals who have not previously participated in the development or have recently joined the community.
When accepting changes, you should take as signs of potentially malicious actions attempts to include binary data in merge requests (for example, in xz, the backdoor was passed in the archives to test the unpacker) or confusing or difficult to understand code. You should pay attention to trial attempts to make changes that slightly reduce security, sent to assess the community's response and check for people monitoring changes (for example, in xz, the Safe_fprintf function was replaced with fprintf). Suspicion should also be caused by atypical changes in the methods of compiling, building and deploying the project, using third-party artifacts, and whipping up a sense of the need for urgent adoption of changes.
