Análisis de la Vulnerabilidad de Reutilización de Nombres en VS Code Marketplace y sus Implicaciones para la Seguridad de la Cadena de Suministro de Software

 

Investigadores de ciberseguridad han identificado una vulnerabilidad crítica en la gobernanza de políticas del Visual Studio Code (VS Code) Marketplace, que permite a los actores de amenazas reutilizar los nombres de extensiones previamente eliminadas.

Este informe proporciona un análisis exhaustivo de esta falla, su explotación en el mundo real y su contexto dentro del panorama más amplio de los riesgos de la cadena de suministro de software.

El descubrimiento, realizado por la firma de seguridad ReversingLabs, expone una brecha significativa entre las prácticas de seguridad declaradas por Microsoft y la realidad operativa de su marketplace, permitiendo ataques de suplantación de identidad altamente efectivos.

La vulnerabilidad se origina en una distinción de política entre “anular la publicación” y “eliminar” una extensión. Mientras que la primera opción reserva el nombre, la segunda lo libera para que cualquier otro editor lo reclame.

Esta laguna fue explotada por la campaña de ransomware en desarrollo “Shiba”, que utilizó nombres de extensiones idénticos bajo diferentes editores para distribuir cargas útiles maliciosas. Este incidente subraya cómo una falla de política, en lugar de un error de código tradicional, puede crear un vector de ataque potente y sigiloso.

Un análisis comparativo revela una disparidad en la madurez de la seguridad entre los principales repositorios de paquetes. El Python Package Index (PyPI), por ejemplo, ha implementado una política más robusta que prohíbe explícitamente la reutilización de nombres previamente asociados con paquetes maliciosos, una salvaguarda crucial que está ausente en el VS Code Marketplace.

El ecosistema de npm, aunque se centra en la prevención del typosquatting y la resolución de disputas, también presenta complejidades en sus políticas de ciclo de vida de paquetes. Estas diferencias ilustran una falta de estandarización en las prácticas de seguridad fundamentales en todo el ecosistema de código abierto.

La amenaza se ve agravada por la sofisticación de las campañas maliciosas, como se demuestra en un análisis de ocho paquetes maliciosos de npm que utilizaron 70 capas de ofuscación para desplegar un ladrón de información del navegador Google Chrome. Esta campaña destaca la capacidad de los adversarios para evadir el análisis estático y automatizado, lo que requiere un enfoque de defensa en profundidad.

La mitigación de estos riesgos sistémicos exige la adopción de un modelo de “Responsabilidad Compartida”. Este marco asigna deberes específicos a los propietarios de plataformas, los mantenedores de paquetes, los investigadores de seguridad y los consumidores de software (desarrolladores y organizaciones).

Las recomendaciones clave de este informe incluyen: para los propietarios de plataformas, la reforma de las políticas de ciclo de vida de los nombres para priorizar la seguridad; para las organizaciones, la implementación de controles empresariales como listas de permitidos y el uso de repositorios privados; y para los desarrolladores, la adopción de prácticas de investigación rigurosas para todas las dependencias de terceros.

En última instancia, la seguridad de la cadena de suministro de software depende de un esfuerzo colaborativo y de la maduración de las políticas de gobernanza en todos los niveles del ecosistema.

Deconstrucción de la Vulnerabilidad de Secuestro de Nombres en el Visual Studio Code Marketplace

La vulnerabilidad que permite el secuestro de nombres en el VS Code Marketplace no es un error de código convencional, sino una falla fundamental en la política de gobernanza y el ciclo de vida de las extensiones.

Su mecanismo se basa en una distinción sutil pero crítica en la forma en que el marketplace maneja la eliminación de extensiones, creando una oportunidad para que los actores de amenazas se apropien de la confianza y la reputación asociadas con nombres de extensiones previamente existentes.

La Falla Central: Extensiones “Eliminadas” vs. “No Publicadas”

La raíz de la vulnerabilidad reside en las dos opciones distintas que un editor tiene para retirar una extensión del marketplace, cada una con implicaciones de seguridad drásticamente diferentes.   

1. Anular la Publicación (Unpublish): Cuando un editor anula la publicación de una extensión, esta se oculta de la vista pública en el marketplace. Sin embargo, la plataforma retiene el nombre de la extensión y sus metadatos asociados, como las estadísticas de descarga. Crucialmente, el nombre permanece vinculado al editor original y no puede ser reclamado por nadie más. Este comportamiento es el esperado para mantener la integridad del espacio de nombres y prevenir la suplantación de identidad.   
2. Eliminar (Remove): Por el contrario, cuando una extensión es eliminada por completo, el marketplace la borra de sus registros y, fundamentalmente, libera su nombre. Este nombre vuelve al grupo público de nombres disponibles, lo que permite que cualquier otro editor, legítimo o malicioso, lo reclame y publique una nueva extensión bajo esa misma identidad.   

Esta dualidad en la política de eliminación es el núcleo de la falla explotable. Permite a un actor de amenazas monitorear el marketplace en busca de extensiones que han sido eliminadas, especialmente aquellas que pudieron haber tenido una base de usuarios o una reputación establecida, para luego secuestrar ese nombre y publicar una versión maliciosa.

ReversingLabs demostró de manera concluyente esta falla al publicar con éxito extensiones de prueba utilizando nombres que habían sido previamente asociados con paquetes maliciosos eliminados, como “Solidity-Ethereum”.

El problema no es un error que impide que la política funcione como se diseñó; el problema es que la política fue diseñada con una opción inherentemente insegura.   

Contradicción con la Documentación Oficial y las Políticas de Nomenclatura

La existencia de esta laguna contradice directamente el espíritu, si no la letra, de la propia documentación de VS Code. La documentación oficial para desarrolladores de extensiones estipula que el campo <name> en el manifiesto de la extensión “debe ser exclusivo del Marketplace”. Si bien la unicidad técnica se mantiene a través del identificador completo de la extensión, que combina el nombre del editor y el nombre de la extensión (<editor>.<nombre>), la política de eliminación permite que el componente <nombre>, que es el que ven y buscan los usuarios, sea duplicado por diferentes editores.

El caso de las extensiones ahban.shiba y ahbanC.shiba ejemplifica perfectamente esta contradicción. Ambas compartían el mismo nombre de extensión, “shiba”, y solo se diferenciaban por el nombre del editor.

Para un desarrollador que busca una extensión, esta distinción puede pasar fácilmente desapercibida, especialmente si el nombre del editor malicioso está diseñado para parecer legítimo o genérico.

La política de “eliminar” socava la garantía de unicidad que la documentación pretende ofrecer, creando confusión y un vector de ataque directo.   

Evaluación de las Medidas de Seguridad Declaradas por Microsoft

Microsoft enumera varias medidas de seguridad para proteger el VS Code Marketplace. Sin embargo, un análisis crítico a la luz de esta vulnerabilidad revela que, si bien son útiles para ciertos tipos de amenazas, son insuficientes para abordar la falla de la reutilización de nombres.   

• Análisis de Malware: El marketplace realiza análisis de malware en cada paquete de extensión publicado. Sin embargo, esta es una medida reactiva y no infalible. Las extensiones maliciosas de la campaña “Shiba” estuvieron disponibles en el marketplace durante períodos prolongados antes de ser detectadas y eliminadas, lo que indica que el análisis inicial no las marcó o que el código malicioso se introdujo en una actualización posterior. Además, los atacantes utilizan cada vez más técnicas de ofuscación para evadir estos escáneres.   
• Prevención de “Name Squatting”: La política de Microsoft contra el “name squatting” está diseñada principalmente para evitar que los autores roben los nombres de editores oficiales (como Microsoft o RedHat) o de extensiones muy populares (como GitHub Copilot). Es ineficaz contra el escenario de esta vulnerabilidad, que no implica robar el nombre de un editor oficial, sino reutilizar el nombre de una extensión no oficial que ha sido eliminada.   
• Lista de Bloqueo (Block List): Si se verifica que una extensión es maliciosa, se elimina del marketplace y se agrega a una lista de bloqueo. VS Code puede desinstalar automáticamente las extensiones que están en esta lista de las máquinas de los usuarios. Si bien esta es una medida de respuesta a incidentes crucial, no aborda el problema de la prevención. Si la extensión fue “eliminada” en lugar de simplemente bloqueada, su nombre queda disponible para ser reutilizado, iniciando el ciclo de ataque de nuevo.   
• Editores Verificados: El programa de editores verificados (indicado por una marca de verificación azul) proporciona una señal de confianza al confirmar la identidad de un editor a través de la propiedad del dominio. Sin embargo, no impide que un editor no verificado secuestre el nombre de una extensión eliminada que pertenecía a otro editor (verificado o no). La confianza se asocia con el nombre de la extensión tanto como con el editor, y la política actual permite que esta confianza sea explotada.   

El análisis de esta vulnerabilidad revela una desconexión fundamental en el modelo de amenaza del marketplace. La política de “eliminar” trata los nombres de las extensiones como recursos transitorios y reutilizables, similar a cómo un sistema operativo podría liberar memoria.

Sin embargo, en un ecosistema social como un marketplace, un nombre no es solo un puntero; es un activo que acumula reputación y confianza. Al permitir que este activo sea transferido a un actor no relacionado y potencialmente malicioso sin ningún tipo de control o advertencia, la política crea un riesgo sistémico.

La vulnerabilidad no es, por lo tanto, un simple descuido, sino el resultado de una decisión de diseño de políticas que prioriza la limpieza del espacio de nombres sobre la seguridad y la no repudiación de la identidad.

Estudio de Caso: La Campaña de Ransomware “Shiba”

La explotación de la vulnerabilidad de reutilización de nombres en el VS Code Marketplace no fue un ejercicio teórico. Fue puesta en práctica por una campaña de malware activa, aunque en una etapa de desarrollo temprano, denominada “Shiba”. El análisis de esta campaña proporciona una visión concreta de cómo los actores de amenazas pueden convertir una falla de política en un arma para distribuir código malicioso, sentando las bases para ataques más sofisticados.

Cronología del Ataque y Variantes

La campaña “Shiba” demostró un patrón de desarrollo iterativo y persistencia por parte del actor de amenazas. La actividad se manifestó a través de varias extensiones publicadas a lo largo de varios meses :   

• ahban.cychelloworld: Esta extensión fue la primera en aparecer, subida al marketplace el 27 de octubre de 2024. Inicialmente, la primera versión no contenía la carga útil maliciosa. El código de ransomware se introdujo en la versión 0.0.2, publicada el 24 de noviembre de 2024.   
• ahban.shiba: Una segunda variante fue publicada el 17 de febrero de 2025, utilizando un editor diferente pero una carga útil similar.   
• ahbanC.shiba: Esta fue la variante que finalmente llevó a ReversingLabs a descubrir la vulnerabilidad subyacente. El nombre de la extensión era prácticamente idéntico al de ahban.shiba, pero fue publicado por un editor diferente. Esta repetición del nombre de la extensión fue la anomalía que desencadenó una investigación más profunda.   

La existencia de estas tres bibliotecas, todas con una funcionalidad similar y nombres casi idénticos, sugiere que el actor de amenazas estaba probando y refinando constantemente su enfoque, probablemente explorando la eficacia de la distribución a través del marketplace y la evasión de las defensas existentes.

Análisis Técnico del Malware

El malware “Shiba” operaba a través de un ataque de múltiples etapas, una técnica común para evadir la detección y aumentar la flexibilidad. La cadena de ataque se puede desglosar de la siguiente manera:

1. Etapa 1: Carga Útil del Descargador (Downloader): La extensión de VS Code en sí misma no contenía el ransomware completo. Su función principal era actuar como un simple descargador. Una vez instalada y activada, la extensión ejecutaba un comando, como shiba.aowoo, diseñado para contactar un servidor remoto y recuperar la siguiente etapa de la carga útil. Este enfoque permite al atacante cambiar la carga útil final sin tener que volver a publicar la extensión en el marketplace.   
2. Etapa 2: Ejecución de PowerShell: La carga útil descargada del servidor remoto era un script de PowerShell. PowerShell es una herramienta de ataque preferida debido a su poder, su presencia nativa en los sistemas Windows y su capacidad para ejecutar operaciones en memoria (“fileless”), lo que puede dificultar la detección por parte de soluciones antivirus tradicionales.   
3. Etapa 3: Funcionalidad de Ransomware Naciente: El script de PowerShell contenía la lógica del ransomware, pero su implementación indica que estaba en una fase experimental o de prueba. En lugar de cifrar todo el sistema de archivos del usuario, su objetivo era muy específico: buscaba y cifraba archivos únicamente dentro de una carpeta llamada C:\users\%username%\Desktop\testShiba. Este comportamiento sugiere que el atacante estaba probando su código de cifrado en un entorno controlado antes de desplegarlo a una escala más destructiva.   
4. Nota de Rescate y Pago: Después de completar el proceso de cifrado, el malware mostraba una notificación de Windows con el siguiente mensaje: “Tus archivos han sido cifrados. Paga 1 ShibaCoin a ShibaWallet para recuperarlos”. Sin embargo, la nota de rescate era fundamentalmente defectuosa desde la perspectiva del atacante: no proporcionaba una dirección de billetera de criptomonedas real ni instrucciones detalladas sobre cómo realizar el pago. Esta omisión refuerza la conclusión de que la campaña era un trabajo en progreso, posiblemente un prototipo para futuras operaciones de ransomware.   

A continuación se presenta una tabla que resume los Indicadores de Compromiso (IOCs) clave asociados con la campaña “Shiba”, proporcionando a los equipos de seguridad información procesable para la detección y respuesta.

El Ecosistema Más Amplio: Un Análisis Comparativo de las Posturas de Seguridad de los Repositorios

La vulnerabilidad de reutilización de nombres en el VS Code Marketplace no es un fenómeno aislado, sino un síntoma de los desafíos de gobernanza más amplios que enfrentan los ecosistemas de software de código abierto.

La postura de seguridad de un repositorio de paquetes es un reflejo directo de su filosofía de gobernanza, su madurez y las lecciones aprendidas de incidentes de seguridad pasados.

Un análisis comparativo de las políticas del VS Code Marketplace, el Python Package Index (PyPI) y el npm Registry revela diferencias significativas en la forma en que cada plataforma gestiona el ciclo de vida de los nombres de los paquetes, lo que resulta en niveles de riesgo muy diferentes para sus respectivos usuarios.

Python Package Index (PyPI): Un Modelo Más Maduro

PyPI, como uno de los repositorios de paquetes más antiguos y grandes, ha desarrollado un conjunto de políticas que demuestran una mayor conciencia de las tácticas adversarias. Si bien su política sobre la reutilización de nombres no es perfecta, contiene una salvaguarda crítica que está ausente en VS Code.

La política de PyPI establece que cuando un proyecto es eliminado, su nombre queda disponible para que cualquier otro usuario lo registre. A primera vista, esto parece similar a la política de VS Code y presenta un riesgo de secuestro de nombres, como lo demostraron los investigadores de JFrog, quienes identificaron miles de paquetes con potencial de secuestro y observaron un caso real con el paquete    pingdomv3.   

Sin embargo, PyPI ha instituido una excepción crucial: los administradores de PyPI se reservan el derecho de hacer que los nombres de los paquetes no estén disponibles permanentemente si se determina que fueron utilizados por primera vez para distribuir malware. Esta política es una medida de seguridad proactiva y específica.

Reconoce que los nombres asociados con malware son “tóxicos” y no deben ser reciclados, ya que podrían engañar a los usuarios o ser reutilizados por el mismo actor de amenazas u otros.

Además, PyPI ha implementado reglas estrictas sobre la inmutabilidad de las versiones de los paquetes; una vez que un archivo con un nombre y una versión específicos se ha subido, ese mismo nombre de archivo no se puede volver a subir, incluso si se elimina. Esto evita que los atacantes reemplacen una versión legítima por una maliciosa sin cambiar el número de versión.   

La existencia de estas políticas más estrictas no es accidental. Es el resultado de años de lidiar con una multitud de ataques a la cadena de suministro, desde typosquatting hasta la toma de control de cuentas de mantenedores.

La postura de PyPI refleja una “cicatriz” institucional, donde las lecciones aprendidas de incidentes pasados se han codificado en políticas de gobernanza más sólidas para proteger el ecosistema.  

npm Registry: Enfoque en Disputas y “Squatting”

El npm Registry, el repositorio de paquetes más grande del mundo, ha centrado gran parte de sus políticas de nomenclatura en la prevención del typosquatting y la resolución de disputas de nombres a través de un proceso formal. Las directrices de npm prohíben explícitamente el “squatting”, que se define como registrar un nombre de paquete con el único propósito de reservarlo para uso futuro sin publicar código funcional.   

En cuanto a la eliminación, la historia de npm está marcada por el infame incidente de left-pad en 2016, donde la eliminación de un paquete trivial pero ampliamente utilizado rompió miles de compilaciones en todo el mundo. Como resultado, las políticas sobre la anulación de la publicación (unpublish) se han vuelto más estrictas.

La documentación de npm indica que “incluso si se anula la publicación de una versión de un paquete, esa combinación específica de nombre y versión nunca se puede reutilizar”.   

Sin embargo, el enfoque principal aquí está en la inmutabilidad de la versión. Las políticas son menos explícitas y más complejas en lo que respecta al ciclo de vida completo del nombre del paquete después de que todas sus versiones han sido eliminadas.

Si bien la intención es prevenir la interrupción y el secuestro, el enfoque principal ha sido la resolución de conflictos y la prevención del typosquatting, en lugar de una política proactiva de retirada de nombres maliciosos como la de PyPI.

Implicaciones de las Diferencias de Políticas

La postura de seguridad de un repositorio no puede evaluarse únicamente por sus capacidades de escaneo de malware, sino que debe incluir un análisis de sus políticas de gobernanza fundamentales. La vulnerabilidad de reutilización de nombres en VS Code es un ejemplo claro de cómo una política permisiva puede crear un riesgo sistémico.

La ausencia de una excepción para nombres maliciosos, como la que tiene PyPI, indica una falta de madurez en el modelo de amenaza del marketplace.

El estado actual de las políticas de ciclo de vida de los repositorios puede considerarse un indicador de su madurez en seguridad. PyPI, habiendo sido un objetivo principal durante más tiempo, ha desarrollado políticas más endurecidas en respuesta a TTPs (Tácticas, Técnicas y Procedimientos) adversarios observados en el mundo real.

El VS Code Marketplace, al ser un ecosistema más joven y curado por una única corporación, parece tener políticas más centradas en la conveniencia del desarrollador y la gestión de la plataforma que en un modelo de amenaza adversarial robusto.

La vulnerabilidad de reutilización de nombres no fue una sorpresa para los investigadores familiarizados con los patrones de ataque en otros ecosistemas; fue una falla predecible en una plataforma que aún no ha incorporado las duras lecciones aprendidas por sus predecesores.

Inmersión Profunda en el Vector de Ataque: Typosquatting, Brandjacking y Confusión de Dependencias

La vulnerabilidad de reutilización de nombres en el VS Code Marketplace no existe en el vacío.

Es una manifestación de una clase más amplia y persistente de ataques a la cadena de suministro de software conocidos colectivamente como ataques de confusión de nombres.

Estos ataques explotan la psicología humana, los errores tipográficos y las complejidades de los sistemas de gestión de paquetes para engañar a los desarrolladores y a las herramientas de compilación automatizadas para que consuman código malicioso. Comprender este contexto es crucial para apreciar la gravedad de la falla del marketplace.

Definición de las Clases de Ataque

Los ataques de confusión de nombres se pueden clasificar en varias categorías distintas, cada una con su propio mecanismo de engaño:

• Typosquatting: Esta es la forma más común de ataque. Los adversarios publican paquetes maliciosos con nombres que son errores tipográficos comunes de paquetes legítimos y populares. El objetivo es atrapar a los desarrolladores que escriben mal un nombre de paquete durante la instalación. Los ejemplos incluyen omisiones de letras (requests vs. reqests), repeticiones (jquery vs. jquerry) o transposiciones (electron vs. electorn). El ataque al paquete  colorama de PyPI con un paquete malicioso llamado colourama es un caso clásico.   
• Brandjacking: En este ataque, un actor de amenazas toma el nombre de un paquete popular y de confianza de un ecosistema de lenguaje (por ejemplo, Python) y publica un paquete malicioso con el mismo nombre en un ecosistema diferente (por ejemplo, Rust). El atacante se aprovecha del reconocimiento de la marca, esperando que un desarrollador que se mueva entre ecosistemas confíe en el nombre familiar sin una investigación adecuada.   
• Combosquatting: Esta técnica implica combinar el nombre de un paquete popular con palabras clave que sugieren una funcionalidad mejorada o específica, como “api”, “security” o “tools” (por ejemplo, axios-api). Esto puede engañar a los desarrolladores para que piensen que están instalando un complemento oficial o una herramienta de ayuda.   
• Confusión de Dependencias (Dependency Confusion): Este ataque, más dirigido, explota la forma en que los gestores de paquetes resuelven las dependencias. Un atacante identifica el nombre de un paquete privado o interno utilizado dentro de una organización. Luego, publica un paquete malicioso con el mismo nombre en un repositorio público (como npm o PyPI). Si el sistema de compilación de la organización no está configurado correctamente para priorizar el repositorio privado, puede “confundirse” y descargar la versión pública maliciosa, especialmente si esta tiene un número de versión más alto.   

Conectando la Reutilización de Nombres con el Panorama General de Amenazas

La vulnerabilidad de reutilización de nombres descubierta en el VS Code Marketplace puede considerarse una variante particularmente potente y sigilosa de estos ataques de confusión de nombres.

A diferencia del typosquatting, que se basa en un error del usuario, la reutilización de nombres explota la confianza establecida y la memoria institucional.

El peligro radica en que el nombre secuestrado no es una imitación; es el nombre exacto de un paquete que pudo haber sido legítimo, popular y de confianza en el pasado.

Considere los siguientes escenarios:

1. Scripts de Automatización y Tutoriales: Un desarrollador puede tener un script de instalación o seguir un tutorial en línea que hace referencia a una extensión por su nombre legítimo. Si esa extensión es eliminada y su nombre es secuestrado, el script o el tutorial ahora apuntan directamente a la versión maliciosa. No hay ningún error tipográfico que detectar.
2. Sistemas de CI/CD (Integración Continua/Entrega Continua): Las canalizaciones de CI/CD a menudo están configuradas para instalar un conjunto específico de herramientas y extensiones en los entornos de compilación. Si una de estas extensiones es eliminada y su nombre es reutilizado, la canalización de CI/CD comenzará a instalar automáticamente la versión maliciosa en cada ejecución, comprometiendo potencialmente el entorno de compilación, las credenciales y el software que se está produciendo.   
3. Confianza del Desarrollador: Un desarrollador que usó una extensión en el pasado puede buscarla por su nombre para reinstalarla en una nueva máquina. Al encontrar una extensión con el nombre y el icono esperados, es mucho menos probable que investigue al editor o el código fuente, asumiendo que es el mismo paquete que recuerda.

Esta técnica es más insidiosa que el typosquatting porque el indicador principal de un ataque—un nombre mal escrito—está ausente.

La carga de la detección se traslada por completo al desarrollador, quien ahora debe verificar no solo el nombre, sino también la identidad del editor y compararla con un estado previamente conocido, una tarea que es poco práctica a escala.

El ataque al paquete cross-env de npm, que exfiltraba variables de entorno, demostró cuán efectivo puede ser un nombre casi idéntico. La reutilización de un nombre exacto elimina incluso esa pequeña diferencia, haciendo que la detección manual sea casi imposible sin un escrutinio forense.   

La Ofuscación de Múltiples Capas de los Ladrones de Información de npm

Si la campaña “Shiba” representa una amenaza en desarrollo, un conjunto de paquetes maliciosos descubiertos en el registro de npm por el equipo de investigación de seguridad de JFrog ilustra el extremo superior de la sofisticación en los ataques a la cadena de suministro.

Esta campaña no solo utilizó tácticas de confusión de nombres para su distribución inicial, sino que también empleó una técnica de ofuscación de 70 capas para ocultar su carga útil final: un potente ladrón de información dirigido al navegador Google Chrome.

Descripción General de la Campaña

La campaña involucró al menos ocho paquetes maliciosos de npm, publicados por los usuarios ruer y npjun. Los nombres de los paquetes fueron diseñados para imitar bibliotecas legítimas de React y Solana, utilizando técnicas de typosquatting y combosquatting para atraer a los desarrolladores. Los paquetes incluían toolkdvv, react-sxt, react-sdk-solana, react-typex, react-typexs, react-native-control, revshare-sdk-api y revshare-sdk-apii.   

El objetivo final de cada uno de estos paquetes era el mismo: desplegar un ladrón de información altamente capaz en los sistemas Windows de las víctimas, con el objetivo de exfiltrar datos sensibles directamente del navegador Google Chrome.

Deconstrucción de la Ofuscación de 70 Capas

La característica más notable de esta campaña fue el uso extremo de la ofuscación para evadir la detección por parte de herramientas de análisis estático y de los propios investigadores de seguridad. La cadena de ataque se desarrolló a través de múltiples etapas, cada una desenvolviendo la siguiente como una muñeca rusa.

1. Etapa Inicial (JavaScript): El ataque comenzaba con un archivo JavaScript (src/react.js) dentro del paquete de npm. Este script inicial estaba ofuscado utilizando una técnica similar a la de obfuscator.io para ocultar su verdadera intención. Una vez desofuscado, el propósito del script era claro: preparar el terreno para una carga útil de Python.
2. Sus acciones incluían:   
   • Terminar cualquier proceso de Python en ejecución.
   • Verificar si Python estaba instalado en la máquina. Si no lo estaba, descargaba e instalaba silenciosamente una versión específica desde los lanzamientos oficiales de Python.
   • Instalar las bibliotecas de Python necesarias, como pycryptodome y requests, utilizando pip.
   • Finalmente, escribía un script de Python ofuscado en un archivo temporal y lo ejecutaba silenciosamente utilizando múltiples métodos de evasión (WMI, ActiveXObject, PowerShell, Tareas Programadas) para asegurar la ejecución.   
3. Ofuscación de Python de Múltiples Capas: La verdadera complejidad residía en la carga útil de Python.
   • Primera Capa (64 iteraciones): El código estaba oculto dentro de una función lambda anónima que se llamaba a sí misma recursivamente. En cada llamada, la carga útil se desenvolvía realizando tres operaciones: revertir el orden de una cadena de caracteres, decodificarla desde Base64 y descomprimirla utilizando zlib. Este proceso se repetía 64 veces, creando una barrera formidable para el análisis manual.   
   • Segunda Capa: Después de las 64 iteraciones, emergía una técnica de ofuscación diferente. Esta capa utilizaba bytes sin procesar para ocultar cadenas y empleaba la inversión de segmentos (slice reversing) para ocultar la lógica. La desofuscación de esta capa reveló un código Python serializado (marshalled) que había sido comprimido dos veces con bz2, con los bytes en orden inverso en cada etapa de descompresión.   
   • Capas Posteriores: Las capas subsiguientes continuaron utilizando variaciones de estas técnicas, totalizando 70 capas de ofuscación. Este nivel de complejidad no solo está diseñado para derrotar a los escáneres automatizados, sino también para agotar el tiempo y los recursos de los analistas de seguridad humanos.

Carga Útil Final: Funcionalidad del Ladrón de Información de Chrome

Después de navegar por el laberinto de la ofuscación, la carga útil final reveló ser un ladrón de información altamente especializado y peligroso, con capacidades extensas para robar datos del navegador Chrome.   

• Robo de Datos:
  • Credenciales: Extraía contraseñas guardadas.
  • Finanzas: Recopilaba datos de tarjetas de crédito almacenadas.
  • Sesiones: Robaba cookies de sesión, lo que podría permitir a los atacantes secuestrar sesiones de usuario activas en varios sitios web.
  • Criptomonedas: Se dirigía específicamente a los datos de las billeteras de criptomonedas almacenadas por extensiones populares, incluyendo MetaMask (nkbihfbeogaeaoehlefnkodbefgpgknn), Phantom (bfnaelmomeimhlpmgjnjophhpkkoljpa), Trust Wallet (egjidjbpglichdcondbcbdnbeeppgdph) y Solflare (bhhhlbepdkbapadjdnnojkbgioiodbic).
• Técnicas de Evasión: El malware empleaba técnicas avanzadas para acceder a los archivos de datos de Chrome, que a menudo están bloqueados mientras el navegador está en funcionamiento. Utilizaba un bypass de “shadow copy” y la suplantación de LSASS para acceder y descifrar las claves de Chrome.   
• Exfiltración de Datos: Los datos robados se empaquetaban y se exfiltraban a servidores remotos alojados en la plataforma railway.app. La carga útil también incluía un webhook de Discord como mecanismo de exfiltración de respaldo, aunque no se observó que se utilizara en la campaña analizada.   

La siguiente tabla resume los Indicadores de Compromiso (IOCs) asociados con esta sofisticada campaña, proporcionando a los equipos de seguridad los datos necesarios para la detección y la caza de amenazas.

  Una Falla de Gobernanza: Análisis de las Políticas de Plataforma sobre el Ciclo de Vida de los Paquetes

Los incidentes analizados, desde la reutilización de nombres en VS Code hasta la ofuscación extrema en npm, no son simplemente una colección de ataques aislados. Son manifestaciones de una falla sistémica más profunda en la gobernanza de los repositorios de software de código abierto.

La falta de políticas estandarizadas, coherentes y centradas en la seguridad para todo el ciclo de vida de un paquete—desde su publicación y mantenimiento hasta su eliminación y el destino de su nombre—crea un entorno inherentemente riesgoso.

Esta ambigüedad e inconsistencia entre plataformas obliga a los desarrolladores y a las organizaciones a navegar por un panorama de amenazas complejo sin un marco de confianza claro, convirtiendo a los repositorios en uno de los principales puntos de entrada para los ataques a la cadena de suministro.

La raíz del problema es que muchas políticas de los repositorios parecen haber sido diseñadas con un enfoque en la funcionalidad, la conveniencia del desarrollador y la gestión del espacio de nombres, en lugar de un modelo de amenaza adversarial robusto. La capacidad de “eliminar” completamente una extensión en VS Code y liberar su nombre es un ejemplo perfecto.

Esta característica puede haber sido concebida para permitir a los desarrolladores desvincularse por completo de un proyecto o para mantener el espacio de nombres limpio. Sin embargo, no tuvo en cuenta el valor de la “reputación” como un activo de seguridad.

Un nombre de paquete no es solo una cadena de caracteres; es un identificador al que los usuarios asocian confianza con el tiempo. Permitir que esa confianza sea transferida a un actor desconocido y potencialmente malicioso es un fallo de diseño de políticas.

Esta falla se vuelve aún más evidente cuando se compara con las políticas de otras plataformas importantes. La siguiente tabla ofrece una comparación directa de las políticas de reutilización de nombres de paquetes en el VS Code Marketplace, PyPI y npm, destacando las diferencias críticas en sus posturas de seguridad.

Como muestra la tabla, existe una clara jerarquía en la madurez de la seguridad. PyPI se destaca por su política proactiva, que reconoce que ciertos identificadores están permanentemente comprometidos y deben ser retirados de la circulación.

Esta es una lección fundamental en la gestión de identidades digitales que el VS Code Marketplace aún no ha implementado. La postura de VS Code, al tratar todos los nombres eliminados por igual, independientemente de su historial, crea un riesgo innecesario y significativo.

Esta falta de gobernanza estandarizada coloca una carga desproporcionada sobre el consumidor final. Se espera que los desarrolladores no solo evalúen el código de un paquete, sino que también comprendan y naveguen por las sutiles y a menudo mal documentadas políticas de ciclo de vida de cada repositorio que utilizan.

Esta es una expectativa poco realista y una receta para el fracaso a escala. Sin políticas de plataforma sólidas y seguras por defecto, los ataques a la cadena de suministro seguirán proliferando, explotando las grietas en la gobernanza de los ecosistemas de los que depende la industria del software.

El Imperativo de la Responsabilidad Compartida: Un Marco para Asegurar la Cadena de Suministro de Software

La seguridad de la cadena de suministro de software no puede ser responsabilidad de una sola entidad. La naturaleza interconectada y distribuida del desarrollo de software moderno, que depende en gran medida de componentes de código abierto, exige un modelo de Responsabilidad Compartida. Este modelo, similar al utilizado en la seguridad de la computación en la nube, distribuye las obligaciones de seguridad entre todos los participantes del ecosistema. Cada actor, desde los propietarios de las plataformas hasta los desarrolladores individuales, tiene un papel distinto y crucial que desempeñar para fortalecer las defensas colectivas contra las amenazas.  

Propietarios de Plataformas (por ejemplo, Microsoft, GitHub/npm, Python Software Foundation)

Los propietarios de los repositorios de paquetes actúan como los guardianes del ecosistema y tienen la mayor capacidad para implementar cambios a escala. Sus responsabilidades son fundamentales para establecer una base de seguridad.

• Establecer Políticas Seguras por Defecto: Deben diseñar e implementar políticas de ciclo de vida de paquetes que prioricen la seguridad sobre la conveniencia. Esto incluye la adopción de políticas como la de PyPI de retirar permanentemente los nombres asociados con malware, hacer que la autenticación de dos factores (2FA) sea obligatoria para los mantenedores de paquetes populares y tener procesos de disputa de nombres claros y transparentes.   
• Invertir en Detección y Prevención Robustas: Las plataformas deben ir más allá del escaneo básico de malware. Deben invertir en análisis estáticos y dinámicos avanzados capaces de detectar técnicas de ofuscación sofisticadas y comportamientos sospechosos antes de que un paquete sea publicado. La integración de la inteligencia de amenazas en estos sistemas es crucial.   
• Fomentar la Transparencia y la Confianza: Deben proporcionar a los usuarios un historial claro y auditable de los paquetes y los nombres de los paquetes. Esto incluye información sobre la propiedad, las transferencias y las eliminaciones. Las insignias de “editor verificado” son un buen comienzo, pero se necesita más granularidad para construir una cadena de confianza sólida.   
• Colaborar con la Comunidad de Seguridad: Deben establecer canales claros y receptivos para que los investigadores de seguridad informen sobre vulnerabilidades (tanto en la plataforma como en los paquetes que aloja) y seguir las mejores prácticas de divulgación coordinada de vulnerabilidades (CVD).   

Mantenedores de Paquetes

Los desarrolladores que crean y mantienen el software de código abierto del que todos dependemos son una parte vital de la cadena de suministro.

• Asegurar sus Cuentas y Entornos de Desarrollo: La toma de control de la cuenta de un mantenedor es un vector de ataque común. Es su responsabilidad utilizar contraseñas seguras y, lo que es más importante, habilitar la 2FA en sus cuentas de repositorio. También deben seguir prácticas de desarrollo seguras en sus propios entornos.   
• Gestionar las Dependencias de Forma Responsable: Los mantenedores deben investigar y monitorear las dependencias que utilizan en sus propios proyectos, ya que una vulnerabilidad en una dependencia transitiva puede comprometer su paquete.
• Responder a las Divulgaciones de Vulnerabilidades: Deben tener un proceso claro para recibir informes de seguridad y deben responder de manera oportuna para corregir las vulnerabilidades y notificar a sus usuarios.

Investigadores de Seguridad

La comunidad de investigación de seguridad actúa como el sistema inmunológico del ecosistema de código abierto, identificando debilidades antes de que puedan ser explotadas a gran escala.

• Descubrimiento Proactivo de Amenazas: Su función es buscar activamente vulnerabilidades en las plataformas, paquetes y las tácticas utilizadas por los actores de amenazas.
• Divulgación Responsable: Deben seguir las normas de Divulgación Coordinada de Vulnerabilidades (CVD), notificando de forma privada a los propietarios de la plataforma o a los mantenedores y dándoles un tiempo razonable para solucionar el problema antes de la divulgación pública. Esto equilibra la necesidad de informar al público con el riesgo de armar a los atacantes.   

Consumidores (Desarrolladores y Organizaciones)

En última instancia, la organización que construye e implementa el software es responsable de los componentes que elige incluir. No pueden delegar completamente la seguridad a las plataformas o a los mantenedores.

• Investigar Antes de Integrar: Los desarrolladores y las organizaciones tienen la responsabilidad de realizar la debida diligencia en cada componente de terceros. Esto significa no confiar ciegamente en un nombre de paquete, sino investigar al autor, la popularidad, el historial de mantenimiento y las vulnerabilidades conocidas.   
• Implementar Controles Técnicos: Las organizaciones deben implementar defensas técnicas como el uso de repositorios privados o proxy que actúen como una zona de cuarentena, el uso de herramientas de Análisis de Composición de Software (SCA) para escanear dependencias y la aplicación de políticas de seguridad en sus canalizaciones de CI/CD.   
• Mantener un Inventario y Monitorear Continuamente: Es crucial mantener un inventario preciso de todos los componentes de software y sus dependencias, comúnmente conocido como una Lista de Materiales de Software (SBOM, por sus siglas en inglés). Este inventario permite una rápida evaluación del impacto cuando se descubre una nueva vulnerabilidad y debe ser monitoreado continuamente en busca de nuevas amenazas.   

Solo cuando cada uno de estos grupos asuma plenamente sus responsabilidades, el ecosistema de software de código abierto podrá pasar de un estado reactivo, donde se responde a los ataques a medida que ocurren, a una postura proactiva y resistente, donde las defensas colectivas hacen que los ataques a la cadena de suministro sean significativamente más difíciles y costosos de ejecutar.

Recomendaciones Estratégicas para la Mitigación y la Resiliencia

Para abordar eficazmente las amenazas a la cadena de suministro de software, como la vulnerabilidad de reutilización de nombres en el VS Code Marketplace, se requiere un enfoque de defensa en profundidad.

Las siguientes recomendaciones estratégicas están diseñadas para proporcionar orientación procesable a los diferentes actores dentro del ecosistema de software, desde el desarrollador individual hasta el CISO de la organización y los propietarios de las plataformas.

Para Desarrolladores y Equipos de DevSecOps

Los desarrolladores son la primera línea de defensa. La incorporación de prácticas de seguridad en el flujo de trabajo diario es la forma más eficaz de prevenir la introducción de dependencias maliciosas.

• Adoptar una Mentalidad de Confianza Cero para las Dependencias: Cada paquete, extensión o biblioteca de terceros debe ser tratado como potencialmente no confiable hasta que se verifique. Nunca se debe confiar únicamente en el nombre de un paquete.
• Implementar un Proceso de Investigación Riguroso: Antes de agregar cualquier nueva dependencia a un proyecto, los desarrolladores deben realizar un proceso de investigación utilizando una lista de verificación estandarizada.
• Integrar Herramientas de Seguridad Automatizadas en la Canalización de CI/CD: La seguridad no debe ser un paso manual y esporádico. Herramientas como el Análisis de Composición de Software (SCA), el Análisis Estático de Seguridad de Aplicaciones (SAST) y el Análisis Dinámico de Seguridad de Aplicaciones (DAST) deben integrarse en la canalización de CI/CD. Estas herramientas pueden escanear continuamente las dependencias en busca de vulnerabilidades conocidas, problemas de licencia y comportamientos sospechosos.   
• Utilizar Banderas de Instalación Seguras: Al instalar paquetes de npm, se debe utilizar la bandera --ignore-scripts. Esta bandera evita la ejecución automática de scripts de preinstalación y postinstalación, que son un vector de ataque común utilizado por los paquetes maliciosos para ejecutar código arbitrario en la máquina del desarrollador o en el servidor de compilación.   
• Fijar las Versiones de las Dependencias (Pinning): Se deben utilizar archivos de bloqueo (como package-lock.json en npm o poetry.lock en Python) para fijar las versiones exactas de todas las dependencias, incluidas las transitivas. Esto evita que el gestor de paquetes descargue automáticamente una versión más nueva (y potencialmente maliciosa) de una dependencia sin una acción explícita.

La siguiente tabla proporciona una lista de verificación práctica que los desarrolladores pueden utilizar para evaluar las dependencias de terceros.

  Para Organizaciones y los CISO

La seguridad de la cadena de suministro debe ser una prioridad estratégica a nivel organizacional, respaldada por políticas y controles técnicos.

• Establecer una Lista de Permitidos (Allowlist) a Nivel Empresarial: En lugar de permitir que los desarrolladores instalen cualquier paquete o extensión, las organizaciones deben mantener una lista centralizada de componentes de terceros aprobados y examinados. VS Code y otros entornos de desarrollo ofrecen mecanismos de políticas para hacer cumplir estas listas de permitidos, como la política AllowedExtensions.   
• Exigir el Uso de un Repositorio Privado/Proxy: Se debe exigir a todos los equipos de desarrollo que obtengan sus dependencias a través de un repositorio interno (como Sonatype Nexus o JFrog Artifactory). Este repositorio actúa como un caché y una puerta de seguridad, almacenando solo las versiones aprobadas de los paquetes públicos. Esto evita que los desarrolladores y los sistemas de compilación se conecten directamente a los repositorios públicos y proporciona un único punto de control para el escaneo y la auditoría.   
• Promover la Lista de Materiales de Software (SBOM): Las organizaciones deben exigir la generación de un SBOM para cada aplicación que construyan. Un SBOM es un inventario detallado de todos los componentes de software, bibliotecas y sus dependencias. Este inventario es invaluable para la gestión de vulnerabilidades, el cumplimiento de licencias y, lo que es más importante, para una rápida evaluación del impacto cuando se revela una nueva vulnerabilidad en un componente de código abierto.   
• Desarrollar un Plan de Respuesta a Incidentes para Ataques a la Cadena de Suministro: Se deben crear manuales de procedimientos (playbooks) específicos para responder a incidentes que involucren dependencias comprometidas. Estos planes deben incluir pasos para la identificación (utilizando el SBOM), la contención (aislando los sistemas afectados), la erradicación (eliminando el componente malicioso y rotando las credenciales comprometidas) y la recuperación.

Para Propietarios de Plataformas

Los propietarios de los repositorios tienen la responsabilidad de crear un entorno seguro para sus usuarios.

• Reformar las Políticas de Ciclo de Vida de los Nombres: La laguna de reutilización de nombres en el VS Code Marketplace debe cerrarse de inmediato. Las plataformas deben adoptar el modelo de PyPI de retirar permanentemente los nombres de los paquetes que se haya confirmado que son maliciosos. La seguridad del ecosistema debe tener prioridad sobre la limpieza del espacio de nombres.
• Mejorar la Detección Automatizada: Se debe invertir en capacidades de análisis estático y dinámico más sofisticadas. Estas herramientas deben estar diseñadas para detectar las técnicas de ofuscación avanzadas y los comportamientos sospechosos (como los observados en los ladrones de información de npm) antes de que un paquete se publique.
• Aumentar la Transparencia: Los usuarios deben tener acceso a un historial claro y auditable para cada nombre de paquete. Esto debería incluir cuándo se creó, por quién, si alguna vez fue eliminado o transferido, y su historial de seguridad. Esta transparencia ayuda a los desarrolladores a tomar decisiones informadas.
• Reforzar la Verificación de la Identidad del Editor: Los procesos para verificar la identidad de un editor deben ser más estrictos. Esto ayuda a construir una cadena de confianza más fuerte y dificulta que los actores de amenazas publiquen paquetes bajo una apariencia de legitimidad.

 

Por Marcelo Lozano – General Publisher IT CONNECT LATAM

Lea más sobre Ciberseguridad en:

• Empresas Argentinas 2025 Protegen su Seguridad
• Campo de Batalla Algorítmico: La guerra superior 2025
• Red Team 2025: cuando pensar como el enemigo, es seguridad
• Zero Trust: Evaluando las Brechas de Seguridad 2025
• PFA, GNA, PNA y otras policías en riesgo impactante en 2025

vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, 

vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code, vs code,