La traición de la AUR: cómo un ataque a la cadena de suministro convirtió paquetes huérfanos en robo de credenciales y persistencia oculta

La última oleada contra el Arch User Repository (AUR) obliga a replantear cómo confiamos en paquetes comunitarios: atacantes tomaron control de centenares de paquetes "huérfanos", modificaron únicamente sus instrucciones de construcción (PKGBUILD/.install) y lograron que máquinas de desarrollo ejecutaran un binario en Rust diseñado para robar credenciales. La pieza clave del ataque no fue un fallo en Arch ni un zero-day, sino la explotación del modelo de confianza de la AUR: nombre e historial intactos, mantenedor cambiado.

Qué pasó en términos técnicos: los adversarios adoptaron paquetes abandonados, insertaron llamadas como npm install atomic-lockfile o bun install js-digest durante la compilación y así arrastraron un paquete npm malicioso que ejecuta un ELF llamado deps en el proceso de build. Ese binario recoge tokens de navegadores y apps Electron, claves SSH, credenciales de contenedores, datos de Vault y hasta material de OpenAI/ChatGPT, y exfiltra a servicios públicos (temp.sh). Si corre con privilegios root, puede instalar un servicio persistente y opcionalmente cargar un módulo eBPF que oculta procesos, nombres y sockets; la rootkit-eBPF es accesorio pero eleva la gravedad porque complica la limpieza. Para análisis técnicos y conjuntos de indicadores vea el informe comunitario y el análisis forense de la muestra: Sonatype — Atomic Arch y ioctl.fail — análisis y señales.

Implicaciones prácticas: si construiste o actualizaste cualquier paquete desde la AUR desde el 11 de junio, no basta con confiar en que borrar el paquete del gestor deja el sistema limpio. Una vez que el payload se ejecuta con privilegios suficientes, el atacante puede dejar persistencia, robar secretos y, en el peor caso, ocultar su presencia con eBPF. Las cifras iniciales de paquetes comprometidos llegaron a cientos y siguen fluctuando: la vía de exposición no era la descarga directa del paquete npm (atomic-lockfile tenía muy pocas descargas semanales), sino el canal de build en la AUR.

Qué comprobar inmediatamente en un equipo sospechoso: revise los logs y caches de makepkg/build (busque trazas de npm install atomic-lockfile, bun install js-digest o rutas como src/hooks/deps), inspeccione unidades systemd tanto a nivel de sistema como de usuario en busca de servicios desconocidos, explore /var/lib/ por artefactos y /sys/fs/bpf/ por mapas nombrados como hidden_pids, hidden_names o hidden_inodes. Monitorice conexiones salientes inusuales, especialmente hacia nodos Tor o servicios de subida, y compare binarios sospechosos con los hashes publicados por los investigadores. Si el binario corrió con root, lo prudente es asumir compromiso de la máquina y reinstalar desde medios de confianza. La AUR y los repos oficiales de Arch son distintos; los repos oficiales no se vieron afectados, pero eso no limpia un sistema local comprometido.

Acciones de contención y recuperación: si una compilación ejecutó alguno de los payloads, rote inmediatamente cualquier secreto que el malware pudiera haber leído: sesiones y cookies de navegadores, tokens de GitHub y npm, claves SSH, credenciales de Vault, credenciales de Docker/Podman, perfiles VPN y claves cloud. Revoque y regenere claves y tokens desde otra máquina conocida limpia. Busque y elimine servicios systemd desconocidos y archivos en ubicaciones persistentes; sin embargo, recuerde que un rootkit con capacidad para ocultarse podría impedir una detección fiable. Por eso, cuando hay indicio de ejecución con privilegios, la única forma segura de recuperar la confianza es reinstalar el sistema desde medios verificados y restaurar datos desde backups previos y examinados.

Prevención a medio y largo plazo: trate los paquetes adoptados recientemente o que hayan permanecido dormidos como potencialmente riesgosos. No construya AUR a ciegas: lea el PKGBUILD y los hooks .install antes de ejecutar makepkg, y si no comprende los pasos de build absténgase. Valore construir paquetes en entornos aislados: máquinas virtuales efímeras, contenedores o chroots sin acceso a credenciales sensibles. Para proyectos mantenidos por la comunidad, observe el historial de mantenimiento y las señales de adopción reciente; los atacantes explotan precisamente esa ventana de confianza. Recursos oficiales y guías sobre seguridad en AUR pueden consultarse en la documentación de Arch: AUR y la Wiki de Arch sobre políticas y seguridad de paquetes.

Por último, la lección es estructural: las cadenas de suministro que delegan confianza en nombres e historia sin validar la identidad y la intención del mantenedor son frágiles. Los equipos deben incorporar controles que reduzcan el blast radius de builds no confiables: separación de roles, entornos de compilación dedicados, revisión humana de scripts de build y rotación frecuente de secretos. Para indicadores técnicos, hashes y la lista consolidada de paquetes afectados siga las investigaciones públicas (el análisis y el conjunto de IOCs se encuentran recopilados por la comunidad y por investigadores como los enlazados arriba).