Problema 6238

Como la mayoría de las empresas tecnológicas, Microsoft está apostando a fondo por la IA. Su producto estrella, Copilot (en todas sus variantes), permite a las personas utilizar la IA en su trabajo diario para interactuar con los servicios de Microsoft y, en general, realizar tareas. Desafortunadamente, esto también genera una amplia gama de nuevos problemas de seguridad.

El 4 de julio, me encontré con un problema en M365 Copilot: a veces accedía a un archivo y devolvía la información, pero el registro de auditoría no la reflejaba. Tras realizar más pruebas, descubrí que podía simplemente pedirle a Copilot que se comportara de esa manera, y lo hacía. Esto permitía acceder a un archivo sin dejar rastro. Dados los problemas que esto genera, tanto para la seguridad como para el cumplimiento legal, lo reporté de inmediato a Microsoft a través de su portal MSRC.

Afortunadamente, Microsoft proporciona una guía clara sobre qué esperar al reportar vulnerabilidades. Menos útil aún, no siguieron esa guía en absoluto. Todo el proceso ha sido un desastre. Y si bien solucionaron el problema, clasificándolo como una vulnerabilidad "importante", también decidieron no notificar a los clientes ni publicarlo. Esto significa que su registro de auditoría es incorrecto, y Microsoft no planea decírselo.

Esta publicación se divide en tres partes. La primera explica la vulnerabilidad de Copilot y los problemas que puede causar. La segunda describe cómo Microsoft gestionó el caso. Y la tercera parte analiza la decisión de Microsoft de no publicar esta información y por qué considero que es un gran perjuicio para sus clientes.

La vulnerabilidad: Copilot y el registro de auditoría

La vulnerabilidad en este caso es extremadamente simple. Normalmente, si le pides a M365 Copilot que resuma un archivo, te lo entregará y el registro de auditoría mostrará que Copilot accedió a ese archivo en tu nombre.[1]

¡Bien! Los registros de auditoría son importantes. Imagina que alguien descargó un montón de archivos antes de dejar tu empresa para fundar una empresa de la competencia; Querrías tener un registro de eso, y sería perjudicial que la persona pudiera usar Copilot para pasar desapercibida.[2] O quizás tu empresa tenga datos personales confidenciales y necesites un registro estricto de quién accedió a esos archivos por motivos legales y de cumplimiento normativo; de nuevo, necesitarías saber sobre el acceso realizado a través de Copilot. Estos son solo dos ejemplos. Las organizaciones dependen de tener un registro de auditoría preciso.

Pero ¿qué ocurre si le pides a Copilot que no te proporcione un enlace al archivo que resumió? En ese caso, el registro de auditoría está vacío.

Así de simple, tu registro de auditoría está mal. Para un infiltrado malintencionado, evitar ser detectado es tan sencillo como preguntarle a Copilot.[3]

Quizás estés pensando: "¡Vaya! Pero supongo que no mucha gente lo ha descubierto, así que probablemente no haya problema". Desafortunadamente, te equivocas. Cuando descubrí esto, no estaba buscando maneras de violar el registro de auditoría. En cambio, simplemente intentaba activar el registro de auditoría para probar la funcionalidad que estamos desarrollando en Pistachio y me di cuenta de que no era fiable. En otras palabras, esto puede ocurrir por casualidad.[4] Así que, si su organización tiene licencias de Copilot de M365, su registro de auditoría probablemente esté equivocado.

ACTUALIZACIÓN: Resulta que Michael Bargury, el director de tecnología de Zenity, descubrió esto hace un año y lo divulgó, y Microsoft aún no lo ha solucionado (de ahí mi informe). Dio una muy buena charla sobre el tema, entre otras cosas malas sobre IA. La parte relevante está aquí.

Problemas con MSRC

Nunca antes había reportado una vulnerabilidad a Microsoft, y mi reacción inicial al proceso fue bastante positiva. El hecho de poder enviar algo ya me pareció inusualmente amigable para los estándares de Microsoft. Y como mencioné, incluso tenían una guía sobre qué esperar.

Desafortunadamente, nada salió según lo planeado. El 7 de julio, el estado de mi reporte cambió a "en reproducción", pero cuando fui a proporcionar más evidencia el 10 de julio, la funcionalidad había cambiado. Esa no es la política de Microsoft; se supone que reproducen y luego pasan a "en desarrollo" cuando comienzan a trabajar en una solución. Ver el cambio de funcionalidad mientras aún estaban en "en reproducción" me hizo pensar que Microsoft me contactaría y afirmaría que no podían reproducir el problema, cuando en realidad simplemente lo habían solucionado basándose en mi reporte.

Así que pregunté a MSRC qué estaba pasando, y en lugar de responder con una explicación simple, cambiaron el estado del reporte a "en desarrollo" y no dijeron nada. Hasta ese momento, pensé que Microsoft seguiría un proceso y se coordinaría conmigo si tuvieran que desviarse. En cambio, me pareció que el proceso reflejaba menos lo que realmente estaba sucediendo y se parecía más a un rastreador de Domino's Pizza para investigadores de seguridad. Los estados no son reales.

El 2 de agosto, Microsoft me informó que el 17 de agosto se publicaría una solución completa, que podría revelar a partir del 18 de agosto. Pregunté cuándo se emitiría un número de CVE, y me dijeron:

Las CVE se asignan a las correcciones implementadas en las versiones de seguridad cuando los clientes necesitan tomar medidas para mantenerse protegidos. En este caso, la mitigación se enviará automáticamente a Copilot, donde los usuarios no tendrán que actualizar manualmente el producto y no se les asignará una CVE.

Esa no es en absoluto la política de Microsoft, como les señalé mediante enlace a su propia política. MSRC respondió: "Entiendo que es posible que no tengan una visión completa de cómo MSRC aborda estos casos", como si yo no fuera el responsable. Luego explicaron que la vulnerabilidad está clasificada como "importante", no "crítica", y que por eso no emitirán una CVE.[5] Por supuesto, no me habían dicho que hubieran clasificado la vulnerabilidad antes de ese momento.

La decisión de Microsoft de no decir nada

Si Microsoft no emite una CVE para esta vulnerabilidad, ¿cómo van a informar a los clientes? La respuesta es que no lo harán. En una llamada el 14 de agosto, Microsoft me informó que no tenían previsto revelar esto.[6]

Creo firmemente que eso es un error. Podría estar bien ignorar el asunto si se tratara de una vulnerabilidad oculta, pero la realidad es que es tan fácil que prácticamente ocurre por accidente. Si trabajas en una organización que usaba Copilot antes del 18 de agosto, es muy probable que tu registro de auditoría esté incompleto.

¿Acaso las organizaciones no necesitan saberlo? ¿Qué ocurre con las empresas sujetas a la HIPAA y que dependen del registro de auditoría de Microsoft para cumplir con algunos de los requisitos de protección técnica? ¿Acaso no se enteran, a pesar de que Microsoft afirma que M365 Copilot puede cumplir con la HIPAA? Es casi seguro que existen otras entidades reguladas con requisitos similares, y tampoco se les informará.

Hay muchos casos en los que las organizaciones dependen de los registros de auditoría para detectar, investigar y responder a incidentes. Hay demandas en las que los registros de auditoría se utilizan como prueba importante. El gobierno estadounidense incluso criticó el aumento en el cobro de registros de auditoría por parte de Microsoft (https://www.cisa.gov/news-events/news/when-tech-vendors-make-important-logging-info-available-free-everyone-wins), y un senador estadounidense criticó a Microsoft (https://www.cybersecuritydive.com/news/microsoft-free-security-logs-Outlook-email-hack-backlash/688388/) y se refirió al registro de auditoría como una característica de seguridad esencial.

¿Y ahora Microsoft afirma que, aunque el registro de auditoría era muy plausiblemente erróneo para cualquier cliente que usa Copilot, nadie necesita saberlo? Esto plantea serias dudas sobre qué otros problemas Microsoft decide ocultar discretamente.

• 1

El registro de auditoría no mostrará que el usuario accedió al archivo como un evento SharePointFileOperation FileAccessed normal, sino como un registro CopilotInteraction. Eso es lo que se pretendía y, en mi opinión, es correcto. Sería extraño que el usuario accediera directamente al archivo cuando solo lo hizo a través de Copilot.

• 2

Lo ideal sería tener un sistema que monitorizara los registros para detectar este tipo de cosas, pero como mínimo, se necesita el registro para poder comprobarlo posteriormente.

• 3

Quizás pienses que esto solo funciona con archivos a los que ya has accedido a través de Copilot, pero te equivocas. Funciona con cualquier archivo.

• 4

Me gustaría poder proporcionar una captura de pantalla de lo que está sucediendo, pero parece que Copilot trunca los chats en el historial, por lo que ya no los puedo ver.

• 5

Esto concuerda con su política, aunque debo aclarar que no estoy de acuerdo. Las normas establecen que se debe emitir una CVE si alguien ajeno a Microsoft necesita realizar una evaluación de riesgos. En mi opinión, Microsoft debería tomar esa decisión basándose en la vulnerabilidad real, no establecer una norma general basada en la clasificación de la vulnerabilidad.

• 6

Microsoft fijó la fecha de divulgación de esta vulnerabilidad para el 18 de agosto. He comunicado a Microsoft, tanto por teléfono como por escrito, que no estoy de acuerdo con su decisión de no revelar este problema por todas las razones mencionadas anteriormente. Microsoft no me ha dado ninguna razón para creer que haya malinterpretado el alcance del problema. Si este problema no fuera tan generalizado como creo, Microsoft tuvo todas las oportunidades para informarme y decidió no hacerlo. Por supuesto, lo mejor habría sido que Microsoft lo informara ellos mismos para que pudiéramos tener todos los detalles, pero decidieron no hacerlo.