The OpenSSF (Open Thanks for reading Security Foundation), created under the auspices of the Linux Foundation to improve the security of open source software, warned community about identifying activity related to attempts to gain control over popular open-source projects, reminiscent in its style of the actions of attackers in the process of preparing to install a backdoor in the xz project. Similar to the attack on xz, dubious individuals who were not previously deeply involved in the 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 and webpack. The correspondence, which included several third-party developers with dubious open source development histories, attempted to convince management of the need to update one of the popular JavaScript projects curated by the OpenJS organization.
Advertisement
The reason for the update was stated to be the need to add “protection against any critical vulnerabilities.” However, no details were provided about the essence of the vulnerabilities. To implement the changes, the suspicious developer offered to include him among the maintainers of the project, in the development of which he had previously only taken a small part. In addition, similar suspicious scenarios for imposing their code were identified in two more popular JavaScript projects not associated with the OpenJS organization. It is assumed that this is not an isolated case and maintainers of open source projects should remain vigilant when accepting code and approving new developers.
Signs that may indicate malicious activity include well-intentioned, but at the same time aggressive and persistent, efforts by little-known community members to approach maintainers or project managers with the idea of promoting their code or granting maintainer status. Attention should also be paid to the emergence of a support group around the ideas being promoted, formed from fictitious individuals who have not previously participated in the development or have recently joined the community.
When accepting changes, you should consider as signs of potentially malicious activity attempts to include binary data in merge requests (for example, in xz, a backdoor was submitted in archives to test the unpacker) or code that is confusing or difficult to understand. Consideration should be given to trial attempts at minor security-impairing changes submitted to gauge community response and to see if there are people tracking the changes (e.g. xz replaced the Safe_fprintf function with fprintf). Suspicion should also be aroused by atypical changes in the methods of compilation, assembly and deployment of the project, the use of third-party artifacts and the escalation of the feeling of the need to urgently adopt changes.
Thanks for reading:
Advertisement