Repo jacking en bundler.io: supply chain abierta

Qué pasa

Un investigador descubrió y reportó en HackerOne que bundler.io —documentación oficial de Bundler, el gestor de gemas de Ruby— enlazaba a dos repositorios de GitHub (`rubygems/bundler-site` y `rubygems/bundler.github.io`) cuyo username original había quedado libre tras un cambio de propietario en la organización.

El bug class es repo jacking (*secuestro de repositorio de dependencias*, una variante de *supply chain attack* — ataque que compromete la cadena de suministro de software en lugar del objetivo final directamente). El mecanismo es simple: cuando un usuario u organización de GitHub cambia de nombre, el username anterior queda disponible para que cualquier persona lo registre. Si sitios con autoridad —como la documentación oficial de un gestor de dependencias— siguen apuntando a esa URL antigua, el atacante que reclama el username puede *reemplazar el contenido al que todos los links del ecosistema hacen referencia*.

El informe también identificó un open redirect (redirección abierta — una URL de un dominio de confianza que redirige al usuario a cualquier destino que el atacante elija) en el mismo dominio de bundler.io, encadenando ambos vectores para amplificar el alcance del ataque.

Por qué importa

Este patrón no es exclusivo de RubyGems. El mismo vector existe en *cualquier proyecto* cuya documentación, README, o sitio web enlace repos de GitHub con usernames que alguna vez cambiaron. Y no hace falta que el repo contenga código ejecutable directamente: basta con que sirva scripts de instalación, snippets que se copian en terminales, o que esté listado como fuente de confianza.

La superficie es enorme. Miles de proyectos open source han pasado por fusiones, renombrados o abandonos de cuentas. Los IOC (huellas técnicas que delatan el ataque — en este caso, repos reclamados con contenido inesperado) son difíciles de detectar si no monitorizas activamente qué hay detrás de los links que publicas.

El open redirect añade otro ángulo: incluso sin llegar al repo jacking completo, un atacante puede abusar de redirects en dominios de confianza para saltarse filtros anti-phishing o encadenar con otros ataques de ingeniería social.

El bug class combina baja barrera de entrada (registrar un username es gratis y trivial) con impacto potencialmente crítico (inyección de código en proyectos que confían en esas referencias). Es el tipo de hallazgo que los programas de bug bounty (programas de recompensa por vulnerabilidades) tienden a subestimar hasta que alguien lo explota en producción.

Qué hacer

Si mantienes documentación o un sitio de proyecto:

• Audita hoy todos los links externos a GitHub en tu documentación, README y sitio web. Verifica que los usernames sigan activos y pertenecen a quien deben.
• Configura alertas (GitHub Dependabot, scripts de monitorización) para detectar cambios inesperados en repositorios que referencias.
• Migra links a URLs con commit hash o forks bajo tu propia organización cuando el repositorio externo sea crítico.

Si cazas bugs (bug bounty hunter):

• Busca en `waybackmachine.org` o `github.com/search` usernames referenciados en docs de proyectos populares que ya no existen como organización activa.
• Comprueba si el dominio objetivo tiene endpoints con parámetros `?url=`, `?redirect=`, `?next=`, `?return_to=` — son candidatos a open redirect.
• Encadena repo jacking + open redirect para elevar severidad: el redirect puede usarse para que el sitio oficial sirva como puente hacia el repo malicioso.

Si eres SOC (equipo de operaciones de seguridad que monitoriza amenazas activas):

• Incluye monitorización de repositorios de dependencias en tu modelo de amenazas para proyectos internos que usen gestores de paquetes basados en GitHub.

El patrón de repo jacking lleva años documentado pero sigue apareciendo en programas maduros. La razón: los equipos auditan código, no links. Un link en docs tiene la misma capacidad de daño que una dependencia directa si está en la cadena de confianza.