Investigadores y la propia comunidad de Ethersphere identificaron el 9 de noviembre la publicación de versiones maliciosas de dos herramientas del ecosistema Swarm: la biblioteca JavaScript bee-js y la aplicación Swarm Desktop. Los paquetes fueron distribuidos mediante la misma automatización de lanzamiento del proyecto, lo que permitió que el código malicioso pareciera legítimo.
Qué hacía el código malicioso
Ambas versiones contenían un cargador ligero que descargaba más código desde un servidor controlado por los atacantes y lo ejecutaba con los permisos del usuario. Ese segundo código buscaba en la carpeta de datos de Swarm Desktop dos archivos: config.yaml y data-dir/keys/swarm.key. El segundo es la clave privada del nodo (un keystore cifrado) y el primero contiene, según el análisis, la contraseña en texto plano que desbloquea esa clave.
Con ambos archivos, los atacantes pueden recuperar la clave y acceder a los fondos y activos asociados al nodo (tokens, chequebook y stake). Además, el payload instalaba una puerta trasera: en Linux y macOS dejaba un shell remoto escrito en Go en una carpeta oculta y lo ejecutaba como servicio de usuario o LaunchAgent; en Windows instalaba un cliente legítimo de acceso remoto (ScreenConnect) y lo hacía persistente como servicio del sistema.
Cómo se distribuyeron las versiones y por qué fueron efectivas
En el caso de bee-js, el paquete comprometido se publicó en el registro npm y contenía un script postinstall, que npm ejecuta automáticamente durante la instalación a menos que se desactiven los scripts de instalación. Eso permitía que el código se ejecutara incluso si un proyecto no importaba explícitamente la librería.
Swarm Desktop, que ejecuta un nodo y almacena las claves en el equipo del usuario, fue firmado y distribuido usando la canalización de publicación del proyecto: los atacantes lanzaron un flujo de trabajo de build que poseía las credenciales de firma y logró producir un instalador firmado y notarizado para macOS y firmado para Windows. Al estar firmado con credenciales válidas del proyecto, la aplicación pasó las comprobaciones habituales de macOS y pudo ofrecerse a través del actualizador integrado en algunos sistemas.
Acciones tomadas y limitaciones de la remediación
Los mantenedores retiraron las versiones maliciosas y publicaron una nueva versión limpia de Swarm Desktop que reemplaza la 0.56.2 comprometida. En el caso de bee-js, el registro npm volvió a la versión anterior legítima. Los responsables del proyecto indicaron que la publicación de las releases comprometidas se hizo usando credenciales de CI robadas.
Sin embargo, retirar las releases y emitir actualizaciones no elimina una puerta trasera ya instalada ni recupera claves que ya fueron exfiltradas. Los análisis técnicos recomiendan considerar cualquier equipo que haya ejecutado los paquetes comprometidos como comprometido por completo.
Qué deben hacer administradores y responsables de sitios
- Determinar si sus sistemas instalaron bee-js o Swarm Desktop durante la ventana de compromiso; revisar logs de instalación y actualizaciones automáticas.
- Si Swarm Desktop 0.56.2 o bee-js 13.3.0 (u otras versiones identificadas como comprometidas) estuvieron presentes, asumir la posible exfiltración de config.yaml y swarm.key y proceder como si la clave estuviera comprometida.
- Retirar cualquier instancia afectada y reinstalar desde versiones oficiales y revisadas; en Linux, sustituir paquetes manualmente cuando el autoactualizador no aplique la corrección.
- Rotar claves y migrar fondos y stake a nuevos wallets creados y protegidos; cambiar contraseñas y no reutilizar configuraciones que contuvieran secretos en texto plano.
- Revisar procesos de CI/CD: exigir aprobaciones manuales en trabajos de firma y limitar el acceso a credenciales y secretos en pipelines.
- Habilitar prácticas de mitigación para npm: desactivar scripts postinstall cuando sea posible, usar auditorías de dependencias y reproducir builds en entornos controlados para verificar la procedencia del código.
Contexto y recomendaciones finales
El incidente ilustra un vector frecuente en la seguridad de la cadena de suministro: la publicación de artefactos maliciosos aprovechando credenciales de automatización. Aunque la firma y la procedencia pueden indicar que un artefacto proviene del repositorio y del workflow correctos, no garantizan que el contenido haya sido revisado. Los equipos deben combinar controles de acceso en CI, aprobaciones manuales para firmas y políticas que reduzcan la ejecución automática de scripts en dependencias.
Nota: los mantenedores afirmaron que la publicación fue posible por credenciales de CI robadas; las investigaciones en curso no habían confirmado el alcance total de equipos afectados ni pérdidas de fondos al cierre de las fuentes técnicas consultadas.
Lee también:
- Revolve confirma que la brecha de septiembre afectó a 1,5 millones de clientes
- Ataque aprovechó el acceso confiable de Qubole a AWS para robar secretos y datos de clientes
Fuente: The Hacker News
