Demostrar, no solo decir: lo que Evo Continuous Offensive Security encontró en un SaaS empresarial real

Los ataques autónomos con IA dejaron definitivamente atrás las demostraciones de investigación que tanto asombraban a todos para convertirse en un procedimiento operativo estándar. Para quienes han prestado suficiente atención, esto no es necesariamente una novedad: en junio, la alianza Five Eyes advirtió que la IA evadirá la ciberseguridad en cuestión de meses, no de años, y que los tiempos de penetración de los adversarios ya pueden medirse en segundos. La propia Gartner predijo algo similar y anticipó que la ventana de explotación se reduciría a la mitad tan pronto como el próximo año.

Descubre lo que pueden encontrar los atacantes antes de que lo hagan.

Esto hace que nuestro anuncio sobre la disponibilidad de Evo Continuous Offensive Security sea aún más relevante y oportuno. Ofrecemos seguridad ofensiva autónoma que ataca continuamente tus aplicaciones y sistemas de IA, tal como lo haría un equipo líder de red team humano, mediante tres capacidades integradas: Pruebas de penetración con IA, Red teaming de agentes y Pruebas dinámicas (DAST).

COS está diseñado para ser el pentester de IA más preciso y confiable del mercado. Antes de que llegue a ti, cada hallazgo es validado por un «juez independiente», por así decirlo, para comprobar que la explotación sea real y reproducible. Así, tu informe final solo incluye aquello que un atacante podría explotar en la práctica.

Pero, en lugar de solo decirte lo que puede hacer, queremos mostrártelo. Todo lo que sigue corresponde a una evaluación real de la aplicación de un cliente y a dos de las vulnerabilidades reales que encontró y comprobó.

Evaluación real de la aplicación SaaS multiinquilino de un cliente

Uno de nuestros clientes usó COS para evaluar una aplicación SaaS empresarial multiinquilino. Esta incluía una aplicación de página única (SPA) de frontend, utilizada como cliente web, que a su vez consume un conjunto de cientos de endpoints de microservicios que conforman su lógica de negocio.

Esta aplicación es particularmente interesante porque resulta difícil de evaluar de distintas maneras, tanto para los pentesters humanos como para las herramientas deterministas, como un escáner DAST:

Para las personas, es muy difícil garantizar una cobertura completa de la autorización y la lógica de negocio de cientos de microservicios. Para las máquinas, el desafío no es el acceso. Los escáneres DAST modernos, como Snyk API & Web (la capacidad de pruebas dinámicas de Evo COS), pueden autenticarse en SPA y enumerar sin mayor problema los endpoints que hay detrás. La dificultad está en casi todo lo que viene después, porque las fallas de autorización y de lógica de negocio no tienen una firma con la que compararlas: decidir si un rol específico debería poder invocar cierto endpoint o si una secuencia de solicitudes, válidas por separado, produce un resultado que la aplicación nunca tuvo previsto requiere conocer el propósito de la aplicación y lo que cada actor debería poder hacer. Ahora imagina esa situación en cientos de microservicios y verás que se trata mucho más de un problema de razonamiento que de cobertura. Y eso es lo que las pruebas dinámicas aún no han automatizado.

La solución agéntica de COS «exploró» la aplicación de forma metódica y guiada, aprovechando el poder de los LLM:

• Comprobaciones previas: probó las credenciales proporcionadas mediante un navegador sin interfaz gráfica y verificó que se pudiera acceder a todos los recursos necesarios de la aplicación y que esta estuviera en condiciones de ser evaluada.

• Reconocimiento inicial: un subagente dedicado identificó la pila tecnológica de la aplicación, los distintos endpoints existentes e información relevante para la seguridad, como el uso de un WAF, agentes LLM expuestos mediante interfaces de chat, el flujo de autenticación, entre otros. Y, algo fundamental, este paso también permitió conocer el modelo de negocio de la aplicación. En este caso, infirió correctamente para qué servía el producto, quiénes lo usaban y cuáles de sus flujos de trabajo tenían valor comercial real. Para ello, solo contaba con un entorno de pruebas, poca documentación y datos de prueba precargados. Esa inferencia permitió evaluar todo lo que vino después en función del impacto en el negocio, y no de la gravedad técnica.

• Pruebas y validación de vulnerabilidades: se generaron subagentes especializados para buscar clases específicas de vulnerabilidades, a partir de los resultados del reconocimiento. Subagentes adversariales realizaron una validación cruzada de cada hallazgo para garantizar que pudiera reproducirse de forma independiente y reducir al mínimo la posibilidad de falsos positivos.

• Encadenamiento y validación de vulnerabilidades: las vulnerabilidades individuales se relacionaron lógicamente para verificar si podían aprovecharse en conjunto y aumentar el impacto en el negocio. Los subagentes adversariales también validaron y reprodujeron las cadenas de vulnerabilidades.

• Elaboración del informe: los hallazgos se compilaron en un documento que imitaba el resultado de un equipo humano, con un resumen ejecutivo y una lista priorizada de acciones para reducir el riesgo.

Esta evaluación se realizó con un enfoque de caja negra pura, es decir, sin acceso al código fuente. También podemos usar un enfoque de caja gris y aprovechar el acceso al código fuente para mejorar la detección y la eficiencia, pero en este caso decidimos no hacerlo. En cualquier caso, estamos poniendo énfasis en el componente dinámico de las pruebas: atacar la aplicación desde afuera hacia adentro, tal como lo haría un atacante real.

Entonces, ¿qué ventajas hemos observado con este enfoque?

1. Poder identificar los objetivos de negocio de las aplicaciones es una ventaja real, sobre todo cuando no son del todo evidentes. Este era un entorno de pruebas «desordenado», con pocos datos reales, lo que dificultaba la tarea incluso para una persona. Identificar los objetivos de negocio ayuda a que el conjunto de agentes interprete mejor el impacto de ciertas vulnerabilidades en el negocio.

2. Nuestros agentes controlan un navegador real y se adaptan a cualquier método de autenticación que la aplicación les presente, sin necesidad de crear scripts específicos para cada objetivo. En una evaluación, el inicio de sesión del cliente estaba protegido por autenticación de dos factores (2FA) basada en el tiempo. Proporcionamos la semilla TOTP y el agente se encargó de generar códigos de un solo uso como parte del proceso para descubrir cómo iniciar sesión, no porque lo hubiéramos configurado expresamente para hacerlo. Esto importa menos como capacidad que como garantía de confiabilidad: la autenticación es el punto en el que las pruebas automatizadas suelen fallar sin dar aviso, y una evaluación que nunca pasa de la página de inicio de sesión no sirve de nada, por muy buenas que sean las pruebas.

3. Con un enfoque guiado, metódico y multiagente, aprovechamos las ventajas de agentes creativos similares a las personas y, al mismo tiempo, garantizamos la cobertura de las pruebas: evaluamos sistemáticamente cada microservicio en busca de fallas de autorización, autenticación y lógica de negocio.

Las vulnerabilidades que encontró

En esta aplicación encontramos un total de 33 vulnerabilidades confirmadas, desde problemas de bajo impacto, como el uso de bibliotecas jQuery obsoletas o inseguras, hasta varias vulnerabilidades críticas. Entre estas últimas había una política CORS insegura que permite que sitios maliciosos arbitrarios roben tokens de autorización y actúen en nombre de un usuario (sin que este tenga que hacer nada), además de fallas en los niveles de autorización que permiten que cualquier usuario se convierta en administrador de su inquilino.

Para ser breves, destacaremos dos hallazgos que muestran en conjunto los dos aspectos que distinguen este enfoque: encontrar lo que otras herramientas no pueden encontrar por su diseño y comunicar el verdadero impacto de lo que sí pueden encontrar.

1. Compromiso de todo un inquilino mediante asignación masiva y fallas de autorización a nivel de función

Este es justamente el tipo de hallazgo que un escáner DAST no puede producir por su diseño y que un pentester humano necesitaría conocer a fondo la aplicación para encontrar. No hay una carga útil reflejada que detectar ni un error evidente que investigar: la falla reside por completo en la lógica de autorización de la aplicación, en un endpoint administrativo heredado que administra la configuración de todo un inquilino.

Nuestro agente identificó que un endpoint JSON heredado, usado para guardar la configuración de las cuentas de todo un inquilino, realizaba una operación upsert ilimitada de pares clave/valor sin verificar en el servidor los roles o permisos, y tampoco exigía los parámetros de signature / timestamp con estilo HMAC que, según parecía, requería. A partir de ahí, razonó sobre las consecuencias y las encadenó: el rol de usuario con menos privilegios —el que se asigna al iniciar sesión a cada empleado de base y que ni siquiera permite abrir la interfaz de administración— podía modificar cualquier configuración crítica para la seguridad de todo el inquilino. Además, varios de esos ajustes podían usarse para lograr un compromiso total.

Todo el proceso, desde el descubrimiento hasta la validación de una cadena reproducida de forma independiente, se completó en una sola ejecución sin supervisión humana. Por lo general, un equipo humano necesitaría varios días para familiarizarse con la aplicación y llegar a la misma conclusión.

Aquí tienes un fragmento ligeramente editado del informe del agente (se generalizaron todos los detalles específicos del cliente y del producto):

Un endpoint administrativo heredado de «guardar configuración de la cuenta» realiza una operación upsert ilimitada de pares clave/valor en el almacén de configuración de todo el inquilino, sin verificar en el servidor los roles o permisos ni validar los parámetros de consulta complementarios de estilo HMAC signature / timestamp . Cualquier usuario autenticado del inquilino, incluso quien tenga el rol con menos privilegios (que ni siquiera puede acceder a la interfaz de administración), puede invocar el endpoint con un token de acceso Bearer estándar y modificar cualquier configuración crítica para la seguridad de todo el inquilino.

[...]

El conjunto de claves afectadas incluye:

• Política de contraseñas: complejidad, longitud mínima, cantidad de contraseñas anteriores y antigüedad máxima.

• Política de bloqueo de autenticación: umbral de intentos fallidos y duración del bloqueo.

• Lista de bloqueo de tipos de archivos ejecutables para cargas.

• Orígenes adicionales de Content-Security-Policy.

• Dominio de envío para los correos electrónicos salientes del inquilino.

• Parámetros de integración OAuth para una integración empresarial de terceros (ID de cliente, secreto de cliente, URL de inicio de sesión, recurso y estado de habilitación).

• Nuevas claves arbitrarias definidas por el atacante.

Causas raíz:

1. Falta de verificación de roles o permisos en el método de escritura. 2. No hay una lista de claves permitidas; el endpoint acepta cualquier cadena como clave. 3. No se exigen los parámetros de consulta de estilo HMAC signature / timestamp que, según parece, requiere el endpoint. La prueba se realizó con una firma deliberadamente inválida y aun así tuvo éxito.

El informe continúa detallando los pasos necesarios para reproducir esta vulnerabilidad e incluye una sección sobre el impacto en el negocio, que citamos aquí (también generalizada):

Impacto:

Como un usuario con los menores privilegios tiene control total de lectura y escritura sobre la configuración de seguridad de todo el inquilino, una sola cuenta de inquilino comprometida o maliciosa (o cualquier persona interna con acceso legítimo de bajo privilegio) puede:

1. Tomar el control total de las cuentas de todos los usuarios del inquilino debilitando la política de contraseñas (por ejemplo, al permitir contraseñas de un solo carácter y eliminar los requisitos de complejidad) y deshabilitando la política de bloqueo; después, puede probar contraseñas en línea contra el endpoint de inicio de sesión del inquilino.

2. Distribuir malware en todo el inquilino al borrar la lista de bloqueo de archivos ejecutables y cargar ejecutables nativos mediante la interfaz de carga de contenido, a la que los usuarios con pocos privilegios ya pueden acceder. Los archivos cargados se propagan a todos los usuarios que consultan el contenido compartido del inquilino.

3. Habilitar el scripting entre sitios agregando orígenes controlados por el atacante a la lista de permitidos de Content-Security-Policy y ampliando script-src y connect-src para el inquilino.

4. Arma un ataque con el correo saliente al reescribir el dominio del remitente, haciendo que las notificaciones del inquilino parezcan provenir de un dominio controlado por un atacante (lo que permite crear correos de phishing internos muy convincentes, firmados y que superan SPF/DKIM mediante la infraestructura del inquilino).

5. Secuestra la integración OAuth de terceros al reescribir su URL de inicio de sesión, ID de cliente y parámetros de recursos, redirige el intercambio de código/token de OAuth a la infraestructura del atacante y obtiene las credenciales OAuth que el inquilino emite para quien cree que es su proveedor de identidad.

6. Mantén el acceso entre sesiones. Los cambios persisten más allá de la vida útil de ~30 minutos del token OIDC del atacante, por lo que el inquilino permanece con la configuración debilitada hasta que un administrador detecta y revierte manualmente cada clave.

7. Provoca una denegación de servicio en las páginas de administración al escribir una configuración mal formada que hace que la interfaz de administración se bloquee en el siguiente análisis.

El único requisito es un token de acceso OIDC con los privilegios más bajos, exactamente el token que se emite al iniciar sesión a cada usuario real del inquilino (incluidos todos los empleados sin privilegios). No hay ninguna barrera adicional, alcance de administrador ni firma requerida.

Esta es la capa de razonamiento a la que los escáneres tradicionales no pueden llegar: reconocer una escritura sin restricciones, entender qué significa cada configuración para el negocio y combinar varias para comprometer todo el inquilino.

2. Reflejo del origen CORS: un hallazgo «trivial» que queda fuera de toda duda

Las configuraciones incorrectas de intercambio de recursos de origen cruzado (CORS) son de las vulnerabilidades web más comunes. Prácticamente cualquier escáner y cualquier evaluador competente señalarán un endpoint que refleja el Origin de la solicitud en Access-Control-Allow-Origin y devuelve Access-Control-Allow-Credentials: true. Detectarlo no es lo difícil.

Lo difícil es uno de los problemas más persistentes y menos comentados de la industria: se reporta una vulnerabilidad y nadie en las etapas posteriores puede traducirla en lo que realmente significa para el negocio. Esto sucede porque los niveles de gravedad transmiten bien la urgencia, pero no suelen comunicar las consecuencias reales.

El hallazgo llega como el nombre de una clase y una puntuación CVSS, y el equipo que lo recibe tiene que decidir qué tan importante es con información que nunca explica el posible resultado. Entonces, recurre al análisis más sencillo y se guía solo por la cifra.

Todo lo etiquetado como medio queda detrás de lo etiquetado como alto, y el resultado no es solo una demora, sino una verdadera asignación inadecuada de esfuerzos: los riesgos reales quedan sin atender en el backlog mientras los equipos corrigen hallazgos más fáciles de entender. La evaluación de riesgos solo es tan buena como el análisis de impacto que la alimenta y, en la mayoría de las herramientas, ese análisis queda a criterio de quien lo lee.

Este hallazgo es un claro ejemplo. En un informe típico de un escáner, aparece como una sola línea de gravedad media sobre un encabezado permisivo. En realidad, significaba que cualquier sitio web que visitara un usuario con sesión iniciada podía leer su sesión sin que lo supiera y robar los tokens que permiten actuar en su nombre, sin necesidad de interacción ni phishing.

La configuración incorrecta estaba en el proveedor de identidad, se aplicaba a todos los endpoints de la aplicación y los tokens de acceso se devolvían en el cuerpo de las respuestas de origen cruzado. Por eso, el problema va mucho más allá de la higiene de encabezados: se convierte en la toma de control completa de la cuenta de cualquier usuario que visite por casualidad la página «equivocada». Y, mientras tanto, la vulnerabilidad seguía en la categoría «media».

Lo que más impresionó a nuestro cliente y socio de diseño no fue solo que lograra encontrarla, sino lo que hizo después. Además de describir el problema y su impacto en el negocio, el agente creó en cuestión de minutos una prueba de concepto completamente funcional que reprodujo todo el ataque en una instalación estándar del navegador Chrome: abre la página y observa cómo se exfiltra tu propio token de acceso a un origen controlado por un atacante.

Un desarrollador del equipo del cliente pudo ver de inmediato, en lugar de que se lo explicaran, que el hallazgo implica el compromiso real de una cuenta, sin proxy, conocimientos de seguridad ni herramientas especializadas. Al final, esa será la diferencia entre un hallazgo que se clasifica y uno que se corrige.

También puedes consultar hallazgos como este directamente en la plataforma Evo: puedes pedirle a un hallazgo que se explique en lenguaje sencillo o que sugiera una solución, así la demostración y la corrección están en el mismo lugar.

Esa es la diferencia que nos importa: no detectar CORS, algo trivial, sino reducir la distancia entre un hallazgo de bajo esfuerzo y una demostración irrefutable de su impacto en el mundo real.

Dos hallazgos, dos fortalezas distintas

Esto demuestra que COS se diferencia tanto por su capacidad para profundizar como por comunicar correctamente el impacto.

En cuanto a la profundidad, se trata de reconocer una falla de autorización que un escáner no puede detectar y que a una persona le tomaría días encontrar. Y en cuanto a la comunicación, se trata de tomar un hallazgo que cualquier herramienta puede detectar y hacer que su impacto en el mundo real sea innegable.

Para un modelo capaz, encontrar vulnerabilidades es la parte fácil. Lo difícil es comunicarlas bien, sin ruido y de una manera que permita al público previsto actuar. Ahí es donde concentramos gran parte de nuestro trabajo de ingeniería.

Míralo en acción

Todo lo anterior surgió de una sola ejecución sin supervisión en una aplicación real. Y, en lugar de pedirte que nos creas, es mejor que lo veas por ti mismo.

Para conocer en detalle cómo AI Pentesting, Agent Red Teaming y Dynamic Testing funcionan como un solo sistema, y por qué la cobertura continua supera a una prueba de penetración una o dos veces al año, empieza por nuestro anuncio de lanzamiento e inscríbete en nuestro próximo webinar, Pentesting-Grade Coverage at the Speed of AI, el 2 de septiembre.