Investigador de seguridad de Snyk publicó paquetes NPM maliciosos dirigidos a Cursor.com

 (sourcecodered.com)
1 puntos por GN⁺ 2025-01-14 | 1 comentarios | Compartir por WhatsApp
  • Varios paquetes publicados en npm incluían scripts de instalación que parecían estar dirigidos a Cursor.com y, al instalarse, enviaban información del sistema a un servicio web externo
  • El publicador era el usuario de npm sn4k-s3c, y usaba nombres que evocaban paquetes internos de Cursor, como cursor-retreival, cursor-always-local y cursor-shadow-workspace
  • La salida de env que toman los paquetes puede incluir variables de entorno sensibles, como claves de AWS, tokens de npm y credenciales de GitHub, por lo que el alcance del daño podría ampliarse
  • El scanner de análisis de paquetes de OpenSSF identificó los paquetes como maliciosos, y OSV generó 3 avisos: MAL-2025-27, MAL-2025-28 y MAL-2025-29
  • En los metadatos de npm, aparecía como publicador un correo de snyk.io de Snyk Security Labs; después, un investigador de Snyk retiró los paquetes y Snyk respondió con una publicación en su blog

Paquetes npm que parecen dirigidos a Cursor

  • Durante el proceso de detección de paquetes maliciosos de SourceCodeRed, se identificaron varios paquetes publicados en npm
  • Los nombres de los paquetes tenían una forma que hacía pensar en paquetes internos relacionados con Cursor
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • El publicador figuraba como el usuario de npm sn4k-s3c
  • Se indicó que la lista de paquetes podía consultarse en https://www.npmjs.com/~sn4k-s3c

Comportamiento al instalarse

  • Al instalar los paquetes, recopilan datos del sistema y los envían a un servicio web controlado por el atacante
  • Según la captura de pantalla, el paquete toma la salida del comando env
  • La salida de env puede incluir variables de entorno sensibles junto con la configuración del sistema
    • Claves de AWS
    • Tokens de npm
    • Credenciales de GitHub
    • Otras variables de entorno sensibles
  • Como resultado, solo con instalarlos, la información del entorno local podría filtrarse al exterior

Posible confusión de dependencias y resultados de detección

  • Este tipo de paquetes se ve con frecuencia en ataques de confusión de dependencias (dependency confusion) dirigidos a una empresa específica
  • No se confirmó si Cursor.com tiene un programa de bug bounty ni el contexto específico
  • SourceCodeRed sospecha que en Cursor podrían existir paquetes privados de npm como cursor-always-local, cursor-retrieval y cursor-shadow-workspace
  • El atacante podría haber esperado que un empleado de Cursor instalara por error el paquete público y enviara datos
  • El scanner de análisis de paquetes de OpenSSF identificó esos paquetes como maliciosos, y OSV generó 3 avisos de malware

Metadatos del publicador

  • En los metadatos de los paquetes npm, el publicador usaba una dirección de correo de snyk.io del equipo de Snyk Security Labs
  • Se indica que esos metadatos de correo del publicador no pueden falsificarse
  • El campo author menciona específicamente a un empleado de Snyk
  • Aunque el campo author sí puede falsificarse, se plantea la presunción de que realmente salió de Snyk porque el publicador tenía un correo verificado de Snyk

Respuesta de usuarios y actualizaciones posteriores

  • SourceCodeRed notificó a npm, pero afirma que en ese momento los paquetes aún no estaban marcados como maliciosos
  • Muchas herramientas de seguridad de la cadena de suministro de software solo pueden bloquear un paquete si saben que es malicioso
  • Se recomienda no instalar paquetes npm a ciegas
  • Esos paquetes contenían solo dos archivos, package.json e index.js o main.js, lo que puede considerarse una señal sospechosa
  • Según una actualización del 15 de enero de 2025, un investigador de Snyk retiró los paquetes relacionados con Cursor al día siguiente de la publicación del blog
  • El 14 de enero de 2025, The Register publicó un artículo relacionado: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • Ese mismo día, Snyk publicó una respuesta en su blog y sostuvo, en esencia, que no habían hecho nada incorrecto: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-14
Comentarios de Hacker News

  • [Corrección: viendo la respuesta del desarrollador de Cursor más abajo, parece que Cursor no lo aprobó] Suena a que Cursor tiene un registro privado de NPM interno donde están esos paquetes y, por cómo funciona NPM, era fácil que un atacante los engañara para que tomaran el mismo paquete desde el registro público
    Probablemente algún empleado de Snyk encontró, o sospechó, que parte del build de Cursor estaba mal configurado de esta forma, y subió el paquete como prueba de concepto. Al ver que la descripción del paquete decía “for Cursor”, pensé que lo habían contratado para eso
    Si es así, no hay mucho que ver; si el punto era mostrar una mala configuración que se salta el registro privado, un investigador de seguridad no habría podido usar un registro privado de NPM para la prueba de concepto
    En particular, muchos proxies eligen el registro público por encima del privado si la versión más reciente del paquete es mayor: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Soy desarrollador de Cursor. Es una suposición razonable, pero la realidad es un poco distinta. Los paquetes de Snyk son solo nombres de extensiones que incluimos en el bundle; nosotros no los empaquetamos ni los subimos a ningún registro
      Los manejamos de la misma forma que VS Code: https://github.com/microsoft/vscode/tree/main/extensions
      No contratamos a Snyk, y cuando los contactamos después de ver esto, recibimos una disculpa. No nos confirmaron exactamente qué intentaban hacer, pero la explicación de que alguien sospechó una vulnerabilidad de confusión de dependencias suena plausible. Aun así, hacer que desde el NPM público realmente se enviaran variables de entorno me parece bastante irresponsable
    • La prueba de concepto pudo haberse hecho sin enviar al exterior información del host donde se instaló ni todas las variables de entorno. Eso parece cruzar una línea
    • Darle a alguien acceso completo a todo mi entorno, es decir, a la salida completa del comando env, sería un gran problema para la mayoría
    • Trabajo en DevRel & SecRel en Snyk. Acabamos de publicar un artículo para aclarar los rumores, y contiene información bastante detallada sobre la situación: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • ¿Esto no debería haberse corregido en NPM? Recuerdo que un investigador de PortSwigger dio una charla sobre esto hace tiempo, y recuerdo que casi todas las FAANG, como Apple, Microsoft y Meta, eran vulnerables en ese momento

  • Curiosamente, un cofundador de Snyk fundó una competidora de Cursor
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    Espero que no haya habido juego sucio

    • Como todas mis interacciones con ellos fueron muy negativas, creo que es bastante probable que sí haya habido juego sucio

  • Ahora siento que todo desarrollo debería hacerse en serio dentro de una máquina virtual. Una VM por proyecto. Hay demasiadas formas ingeniosas de arruinar la seguridad por accidente sin darme cuenta. El único consuelo es que soy un desconocido sin secretos ni patrimonio que valga la pena robar
    Confiamos ciegamente en demasiado código: IDE, plugins, utilidades de desarrollo, bibliotecas de lenguaje, paquetes del sistema operativo, etc.

    • Parece que la popularidad de Vagrant se enfrió por los contenedores Docker, pero como forma de crear entornos de desarrollo, Vagrant sigue siendo la que más me gusta
      En un lugar donde trabajé hace unos años, estaban prohibidos los navegadores web y las herramientas de desarrollo en la laptop. Si necesitabas un navegador, tenías que usarlo vía Citrix; si necesitabas programar, tenías que usar VDI o ejecutar las herramientas dentro de una VM
      En ese momento ese enfoque me parecía casi una locura, pero cada vez lo entiendo más
    • El verdadero problema es el rendimiento gráfico de las VM. Sigue siendo simplemente malo. Si ejecutas Cinnamon en una VM, es casi imposible hacer que la aceleración GL funcione bien
      Como NVIDIA mantiene las funciones de GPU virtualizada bloqueadas detrás de sus tarjetas enterprise, terminas dependiendo de traducciones de instrucciones que no sirven de mucho
      Casi todo el demás overhead de una VM se puede tolerar, pero una GUI entrecortada y sin respuesta tiene un impacto ergonómico peor de lo que parece y, curiosamente, termina afectando también la percepción de otros rendimientos
      Si este problema se resolviera aunque sea para el caso de virtualizar Linux sobre Linux, la opción de virtualizarlo todo sería mucho más realista
    • Es terrible que la confianza se haya deteriorado tanto, y tampoco tranquiliza recibir actualizaciones de varios GB del sistema operativo todos los meses. Me gusta la idea de tener una VM estable y aislada por proyecto. ¿Existe alguna herramienta open source estándar para esto?
      En concreto, estoy migrando mi entorno de desarrollo de Go y Zig desde una Mac vieja a Asahi Linux en una M1, y ya estoy trabado buscando reemplazos para TrueCrypt y Little Snitch. ¿Estas herramientas de VM soportan VM cifradas y reglas de firewall? Se mencionó Vagrant aquí y parece que resolvería en parte el aislamiento de red, pero ¿qué más recomendarían?
    • Entiendo esa sensación, y yo también le he dado vueltas varias veces. Ahora mismo no quiero hacerlo, pero la razón principal no es el esfuerzo
      Una VM puede protegerme a mí, pero no protege a los usuarios del software que creo. Si necesito ponerme un traje de protección para tocar un producto, ¿cómo puedo enviárselo a mis clientes y esperar que lo usen de forma segura sin protección?
      Ese no es el entorno que quiero
      La solución actual es ser extremadamente exigente al elegir dependencias. Más específicamente, creo que no hay que confiar en proyectos ni empresas, sino solo en personas. No es fácil, pero por ahora no veo una alternativa mejor
    • Desarrollo varios proyectos en Linux. Como me preocupa sobre todo que herramientas, scripts de build o pruebas lean datos sensibles o destruyan datos por accidente, uso namespaces de Linux y bubblewrap para restringir el acceso a archivos mientras trabajo en cada proyecto
      Tengo un archivo dot simple por proyecto donde anoto los binds del sistema de archivos, y cuando abro una terminal nueva mientras trabajo, se aísla automáticamente según ese archivo dot. La carga cognitiva es muy baja y la integración es casi transparente. Imagino que muchos desarrolladores tienen scripts parecidos. Hace tiempo busqué algún proyecto así pero no encontré nada; no sé si es porque es demasiado simple como para convertirlo en proyecto o porque no sé cómo le llaman otras personas. Me gustaría tener algo de referencia
      No restrinjo el acceso a la red. Experimenté con registrar todo el tráfico y configurar automáticamente un proxy MITM, pero no era lo suficientemente cómodo para usarlo como usuario normal. Por supuesto, la superficie de ataque del kernel sigue existiendo. Aun así, mi principal preocupación es que se lean o destruyan archivos

  • La parte del artículo con la que no estoy de acuerdo es esta: “Conviene no instalar paquetes NPM a ciegas, y hay señales para ver si un paquete es sospechoso. Estos paquetes tienen solo dos archivos, package.json e index.js o main.js, y eso es una de las banderas para juzgar si son normales”
    Esto puede funcionar hasta cierto punto para paquetes de nivel superior, pero revisar también todas las dependencias transitivas es casi imposible
    Si incorporas un paquete con 400 dependencias, ¿cómo vas a revisar correctamente siquiera el 10% de esa superficie? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • El consejo de seguridad que aplica en ese caso es distinto: no incorpores un paquete con 400 dependencias
    • En este punto, la dirección general de SELinux era la correcta. Si clasificas de antemano los archivos como datos sensibles y niegas el acceso según eso, resuelves bastante bien este problema; por ejemplo, impedir que una instalación de NPM acceda a id_rsa
    • ¿Cómo diablos un componente de carrusel para React termina teniendo más de 400 dependencias…?
    • En nuestra empresa usamos una excelente herramienta de seguridad llamada Snyk. Recomiendo mucho probarla /s

  • Snyk también es una empresa que no rota las claves públicas, sino que simplemente las cambia sin avisar: https://github.com/snyk/cli/pull/5649
    Si un proyecto se muda a un hosting de repositorios que no sea GitHub, lo marca como “abandoned”, y aunque haya nuevas versiones en npm/PyPI, sigue apareciendo como proyecto abandonado
    No creo que su capacidad esté a la altura de su reputación
    Además, un vendedor de Snyk me insultó por email. Al parecer, no estar interesado en comprar el producto significa que soy un desarrollador incompetente que solo puede usar software lleno de vulnerabilidades

    • También penaliza bibliotecas cuyo desarrollo ya terminó y solo necesitan mantenimiento mínimo
      Parece un software completamente al revés, que las empresas compran porque las aseguradoras les piden completar ítems de una checklist de seguridad
    • Ese etiquetado de “abandoned” es especialmente lamentable. Yo también estoy intentando salir de GitHub últimamente, y siento que GitHub tiene demasiado control
      Codeberg se ve interesante, y si puedes encargarte del mantenimiento, opciones self-hosted como Forejo también parecen buenas
    • Que lo marquen como “abandoned” por haberse mudado a otro repositorio que no sea GitHub, y que siga así aunque haya nuevas versiones en npm/PyPI, es claramente señal de un gran equipo /s
      No había escuchado mucho sobre Snyk más allá de que son bastante orgullosos, pero es una perspectiva bastante interesante
    • Supongo que podrías compartir el cuerpo de ese email con las partes pertinentes censuradas, ¿no?

  • Sin más contexto, tampoco se ve bien para Snyk. Significa que un empleado probó su propio servicio en un entorno real usando NPM, o que al realizar una auditoría legítima sobre Cursor faltaron controles y procedimientos para evitar usar recursos públicos.

    • ¿Por qué está mal? NPM se comporta de forma extraña si existe un paquete público con el mismo nombre que un paquete de un repositorio privado, y en algunos casos descarga el paquete público. Creo que a esto se le llama algo como ocupación previa de paquetes. Puede que durante la evaluación solo hayan demostrado que eso era posible. En mi opinión no hubo daño y no hay problema.

  • Parece una auditoría white hat de Snyk. oastify.com es el servidor predeterminado de Burp Collaborator, por eso probablemente se detectó.
    Para la prueba debieron usar un repositorio npm privado, y sobrescribirlo localmente no es difícil. También debieron usar su propio servidor Collaborator.

    • No es white hat porque extrajeron datos activamente. Si solo querían demostrar que funcionaba, habría bastado con imprimir un console.log, hacer fallar npm install o usar un método que no extrajera el payload.

  • Parece que NPM está creando empleos en la industria de seguridad. Es un desastre imposible de arreglar, y espero que competidores como JSR presionen lo suficiente a la organización.

    • No es un problema exclusivo de NPM, sino un problema general de confianza en bibliotecas de terceros. Aunque es mucho menos frecuente, también aparecen exploits en plataformas como NuGet. También aparecerán en JSR. Gracias a la inmutabilidad es más seguro, pero eso no impide que alguien descargue un paquete malicioso antes de que salga a la luz.
      Más bien, es probable que regulaciones como DORA y NSIS empiecen a exigir cada vez más auditorías de paquetes de terceros. Eso obligará a cambiar la forma de desarrollar en industrias críticas. Además, creo que en la era de los LLM se usará mucho menos paquetes externos. ¿Para qué traer un paquete externo para hacer cosas como generar una especificación OpenAPI? Un LLM puede escribirte el script CLI necesario con una o dos horas de configuración. Del mismo modo, aunque no uses un LLM para autogenerar directamente las partes tediosas del código, puedes hacer que cree una herramienta CLI que haga ese trabajo. Así no dependes de factores externos, y aunque es casi seguro que esas herramientas CLI sean código cowboy desordenado, puedes pulir la herramienta para que el resultado quede como quieres.
      Si miras lenguajes como Go, que meten lo necesario en los paquetes estándar, se ve un mundo donde se puede hacer muchísimo con gran facilidad usando solo la biblioteca estándar.

  • Me salgo un poco del tema, pero ¿alguien ha recibido alguna vez un SBOM decente de las propias herramientas y servicios de Snyk? Pregunto porque nos están intentando vender una solución para generar SBOM en nuestra empresa.

    • Snyk fue fundada por gente que salió de la Unit 8200 del ejército israelí.
      Creo que no la instalaría ni aunque me pagaran. Unit 8200 sigue produciendo fundadores y financiándolos, y se siente como una estructura en la que, al estilo de la NSA, ya tienen un pie dentro de la puerta.
    • Obtuve mejores resultados con Syft.
    • En mi experiencia, tenía muchos falsos positivos.

  • Snyk Research Labs contribuye regularmente a la comunidad mediante pruebas e investigación de paquetes de software comunes. Esta investigación sobre Cursor no tuvo intención maliciosa, y los paquetes incluían datos de contacto de Snyk Research Labs y del investigador. Estábamos analizando de forma muy específica la confusión de dependencias en algunas extensiones de VS Code, y esos paquetes no estaban destinados a ser instalados directamente por desarrolladores.
    Snyk sigue una política de divulgación responsable. Nadie descargó estos paquetes, pero si alguien lo hubiera hecho, habríamos tomado medidas de seguimiento de inmediato.

    • Poner un ataque en un espacio público y esperar que le pegue al objetivo es exactamente lo contrario de una conducta responsable. Lo único “bueno” es que los atraparon en el acto antes de que otra persona recibiera una bala perdida.
      Como respuesta, suena como si dijeran que enviarían una carta de disculpa al funeral de la persona alcanzada. Aunque hubiera sido con “buenas intenciones”, si comprometes credenciales, esa persona ya quedó comprometida y debe responder igual que si hubiera sido atacada por un actor malicioso.
      Esto está tan cerca de la malicia que cuesta notar la diferencia.
      Además, todos deberíamos recordar que una parte interesada de Snyk está intentando lanzar ahora un producto competidor de Cursor. Eso hace mucho más difícil asumir buena fe.
    • Bien. Pero entonces, ¿por qué enviaron las variables de entorno del usuario a casa? Para confirmar la vulnerabilidad habría bastado con enviar valores dummy, no valores reales del entorno.
    • Esto es gray hat en el mejor de los casos. Puede que la intención haya sido buena, pero este equipo creó y distribuyó software que accedía a datos y los exfiltraba sin permiso, y eso es muy ilegal. Les convendría consultar con el equipo legal antes de publicar algo así en un foro público.
    • Suena plausible, pero ¿por qué enviaron de vuelta las variables de entorno con POST? Aunque hubiera sido completamente de buena fe, no quiero que un paquete arbitrario tenga la salida de mi env.
    • Podría ser realmente el CTO de Snyk y la respuesta oficial debería ser vista por la gente, así que la recomiendo, pero esto se siente realmente irresponsable. Podían hacer una prueba de concepto sin robar de verdad las credenciales de desarrolladores inocentes.
      Además, dado el conflicto de interés con un producto competidor de Cursor, debieron ser mucho más cuidadosos. Tanto la toma de decisiones como la respuesta son pésimas.