Paquetes falsos de AUR ejecutan malware como root en Arch
Un actor malicioso ha subido al Arch User Repository (AUR) paquetes maliciosos que se hacían pasar por yay y paru, dos herramientas auxiliares muy utilizadas. Al instalarse, los paquetes ejecutaban un script de shell remoto con privilegios de root.
Los paquetes se detectaron el 13 de octubre. Los publicó un usuario llamado "marchos1as" con nombres de typosquatting muy parecidos a los de las herramientas legítimas.
Qué es el AUR y por qué importan los helpers
El AUR es un índice de paquetes mantenido por la comunidad para Arch Linux y las distribuciones basadas en ella. No aloja binarios ya compilados. Lo que aloja son scripts de compilación, conocidos como PKGBUILD, que los propios usuarios ejecutan para compilar e instalar el software. Estos scripts abarcan herramientas de terceros y propietarias, versiones beta y versiones antiguas que ya no están disponibles a través de los canales oficiales de la distribución.
Herramientas como yay y paru se conocen como helpers de AUR. Facilitan la búsqueda e instalación de paquetes aportados por los usuarios, así que muchos usuarios de Arch los instalan pronto, a menudo como una de las primeras cosas que añaden a un sistema nuevo. Eso los convertía en un disfraz atractivo para los atacantes.
Código legítimo con un script de instalación malicioso
Los usuarios recibieron el aviso a través de un hilo de la lista de correo de Arch Linux titulado "hundreds of aur packages were mass uploaded with malware" ("se subieron de forma masiva cientos de paquetes de AUR con malware"). En cuestión de minutos, miembros de la comunidad habían revisado los paquetes y confirmado lo que contenían.
Los paquetes incluían el código original del proyecto, pero le añadían un script de instalación malicioso. Ese script descargaba y ejecutaba un script de shell remoto con privilegios de root.
El mantenedor de AUR Andreas Reichel describió uno de los paquetes en detalle.
"El paquete se presenta como un simple reempaquetado del helper de AUR legítimo 'yay' (la misma URL de origen, el mismo tarball de código fuente), pero el nombre del paquete, 'yyay', y el scriptlet de instalación malicioso revelan que se trata de una suplantación troyanizada diseñada para pasar desapercibida junto al paquete real", advirtió Reichel.
Como la URL de origen y el tarball coincidían con los del proyecto real, un vistazo rápido al script de compilación no habría revelado nada raro. La parte maliciosa estaba en el scriptlet de instalación, que se ejecuta durante la instalación del paquete.
Otro mantenedor, Emiliano Gandini Outeda, publicó una lista de paquetes maliciosos que habían hecho saltar las alertas en su propio sistema. Las detecciones procedían de reglas de TrustSight, una herramienta de código abierto de seguridad de aplicaciones que él mismo desarrolla.
El equipo de AUR bloqueó la cuenta marchos1as y retiró los paquetes maliciosos del repositorio.
Una carga útil que pasaba por la Wayback Machine
Según Reichel, la carga útil no se descargaba directamente de un servidor del atacante. En su lugar, el script de instalación la obtenía a través de una URL de la Wayback Machine. Esa URL apuntaba a un repositorio personal llamado hellscripter/install-scripts, alojado en GitFlic, un servicio ruso de alojamiento de código.
Usar un servicio de archivo como paso intermedio permite a los atacantes hacer pasar el tráfico por un dominio de confianza, lo que puede ayudar a que la descarga parezca menos sospechosa.
Un posible vínculo con un gusano de npm
El nombre del repositorio ya había aparecido antes. La empresa de seguridad de aplicaciones SafeDep documentó hace poco una campaña en npm a la que llamó "DirtyBlanket". Esa campaña obtenía código de un repositorio con el mismo nombre, hellscripter/install-scripts, pero alojado en Codeberg.
Los investigadores de SafeDep encontraron un gusano para Linux en esa actividad. Desplegaba el troyano de acceso remoto CHAOS camuflado como un servicio de fuentes y, además, inyectaba un cargador en paquetes de AUR.
Un aviso de OSV sobre DirtyBlanket recoge también el mismo dominio de la Wayback Machine y de GitFlic que se ha visto en las últimas subidas a AUR.
Estas coincidencias llaman la atención, pero por ahora no hay confirmación de que ambas operaciones estén relacionadas.
Parte de una serie de ataques contra AUR
No es la primera vez este año que el AUR está en el punto de mira. En junio, 400 paquetes distribuyeron malware de robo de credenciales con capacidades de rootkit. Otra campaña en julio llevó al equipo de Arch a desactivar temporalmente la adopción de paquetes, el proceso que permite a los usuarios hacerse cargo de paquetes huérfanos.
Los usuarios de Arch que hayan instalado alguno de los paquetes sospechosos deben dar por hecho que su sistema está comprometido y tomar medidas de inmediato. Como el script malicioso se ejecutaba como root, el atacante podría haber modificado cualquier cosa en la máquina afectada.
Nuestra opinión
Es la tercera campaña contra AUR en unos cuatro meses, lo que indica que los atacantes ven ya el repositorio como una vía de entrada fiable a los sistemas Linux. El modelo que hace útil al AUR, con subidas abiertas y paquetes compilados por los usuarios, también deja la revisión en gran medida en manos de la comunidad. En este caso la comunidad reaccionó rápido, pero la detección siguió dependiendo de voluntarios que leen hilos de listas de correo y ejecutan sus propias herramientas.
La elección de los objetivos dice mucho. Los helpers de AUR se instalan pronto y gozan de una confianza generalizada, y combinar el código original del proyecto con un scriptlet de instalación oculto está pensado para superar una revisión superficial. El mismo patrón de esconder pasos maliciosos dentro de scripts de instalación aparece en campañas como la operación de malware MALFEX en npm y en repositorios maliciosos de GitHub creados para parecer legítimos.
Para los usuarios de Arch, la lección práctica es revisar con cuidado los nombres de los paquetes y leer los scripts de instalación, no solo las URL de origen. Habrá que estar atentos a si se confirma el presunto vínculo con DirtyBlanket y a si el equipo de Arch endurece los controles sobre las nuevas subidas tras esta última oleada.