VS Code<\/figcaption><\/figure>\nInvestigadores de ciberseguridad han identificado una vulnerabilidad cr\u00edtica en la gobernanza de pol\u00edticas del Visual Studio Code (VS Code) Marketplace, que permite a los actores de amenazas reutilizar los nombres de extensiones previamente eliminadas.<\/p>\n
Este informe proporciona un an\u00e1lisis exhaustivo de esta falla, su explotaci\u00f3n en el mundo real y su contexto dentro del panorama m\u00e1s amplio de los riesgos de la cadena de suministro de software.<\/p>\n
El descubrimiento, realizado por la firma de seguridad ReversingLabs, expone una brecha significativa entre las pr\u00e1cticas de seguridad declaradas por Microsoft y la realidad operativa de su marketplace, permitiendo ataques de suplantaci\u00f3n de identidad altamente efectivos.<\/p>\n
La vulnerabilidad se origina en una distinci\u00f3n de pol\u00edtica entre “anular la publicaci\u00f3n” y “eliminar” una extensi\u00f3n. Mientras que la primera opci\u00f3n reserva el nombre, la segunda lo libera para que cualquier otro editor lo reclame.<\/p>\n
Esta laguna fue explotada por la campa\u00f1a de ransomware en desarrollo “Shiba”, que utiliz\u00f3 nombres de extensiones id\u00e9nticos bajo diferentes editores para distribuir cargas \u00fatiles maliciosas. Este incidente subraya c\u00f3mo una falla de pol\u00edtica, en lugar de un error de c\u00f3digo tradicional, puede crear un vector de ataque potente y sigiloso.<\/p>\n
Un an\u00e1lisis 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\u00edtica m\u00e1s robusta que proh\u00edbe expl\u00edcitamente la reutilizaci\u00f3n de nombres previamente asociados con paquetes maliciosos, una salvaguarda crucial que est\u00e1 ausente en el VS Code Marketplace.<\/p>\n
El ecosistema de npm, aunque se centra en la prevenci\u00f3n del typosquatting y la resoluci\u00f3n de disputas, tambi\u00e9n presenta complejidades en sus pol\u00edticas de ciclo de vida de paquetes. Estas diferencias ilustran una falta de estandarizaci\u00f3n en las pr\u00e1cticas de seguridad fundamentales en todo el ecosistema de c\u00f3digo abierto.<\/p>\n
La amenaza se ve agravada por la sofisticaci\u00f3n de las campa\u00f1as maliciosas, como se demuestra en un an\u00e1lisis de ocho paquetes maliciosos de npm que utilizaron 70 capas de ofuscaci\u00f3n para desplegar un ladr\u00f3n de informaci\u00f3n del navegador Google Chrome. Esta campa\u00f1a destaca la capacidad de los adversarios para evadir el an\u00e1lisis est\u00e1tico y automatizado, lo que requiere un enfoque de defensa en profundidad.<\/p>\n
La mitigaci\u00f3n de estos riesgos sist\u00e9micos exige la adopci\u00f3n de un modelo de “Responsabilidad Compartida”. Este marco asigna deberes espec\u00edficos a los propietarios de plataformas, los mantenedores de paquetes, los investigadores de seguridad y los consumidores de software (desarrolladores y organizaciones).<\/p>\n
Las recomendaciones clave de este informe incluyen: para los propietarios de plataformas, la reforma de las pol\u00edticas de ciclo de vida de los nombres para priorizar la seguridad; para las organizaciones, la implementaci\u00f3n de controles empresariales como listas de permitidos y el uso de repositorios privados; y para los desarrolladores, la adopci\u00f3n de pr\u00e1cticas de investigaci\u00f3n rigurosas para todas las dependencias de terceros.<\/p>\n
En \u00faltima instancia, la seguridad de la cadena de suministro de software depende de un esfuerzo colaborativo y de la maduraci\u00f3n de las pol\u00edticas de gobernanza en todos los niveles del ecosistema.<\/p>\n
Deconstrucci\u00f3n de la Vulnerabilidad de Secuestro de Nombres en el Visual Studio Code Marketplace<\/h2>\n
La vulnerabilidad que permite el secuestro de nombres en el VS Code Marketplace no es un error de c\u00f3digo convencional, sino una falla fundamental en la pol\u00edtica de gobernanza y el ciclo de vida de las extensiones.<\/p>\n
Su mecanismo se basa en una distinci\u00f3n sutil pero cr\u00edtica en la forma en que el marketplace maneja la eliminaci\u00f3n de extensiones, creando una oportunidad para que los actores de amenazas se apropien de la confianza y la reputaci\u00f3n asociadas con nombres de extensiones previamente existentes.<\/p>\n
La Falla Central: Extensiones “Eliminadas” vs. “No Publicadas”<\/h3>\n
La ra\u00edz de la vulnerabilidad reside en las dos opciones distintas que un editor tiene para retirar una extensi\u00f3n del marketplace, cada una con implicaciones de seguridad dr\u00e1sticamente diferentes.\u00a0 \u00a0<\/span><\/p>\n\n- Anular la Publicaci\u00f3n (Unpublish):<\/b> Cuando un editor anula la publicaci\u00f3n de una extensi\u00f3n, esta se oculta de la vista p\u00fablica en el marketplace. Sin embargo, la plataforma retiene el nombre de la extensi\u00f3n y sus metadatos asociados, como las estad\u00edsticas de descarga. Crucialmente, el nombre permanece vinculado al editor original y no puede ser reclamado por nadie m\u00e1s. Este comportamiento es el esperado para mantener la integridad del espacio de nombres y prevenir la suplantaci\u00f3n de identidad.\u00a0 \u00a0<\/span>\n
\n
<\/div>\n<\/div>\n<\/li>\n
- Eliminar (Remove):<\/b> Por el contrario, cuando una extensi\u00f3n es eliminada por completo, el marketplace la borra de sus registros y, fundamentalmente, libera su nombre. Este nombre vuelve al grupo p\u00fablico de nombres disponibles, lo que permite que cualquier otro editor, leg\u00edtimo o malicioso, lo reclame y publique una nueva extensi\u00f3n bajo esa misma identidad.\u00a0 \u00a0<\/span><\/li>\n<\/ol>\n
Esta dualidad en la pol\u00edtica de eliminaci\u00f3n es el n\u00facleo 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\u00f3n establecida, para luego secuestrar ese nombre y publicar una versi\u00f3n maliciosa.<\/p>\n
ReversingLabs demostr\u00f3 de manera concluyente esta falla al publicar con \u00e9xito extensiones de prueba utilizando nombres que hab\u00edan sido previamente asociados con paquetes maliciosos eliminados, como “Solidity-Ethereum”.<\/p>\n
El problema no es un error que impide que la pol\u00edtica funcione como se dise\u00f1\u00f3; el problema es que la pol\u00edtica fue dise\u00f1ada con una opci\u00f3n inherentemente insegura.\u00a0 \u00a0<\/span><\/p>\nContradicci\u00f3n con la Documentaci\u00f3n Oficial y las Pol\u00edticas de Nomenclatura<\/h3>\n
La existencia de esta laguna contradice directamente el esp\u00edritu, si no la letra, de la propia documentaci\u00f3n de VS Code. La documentaci\u00f3n oficial para desarrolladores de extensiones estipula que el campo <name><\/code> en el manifiesto de la extensi\u00f3n “debe ser exclusivo del Marketplace”. Si bien la unicidad t\u00e9cnica se mantiene a trav\u00e9s del identificador completo de la extensi\u00f3n, que combina el nombre del editor y el nombre de la extensi\u00f3n (<editor>.<nombre><\/code>), la pol\u00edtica de eliminaci\u00f3n permite que el componente <\/span><nombre><\/code>, que es el que ven y buscan los usuarios, sea duplicado por diferentes editores.<\/span><\/p>\nEl caso de las extensiones ahban.shiba<\/code> y ahbanC.shiba<\/code> ejemplifica perfectamente esta contradicci\u00f3n. Ambas compart\u00edan el mismo nombre de extensi\u00f3n, “shiba”, y solo se diferenciaban por el nombre del editor.<\/p>\nPara un desarrollador que busca una extensi\u00f3n, esta distinci\u00f3n puede pasar f\u00e1cilmente desapercibida, especialmente si el nombre del editor malicioso est\u00e1 dise\u00f1ado para parecer leg\u00edtimo o gen\u00e9rico.<\/p>\n
La pol\u00edtica de “eliminar” socava la garant\u00eda de unicidad que la documentaci\u00f3n pretende ofrecer, creando confusi\u00f3n y un vector de ataque directo.\u00a0 \u00a0<\/span><\/p>\nEvaluaci\u00f3n de las Medidas de Seguridad Declaradas por Microsoft<\/h3>\n
Microsoft enumera varias medidas de seguridad para proteger el VS Code Marketplace. Sin embargo, un an\u00e1lisis cr\u00edtico a la luz de esta vulnerabilidad revela que, si bien son \u00fatiles para ciertos tipos de amenazas, son insuficientes para abordar la falla de la reutilizaci\u00f3n de nombres.\u00a0 \u00a0<\/span><\/p>\n\n- An\u00e1lisis de Malware:<\/b> El marketplace realiza an\u00e1lisis de malware en cada paquete de extensi\u00f3n publicado. Sin embargo, esta es una medida reactiva y no infalible. Las extensiones maliciosas de la campa\u00f1a “Shiba” estuvieron disponibles en el marketplace durante per\u00edodos prolongados antes de ser detectadas y eliminadas, lo que indica que el an\u00e1lisis inicial no las marc\u00f3 o que el c\u00f3digo malicioso se introdujo en una actualizaci\u00f3n posterior. Adem\u00e1s, los atacantes utilizan cada vez m\u00e1s t\u00e9cnicas de ofuscaci\u00f3n para evadir estos esc\u00e1neres.\u00a0 \u00a0<\/span>\n
\n
<\/div>\n<\/div>\n<\/li>\n
- Prevenci\u00f3n de “Name Squatting”:<\/b> La pol\u00edtica de Microsoft contra el “name squatting” est\u00e1 dise\u00f1ada 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\u00f3n no oficial que ha sido eliminada.\u00a0 \u00a0<\/span>\n
\n
<\/div>\n<\/div>\n<\/li>\n
- Lista de Bloqueo (Block List):<\/b> Si se verifica que una extensi\u00f3n es maliciosa, se elimina del marketplace y se agrega a una lista de bloqueo. VS Code puede desinstalar autom\u00e1ticamente las extensiones que est\u00e1n en esta lista de las m\u00e1quinas de los usuarios. Si bien esta es una medida de respuesta a incidentes crucial, no aborda el problema de la prevenci\u00f3n. Si la extensi\u00f3n fue “eliminada” en lugar de simplemente bloqueada, su nombre queda disponible para ser reutilizado, iniciando el ciclo de ataque de nuevo.\u00a0 \u00a0<\/span>\n
\n
<\/div>\n<\/div>\n<\/li>\n
- Editores Verificados:<\/b> El programa de editores verificados (indicado por una marca de verificaci\u00f3n azul) proporciona una se\u00f1al de confianza al confirmar la identidad de un editor a trav\u00e9s de la propiedad del dominio. Sin embargo, no impide que un editor no verificado secuestre el nombre de una extensi\u00f3n eliminada que pertenec\u00eda a otro editor (verificado o no). La confianza se asocia con el nombre de la extensi\u00f3n tanto como con el editor, y la pol\u00edtica actual permite que esta confianza sea explotada.\u00a0 \u00a0<\/span>\n
\n
<\/div>\n<\/div>\n<\/li>\n<\/ul>\n
El an\u00e1lisis de esta vulnerabilidad revela una desconexi\u00f3n fundamental en el modelo de amenaza del marketplace. La pol\u00edtica de “eliminar” trata los nombres de las extensiones como recursos transitorios y reutilizables, similar a c\u00f3mo un sistema operativo podr\u00eda liberar memoria.<\/p>\n
Sin embargo, en un ecosistema social como un marketplace, un nombre no es solo un puntero; es un activo que acumula reputaci\u00f3n y confianza. Al permitir que este activo sea transferido a un actor no relacionado y potencialmente malicioso sin ning\u00fan tipo de control o advertencia, la pol\u00edtica crea un riesgo sist\u00e9mico.<\/p>\n
La vulnerabilidad no es, por lo tanto, un simple descuido, sino el resultado de una decisi\u00f3n de dise\u00f1o de pol\u00edticas que prioriza la limpieza del espacio de nombres sobre la seguridad y la no repudiaci\u00f3n de la identidad.<\/p>\n
Estudio de Caso: La Campa\u00f1a de Ransomware “Shiba”<\/h2>\n
La explotaci\u00f3n de la vulnerabilidad de reutilizaci\u00f3n de nombres en el VS Code Marketplace no fue un ejercicio te\u00f3rico. Fue puesta en pr\u00e1ctica por una campa\u00f1a de malware activa, aunque en una etapa de desarrollo temprano, denominada “Shiba”. El an\u00e1lisis de esta campa\u00f1a proporciona una visi\u00f3n concreta de c\u00f3mo los actores de amenazas pueden convertir una falla de pol\u00edtica en un arma para distribuir c\u00f3digo malicioso, sentando las bases para ataques m\u00e1s sofisticados.<\/p>\n
Cronolog\u00eda del Ataque y Variantes<\/h3>\n
La campa\u00f1a “Shiba” demostr\u00f3 un patr\u00f3n de desarrollo iterativo y persistencia por parte del actor de amenazas. La actividad se manifest\u00f3 a trav\u00e9s de varias extensiones publicadas a lo largo de varios meses :\u00a0 \u00a0<\/span><\/p>\n\nahban.cychelloworld<\/code>:<\/b> Esta extensi\u00f3n fue la primera en aparecer, subida al marketplace el 27 de octubre de 2024. Inicialmente, la primera versi\u00f3n no conten\u00eda la carga \u00fatil maliciosa. El c\u00f3digo de ransomware se introdujo en la versi\u00f3n 0.0.2, publicada el 24 de noviembre de 2024.\u00a0 \u00a0<\/span>\n\n
<\/div>\n<\/div>\n<\/li>\n
ahban.shiba<\/code>:<\/b> Una segunda variante fue publicada el 17 de febrero de 2025, utilizando un editor diferente pero una carga \u00fatil similar.\u00a0 \u00a0<\/span>\n\n
<\/div>\n<\/div>\n<\/li>\n
ahbanC.shiba<\/code>:<\/b> Esta fue la variante que finalmente llev\u00f3 a ReversingLabs a descubrir la vulnerabilidad subyacente. El nombre de la extensi\u00f3n era pr\u00e1cticamente id\u00e9ntico al de ahban.shiba<\/code>, pero fue publicado por un editor diferente. Esta repetici\u00f3n del nombre de la extensi\u00f3n fue la anomal\u00eda que desencaden\u00f3 una investigaci\u00f3n m\u00e1s profunda.\u00a0 \u00a0<\/span>\n\n
<\/div>\n<\/div>\n<\/li>\n<\/ul>\n
La existencia de estas tres bibliotecas, todas con una funcionalidad similar y nombres casi id\u00e9nticos, sugiere que el actor de amenazas estaba probando y refinando constantemente su enfoque, probablemente explorando la eficacia de la distribuci\u00f3n a trav\u00e9s del marketplace y la evasi\u00f3n de las defensas existentes.<\/p>\n
An\u00e1lisis T\u00e9cnico del Malware<\/h3>\n
El malware “Shiba” operaba a trav\u00e9s de un ataque de m\u00faltiples etapas, una t\u00e9cnica com\u00fan para evadir la detecci\u00f3n y aumentar la flexibilidad. La cadena de ataque se puede desglosar de la siguiente manera:<\/p>\n
\n- Etapa 1: Carga \u00datil del Descargador (Downloader):<\/b> La extensi\u00f3n de VS Code en s\u00ed misma no conten\u00eda el ransomware completo. Su funci\u00f3n principal era actuar como un simple descargador. Una vez instalada y activada, la extensi\u00f3n ejecutaba un comando, como
shiba.aowoo<\/code>, dise\u00f1ado para contactar un servidor remoto y recuperar la siguiente etapa de la carga \u00fatil. Este enfoque permite al atacante cambiar la carga \u00fatil final sin tener que volver a publicar la extensi\u00f3n en el marketplace.<\/span>\u00a0 \u00a0<\/span>\n\n
<\/div>\n<\/div>\n<\/li>\n
- Etapa 2: Ejecuci\u00f3n de PowerShell:<\/b> La carga \u00fatil 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\u00f3n por parte de soluciones antivirus tradicionales.\u00a0 \u00a0<\/span>\n
\n
<\/div>\n<\/div>\n<\/li>\n
- Etapa 3: Funcionalidad de Ransomware Naciente:<\/b> El script de PowerShell conten\u00eda la l\u00f3gica del ransomware, pero su implementaci\u00f3n 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\u00edfico: buscaba y cifraba archivos \u00fanicamente dentro de una carpeta llamada
C:\\users\\%username%\\Desktop\\testShiba<\/code>. Este comportamiento sugiere que el atacante estaba probando su c\u00f3digo de cifrado en un entorno controlado antes de desplegarlo a una escala m\u00e1s destructiva.\u00a0 \u00a0<\/span>\n\n
<\/div>\n<\/div>\n<\/li>\n
- Nota de Rescate y Pago:<\/b> Despu\u00e9s de completar el proceso de cifrado, el malware mostraba una notificaci\u00f3n 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\u00f3n de billetera de criptomonedas real ni instrucciones detalladas sobre c\u00f3mo realizar el pago. Esta omisi\u00f3n refuerza la conclusi\u00f3n de que la campa\u00f1a era un trabajo en progreso, posiblemente un prototipo para futuras operaciones de ransomware.\u00a0 \u00a0<\/span>\n
\n
<\/div>\n<\/div>\n<\/li>\n<\/ol>\n
A continuaci\u00f3n se presenta una tabla que resume los Indicadores de Compromiso (IOCs) clave asociados con la campa\u00f1a “Shiba”, proporcionando a los equipos de seguridad informaci\u00f3n procesable para la detecci\u00f3n y respuesta.<\/p>\n
![\"VS](\"https:\/\/itconnect.lat\/portal\/wp-content\/uploads\/2025\/08\/tinywow_02_83691950-e1756406935480.webp\" "\\"\\"")
<\/a>