Pentest White Box : objectifs, méthodologie de tests et use cases

Lors d’un pentest d’application web, d’API ou de réseau interne, on distingue généralement 3 approches : des tests en boite noire, en boite grise ou en boite blanche.

Ces approches ou conditions de tests correspondent à différents niveaux d’informations fournis aux pentesters pour identifier des vulnérabilités et des faiblesses potentielles pouvant compromettre l’intégrité d’un système cible. Alors qu’un pentest black box consistera à fournir aucune donnée spécifique, lors d’un pentest white box, les pentesters disposeront d’un maximum d’informations.

Dans cet article, nous nous focaliserons sur le pentest white box en présentant, de la manière la plus exhaustive possible, les principes et objectifs de cette approche de sécurité offensive. En partant de cas concrets, nous présenterons la méthodologie d’un pentest white box et des exemples de vulnérabilités sur diverses cibles.

Plan détaillé de l’article :

En quoi consiste un pentest white box (audit en boite blanche) ?

Le pentest white box (audit en boîte blanche), est une méthode d’évaluation de la sécurité où les pentesters disposent d’une connaissance complète de l’infrastructure, du système et du code source.

Dans ce contexte, les pentesters utilisent ces informations pour identifier des vulnérabilités plus spécifiques et complexes. Cela inclut l’examen du code source et/ou de l’infrastructure pour détecter les erreurs de développements et les défauts de configuration afin de s’assurer que le système cible est robuste contre les attaques.

L’objectif d’un pentest white box est donc d’identifier des vulnérabilités qui ne seraient pas nécessairement évidentes sans une connaissance approfondie du système et de proposer des recommandations pour renforcer la sécurité.

Par ailleurs, cette méthode est particulièrement efficace pour examiner la qualité du code. De plus, cela fait gagner énormément de temps aux pentesters et fournit une vue plus exhaustive de la posture sécurité.

Préparation pour un pentest white box

La préparation pour un pentest white box est une phase essentielle qui nécessite une attention minutieuse aux détails et une bonne planification.

Cette phase commence par une collecte d’informations exhaustive. Il est crucial d’obtenir des détails complets sur l’architecture du système, y compris les diagrammes des réseaux, les configurations des serveurs, les bases de données et les applications concernées.

L’accès au code source est également vital, car il permet une analyse en profondeur des possibles vulnérabilités et erreurs de programmation.

En outre, rassembler la documentation technique pertinente, telle que les spécifications de conception et les politiques de sécurité, aide à comprendre le fonctionnement interne et les exigences du système.

Une fois que les informations nécessaires sont collectées, la prochaine étape consiste à définir les objectifs spécifiques du pentest. Cela implique de déterminer les composants critiques du système qui nécessitent une attention particulière et de fixer des objectifs précis pour l’évaluation, comme l’identification des vulnérabilités, l’évaluation de la résistance aux attaques, ou la validation des contrôles de sécurité existants.

Quelles sont les différentes phases d’un pentest white box ?

Un pentest white box est une démarche structurée qui se déroule en plusieurs phases clés, chacune jouant un rôle clé dans l’évaluation complète de la sécurité du système.

Analyse statique du code

Cette phase initiale se concentre sur l’examen du code source. L’analyse statique permet d’identifier les vulnérabilités potentielles sans exécuter le code.

Les pentesters examinent le code pour détecter des failles telles que les injections SQL, failles XSS mais aussi les manques de contrôles de droits.

Cela implique l’utilisation d’outils automatisés et d’une revue manuelle pour comprendre le fonctionnement du code et repérer les failles de sécurité.

En effet, des outils d’analyse statique permette à l’auditeur d’être plus efficace dans sa recherche de vulnérabilités.

Parmi ceux-ci, on trouve notamment Semgrep qui permet de relever des problèmes de sécurité dans le code source.

En examinant le code d’un formulaire de connexion, par exemple, un pentester peut identifier des failles où le code ne filtre pas correctement les entrées utilisateur, laissant la porte ouverte à des attaques par injection SQL.

Cette analyse est cruciale car elle permet de détecter les problèmes de sécurité avant que l’application ne soit mise en ligne ou exposée à des menaces réelles.

Grâce à cette détection, l’auditeur est en mesure de tester la vulnérabilité sur l’application web pour prouver son existence.

<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDatabase";
// Connexion à la base de données
$conn = new mysqli($servername, $username, $password, $dbname);

// Vérification de la connexion
if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
}
// Récupération des données du formulaire
$user = $_POST['username'];
$pass = $_POST['password'];

// Requête SQL vulnérable
$sql = "SELECT * FROM users WHERE username = '$user' AND password = '$pass'";
$result = $conn->query($sql);

if ($result->num_rows > 0) {
    // Utilisateur trouvé
    echo "Connexion réussie";
} else {
    // Utilisateur non trouvé
    echo "Identifiant ou mot de passe incorrect";
}
$conn->close();
?>

Analyse dynamique et tests d’intrusion

Contrairement à l’analyse statique, l’analyse dynamique implique l’interaction avec l’application ou le système en cours d’exécution.

Cette étape permet d’identifier des vulnérabilités qui ne sont apparentes que lors de l’exécution du code.

Les pentesters simulent des attaques réalistes pour tester la réactivité du système face à des intrusions, en évaluant par exemple sa capacité à gérer correctement les entrées utilisateur ou à maintenir l’intégrité des données.

Cette étape se fait en même temps qu’une lecture de code approfondie afin de déterminer rapidement quel endroit du code est vulnérable.

Énumération des vulnérabilités et points de faiblesse

Après les analyses statique et dynamique, les pentesters compilent une liste des vulnérabilités détectées.

Cette énumération inclut non seulement les failles techniques, les vulnérabilités logiques mais aussi les faiblesses dans les procédures et l’architecture globale.

Chaque vulnérabilité est évaluée en termes de gravité, d’impact potentiel, et de facilité d’exploitation, puis reportée dans le rapport de pentest.

Pentest white box d’une application web avec accès à une infrastructure AWS

Pour illustrer le processus d’audit en boite blanche d’une application web, prenons l’exemple concret où un client nous fournit le nom de domaine complet (FQDN) : « pentest.vaadata.com ».

Lors de la phase de reconnaissance de la cible, une résolution DNS révèle l’utilisation de CloudFront par le client.

CloudFront est un réseau de distribution de contenu (CDN) proposé par Amazon Web Services (AWS). Il s’agit d’une couche intermédiaire qui se place entre les utilisateurs finaux et le serveur où réside l’application web. Ce type d’outils permet notamment d’accélérer la livraison de contenu web en le distribuant depuis des emplacements géographiquement proches de l’utilisateur.

L’intérêt de CloudFront ne réside pas uniquement dans l’optimisation de la vitesse d’accès au contenu, mais également dans un aspect de sécurité.

En masquant l’adresse IP réelle des serveurs d’origine, CloudFront contribue à protéger les applications web contre des attaques telles que les DDoS (Distributed Denial of Service).

Néanmoins, lors d’un pentest white box, obtenir l’adresse IP directe du serveur sur lequel l’application est hébergée peut s’avérer crucial. En effet, accéder directement au serveur permet de contourner les protections offertes par CloudFront, telles que le masquage de l’IP et la mitigation des attaques, permettant ainsi d’évaluer de manière exhaustive la sécurité de l’application web.

Analyse de l’infrastructure AWS

Ce rôle spécifique nous permet d’examiner en détail les ressources et les configurations mises en place au sein de leur environnement cloud.

Parmi les découvertes, il s’avère que le client a déployé une instance EC2 (Amazon Elastic Compute Cloud) pour héberger son application web.

L’une des premières étapes de l’audit consiste à identifier l’adresse IP réelle de l’instance EC2. Cette information est importante car elle offre la possibilité de contourner CloudFront, dans l’éventualité où la configuration de sécurité le permet.

En effet, accéder directement à l’instance EC2 peut révéler des vulnérabilités qui seraient autrement masquées par les couches intermédiaires de distribution de contenu comme CloudFront.

En outre, l’analyse de l’infrastructure AWS a mis en évidence l’utilisation d’un bucket S3, nommé « web-storage-aws », servant de solution de stockage pour le site web.

Les buckets S3 sont fréquemment utilisés pour stocker des ressources web statiques telles que des images, des feuilles de style CSS et des scripts JavaScript.

La configuration et les politiques de sécurité appliquées à ce bucket S3 sont donc des éléments clés à auditer. En effet, une configuration inappropriée peut exposer ces ressources à des accès non autorisés ou à des fuites de données, compromettant ainsi la sécurité de l’ensemble de l’application web.

Identification de mauvaises configurations

Dans le cadre de notre pentest white box, nous avons examiné les autorisations attachées à ce bucket S3 spécifique via l’onglet « Autorisation » de la console AWS.

Il est apparu que le bucket est configuré avec une politique d’accès (policy) permettant à quiconque de télécharger les fichiers qu’il contient.

Cette configuration ouvre la porte au téléchargement direct de fichiers par toute personne connaissant le chemin précis du fichier, bien que la liste des répertoires et fichiers (directory listing) ne soit pas activée.

Cette restriction empêche de connaître les noms des dossiers et fichiers présents dans le bucket, ajoutant une couche de sécurité par obscurité.

Découverte de fichiers sensibles

Notre analyse en white box a permis de découvrir l’existence d’un fichier de backup situé à l’adresse suivante : backup/2024-02-22/website/.env.backup.

Cette découverte souligne l’importance de connaître précisément les chemins des fichiers stockés dans le bucket S3, car sans cette connaissance, l’accès aux fichiers serait beaucoup plus difficile.

Comparativement, dans un contexte d’audit black box où l’auditeur n’a pas accès aux configurations internes ou aux politiques d’accès, la découverte de ce chemin de fichier aurait potentiellement nécessité une attaque brute force, testant systématiquement divers chemins de fichiers pour identifier les ressources accessibles.

Cette méthode est non seulement chronophage mais également moins efficace, augmentant le risque de détection par les mécanismes de surveillance du trafic, notamment de rate limiting.

Il est également plausible d’imaginer que les assets statiques tels que les images et les fichiers JavaScript soient stockés dans le même dossier website.

Étant donné que ces ressources sont souvent référencées directement dans le code source de l’application web, un attaquant pourrait extrapoler les chemins d’accès à ces fichiers.

Cependant, la découverte du fichier spécifique .env.backup, contenant potentiellement des informations sensibles, nécessiterait une connaissance ou une supposition précise du chemin d’accès.

Le fichier « .env.backup » peut ainsi être téléchargé depuis le répertoire « website ».

Ce fichier s’est avéré contenir des clés d’autorisation AWS, un élément crucial pour la suite de notre investigation.

Tests de validité des clés d’accès AWS

Pour tester la validité de ces clés, nous avons utilisé le CLI d’AWS, un outil pour interagir avec les services AWS directement depuis le terminal.

En utilisant une commande spécifique, nous avons pu lister l’utilisateur associé à ces clés, révélant qu’elles étaient valides et appartenaient à l’utilisateur web-deploy.

En explorant davantage via l’interface AWS, nous avons rapidement examiné les politiques attachées à l’utilisateur web-deploy. Cet utilisateur était associé à la politique secret-manager-viewer, une politique permettant de lister tous les secrets présents dans le compte AWS et d’en lire le contenu.

Cette capacité d’accès est particulièrement sensible car elle peut révéler des informations critiques qui, dans de mauvaises mains, pourraient compromettre la sécurité de l’ensemble de l’infrastructure AWS.

Nous avons listé les secrets disponibles et découvert un secret nommé personal-db. Ce secret, apparemment déconnecté de l’application web, semblait plutôt lié à une base de données personnelle.

Le fait que nous ayons pu découvrir et accéder à ce type d’information souligne l’importance de restreindre les permissions sur un compte AWS.

Les identifiants de cette base de données personnelle étaient accessibles en raison de permissions excessivement larges attribuées à l’utilisateur web-deploy.

Recommandations de correction indiquées dans le rapport de pentest

Face aux vulnérabilités et aux mauvaises configurations découvertes lors de notre audit, plusieurs recommandations de correction s’imposent pour renforcer la sécurité de l’infrastructure AWS du client.

• Premièrement, il est crucial de revoir et de restreindre les permissions accordées aux utilisateurs, en particulier celles liées à l’utilisateur web-deploy. Appliquer le principe de moindre privilège, en ne fournissant que les accès strictement nécessaires pour les tâches spécifiques, permettra de réduire significativement le risque de fuites de données ou d’autres failles de sécurité.
• Ensuite, il est recommandé de mettre en place une stratégie de gestion des secrets plus stricte. Les clés d’autorisation et les identifiants de base de données ne devraient pas être stockés dans des fichiers accessibles publiquement, comme le .env.backup. L’utilisation d’outils tels que AWS Secrets Manager pour gérer ces informations sensibles de manière sécurisée est fortement conseillée. Ces outils offrent des fonctionnalités de rotation automatique des secrets et d’accès basées sur les politiques, renforçant ainsi la sécurité des données.
• De plus, il est impératif de reconfigurer les politiques appliquées aux buckets S3 pour empêcher le téléchargement non autorisé de fichiers. Cela comprend la mise en œuvre de politiques de compartiment (bucket policies) qui limitent l’accès aux fichiers et dossiers spécifiques, ainsi que l’utilisation de fonctions de blocage du listage public, pour éviter la divulgation de la structure des répertoires et des fichiers stockés.

Audit en boite blanche d’une application avec accès au code source

Dans ce second exemple, l’examen du code source d’une application web nous offre une fenêtre précieuse sur sa conception et sa sécurité.

Dès les premières lignes, nous identifions que l’application utilise Flask, un micro-framework écrit en Python et destiné au développement web.

Flask est réputé pour sa simplicité et sa flexibilité, mais comme tout outil, son utilisation peut introduire des vulnérabilités si les meilleures pratiques de sécurité ne sont pas respectées.

Un détail révélé par l’analyse du code est que le serveur Flask est exécuté en mode Debug. Activer le mode Debug dans un environnement de production est une pratique hautement risquée pour plusieurs raisons.

Premièrement, ce mode fournit des informations détaillées sur les erreurs, y compris des traces de pile et des configurations de l’application, qui peuvent être exploitées par des acteurs malveillants pour découvrir des vulnérabilités ou des failles dans le code.

Deuxièmement, le mode Debug peut parfois permettre l’exécution de code arbitraire si l’interface de débogage est accessible (/console), offrant ainsi un vecteur d’attaque potentiel pour l’exécution de code malveillant sur le serveur.

L’analyse du code source, surtout lorsqu’il comprend des milliers de lignes, peut être un processus complexe. Toutefois, elle est essentielle pour identifier les pratiques de développement non sécurisées et les configurations potentiellement vulnérables.

Extraction des routes de l’application web

Dans le cadre de notre audit de sécurité, une étape clé consiste à extraire et à examiner les routes de l’application web.

Sous Flask, chaque route est définie avec un décorateur @app.route, facilitant ainsi l’identification des différents points d’entrée de l’application.

En développant un script bash capable de parcourir le code source pour extraire ces routes, ainsi que la méthode de la requête associée (GET, POST, …) et le chemin associé, nous pouvons obtenir une vue d’ensemble complète des endpoints de l’application.

Cette liste exhaustive des routes nous permet de réaliser des tests ciblés sur tous les endpoints, assurant ainsi qu’aucun élément n’est négligé lors de l’audit.

Tester chaque endpoint individuellement aide à identifier les vulnérabilités spécifiques, telles que les injections SQL, les failles XSS, ou encore les problèmes de configuration, qui pourraient autrement passer inaperçues.

La présence de la route /api/v1/template/edit dans l’application web, qui permet de modifier un template Jinja2 et d’en renvoyer le contenu, révèle une vulnérabilité critique.

Cette fonctionnalité, qui récupère la valeur du paramètre content pour la traiter, pourrait sembler inoffensive à première vue.

Cependant, le code révèle l’utilisation de la méthode render_template_string, qui renvoie la valeur de notre paramètre content dans la réponse du serveur.

Le problème de sécurité ici est lié à l’injection de template (SSTI).

Exploitation d’une vulnérabilité de type SSTI (Server Side Template Injection)

L’injection de template Jinja2 est une vulnérabilité sérieuse car elle peut permettre l’exécution de code arbitraire sur le serveur.

Jinja2 est un moteur de template puissant qui offre la possibilité d’exécuter du code Python au sein des templates.

Lorsqu’un utilisateur peut contrôler le contenu d’un template, comme c’est le cas avec le paramètre content, il peut potentiellement insérer du code malveillant qui sera exécuté par le serveur lors du rendu du template.

Le fait que la multiplication simple testée renvoie 49 indique que le moteur de template traite et exécute le contenu du paramètre content, confirmant ainsi que le template est en cours de traitement.

Cette capacité d’exécuter du code sur le serveur à distance via l’injection de templates ouvre la porte à plusieurs techniques d’attaque, allant de la divulgation d’informations sensibles à l’exécution de commandes arbitraires sur le serveur.

Les attaquants peuvent exploiter cette vulnérabilité pour accéder à des variables d’environnement, lire des fichiers sur le serveur, ou même exécuter du code malveillant, compromettant ainsi la sécurité de l’application et de ses données.

Comment prévenir ce type de vulnérabilité ?

Nous recommandons fortement de désactiver le mode Debug dans les environnements de production pour éviter la divulgation d’informations sensibles.

Il est également crucial de valider et de nettoyer toutes les entrées utilisateur pour prévenir les injections, en particulier lors de l’utilisation de templates Jinja2, afin d’éviter l’exécution de code arbitraire.

Pentest white box d’une application PHP

Dans le cadre d’un autre pentest white box d’une application web utilisant PHP, nous avons analysé une fonctionnalité agissant comme un proxy.

Cette fonctionnalité est conçue pour récupérer le contenu de pages spécifiques du site « vaadata.com », en utilisant un paramètre url pour passer l’URL souhaitée au serveur, qui établit ensuite la requête.

Un filtrage est effectué à l’aide d’une expression régulière (regex) visant à restreindre les requêtes uniquement au domaine « vaadata.com », dans le but de prévenir des exploitations malveillantes.

Cependant, nous avons identifié une erreur critique dans cette approche : la regex ne vérifie pas la présence du slash (/) immédiatement après le nom de domaine, ce qui ouvre une porte à des attaques par injection de Server-Side Request Forgery (SSRF).

Exploitation d’une vulnérabilité de type SSRF

Une faille SSRF permet à un attaquant d’envoyer des requêtes forgées depuis le serveur vers des systèmes internes ou externes, contournant ainsi les mesures de sécurité normalement appliquées aux requêtes issues de sources externes.

Cette vulnérabilité peut être exploitée pour accéder à des services internes non exposés publiquement, comme dans le cas d’un service interne, qui divulgue des identifiants de base de données sensibles.

Normalement protégé et accessible uniquement via une requête locale (127.0.0.1), ce service peut néanmoins être atteint par un attaquant exploitant la vulnérabilité SSRF découverte.

L’exploitation de cette faille peut se faire de plusieurs manières. Par exemple, un attaquant pourrait contourner la regex en utilisant « vaadata.com » comme sous-domaine d’un FQDN pointant vers localhost, ou encore en passant « vaadata.com » comme paramètre d’authentification basique dans la requête, feignant ainsi une requête interne légitime et accédant au service /api/internal.

Une autre méthode d’exploitation de la vulnérabilité SSRF dans l’application web PHP réside dans la capacité d’effectuer initialement une requête vers un serveur externe contrôlé par l’attaquant, pour ensuite rediriger cette requête vers le service interne visé.

Cette technique s’appuie sur l’activation de l’option CURLOPT_FOLLOWLOCATION dans le code de l’application, qui permet au serveur de suivre automatiquement les redirections HTTP.

En exploitant cette fonctionnalité, un attaquant peut effectuer plusieurs requêtes où la dernière étape consiste à accéder à un service interne spécifique, tel que /api/internal, qui divulgue des informations confidentielles et qui était présumé être sécurisé et inaccessible depuis l’extérieur.

Correction de la faille SSRF

Pour remédier aux vulnérabilités SSRF identifiées au cours de l’audit de l’application web PHP, il est essentiel de renforcer la validation des entrées utilisateur, spécialement pour les fonctionnalités qui traitent des URL ou des requêtes externes.

L’utilisation de listes blanches strictes pour les domaines autorisés et l’application de regex plus rigoureuses pour vérifier le format et la légitimité des URL peuvent empêcher efficacement les tentatives de contournement.

Il est également important de revoir la configuration des requêtes HTTP sortantes réalisées par l’application. La désactivation de l’option CURLOPT_FOLLOWLOCATION pour les requêtes cURL est recommandée afin de ne pas suivre automatiquement les redirections.

Pentest white box d’un réseau interne

Dans le cadre d’un audit du réseau interne d’un client, la méthodologie white box nous offre un avantage significatif grâce à la fourniture préalable d’informations détaillées, notamment le schéma complet du réseau, l’accès à plusieurs comptes de l’Active Directory avec différents niveaux de privilèges, y compris un compte de domaine administrateur, ainsi que l’accès aux différents VLANs du client.

Ces éléments constituent une base solide pour lancer l’audit, en nous permettant d’approfondir notre analyse sans les obstacles habituellement rencontrés dans les approches black box ou grey box.

L’utilisation d’un compte administrateur joue un rôle important dans cet audit, en nous permettant d’examiner la configuration de l’Active Directory, y compris les listes de contrôle d’accès (ACL), les privilèges attribués aux différents utilisateurs, les tâches planifiées ainsi que les politiques d’authentification.

L’objectif est de détecter les configurations incorrectes, les permissions excessives ou inappropriées, et les potentielles vulnérabilités qui pourraient être exploitées par des attaquants.

Pour faciliter cette analyse, nous utilisons BloodHound, un outil qui effectue des requêtes LDAP pour cartographier les relations et les flux de privilèges au sein de l’Active Directory.

BloodHound génère des graphiques interactifs pour illustrer ces relations, offrant ainsi une clarté et une compréhension améliorée des interdépendances complexes et des chemins d’attaque potentiels au sein de l’environnement réseau.

Cette représentation graphique est particulièrement utile pour identifier rapidement les comptes à privilèges élevés et les configurations de groupe susceptibles de poser des risques de sécurité.

Réalisez un pentest white box avec Vaadata, entreprise certifiée CREST, ISO 27001 et ISO 27701

L’audit de sécurité en boite blanche, qu’il s’agisse de pentests web, d’APIs ou autre, est un processus fondamental dans la sécurisation des systèmes informatiques.

Grâce à une connaissance approfondie d’un système cible (architecture, code source, etc.), il permet d’identifier et de corriger des vulnérabilités qui pourraient rester inaperçues dans des approches boite noire ou boite grise.

Cet article a mis en lumière les étapes clés d’un pentest white box soulignant l’importance de l’analyse statique et dynamique pour identifier et exploiter des vulnérabilités.

Par ailleurs, les exemples concrets fournis illustrent les risques associés à des pratiques de développement non sécurisés. Nous vous proposons d’identifier les vulnérabilités de vos systèmes et de vous accompagner dans leur correction.

Contactez-nous pour échanger sur vos enjeux et besoins.

Auteurs : Alexis MARTIN – Pentester & Amin TRAORÉ – CMO @Vaadata