Fundaciones de código abierto advierten sobre nuevos intentos de adquisición de ingeniería social tras XZ Utils

   MADRID, 17 Abr. (Portaltic/EP) -

   Las fundaciones de código abierto Open Source Security (OpenSSF) y OpenJS han advertido que el incidente de puerta trasera de XZ Utils "puede no ser aislado" tras interceptar nuevos intentos de adquisición de ingeniería social, por lo que han recomendado a los desarrolladores mantenedores de código abierto a "estar alerta".

   Tal y como se pudo conocer recientemente tras una investigación del desarrollador Andres Freund, a causa de fallos en el rendimiento de Linux, un actor malicioso consiguió insertar una puerta trasera (CVE-2024-3094) en las versiones más actuales de la herramienta xz Utils, con la que buscaba hacerse con el control total de los sistemas Linux afectados.

   Asimismo, los investigadores de seguridad señalaron como autor del ataque de puerta trasera a un usuario conocido como JiaT575 o Jia Tan. Este actor hizo su primer 'commit' en 2021, un cambio en el proyecto libarchive, y un año después comenzó a involucrarse en xz Utils, enviando parches y actualizaciones.

   Sin embargo, parece que este caso no ha sido un incidente aislado. Tras un intento similar interceptado por la Fundación OpenJS, que alberga proyectos JavaScript utilizados por "miles de millones" de sitios web en todo el mundo, las fundaciones OpenSSF y OpenJS han advertido sobre estos intentos de adquisición de ingeniería social, y han llamado a todos los desarrolladores de código abierto a "estar alerta".

   Así lo han compartido en un comunicado conjunto, en el que también han incidido en la importancia de que los mantenedores de código abierto puedan reconocer los patrones de amenazas de este tipo de ataques y tomen mediadas para proteger sus proyectos de código abierto.

   En este marco, la Fundación OpenJS ha dado a conocer un intento fallido de adquisición creíble que se llevó a cabo recientemente y que fue interceptado por la propia organización, en el que se pretendía engañar al Consejo de Proyectos Cruzados de la Fundación OpenJS.

   En esta ocasión, los ciberdelincuentes enviaron una serie de correos electrónicos sospechosos con mensajes similares, aunque con nombres distintos y desde direcciones de correos electrónicos superpuestos asociados a GitHub.

   En dichos correos, los actores maliciosos solicitaban a OpenJS que "tomara medidas" para actualizar uno de sus populares proyectos de JavaScript, de cara a "abordar cualquier vulnerabilidad crítica". Sin embargo, no mencionaban detalles específicos.

   Así, los autores de los correos electrónicos querían que la Fundación les permitiera participar o les designara como nuevos responsables del proyecto para abordar las vulnerabilidades en dicho programa, a pesar de haber tenido poca participación previa. Se trata de un modus operandi muy similar a la forma en la que actuó el presunto autor de la puerta trasera de XZ Utils, Jia Tan.

   Sin embargo, la Fundación se percató de este intento de ataque y denegó el acceso privilegiado del proyecto alojado en OPenJS a los autores de los correos electrónicos.

   Siguiendo esta línea, el equipo de OpenJS ha subrayado que también reconoció un patrón sospechoso similar en otros dos proyectos populares de JavaScript. No obstante, en esta ocasión eran proyectos que no estaban alojados en su Fundación.

   Ante esta situación, OpenJS procedió a informar sobre estos problemas de seguridad a la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) dentro del Departamento de Seguridad Nacional de Estados Unidos.

   Con todo ello, la Fundación ha señalado que aunque en los proyectos de código abierto "siempre se agradecen las contribuciones" se ha de estar alerta sobre el peligro que conlleva otorgar acceso administrativo al código fuente a desarrolladores desconocidos. Asimismo, ha insistido en que otorgar acceso como mantenedor "requiere un mayor nivel de confianza" y no se debe ofrecer como "solución rápida" a ningún problema.

PATRONES SOSPECHOSOS EN ADQUISICIONES DE INGENIERÍA SOCIAL

   De cara a ayudar a los desarrolladores de proyectos de código abierto a prevenir estos intentos de adquisición de ingeniería social, la Fundación OpenJS, junto con la Fundación Linux, han compartido algunos patrones sospechosos comunes en estos tipos de ataques.

   Por ejemplo, han señalado que los actores maliciosos suelen ser miembros relativamente desconocidos en la comunidad y llevan a cabo una persecución "amistosa pero agresiva y persistente" al desarrollador o la entidad donde está alojado el proyecto para convertirse en mantenedor.

   Igualmente, este tipo de solicitudes pueden ir respaldadas por otros miembros desconocidos de la comunidad que, según ha dicho OpenJS, también pueden utilizar identidades falsas.

   Además, los ciberdelincuentes suelen utilizar código fuente "intencionalmente ofuscado o difícil de entender", y llevan a cabo una desviación de las prácticas típicas de compilación para implementar proyectos que podrían permitir la inserción de cargas maliciosas externas en "blobs, zips u otros artefactos binarios".

   Todo ello se acompaña de un "falso sentimiento de urgencia" con el que se pretende obligar a reducir la minuciosidad ante posibles revisiones y evadir así los controles.

   "Este tipo de ataques son difíciles de detectar o proteger mediante programación, ya que se aprovechan de una violación de la confianza a través de la ingeniería social", ha sentenciado la Fundación, al tiempo que ha recomendado que, a corto plazo, compartir de forma transparente las actividades sospechosas que se identifiquen en los proyectos "ayudará a otras comunidades a mantenerse alerta".

   Finalmente, OpenJS también ha recomendado llevar a cabo ciertas prácticas de seguridad para los proyectos, como utilizar una autenticación "fuerte", habilitar la autenticación de dos factores (2FA) o multifactor (MFA), utilizar un administrador de contraseñas seguro y contar con una política de seguridad que incluya "un proceso de divulgación coordinada de informes". Igualmente, ha aconsejado que un segundo desarrollador realice revisiones de código.