Tout savoir sur les tests d’intrusion web

Il existe plusieurs méthodologies relatives aux tests d’intrusion web :  

• Test en boîte noire : l’auditeur se place dans la peau d’un attaquant sur Internet et n’a aucune connaissance du système d’information ciblé, excepté les informations accessibles publiquement. C’est un audit réaliste, mais qui perd en exhaustivité, car il ne permet pas d’identifier les vulnérabilités présentes depuis un contexte authentifié. 
• Test en boîte grise : l’auditeur dispose de comptes valides lui permettant d’accéder aux applications – obtenus lors du test en boîte noire ou mis à disposition par le mandataire de la prestation – afin d’accroître la surface d’attaque. Ce type d’audit permet de tester la défense en profondeur, avec la recherche de défauts de cloisonnement utilisateur ou l’élévation de privilèges. 
• Test en boîte blanche : L’auditeur est en possession du code source de l’application. Bien que nécessitant plus de temps, cette méthodologie offre un nouvel angle d’attaque et permet d’identifier des vulnérabilités qui peuvent être complexes à découvrir lors d’un test d’intrusion. C’est une étape complémentaire permettant d’être plus exhaustif.   

Si lors d’un test en boîte noire la surface d’attaque peut paraître très réduite, il est souvent possible d’élargir cette dernière en réalisant une bonne reconnaissance. 

L’objectif de cet article est de présenter ces méthodes de reconnaissance, afin d’illustrer leur importance à travers un scénario d’exploitation réel, réalisé dans le cadre de l’un de nos tests d’intrusion.

La phase d’énumération est l’étape la plus importante permettant de dresser la surface d’attaque d’une application. Cette étape s’appuie sur divers procédés et outils, et génère un niveau d’interaction différent avec la cible, qu’il s’agisse d’une phase de reconnaissance passive, ou active. 

Nous retiendrons donc les sous-étapes suivantes d’une phase de reconnaissance classique :    

• Énumération des services réseau (passive ou active) 
• Énumération de domaines alternatifs (passive ou active)  
• Énumération de l’arborescence des fichiers (passive ou active) 

Contrairement à la version passive, la reconnaissance active suppose une interaction (trafic réseau) avec la cible. Si cette dernière est plus efficace, elle présente l’inconvénient d’avertir le serveur qu’une tentative d’intrusion est en cours. 

La représentation de l’arborescence de fichier est circulaire.

Approche active :

Plusieurs outils open source sont intégrés à la distribution Kali pour automatiser une partir de cette étape :

Dirbuster, dirb, wfuzz.

Enfin, l’obtention de comptes valides sur les services identifiés permet naturellement à l’attaquant d’étendre sa surface d’attaque en lui donnant accès aux fonctionnalités présentes depuis un contexte authentifié.

Obtention d’un compte valide

La manière la plus naturelle d’étendre la surface d’attaque en boîte noire est d’obtenir un compte valide pour être en mesure d’effectuer les tests authentifiés (en boîte grise).

Il existe de nombreux vecteurs permettant d’obtenir un accès authentifié :

• Usurpation d’identité sur l’application grâce à des attaques de type CSRF ou XSS.
• Énumération des comptes valides, puis usurpation d’un compte via une attaque par force brute.
• Compromission de la base de données via une injection SQL pour récupérer les informations d’authentification.
• Rejeu d’identifiants ayant fuités sur Internet. (Exemple : haveibeenpwned.com)

Concrètement, il était alors possible de récupérer l’intégralité des sources de l’application à l’aide de cet outil open source https://github.com/internetwache/GitTools.

À l’aide de l’outil open source hashcat, il a été relativement facile de casser ces empreintes afin de retrouver le mot de passe en clair associé. Un ordinateur doté d’une bonne carte graphique est à même de réaliser plusieurs millions de tentatives par seconde sur le format d’empreinte employé.

hashcat –force -m 400 -a 3 hashes.txt

Lors de nos audits, nous ajoutons systématiquement un mot de passe robuste pour protéger cette porte dérobée et éviter ainsi de dégrader la sécurité globale de l’application auditée.

Les tests réalisés lors de cet audit ont permis de dresser un risque global critique. En effet, par l’exploitation des diverses vulnérabilités présentées, un attaquant depuis Internet est à même de récupérer des informations personnelles sur les clients (nom, adresses, coordonnées bancaires, etc.), ou bien de changer les prix des articles, générant ainsi une perte nette sur le chiffre d’affaires et une altération de l’image de la société.

Enfin, la compromission du serveur hébergeant l’application offre une voie d’entrée privilégiée pour essayer de rebondir sur le réseau bureautique et ainsi réaliser une attaque aux impacts plus conséquents (attaque de type ransomware par exemple).

Grâce à ce retour d’expérience avec un tel scénario d’intrusion, nous pouvons saisir l’importance de réaliser une phase de reconnaissance minutieuse, avec ses multiples étapes.

De ce cas pratique, il ressort ces quelques recommandations :

Les domaines alternatifs présentent l’avantage d’être économiques et de centraliser la gestion de l’infrastructure. Il faut cependant redoubler d’efforts pour revoir la configuration de chacun d’entre eux afin qu’ils garantissent tous le même niveau de sécurité.

En particulier, la gestion des accès aux fichiers du serveur doit être stricte pour interdire l’accès à des fichiers sensibles et à d’autres applications qui n’ont pas vocation à être exposées sur Internet.

Ensuite, il est important d’effectuer des revues de code et des tests d’intrusion pour identifier les plugins vulnérables aux injections classiques (XSS, injections SQL), les portes dérobées et le code obsolète.

Enfin, un durcissement du serveur, aurait fortement complexifié l’attaque présentée.

Pour en savoir plus sur nos offres Ethical Hacking, cliquez ici.