Glassworm vuelve: tercera ola de paquetes maliciosos en los marketplaces de VS Code

Resumen de la campaña

La campaña conocida como Glassworm, detectada inicialmente en octubre en los marketplaces OpenVSX y Microsoft Visual Studio, ha regresado con una tercera oleada. Según los informes, se han añadido 24 paquetes nuevos distribuidos entre ambas plataformas. La actividad reiterada indica un esfuerzo sostenido por parte de los operadores para usar extensiones de editores como vector de compromiso.

Glassworm reaparece en los marketplaces de extensiones para editores; 24 paquetes nuevos integrados en la tercera oleada refuerzan el carácter persistente de la campaña.

Contexto y por qué importa

Los editores de código y sus marketplaces se han convertido en un punto de apoyo crítico para la cadena de suministro de software. Las extensiones para Visual Studio Code (y variantes) facilitan flujos de trabajo, integraciones con servicios en la nube y automatizaciones CI/CD, lo que a su vez les confiere un acceso privilegiado a entornos de desarrollo. Un paquete malicioso en este ecosistema puede ejecutar código en máquinas de desarrolladores, robar credenciales o instrumentar pipelines de despliegue.

Glassworm no es un caso aislado dentro del modelo de riesgos de la cadena de suministro. Históricamente, incidentes como la intrusión a SolarWinds (2020) o compromisos en repositorios de dependencias y gestores de paquetes (por ejemplo, casos de manipulación de paquetes npm o de integridad de herramientas de build) han demostrado que componentes aparentemente benignos pueden convertirse en puertas traseras de gran impacto. Además, ya se han documentado extensiones de editores que contenían criptomineros, backdoors o funcionalidades de exfiltración.

La recurrencia de Glassworm y la proliferación de paquetes asociados hacen que el problema sea relevante tanto para equipos de seguridad como para desarrolladores individuales: la confianza en extensiones distribuidas por marketplaces gestionados no garantiza inmunidad frente a operadores persistentes y adaptativos.

Análisis técnico y comentarios para profesionales

Aunque los detalles técnicos finos de cada paquete no siempre se publican con rapidez, hay patrones comunes que los profesionales deben vigilar:

• Obfuscación o empaquetado de código que dificulta la revisión manual.
• Uso de cargas remotas o módulos descargados en tiempo de ejecución que puedan cambiar comportamiento tras la instalación.
• Solicitudes de permisos amplios en el entorno del editor o acceso a APIs que permiten leer variables de entorno, archivos locales o tokens almacenados.
• Comportamiento persistente: agentes que intentan instalar mecanismos de reinicio, tareas programadas o establecer persistencia en el sistema.

Para equipos de seguridad y DevSecOps, la clave es combinar controles preventivos con detección basada en comportamiento:

• Revisión de código y auditoría automatizada de paquetes nuevos y actualizaciones antes de su despliegue en entornos corporativos.
• Análisis estático y dinámico (sandboxing) de extensiones sospechosas para observar llamadas a red, descargas dinámicas y operaciones sobre el sistema de archivos.
• Control estricto de tokens y credenciales: minimizar privilegios, usar scopes limitados y rotación periódica de secretos.
• Políticas de gestión de extensiones: permitir solo extensiones aprobadas en máquinas gestionadas y bloquear instalaciones desde orígenes no verificados.

Los equipos de respuesta a incidentes deben tratar cada paquete malicioso como un potencial punto de compromiso de desarrollo que puede afectar artefactos, flujos de integración continua y credenciales. La rápida identificación y revocación de tokens expuestos es esencial para mitigar movimiento lateral y persistencia.

Riesgos, implicaciones y casos comparables

Las implicaciones de campañas como Glassworm varían según el alcance del compromiso, pero entre los riesgos más relevantes destacan:

• Robo de credenciales y tokens de acceso que permiten comprometer repositorios de código, servicios cloud o pipelines CI/CD.
• Inserción de código malicioso en repositorios o artefactos de build (integridad de la cadena de suministro).
• Exfiltración de información sensible desde equipos de desarrollo, incluyendo secretos nunca comprometidos anteriormente.
• Despliegues no autorizados y posible escalada hacia entornos de producción.

En términos comparables, los incidentes de compromisos en gestores de paquetes, ataques a proveedores de software y extensiones maliciosas han demostrado un patrón repetido: los actores buscan alcanzar cuentas con privilegios y/o mecanismos de automatización. Los ejemplos de alto perfil (por ejemplo, SolarWinds) y casos de manipulación de dependencias (varios incidentes documentados en ecosistemas de paquetes como npm o PyPI) sirven de recordatorio de que la confianza transaccional en componentes de terceros es un vector explotable con consecuencias a gran escala.

Recomendaciones prácticas

A continuación, medidas concretas y priorizadas para organizaciones y desarrolladores:

• Gestionar extensiones desde una lista blanca: en entornos corporativos, aplicar políticas que solo permitan extensiones aprobadas por el equipo de plataformas o seguridad.
• Auditar nuevas instalaciones y actualizaciones: integrar análisis estático/dinámico automático en el proceso de aprobación.
• Minimizar privilegios: no almacenar tokens de amplio alcance en máquinas de desarrollo; usar tokens de corto tiempo de vida y scopes reducidos.
• Segregar entornos de desarrollo y secretos: usar credenciales dedicadas para tareas locales y evitar que herramientas de editor accedan a claves de producción.
• Hardenizar estaciones de trabajo: controles EDR/AV con detección de comportamiento, listas de bloqueo de ejecuciones no autorizadas y segmentación de red para limitar la exfiltración.
• Monitorizar actividad sospechosa: alertas sobre conexiones salientes inusuales, procesos nuevos que interactúan con sistemas de control de versiones o CI, y cambios en artefactos de build.
• Plan de respuesta: procedimientos para rotación rápida de credenciales, revocación de tokens y análisis forense si se detecta una extensión comprometida.
• Formación y concienciación: educar a desarrolladores sobre riesgos de extensiones, señales de comportamiento malicioso y prácticas seguras de gestión de secretos.

Conclusión

La tercera ola de Glassworm, con 24 paquetes nuevos detectados en OpenVSX y Microsoft Visual Studio Marketplace, subraya la persistencia y eficacia de los actores que explotan el ecosistema de extensiones. Para mitigar el riesgo es imprescindible combinar políticas de control de extensiones, auditoría técnica de paquetes y prácticas sólidas de gestión de credenciales. La seguridad en la cadena de suministro del software es una responsabilidad compartida: marketplaces, equipos de plataforma, desarrolladores y equipos de seguridad deben coordinarse para reducir la superficie de ataque y responder con rapidez ante nuevas oleadas.

Source: www.bleepingcomputer.com