Ataque a la cadena de suministro de extensiones GlassWorm roba credenciales desde Open VSX

Una nueva alerta de seguridad pone en evidencia lo frágil que puede ser la cadena de distribución de código: actores maliciosos lograron manipular actualizaciones legítimas alojadas en el registro Open VSX para propagar un cargador de malware conocido como GlassWorm. La investigación publicada por la firma Socket describe cómo extensiones mantenidas por un desarrollador legítimo fueron actualizadas con versiones contaminadas que, antes de su eliminación, habían acumulado decenas de miles de descargas.

Open VSX es una plataforma abierta para publicar extensiones compatibles con editores tipo Visual Studio Code, y su ecosistema facilita que herramientas útiles de productividad y utilidades del día a día lleguen a programadores de todo el mundo. Precisamente esa confianza y ese alcance es lo que convierten a este tipo de repositorios en objetivos atractivos para atacantes que quieren maximizar el impacto de su código malicioso. La explicación técnica y el análisis forense del incidente pueden consultarse en el informe publicado por Socket aquí, y el repositorio afectado también registró discusión pública en GitHub sobre la intrusión en esta incidencia.

Según el análisis disponible, el mecanismo de ataque no fue la creación de paquetes falsos con nombres parecidos ni una estafa de typosquatting en esta ocasión: los atacantes habrían obtenido acceso a las credenciales de publicación de un desarrollador real y usaron esa cuenta para subir versiones maliciosas de extensiones ya populares. Por ese motivo las muestras pasaron relativamente desapercibidas al principio, hasta que el comportamiento malicioso fue detectado y las versiones comprometidas fueron eliminadas del registro.

El software entregado en las actualizaciones actúa como un cargador: es decir, un componente diseñado para descifrar y ejecutar código adicional en tiempo de ejecución. Socket relaciona estas cargas con la familia GlassWorm, que emplea técnicas cada vez más sofisticadas para ocultar sus comunicaciones y servidores de mando y control. Entre esas técnicas figura lo que los investigadores describen como “EtherHiding” y el uso de memos en la red de Solana como un mecanismo dinámico para publicar puntos de contacto alternativos sin necesidad de volver a distribuir la extensión maliciosa.

El comportamiento del malware evidencia una fase de reconocimiento antes de activarse: el código evalúa el entorno de la máquina víctima y evita detonar si detecta una configuración local de Rusia o territorios afines, una práctica habitual entre campañas atribuidas a actores de habla rusa que buscan reducir la posibilidad de acción legal contra los suyos. Cuando la ejecución continúa, el objetivo principal del actor es la recolección de credenciales y datos sensibles.

Las piezas de información que GlassWorm busca abarcan desde credenciales y cookies de navegadores —tanto de Firefox como de navegadores basados en Chromium, incluyendo extensiones de billeteras Web3 como MetaMask— hasta archivos de billeteras de criptomonedas (por ejemplo, Electrum, Exodus, y soluciones de hardware/software como Ledger Live y Trezor Suite). Además, según la investigación, el cargador intenta extraer datos del llavero de iCloud, cookies de Safari, notas y documentos locales, configuraciones de clientes VPN (se cita FortiClient) y artefactos usados por desarrolladores, como configuraciones de npm con tokens de autenticación o credenciales de GitHub que podrían permitir acceder a repositorios privados y secretos de CI/CD.

Robar acceso a herramientas de desarrollo y credenciales en la máquina de un desarrollador es especialmente peligroso porque facilita movimientos laterales y compromisos de cuentas en la nube: con un token o una llave privada pueden ejecutarse despliegues, accederse a infraestructura o activar automatizaciones que afectan a toda una organización. Por eso los expertos subrayan que la amenaza no es solo individual sino de carácter empresarial.

Otro aspecto relevante del incidente es cómo el atacante procura confundirse con los flujos normales de trabajo del desarrollador. En lugar de basarse únicamente en indicadores estáticos —hashes o URLs concretas que cambian con frecuencia— el operador del malware usa cargas cifradas que se decodifican en memoria y una infraestructura de control que rota mediante señales públicas en blockchain, lo que dificulta la detección tradicional basada en firmas y eleva la necesidad de detección por comportamiento y respuesta ágil. Socket explica estas tácticas y la dificultad que implican para defensores en su informe aquí.

Para usuarios y administradores la receta de mitigación pasa por medidas en varios frentes: revisar y revocar credenciales comprometidas, forzar la rotación de tokens y claves, habilitar la autenticación multifactor para cuentas de publicación y repositorios, y auditar los entornos de CI/CD por artefactos sospechosos. También es importante monitorizar comportamientos atípicos en endpoints, como procesos que descifran y ejecutan blobs en memoria o conexiones hacia dominios/esquemas no habituales. Recursos institucionales sobre seguridad de la cadena de suministro y buenas prácticas pueden consultarse en páginas oficiales como la de CISA sobre seguridad en la cadena de suministro aquí, y la documentación sobre gestión de secretos y seguridad en plataformas de desarrollo es útil para reducir riesgos.

Para los desarrolladores que publican extensiones, la lección es doble: proteger el proceso de publicación con controles robustos, y suponer que cualquier artefacto que llegue al usuario final puede ser auditado y revertido rápidamente. Mantener copias verificadas de los paquetes, registrar y limitar tokens de publicación, revisar registros de acceso y emplear escaneo automático de dependencias son prácticas que reducen la ventana de exposición. GitHub y otros proveedores ofrecen guías de seguridad aplicables a estos escenarios; es aconsejable revisarlas y aplicarlas en los flujos de trabajo.

En última instancia, este incidente recuerda que la seguridad del software no empieza ni termina en el código que escribimos: la confianza en las herramientas y en las cadenas de distribución es crítica y debe gestionarse con la misma seriedad que la protección de la infraestructura. Para quien quiera profundizar en los detalles técnicos y las evidencias del caso, el análisis de Socket y la discusión del repositorio afectado ofrecen un punto de partida fidedigno: informe de Socket, el hilo en GitHub y la página del registro Open VSX para seguir las acciones tomadas por la comunidad.