Cómo lograron obtener acceso root en Copilot

• En abril de 2025, Copilot Enterprise se actualizó con un sandbox de Python en tiempo real (basado en Jupyter Notebook), lo que permitió la ejecución de código en el backend
• Mediante la sintaxis %command de Jupyter, era fácil ejecutar código arbitrario sobre el sistema base, y también se podían ejecutar comandos de Linux como el usuario ubuntu (entorno miniconda)
• Existía una vulnerabilidad de seguridad: la ruta /app/miniconda/bin era escribible por el usuario ubuntu y además tenía prioridad en el $PATH de root, por lo que se podían sobrescribir comandos clave como pgrep
• Aprovechando esto, lograron obtener privilegios de root, pero el interior del contenedor estaba fuertemente aislado, por lo que no era posible escapar del contenedor ni hubo filtración adicional de información
• La vulnerabilidad fue reportada en abril y parcheada en julio con riesgo moderado; no hubo recompensa y solo se incluyó a los investigadores en la lista de reconocimiento

---

Análisis de la vulnerabilidad en el sandbox Jupyter de Microsoft Copilot Enterprise

Resumen del entorno Jupyter de Copilot Enterprise

• Desde abril de 2025, se introdujo en Copilot Enterprise un sandbox de Python basado en Jupyter Notebook
• Los usuarios podían ejecutar comandos del sistema Linux mediante la sintaxis %command de Jupyter
• El entorno corría con permisos del usuario ubuntu sobre miniconda y no contaba con binario sudo
• Era posible explorar variables de entorno, red, sistema de archivos e información de procesos, entre otros

Funcionamiento y estructura interna del contenedor

• Copilot es similar al sandbox de ChatGPT, pero usa un kernel más reciente y Python 3.12
• Procesos principales: Jupyter Notebook, goclientapp escrito en Go (ejecutándose en el puerto 6000), httpproxy, etc.
• La red solo tenía habilitados loopback y una interfaz link-local limitada
• El sistema de archivos usa OverlayFS con base en la ruta /legion, y existen scripts personalizados en /app

Descarga y manipulación de archivos

• Los archivos de texto o salidas de comandos se podían descargar normalmente, pero los archivos binarios corrían riesgo de corrupción, por lo que era necesario codificarlos en base64
• Los archivos se ubicaban en /mnt/data y se generaban enlaces de descarga externos en formato blob URL

Estructura de goclientapp/httpproxy

• goclientapp: ejecuta en el entorno Jupyter el código recibido desde el exterior por el endpoint /execute (formato JSON) y devuelve el resultado
• httpproxy: actúa como proxy del tráfico HTTP saliente desde Jupyter (deshabilitado con ENABLE_EGRESS=false)

Vulnerabilidad en el script entrypoint.sh

• En entrypoint.sh, el script de entrada del contenedor, varios servicios (goclientapp, httpproxyapp) se ejecutaban con permisos del usuario ubuntu
• Solo keepAliveJupyterSvc.sh seguía ejecutándose continuamente como root
• En la línea 28, el comando pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888" se ejecutaba según la prioridad de directorios dentro de $PATH
• /app/miniconda/bin aparecía antes que /usr/bin en el PATH tanto de root como del usuario ubuntu, lo que permitía reemplazar arbitrariamente comandos como pgrep

Proceso para obtener privilegios de root y sus límites

• El atacante creó un script malicioso llamado pgrep en /app/miniconda/bin, haciendo que entrypoint.sh lo ejecutara periódicamente con privilegios de root
• Ese script leía el archivo /mnt/data/in, ejecutaba su contenido como comandos de shell y guardaba los resultados en /mnt/data/out
• Con este método sí lograron obtener privilegios de root dentro del contenedor, pero no pudieron acceder a información sensible como archivos de /root, registros u otros datos, ni escapar del contenedor
• El contenedor ya tenía parcheados los distintos escenarios de breakout

Respuesta de Microsoft y resultado

• 18 de abril de 2025: Eye Security reportó la vulnerabilidad al MSRC
• 25 de julio de 2025: Microsoft la clasificó como de riesgo moderado (moderate severity), la parcheó y cerró el caso, incluyendo a los investigadores en la lista de reconocimiento (sin pago de bug bounty)

Referencias y apéndice

• Eye Security es una empresa europea de ciberseguridad que ofrece monitoreo de amenazas 24/7, respuesta a incidentes, ciberseguro, entre otros servicios

• Los casos de intrusión en servicios internos de Microsoft (como Entra OAuth), incluida esta vulnerabilidad, están previstos para presentarse en BlackHat USA 2025

• Línea de tiempo

  • 18 de abril de 2025 – Reporte al MSRC
  • 25 de julio de 2025 – Parche, cierre del caso y publicación del blog

[GN⁺]

Opiniones de Hacker News

• Entiendo que el punto clave de esta vulnerabilidad fue que, mediante un truco, se pudo ejecutar código con privilegios de root en un diseño que originalmente solo pretendía otorgar privilegios de usuario normal dentro del contenedor. Pero en la práctica, el contenedor en sí estaba tan estrictamente aislado que no tenía acceso a la red ni forma de escapar, así que lo único que se podía hacer con privilegios de root era romper tu propio contenedor
  • Hay que reconocer que Microsoft configuró la seguridad de forma realmente minuciosa. La mayoría de las empresas no aíslan así de bien
  • No sé exactamente cómo estaba implementado este contenedor. Microsoft usa una forma estándar (Azure container-apps session) para aislar el sandbox de Python, y ojalá esta función use eso o algo parecido
  • Se siente un poco raro que Copilot a veces rechace ejecutar código y otras veces lo permita. Me da curiosidad saber exactamente hasta dónde quieren llegar con eso
  • Hoy en día las vulnerabilidades se apilan como una pila de exploits, así que decir “el contenedor es seguro” solo significa que el atacante todavía no encontró la falla. Ya existen ataques conocidos para escapar de contenedores o VMs, y basta un error pequeño, como una mala configuración o un bug en un driver virtio, para abrir una brecha. Este caso sí es un resultado importante
• Al ver un título como “How We Rooted Copilot”, pensé que de verdad habían comprometido la VM principal de Copilot, pero en realidad solo obtuvieron privilegios de root dentro de un contenedor sandbox de Python extremadamente limitado. Un título más preciso sería “How We Rooted the Copilot Python Sandbox”
  • Se puede resumir como “logramos elevar privilegios de usuario normal a root en un sandbox completamente aislado”. En la práctica no significa mucho, pero más bien demuestra qué tan eficazmente contribuye el sandbox a la defensa
• Aquí se puede ver todo el proceso del hackeo
• Yo había entendido este incidente como un escape del sandbox de Python que además comprometía el contenedor. Parece que por eso Microsoft calificó la severidad de la vulnerabilidad como moderate
• No sé si se me está escapando algo, pero ¿no se podría intentar una conexión de red hacia el exterior aunque fuera pasando por la red local? Me pregunto si Microsoft realmente no tenía riesgo de exfiltración de datos o de ataques adicionales al permitir incluso privilegios de root dentro de este tipo de contenedores para los clientes
  • Cuando openai publicó antes su función de intérprete de Python, la situación fue parecida. El acceso a red externa estaba bloqueado, y lo único interesante eran algunos archivos de configuración interna y algo de información sobre cómo programaban los desarrolladores. Este caso es básicamente igual
• ¿Cómo podemos saber si la respuesta que dio Copilot es real o pura alucinación? Yo trabajo ahí y nunca he visto un proceso así. Como referencia, encontré un script llamado keepAliveJupyterSvc.sh en un repositorio público
  • Ese repositorio y sus contribuidores sí pertenecen realmente a MS/Azure y están desarrollando el servicio de ejecución de código Python dentro del contenedor. No sé por qué está en una cuenta personal. Dicen que es un fork de un proyecto de Office, pero no encuentro el original
  • Puede que no sea alucinación. El código de Copilot podría haberse generado a partir del dataset de entrenamiento de GitHub
  • Esto sí se siente como una verdadera alucinación. La mayoría de los chatbots no son más que generadores de tokens. En realidad no ejecutan programas para responder, sino que generan tokens con GPU, los convierten en inglés y los envían
• Antes se decía que los LLM antiguos se entrenaban con documentos privados de empresas y por eso exponían bien los secretos corporativos. Ahora parece que la mayoría de los datos ya están depurados
  • Los LLM no memorizan ni siquiera datos que aparecieron una sola vez por accidente, y tampoco he visto casos reales de entrenamiento masivo con datos privados. Por eso me parece poco realista. Lo único que puede pasar es que una alucinación del LLM parezca una filtración real de información confidencial
  • Por mi experiencia, los secretos corporativos no suelen tener mucho valor para otras empresas
  • Me gustaría ver ejemplos concretos de eso. Yo nunca he visto ninguno
  • Antes incluso empresas no técnicas lo adoptaban sin lineamientos y a veces generaban contenido para fines no previstos. Por ejemplo, una empresa de boba (té de burbujas) lanzó un LLM gratis y sin registro, y yo llegué a usarlo para generar algunos scripts de bash antes de que saliera la versión gratuita de ChatGPT
  • Me da curiosidad la fuente
• En la práctica, esto ni siquiera parece una vulnerabilidad. El objetivo de este sistema es justamente ejecutar código dentro de un contenedor
  • Claro, eso solo tiene sentido bajo el supuesto de que el contenedor esté aislado
• Parece que habría sido más fácil saltarse esto dándole a Copilot el binario de sudo en base64 y luego usándolo
  • En ese caso también habría que cambiar el propietario del archivo a root
• Reportaron la vulnerabilidad a Microsoft, la clasificaron como moderate, no recibieron bug bounty y solo obtuvieron un acknowledgement. No entiendo bien cómo una empresa tan grande ni siquiera da una recompensa. Me pregunto si de verdad no puede salir nada malo de una situación así
  • En esencia no obtuvieron nada. Aunque consiguieras root, solo podías explorar una parte del contenedor a la que antes no tenías acceso; ni siquiera había archivos en /root y tampoco quedaron logs útiles. Todos los métodos de escape conocidos ya estaban parchados. Si Microsoft recompensara cada bypass de este tipo, no terminaría nunca, así que hasta cierto punto se entiende que no den una recompensa aparte si no hay riesgo real
  • De verdad no entiendo por qué la gente le reporta bugs gratis a megacorporaciones valuadas en billones
  • Si Microsoft no va a pagar, al menos sería mejor dar swag. Si les dieran buenos regalos promocionales a los hackers, eso serviría como publicidad natural e incluso podría hacer que quisieran entrar a trabajar ahí. Habría que aprovechar la cultura de la comunidad hacker
  • Aunque obtengas “root”, en la práctica no consigues nada. Intentaron varias cosas y no sacaron provecho de ninguna