Pentest en boîte noire : ce qu’il trouve, ce qu’il rate

En boîte noire, le pentester reçoit un nom de domaine, parfois une plage d’adresses IP ou l’URL d’une application. Rien d’autre. Pas de compte, pas de schéma d’architecture, pas de code source. Il voit votre système exactement comme n’importe qui sur Internet le voit.

C’est l’approche que la plupart des gens imaginent quand on parle de hacking éthique. Elle a un vrai intérêt, et des limites qu’il vaut mieux connaître avant de signer un devis.

Si vous découvrez le sujet, l’article Audit d’intrusion (pentest), approches et méthodologie présente les trois approches côte à côte.

Ce que le pentester reçoit, et ce qu’il ne reçoit pas

« Aucune information » ne veut pas dire « aucun cadre ». Un test en boîte noire démarre comme les autres, par une convention d’audit signée : dates, adresses IP d’où partiront les tests, actions interdites, contacts en cas d’incident. Le périmètre est le seul point délicat. Le pentester va trouver des sous-domaines et des serveurs dont vous ignoriez peut-être l’existence, et certains n’appartiennent pas à votre société (un service hébergé chez un prestataire, un ancien site revendu). Avant tout test actif, la liste de ce qui a été trouvé vous est soumise pour validation. On ne teste que ce qui vous appartient.

Comment se déroule un test en boîte noire

La première moitié du travail est de la reconnaissance. Le pentester construit l’inventaire que l’attaquant construirait :

• les sous-domaines, dont une bonne partie apparaît dans les journaux publics de certificats TLS (chaque certificat émis y est inscrit, y compris celui du serveur de préproduction) ;
• les adresses IP et les services qui répondent : sites, VPN, messagerie, bureaux à distance, interfaces d’administration ;
• les versions de logiciels, comparées aux failles connues ;
• les fuites déjà publiques : identifiants de salariés dans des bases volées, documents indexés par les moteurs de recherche, dépôts de code ouverts par erreur.

L’OWASP consacre une section entière de son guide de test à cette collecte d’informations. C’est souvent là que se joue le résultat de l’audit.

Vient ensuite le test de ce qui a été trouvé : configurations par défaut, mots de passe d’usine, interfaces qui ne devraient pas être publiques, failles connues non corrigées. Sur une application web, le pentester attaque tout ce qui est accessible sans compte : formulaire de connexion, réinitialisation de mot de passe, pages publiques, API appelées par le site. Si l’inscription est ouverte, il crée un compte comme le ferait un attaquant.

Ce qu’il trouve bien

La boîte noire est imbattable sur une question : qu’est-ce que vous exposez sans le savoir ?

Un cas typique, qu’on retrouve sous une forme ou une autre dans beaucoup d’audits externes : un sous-domaine de préproduction monté pour un projet il y a trois ans, jamais éteint, avec une copie de la base clients et un mot de passe d’administration resté à sa valeur d’installation. Personne en interne ne le surveille, il n’apparaît dans aucun inventaire. Un attaquant le trouve en quelques minutes.

Elle trouve aussi très bien les failles exploitables sans authentification : un VPN pas à jour, un service de partage de fichiers exposé, une version vulnérable d’un CMS. Ce sont exactement les portes qu’utilisent les attaquants qui scannent Internet en masse, et beaucoup d’attaques par ransomware commencent par l’une d’elles.

Ce qu’il rate

Le premier angle mort, c’est le temps. Un attaquant a des semaines, voire des mois. Un pentest dure quelques jours. Chaque heure passée à deviner ce qu’un simple échange de dix minutes aurait appris est une heure qui ne sert pas à creuser.

Le second est plus gênant : tout ce qui se trouve derrière une authentification. Sur une application sans inscription publique, un test en boîte noire ne voit que la page de connexion. Le pentester peut essayer d’atteindre directement des adresses normalement protégées, mais il ne testera pas sérieusement ce qui compte le plus dans une application métier : est-ce qu’un client peut lire les données d’un autre client ? Est-ce qu’un simple utilisateur peut appeler une fonction réservée aux administrateurs ? Ces failles de contrôle d’accès sont en tête du Top 10 de l’OWASP, et la boîte noire passe à côté presque par construction.

On entend souvent que la boîte noire est « plus réaliste ». C’est vrai pour un attaquant opportuniste qui ne vous connaît pas. Un attaquant motivé, lui, finit souvent par obtenir un compte : hameçonnage, mot de passe réutilisé, fuite chez un sous-traitant. À ce moment-là, il est en boîte grise, et vous ne savez pas ce qu’il peut faire.

Pour qui, et quand

La boîte noire convient bien à :

• une entreprise qui n’a jamais fait d’audit et veut une première photo de son exposition sur Internet, à budget maîtrisé ;
• un état des lieux après une fusion, un changement de prestataire ou une migration, quand plus personne ne sait vraiment ce qui est en ligne ;
• la vérification de votre surface externe, en complément d’un audit plus profond de vos applications.

Elle est un mauvais choix pour un SaaS avec des comptes clients, une application interne réservée aux salariés, ou toute plateforme où plusieurs clients partagent les mêmes serveurs. Là, c’est la boîte grise qu’il faut, avec des comptes de test.

Côté durée, un audit externe en boîte noire prend en général de un à quatre jours de tests, selon le nombre de domaines et de services exposés. Notre audit de sécurité externe suit cette approche, et l’audit externe Découverte en est la version courte, sur une journée.

Pour aller plus loin sur les autres approches : le pentest en boîte grise et le pentest en boîte blanche. Et pour chiffrer votre cas, le formulaire de devis vous demande justement quelle approche vous visez.