The OpenSSF (Open Source Security Foundation), established under the auspices of the Linux Foundation to enhance the security of open-source software, has alerted the community about detected activities related to attempts to gain control over popular open-source projects, reminiscent of the tactics used by attackers preparing to insert a backdoor into the xz project. Similar to the attack on xz, questionable individuals, who were previously not deeply involved in development, attempted to use social engineering methods to achieve their goals.
The attackers engaged in correspondence with members of the board of the OpenJS Foundation, which serves as a neutral platform for collaborative development of open JavaScript projects, such as Node.js, jQuery, Appium, Dojo, PEP, Mocha, and webpack. In the correspondence, involving several external developers with questionable open-source development histories, efforts were made to convince the leadership of the need to update one of the popular JavaScript projects overseen by OpenJS.
The reason given for the update was the necessity to add "protection against any critical vulnerabilities." However, no details about the nature of these vulnerabilities were provided. To facilitate the changes, the suspicious developer proposed to be included among those maintaining the project, in which they had previously only played a minor role. Additionally, similar suspicious scenarios of imposing their code have been identified in two other popular JavaScript projects unrelated to OpenJS. It is believed that such cases are not isolated, and those maintaining open projects should remain vigilant when accepting code and approving new developers.
Among the signs that may indicate malicious activity, mention is made of the friendly, yet simultaneously aggressive and persistent, behavior of less-known community members approaching project maintainers or leaders with ideas to promote their code or gain maintainer status. Attention should also be drawn to the emergence of a support group around the promoted ideas, formed from fictitious personalities who previously did not participate in the development or have recently joined the community.
When accepting changes, one should interpret as signs of potentially harmful actions the attempts to include binary data in merge requests (for example, a backdoor was passed in archives for testing the unpacker in xz) or convoluted and hard-to-understand code. Attention should be paid to trial attempts to make changes that slightly reduce security, sent to gauge community reaction and check for the presence of individuals monitoring the changes (for example, in xz the Safe_fprintf function was replaced with fprintf). Suspicion should also arise from atypical changes in the project's compilation, build, and deployment methods, the involvement of third-party artifacts, and the instillation of a sense of urgency to accept changes.
Source: opennet.ru
