Herramienta de código abierto de Microsoft fue hackeada y usada para robar contraseñas de desarrolladores de IA

 (techcrunch.com)
3 puntos por GN⁺ 4 시간 전 | 2 comentarios | Compartir por WhatsApp
  • Decenas de proyectos de código abierto alojados en GitHub fueron comprometidos por hackers, que inyectaron malware roba-contraseñas en el código, por lo que Microsoft bloqueó el acceso a esos proyectos e inició una investigación
  • Muchos de los proyectos afectados están relacionados con herramientas usadas para programar con apps de desarrollo de IA como el servicio en la nube Azure y Claude Code, Gemini CLI y VS Code
  • Si un usuario abre la herramienta infectada en una app de codificación con IA, el malware actúa robando contraseñas y credenciales sensibles
  • Según GitHub, al menos 70 proyectos fueron deshabilitados, y Microsoft retiró temporalmente algunos repositorios antes de restaurarlos tras una revisión
  • Este caso es un ejemplo reciente de ataque a la cadena de suministro dirigido a código abierto popular, y se informa que es la segunda vez en pocas semanas que se comprometen proyectos de código abierto de Microsoft

Resumen del incidente y respuesta de Microsoft

  • Se confirmó que hackers comprometieron proyectos e inyectaron malware roba-contraseñas en el código, por lo que Microsoft bloqueó el acceso a decenas de proyectos de código abierto en GitHub mientras investiga cómo ocurrió la intrusión
  • Muchos de los proyectos afectados están vinculados a herramientas usadas para programar en apps de desarrollo de IA como el servicio en la nube Azure y Claude Code, la interfaz de línea de comandos de Gemini y VS Code
  • No se pudo confirmar de inmediato cuántas personas descargaron realmente las herramientas afectadas
  • Microsoft confirmó que bajó repositorios, algo reportado primero por 404 Media
    • El vocero de Microsoft Ben Hope dijo: "retiramos temporalmente algunos repositorios mientras investigamos contenido potencialmente malicioso"
    • Algunos repositorios fueron restaurados tras la revisión, y otros pueden permanecer fuera de línea mientras continúan los trabajos
    • Se notificó a un pequeño número de clientes que podrían haber descargado contenido desde los repositorios afectados, y si se identifica que se requieren más acciones, serán contactados directamente a través de los canales de soporte existentes
  • En respuesta a la consulta de TechCrunch, no se entregó de inmediato una cifra concreta de clientes afectados

Cómo opera el malware

  • La empresa de seguridad Cloudsmith y el sitio comunitario de análisis de malware OpenSourceMalware estuvieron entre los primeros en señalar este hackeo
  • El malware opera para robar contraseñas y otras credenciales sensibles cuando un usuario abre la herramienta infectada en una app de codificación con IA
  • Al acceder a las páginas de los proyectos en GitHub, el sitio de hospedaje de código propiedad de Microsoft, al menos 70 proyectos aparecían marcados como "deshabilitados (disabled)"
    • Mensaje mostrado: "El acceso a este repositorio ha sido deshabilitado por personal de GitHub debido a una violación de los Términos de Servicio de GitHub"

El contexto de un ataque a la cadena de suministro

  • Es el caso más reciente de una serie ocurrida en los últimos meses, en la que se comprometen proyectos de código abierto ampliamente usados para sembrar malware en muchos usuarios que instalan ese código
  • Este tipo de hackeo se conoce como ataque a la cadena de suministro (supply chain) y apunta a código que se usa en muchos productos de software o por cierto tipo de usuarios
    • Ese tipo de objetivos puede resultar atractivo para hackers porque a veces tiene acceso a sistemas en la nube y a grandes volúmenes de datos de clientes
  • No es raro que desarrolladores únicos de proyectos de código abierto sean el blanco, y en algunos casos esto forma parte de intentos de largo plazo para ganarse la confianza del desarrollador
  • Aun así, es inusual que una gran empresa tecnológica como Microsoft, que sí cuenta con recursos para defenderse de estos ataques, sea comprometida

Indicios de intrusiones repetidas

  • Según Ars Technica, este es el segundo caso conocido en las últimas semanas en que un proyecto de código abierto de Microsoft es comprometido
  • A mediados de mayo, investigadores de seguridad señalaron que el proyecto de código abierto de Microsoft Durable Task, que ayuda a desarrolladores a construir apps, aparentemente fue hackeado
  • OpenSourceMalware describió este incidente más reciente como una "re-comprometida (re-compromise)" del proyecto Durable Task
    • Esto sugiere que Microsoft podría no haber expulsado por completo a los hackers en el primer intento, o que podría tratarse de una intrusión nueva y totalmente distinta

Lecturas relacionadas

2 comentarios

 
brainer 1 시간 전

¿Será que esta es la razón por la que sigo recibiendo intentos de inicio de sesión en mi cuenta de Microsoft incluso después de cambiar la contraseña?
 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • Es pura especulación y una observación personal, pero el modelo RBAC de antes ya estaba casi roto y ahora parece estar completamente quebrado
    Creo que el riesgo de cadena de suministro dentro de las empresas ha aumentado mucho porque los asistentes de código y los ingenieros tocan varios proyectos no relacionados al mismo tiempo y, sobre todo, hasta hacen experimentos que antes no hacían por falta de tiempo
    No digo que esté directamente relacionado, pero siento que sí influye, y también creo que pronto será un problema que en muchos lugares desarrolladores y gerentes estén empujando a usar IA para programar de cualquier manera en equipos personales
    Cuesta creer que no haya un patrón común entre los incidentes recientes de cadena de suministro, y también creo que existen grupos de hackers especializados en este tipo de ataques porque la recompensa es grande

    • Para ser claros, el comentario original no afirmaba que estuviera relacionado, pero esto no tiene absolutamente nada que ver con la codificación con IA o vibe coding
      Es una extensión de la falta de seguridad en la instalación de dependencias por parte de desarrolladores, que existe desde hace mucho, y del gusano Shai Halud
      Los hackers descubrieron que es fácil engañar a desarrolladores para que instalen algo, y que los equipos de desarrollo son objetivos ideales porque tienen credenciales, CLI de nube y datos sensibles como MCP
    • En nuestra empresa es parecido. Se ha extendido una especie de doctrina de “si no haces lo más posible con IA, te vas a quedar atrás”
      Se siente como repetir exactamente el antiguo boom exagerado del IoT, tratando de correr primero que todos sin prestar atención a la seguridad
    • Llevo años diciendo que hay muy poco personal para la cantidad total de proyectos, pero la dirección decía que la mayoría estaban inactivos, así que estaba bien que cada persona llevara muchos
      Y al final pasa esto
    • Me pregunto si eso significa que hay que reemplazar el control de acceso basado en roles, o sea RBAC, por otra cosa, o si significa que los modelos específicos de RBAC que se usan actualmente están rotos
      Personalmente, aunque el nombre me parece algo confuso, creo que el futuro es el modelo de seguridad basado en capacidades

  • El título ya está sesgado desde cómo está redactado, y el texto también está escrito como si fuera culpa del open source
    Luego hasta parece que le atribuye a Microsoft la responsabilidad por un ataque de cadena de suministro que fue intentado, lo cual lo hace más ridículo
    Dice Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch., pero TechCrunch no explica que así es como funciona normalmente el open source
    Me gusta criticar a Microsoft cuando se puede, pero esta vez creo que Microsoft tomó medidas seguras y correctas
    El artículo lo presenta como si todo fuera culpa de Microsoft y como si limitar el alcance de la intrusión fuera algo vergonzoso
    La frase steal passwords of AI developers también deja una implicación rara sobre si se refiere a “desarrolladores de IA” o “desarrolladores que usan IA”
    Incluso la explicación del ataque de cadena de suministro no habla de su significado real, sino solo del resultado y de por qué existe la superficie de ataque, así que me parece una cobertura muy mala

    • TechCrunch es muy descuidado y difícil de confiar
      He visto que inventan hechos para SEO mientras cubren cosas en las que trabajé directamente, y no había forma de obligarlos a corregirlo
    • No veo qué tiene de problemático esa frase
      Microsoft tiene problemas de seguridad organizacional, y el hecho de que no aseguraran bien GitHub Actions y permitieran que las solicitudes de fusión evitaran el CI/CD ayudó a esto o lo dejó en evidencia
      Este es un problema de Microsoft que existe desde antes de la IA y ni siquiera es debatible: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
      En la era de la IA, este problema se ha vuelto endémico y se está militarizando
    • Entonces me gustaría saber cómo interpretas el análisis posterior al incidente
      ¿Qué fue lo que realmente pasó y cómo habría que leerlo?

  • Parecen ser publicaciones relacionadas
    https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
    https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
    https://news.ycombinator.com/item?id=48416155
    https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)

    • Creó una herramienta de mitigación que puede corregir o eliminar el gusano en todos los repositorios infectados, y también escribió al respecto
      El lunes, la campaña Hades añadió soporte para Composer, Go y Pip. Antes de eso, solo soportaba NPM y editores asistentes de IA, y también estaba Ruby, pero parece que hoy casi nadie usa Rubygems
      Lo que incluso Microsoft está pasando por alto es que este es el primer gusano que se ejecuta en todas las plataformas del ecosistema de código. Corre en hosts de desarrolladores, servidores y runners de CI/CD, y propaga el gusano a todos los repositorios a los que esos equipos pueden acceder
      Para vencer este gusano habría que apagar al mismo tiempo y al 100% todas las computadoras y AWS EC2, Google Cloud Platform, Azure y los clústeres de Kubernetes. Literalmente se propaga a través de toda la infraestructura
      Como siempre ocurre con el malware de APT28, el kill switch consiste en configurar el idioma del host como ru_RU.KOI8-R, es decir, ajustar la variable de entorno LANG. Eso desactiva el mecanismo de propagación
      Herramienta de mitigación: https://github.com/cookiengineer/antimiasma
      Publicación del blog: https://cookie.engineer/weblog/articles/malware-insights-mia...

  • Sospecho fuertemente que esto probablemente sea un caso de uso descuidado de personal access tokens tradicionales
    Si le vas a pasar tokens a agentes de IA en dispositivos openclaw raros, deberías usar tokens granulares
    Mi cuenta de GitHub está repartida entre 3 organizaciones con políticas completamente distintas, y aun así me sorprende un poco que todavía se permitan los tokens classic
    Como mínimo, deberían hacer que hubiera que permitirlos manualmente para cada organización

    • Creo que los agentes de IA deberían ser una entidad de seguridad separada y recibir tokens de acceso dedicados solo para los repositorios u organizaciones que necesiten
      Pasarle a un agente de IA un token de acceso “acuñado” para una cuenta humana se siente como el nuevo “anotar la contraseña en un post-it”
    • Es cierto, pero la gestión de permisos de los tokens granulares es casi una pesadilla
      No es fácil determinar qué necesita exactamente cada tarea y qué sería lo correcto
      Además, muchos desarrolladores de software creen que es más importante enfocarse en el código que en los permisos, y también ven los permisos como responsabilidad de otra persona
    • Si la causa fue un classic PAT, ¿no significa eso que podrían estar en riesgo repositorios privados adicionales, aparte de los repositorios recientes de GitHub?
    • Estoy usando un token classic de una cuenta de bajos privilegios para hacer scraping de repositorios públicos
      Si hubiera permisos a nivel de organización, probablemente se ajustaría bastante bien a mi caso de uso

  • Ayer tuve que restablecer la contraseña de mi cuenta personal de Microsoft porque recibí una alerta de autenticación de dos factores por un intento de inicio de sesión desde Rumania
    No sé cómo consiguieron la contraseña. El único producto de Microsoft que tengo es una Xbox
    Desde antes de la IA, Microsoft ya me daba la impresión de tener fugas por todos lados como un colador, y estaría bien que la empresa se alejara de Microsoft, pero ya está amarrada

    • Es casi imposible configurar una cuenta personal de Microsoft para no permitir el inicio de sesión sin contraseña
      Así que en realidad es muy probable que tu cuenta estuviera configurada de esa manera, y que la solicitud de MFA que recibiste no haya sido autenticación de dos factores sino simplemente un intento de acceso a la cuenta
      Yo también recibí este tipo de solicitudes varias veces al día, y descubrí que si configuras la app Microsoft Authenticator en el teléfono, si tienes activado algún bloqueo como rostro, huella o PIN, te cambia por la fuerza al modo sin contraseña
      Para evitarlo, tienes que desactivar todos esos bloqueos mientras configuras la cuenta en la app Authenticator
      Como casi no uso mi cuenta de Microsoft, ahora valido con un correo aparte en lugar de Authenticator
      El simple hecho de que funcione así es una locura, pero supongo que alguien dentro de Microsoft debe estar cumpliendo su KPI de inicios de sesión sin contraseña
    • En algunas organizaciones donde trabajé, hacían que aparecieran prompts de autenticación multifactor sin importar si la contraseña era correcta o no. La intención era hacerle perder más tiempo al atacante
      No estoy seguro de si Microsoft también hace eso

  • Ojalá alguien explicara cómo se puede agregar archivos ofuscados a tantos repositorios. ¿De verdad no hay revisión de código alguna?
    El título también lleva a confusión. El setup agrega una configuración que hace que la ejecuten automáticamente las personas que trabajan en el repositorio, y esas personas tienen que usar VSCode, Cursor, Claude o Gemini
    Quienes usen Codex, opencode u otros harnesses de ejecución probablemente estén a salvo
    Más detalles: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...

    • Tengo un amigo cercano que trabaja en una gran corporación. No puedo decir cuál, pero es una empresa del S&P 500
      Lleva bastante tiempo ahí, pero nunca ha visto cómo es realmente el proyecto del que está a cargo; tiene el repositorio clonado y solo sabe qué lenguaje usa, nada más
      Todo lo están uniendo a medias con AI. Ese proyecto es el sistema de autenticación y autorización de todo el producto de la empresa
      Según él: “Me paso el día presionando Tab y en las revisiones escribo ‘comportamiento intencional’. Las revisiones también las hace AI y no interviene ningún humano. El CEO y el CTO hablan totalmente en serio cuando dicen que trabajemos así. Si algo se rompe, nadie sabe cómo funciona porque ninguna persona ha visto el código real. El desempeño no se evalúa por lo que hicimos, sino por la cantidad de tokens que usamos”
      Es muy posible que muchas empresas estén así, así que no sería raro asumir que no hay revisiones de código reales
    • Muchos de los commits maliciosos aparecen con el autor github-actions
      Eso significa que están autenticando contra el lado interno de GitHub CI/CD, y hay tantos commits así que sería difícil para cualquier herramienta automática encontrar el veneno en un enorme montón de paja
      Por eso esto está relacionado con la brecha de seguridad de GitHub de septiembre de 2025
      “Las estrellas de GitHub de los cinco repositorios suman 1,459, y mantine-datatable por sí solo representa 1,225. Las estrellas son un indicador indirecto muy aproximado de cuántos desarrolladores han hecho checkout local del código fuente, y ese es el grupo al que apunta este ataque.”
      “Todos los commits estaban sin firmar, con identidad github-actions, y dejaban el mismo rastro de seis archivos con mensajes como chore: update dependencies [skip ci]. Recorrer cinco repositorios en 49 segundos no es trabajo humano, es automatización. Esto coincide con la autopropagación de Shai-Hulud, que primero recopila tokens de GitHub con permisos de escritura de una infección previa y luego empuja payloads persistentes a todos los repositorios a los que esos tokens alcanzan.”
      https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
      Funcionamiento real: https://safedep.io/config-files-that-run-code/
      No tengo relación con esa gente, pero es la explicación más simple y detallada que he encontrado de lo que está pasando ahora mismo
    • Un colega preguntó muy en serio: “Si ahora generamos la mayor parte del código, entonces ¿quién está leyendo realmente todo ese código?”
      Es una empresa pequeña, pero con algunas personas siento que el impulso de querer confiar en AI como si fuera una fe ciega es casi religioso
      Yo leo más del 90% del código que genero como si estuviera revisando el código de un desarrollador junior
      Ahora mismo estoy haciendo bastante vibe coding para una función nueva, pero cuando los PR de GitHub vuelvan a funcionar, pienso leer todo a fondo
    • Si se comprometió una cuenta con permisos para hacer push al repositorio, entonces no habría hecho falta una revisión de PR

  • ¿Y a esta gente le estamos confiando los certificados CA raíz de Secure Boot?

    • ¿Te refieres a esa empresa que reprobó la revisión de seguridad de 2023? [0]
      “Cada una de las fallas descritas arriba, vista por separado, podría resultar comprensible. Pero tomadas en conjunto, señalan una falla en los controles organizacionales y la gobernanza de Microsoft, así como en su cultura corporativa en materia de seguridad.”
      Los productos y servicios de Microsoft están en todas partes. Es una de las empresas tecnológicas más importantes del mundo, quizá la más importante. Esa posición conlleva una responsabilidad global del más alto nivel. Se necesita una cultura corporativa responsable y centrada en la seguridad, empezando por el CEO, para asegurar que los factores financieros o de salida al mercado no debiliten la ciberseguridad ni la protección de los clientes de Microsoft.
      “Lamentablemente, a lo largo de esta revisión el comité identificó una serie de decisiones operativas y estratégicas que apuntan a una cultura corporativa en Microsoft que puso como baja prioridad tanto la inversión en seguridad empresarial como la gestión rigurosa del riesgo. Estas decisiones causaron costos y daños significativos a clientes de Microsoft en todo el mundo.”
      “El comité está convencido de que Microsoft debe corregir su cultura de seguridad.”
      [0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
    • La raíz de confianza de Secure Boot normalmente no es un certificado de Microsoft, sino uno del OEM, y eso podría ser todavía peor: https://www.binarly.io/blog/pkfail-untrusted-platform-keys-u...
      De todos modos, eres libre de quitar el certificado de Microsoft y registrar el tuyo
    • Más que “confiar”, se parece a “tener que aceptarlo a la fuerza”
      Este incidente solo continúa el historial de Microsoft de haber sido no una empresa que cuida bien la seguridad, sino el problema de seguridad en sí
    • Confiar en Microsoft en temas de seguridad es una tontería
      En los últimos 40 años han demostrado muchas veces que no les importa

  • Puede que me haya dado cuenta tarde, pero desde hace tiempo vengo diciendo que, aunque no quieras usar IA por razones como que “el código es malo”, al menos deberías considerar usarla para auditorías de seguridad
    Como mínimo, hay que usar herramientas que escaneen el código en busca de vulnerabilidades
    El vector de ataque no son solo los plugins que roban datos, sino también vulnerabilidades de día cero en casi cualquier software que usas y script kiddies con LLM atacando tus servicios web
    Los hackeos van a aumentar y van a empeorar, así que hay que pensarlo dos veces antes de no invertir en auditorías y herramientas de ciberseguridad

  • Nadie debería hacer npm install ni pip install en su propia máquina
    Si usas de forma consistente un sandboxing adecuado (https://github.com/ashishb/amazing-sandbox), puedes reducir mucho el alcance del daño de este tipo de ataques

    • ¿El backend de Docker ejecuta los comandos en contenedores rootless?
      Revisé el código por encima, pero no vi nada que lo confirmara
    • Docker no es una estrategia de sandboxing seria
    • Si dices que no hay que hacer npm install ni pip install en la propia máquina, ¿qué alternativa propones?
      ¿Que no se instale nada fuera del sandbox?
    • ¿Aquí también hay algún componente de detección?
      Está bien desarrollar dentro de un sandbox, pero el siguiente paso es el despliegue en producción
      ¿Cómo sabes si hubo comportamiento malicioso dentro del sandbox para no terminar desplegando también ese malware?

  • Es demasiado gracioso que el GitHub de Microsoft haya suspendido el acceso de Microsoft Azure y de todos los demás usuarios al código base de Microsoft por una violación de los términos de servicio
    Realmente ayuda a dimensionar bien este organigrama: https://www.businessinsider.com/big-tech-org-charts-2011-6