35 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 software que importara el código, dijeron hoy expertos en software.

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 software afectados probablemente sea mucho menor, afirmó el ingeniero de software Stephen Lacy en una publicación de Twitter temprano en la mañana. El ataque, una variante de confusión de dependencia, podría haber causado problemas a los desarrolladores que usan los repositorios falsos de GitHub sin una verificación adecuada de la fuente del software, dijo.

Si se importa, el código malicioso ejecuta código en el sistema, según Lacy. “¡Este ataque enviará TODO EL ENV del script, la aplicación, la computadora portátil (aplicaciones electrónicas) al servidor del atacante! Los ENV incluyen: llaves 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 software encontró la funcionalidad maliciosa cuando auditó una biblioteca de software 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 retener compromisos 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 original también realizaron compromisos más nuevos. Las confirmaciones de código fuente abierto firmadas con 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 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 real. 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. ningún daño hecho. Se publicará un 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 Dark Jossef Harush, jefe de ingeniería de seguridad de la cadena de suministro de la firma de seguridad de software 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 original 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 original 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 software 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. El número de ataques contra la cadena de suministro de software saltó un 650% en 2021, impulsado principalmente por ataques de confusión de dependencias, donde el atacante usa 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 o componente deseado, o no noten 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 firma de seguridad de software Checkmarx reveló una forma de crear cuentas de desarrollador falsas en GitHub, completo 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, [y deben] revisar... el contenido de las contribuciones en comparación con el descargo de responsabilidad en el mensaje de confirmación y las contribuciones que agregan o modifican dependencias existentes a dependencias con nombres similares como parte de la aporte”, agrega.

No confíe, verifique

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 cuando evalúan el proyecto candidato y piensan que son legítimos, [por lo que] lo usan en sus computadoras de desarrollo locales, crean entornos, entornos de producción e incluso crean software, [hasta que finalmente ejecutan algo malicioso] en los clientes [ sistemas].”

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 software cuando los autores maliciosos se disfrazan como contribuyentes conocidos. Esto “hace que el proyecto parezca confiable”, la firma declaró. "Lo que hace que esta suplantación de identidad 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 ha agregado firmas digitales para compromisos de código para verificar la identidad del colaborador, pero los mantenedores del proyecto deben habilitar el "modo vigilante", una función de GitHub que muestra detalles del estado de verificación de cada compromiso 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.