Arch Linux AUR: cómo un ataque masivo de paquetes comprometidos robó credenciales y ocultó un rootkit
Por Mag-Info Tech editorial · 2026-06-13
El modelo de confianza en el software de código abierto depende, en gran medida, de que los paquetes mantengan su integridad y autenticidad. Sin embargo, un reciente ataque a gran escala en el Arch User Repository (AUR) de Arch Linux ha demostrado que los atacantes pueden subvertir ese modelo sin explotar vulnerabilidades técnicas en el sistema operativo o en los paquetes en sí. En lugar de eso, aprovecharon la confianza que los usuarios depositan en los nombres de los paquetes y en sus históricos de mantenimiento. Más de 400 paquetes en el AUR fueron comprometidos, sus scripts de compilación alterados para instalar malware en cualquier máquina que los compilara. El ataque no solo robó credenciales de desarrolladores, sino que también desplegó un rootkit basado en eBPF capaz de ocultarse en el sistema. A continuación, analizamos cómo ocurrió, qué paquetes están afectados y qué medidas puedes tomar para protegerte.
¿Qué es el Arch User Repository y por qué es un objetivo atractivo?
El Arch User Repository (AUR) es un repositorio comunitario de Arch Linux donde los usuarios pueden compartir paquetes no incluidos en los repositorios oficiales. Estos paquetes, conocidos como PKGBUILD, permiten a los usuarios compilar e instalar software desde el código fuente. Dado que el AUR no está sujeto a las mismas revisiones estrictas que los repositorios oficiales, se convierte en un objetivo atractivo para los atacantes. Los paquetes en el AUR suelen ser mantenidos por voluntarios, algunos de los cuales pueden abandonar sus proyectos con el tiempo, dejando paquetes "huérfanos" que cualquiera puede adoptar. Esta dinámica fue aprovechada por los atacantes para infiltrarse en el ecosistema.
La confianza en el AUR se basa en la reputación de los paquetes y sus mantenedores. Los usuarios suelen instalar paquetes del AUR sin verificar exhaustivamente su origen, especialmente si el paquete tiene un historial de uso prolongado y comentarios positivos. Los atacantes explotaron esta confianza al adoptar paquetes huérfanos, editando sus scripts de compilación para incluir código malicioso. El ataque no requirió vulnerabilidades en Arch Linux o en los paquetes en sí, sino que se centró en manipular la cadena de suministro del software. Esto subraya un riesgo inherente en los repositorios comunitarios: la confianza en los mantenedores puede ser explotada si no se implementan controles adecuados.
Además, el AUR permite a los usuarios compilar e instalar paquetes directamente desde el código fuente, lo que significa que cualquier script malicioso incluido en el PKGBUILD se ejecutará con los permisos del usuario que realiza la compilación. Si el usuario tiene permisos de administrador, el malware puede obtener acceso root y realizar cambios profundos en el sistema. Este enfoque de ataque, conocido como "compromiso de la cadena de suministro de compilación", es particularmente peligroso porque el malware se ejecuta durante el proceso de instalación, cuando los usuarios confían en que el software es seguro.
El ataque: cómo los atacantes secuestraron más de 400 paquetes
Los atacantes adoptaron paquetes huérfanos en el AUR, es decir, paquetes que habían sido abandonados por sus mantenedores originales. Al adoptarlos, editaron los scripts de compilación (PKGBUILD o .install) para incluir una línea que ejecutaba npm install atomic-lockfile@1.4.2 durante el proceso de compilación. Este paquete de npm, aparentemente legítimo, contenía un gancho de preinstalación que descargaba y ejecutaba un binario ELF llamado deps. Una vez ejecutado, el binario desplegaba un ladrón de credenciales escrito en Rust y un rootkit basado en eBPF.
El ladrón de credenciales estaba diseñado para recopilar información sensible de los sistemas infectados, incluyendo archivos específicos y credenciales almacenadas en el sistema. Los datos robados se enviaban a un servidor remoto a través de HTTP, utilizando el servicio temporal temp.sh como punto de exfiltración. El comando y control (C2) se gestionaba a través de un servicio onion de Tor, accesible mediante un proxy local en el sistema infectado. Esto dificultaba la detección y el bloqueo del tráfico malicioso, ya que el tráfico de red se ocultaba tras la red Tor.
Para garantizar la persistencia en el sistema, el malware instalaba un servicio de systemd con la opción Restart=always. Si el malware se ejecutaba con permisos de root, se copiaba a sí mismo en el directorio /var/lib/ y creaba un archivo de unidad en /etc/systemd/system/. Si, en cambio, se ejecutaba con permisos de usuario normal, se instalaba en el directorio home del usuario, bajo ~/.config/systemd/user/. Esta dualidad permitía al malware mantenerse activo incluso después de reinicios del sistema, independientemente de los permisos con los que se hubiera ejecutado inicialmente.
El malware: un ladrón de credenciales y un rootkit eBPF
El binario deps, escrito en Rust, funcionaba como un ladrón de credenciales con capacidades avanzadas. Su objetivo principal era recopilar información sensible de los sistemas infectados, incluyendo archivos específicos y credenciales almacenadas en navegadores, gestores de contraseñas y otros lugares comunes. Los atacantes utilizaron técnicas de ofuscación para dificultar el análisis estático del binario, lo que retrasó su detección inicial. Una vez recopilados los datos, estos se enviaban a un servidor remoto a través de HTTP, utilizando el servicio temp.sh como punto intermedio para la exfiltración.
Además del ladrón de credenciales, el malware incluía un rootkit basado en eBPF. eBPF (Extended Berkeley Packet Filter) es una tecnología del kernel de Linux que permite ejecutar código en el espacio del kernel de manera segura y eficiente. Los atacantes aprovecharon esta tecnología para ocultar el malware y sus actividades en el sistema. El rootkit podía interceptar y modificar llamadas al sistema, ocultar procesos, archivos y conexiones de red, lo que hacía que el malware fuera extremadamente difícil de detectar con herramientas convencionales. Esto representaba un desafío significativo para los administradores de sistemas y los equipos de seguridad, ya que el malware podía operar de manera encubierta durante largos períodos.
El uso de eBPF para implementar rootkits es una técnica relativamente nueva y sofisticada. Aunque eBPF fue diseñado originalmente para tareas de monitoreo y diagnóstico, su capacidad para ejecutar código en el espacio del kernel lo convierte en una herramienta poderosa para los atacantes. El rootkit podía ocultar el malware incluso de herramientas como ps, ls y netstat, lo que dificultaba su detección. Esto subraya la importancia de implementar controles de seguridad adicionales, como el monitoreo de comportamiento anómalo y el uso de herramientas de detección basadas en eBPF para identificar actividades sospechosas en el kernel.
¿Qué paquetes están afectados y cómo identificarlos?
La lista de paquetes afectados en el AUR sigue creciendo y no está completa en el momento de redactar este artículo. Los atacantes adoptaron paquetes huérfanos y editaron sus scripts de compilación para incluir el código malicioso. Algunos de los paquetes confirmados como afectados incluyen alvr y premake-git, pero es probable que la lista sea mucho más extensa. Los usuarios que hayan instalado o actualizado paquetes del AUR a partir del 11 de junio deben verificar si alguno de los paquetes que tienen instalados está en la lista de afectados.
Para identificar si un paquete está comprometido, los usuarios pueden revisar el historial de cambios en el PKGBUILD del paquete. Los atacantes modificaron los scripts de compilación para incluir la línea npm install atomic-lockfile@1.4.2, por lo que buscar esta línea en el PKGBUILD puede ser un indicio de compromiso. Además, se recomienda revisar los comentarios y las notificaciones en el repositorio del AUR, donde otros usuarios pueden haber reportado problemas con paquetes específicos. También es útil verificar la fecha de los últimos cambios en el PKGBUILD, ya que los atacantes suelen realizar modificaciones recientes para incluir el código malicioso.
Resultados reales de la IA de MEFAI. Obtén $50 de descuento en el plan Pro.
Patrocinado · El rendimiento pasado no indica resultados futuros. No es asesoramiento financiero.
Otra medida importante es revisar los servicios de systemd que se ejecutan en el sistema. El malware instala un servicio con Restart=always, por lo que buscar servicios con nombres sospechosos o fechas de creación recientes puede ayudar a identificar sistemas infectados. Los usuarios también pueden utilizar herramientas como journalctl para revisar los logs del sistema en busca de actividades sospechosas, como la ejecución de binarios no reconocidos o la creación de archivos en directorios inusuales.
¿Por qué este ataque es especialmente peligroso?
Este ataque es especialmente peligroso por varias razones. En primer lugar, explotó la confianza en el modelo de software de código abierto, donde los usuarios confían en los nombres de los paquetes y en sus históricos de mantenimiento. Los atacantes no necesitaron explotar una vulnerabilidad en Arch Linux o en los paquetes en sí, sino que aprovecharon la cadena de suministro del software para distribuir el malware. Esto hace que el ataque sea difícil de detectar y prevenir, ya que no hay una vulnerabilidad específica que parchear.
En segundo lugar, el malware incluía un rootkit basado en eBPF, una técnica avanzada que permite ocultar las actividades del malware incluso de herramientas convencionales de detección. Esto representa un desafío significativo para los administradores de sistemas y los equipos de seguridad, ya que el malware puede operar de manera encubierta durante largos períodos. La detección de rootkits basados en eBPF requiere herramientas especializadas y un monitoreo constante del comportamiento del sistema.
Además, el ataque se centró en desarrolladores y sistemas de compilación, lo que significa que las credenciales robadas podrían ser utilizadas para acceder a otros sistemas y cuentas. Los atacantes podrían utilizar las credenciales para comprometer cuentas de correo electrónico, servicios en la nube, repositorios de código y otros recursos críticos. Esto subraya la importancia de implementar medidas de seguridad adicionales, como la autenticación multifactor y el monitoreo de actividades sospechosas en las cuentas.
¿Qué pasos deben seguir los usuarios afectados?
Si sospechas que tu sistema puede estar infectado, hay varios pasos que puedes seguir para mitigar el riesgo. En primer lugar, revisa la lista de paquetes afectados publicada por la comunidad de Arch Linux y elimina cualquier paquete que esté en la lista. Utiliza el comando pacman -Rns <nombre-del-paquete> para desinstalar el paquete y sus dependencias. Después de desinstalar los paquetes comprometidos, reinicia el sistema para asegurarte de que el malware no se haya reactivado.
A continuación, revisa los servicios de systemd que se ejecutan en tu sistema. Busca servicios con nombres sospechosos o fechas de creación recientes y elimínalos con el comando sudo systemctl disable <nombre-del-servicio> y sudo systemctl stop <nombre-del-servicio>. También es recomendable revisar los logs del sistema con journalctl en busca de actividades sospechosas, como la ejecución de binarios no reconocidos o la creación de archivos en directorios inusuales.
Finalmente, cambia todas las credenciales que puedan haber sido comprometidas, incluyendo contraseñas de cuentas de correo electrónico, servicios en la nube, repositorios de código y otros recursos críticos. Implementa la autenticación multifactor en todas las cuentas posibles y monitorea las actividades sospechosas en tus cuentas. También es recomendable realizar una revisión exhaustiva de los permisos y accesos en tus sistemas para identificar posibles brechas de seguridad.
¿Qué medidas puede tomar la comunidad de Arch Linux para prevenir futuros ataques?
La comunidad de Arch Linux y los mantenedores del AUR pueden implementar varias medidas para prevenir futuros ataques similares. En primer lugar, es crucial implementar un proceso de revisión más estricto para los paquetes huérfanos. Esto podría incluir la asignación de mantenedores temporales o la eliminación de paquetes que no han sido actualizados durante un período prolongado. Además, se podría implementar un sistema de notificaciones automáticas para los usuarios que instalen paquetes huérfanos, advirtiéndoles sobre los riesgos potenciales.
Otra medida importante es la implementación de firmas digitales para los paquetes del AUR. Esto permitiría a los usuarios verificar la autenticidad de los paquetes antes de instalarlos, reduciendo el riesgo de instalar software malicioso. Además, se podría implementar un sistema de revisión por pares para los cambios en los PKGBUILD, similar al proceso utilizado en los repositorios oficiales de Arch Linux. Esto ayudaría a detectar cambios sospechosos en los scripts de compilación antes de que sean distribuidos a los usuarios.
Finalmente, es importante educar a la comunidad sobre los riesgos asociados con los paquetes huérfanos y cómo identificar paquetes comprometidos. Esto podría incluir la publicación de guías de seguridad y la organización de talleres para enseñar a los usuarios a revisar los PKGBUILD y otros archivos de configuración antes de instalar paquetes del AUR. La educación y la concienciación son clave para prevenir futuros ataques y garantizar la seguridad del ecosistema de Arch Linux.
Conclusión
El ataque a más de 400 paquetes en el AUR de Arch Linux representa un recordatorio de los riesgos inherentes en los repositorios comunitarios de software. Los atacantes aprovecharon la confianza en los nombres de los paquetes y en sus históricos de mantenimiento para distribuir malware sin explotar vulnerabilidades técnicas. El uso de un ladrón de credenciales y un rootkit basado en eBPF hizo que el ataque fuera especialmente peligroso, ya que el malware podía operar de manera encubierta y robar credenciales sensibles.
Para los usuarios, es crucial revisar los paquetes instalados en el AUR y tomar medidas inmediatas si se detecta un compromiso. Para la comunidad de Arch Linux, este ataque subraya la necesidad de implementar controles de seguridad más estrictos, como la revisión de paquetes huérfanos, la implementación de firmas digitales y la educación de los usuarios sobre los riesgos asociados con los paquetes del AUR. La seguridad del software de código abierto depende de la colaboración y la vigilancia constante de toda la comunidad.
Más en Ciberseguridad y Privacidad
El fraude en portales de notificación de brechas de datos expone riesgos en la transparencia pública
El portal de notificación de brechas de datos de Maine fue desactivado temporalmente tras la publicación de falsas alertas que afectaron a Discord y VRChat, revelando fallos en los sistemas de verific
La vulnerabilidad crítica en PeopleSoft expone a cientos de organizaciones y activa extorsiones masivas
Una falla crítica en PeopleSoft permite a atacantes robar gigabytes de datos y extorsionar a víctimas. Oracle emitió mitigación temporal mientras ShinyHunters ya lleva semanas explotándola.
Pérdida de un disco con datos de 10,9 millones de clientes en una eléctrica japonesa: qué pasó y qué significa
Una eléctrica japonesa perdió un disco duro con datos de 10,9 millones de clientes tras un fallo en seguridad física. Sin datos bancarios, la compañía investiga el incidente y refuerza protocolos.