35.000 inserciones de código malicioso en GitHub: ¿ataque o esfuerzo de recompensa por errores?



Un hacker con el nombre de usuario «Pl0xP» clonó una gran cantidad de repositorios de GitHub y cambió ligeramente los nombres de los repositorios clonados, en un intento de suplantar proyectos legítimos, lo que podría infectar cualquier program que importara el código, dijeron hoy expertos en software package.

La clonación generalizada resultó en más de 35,000 inserciones de una URL maliciosa en diferentes repositorios de código, aunque la cantidad exacta de proyectos de application afectados probablemente sea mucho menor, afirmó el ingeniero de computer software Stephen Lacy en una publicación de Twitter temprano en la mañana. El ataque, una variante de la confusión de dependencias, podría haber causado problemas a los desarrolladores que utilizan los repositorios falsos de GitHub sin una verificación adecuada de la fuente del software program, dijo.

Si se importa, el código malicioso ejecuta código en el sistema, según Lacy. «¡Este ataque enviará el ENV COMPLETO del script, la aplicación, la computadora portátil (aplicaciones electrónicas) al servidor del atacante! Los ENV incluyen: claves de seguridad, claves de acceso de AWS, claves criptográficas… mucho más».

Los «ENV» son variables de entorno que se utilizan para almacenar información a la que los desarrolladores quieren hacer referencia en sus flujos de trabajo.

El ingeniero de computer software encontró la funcionalidad maliciosa cuando auditó una biblioteca de application que consideró incorporar a su propio proyecto, dijo Lacy.

«Descubrí el exploit mientras revisaba un proyecto que encontré en una búsqueda de Google». tuiteó. «¡Es por eso que no instalamos paquetes aleatorios de Internet!»

La clonación, o «bifurcación», no es una nueva técnica maliciosa, pero es engañosa.

«Ya se conocía a los malos actores en el pasado por crear repositorios populares clonados/bifurcados con código malicioso», dice Mor Weinberg, ingeniero de software de Aqua Security. «Esto puede volverse bastante difícil de detectar, ya que los repositorios clonados pueden conservar confirmaciones de código con nombres de usuario y direcciones de correo electrónico de los autores originales, dando la impresión engañosa de que los autores del proyecto primary también realizaron confirmaciones más nuevas. Confirmaciones de código fuente abierto firmadas con Las claves GPG de autores de proyectos auténticos son una forma de verificar la autenticidad del código».

«Esto… era como si alguien levantara un sitio world-wide-web ‘falso’ o enviara un correo electrónico de phishing», agrega Mark Lambert, vicepresidente de productos de ArmorCode. «Esto va a atrapar a las personas que no están prestando atención».

¿Un ataque o una investigación legítima?

Es posible que esta bifurcación masiva en GitHub no haya sido un ataque genuine. Una persona que afirmaba tener conocimiento del tema posicionó el error tipográfico generalizado como un esfuerzo de investigación legítimo.

«Este es un mero esfuerzo de recompensa por errores. No se hace daño. Se publicará el informe», un El usuario de Twitter llamado «pl0x_plox_chiken_p0x» tuiteó el 3 de agosto.

Si bien un proyecto de investigación mal concebido podría explicar el ataque, crear miles de cambios de código para la investigación parece irracionalmente arriesgado. Además, el usuario de Twitter solo había registrado la cuenta en los tres días anteriores: la vida útil corta de la cuenta suele ser una característica de las personas fraudulentas en línea.

La afirmación de que el ataque es parte de una recompensa por errores «está a la espera de ser probada, ya que la actividad tiene las características de uno con una intención maliciosa», le dice a Darkish Jossef Harush, jefe de ingeniería de seguridad de la cadena de suministro de la firma de seguridad de program Checkmarx. Lectura.

En cualquier caso, Michael Skelton, director sénior de operaciones de seguridad en la plataforma de recompensas por errores Bugcrowd, señala que al menos los repositorios del código unique no se vieron afectados.

«Si bien no está claro cuál sería la naturaleza del hallazgo de recompensas por errores de Pl0xP (ya que la ingeniería social está fuera del alcance de casi todos los programas de recompensas por errores), parece que clonaron varios repositorios e hicieron sus cambios en esos clones solo que, en ningún caso, este cambio llegó a los repositorios originales que habían sido clonados», dice. «Clonar un repositorio es una acción estándar que no afecta el repositorio primary a menos que el propietario vuelva a fusionar un cambio (solicitado a través de una solicitud de extracción), que no se hizo aquí».

Abundan las dependencias de program malicioso

GitHub aparentemente limpió las confirmaciones de código malicioso y, a partir de la tarde del 3 de agosto, una búsqueda de la URL incorrecta incrustada no arrojó resultados. Sin embargo, el ataque no es la primera vez que los proyectos de código abierto han tenido que lidiar con atacantes. La cantidad de ataques contra la cadena de suministro de software package aumentó un 650 % en 2021, impulsados ​​principalmente por ataques de confusión de dependencias, en los que el atacante united states una versión con un nombre casi idéntico de un bloque de código fuente abierto con la esperanza de que los desarrolladores escriban mal el nombre de una biblioteca deseada o componente, o no darse cuenta de la ligera diferencia en la nomenclatura.

Sembrar repositorios con proyectos maliciosos y con nombres incorrectos requiere que el atacante haga un trabajo preliminar. En julio, la empresa de seguridad de program Checkmarx reveló una forma de crear cuentas de desarrollador falsas en GitHub, con un historial activo de compromisos de código para aumentar su credibilidad. La técnica, junto con el último ataque, subraya que los mantenedores deben tomar medidas para aceptar solo compromisos de código firmado, dice Harush. Los desarrolladores deben «tener cuidado con las solicitudes de incorporación de cambios y las contribuciones que tienen confirmaciones no verificadas sospechosas, [and need to] revise… el contenido de las contribuciones en comparación con el descargo de responsabilidad en el mensaje de confirmación y las contribuciones agregando o modificando dependencias existentes a dependencias con nombres similares como parte de la contribución», agrega.

No confíes, verifica

Para evitar que sus proyectos se envenenen, los mantenedores y desarrolladores solo deben confiar en aquellos colaboradores que conocen y que tienen un historial de confirmaciones extenso y verificable. También deben usar las herramientas disponibles, como firmas digitales y autenticación multifactor, para proteger sus cuentas, dice Harush.

«Como no debes confiar en los dulces de los extraños, no confíes en el código de los extraños», dice. «Los usuarios pueden ser engañados al evaluar el proyecto candidato y pensar que son legítimos, [so] lo usan en sus computadoras de desarrollo locales, crean entornos, entornos de producción e incluso crean application, [until finally executing something malicious] en los clientes [systems].»

En el aviso de julio de Checkmarx sobre la falsificación de información de identidad y la información de compromiso en el git utilidad de línea de comandos, la compañía subrayó los riesgos para los proyectos de application cuando los autores maliciosos se disfrazan como contribuyentes conocidos. Esto «hace que el proyecto parezca digno de confianza», la firma declaró. «Lo que hace que esta falsificación de confirmación sea aún más alarmante es el hecho de que el usuario que está siendo falsificado no recibe una notificación y no sabrá que se está utilizando su nombre».

GitHub ya agregó firmas digitales para confirmaciones de código para verificar la identidad del colaborador, pero los mantenedores del proyecto deberían habilitar el «modo vigilante», una función de GitHub que muestra detalles del estado de verificación de cada confirmación y su colaborador, afirmó Checkmarx.

Como mínimo, los desarrolladores y mantenedores de proyectos deberían revisar ocasionalmente su registro de confirmación y pedirles a sus otros mantenedores que habiliten las confirmaciones firmadas por GPG, dice Harush. «Acostumbrarse a tener un registro de compromiso firmado lo beneficiará para prestar atención a las contribuciones no verificadas».

GitHub no pudo ser contactado de inmediato para hacer comentarios.





Enlace a la noticia authentic