Paquetes AUR comprometidos con infostealer y rootkit

Alcance y naturaleza del compromiso

• Alrededor de ~400 paquetes AUR fueron tomados, en su mayoría mediante la adopción de paquetes huérfanos e inyección de pasos de compilación maliciosos.
• La carga útil usó inicialmente npm install atomic-lockfile ... durante post_install; variantes posteriores cambiaron de herramientas (por ejemplo, bun) para evadir indicadores simples.
• La campaña ha continuado, con nuevas confirmaciones maliciosas que siguen apareciendo; no se limita a una sola ventana de incidentes.

Detección y “¿estoy comprometido?”

• Se compartieron varios scripts / one‑liners para:
  • Comparar paquetes AUR instalados con listas de paquetes comprometidos conocidos.
  • Distinguir entre “instalado pero nunca actualizado durante la ventana del ataque” y “actualizado y probablemente infectado”.
• Matiz clave: no bastaba con tener instalado un paquete afectado; por lo general había que actualizarlo durante el período malicioso.
• Se compartieron enlaces a análisis preliminares del malware e ideas para comprobar rootkits; no está claro cuán eficaces sean herramientas genéricas (p. ej., rkhunter) para este rootkit BPF específico.

Modelo de confianza de AUR y sus límites

• Recordatorio contundente: AUR es explícitamente “producido por usuarios, bajo tu propia responsabilidad”, más parecido a un pastebin que a un repositorio verificado.
• Muchos sostienen que debes:
  • Leer cada PKGBUILD antes de instalar.
  • Revisar los diffs en cada actualización, incluidos parches y fuentes externas.
• Otros dicen que esto es irreal a gran escala y comparable a esperar que todo el mundo lea íntegramente los EULAs.

Paquetes huérfanos y política de adopción

• Vector de ataque principal: adopción masiva de paquetes huérfanos (hay muchos miles), y luego añadir pasos maliciosos.
• Varios califican el modelo actual de adopción como “roto” y sugieren:
  • Forzar nuevas presentaciones en lugar de tomas silenciosas.
  • Depurar huérfanos antiguos.
  • Advertencias visibles cuando cambia la mantenencia.
• Algunos proponen nombres de paquetes restringidos por nombre de usuario para dejar más clara la propiedad.

Prácticas de usuario y mitigaciones

• Muchos recomiendan:
  • Limitarse a los repositorios oficiales cuando sea posible; mantener el uso de AUR al mínimo.
  • Evitar los ayudantes de AUR o, al menos, usarlos solo con revisión manual del diff de PKGBUILD.
  • Desconfiar de paquetes AUR que a su vez dependan de otros paquetes AUR, grandes conjuntos de parches o pasos adicionales de descarga desde la red.
  • Ejecutar software riesgoso en VMs/contenedores o VMs QEMU separadas para distintos roles (trabajo vs. finanzas).
• Herramientas como traur y otros escáneres pueden señalar patrones sospechosos (p. ej., tomas de huérfanos), pero no son garantías.

Papel de npm y el riesgo más amplio de la cadena de suministro

• El código malicioso se distribuyó a través de npm (y luego mediante otras herramientas de JS), reforzando la percepción del ecosistema JS como un vector frecuente de cadena de suministro.
• Varios señalan que esto no es exclusivo de AUR: PyPI, npm, cargo, extensiones del navegador, Flatpak/Flathub, etc. comparten riesgos sistémicos similares.

Respuesta de Arch y comunicación

• Algunos critican el retraso o la escasa comunicación oficial y sostienen que AUR debería haberse puesto temporalmente en “cuarentena” con advertencias claras.
• Otros responden que:
  • AUR siempre ha sido explícitamente no verificado.
  • La infraestructura está gestionada por voluntarios; las expectativas de una respuesta a incidentes de “nivel empresarial” son poco realistas.
• Finalmente, una noticia oficial de Arch reconoció el incidente; los mantenedores están procesando solicitudes de borrado / conversión a huérfano.

Salvaguardas futuras y automatización

• Mejoras sugeridas:
  • Advertencias en los ayudantes para cambios recientes de propietario, adopciones de huérfanos y descargas inusuales (por ejemplo, nuevo uso de npm/curl).
  • Escaneo automatizado opcional (incluida revisión basada en LLM) para señalar cambios sospechosos en PKGBUILD, reconociendo al mismo tiempo los riesgos de prompt injection y de falsa sensación de seguridad.
  • Aislamiento más fuerte mediante sandbox/VM y adopción más amplia de marcos de cadena de suministro como SLSA.
• Algunos ven esto como “prácticamente el fin del modelo actual de AUR”; otros lo consideran un incidente serio pero no sorprendente que reafirma advertencias conocidas en lugar de invalidar AUR por completo.