Paquetes de AUR fueron comprometidos con un infostealer y un rootkit

 (discourse.ifin.network)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El repositorio de paquetes AUR tiene una estructura en la que cualquiera puede adoptar paquetes no mantenidos y enviar cambios a PKGBUILD y archivos relacionados; en este incidente hay indicios de que más de 408 paquetes fueron comprometidos
  • Un nuevo maintainer de paquetes en AUR se hizo pasar por un maintainer de confianza, adoptó paquetes y otros maintainers de AUR avanzan con la eliminación de los paquetes comprometidos
  • Los paquetes comprometidos inicialmente fueron modificados para ejecutar npm mediante un script de preinstalación e instalar la carga maliciosa atomic-lockfile
  • Más tarde, la infección instaló el malicioso js-digest con Bun, y NPM eliminó ese paquete
  • La mayoría de los paquetes se usan rara vez, pero lo importante es la amplitud del alcance y que se trata de un ataque a la cadena de suministro que, además del robo de información, incluso incluía un rootkit eBPF

Estado del incidente

  • Qué ocurrió

    • Hay indicios de que un nuevo maintainer de paquetes en AUR se hizo pasar por un maintainer de confianza, adoptó más de 408 paquetes y los comprometió
    • Tras reportarse la intrusión, otros maintainers de AUR comenzaron a retirar los paquetes comprometidos
    • Al momento de 2026-06-12T17:30:00Z, los maintainers de AUR informaron que habían eliminado todos los commits maliciosos
    • Los maintainers de AUR decidieron aplicar controles y restricciones a algunas funciones, incluida la adopción de paquetes
    • Arch Linux publicó el aviso Active AUR malicious packages incident

  • Dependencias maliciosas

    • El ataque incluyó al menos dos dependencias maliciosas distintas
    • Los paquetes afectados al inicio fueron modificados para usar npm en un script de preinstalación e instalar el paquete de carga maliciosa atomic-lockfile
    • El paquete premake-git tiene un commit de ejemplo de ese cambio
    • Más adelante, la infección usó Bun para instalar el malicioso js-digest, y NPM eliminó js-digest
    • El análisis del ataque tiene un desglose detallado en Preliminary analysis of AUR malware

Respuesta e indicadores de compromiso

  • Medidas recomendadas

    • Si no usas Arch, no eres un objetivo directamente afectado por esta intrusión en paquetes de AUR
    • Los usuarios de Arch deben revisar la lista de paquetes afectados e inspeccionar sus sistemas con el script para verificar exposición
    • El aur_check.sh enlazado en la fuente original es una versión antigua, y para la verificación más reciente se debe seguir la guía de ese Gist
    • Si se encuentran indicadores de compromiso, el sistema debe preservarse para una investigación forense adecuada
    • Si se detectan paquetes infectados, se deben seguir los procedimientos habituales de respuesta a incidentes, cambiar todas las credenciales y considerar reinstalar Arch
    • Debido a la posible presencia de un rootkit, ya no se puede garantizar la confiabilidad del sistema
    • Todos los usuarios deben tomar medidas para bloquear el tráfico saliente de Tor en la red

  • Indicadores de compromiso

    • El SHA256 del ejecutable malicioso para Linux incrustado en js-digest es 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
    • Se pueden detectar mapas eBPF sospechosos con bpftool map list
    • Entre los nombres de mapas sospechosos están hidden_pids, hidden_names, hidden_inodes

  • Verificaciones adicionales

    • No fue una cuenta existente de maintainer la que realizó los commits maliciosos, sino que se suplantó a una cuenta de maintainer conocida
    • La mayoría de los paquetes se usan rara vez, pero el alcance de la infección, con más de 408 paquetes, es grande
    • Un ataque a la cadena de suministro que, además del robo de información, incluya incluso un rootkit eBPF es un caso poco común
    • La página de Socket.dev de atomic-lockfile muestra 134 descargas del paquete malicioso de NPM
    • El paquete de NPM es mantenido por el usuario herbsobering
    • Al buscar el nombre de usuario herbsobering en GitHub aparece una única imagen de contenedor que parece ser una herramienta de reverse shell/proxy, herbsobering430
    • En el repositorio de paquetes AUR, si un paquete aparece como no mantenido, cualquiera puede adoptarlo y enviar cambios al PKGBUILD y a los archivos relacionados
    • Buscar y adoptar automáticamente paquetes abandonados no es algo inusual, y el contexto relacionado está en este hilo de Mastodon

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • Hay que aceptar que AUR no es más que una colección de PKGBUILD hechos por usuarios
    Siempre hay que revisar el código fuente de cualquier PKGBUILD que instales desde AUR, y las actualizaciones no son una excepción. Este ha sido el supuesto básico durante más de 10 años, y por eso no existe un helper oficial de AUR como yay
    Mucha gente se queja de que Arch Linux es elitista, pero en la práctica es una distribución para personas que saben lo que hacen y no quieren que las lleven de la mano en cada paso. Eso también significa que si instalas paquetes aleatorios de AUR y terminas rompiendo tu sistema o siendo comprometido, es tu responsabilidad
    Dicho eso, puede que la época de permitir que cualquiera adopte paquetes de AUR esté llegando a su fin. Tan solo el costo de revertir los paquetes afectados cada vez es demasiado alto. Como alternativa, revisar todas las solicitudes de adopción sería demasiado pesado y no hay garantía de que ayude en todos los casos

    • Si hay que revisar el código fuente de todos los PKGBUILD que se instalan desde AUR, entonces supongo que lo mismo aplica a las extensiones del navegador, extensiones de VSCode, paquetes de NuGet, crates de Cargo, paquetes de Python, paquetes de npm, etc.
      Yo diría que sí, salvo que se ejecuten en un lugar sin acceso a internet o que solo acceda a cosas públicas que no importe exponer
      Puede que AUR no, pero otros ecosistemas al menos podrían mejorar en teoría con modelos de permisos o sandboxing. Las extensiones del navegador ya tienen esa opción, pero casi ningún usuario “normal” la usa
      Por desgracia, el 99.99% de la gente no puede revisar todo ni tiene tiempo para hacerlo. Lo más seguro parece ser paquetes de distribuciones con maintainers de confianza, o algo como la App Store de iOS, con permisos y cierto nivel de revisión
    • No creo que esto sea una solución real. El patrón general de este tipo de ataques ha sido ocultar el payload en alguna parte de las dependencias
      Este caso es algo raro porque en el PKGBUILD hacen un npm install de una forma muy poco elaborada. Ahora casi todos los repositorios de paquetes fuera de AUR tienen el mismo problema, y auditar manualmente toda la cadena de dependencias no es realista
      Claro, yo tampoco tengo una solución
    • Creer que siquiera una pequeña parte de los usuarios realmente hace eso es una idea totalmente desconectada de la realidad
    • Me pregunto qué tan distinto es que AUR sea una colección de PKGBUILD hechos por usuarios frente a todo el ecosistema de PyPI, npm o Docker Hub
      La gente desactiva SELinux, --privileged desactiva seccomp y AppArmor, y además existen CVE de escape de sandbox
    • Nunca debió existir eso de que cualquiera pudiera adoptar un paquete de AUR
      Al final me gustaría que fuera algo como username/packagename-bin|git. Así quedaría mucho más claro qué está instalando la gente realmente y de quién lo está obteniendo

  • Esta campaña sigue en curso. Justo ahora recibí un correo avisando que uno de mis paquetes viejos fue adoptado; llevaba años sin funcionar y había sido un paquete huérfano por bastante tiempo. Justo después de la adopción apareció un commit malicioso
    Ahora parece que están usando bun en lugar de npm, así que es posible que los atajos basados en npm ya no sirvan
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

    • A estas alturas me pregunto si el concepto mismo de adoptar paquetes huérfanos ya está roto y si no habría que eliminarlo por completo
      Sería incómodo, pero quizá sería mejor que AUR obligara a hacer un nuevo envío en vez de permitir adoptar un paquete abandonado por otra persona, y que además eliminara periódicamente los paquetes huérfanos después de cierto tiempo
    • Yo también acabo de recibir una notificación de que uno de los paquetes de AUR que vigilaba pasó a manos de alguien desconocido solo porque era huérfano

  • Es obvio que hay que tener cuidado al instalar cosas desde AUR, y antes siempre hubo paquetes sospechosos —mal construidos o mal empaquetados—, pero ver una inserción maliciosa activa sí preocupa
    Creo que AUR tiene dos grandes problemas. Primero, que es un vestigio de una época un poco más igualitaria del software libre, cuando en general se podía confiar en código de terceros. Segundo, que cualquiera puede adoptar paquetes huérfanos conservando intacto el historial y los antecedentes de verificación existentes
    La primera época ya quedó atrás, y la segunda se puede mitigar con controles más estrictos sobre las cuentas de AUR o con protecciones adicionales del lado de los helpers de AUR. Por ejemplo, si un paquete cambió de dueño recientemente, mostrar una advertencia enorme y aterradora. Igual habrá gente que simplemente presione y y siga adelante, pero sigue siendo mejor que nada
    O también se puede evitar por completo el uso de helpers de AUR y revisar y compilar directamente el paquete necesario desde el PKGBUILD

    • La política de adopción de paquetes nunca tuvo sentido en ningún momento
    • Yo diría que los helpers de AUR más bien facilitan integrar el paso de revisión dentro del flujo de trabajo
      Te preguntan activamente si quieres revisarlo y, después de aceptar el riesgo final, también te avisan si hubo cambios
      De todos modos, la postura de que “AUR es dañino” no es nueva. Quien usa AUR debería entender los riesgos de ese entorno y, en la práctica, apenas está un paso por encima de hacer curl | bash con algo sacado de StackOverflow

  • Han pasado más de 7 horas desde que ocurrió esto y todavía no hay ninguna mención en archlinux.org ni en aur.archlinux.org. No entiendo por qué. Debieron haber bloqueado el AUR hasta tomar medidas que demostraran que los usuarios estaban enterados de esto
    Por ejemplo, podrían cambiar ligeramente la URL de la API del AUR para hacer que los usuarios de yay/yaourt investiguen qué pasó. La nueva API debería tener infraestructura para avisarle al usuario y verificar que leyó el mensaje antes de continuar. Esto es aún más necesario cuando ni siquiera está claro si ya encontraron todo el malware
    También debería existir una base de datos de commits del AUR revocados o comprometidos, y un mecanismo para advertir a los usuarios si alguna vez instalaron esos paquetes

    • Para bien o para mal, esa advertencia siempre ha existido en el AUR
      Está incluso en el nombre mismo, y en la documentación de la wiki se indica claramente que el AUR es un repositorio de usuarios y que no debe confiarse en él ciegamente
      Está escrito tal cual en la gran caja roja de arriba: https://wiki.archlinux.org/title/Arch_User_Repository
      Hay muchas cosas en el AUR que yo jamás instalaría, y no creo que lo mejor sea difundir todas por la lista de correo
      No me desagrada la idea de advertir a los usuarios que instalaron paquetes maliciosos, pero parece poco viable de implementar. El AUR no tiene el seguimiento de instalaciones que sí existe en herramientas comerciales. ¿Cómo sabrías quién instaló qué paquete? El AUR es básicamente más parecido a una guía telefónica de ubicaciones de paquetes, y ni siquiera requiere información de inicio de sesión o autenticación
      Así que las advertencias tendrían que venir de herramientas que el usuario pueda ejecutar si presta atención, y que de hecho le exijan prestar atención. Ej.: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • No debería ser así. Que algunas personas no se tomen en serio los consejos básicos de seguridad no significa que debas romper el flujo de trabajo de todos
      ¿Y cómo se supone exactamente que funcionaría eso de que la nueva API avise al usuario y le haga confirmar que lo leyó? Los paquetes del AUR son solo repositorios git, y los mantenedores de Arch no pueden controlar lo que los ayudantes de AUR hagan o dejen de hacer
    • Sí debería haber un aviso en la portada del AUR. Personalmente, también creo que ayudaría una nota breve en la página principal de Arch con un enlace al aviso en la página del AUR
      Si no quieren enumerar todos los paquetes conocidos afectados, al menos deberían recomendar como postura oficial que quien use paquetes del AUR lea todos los archivos de todos los paquetes que utiliza
    • Ya publicaron el aviso: https://archlinux.org/news/active-aur-malicious-packages-inc...
    • Si se puede confiar en las cifras de Socket.dev, por suerte el impacto parece bastante pequeño
      También tiene sentido. Conozco algunos de los paquetes en la lista de afectados, y están muy desactualizados; además, los proyectos upstream ya no tienen mantenimiento
      No sé cuántas víctimas habrá en total, pero es muy probable que el equipo del AUR tenga cifras exactas. Supongo que lo están manejando lo mejor que pueden de acuerdo con la magnitud del impacto

  • Al final, este tipo de cosa se volvió inevitable y, si no cambia nada, probablemente ocurra con más frecuencia. Me gusta mucho el sistema PKGBUILD del AUR, y lo uso seguido incluso al escribir los míos
    El problema más serio y a la vez más fácil de corregir es que cualquiera puede adoptar un paquete huérfano, y al usuario final no se le informa eso en absoluto
    Lograr que se elimine un paquete da poco beneficio en comparación con el esfuerzo que requiere, así que la forma óptima de soltar el control termina siendo convertirlo en paquete huérfano. Creo que debería ser al revés. Como mínimo, el usuario debería saber claramente que el paquete quedó huérfano
    Puede que esta carga recaiga más en ayudantes de AUR como paru o yay, y recomendaría que hagan ese cambio

  • Hay un script sencillo para escanear paquetes comprometidos
    https://cscs.pastes.sh/aurvulntest20260611.sh
    No es mi script, y es fácil de leer y entender. Nunca deberían hacer pipe directo de un script a bash

    • También hay una alternativa más rápida
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      Nunca es mal momento para aprender comm(1)
    • Esto solo verifica si el paquete fue instalado, no si la versión instalada fue la infectada
      Supongo que si, como yo, no ejecutaste yay -Syu en un buen rato, durante meses, entonces estarás bien, ¿no? …¿verdad?
      Carajo, no me hagan reinstalar Arch. La última vez me llevó una semana
      Actualización: archinstall está bueno. Me recuperé de nuevo en unos 15 minutos
    • No hay garantía de que esa lista esté completa
      Siempre hay que revisar el PKGBUILD y las fuentes. En general, el AUR no es algo en lo que confiar. Más bien sorprende que una intrusión así no haya pasado antes
    • pacman admite configuración regional para fechas, así que buscar 9 Jun solo funciona en locales en inglés o con formato similar
      Después de adaptarlo a mi entorno, me apareció jd-gui, pero en realidad había instalado jd-gui-bin unas dos horas antes de la intrusión. Creo que tuve suerte porque esa noche me dio flojera esperar a compilar desde las fuentes y elegí el paquete -bin

  • La comunidad de Arch está publicando scripts y herramientas rápidamente.
    Por ahora, la utilidad unificada más actual para comprobar si hay infección es esta:
    https://github.com/lenucksi/aur-malware-check
    Además, en la lista de correo aur-request están apareciendo muchas solicitudes de eliminación y de dejar paquetes huérfanos para revertir commits maliciosos:
    https://lists.archlinux.org/archives/list/aur-requests@lists...

    • Pregunta de principiante: si esto no viene de Arch ni de una fuente oficial, ¿cómo se sabe que es confiable?
      Hay muchas partes de ese script que son difíciles de entender, así que no es fácil juzgar solo leyendo el código si es seguro
      Uno termina esperando alguna reacción o solución del lado de los desarrolladores oficiales de Arch
    • Me gusta la gráfica de estrellas en la parte de abajo del README del repositorio.
      Transmite bien la urgencia y la importancia de estar involucrado en un ataque de malware de esta magnitud

  • Recuerdo haber instalado hace como 10 años el emulador Mednafen en Arch Linux. El programa no arrancaba porque estaba enlazado contra una biblioteca que no existía en mi sistema.
    Resultó que el mantenedor había compilado el software en su propio sistema, y se usó una biblioteca que estaba ahí pero no figuraba en las dependencias.
    Era un paquete oficial mantenido, y yo siempre había pensado que estas cosas se construían en servidores dedicados de build, no por voluntarios al azar o en computadoras de casa. No sé si Arch todavía compila de la misma manera, pero eso me asustó lo suficiente como para cambiar de distribución

    • Esto puede pasar incluso usando pkgctl build. Es un caso donde makedepends= trajo de forma transitiva bibliotecas compartidas al entorno de compilación, pero faltan en depends=.
      Hay una advertencia cuando se detectan dependencias .so, pero depende del mantenedor verla y tomar medidas.
      En términos de integridad y seguridad, Arch Linux ha sido uno de los pilares que impulsan el proyecto de compilaciones reproducibles, y una parte considerable del sistema operativo puede verificarse de forma independiente para confirmar que esos binarios realmente se compilaron a partir del código fuente. El esquema de auditoría para paquetes oficiales es más fuerte que el de NixOS y está más o menos al nivel de Debian:
      https://reproducible.archlinux.org/
      Pero todo esto es totalmente aparte del incidente actual de AUR
    • Hay herramientas para detectar esto compilando e instalando paquetes desde una imagen limpia. Por ejemplo, pkgctl.
      Si eres mantenedor, deberías usarlas sí o sí antes de publicar
    • Hasta hace relativamente poco, esta forma de trabajar era común. Debian también operó así durante mucho tiempo, y recién en 2019 lo prohibió por completo

  • ¿Cuál sería la solución a este problema? ¿Instalar este tipo de paquetes dentro de un contenedor Docker sin acceso a red? No creo que haya que asumir que esto se limita solo a AUR.
    En 2026 habrá que desconfiar de todas las fuentes de software. Más aún con la expansión del vibe coding, y el software cerrado es una caja negra, así que es un caos todavía mayor que el open source

    • Las “app stores” no confiables, incluyendo AUR, Flatpak, etc., deberían estar dentro de un sandbox. Como mínimo, parece necesario tener una máquina virtual como opción o como valor por defecto
    • Me duele decirlo, pero la gente de Qubes OS tenía razón. La solución es aislar agresivamente las apps en máquinas virtuales.
      Si alguien se cambia en serio, ¿sabe cuánto empeora la duración de batería?
    • Hace falta adoptar SLSA
    • Flatpak

  • Siguen saliendo más noticias relacionadas.
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    He pensado en la idea de crear un binario canario que, cuando se ejecute, simplemente envíe un correo o muestre una notificación, y llamarlo npm.
    A estas alturas, no cambiarle el nombre al binario de npm es un riesgo enorme