-
Un ingeniero de software realizรณ el hallazgo e identificรณ la mayor parte de los repositorios daรฑados
-
GitHub eliminรณ la totalidad de los repositorios vinculados con el ataque.
Un ingeniero de software descubriรณ que 35.000 repositorios de GitHub habรญan sido bifurcados (clonados) para incluir malware.
ยซEstoy descubriendo lo que parece ser un ataque masivo de malware generalizado en GitHubยป, indica una publicaciรณn difundida hoy en Twitter por Stephen Lacy. Segรบn el ingeniero, muchas de las confirmaciones parecรญan ser inofensivas.
Otras, en cambio, incluรญan confirmaciones del autor original en GitHub, pero ninguna incluรญa una confirmaciรณn con GPG, un tipo de llave pรบblica criptogrรกfica que sirve para comprobar que el origen de un mensaje es genuino.
Algunos repositorios, que parecรญan tener todos los archivos infectados, mostraban seรฑales de legitimidad. Sin embargo, no habรญan recibido ningรบn PR o solicitud de integraciรณn. Esto probarรญa que otros desarrolladores estaban participando en la programaciรณn de un determinado proyecto.
En un caso especรญfico, el atacante creรณ un repositorio falso de un proyecto de minerรญa de criptomonedas y enviรณ un clon de un proyecto legรญtimo infectado.
El ataque no daรฑรณ ningรบn proyecto legรญtimo
GitHub eliminรณ todos los repositorios que tenรญan elementos sospechosos al recibir la notificaciรณn de Stephen Lacy, incluyendo algunos que parecรญan haber sido ยซarchivadosยป en 2019 y en 2015.
Tambiรฉn se comprobรณ posteriormente que ningรบn proyecto legรญtimo habรญa sido alterado de ninguna manera. Entre las pruebas que podemos citar se encuentra una URL que Lacy habรญa ยซencontrado en una bรบsqueda en Googleยป mientras investigaba sobre un proyecto de cรณdigo abierto en GitHub: hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ru.
La URL era comรบn a todos los repositorios clonados y sirviรณ a muchos para reconocer cuรกles podrรญan estar infectados. Si alguien intenta acceder en este momento a uno de los enlaces compartidos por Stephen Lacy se encontrarรก un cรณdigo de error 404 o una redirecciรณn al repositorio legรญtimo.
Cรณmo funcionaba el ataque
La prรกctica de bifurcar un repositorio de cรณdigo abierto es comรบn en el desarrollo. Sin embargo, en esta oportunidad habรญa una intenciรณn oculta.
El desarrollador James Tucker seรฑalรณ que los repositorios clonados que contenรญan la URL maliciosa contenรญan una puerta trasera de una lรญnea de cรณdigo, como informรณ Bleepingcomputer. Ademรกs, exfiltraban las variables de entorno del usuario.
La filtraciรณn de variables de entorno puede proporcionar al atacante informaciรณn de seguridad valiosa. Por ejemplo, sus claves API, claves criptogrรกficas, tokens y credenciales de Amazon AWS.
Por su parte, la instrucciรณn de una sola lรญnea (lรญnea 241 anterior) permite que los atacantes remotos ejecuten cualquier cรณdigo arbitrario en los sistemas de aquellos usuarios que instalen y ejecuten estos clones maliciosos.
Bleepingcoputer descubriรณ ademรกs que, de los mรกs de 35.000 repositorios sospechosos, 13.000 provenรญan de un mismo repositorio denominado ยซredhat-operator-ecosystemยป. Tambiรฉn, determinaron que la lรญnea de tiempo de creaciรณn de estos falsos repositorios podrรญa ubicarse, en mayor medida, entre seis y veinte dรญas. Aunque algunas confirmaciones son tan antiguas como 2015, presuntamente.