La OpenSSF (Open Source Security Foundation), creada bajo los auspicios de la Fundación Linux para mejorar la seguridad del software de código abierto, advirtió a la comunidad sobre la identificación de actividades relacionadas con intentos de hacerse con el control de proyectos populares de código abierto, que recuerdan en su estilo. de las acciones de los atacantes en el proceso de preparación para instalar una puerta trasera en el proyecto xz. De manera similar al ataque a xz, personas dudosas que previamente no estaban profundamente involucradas en el desarrollo intentaron utilizar métodos de ingeniería social para lograr sus objetivos.
Los atacantes mantuvieron correspondencia con miembros del consejo de gobierno de la Fundación OpenJS, que actúa como una plataforma neutral para el desarrollo conjunto de proyectos abiertos de JavaScript como Node.js, jQuery, Appium, Dojo, PEP, Mocha y webpack. La correspondencia, que incluía a varios desarrolladores externos con dudosos historiales de desarrollo de código abierto, intentó convencer a la gerencia de la necesidad de actualizar uno de los proyectos populares de JavaScript seleccionados por la organización OpenJS.
Se afirmó que el motivo de la actualización era la necesidad de agregar "protección contra cualquier vulnerabilidad crítica". Sin embargo, no se proporcionaron detalles sobre la esencia de las vulnerabilidades. Para implementar los cambios, el desarrollador sospechoso se ofreció a incluirlo entre los mantenedores del proyecto, en cuyo desarrollo hasta entonces sólo había participado una pequeña parte. Además, se identificaron escenarios sospechosos similares para imponer su código en dos proyectos JavaScript más populares no asociados con la organización OpenJS. Se supone que los casos no son aislados y los mantenedores de proyectos de código abierto deben permanecer atentos al aceptar código y aprobar a nuevos desarrolladores.
Los signos que pueden indicar actividad maliciosa incluyen esfuerzos bien intencionados, pero al mismo tiempo agresivos y persistentes, por parte de miembros poco conocidos de la comunidad para acercarse a los mantenedores o gerentes de proyectos con la idea de promover su código u otorgar el estatus de mantenedor. También se debe prestar atención al surgimiento de un grupo de apoyo en torno a las ideas que se promueven, formado por personas ficticias que no han participado anteriormente en el desarrollo o se han incorporado recientemente a la comunidad.
Al aceptar cambios, debe considerar como signos de actividad potencialmente maliciosa los intentos de incluir datos binarios en solicitudes de fusión (por ejemplo, en xz, se envió una puerta trasera en los archivos para probar el desempaquetador) o código que sea confuso o difícil de entender. Se deben considerar los intentos de prueba de cambios menores que afecten la seguridad enviados para evaluar la respuesta de la comunidad y ver si hay personas rastreando los cambios (por ejemplo, xz reemplazó la función Safe_fprintf con fprintf). También deberían despertar sospechas los cambios atípicos en los métodos de compilación, montaje y despliegue del proyecto, el uso de artefactos de terceros y la intensificación del sentimiento de necesidad de adoptar cambios urgentemente.
Fuente: opennet.ru