GitHub asolado por un “investigador” que creó miles de proyectos maliciosos

Hace poco más de un año, escribimos sobre un “investigador de ciberseguridad” que publicó casi 4000 paquetes maliciosos de Python sin sentido en el popular repositorio PyPI.

Esta persona tenía el curioso apodo de Remind Supply Chain Risks, y los paquetes tenían nombres de proyectos que eran similares a proyectos conocidos, presumiblemente con la esperanza de que algunos de ellos se instalaran por error, gracias a que los usuarios utilizaran términos de búsqueda ligeramente incorrectos o cometieran pequeños errores al escribir las URL de PyPI.

Estos paquetes sin sentido no eran abiertamente maliciosos, pero sí llamaban a un servidor alojado en Japón, presumiblemente para que el autor pudiera recopilar estadísticas sobre este “experimento” y escribirlo mientras se hacía pasar como un “investigador”.

Un mes después, escribimos sobre un estudiante de doctorado (que debería haberlo hecho mejor) y su supervisor (que aparentemente era un profesor asistente de Informática en una universidad de Estados Unidos, y definitivamente, tambiéndebería haberlo hecho mejor) que se esforzaron por introducir numerosos parches aparentemente legítimos pero no estrictamente necesarios en el kernel de Linux.

Llamaron a estos parches hypocrite commits, y la idea era mostrar que dos parches enviados en diferentes momentos podrían, en teoría, combinarse más tarde para introducir un agujero de seguridad, contribuyendo efectivamente cada uno a una especie de “media vulnerabilidad” que no se detectaría como un error por sí misma.

Como puedes imaginar, el equipo del kernel de Linux no se tomó muy bien que se experimentara de esta manera sin permiso, entre otras cosas porque se enfrentaron a la limpieza del desastre:

Por favor, deja de enviar parches que no son válidos. Tu profesor está jugando con el proceso de revisión para conseguir un trabajo de una forma extraña y estrafalaria. No está bien, nos hace perder el tiempo, y tendremos que informar de esto, OTRA VEZ, a tu universidad…

GitHub inundado con código hostil

Esta vez, el experto de código abierto Steve Lacy informó de algo similar, pero peor (y mucho más extenso) que cualquiera de los ejemplos mencionados de pseudoinvestigación.

Una búsqueda de código fuente en GitHub que Lacy realizó de buena fe le llevó a un proyecto de aspecto legítimo que resultó no ser en absoluto lo que parecía, ya que era una copia clonada de un paquete no engañoso al que le añadieron unas pocas líneas que convertían el código en un auténtico malware.

Como explicó Lacy, “miles de proyectos falsos infectados [estaban] en GitHub, haciéndose pasar por proyectos reales. Todos ellos fueron creados en las últimas [tres semanas]”.

Como se puede ver, Lacy también señaló que las organizaciones que supuestamente estaban detrás de estos proyectos falsos eran “clones diseñados para tener nombres que parecían legítimos”, de manera que “las cuentas de usuarios legítimos (probablemente) no se vieron comprometidas”, pero donde “el atacante modificó el último commit en [los repositorios clonados] con código infectado”:

A few clarifications on the infected github projects as I was typing as I researched:

– The orgs are clones designed to have legitimate sounding names
– Legitimate user accounts are (probably) not compromised
– The attacker amended the last commit on repos with infected code

— Stephen Lacy (@stephenlacy) August 3, 2022

Infección de malware incluida

Según Lacy y la empresa de comprobación de código fuente Checkmarx, que se hizo con algunos de los proyectos infectados y los redactó antes de que fueran purgados de GitHub por Microsoft, los implantes de malware incluían código para llevar a cabo tareas como:

• Realizar un POST HTTP para exfiltrar el entorno de procesos del servidor actual. Tanto en Unix como en Windows, el entorno es una base de datos clave-valor basada en la memoria con información útil como el nombre del host, el nombre de usuario y el directorio del sistema. El entorno a menudo incluye secretos en tiempo de ejecución como tokens de autenticación temporales que sólo se mantienen en memoria para que nunca se escriban en el disco por error. (El bug Log4Shell fue ampliamente abusado para robar datos como tokens de acceso para Amazon Web Services mediante la exfiltración de variables de entorno).
• Ejecutar comandos shell arbitrarios en la respuesta HTTP enviada a la solicitud POST anterior. Esto esencialmente le da al atacante el control remoto completo de cualquier servidor en el que se instale y utilice el proyecto infectado. Los comandos del atacante se ejecutan con los mismos privilegios de acceso que el programa ahora infectado que incorpora el proyecto envenenado.

Afortunadamente, como mencionamos anteriormente, Microsoft actuó rápidamente para buscar y eliminar el mayor número posible de estos proyectos falsos, una reacción sobre la que Lacy tuiteó:

Correction, 35k+ "code hits" on github, not infected repositories.

— Stephen Lacy (@stephenlacy) August 3, 2022

El misterio se profundiza

Tras la salida (y la expulsión) de estos proyectos de malware, el propietario de una nueva cuenta de Twitter con el extraño nombre de pl0x_plox_chiken_p0x apareció para reclamar:

esto es un mero esfuerzo de bugbounty. no hay daño. el informe será publicado.

Llamar a casa para rastrear a tus víctimas como hizo Remind Supply Chain Risks el año pasado ya es bastante malo.

Enumerar a tus víctimas sin consentimiento no constituye una investigación, lo mejor que se podría llamar es probablemente una violación de la privacidad errónea y aterradora.

Pero llamar a casa a sabiendas para robar datos privados, tal vez incluyendo tokens de acceso en vivo, es un acceso no autorizado, que es un delito sorprendentemente grave en muchas jurisdicciones.

Y la instalación a sabiendas de un troyano de puerta trasera que permite implantar y ejecutar código sin permiso es, como mínimo, una modificación no autorizada, que se suma al delito de acceso no autorizado en muchos sistemas legales, y suele añadir unos cuantos años más a la pena máxima de prisión que podría imponerse si te pillan.

¿Qué hacer?

Este tipo de cosas no es “investigación” ni mucho menos, y es difícil imaginar que un investigador de ciberseguridad genuino, un jurado o un magistrado de un tribunal penal se traguen esa idea.

Así que, si alguna vez has tenido la tentación de hacer algo así bajo la falsa idea de que estás ayudando a la comunidad, por favor no lo hagas.

En particular:

• No contamines el ecosistema del software de código abierto con tu propia ciber-basura, sólo para “probar” una idea. Incluso si todo lo que haces es incluir código que imprime algún tipo de advertencia o mantiene anónimamente un registro de las personas que atrapaste, todavía estás haciendo un trabajo inútil para aquellos en la comunidad que tienen que poner en orden después de ti.
• No distribuyas casualmente malware y luego intentes justificarlo como “investigación” de ciberseguridad. Si abiertamente te apropias del código fiable de otras personas y lo vuelves a subir como si fuera un proyecto legítimo después de infectarlo deliberadamente con malware de robo de datos y puertas traseras de ejecución remota de código, no esperes que nadie se trague tus excusas.
• No esperes compasión si haces cualquiera de las dos cosas anteriores. El punto que pretendes hacer se ha hecho muchas veces antes. La comunidad de código abierto no lo agradeció anteriormente y no lo hará nunca.