Arch Linux desactiva la adopción de paquetes en el AUR tras una oleada de más de 200 secuestros maliciosos
El repositorio comunitario más popular del mundo Linux ha tenido que echar el freno de mano. El proyecto Arch Linux ha desactivado temporalmente la adopción de paquetes en el AUR (Arch User Repository) después de detectar una avalancha de tomas de control maliciosas: atacantes que reclamaban paquetes huérfanos —abandonados por sus mantenedores originales— para colar en ellos un troyano de acceso remoto que se comunica por la red Tor. Es el segundo golpe serio al AUR en apenas dos meses y vuelve a poner sobre la mesa una pregunta incómoda: ¿hasta qué punto podemos fiarnos del software que instalamos con un simple comando?
El aviso lo publicó el colaborador Robin Candau en la lista de correo aur-general: «Debido a la actual avalancha de adopciones maliciosas de paquetes y de los commits posteriores realizados a través del AUR, la adopción de paquetes está desactivada mientras gestionamos la situación». La medida es provisional, pero sin fecha de vuelta. Mientras tanto, el equipo pide a la comunidad que reporte cualquier adopción o commit sospechoso que siga sin revisar.
Qué es el AUR y por qué es un objetivo tan goloso
El AUR no es un repositorio oficial de paquetes compilados, sino una colección de recetas de construcción (los archivos PKGBUILD) que la propia comunidad sube y mantiene. Cuando un usuario instala algo desde el AUR con un asistente como yay o paru, lo que hace en realidad es descargar ese script y ejecutarlo en su máquina para compilar el programa. Ahí está el problema: un PKGBUILD es código que se ejecuta con los permisos del usuario, y en muchos casos con privilegios de instalación. No hay una revisión editorial previa como en los repositorios oficiales de la distribución.
Cuando un mantenedor abandona un paquete, este queda marcado como «huérfano» y cualquier cuenta registrada puede adoptarlo. Los atacantes crearon cuentas nuevas, se apropiaron de esos paquetes sin dueño y empezaron a publicar actualizaciones envenenadas. Según el seguimiento hecho por la comunidad, la campaña habría alcanzado ya más de 200 paquetes, algunos con bastante tirón: se mencionan nombres como openconnect-sso, boringssl-git, icloudpd, windscribe-cli-v2-bin, stirling-pdf-desktop-bin o pgadmin4-server. El listado completo no se ha publicado ni verificado de forma independiente, así que conviene tomarlo como indicio, no como confirmación.
Un troyano en dos fases que evita los laboratorios
El análisis técnico, difundido por investigadores independientes y recogido por medios como BleepingComputer, Phoronix y LWN, describe una infección en dos etapas bastante cuidada. La primera es un cargador que, antes de hacer nada, comprueba si está siendo observado: busca depuradores, entornos aislados (sandbox), máquinas virtuales e incluso sistemas de integración continua. Si detecta que está en un laboratorio de análisis, se calla. Si no, instala servicios de systemd y tareas de cron para sobrevivir a los reinicios y lanza un cliente Tor camuflado bajo el nombre de dbus-daemon para descargar la segunda fase desde un servidor .onion.
La segunda etapa es un ladrón de información escrito en Rust, y su lista de la compra es demoledora: credenciales guardadas en el navegador, monederos de criptomonedas, bases de datos de gestores de contraseñas, secretos de desarrollo y de servicios en la nube, claves de API de servicios de inteligencia artificial, claves SSH y tokens de aplicaciones de mensajería. Además abre un canal cifrado por Tor para que el atacante ejecute órdenes a distancia y —lo más preocupante para entornos profesionales— utiliza las claves SSH robadas para copiarse y ejecutarse en otras máquinas de la misma red. Es decir, se comporta como un gusano dentro de la infraestructura de la víctima.
El eslabón débil ya no es el sistema operativo
Este incidente no es un fallo de Arch Linux ni de Linux en general: es un ataque a la cadena de suministro del software, el mismo patrón que hemos visto una y otra vez en npm, PyPI, extensiones de navegador o repositorios de GitHub que se hacen pasar por proyectos legítimos. El atacante ya no busca una vulnerabilidad en el kernel; busca un paquete abandonado con cientos de usuarios que actualizan sin mirar. En junio, otra campaña había comprometido más de 400 paquetes del AUR para distribuir un rootkit y un infostealer.
Para quien use Arch o derivadas, las recomendaciones son de sentido común pero incómodas de cumplir: leer el PKGBUILD antes de instalar o actualizar —los asistentes lo muestran y casi nadie lo lee—, desconfiar de paquetes que hayan cambiado de mantenedor recientemente, revisar el historial de commits y, si se sospecha de una infección, rotar de inmediato claves SSH, tokens y contraseñas guardadas. Y para las empresas, una lección más amplia: cualquier repositorio comunitario que entre en un equipo de desarrollo debería pasar por el mismo filtro que un proveedor externo. La comodidad de instalar cualquier cosa con un comando tiene una factura, y esta vez la ha pagado la confianza.
