Arch Linux considera que el incidente de malware ya está bajo control: más de 1,500 paquetes afectados

 (phoronix.com/news)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • En el repositorio AUR de contribuciones de usuarios de Arch Linux, primero se confirmó que había más de 400 paquetes infectados con malware, pero la cifra final aumentó a más de 1,500
  • En una actualización de hace unas horas, se estimaba que unos 900 paquetes habían sido infectados en este incidente de esta semana
  • Después, los desarrolladores de Arch Linux eliminaron todos los commits maliciosos identificados, y el número de paquetes afectados se contabilizó en 1,579
  • La lista de 1,579 también aparece como una lista amplia pero no completa de los paquetes afectados, por lo que el alcance total podría ser mayor
  • Mucho software en el repositorio mantenido por usuarios se vio afectado por este incidente de seguridad, y en una actualización aparte se reportó otra ola de ataques de malware más sofisticados

Resumen del incidente

  • El incidente comenzó cuando se descubrieron más de 400 paquetes infectados con malware en el repositorio AUR de contribuciones de usuarios para usuarios de Arch Linux
  • Al final del día, Arch Linux consideró que todos los commits afectados ya habían sido atendidos, pero el número de paquetes impactados aumentó a más de 1,500
  • Este fue un incidente de seguridad que afectó a mucho software del repositorio mantenido por usuarios de Arch Linux

Cambio en el alcance del impacto

  • En una actualización de hace unas horas, se estimaba que alrededor de 900 paquetes habían sido infectados con malware en el incidente de esta semana
  • Después, según el último mensaje del hilo sobre el incidente de seguridad, los desarrolladores de Arch Linux eliminaron todos los commits maliciosos identificados
  • La lista citada muestra que el número de paquetes afectados por el malware fue de 1,579

Incertidumbre restante

  • La lista que muestra 1,579 paquetes también está marcada como “una lista amplia, pero no completa, de los paquetes afectados”
  • Por lo tanto, la cifra publicada muestra un alcance confirmado y masivo del impacto, pero la propia lista no abarca todos los paquetes

Actualización posterior

  • En una actualización aparte, continuó la información de que el AUR de Arch Linux enfrentó otra ola de ataques de malware más sofisticados

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Hacker News

  • Me pregunto si el equipo de AUR ha publicado alguna vez un análisis post mortem
    La respuesta esta vez fue impresionantemente rápida, pero sinceramente parece que hacen falta cambios, ya sea en la política de AUR o en los wrappers
    Debería poder configurarse una antigüedad mínima del paquete como en pnpm, y no cualquiera debería poder adoptar paquetes huérfanos
    También se podría poner un límite de velocidad global a las adopciones para usarlo como señal de ataque, y al publicar también hace falta escaneo de vulnerabilidades, como hacen varias empresas en NPM
    Aun así, la mayoría de estos cambios les corresponderían más a los helpers de empaquetado y a terceros que a los mantenedores de AUR

    • Sería mejor dividir los paquetes de AUR por espacios de nombres
      Así la propiedad no desaparecería y ya no haría falta marcarlos como huérfanos
    • No hay una herramienta oficial para descargar repositorios de AUR, así que esa parte depende del método que use cada quien
    • Hace poco hice un parche para pakku inspirado en pnpm que agrega una antigüedad mínima de AUR [1]
      [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
      [2] https://github.com/zqqw/pakku
    • Si se restringe demasiado la adopción de paquetes huérfanos, algunos que sí podrían mantenerse bien terminarían abandonados
      Sí hace falta una limitación, pero algo como 1 adopción al mes para usuarios registrados desde antes de cierto periodo parece razonable
      De todos modos, casi nadie aplica actualizaciones automáticas y sin revisión a paquetes de AUR instalados localmente, así que la superficie de ataque ya es bastante pequeña
    • Es muy probable que un simple escaneo de vulnerabilidades no lo hubiera detectado
      El punto clave del gusano miasma es precisamente que las firmas y la forma de los helpers cambian demasiado rápido
      El implante malicioso cifrado descifra la carga útil con una clave AES-128-GCM distinta según la ubicación subida en GitHub, los nombres de métodos del código también cambian dinámicamente, y además reutiliza offsets de símbolos cifrados mezclándolos
      Como es malware polimórfico, es un rival terrible para las herramientas basadas en firmas
      APT28/29 parece depender en cierta medida de que Microsoft tarde en bloquear automáticamente a los usuarios y repositorios de GitHub usados como infraestructura C2
      Vale la pena pensar qué implica esto para la estrategia de seguridad
      Para cuando ya puedes escanear firmas o cadenas, ya estás jugando al gato y al ratón contra una botnet totalmente automatizada, y no vas a ganar
      Durante la semana pasada, prácticamente solo socket.dev siguió estos cambios del implante, y las demás herramientas redescubrieron Miasma como si fuera una campaña nueva sin siquiera saber de qué se trataba
      Faltó personal y toolchains capaces de hacer ingeniería inversa de las cargas útiles lo bastante rápido como para seguir el ritmo de nuevos adaptadores para ecosistemas que aparecían cada 24 horas
      Aquí, “totalmente automatizado” significa que en otros ecosistemas de paquetes ya se estaban usando credenciales robadas antes de 48 horas
      Siguen apareciendo direcciones de correo y nombres, y parece muy probable que pertenezcan a personas que no entendieron el impacto de este gusano autorreplicante
      Por ejemplo, buscar indicadores de compromiso en paquetes que dependan de bun tampoco ayuda mucho
      El malware simplemente puede volver a descargarse por otros medios externos
      En la segunda campaña de PyPI, después de que la primera ola de droppers maliciosos de la campaña de RedHat fue marcada para los mantenedores de PyPI, cambiaron a descargar el dropper con archivos WHL comprimidos y archivos setup.pth de ejecución automática
      A menos que los gestores de paquetes de estos ecosistemas se reescriban desde cero asumiendo chroot, sandboxing, logs de red y dominios, y listas de permisos por ítem, seguirá siendo realista usar ataques a la cadena de suministro para distribuir malware
      El repositorio con herramientas de mitigación es [1], y los detalles técnicos están en la entrada de blog [2]
      También se ven afectados Composer, Rubygems, NPM, PyPI y Go; es un problema de todos los gestores de paquetes
      Hay que discutir más abiertamente cuánta confianza externa y cuánta negligencia estamos cargando sobre los gestores de paquetes en general, y esto de verdad tiene que cambiar
      [1] https://github.com/cookiengineer/antimiasma
      [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • Cuando empezaron a aparecer wrappers de pacman que se podían instalar directamente desde AUR, me resultó muy incómodo
    Sí he instalado cosas desde AUR, pero la mayoría de las veces prefiero saltarme ese paso intermedio e ir directo al sitio web del proyecto
    Un PKGBUILD ya preparado no me parece lo bastante conveniente como para asumir el riesgo de typosquatting o del abuso de dependencias de npm o pip

    • Wrappers como yay muestran el diff del PKGBUILD en cada actualización
      Al instalar por primera vez, verificas la URL y si el script de instalación y demás parecen razonables; después, en la mayoría de las actualizaciones solo cambian el número de versión y el checksum
      Un ataque de typosquatting se notaría con bastante claridad
      La primera instalación sí es algo vulnerable, pero lo mismo pasa si vas al sitio web del proyecto y haces clic en descargar
    • Arch sigue recibiendo críticas por ser elitista o por poner barreras a usuarios comunes, pero claramente hay una ventaja en no hacer fáciles las cosas peligrosas
      Pasa igual en muchos otros aspectos de la vida
      Después de usar Void Linux, en Arch también me cambié a aurutils para tener una separación parecida
      Puedes compilar tú mismo, mantener fácilmente un repositorio local de AUR e instalar y administrar con pacman, lo que mejora todo el proceso de actualización
    • Para mí, ese punto medio no vale la pena
      No me cambié a Linux para perder tiempo actualizando programas como usuario de Windows, entrando a sitios web y haciendo clic en “download”
      Aun así, los wrappers de pacman que mencionaste sí parecen riesgosos
    • AUR y repositorios parecidos en otras distribuciones realmente dan miedo
      Hay tantos tutoriales que usan esos repositorios que ya casi parece que uno es el raro por no querer darle permisos root indefinidos a un desconocido sin casi ninguna revisión por pares
      Todo eso por instalar una sola versión de un paquete que no necesita actualizaciones o que las necesita muy rara vez

  • Leyéndolo rápido, parece que instalaron atomic-lockfile, js-digest y lockfile-js desde npm
    La lista de paquetes afectados está en [1]
    No encontré de inmediato una forma de verificar el sistema, así que ejecuté pacman -Qmi para buscar información sobre paquetes externos y fechas
    Luego se puede comparar la salida con la lista de paquetes afectados
    También se pueden buscar archivos así en varias ubicaciones
    grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
    grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
    grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
    No sé si el paquete se borra a sí mismo después de ejecutarse
    Como la otra información no ayudó mucho, quería compartir al menos comandos básicos
    [1] https://md.archlinux.org/s/SxbqukK6IA

    • Yo lo hice así
      Obtuve con yay la lista de paquetes instalados desde AUR: yay -Qam > packages_aur.last
      Descargué la lista desde https://md.archlinux.org/s/SxbqukK6IA#: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
      Después, al ejecutar grep -wFf compromised.txt packages_aur.last, deberían salir los paquetes que aparecen en ambos archivos, es decir, los que estuvieron comprometidos en algún momento
    • El atacante usó al menos tres dependencias de Node, así que no basta con revisar solo atomic-lockfile
      También usó js-digest y lockfile-js, y en algún momento cambió de npm a bun
    • Esto también puede servir: https://github.com/lenucksi/aur-malware-check
    • Da risa que incluso en una situación donde intentan meter malware en el AUR de Arch Linux, el malware siga distribuyéndose por NPM
      Una plataforma legendaria
    • No entiendo cómo fue que emacs-magit salió afectado
      Hasta donde sé, no tiene nada de JavaScript

  • Como siempre, es un recordatorio válido de no instalar paquetes, bibliotecas o aplicaciones arbitrarias de terceros sin revisarlas
    Por suerte, esta vez se limitó al AUR, y el AUR es básicamente un repositorio donde cualquiera puede subir paquetes; además, a diferencia de los repositorios oficiales, se ha advertido muchas veces que hay que revisarlos antes de instalar
    Herramientas de línea de comandos como rua facilitan revisar paquetes antes de instalarlos desde el AUR
    Si haces operaciones bancarias en la misma computadora, no hay excusa para no revisar el software del que dependes
    Si mantienes bajo el número de paquetes y usas solo lo necesario, también se vuelve mucho más simple actualizar

    • ¿Y cómo se supone que uno “revise” eso?
      ¿Que lea línea por línea todo el código antes de instalar?
      ¿Y qué pasa si es un paquete binario?
      ¿Hay que hacer builds reproducibles de todo lo que se instala, o cambiarse a una distro basada en código fuente?
      Pasarle esa responsabilidad al usuario no es una solución sostenible
      Hay espacio para el sentido común, pero culpar al usuario por esto no tiene sentido
    • Suena razonable, pero al final es un consejo imposible de llevar a la práctica, así que más que inútil, termina siendo dañino
      Hay muchísimo más código en el mundo del que una persona podría leer en toda su vida
      Seguramente ni tú has leído el 1% del código fuente que se está ejecutando ahora mismo en tu computadora
      ¿Entonces dejaste de usar computadoras?
      ¿Cómo puedes confiar en lo que pasa dentro de ella?
    • Creo que la postura de “siempre hay que revisar antes de instalar” debería reevaluarse
      Los desarrolladores de Arch Linux hacen un gran trabajo y en lo personal se los agradezco, pero con el aumento de ataques a la cadena de suministro, siento que las advertencias al usuario ya llegaron a su límite hace tiempo
      No se ve una solución fácil, pero controles como revisión por pares antes de publicar o un período de espera sí podrían mitigar el problema hasta cierto punto
    • El AUR ha sido muy valorado desde hace años como una gran ventaja de Arch, pero esa comodidad siempre tuvo un costo
      Es absurdo que alguien pueda marcar un paquete como huérfano, esperar dos semanas y, si el mantenedor original está de vacaciones y no responde, el atacante termine asignado como mantenedor y pueda distribuir una actualización maliciosa
    • Creo que este es un caso fuerte a favor de combinar archivos del sistema inmutables, instalaciones locales de usuario por defecto y privilegios mínimos para componentes y programas
      Las distros inmutables, Wayland y Flatpak aportan algunas piezas, pero todavía quedan huecos importantes
      El problema más grande es que el sandboxing está atado al formato del paquete, y eso me parece un error
      El sandboxing y los permisos de acceso deberían ser funciones a nivel del sistema, para que incluso binarios arbitrarios no puedan escaparse tan fácilmente por las grietas
      Aunque no resuelva todo el problema, sí puede reducir mucho el alcance del daño y volver a los usuarios de la distro objetivos menos atractivos

  • Para quienes estén preocupados, encontré un repositorio que reúne scripts actualizados y listas de paquetes para ayudar a verificar si hubo infección: https://github.com/lenucksi/aur-malware-check

    • Le di la misma lista (https://md.archlinux.org/s/SxbqukK6IA) a Claude para que hiciera una verificación de malware, y realizó esencialmente la misma comprobación que hace este script
      Cualquiera de las dos opciones debería bastar

  • No soy usuario de Arch Linux, pero uso mucho NodeJS, y ahí también sufren ataques parecidos con frecuencia
    Últimamente me pregunto qué lugares están haciendo una gestión de paquetes realmente correcta y segura

    • AUR se basa en el soporte de usuarios, así que a veces se cuela malware en los paquetes
      No había sido a una escala tan grande como esta, pero desde el principio estaba claro que no era seguro y había advertencias de riesgo por todas partes
    • Las distribuciones de Linux lo están haciendo bien
      Todas tienen mantenedores que revisan los paquetes y se hacen responsables
      Arch Linux también es así
      La falta de confiabilidad inherente de AUR siempre se ha mostrado explícitamente en la Arch Wiki y en la cultura alrededor, y es distinta de gestores de paquetes de lenguajes de programación como npm o pip
    • Si no usas AUR, Arch está bien
      Si usas AUR, hay que revisar todo
      La mayoría de las distribuciones también están bien, y las distribuciones grandes tienen un historial bastante bueno
    • Parece que hay algo en el ecosistema de Node que lo hace especialmente vulnerable
      Tal vez sea por una cultura excesiva de DRY, o quizá por otra razón
      De todo lo que he usado, no he visto otra pesadilla de árbol de dependencias a un nivel parecido

  • En AUR hay 15 mil paquetes huérfanos
    Esta mañana ordené por popularidad y adopté 3 que casi no se actualizan para compilarlos
    Si estás usando paquetes huérfanos, quizá valga la pena considerar adoptarlos tú mismo antes de que los tomen personas malintencionadas

  • Puede que me equivoque, pero esta situación parece una señal de mayor adopción de Linux de escritorio

  • Nunca he necesitado AUR
    Si necesito un paquete que no está en el repositorio oficial, lo compilo yo mismo o, si hay una versión binaria, la descargo
    Así no hace falta usar root al compilar, y puedes instalar el programa localmente para un solo usuario, lo que de hecho encaja mejor con la mayoría de los casos de uso de escritorio
    Al menos reduce en un paso la posibilidad de inyección de malware de desarrollador → usuario a desarrollador → mantenedor → usuario

    • makepkg rechaza activamente ejecutarse como root
      A menos que lo fuerces con algo como env EUID=123 makepkg ..., no corre como root
      Aun así, estaría bien que pacman admitiera instalaciones a nivel de usuario
      Actualmente se niega a instalar si no eres root, aunque se puede rodear eso mapeándose a root con un espacio de nombres de usuario

  • Entiendo que esta vez fue en AUR
    Independientemente de si es AUR o no, estaría bien que compartieran qué pasos siguen al instalar paquetes y cómo garantizan que el paquete y sus dependencias no sean malware
    Después de instalar un paquete malicioso, de verdad parece muy difícil volver atrás