Cientos de paquetes de AUR fueron afectados por un ataque de malware para robo de información

• Se insertaron múltiples commits maliciosos en AUR (Arch User Repository), provocando un ataque a la cadena de suministro en el que se modificó el proceso de instalación de paquetes para ejecutar npm install atomic-lockfile
• Una búsqueda en un mirror de solo lectura confirmó el mismo comando malicioso en los archivos PKGBUILD, .install y .hook de aproximadamente 408 paquetes
• Los commits maliciosos usan una modalidad de falsificación de commits en la que suplantan el nombre y correo del commit anterior para hacerse pasar por mantenedores legítimos, independientemente de si hubo o no robo de cuentas
• El equipo de Arch ya está revirtiendo y eliminando los commits maliciosos y bloqueando cuentas; además pidió reportar paquetes maliciosos adicionales en un solo hilo
• Miembros de la comunidad fueron reportando commits de paquetes individuales de forma continua, en una respuesta colaborativa ante un incidente masivo que afecta al ecosistema de paquetes de AUR en general

---

Resumen del incidente y solicitud de respuesta

• Se compartieron indicios de una inserción masiva de commits maliciosos en AUR, y ya están en marcha las tareas de reversión/eliminación de commits maliciosos y bloqueo de cuentas
• Si se detectan más paquetes maliciosos, se pidió reportarlos respondiendo a ese mismo correo para reunirlos en un solo hilo
• La persona encargada de la coordinación respondió que revisó todos los reportes recibidos y agradeció a quienes dedicaron tiempo a reportarlos

Patrón del malware — atomic-lockfile

• Los paquetes alterados ejecutan en común npm install atomic-lockfile, seguido de nombres de paquetes npm adicionales como ora, fast-glob, glob, minimist, axios, commander, execa, chalk, debug y otros
• Tipos de archivos donde se ubicó el comando malicioso
  • Scripts de instalación con formato *-deps.install
  • Scripts de instalación de paquetes *.install
  • Archivos *.hook — por ejemplo, en la forma Exec = /bin/sh -c 'cd /tmp && npm install atomic-lockfile ... 2>/dev/null; exit 0', ejecutándose desde /tmp, ocultando errores y saliendo después
  • En algunos casos también estaba incluido en archivos relacionados como install.sh
• Como ejemplo de paquete malicioso creado recientemente, se reportó exodus-wallet-bin, confirmado como un paquete nuevo creado hace unas 4 horas con base en su primer commit

Método de detección y alcance del impacto

• La detección se hizo revisando directamente un mirror de solo lectura
  • Después de git clone https://github.com/archlinux/aur.git, se recorrieron todas las refs y se ejecutó git grep 'atomic-lockfile'
  • El resultado fue una lista extensa de aproximadamente 408 paquetes que instalan atomic-lockfile, útil para tareas automáticas de limpieza
• Ejemplos de paquetes mencionados como afectados
  • runescape-launcher, oracle-bin, tesseract-gui, python-starsessions, bitcoin-core-git, apple-music-desktop, exodus-wallet-bin, anythingllm-appimage, arm-linux-gnueabihf-binutils y otros
  • También incluye familias amplias de paquetes como cutefish-*, python2-*, python-* y más
• Como el gran volumen de reportes individuales generó demasiados correos, se recomendó agrupar varios casos en un solo mensaje, y en IRC se compartió por separado una lista consolidada de paquetes

Método de suplantación/falsificación

• En paquetes asociados a cierta cuenta (arojas), surgió la duda de si se trataba de robo de cuenta o falsificación de commits
• En respuesta, se confirmó que los commits maliciosos suplantan (impersonate) el nombre y el correo del commit inmediatamente anterior; es decir, falsifican los metadatos del commit
• También se reportó que otros paquetes del mismo usuario ya habían sido corregidos

Estado de la respuesta

• Los commits reportados en distintos paquetes se fueron procesando de manera secuencial, y en algunos casos hubo respuesta de corregido (Done)
• A medida que siguieron llegando más reportes, la persona coordinadora confirmó la recepción en bloque, en paralelo con las tareas en curso de bloqueo y reversión
• Numerosos participantes reportaron paquetes individuales junto con enlaces a los commits, en una respuesta colaborativa impulsada por la comunidad

[GN⁺]

Comentarios de Lobste.rs

• Siento que con esto está llegando casi a su fin la confianza que todavía quedaba en las contribuciones anónimas y no verificadas de la comunidad
  Se siente como ver cómo la confianza se desgasta en tiempo real

  • Si soy honesto, es algo bueno, y ya era tarde. Nuestra industria ya tiene que ponerse las pilas
    Estamos confiando demasiados datos personales y sensibles a las computadoras, y se han vuelto el centro de la vida moderna. Si una computadora personal se infecta, eso es realmente un desastre, y con suerte uno solo puede esperar no ser lo bastante interesante como para que un hacker decida molestarse en enfocarse específicamente en ti
    Y aun así, por alguna razón hemos normalizado ejecutar cualquier programa aleatorio con privilegios totales[1], y luego fingimos sorpresa cada vez que eso demuestra ser una mala idea
    [1] Esto se refiere a los privilegios actuales del usuario. En la mayoría de las configuraciones, root prácticamente ya no significa mucho
  • KDE quitó AUR de su propio pipeline de compilación hace una semana, y probablemente fue una respuesta a una versión anterior de este ataque
  • Sería interesante aplicar un modelo de red de confianza a la revisión de paquetes de AUR y combinarlo con un período de enfriamiento para las actualizaciones recientes
    Me imagino un sistema que te dé estas opciones al instalar o actualizar paquetes de AUR: si es un paquete actualizado recientemente, esperar una semana a que se enfríe; dedicar unos minutos a revisar el paquete tú mismo y dejar una revisión firmada vinculada a tu reputación; o apoyarte en revisiones firmadas de varias otras personas en quienes se haya acumulado suficiente confianza
    Técnicamente, el período de enfriamiento podría no encajar con la política de Arch de mantener todo actualizado al mismo tiempo. Pero los paquetes de AUR de todos modos no son parte del soporte oficial

• Ya pasaron varias horas y el paquete de NPM todavía no ha sido dado de baja: https://www.npmjs.com/package/atomic-lockfile

• Para verificar si los paquetes instalados fueron afectados, se puede usar este pequeño script junto con el archivo aur_pkg_list.txt

  installed_pkgs="$(yay -Qq)";  
  grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' \  
  | while read -r pkg; do \  
      echo "$installed_pkgs" | grep "^$pkg\$"; \  
  done  
  

  Dejé los punto y coma para que sea fácil convertirlo en un comando de una sola línea :-)

  • Parece que también captura subcadenas. Por ejemplo, ktea también coincide con kteatime
    Esta versión parece funcionar

    grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' | while read -r pkg; do  
       echo "$installed_pkgs" | grep "^$pkg\$";  
    done  
    

• Puede que esto haya estado ocurriendo desde hace bastante tiempo. Según este correo de hace 18 días, parece que se usó una carga maliciosa similar, pero el commit malicioso aparentemente fue eliminado por completo del repositorio

• A propósito, ¿habrá algún buen material que compare la postura de seguridad de la cadena de suministro de las distribuciones populares de Linux? La mayoría de los textos que encontré hasta ahora parecían marketing disimulado o artículos mediocres generados por IA. Tal vez simplemente me toque investigarlo por mi cuenta
  La parte deprimente es que, aunque me gusta el ideal del desarrollo comunitario, por preocupaciones de cadena de suministro termino mirando con más atención opciones cerradas o incluso software propietario