GlassWorm en Open VSX Un compromiso de desarrollador expone 22.000 descargas y datos en macOS

Una nueva oleada de la familia de malware conocida como GlassWorm ha vuelto a poner en evidencia cuán frágil puede ser la cadena de suministro del software para desarrolladores. En esta ocasión los atacantes comprometieron la cuenta de un autor legítimo en Open VSX —el registro de extensiones alternativo y de código abierto para editores basados en Visual Studio Code— y publicaron actualizaciones maliciosas en varias extensiones que, en conjunto, superaron las 22.000 descargas antes de ser retiradas.

El análisis técnico publicado por el equipo de seguridad de Socket describe cómo los operadores detrás de la campaña abusaron de la cuenta identificada como oorzc para inyectar el cargador GlassWorm en cuatro paquetes de Open VSX: oorzc.ssh-tools, oorzc.i18n-tools-plus, oorzc.mind-map y oorzc.scss-to-css-compile. Las versiones troceadas fueron subidas el 30 de enero; hasta entonces esos paquetes habían estado disponibles sin incidencias durante aproximadamente dos años, lo que sugiere que los atacantes obtuvieron acceso al entorno de publicación del desarrollador y lo aprovecharon para propagar el malware.

GlassWorm está diseñado para atacar exclusivamente macOS en esta campaña y demuestra un abanico amplio de capacidades de espionaje. El malware descarga y ejecuta un extractor de información que establece persistencia mediante un LaunchAgent para ejecutarse al inicio de sesión, y busca datos sensibles en el equipo: credenciales de navegadores Chromium y Firefox, extensiones y aplicaciones de billeteras criptográficas, entradas del llavero de macOS, bases de datos de Apple Notes, cookies de Safari, secretos de desarrollo y documentos locales. Según Socket, toda la información recopilada se enviaba a una infraestructura controlada por los atacantes en la dirección IP 45.32.150[.]251.

Además del robo de datos, GlassWorm incorpora funciones que facilitan el control remoto y el movimiento lateral: soporte VNC para acceso gráfico remoto y la capacidad de funcionar como proxy SOCKS, lo que permite a los atacantes encaminar tráfico a través de la máquina comprometida. En campañas anteriores la familia GlassWorm ya había mostrado técnicas para ocultar código malicioso mediante caracteres Unicode “invisibles” y había intentado detectar e interferir con aplicaciones de hardware wallets como Trezor y Ledger, lo que denota una evolución constante de sus capacidades para atacar fondos cripto y entornos de desarrollo.

Un detalle técnico curioso y llamativo es el mecanismo de comando y control observado: los operadores extraen instrucciones desde los memos de transacciones de la red Solana. Este tipo de canal de control distribuido, usando blockchains públicas para transmitir órdenes, complica el rastreo tradicional y aporta resiliencia a la infraestructura de los atacantes. Socket también detectó comprobaciones del entorno en el código; entre ellas, la exclusión explícita de sistemas configurados en ruso, una práctica que a veces se interpreta como indicio de que los autores intentan evitar víctimas en su propia región.

La respuesta del ecosistema fue rápida: Socket notificó la incidencia a la Eclipse Foundation, responsable de Open VSX, y el equipo de la plataforma confirmó el acceso no autorizado, revocó los tokens de publicación comprometidos y eliminó las versiones infectadas de las extensiones. En un caso particular, oorzc.ssh-tools fue eliminado por completo del registro después de que se confirmara que contenía múltiples lanzamientos maliciosos. A día de hoy, las versiones públicas de esas extensiones han sido limpiadas, pero eso no borra el riesgo para quienes instalaron las actualizaciones comprometidas durante el periodo en el que estuvieron activas. Para una lectura adicional y cobertura periodística, BleepingComputer ha documentado la campaña y su impacto: BleepingComputer — GlassWorm en Open VSX.

Si instalaste alguna de las versiones afectadas, hay pasos prácticos que conviene tomar de inmediato. Primero, asume que el equipo fue comprometido: realiza un análisis completo y elimina ficheros y agentes sospechosos —los LaunchAgents en macOS son un punto clave a revisar— y considera el uso de herramientas de detección y limpieza específicas para macOS. Segundo, cambia y rota contraseñas, llaves API y tokens, y habilita la autenticación multifactor en todos los servicios donde sea posible; para desarrolladores, revocar y volver a emitir tokens de publicación en los registros de extensiones es esencial. Tercero, revisa cualquier wallet de criptomonedas que hayas usado en ese equipo: si una clave privada o frase semilla estuvo expuesta, las recomendaciones de seguridad obligan a mover los fondos a una wallet nueva y segura. Apple ofrece guías generales sobre seguridad en sus dispositivos que pueden ayudar a orientarse: Documentación de seguridad de Apple.

Este incidente recuerda que la confianza en la cadena de suministro de software es un eslabón crítico para la seguridad. Extensiones y plugins son código que ejecutamos en entornos de desarrollo y producción; un único paquete comprometido puede filtrar secretos de infraestructura, credenciales de repositorios y datos sensibles. Proyectos como Open VSX permiten una alternativa abierta a los mercados oficiales, pero no eliminan la necesidad de controles adicionales: firmar releases, auditar procesos de publicación, limitar permisos y mantener la rotación de secretos son medidas que ayudan a reducir el impacto si un actor malicioso obtiene acceso a una cuenta legítima.

Para entender mejor cómo funcionan las transacciones en Solana y por qué su uso como canal de control es relevante, la documentación oficial del proyecto proporciona contexto técnico sobre el formato y los memos: Documentación de transacciones en Solana. Y si eres responsable de la seguridad de paquetes y extensiones, considera implementar auditorías de integridad y políticas de publicación más estrictas; los operadores de registries y plataformas deben mejorar la detección de publicaciones atípicas y facilitar la revocación rápida de credenciales comprometidas.

La lección es clara: la seguridad del desarrollador ya no es un asunto solo de higiene personal, sino una responsabilidad colectiva. Un paquete con miles de descargas puede convertirse en vector de exfiltración masiva si un atacante logra publicar una actualización maliciosa. Mantenerse informado, vigilar los registros de actividad, rotar secretos y aplicar controles técnicos de publicación son prácticas que hoy resultan indispensables para reducir el riesgo de que un GlassWorm futuro vuelva a propagarse.