Analiza esa frase y observa cuánto trabajo está haciendo la expresión "ningún dato del cliente estuvo en riesgo".

Amazon Quick se describe en su propia página de producto como un asistente de IA que "conecta Slack, Microsoft Teams y Outlook, CRMs, bases de datos y documentos en un solo lugar" y "fundamenta cada respuesta en sus datos reales de negocio". El agente de chat predeterminado, que se provisiona automática y molestamente en el instante en que se activa Quick, quiera el cliente esas funciones de IA o no, es el front-end de esos datos. Es el propósito fundamental del front-end de esos datos.

Ahora considera el escenario real que AWS acaba de parchear. Un administrador en, digamos, un banco regulado (un banco no regulado se llama "una empresa criminal que aún no ha sido atrapada") configura permisos personalizados denegando el acceso al agente de chat a un grupo grande de usuarios. Tal vez esos usuarios son contratistas. Tal vez están en una unidad de negocio que no tiene autorización para usar herramientas de IA. Tal vez la postura de cumplimiento del banco prohíbe rotundamente el uso de IA en la sombra sobre datos internos. Hasta hace dos meses, cada uno de esos usuarios podía enviar una solicitud HTTP directamente al endpoint del agente y obtener una respuesta.

Fog preguntó sobre los mangos porque son una firma de seguridad realizando una divulgación limpia, no un infiltrado malicioso. Un infiltrado malicioso no habría preguntado por los mangos.

La pregunta para AWS, sin retórica: ¿En qué sentido los datos del cliente no estuvieron en riesgo? O bien el agente de chat no tiene realmente acceso a los datos que la página del producto dice que tiene (en cuyo caso el departamento de marketing tiene que dar muchas explicaciones), o usuarios no autorizados podían consultar un agente conectado a los datos del cliente, en cuyo caso "los datos del cliente estuvieron en riesgo" es la descripción correcta de la situación en inglés.

AWS aclara, y dice la parte callada en voz alta

Después de que esta historia empezara a circular, AWS ofreció un comentario de seguimiento que agradezco sinceramente, porque es mucho más honesto que el primero. Según un portavoz de AWS que parecía acosado: "El investigador estaba utilizando la capacidad de Control de Administrador que ningún cliente estaba utilizando activamente cuando la validación del lado del servidor no estaba presente".

Leer eso dos veces no ayuda. Permítanme traducir.

AWS está diciendo: Sí, faltaba la comprobación de autorización del lado del servidor. Sí, un usuario autenticado en su cuenta de Quick podía saltarse el único mecanismo de control de acceso que ofrece el servicio. La razón por la que esto está bien, aparentemente, es que ningún cliente real se había molestado en configurar ese control de acceso durante la ventana de tiempo en que no funcionaba.

¿Eh... qué?

La defensa no es "el error no era real", que es lo que podrías haber entendido en la primera declaración de AWS. La defensa tampoco es "el error no podría haber hecho lo que Fog dice que podría haber hecho", que es la implicación aún más fuerte de su primera declaración. La defensa es "el control de acceso no aplicaba lo que dijimos que hacía, pero por suerte nadie dependía de él". Esto es el equivalente en comunicación corporativa a decir: "la cerradura de la puerta principal no funcionaba, pero nadie la había cerrado de todos modos, así que ¿por qué estás molesto?".

También es una afirmación de telemetría sorprendentemente específica. AWS afirma saber que cero clientes habían configurado permisos personalizados para denegar el acceso al agente de chat durante la ventana de exposición. Eso es algo muy seguro de decir, y algo aún más interesante de ofrecer como defensa, porque funciona como una crítica demoledora del modelo de gestión de accesos de Quick: la única perilla que el servicio proporciona para este propósito, la que la propia documentación de AWS dice explícitamente a los administradores que utilicen, tiene cero adopción registrada.

El mismo seguimiento también remitió al hilo de HackerOne para demostrar que AWS dijo a Fog durante toda la ventana de divulgación que "la autorización basada en el usuario se mantuvo aplicada". Traducción: necesitabas credenciales autenticadas en la misma cuenta de Quick para explotar esto. Sí. Eso es el alcance intra-cuenta, que Fog documentó en su análisis, y que es precisamente el alcance en el que los permisos personalizados deberían funcionar como un límite de seguridad. Que AWS diga que "la autorización basada en el usuario estaba bien" es decir "no podías explotar esto anónimamente desde internet", que nunca fue el modelo de amenaza en cuestión. El modelo de amenaza es el contratista con credenciales SSO válidas cuyo administrador intentó bloquearlo de algunos conjuntos de datos.

Por qué esto importa más de lo que parece

El modelo de acceso de Amazon Quick ya es un caso atípico: las políticas de IAM no rigen al Agente de Chat de IA de Quick, las SCP no se aplican y las RCP no se aplican. Los permisos personalizados son la única perilla que proporciona el servicio. Si esos no se aplican, nada más lo hace. Y según el propio seguimiento de AWS, literalmente nadie los estaba usando de todos modos. Ambas mitades de esa frase deberían ser alarmantes, y AWS las ofrece como tranquilidad.

El foso competitivo de AWS durante la última década no ha sido el precio. Desde luego no ha sido la experiencia del desarrollador, la documentación, el diseño de la consola o la inescrutable poesía de los nombres de los servicios. Ha sido la creencia bien ganada de que AWS hace bien las cosas fundamentales: límites, identidad, durabilidad, confiabilidad y las partes que los clientes no pueden verificar fácilmente por sí mismos. Los clientes han pagado la prima de AWS porque confiaban en las cosas aburridas.

Este año esa confianza se está poniendo a prueba de una manera que no había ocurrido antes. La cadencia de avisos de seguridad de AWS de 2025–2026 ha aumentado notablemente, por razones que aún no están claras. Las divulgaciones coordinadas de investigadores independientes siguen revelando comprobaciones de autorización ausentes en servicios más nuevos y relacionados con la IA.

Las correcciones llegan rápido, lo cual es bueno. La comunicación con el cliente no llega en absoluto, lo cual es, siendo caritativos, una elección. Una calificación de "severidad: ninguna" en una omisión del único control de acceso que ofrece un servicio no es tanto un hallazgo de seguridad objetivo como una decisión de comunicación. Y la decisión de comunicación ahora se lee, con el beneficio del seguimiento de AWS: "Arreglaremos el error, no te diremos que existió y, si preguntas, te explicaremos que de todos modos no estabas usando la función".

AWS recibe mucho perdón en las cosas pequeñas porque son dueños de las cosas grandes. Quizás quieran reconsiderar cuántas de las cosas grandes siguen clasificando como "ninguna".

Fuente:
TheRegister