El ataque MavenGate podría permitir a los piratas informáticos secuestrar Java y Android a través de bibliotecas abandonadas


Se ha descubierto que varias bibliotecas públicas y populares abandonadas pero que aún se utilizan en aplicaciones Java y Android son susceptibles a un nuevo método de ataque a la cadena de suministro de software llamado MavenGate.

«El acceso a los proyectos puede ser secuestrado mediante la compra de nombres de dominio y, dado que la mayoría de las configuraciones de compilación predeterminadas son vulnerables, sería difícil o incluso imposible saber si se está realizando un ataque», Oversecured dicho en un análisis publicado la semana pasada.

La explotación exitosa de estas deficiencias podría permitir a actores nefastos secuestrar artefactos en dependencias e inyectar código malicioso en la aplicación y, peor aún, incluso comprometer el proceso de compilación a través de un complemento malicioso.

La firma de seguridad móvil agregó que todas las tecnologías basadas en Maven, incluido Gradle, son vulnerables al ataque y que envió informes a más de 200 empresas, incluidas Google, Facebook, Signal, Amazon y otras.

Apache Maven es utilizado principalmente para crear y administrar proyectos basados ​​en Java, lo que permite a los usuarios descargar y administrar dependencias (que se identifican de forma única por sus ID de grupo), crear documentación y administrar versiones.

Si bien los repositorios que albergan dichas dependencias pueden ser privado o públicoun atacante podría apuntar a este último para realizar ataques de envenenamiento de la cadena de suministro aprovechando bibliotecas abandonadas agregadas a repositorios conocidos.

En concreto, se trata de la compra de los caducados. dominio invertido controlado por el propietario de la dependencia y obteniendo acceso al groupId.

La seguridad cibernética

«Un atacante puede obtener acceso a un ID de grupo vulnerable haciendo valer sus derechos sobre él a través de un registro TXT DNS en un repositorio donde no existe ninguna cuenta que administre el ID de grupo vulnerable», dijo la compañía.

«Si un ID de grupo ya está registrado en el repositorio, un atacante puede intentar obtener acceso a ese ID de grupo comunicándose con el equipo de soporte del repositorio».

Para probar el escenario de ataque, Oversecured cargó su propia biblioteca de prueba de Android (groupId: «com.oversecured»), que muestra el mensaje «¡Hola mundo!» en Maven Central (versión 1.0), y al mismo tiempo cargó dos versiones en JitPack. , donde la versión 1.0 es una réplica de la misma biblioteca publicada en Maven Central.

Pero la versión 1.1 es una copia editada «no confiable» que también tiene el mismo ID de grupo, pero que apunta a un repositorio de GitHub bajo su control y se reclama agregando un registro DNS TXT para hacer referencia al nombre de usuario de GitHub para poder establecer prueba de propiedad.

Luego, el ataque funciona agregando Maven Central y JitPack a la lista del repositorio de dependencia en el script de compilación de Gradle. Vale la pena señalar en esta etapa que el orden de declaración Determina cómo Gradle comprobará las dependencias en tiempo de ejecución.

«Cuando movimos el repositorio de JitPack por encima de mavenCentral, se descargó la versión 1.0 de JitPack», dijeron los investigadores. «Cambiar la versión de la biblioteca a 1.1 resultó en el uso de la versión JitPack independientemente de la posición de JitPack en la lista de repositorios».

Como resultado, un adversario que busque corromper la cadena de suministro de software puede atacar las versiones existentes de una biblioteca publicando una versión superior o contra nuevas versiones promocionando una versión inferior a la de su contraparte legítima.

Esta es otra forma de ataque de confusión de dependencias en la que un atacante publica un paquete no autorizado en un repositorio de paquetes público con el mismo nombre que un paquete dentro del repositorio privado previsto.

La seguridad cibernética

«La mayoría de las aplicaciones no verifican la firma digital de las dependencias y muchas bibliotecas ni siquiera la publican», agregaron los investigadores. «Si el atacante quiere pasar desapercibido el mayor tiempo posible, tiene sentido lanzar una nueva versión de la biblioteca con el código malicioso incorporado y esperar a que el desarrollador la actualice».

Del total de 33.938 dominios analizados, se descubrió que 6.170 (18,18%) eran vulnerables a MavenGate, lo que permitía a los actores de amenazas secuestrar las dependencias e inyectar su propio código.

Sonatype, propietaria de Maven Central, dicho La estrategia de ataque descrita «no es factible debido a la automatización existente», pero señaló que ha «deshabilitado todas las cuentas asociadas con dominios caducados y proyectos de GitHub» como medida de seguridad.

Dijo además que abordó una «regresión en el proceso de validación de clave pública» que hizo posible cargar artefactos al repositorio con una clave no compartida públicamente. También ha anunciado planes para colaborar con SigStore para firmar digitalmente los componentes.

«El desarrollador final es responsable de la seguridad no sólo de las dependencias directas, sino también de las transitivas», dijo Oversecured.

«Los desarrolladores de bibliotecas deben ser responsables de las dependencias que declaran y también escribir hashes de clave pública para sus dependencias, mientras que el desarrollador final debe ser responsable sólo de sus dependencias directas».

¿Encontró interesante este artículo? Siga con nosotros Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.





ttn-es-57