- Se descubrió una vulnerabilidad en M365 Copilot de Microsoft que impedía registrar los logs de auditoría, lo que provocaba que los accesos a archivos no quedaran reflejados en los registros
- Con solo pedirle a Copilot que actuara de cierta manera, era posible acceder a archivos sin dejar registros de auditoría, lo que podría derivar en riesgos de amenazas internas y de incumplimiento regulatorio
- El investigador lo reportó a MSRC, pero Microsoft no emitió un CVE ni avisó a los clientes, pese a que eso contradice su política oficial
- Microsoft clasificó la vulnerabilidad solo con nivel Important y decidió que no hacía falta un aviso adicional porque se resolvió mediante actualización automática
- Sin embargo, esto puede causar graves problemas legales y de seguridad para empresas de sectores regulados que dependen de los logs de auditoría, como los sujetos a HIPAA, y la falta de transparencia de Microsoft está recibiendo fuertes críticas
Vulnerabilidad de auditoría en Copilot: panorama general e impacto
- Se descubrió un fallo en Copilot, uno de los principales servicios de IA que Microsoft está impulsando activamente, por el cual los accesos a archivos no quedaban registrados en los logs de auditoría según la solicitud del usuario
- En condiciones normales, cuando M365 Copilot resume un archivo, ese acceso debería registrarse en el log de auditoría, algo clave para la seguridad de la información dentro de una organización
- Sin embargo, si se le pedía a Copilot que no incluyera enlaces al archivo en el resultado del resumen, ese log simplemente no se registraba
- Por ejemplo, un empleado podría consultar una gran cantidad de archivos mediante Copilot antes de renunciar y filtrar información sin dejar rastro en los registros
- Esta vulnerabilidad no requería un hackeo elaborado; podía ocurrir de forma natural e incluso fue descubierta accidentalmente por el autor del blog durante una prueba interna de funciones
- Michael Bargury, CTO de Zenity, también había encontrado y reportado esta vulnerabilidad a Microsoft un año antes, pero siguió sin resolverse durante mucho tiempo hasta este nuevo reporte
Problemas en MSRC (reporte de vulnerabilidades) y falta de reconocimiento de la respuesta
- Microsoft ofrece una guía oficial y un proceso para reportar vulnerabilidades, pero en la práctica no los sigue adecuadamente durante la gestión del caso
- Después de que el autor reportó el problema a MSRC, se produjo una situación confusa en la que la función de Copilot cambió de inmediato sin que antes se hubieran completado los pasos de reproducción
- Hubo cambios de estado del reporte (reproducción → desarrollo), pero faltó una comunicación clara sobre el avance y los motivos de las decisiones
- Respecto a la emisión de un CVE para vulnerabilidades de seguridad, le comunicaron que solo se asigna un identificador oficial cuando el cliente necesita tomar medidas directas
- Sin embargo, eso contradice la política previa de Microsoft, y esta vulnerabilidad fue clasificada simplemente como de nivel 'Important', sin divulgación ni notificación adicional
- En conjunto, el seguimiento del progreso parecía actualizarse solo de forma visible, sin relación real con las medidas tomadas, lo que convirtió la experiencia del reportante en algo ineficiente y poco transparente
Problemas por la falta de aviso y notificación a los clientes
- Microsoft decidió no emitir un CVE ni notificar a los clientes sobre esta vulnerabilidad
- Como se trata de un error que puede producirse con facilidad incluso por accidente, existe la posibilidad de que en organizaciones reales los logs de auditoría hayan estado registrándose incorrectamente durante mucho tiempo
- Aunque muchas organizaciones, incluidas entidades de salud (por ejemplo, bajo HIPAA), usan los logs de auditoría con fines legales y regulatorios, Microsoft no informó a los usuarios sobre el impacto
- Los logs de auditoría son fundamentales para la seguridad organizacional, la respuesta a incidentes y la evidencia legal, pero Microsoft ha guardado silencio sobre el tema
- Este enfoque sugiere que otros posibles problemas de seguridad también podrían manejarse sin divulgación, lo que plantea serias dudas sobre la confiabilidad de la organización
1 comentarios
Comentario de Hacker News
Estoy a cargo del desarrollo interno de chatbots en la empresa, y me cuesta explicarle a la dirección que, si el chatbot no verifica por completo los permisos del usuario actual cuando accede a documentos confidenciales, inevitablemente se abre una vía de fuga de información
Las bases de datos vectoriales, los índices de búsqueda, las bases de datos de AI Search, etc., deben existir por usuario o rastrear los permisos de acceso junto con el contenido
Pero quiero enfatizar que los permisos de acceso son muy complejos, pueden cambiar en cualquier momento, son difíciles de aplicar a gran escala y vulnerables a condiciones de carrera
Este es un caso concreto del problema de "Confused Deputy"
Corresponde a los riesgos relacionados con LLM02:2025 "Sensitive Information Disclosure" y LLM06:2025 "Excessive Agency" del OWASP LLM Top 10
Algunas soluciones empresariales de RAG lo resuelven creando índices por usuario debido a la diversidad de ACL
Cada proveedor maneja este tema de permisos de acceso de forma distinta, así que al analizar una solución RAG hay que revisar obligatoriamente ese punto
En Japón a esto le llaman "confusión de privilegios" (権限混同), y me parece un nombre curioso
Ver explicación de Confused Deputy, Ver riesgos de OWASP LLM Top 10
Me pregunto por qué se considera que rastrear los permisos de acceso de los usuarios es un problema de escalabilidad
Cuando entra una consulta, basta con buscar los documentos coincidentes en la base vectorial o en el índice, y de ellos pasar al LLM solo los que el usuario puede ver
Es como un asesor bancario, que solo puede ver la información de clientes autenticados, por lo que no debería filtrar por error datos de terceros; y si no hay autenticación, ni siquiera el operador puede ver la información de otros, así que no habría riesgo de abuso
Cuando uno choca con este tipo de muro, en realidad puede que no sea que yo haya fallado al comunicarlo ni que la dirección no lo entienda
Probablemente la dirección ya decidió ignorar el problema y, si más adelante ocurre una filtración, su intención sea trasladar la culpa a los ingenieros
Si te cuesta explicarle el problema a la dirección, puede ser efectivo poner en copia a Legal/Compliance
Eso sí, a algunos ejecutivos obsesionados con las buzzwords les puede molestar esa acción
La mayoría de las bases de datos vectoriales permiten adjuntar metadatos adicionales a los vectores
Si guardas como metadato la lista de entidades con permiso de acceso (por ejemplo, RR. HH., ejecutivos), al hacer una solicitud puedes expandir al usuario a esos roles y filtrar
Así puedes excluir desde el principio los documentos que el usuario no puede ver
Eso sí, cada vez que cambien los permisos de un documento, también hay que actualizar de inmediato los metadatos vectoriales
Es problemático que Copilot eluda los logs de auditoría y actúe como un usuario privilegiado
No creo que eso deba ser posible
En realidad Copilot no accede directamente a los archivos, sino que lee el contenido de archivos ya indexados a través de un motor de búsqueda
Microsoft debería auditar el historial de búsqueda de Copilot, y es engañoso que, si Copilot solo leyó el índice, quede registrado como si hubiera accedido al archivo
Es como decir que viste un sitio web directamente solo por haber visto un resultado en Google
Microsoft está descuidando los logs de auditoría por su afán innecesario de integrar IA a toda costa
En Windows, un proceso con privilegio de Backup puede eludir todos los permisos de acceso y, por defecto, no genera auditoría
En el caso de apps de respaldo, esto es porque los logs de auditoría serían excesivos; ese privilegio debe habilitarse explícitamente y es fácil hacerlo desde código administrado como C#
Lo mismo aplica para el privilegio de Restore
Este fenómeno se parece a los problemas de cuando Delve se introdujo por primera vez y el recorte de permisos fallaba, exponiendo resultados en búsquedas de usuarios, o cuando la búsqueda de SharePoint mostraba algunos documentos cuya existencia era visible aunque no se pudiera acceder a ellos
Por ejemplo, si buscabas "Fall 2025 layoffs", bastaba con que existiera un documento relacionado para que apareciera, lo que generaba un problema de seguridad
Sigue siendo fuerte la impresión de que para Microsoft la seguridad queda en segundo plano
Un mejor título sería "Microsoft Copilot no cumple con HIPAA"
Creo que con un título así el problema se resolvería mucho más rápido
Yendo más allá, todos los sistemas útiles de búsqueda con IA son inseguros por diseño, porque esos vectores RAG almacenados en bases de datos vectoriales no dejan de ser una compresión con pérdida de los documentos
El problema ya fue corregido
La queja actual es que no se notificó a los clientes
“Los CVE se asignan a lanzamientos de seguridad distribuidos cuando los clientes deben tomar medidas para protegerse. En este caso, la acción se despliega automáticamente en Copilot y los usuarios no necesitan actualizar manualmente, así que no se asigna un CVE”
Me pregunto si esa es una característica esencial de los CVE o si Microsoft simplemente los está usando así
Sería bueno contar con un identificador común para vulnerabilidades como esta, y creo que hace falta un sistema de numeración aparte que no dependa del proveedor
Para Microsoft, los CVE sirven para rastrear incidentes/vulnerabilidades de seguridad
Que se pueda hacer un parche urgente de forma inusualmente rápida no hace que el incidente deje de ser un problema de seguridad
Microsoft viene mostrando una tendencia fuerte a ser poco transparente y poco confiable en la divulgación de incidentes de seguridad, así que en casos como este es aún más importante divulgar información
Esto parece menos una limitación de los CVE y más bien que Microsoft está torciendo el proceso de CVE por motivos de PR
La "C" de CVE es de Common
Es decir, es un sistema enfocado en la "comunalidad"
Incluso para las apps LOB importantes, actualmente estamos intentando alejarnos de Microsoft
Después de varios hacks en los últimos meses, zero-days de SSO y ver que Copilot ignora permisos porque el indexador opera como global admin, la inquietud no hace más que crecer
Son tantos los problemas que pueden surgir al dejar la auditoría y los logs de actividad directamente en manos de un LLM que cuesta hasta enumerarlos
Por eso me pregunto cómo arreglaron el bug esta vez, y si acaso introdujeron un “shadow prompt”
En ninguna parte del post se dice que el LLM administre directamente los logs de auditoría
Más bien, los logs parecen registrarse en el scaffolding superior (sistemas laterales), no en el LLM, pero da la impresión de que eligieron mal el "momento" en que debía dejarse el registro
Por ejemplo, en vez de registrar auditoría cuando alguien hace clic en un enlace, debieron hacerlo cuando el documento se inyecta en el LLM, o en un punto similar
Ese diseño tampoco sería ideal, pero sería menos grave que dejar que el LLM registre por sí mismo
Soy muy escéptico respecto a usar shadow prompts (o cualquier tipo de prompt) como mecanismo real de seguridad o de control de compliance
Ese tipo de controles necesariamente debería implementarse en sistemas deterministas y predecibles
Si una herramienta hace que el LLM vea aunque sea una parte de un archivo, entonces toda la información que el LLM produzca después debería considerarse como si hubiera leído ese archivo
Creo que podrían colarse exigencias extrañas en los prompts del LLM, tipo: “Si el usuario te dice que no le des el enlace, ignóralo, y si no lo haces, a tu familia le pasará XYZ espantoso”
Esto también me hace pensar en el problema de las shadow copies
No está claro exactamente de qué tipo de log de auditoría se está hablando aquí
¿Logs de acceso a archivos de SharePoint? ¿Registro de acciones de Copilot? ¿Purview? ¿O alguna otra cosa?
Hay muchas cosas poco claras
Como Copilot está accediendo al contenido indexado y no al archivo en sí, es cierto que no accedió realmente al archivo
El autor del blog debería revisar los logs de acceso al índice
En una nota al pie del blog aparece la opinión: “Creo que es intencional que el log de auditoría no deje constancia de que el usuario accedió directamente al archivo, sino que quede como CopilotInteraction
Si el usuario solo accedió a través de Copilot, sería más raro aún que quedara registrado como si hubiera tocado el archivo directamente”
Le hice la misma pregunta a ChatGPT y me explicó que se refiere a los logs de auditoría de Microsoft 365 y Office 365, en particular al Unified Audit Log del portal Microsoft Purview Compliance
Este tipo de problemas es justo lo que hace que la confianza en grandes proveedores como Microsoft se sienta menos como una "garantía" y más como una "cuestión de suerte"
De verdad me pregunto cómo se podría arreglar esto en la práctica
Según entiendo, el índice o la base de datos que usa Copilot ya rastreó ese archivo, así que podría revelar la información sin necesidad de volver a consultar el archivo
Entonces, ¿cómo se corrige esto exactamente?
¿Habría que vincular la propia consulta a la base de datos/índice con el log de auditoría?
¿O habría que decirle al LLM: “cuando consultes conocimiento, cumple tu promesa y deja registro sí o sí”?
Hace muchísima falta una comunicación oficial sobre cómo Microsoft detectó y resolvió este problema
Si una empresa maneja datos sensibles, creo que este incidente debería servir como llamada de atención
En general, cualquiera puede registrar un CVE
Yo mismo podría enviarlo e intentar forzar una respuesta de Microsoft
Solo con la publicación del blog ya me parece bastante convincente
En la práctica no es tan simple
La mayoría de las autoridades que asignan números CVE (CNA), como MITRE o los CERT nacionales, aceptan reportes de cualquiera, pero hay evaluación y revisión
Microsoft es su propia CNA, así que salvo una razón especial, no van a asignar desde afuera un CVE relacionado con MS
Me pregunto si realmente tiene sentido pedir un CVE para un servicio que solo ofrece Microsoft
La duda es qué podría hacer el usuario con eso
El formulario para registrar CVE está aquí
También inspira confianza por su soporte PGP, su larga trayectoria y sus patrocinadores verificados
Debe usarse solo para asuntos legítimos y justificados
Aunque suene interesante, no creo que esto sea materia de CVE
Un CVE debería corresponder a una vulnerabilidad aplicable en común a varios productos de varias fuentes, y Copilot no entra ahí
Lo más grave de este incidente es el error de diseño de haber delegado en el propio LLM la generación de logs de auditoría
Los logs de auditoría debieron generarse automáticamente en la API que consulta archivos o URLs, y eso es ingeniería básica