Ostorlab face au pentest manuel : davantage de vulnérabilités critiques, moins de temps et de coûts

Ostorlab automatise les tâches de test d’intrusion qui exigent habituellement qu’un pentesteur examine le comportement de l’application, formule des hypothèses d’attaque, exécute des tests et valide leur impact. Pour les équipes AppSec qui achètent des pentests manuels, la comparaison consiste à déterminer si Ostorlab peut trouver davantage de vulnérabilités critiques, livrer les résultats plus tôt et réduire le coût de l’évaluation à périmètre identique.

Notre équipe rapporte qu’Ostorlab a trouvé davantage de vulnérabilités critiques, terminé les tests plus tôt et coûté entre un dixième et un quarantième du prix des pentests manuels menés en parallèle, dans chaque preuve de concept comparative achevée. Ces comparaisons ont porté sur des applications mobiles, des applications web, du code source et des tests Active Directory.

Ostorlab face au pentest manuel : résultats rapportés des PoC

Il s’agit des résultats des missions de notre équipe, pour les périmètres et conditions d’accès évalués. Ce n’est ni un benchmark indépendant ni une garantie pour une autre application. Cet article ne publie pas la taille de la cohorte, les nombres de vulnérabilités appariées, les durées des missions ou la ventilation détaillée des coûts. La plage de coûts rapportée ne constitue donc pas une prévision de vos économies totales ; une comparaison sur votre périmètre doit inclure la préparation, la revue humaine, les contre-tests et l’effort d’ingénierie.

Les cas techniques expliquent le travail d’investigation et de validation derrière les résultats d’Ostorlab. Dans une évaluation mobile, l’agent a extrait des identifiants d’un binaire Flutter iOS, testé les audiences API autorisées et démontré un accès à une API de gestion des identités. Dans une évaluation d’application d’entreprise, il a obtenu un jeton d’administration sans secret client et l’a utilisé pour atteindre une fonctionnalité exécutant du code fourni côté serveur. Ce sont des exemples du travail d’investigation qu’un client confie à un pentesteur.

Les preuves techniques derrière la comparaison

Les exemples anonymisés suivants proviennent des fiches de vulnérabilités et des historiques d’exécution d’Ostorlab. Ils montrent ce que la plateforme a examiné et confirmé. Ils n’identifient pas les vulnérabilités manquées par un pentesteur humain donné et n’étayent pas indépendamment les résultats comparatifs agrégés ; les tableaux de résultats par client et les rapports d’audit ne sont pas publiés ici.

Le cas des identifiants mobiles et la chaîne allant du jeton sans secret à l’exécution serveur sont détaillés dans les cas 1–3. Les preuves techniques complémentaires couvrent l’inscription, la signature et la journalisation. Un exemple AD distinct en laboratoire y figure pour les lecteurs qui évaluent les tests internes ; il ne constitue pas une preuve comparative client. Les extraits de code utilisent des valeurs synthétiques et illustrent les mécanismes rapportés, sans reproduire des échanges capturés chez les clients.

Pour examiner le livrable avant de convenir d’un appel, ouvrez le rapport exemple web ou le rapport exemple mobile.

Cas 1 : des identifiants divulgués dans une application mobile ont donné accès à l’API de gestion du tenant

Ostorlab a évalué une application iOS développée avec Flutter qui utilisait des identifiants machine-to-machine Auth0 pour obtenir des jetons d’accès API. Le binaire compilé de l’application contenait le client_id et le client_secret, fournis au moment du build par le mécanisme DART_DEFINES de Flutter. L’évaluation a testé la validité de ces identifiants et les API auxquelles ils donnaient accès.

La frontière de sécurité attendue. Les identifiants machine-to-machine doivent être limités à l’audience et aux opérations nécessaires à leur service. Des identifiants embarqués dans un client distribué ne sont pas secrets ; ils sont accessibles à quiconque peut obtenir le build. L’évaluation a donc examiné à la fois leur validité et les autres services auprès desquels ils permettaient de s’authentifier.

L’investigation. L’agent a extrait les identifiants du binaire Mach-O et demandé un jeton au point de terminaison /oauth/token du tenant. La requête a réussi avec une réponse HTTP 200 et un JWT signé ; des identifiants inventés ont renvoyé HTTP 401. Le jeton portait un scope read:TSC, un grant client-credentials et une clé de signature rattachable au point de terminaison JWKS du tenant.

La vulnérabilité initiale a reçu une sévérité élevée. La fiche porte aussi le statut « Corrigé et vérifié », mais les éléments disponibles pour ce cas ne documentent ni la correction ni la chronologie de son contre-test. Ce statut seul n’établit pas que les identifiants ont fait l’objet d’une rotation ou que leur accès a été supprimé.

Pour évaluer l’accès au-delà de l’API utilisée par l’application, Ostorlab a envoyé des demandes de jeton pour 38 audiences candidates au même point de terminaison. Dans ces requêtes, l’audience identifie l’API à laquelle l’accès est demandé. Une demande visant l’audience Management API du tenant a renvoyé HTTP 200 avec un jeton portant huit scopes, dont update:users, delete:users, create:users et create:client_credentials. Une seule requête GET non destructive vers Management API a renvoyé la première page d’un annuaire de 1 000 utilisateurs contenant des adresses e-mail, numéros de téléphone, dernières adresses IP et comportements de connexion. L’évaluation a démontré cette lecture ; elle n’a pas exercé les permissions de création, modification ou suppression d’utilisateurs du jeton.

Le point de terminaison de jetons a accepté les identifiants client extraits pour l’audience du service interne comme pour celle de Management API. Une requête ultérieure à l’annuaire a confirmé l’accès en lecture via Management API.

Séquence HTTP illustrative · valeurs synthétiques d’hôte, de client et de jeton.

# The credential is extracted from the mobile binary.
POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=AUDIENCE_A
# Article outcome: a read:TSC token for the internal service.

POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=MANAGEMENT_API
# Article outcome: a token with eight management scopes.

GET /api/v2/users?per_page=100 HTTP/1.1
Host: tenant.example.invalid
Authorization: Bearer FAKE_MANAGEMENT_TOKEN

# Article outcome: the first page of a 1,000-record directory.

Résultat de l’évaluation. Les identifiants extraits permettaient d’obtenir des jetons pour le service interne et Management API. La lecture de l’annuaire a confirmé l’accès à des informations personnelles ; les permissions d’écriture de gestion sont restées non testées. La vérification de la remédiation doit donc couvrir les audiences autorisées du client, et pas uniquement l’API appelée par l’application. Les fiches disponibles ne documentent pas la correction tentée entre les deux vulnérabilités.

Ce qu’Ostorlab a automatisé. Cette évaluation a combiné analyse binaire, validation réelle des identifiants, énumération des audiences et lecture contrôlée d’une API. Un pentesteur menant manuellement cette investigation devrait exécuter et relier les mêmes étapes. Ostorlab a établi les accès utilisables des identifiants au-delà de l’API appelée par l’application, donnant à l’équipe AppSec une exposition validée à prioriser et une exigence de contre-test plus large.

Orientation de la remédiation. Retirez le secret du client et procédez à sa rotation. Examinez les audiences et scopes autorisés du client, et séparez les identifiants de gestion du tenant des identifiants des services accessibles aux clients. Invalidez les jetons émis sous la configuration vulnérable. Le contre-test doit énumérer toute la surface d’autorisation du client, et pas seulement l’audience appelée par l’application.

Une analyse plus détaillée de ce cas est disponible dans l’étude de cas Agentic Deep Scan.

Cas 2 : accès administratif à partir d’une demande de jeton sans secret

Dans une évaluation d’application d’entreprise, Ostorlab a découvert une configuration du service d’identité qui émettait des jetons d’administration sans secret client. L’investigation a établi que le jeton était utilisable : une opération protégée de l’annuaire l’a accepté et a renvoyé des centaines de profils de l’organisation. Les informations d’expiration retournées montraient que le jeton pouvait rester valide bien au-delà d’une courte session, augmentant le risque de persistance.

La frontière de sécurité attendue. Un client qui demande un accès administratif doit établir l’identité et l’autorité nécessaires à cet accès. Un jeton émis doit également avoir une audience, un scope et une durée de validité convenablement restreints. Le test a examiné l’émission et l’utilisation, car il s’agit de deux décisions de sécurité distinctes.

L’investigation. Ostorlab a envoyé une demande de jeton avec un identifiant client et un scope administratif, sans secret client. Le service d’identité a renvoyé un jeton bearer. Ostorlab a ensuite examiné les claims du jeton retourné et l’a utilisé sur une opération protégée de l’annuaire, qui a renvoyé des profils de l’organisation.

L’émission et l’acceptation sont des contrôles distincts. L’évaluation a démontré les deux : une demande de jeton sans secret a produit un identifiant d’accès accepté par une opération protégée de l’annuaire.

Séquence HTTP illustrative · routes, valeurs de champs et espaces réservés de jetons synthétiques.

# Request shape is illustrative; the article omits routes and exact fields.
POST /example/token HTTP/1.1
Host: identity.example.invalid
Content-Type: application/x-www-form-urlencoded

client_id=DEMO_CLIENT&scope=DEMO_ADMIN_SCOPE
# No client_secret and no client-authentication header.
# Article outcome: an administrative bearer token was issued.

GET /example/protected-directory HTTP/1.1
Host: directory.example.invalid
Authorization: Bearer FAKE_ISSUED_TOKEN

# Article outcome: protected access returned organizational profiles.
# Synthetic request shape; this is not a literal captured exchange.

Résultat de l’évaluation. Le test a démontré à la fois l’émission d’un jeton sans secret client et son acceptation par une opération protégée de l’annuaire. La requête à l’annuaire utilisait le jeton obtenu par le chemin d’émission testé, et non des identifiants administrateur fournis. Cela établit un lien entre la mauvaise configuration du service d’identité et l’accès non autorisé à l’API.

Orientation de la remédiation. Examinez les exigences d’authentification du client et les types de grant autorisés ; restreignez ses scopes et audiences ; réduisez la durée de validité selon son usage ; et invalidez, selon les besoins, les identifiants émis sous la configuration vulnérable. Le contre-test doit couvrir les nouvelles tentatives d’émission et le traitement des identifiants déjà émis.

Le contre-test de remédiation doit vérifier les deux contrôles : l’authentification du client au point de terminaison de jetons et l’autorisation au niveau de l’API protégée.

Cas 3 : une fonctionnalité d’intégration a exécuté du code serveur fourni

Dans la même évaluation d’application d’entreprise, Ostorlab a utilisé le jeton d’administration du cas 2 pour accéder à une fonctionnalité d’intégration authentifiée dans un module IAM fourni par un éditeur. Cette fonctionnalité acceptait du C# personnalisé et le compilait dans le processus du serveur applicatif. Des tests de temporisation contrôlés, l’exécution de sous-processus, des diagnostics de l’hôte et des contrôles réseau sortants ont démontré une exécution sous l’identité du pool d’applications IIS, un compte membre de BUILTIN\Administrators disposant de SeDebugPrivilege et de SeImpersonatePrivilege.

La frontière de sécurité attendue. Les fonctionnalités d’extensibilité nécessitent un modèle de confiance explicite : qui peut fournir du code exécutable, où il s’exécute et avec quels privilèges. L’accès à un écran de configuration d’intégration ne constitue pas, à lui seul, une frontière de confiance acceptable pour exécuter du code fourni dans un processus applicatif privilégié.

L’investigation. L’agent a utilisé l’interface attendue par la fonctionnalité. Il a écrit une sonde implémentant cette interface, de sorte que le payload a passé la compilation et les contrôles de type avant l’exécution de son constructeur. L’application utilisait Roslyn pour compiler le code source dans son processus, chargeait l’assembly produit avec AssemblyLoadContext.Default.LoadFromStream() et créait l’instance avec Activator.CreateInstance().

Une requête normale a établi la référence. Les payloads des constructeurs ont introduit des délais contrôlés. Les temps de réponse enregistrés ont suivi la progression demandée : une référence d’environ 122 ms, puis environ 2,13 s, 5,14 s et 10,15 s pour les sondes de deux, cinq et dix secondes, les répétitions suivant le même schéma. Des tests supplémentaires ont enregistré l’exécution de sous-processus, l’identité exécutant le code et des connexions DNS et TCP sortantes vers un hôte contrôlé par le testeur.

La fonctionnalité d’intégration compilait et instançait le C# fourni dans son processus serveur. La progression des délais demandés étayait l’exécution du constructeur ; des tests de sous-processus, des diagnostics de l’hôte et des contrôles de sortie réseau distincts ont établi un impact supplémentaire.

Sonde C# illustrative · à adapter à l’interface d’intégration d’un environnement de test autorisé.

using System;
using System.Threading;

public sealed class IntegrationProbe
{
    // Implements the interface the integration feature expects.
    public IntegrationProbe()
    {
        Thread.Sleep(2000);
        Console.WriteLine(Environment.UserName);
    }
}

// Compare baseline with 2, 5, and 10 second constructor delays.
// This snippet illustrates timing and identity diagnostics only.
// The article reports subprocess execution and egress from separate tests.

Le contrôle négatif. L’agent a également testé un point de terminaison d’intégration voisin qui imposait un contrôle de type préalable à l’instanciation. La même sonde a été rejetée avant compilation ou instanciation, sans effet sur la temporisation. Ce contrôle a montré que les deux points de terminaison d’intégration appliquaient des validations différentes avant d’exécuter du code fourni.

Résultat de l’évaluation. Les tests de temporisation ont démontré l’exécution du constructeur. Des tests distincts de sous-processus, d’identité et de sortie réseau ont établi les privilèges d’exécution et l’accès réseau. Le point de terminaison d’intégration exigeait une authentification, fournie par le jeton obtenu dans le cas 2. La séquence démontrée était l’émission d’un jeton sans secret, l’accès administratif à l’API et l’exécution authentifiée de code côté serveur.

Orientation de la remédiation. Maintenez les intégrations non fiables hors du processus applicatif privilégié :

• Utilisez un processus de travail distinct avec une frontière de sécurité adaptée, imposée par le système d’exploitation. Un AssemblyLoadContext déchargeable permet de décharger des assemblies ; ce n’est pas un bac à sable de sécurité. Microsoft décrit la distinction entre l’isolation du chargement et les frontières de sécurité des processus.
• Attribuez au processus de travail une identité peu privilégiée, un accès restreint aux secrets et une liste d’autorisation des sorties réseau.
• Restreignez les personnes autorisées à créer ou modifier des intégrations.
• Retestez l’autorisation, l’identité du processus, l’accès aux ressources protégées et les sorties réseau interdites. Si l’exécution d’intégrations est une fonctionnalité prévue, une compilation réussie ne signifie pas, à elle seule, que le correctif a échoué.

Ce qu’Ostorlab a automatisé. Les cas 2 et 3 ont demandé à l’agent de réutiliser les identifiants issus d’une vulnérabilité dans un autre test, de construire une sonde compatible avec l’interface d’intégration, de comparer les temps mesurés et d’établir les privilèges du processus et l’accès réseau. Il s’agit d’une investigation de chaîne d’attaque et d’une validation d’impact dans le cadre de l’évaluation. La comparaison avec un pentest manuel doit examiner si chaque prestataire a trouvé et démontré le chemin complet, ainsi que le temps et le coût nécessaires.

Exécuter Ostorlab en parallèle d’un pentest manuel

Fournissez à Ostorlab et au prestataire de pentest manuel des cibles, comptes, accès et actions autorisées équivalents. Votre équipe pourra ainsi comparer l’investigation et les vulnérabilités validées dans les mêmes conditions. Commencez, si possible, par un environnement de préproduction représentatif et des comptes de test dédiés. Si des tests en production sont nécessaires, convenez avec le responsable de l’application des actions permises, de l’accès aux données, des limites de trafic et de l’escalade des incidents avant l’exécution. Une connexion découverte dans une application n’autorise pas automatiquement à tester son fournisseur d’identité ou son service d’analytique.

Utilisez ce plan opérationnel pour cadrer l’évaluation :

Ce sont des décisions de mission à confirmer avec l’équipe d’évaluation, et non la promesse que chaque action est automatiquement approuvée ou annulée.

Contrôles du périmètre et des actions

La mise à jour de la plateforme d’octobre décrit les consignes de périmètre, les exclusions du pare-feu, les contrôles du trafic, la surveillance et les approbations des actions demandées. La liste d’autorisation du périmètre guide l’agent ; ce n’est pas une frontière réseau stricte. Les exclusions du pare-feu bloquent les adresses et réseaux configurés. La surveillance ajoute la détection des écarts et un arrêt facultatif.

Les paramètres d’approbation régissent les décisions demandées par l’agent. « Me demander, bloquer sans réponse » laisse une action demandée en attente de décision ; ce mode n’exige pas une revue humaine avant chaque appel d’outil. L’opérateur doit configurer ces paramètres pour la mission.

Fenêtres d’exécution et conditions d’arrêt

Les fenêtres d’exécution définissent les jours, heures et fuseau horaire. Un scan créé hors de sa fenêtre attend ; un scan pouvant être mis en pause s’interrompt à la fermeture et reprend dans la fenêtre suivante. Les scans ne pouvant pas être mis en pause continuent jusqu’à leur terme après la fermeture. Confirmez le comportement du type de scan choisi avant de considérer l’heure de fermeture comme une limite opérationnelle. Un calendrier récurrent nécessite aussi une condition d’arrêt final distincte.

Consultez la documentation des fenêtres d’exécution pour les comportements de planification pris en charge. Ces captures d’écran sont des exemples de la plateforme provenant de la documentation publique, et non des preuves capturées lors des évaluations anonymisées.

Comparer les preuves d’investigation et le transfert aux équipes

Un nombre de vulnérabilités n’est utile que si votre équipe peut les vérifier. Comparez les preuves du prestataire manuel au dossier d’investigation d’Ostorlab, notamment la façon dont chacun a établi l’exploitabilité et l’impact. La vue d’analyse AI Pentest d’Ostorlab relie les plans et les tâches aux noms d’outils, arguments, sorties et horodatages enregistrés. Examinez une vulnérabilité importante depuis l’hypothèse initiale jusqu’à la réponse établissant l’impact. Le rapport doit distinguer une trace dans le code source, un test d’exécution réussi et une étape d’attaque bloquée.

Le transfert doit identifier les privilèges initiaux, l’impact reproduit, les branches infructueuses, les vérifications restantes et la correction proposée. Comptez les vulnérabilités validées distinctes en rapprochant les causes racines en doublon et les chaînes d’attaque. Ne comptez pas une hypothèse non testée comme une vulnérabilité critique confirmée.

Les journaux d’exécution aident aussi l’opérateur à vérifier le nettoyage. Une évaluation web examinée consignait la création d’une session de support, sa vérification, sa révocation, puis une nouvelle vérification confirmant la déconnexion. Appliquez la même rigueur aux configurations modifiées, fichiers téléversés et identifiants émis. Consignez explicitement les artefacts non résolus et désignez un responsable ; journaliser une action ne revient pas à l’annuler.

Étendre la comparaison jusqu’à la remédiation

La comparaison doit inclure le travail nécessaire pour transformer une vulnérabilité en correction vérifiée. Ostorlab peut accompagner une vulnérabilité jusqu’à la remédiation avec des recommandations personnalisées et des propositions de modifications de code livrées via les intégrations de dépôts prises en charge. Les développeurs examinent le diff résultant dans leur workflow habituel de pull request, exécutent les vérifications pertinentes et utilisent des tests de suivi pour déterminer si l’application modifiée résout le problème initial.

La correction proposée doit traiter le contrôle identifié par l’évaluation. Les vulnérabilités d’inscription exigent des vérifications de propriété des enregistrements ; les journaux contenant des identifiants exigent des modifications aux points d’appel de journalisation et de sérialisation ; les vulnérabilités de jetons sans secret exigent une revue de l’émission des jetons et de l’autorisation en aval.

Le tableau présente les critères de remédiation et de contre-test dérivés des cas ; il n’affirme pas qu’un correctif particulier a été créé ou fusionné :

• Ostorlab Autofix prend en charge les recommandations de correction personnalisées, les modifications via pull requests et les workflows de vérification de suivi.
• Les tests de code source maintiennent le lien entre les chemins affectés, les révisions du code et la remédiation.

Un correctif généré passe toujours par une revue d’ingénierie et des tests adaptés. Les preuves de l’évaluation de suivi éclairent la clôture ; un diff proposé ou un build réussi ne suffit pas à établir qu’un chemin exploitable a été éliminé.

Comparez ce workflow au service de remédiation et de contre-test inclus dans votre pentest manuel. Consignez si les développeurs peuvent reproduire la vulnérabilité, mettre en œuvre la correction proposée et vérifier que le chemin d’accès ou d’exécution initial est bloqué, ainsi que l’effort demandé à votre équipe.

Évaluer Ostorlab face à votre prestataire de pentest manuel

Utilisez les résultats rapportés des PoC comme proposition à tester : davantage de vulnérabilités critiques validées, des tests plus courts et un coût d’évaluation réduit. Une comparaison utile commence avec le même build, les mêmes cibles, comptes, accès au code source, permissions et exclusions. Convenez de la fenêtre d’évaluation et du traitement des modifications effectuées pendant les tests. Consignez les missions incomplètes et les limites au lieu de les retirer des résultats.

Avant d’autoriser un PoC, demandez un devis détaillé précisant les prestations incluses, limites d’usage, conditions de dépassement, contre-tests inclus et travail préparatoire du client. Convenez des dates de livraison après confirmation du périmètre et des accès. Utilisez ces conditions et l’effort réel pour déterminer si l’avantage de coût d’évaluation rapporté dans nos PoC achevés se traduit par un coût total réduit pour votre équipe.

Questions à régler avant de remplacer un pentest existant

Quelle place donner à Ostorlab dans notre programme de tests ? Utilisez une première évaluation parallèle pour décider quelles activités de test applicatif il peut prendre en charge sur votre périmètre : tests de workflows authentifiés, investigations entre applications et API et répétition des tests après modification. Maintenez une responsabilité humaine sur le périmètre, les intentions métier, les vulnérabilités contestées, les décisions opérationnelles et l’acceptation des corrections. Conservez des tests spécialisés pour les activités hors de la couverture convenue. Utilisez les vulnérabilités, les délais, les coûts et les exigences d’assurance pour décider quelle part de votre mission manuelle actuelle Ostorlab peut remplacer.

Devons-nous fournir le code source ? Ostorlab prend en charge les builds mobiles, applications web, API et tests de code source. Le cas des identifiants mobiles a commencé avec le binaire distribué ; les exemples de signature et de journalisation ont utilisé un accès au code source. Convenez explicitement du mode d’évaluation. Une revue limitée au code source ne peut pas prouver le comportement réel du backend, et un test limité à l’exécution offre une visibilité différente d’une évaluation avec accès au code source.

Que doit préparer notre équipe ? Fournissez le build ou les URL cibles, les services autorisés, des comptes de test séparés par rôle, des données de test représentatives et la documentation pertinente des API ou workflows. Pour les parcours connectés, organisez avec l’équipe d’évaluation la configuration de test MFA ou OTP requise. Identifiez un responsable de l’application, un opérateur et un contact d’ingénierie pour la reproduction et les contre-tests. Confirmez l’effort préparatoire lors du cadrage.

Où iront notre code, nos identifiants et nos preuves ? Examinez le Trust Center et les options de scan sur site avec vos équipes sécurité et achats. Confirmez le déploiement choisi, le fournisseur de modèles, les flux de données, la conservation et les contrôles d’accès avant de fournir des éléments sensibles ; ne supposez pas que tous les déploiements ont les mêmes dispositions.

Le rapport répondra-t-il à une exigence d’assurance externe ? Examinez un rapport exemple avec la partie qui demande l’évaluation. Confirmez le périmètre requis, la méthodologie, les qualifications ou l’indépendance des pentesteurs, la revue humaine, le rapport et les preuves de contre-test avant de modifier une mission existante. Demandez à Ostorlab de préciser la validation humaine et l’approbation incluses dans le service proposé. Une vulnérabilité technique seule n’établit pas l’acceptation pour toutes les exigences d’assurance.

Comparer Ostorlab à votre prochain pentest manuel

L’avantage rapporté d’Ostorlab sur le pentest manuel est un plus grand nombre de vulnérabilités critiques, une durée de test réduite et un coût d’évaluation inférieur. Les cas montrent le travail technique que la plateforme peut réaliser : examiner des identifiants sur plusieurs API, chaîner des faiblesses d’identité et d’exécution et valider l’impact par des tests enregistrés. Une comparaison sur votre application doit établir si ces capacités améliorent les résultats et les coûts de votre pentest actuel.

Apportez une application représentative, ses API connectées et votre périmètre actuel de pentest manuel. Utilisez la discussion de cadrage pour convenir des éléments suivants :

1. Entrées : build ou URL, comptes et rôles de test, accès au code source s’il est inclus, documentation, permissions et exclusions.
2. Livrables : rapport avec vulnérabilités reproduites et limites des preuves, accès au dossier d’investigation, remédiation proposée et transfert convenu pour le nettoyage et les contre-tests.
3. Critères de réussite : vulnérabilités validées et recoupements, délai de livraison exploitable, coût total et effort d’ingénierie, avec les mêmes définitions pour les deux prestataires.
4. Engagement : périmètre écrit, plan opérationnel, dates de livraison, devis détaillé et responsables désignés avant le début des tests.

Réservez un PoC Ostorlab face au pentest manuel pour convenir d’un périmètre équivalent, de critères de réussite et de conditions commerciales pour votre application. Commencez par le rapport exemple web ou le rapport exemple mobile si vous souhaitez d’abord examiner le format des preuves.

Preuves techniques complémentaires

Les sections suivantes documentent l’autorisation d’inscription, la signature mobile, la journalisation mobile et une évaluation Active Directory distincte en laboratoire. Chacune décrit la méthode de test, le résultat observé et les validations encore nécessaires.

Propriété d’une inscription : lectures et écritures non autorisées ; activation toujours bloquée

Dans une évaluation d’inscription en libre-service, Ostorlab a suivi un workflow de récupération d’enregistrements et de création de mot de passe. Une session anonyme pouvait récupérer un enregistrement contrôlé par le testeur mais appartenant à un autre principal, obtenir un jeton CSRF utilisable et envoyer des demandes de création de mot de passe pour cette inscription. Les réponses réussies et les changements persistants de version de l’enregistrement documentaient les écritures non autorisées.

La frontière de sécurité attendue. Un workflow doit établir que l’appelant peut agir sur l’inscription précise en cours de modification. Un jeton CSRF répond à une autre question : la requête porte-t-elle le jeton attendu de la session navigateur ? Sa possession n’établit pas la propriété d’un enregistrement identifié dans la requête.

L’investigation. L’agent a comparé des principaux distincts, dont une session invitée anonyme, sur des enregistrements créés pour le test. Il a récupéré l’inscription d’un autre principal, obtenu le jeton CSRF de la session, soumis une demande de création de mot de passe ciblant cet enregistrement, puis relu l’enregistrement pour examiner l’état résultant.

La validation CSRF et l’autorisation sur l’enregistrement répondent à des questions différentes. Une session invitée munie de son propre jeton CSRF pouvait lire et modifier une inscription de test appartenant à un autre principal ; l’étape d’activation et de connexion n’a pas abouti.

Séquence HTTP illustrative · les deux principaux et l’inscription sont contrôlés par le testeur.

# Session A does not own test enrollment B.
GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Obtain FAKE_CSRF_A through the public enrollment flow.
POST /example/enrollments/TEST_RECORD_B/password HTTP/1.1
Cookie: guest=FAKE_SESSION_A
X-CSRF-Token: FAKE_CSRF_A
Content-Type: application/json

{"password":"SYNTHETIC_TEST_PASSWORD"}

GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Article: write accepted; record version changed on readback.
# Final activation and login did not complete.

Étape	Preuve	Frontière évaluée
Lire une inscription de test depuis une session non propriétaire	Réponse réussie contenant l’enregistrement	Confidentialité de l’enregistrement et contrôles de propriété.
Obtenir le jeton CSRF de la session invitée	Jeton disponible via le parcours public	Disponibilité d’un jeton de requête valide pour un appelant anonyme.
Demander la création d’un mot de passe pour l’enregistrement de test d’autrui	Réponse de création réussie	Autorisation d’une opération modifiant l’état.
Relire l’enregistrement	Changements de version persistants	Effet durable au-delà de la réponse initiale.
Tenter l’étape finale d’activation et de connexion	Cette étape n’a pas abouti	Limite du chemin d’attaque démontré.

Ce que prouvent les éléments recueillis. L’évaluation a établi l’accès à des enregistrements entre principaux et la préparation d’identifiants sur une inscription de test. Elle a aussi consigné le point d’arrêt de la chaîne. L’activation finale et la connexion sont restées bloquées dans le déploiement évalué ; ce cas ne revendique donc pas une prise de contrôle achevée d’un compte utilisateur actif.

Orientation de la remédiation. Liez chaque opération d’inscription au principal autorisé ou à une capacité d’inscription délibérément conçue et de portée étroite. Vérifiez ce lien en lecture comme en écriture. Validez les relations entre l’enregistrement, l’appelant et les champs d’identité modifiés. Les cas de non-régression doivent inclure un propriétaire, un autre utilisateur authentifié, une session anonyme et un jeton CSRF valide associé au mauvais enregistrement.

Le défaut d’inscription était une défaillance d’autorisation : l’application acceptait les requêtes portant un jeton CSRF valide sans vérifier si la session pouvait accéder à l’enregistrement indiqué ou le modifier.

Signature mobile : clé récupérable ; acceptation par le backend non testée

Dans un PoC sur code source mobile, Ostorlab a suivi une clé de signature HMAC commune à toute l’application, reconstruite à partir de deux tableaux d’octets embarqués. La signature couvrait un horodatage et un marqueur fixe d’application, tandis que la méthode, le chemin et le corps de la requête restaient hors de l’entrée signée. Il s’agissait d’une vulnérabilité au niveau du code source ; prouver l’acceptation de la signature par le backend exigeait encore un test à l’exécution.

La frontière de sécurité attendue. Une signature de requête ne peut établir que les propriétés représentées par sa clé et son message signé. La revue a donc examiné comment le client obtenait sa clé et quels composants exacts de la requête entraient dans l’opération de signature.

L’investigation. L’agent a suivi la fonction de reconstruction jusqu’au constructeur de requêtes API. Les deux tableaux nécessaires pour récupérer le secret partagé étaient distribués avec le client. La couche API utilisait ensuite cette valeur reconstruite pour signer l’horodatage et le marqueur d’application avant de placer la signature dans les en-têtes des requêtes.

Le client distribué contenait les données nécessaires pour reconstruire sa clé partagée. La signature suivie couvrait un horodatage et un marqueur fixe ; la méthode, le chemin et le corps étaient absents de l’entrée signée. Le comportement du backend restait non testé.

Pseudocode illustratif · les fonctions de reconstruction et HMAC représentent l’implémentation d’origine.

// Both embedded arrays are distributed with the client.
const sharedKey = reconstructKey(embeddedArrayA, embeddedArrayB);

// Simplified representation of the traced signing inputs.
const signedInput = timestamp + APP_MARKER;
const signature = hmac(sharedKey, signedInput);

headers["X-Example-Signature"] = signature;

// request.method is absent from signedInput.
// request.path is absent from signedInput.
// request.body is absent from signedInput.
// The reconstruction algorithm and header name are illustrative.
// Backend acceptance was not established by the source review.

Trace dans le code source	Conséquence de sécurité étayée par le code
Les deux tableaux de reconstruction étaient présents dans le client	L’obfuscation n’empêchait pas la récupération de la clé partagée.
Clé partagée utilisée par le constructeur de requêtes	Le même matériel de signature était réutilisé aux points d’appel suivis.
Horodatage et marqueur fixe fournis à HMAC	Ces valeurs étaient couvertes par la signature.
Méthode, chemin et corps absents de l’entrée signée	La signature ne liait pas ces composants de la requête.

Ce que prouvent les éléments recueillis. La revue a établi que le matériel de signature était récupérable et déterminé la composition du message signé. Elle n’a pas établi que l’authentification bearer ou tous les contrôles de propriété du backend pouvaient être contournés. Le backend ne figurait pas dans cette archive source ; ces questions relevaient donc d’une évaluation de suivi à l’exécution.

Orientation de la remédiation. Réexaminez la confiance accordée à un secret distribué à chaque installation du client. Précisez l’objectif de sécurité de la signature, l’identité qu’elle représente, le contenu de la requête qu’elle lie et les contrôles de fraîcheur du serveur. Maintenez une autorisation explicite des utilisateurs et objets côté serveur. Effectuez la rotation du matériel de signature exposé dans le cadre d’une migration adaptée, tout en corrigeant la conception sous-jacente.

Les preuves du code source identifient le code de reconstruction de la clé et les champs signés. Des tests à l’exécution restent nécessaires pour déterminer comment le backend valide la signature et si d’autres contrôles empêchent les requêtes non autorisées.

Journalisation mobile : lacune de masquage reproduite ; transmission réelle non vérifiée

Dans une évaluation Android distincte, Ostorlab a suivi des valeurs d’authentification depuis un résultat OpenID jusqu’à la journalisation applicative, une fonction de masquage et la sérialisation de télémétrie. La reproduction locale a montré que des valeurs de forme identique à des identifiants passaient le filtre sous des noms de champs et formats de chaîne non reconnus. La fiche identifiait le chemin de fuite et les vérifications à l’exécution encore nécessaires.

La frontière de sécurité attendue. Les éléments d’authentification doivent être exclus ou masqués de manière sûre avant d’entrer dans les journaux. Un filtre doit traiter la sérialisation réellement utilisée par l’application, y compris les champs structurés et les représentations textuelles.

L’investigation. Le code source montrait une journalisation sur le parcours d’authentification réussie. Un point d’appel sérialisait une table d’en-têtes contenant une valeur de cookie ; un autre journalisait un résultat d’authentification sous forme de chaîne. La fonction de masquage reconnaissait un ensemble défini de champs dans un format particulier proche de JSON. Les chaînes contenant les identifiants ne correspondaient ni à ces noms ni à ce format.

La reproduction locale comprenait des contrôles positifs : les champs reconnus d’autorisation et de jeton de rafraîchissement étaient masqués. Les chaînes problématiques de cookie et de code subsistaient. Cette distinction établissait une lacune concrète dans un mécanisme de masquage par ailleurs fonctionnel.

Le même filtre masquait les champs reconnus d’autorisation et de jeton de rafraîchissement tout en manquant les chaînes de table de cookies et de résultat d’authentification. La trace du code source atteignait la sérialisation de télémétrie ; la transmission réelle et le rejeu des identifiants n’ont pas été observés.

Illustration locale exécutable · identifiants synthétiques et règle de masquage simplifiée.

const mask = text => text.replace(
  /("(?:authorization|refresh_token)"\s*:\s*")[^"]*"/gi,
  '$1[REDACTED]"'
);

const known = '{"authorization":"FAKE_BEARER"}';
const refresh = '{"refresh_token":"FAKE_REFRESH"}';
const cookie = '{Cookie=FAKE_COOKIE}';
const result = 'AuthResult(code=FAKE_AUTH_CODE)';

if (mask(known).includes("FAKE_BEARER")) throw Error("control");
if (mask(refresh).includes("FAKE_REFRESH")) throw Error("control");
if (!mask(cookie).includes("FAKE_COOKIE")) throw Error("gap");
if (!mask(result).includes("FAKE_AUTH_CODE")) throw Error("gap");

// The known fields are masked; the cookie and code survive.
// This reproduces the failure class, not the original filter.

Ostorlab a ensuite suivi le message résultant dans le chemin de sérialisation du SDK de journalisation. La capture de trafic à l’exécution et le rejeu des identifiants restaient à effectuer ; l’article ne décrit donc ni une exfiltration réelle d’identifiants observée ni une prise de contrôle de session achevée.

Orientation de la remédiation. Supprimez si possible les instructions de journalisation contenant des identifiants, puis rendez le masquage cohérent entre attributs structurés, en-têtes sérialisés et représentations textuelles des objets. Testez les parcours d’authentification réussie comme les erreurs. Utilisez des secrets synthétiques dans les tests de non-régression et vérifiez que ni l’événement de journal en attente ni sa forme transmise ne les contiennent.

L’évaluation identifie les points d’appel de journalisation de l’authentification, les formats omis par la règle de masquage et le chemin de sérialisation. Ces emplacements définissent les modifications de code requises et les tests de non-régression pour le masquage des identifiants.

Laboratoire AD distinct : chaîne des ACL au certificat et nettoyage non résolu

Dans une évaluation Active Directory en laboratoire, l’agent a commencé avec un utilisateur de domaine peu privilégié et a énuméré la surface de contrôle d’accès de l’annuaire. La revue a couvert 3 002 lignes d’ACL réparties entre utilisateurs, groupes, ordinateurs et racine du domaine. Elle a identifié une ACE WriteOwner non héritée permettant à un utilisateur ordinaire de devenir propriétaire du compte de service de l’autorité de certification. C’était la seule ACE du corpus qui donnait à un principal hors Tier-0 le contrôle d’un objet Tier-0.

Le compte de service de l’autorité de certification était membre de Cert Publishers, disposait de GenericAll sur un modèle de certificat et était exposé au Kerberoasting avec RC4.

Le droit GenericAll sur le modèle de certificat constituait la condition ESC4 : il permettait à l’agent de modifier les paramètres de sécurité du modèle avant de demander un certificat au nom d’un autre principal. L’ACE WriteOwner sur le compte de service était le point d’entrée distinct vers ce chemin de contrôle du modèle. L’appartenance à Cert Publishers et l’exposition au Kerberoasting RC4 constituaient des expositions supplémentaires, et non des prérequis de l’étape ESC4.

La frontière de sécurité attendue. Un compte de service d’autorité de certification et ses modèles de certificat sont des objets Tier-0. Les utilisateurs ordinaires ne doivent pas en être propriétaires, les ACL des modèles doivent être réservées aux administrateurs de l’autorité de certification et de l’annuaire, et chaque émission doit être journalisée et révocable. Une ACE WriteOwner sur le compte de l’autorité de certification n’est pas une délégation ordinaire.

L’investigation. L’agent a pris possession du compte de service, réécrit la DACL pour s’accorder GenericAll et pris le contrôle du compte. Il a modifié le modèle pour autoriser l’inscription, demandé un certificat en tant qu’administrateur, utilisé ce certificat pour s’authentifier et répliqué krbtgt. Il a ensuite forgé un golden ticket. Le certificat administrateur indûment émis est resté non révoqué.

Une ACE non héritée a donné à un utilisateur ordinaire la propriété du compte de service de l’autorité de certification. L’agent a enchaîné cette propriété, un modèle ESC4, un certificat et la réplication du domaine.

Pseudocode d’exécution illustratif · noms synthétiques ; syntaxe non réelle des outils.

# Lab: ordinary user -> CA service account -> template -> certificate -> DCSync.
# Names and values are synthetic.

ace = read_ace(target="svc-ca", trustee="user-a")
# One non-inherited WriteOwner ACE in 3,002 ACL rows.

seize_owner(target="svc-ca", as="user-a")
grant_generic_all(target="svc-ca", to="user-a")
reset_secret(target="svc-ca")

template = modify_template("CorpAuthTemplate", enroll="svc-ca")
cert = request_certificate(template, subject="Administrator")
session = authenticate_with(cert)
replicate_krbtgt(session)
forge_golden_ticket()

# The misissued administrator certificate was not revoked.

Étape	Preuve	Frontière évaluée
Énumérer les ACL dans tout l’annuaire	3 002 lignes ; une ACE WriteOwner non héritée pour un utilisateur ordinaire sur le compte de service de l’autorité de certification	Isolation des objets Tier-0 vis-à-vis des utilisateurs ordinaires.
Prendre possession du compte et réécrire la DACL	Prise de propriété et octroi de GenericAll reproduits en conditions réelles ; écritures annulées à l’octet près	Exploitabilité réelle de l’ACE, au-delà de sa seule présence.
Contrôler le compte de service de l’autorité de certification	Le compte était membre de Cert Publishers et disposait de GenericAll sur le modèle	Extension des droits du compte de service jusqu’à l’émission de certificats.
Modifier le modèle et demander un certificat	Condition ESC4 ; un certificat administrateur a été émis	Capacité des ACL du modèle à empêcher une inscription en tant que principal privilégié.
S’authentifier avec le certificat et répliquer krbtgt	Réplication du domaine et golden ticket	Accès de l’authentification par certificat à l’autorité du contrôleur de domaine.
Vérifier la révocation	Le certificat administrateur indûment émis restait non révoqué	Capacité de l’organisation à retirer l’identifiant d’accès.

Ce que prouvent les éléments recueillis. La prise de contrôle par ACL a été reproduite en conditions réelles, et les droits du compte atteignaient un modèle utilisé par l’autorité de certification. L’étape du certificat et de la réplication est consignée comme chaîne critique de l’agent ; le certificat indûment émis n’était toujours pas révoqué à la fin de l’évaluation. Il s’agit d’une évaluation en laboratoire, et non d’un résultat client ou d’un benchmark comparatif. Le certificat non révoqué est un point de nettoyage non résolu, et non une preuve de restauration achevée. Une mission équivalente exige un responsable désigné pour le révoquer et vérifier le résultat avant d’accepter le nettoyage comme terminé.

Résultat de l’évaluation. Le contrôle du compte de service de l’autorité de certification donnait accès à un modèle de certificat modifiable pour demander un certificat administrateur. La séquence enregistrée reliait la mauvaise configuration initiale des ACL à l’authentification par certificat et à la réplication du domaine. Le laboratoire ne comparait pas les performances des évaluations automatisée et manuelle.

Orientation de la remédiation. Supprimez l’ACE et examinez chaque droit non hérité sur les objets Tier-0. Séparez le compte de service de l’autorité de certification de l’administration ordinaire, restreignez les ACL des modèles aux administrateurs de l’autorité de certification et de l’annuaire, désactivez RC4 pour les comptes de service, exigez une approbation et une journalisation des modifications de modèles et des émissions de certificats, révoquez les certificats indûment émis et effectuez deux rotations de krbtgt. Le contre-test doit vérifier qu’un utilisateur peu privilégié ne peut ni devenir propriétaire du compte de l’autorité de certification ni modifier le modèle, que DCSync échoue et que les tickets forgés sont rejetés après rotation.

Un rapport de tests internes doit documenter l’identité de départ, les ACL affectées, les permissions obtenues, les résultats de validation, les tests infructueux et les artefacts restants. Les administrateurs ont besoin de ces informations pour reproduire la vulnérabilité, corriger la délégation et vérifier le nettoyage dans le périmètre autorisé.