Oleada de malware en AUR obliga a Arch Linux a deshabilitar todos los envíos de paquetes

Why it matters

AUR recipes execute on developer machines that often hold source-control keys and cloud credentials. Attackers are turning trusted package ownership transfers into a distribution channel.

Arch Linux ha deshabilitado todos los pushes al Arch User Repository, impidiendo que los mantenedores actualicen sus recetas de paquetes comunitarios mientras el proyecto, gestionado por voluntarios, elimina commits maliciosos. El cierre se amplificó el domingo por International Cyber Digest, después de que el colaborador de DevOps de Arch Linux, Robin Candau confirmó la congelación en la lista de correo AUR del proyecto.

"Hemos deshabilitado los pushes por completo por el momento, mientras manejamos la situación", escribió Candau el 1 de agosto.

La medida bloquea nuevos commits en todo el AUR, incluidas actualizaciones legítimas de paquetes. Las recetas de paquetes existentes aún pueden leerse y descargarse, pero los mantenedores no pueden publicar correcciones o nuevas versiones mediante el flujo de trabajo normal de Git. La congelación no afecta a los paquetes distribuidos a través de los repositorios oficiales de Arch Linux.

Candau, un ingeniero de sistemas Linux y DevOps que se unió al equipo de Arch en 2023, ya había deshabilitado la adopción de paquetes el 30 de julio. Citó un influjo de adopciones maliciosas y commits de seguimiento, y pidió a los usuarios que reportaran actividad sospechosa. Menos de dos días después, la respuesta se escaló hasta convertirse en una congelación de escritura en todo el repositorio.

Un segundo fallo de contención

Arch Linux ha estado combatiendo actividad maliciosa en el AUR desde junio. En un aviso de incidente del 12 de junio, el mantenedor de paquetes Campbell Jones dijo que el proyecto estaba viendo un alto volumen de adopciones y actualizaciones de paquetes maliciosos. El proyecto advirtió que la creación de cuentas, las actualizaciones de paquetes, la adopción y la creación de nuevos paquetes podrían verse interrumpidas mientras los mantenedores rastreaban commits dañinos.

Posteriormente el proyecto deshabilitó los nuevos registros en el AUR. El 13 de julio, el colaborador de DevOps Leonidas Spyropoulos reabrió el registro con bloqueo de correos desechables, verificación de correo obligatoria y un periodo de enfriamiento para cambios de email.

Esos controles de cuenta no eliminaron la debilidad mayor que los atacantes estaban explotando: los paquetes huérfanos del AUR pueden conservar sus nombres y la confianza acumulada después de que una receta abandonada pase a otras manos.

Sonatype llamó a la campaña de junio "Atomic Arch". Sus investigadores dijeron que los atacantes adoptaron paquetes huérfanos y alteraron sus instrucciones PKGBUILD para instalar dependencias npm maliciosas, incluyendo atomic-lockfile, js-digest y lockfile-js. Sonatype estimó que alrededor de 1,500 paquetes podrían haberse visto afectados a lo largo de varias olas, aunque advirtió que su análisis y el recuento de paquetes eran preliminares.

La carga útil que examinó Sonatype contenía funcionalidades asociadas con recolección de credenciales, anti-depuración, ocultamiento de procesos y archivos, y posible exfiltración de datos. Los investigadores encontraron referencias a credenciales de GitHub, artefactos SSH, tokens de HashiCorp Vault, cookies de navegador y datos de servicios de comunicación laboral. Sonatype aconsejó tratar las máquinas que ejecutaron la carga útil como comprometidas, ya que eliminar solo el paquete del AUR podría dejar el malware de segunda etapa en su lugar.

Los informes de la última ola describen un método de entrega distinto. A finales de julio, usuarios del AUR marcaron paquetes que contenían pequeños ejecutables ELF, a veces llamados validator, assembler, optimizer o converter. Miembros de la comunidad reportaron cambios sospechosos en paquetes que incluían openconnect-sso, git-pkgs y nnn-nerd. Los mantenedores de Arch revirtieron commits y suspendieron cuentas a medida que llegaban los reportes. La evidencia pública no establece si la actividad de finales de julio provino de los operadores detrás de Atomic Arch.

El traspaso de confianza del AUR es el punto débil

El AUR aloja recetas de compilación enviadas por usuarios para software fuera de los repositorios oficiales de Arch Linux. Esas recetas no se someten al mismo escrutinio que los paquetes oficiales, y sus scripts se ejecutan durante el proceso de compilación o instalación. Una instrucción maliciosa puede, por tanto, llegar a una estación de trabajo de un desarrollador incluso cuando el software upstream en sí no esté comprometido.

Los paquetes huérfanos dan a los atacantes una ruta eficiente hacia ese flujo de trabajo. Un atacante puede adoptar un paquete familiar, conservar su nombre reconocible e historial, y luego cambiar las instrucciones que usan los usuarios existentes durante su próxima actualización. El paquete ya ha superado el obstáculo de distribución más difícil: convencer a la gente de confiar en él e instalarlo.

Arch Linux sigue instando a los usuarios a inspeccionar cada PKGBUILD y cambio en scripts de instalación antes de actualizar software del AUR. La congelación de todos los pushes muestra los límites de depender de la revisión manual una vez que atacantes automatizados pueden generar cuentas, escanear paquetes abandonados y publicar cambios maliciosos más rápido de lo que un equipo de moderación voluntario puede revertirlos.

Para los equipos de ingeniería que ejecutan Arch Linux o una distribución derivada de Arch en máquinas de desarrollador, la exposición inmediata se extiende más allá del software de escritorio. Los sistemas de desarrollo comúnmente almacenan credenciales de control de código fuente, claves SSH, tokens de la nube y sesiones de navegador. Un script de compilación comunitario comprometido puede poner esos activos al alcance antes de que una herramienta de endpoint reconozca el nombre del paquete como malicioso.