
Millones de repositorios de GitHub pueden ser vulnerables al secuestro de repositorios de dependencia, también conocido como "RepoJacking", que podría ayudar a los atacantes a implementar ataques en la cadena de suministro que afecten a una gran cantidad de usuarios.
La advertencia proviene del equipo de seguridad de AquaSec , 'Nautilus', que analizó una muestra de 1,25 millones de repositorios de GitHub y descubrió que alrededor del 2,95 % de ellos son vulnerables a RepoJacking.
Al extrapolar este porcentaje a toda la base de repositorios de GitHub de más de 300 millones, los investigadores estiman que el problema afecta aproximadamente a 9 millones de proyectos.

¿Qué es RepoJacking?
Los cambios de nombre de usuario y nombre de repositorio son frecuentes en GitHub, ya que las organizaciones pueden obtener una nueva administración a través de la adquisición o fusión, o pueden cambiar a una nueva marca.
Cuando esto sucede, se crea una redirección para evitar romper las dependencias de los proyectos que usan código de repositorios que cambiaron su nombre; sin embargo, si alguien registra el nombre anterior, esa redirección se vuelve inválida.
RepoJacking es un ataque en el que un actor malintencionado registra un nombre de usuario y crea un repositorio utilizado por una organización en el pasado, pero que desde entonces ha cambiado de nombre.
Si lo hace, cualquier proyecto o código que se base en las dependencias del proyecto atacado obtenga dependencias y código del repositorio controlado por el atacante, que podría contener malware.

GitHub conoce esta posibilidad e implementó algunas defensas para los ataques de RepoJacking. Sin embargo, AquaSec informa que las soluciones hasta ahora han sido incompletas y se han pasado por alto fácilmente.
Por ejemplo, GitHub solo protege proyectos muy populares, pero esos proyectos pueden usar una dependencia de un repositorio vulnerable menos popular que no está cubierto, por lo que el compromiso de la cadena de suministro también los afecta.
Además, GitHub protege los repositorios con más de 100 clones la semana antes de cambiar de nombre, lo que indica preparaciones maliciosas. Esta protección no cubre proyectos que se hicieron populares después de su cambio de nombre o transferencia de propiedad.
Potencial de explotación
Para resaltar la importancia del problema, AquaSec escaneó organizaciones de renombre en busca de repositorios vulnerables y encontró casos explotables en repositorios administrados por Google y Lyft.
En el caso de Google, un archivo Léame que contenía instrucciones sobre cómo construir el proyecto bastante popular "Mathsteps" apuntaba a un repositorio de GitHub perteneciente a Socratic, una empresa que Google adquirió y asimiló en 2018 y ya no existe.
Dado que un atacante puede clonar ese repositorio para romper la redirección, los usuarios que siguieron las instrucciones Léame podrían haber descargado código malicioso del repositorio no autorizado.
Además, debido a que las instrucciones incluían un comando "npm install" para la dependencia, el código del atacante lograría la ejecución de código arbitrario en los dispositivos de usuarios desprevenidos.
Instrucciones de compilación en el archivo Léame de Google (AquaSec)
En el caso de Lyft, el ataque estaría más automatizado, ya que AquaSec encontró un script de instalación en el repositorio de la empresa que obtiene un archivo ZIP de otro repositorio, que es vulnerable a RepoJacking.
Un atacante que registre un nuevo nombre de usuario y repositorio con los nombres correctos ("YesGraph" y "Dominus" en este caso) podría inyectar su código a cualquiera que ejecute el script "install.sh" de Lyft.
Script de Lyft que apunta a un repositorio externo vulnerable a RepoJacking (AquaSec)Conclusión
Desafortunadamente, el riesgo de RepoJacking está muy extendido, es difícil de mitigar y puede tener graves repercusiones para las organizaciones y los usuarios.
Los propietarios de proyectos deben minimizar los recursos que obtienen de repositorios externos tanto como sea posible.
Además, los propietarios deben considerar mantener el control de los repositorios de marcas antiguas o de entidades adquiridas, solo para evitar ataques de secuestro de dependencia en ellos y sus usuarios.