Ajouter une cible réseau ou un site web

Cliquer sur Gestion des actifs > Cibles réseau et sites web
Cliquer sur le bouton Ajouter
Compléter le formulaire :
- « Source » correspond au nœud depuis lequel lancer les analyses
- « Cible » correspond à la cible réseau ou au site web à analyser vous pouvez indiquer une cible réseau sous la forme d’un nom de domaine ou d’une adresse IP, ou un site web sous la forme d’une URL ; dans les deux cas, un scan de port est effectué sur la cible ainsi qu’une reconnaissance des services utilisés afin de déterminer les versions des services exposés
- « Portée du scan » définit l’amplitude du scan à partir de la cible :
  - Par défaut : utilise la portée par défaut (Dossier)
  - URL : scanne uniquement l’URL de base exacte donnée
  - Page : scanne chaque URL correspondant au chemin de l’URL de base (chaque variation de chaîne de requête)
  - Dossier : scanne chaque URL en commençant par la valeur de l’URL de base. Cette URL de base doit avoir une barre oblique finale (pas de nom de fichier)
  - Domaine : scanne chaque URL dont le nom de domaine correspond à celui de l’URL de base
  - Sous-domaine : scanne chaque URL dont le sous-domaine correspond à celui de l’URL de base
  - Punk : scanne chaque URL trouvée quel que soit le domaine
- « URL du Swagger » spécifie l’emplacement du fichier de description des API (YAML ou JSON) pour ajouter les URL qui y sont décrites au scan
- « URL exclues du scan » spécifie la liste des URL séparées par une virgule à exclure du scan, les URL peuvent contenir des wildcards
- « Type d’authentification » spécifie la méthode utilisée pour s’authentifier auprès de l’application web cible
  - Aucun : Aucune authentification n’est effectuée
  - Basic : Utilise l’authentification HTTP Basic, où le nom d’utilisateur et le mot de passe sont envoyés en clair, encodés en base64, dans les en-têtes de requête HTTP
  - Digest : Une forme plus sécurisée que l’authentification Basic, utilisant une réponse chiffrée pour authentifier la requête
  - NTLM : Utilisé principalement dans les environnements Windows, NTLM est un protocole de sécurité pour l’authentification
  - POST : Soumet les données d’authentification au serveur via une requête HTTP POST, permettant une authentification côté serveur
  - HTTP Bearer : Permet de renseigner un jeton d’authentification JWT à transmettre dans chaque requête HTTP dans l’en-tête Authorization, sous le format Authorization: Bearer <jeton>. Seul le jeton est à renseigner dans le champ associé sur Cyberwatch
  - Selenium : Utilisé pour effectuer une authentification en exécutant des actions automatisées spécifiées dans un fichier .side. Une fois ces actions réalisées, les cookies capturés sont utilisés pour la suite du scan. Les actions acceptées sont open, type et click. Pour chacune des actions, la définition de l’élément cible doit commencer par id=, css= ou xpath=
  - Cookie : Spécifie un ou plusieurs cookies à ajouter dans chacune des requêtes HTTP afin de permettre une authentification continue sur le site web cible. Si plusieurs cookies sont renseignés, il est possible de les séparer par un point-virgule, en suivant le format cookie=valeur;cookie=valeur
En raison de l’expiration régulière des cookies, il est recommandé d’associer les actifs utilisant cette méthode d’authentification à une politique d’analyse manuelle, afin de pouvoir garantir la validité des cookies avant chaque analyse.
Valider en cliquant sur « Sauvegarder »

Configurer les paramètres de scan

Certains paramètres avancés sont configurables par politique d’analyse, dont la durée maximale de scan web par module et la durée maximale de parcours web. Il faut pour cela se rendre dans Réglages > Politique d’analyses, et éditer les politiques des cibles et sites webs concernés. Les paramètres de scan se trouvent dans la section « Paramètres avancés ».

Concernant le scan d’application web, plusieurs options peuvent être configurées :

Durée maximale de parcours : Il s’agit du temps maximal alloué à l’exploration de la surface d’attaque, telle que la découverte des pages, des paramètres et des formulaires présents
Durée maximale de scan par module : Une fois la phase d’exploration terminée, un ensemble de modules spécifiques testant des vulnérabilités potentielles vont être exécutés. Cette valeur contrôle le temps d’exécution maximal alloué à chacun de ces modules
Headless : Le mode headless va utiliser un navigateur sans interface pour tester les vulnérabilités de sécurité en simulant des actions utilisateurs dans des applications web, notamment celles construites avec des frameworks JavaScript comme Angular, React ou Vue

Certaines applications à scanner en mode headless peuvent nécessiter plus de temps, et obtenir des résultats partiels avec les durées maximales par défaut. Dans ce type de cas, les valeurs recommandées à configurer dans la politique de scan sont de 600 secondes pour la durée maximale de parcours et 300 secondes pour la durée maximale de scan par module.

Scans web authentifiés

Lors de l’ajout ou de l’édition d’une cible réseau, il est possible de spécifier un jeu d’identifiants et une méthode d’authentification. Ces paramètres ne s’appliquent que quand la cible est un site web, ou au moins à un port HTTP ouvert.

Afin d’activer l’authentification, il est nécessaire de créer préalablement un jeu d’identifiants de type Scan web depuis le menu Identifiants enregistrés.

Les méthodes d’authentification correspondent aux types supportés par l’en-tête HTTP Authorization, à l’exception de la méthode post qui simule un utilisateur qui entre ses identifiants dans un formulaire de connexion. L’URL du formulaire de connexion ne s’applique qu’à la méthode post.

Produits supportés par les cibles réseau ou site web

Cyberwatch supporte toute adresse IP, comme tout URL ou nom de domaine valide et résolu.

Dans l’ensemble des cas, Cyberwatch vérifie quels ports sont ouverts parmi les 3000 ports les plus couramment utilisés. Sur les ports ouverts, deux stratégies d’analyse sont utilisées.

Un scan passif, qui détecte les versions des services exposés sur chaque port de la cible, et identifie les vulnérabilités qui y sont associées. Lorsqu’il s’agit d’un port web, un scan supplémentaire permettant d’identifier des défauts de configuration issus du top 10 OWASP est aussi exécuté. Ce dernier couvre entre autres les défauts de configuration au sein des headers, et identifie les librairies utilisées.
Un scan actif, qui est un examen plus approfondi en fonction des spécificités de chaque port. Si le port supporte le TLS, un audit TLS est effectué afin d’identifier si des suites cryptographiques faibles sont acceptées, l’utilisation de protocoles dépréciés ou une invalidité du certificat. Si le port répond aux requêtes http/https, Cyberwatch effectue un second scan dont le but est d’identifier d’autres défauts de configuration issus du top 10 OWASP, comme par exemple la possibilité d’effectuer des injections XSS/SQL…

Les deux analyses OWASP sont décrites ci-dessous.

Analyses OWASP (Wapiti)

Wapiti vous permet d’auditer la sécurité des applications web. Il effectue des scans externes de l’application web (authentifiés ou non en fonction du mode de scan utilisé) en explorant les pages web de l’application déployée, à la recherche de défauts de sécurité. Une fois qu’il obtient la liste des URL, des formulaires et de leurs entrées, Wapiti agit comme un fuzzer, injectant des charges utiles et évaluant divers retours applicatifs.

Afin que le scan log4j puisse fonctionner, il est nécessaire que Cyberwatch ait accès au DNS suivant : dns.cyberwatch.app

Pour plus d’informations concernant ce projet, vous pouvez visiter sa page GitHub.

Informations générales

Le scan Wapiti peut être divisé en deux grandes étapes consécutives :

Le « scan passif » : cette étape est composée de modules permettant de faire une étude statique des défauts de sécurité potentiels
Le « scan actif » : cette étape est composée de modules d’attaque permettant de tester activement la surface d’exposition afin d’identifier certains défauts de sécurité

Ces deux étapes sont précédées d’une reconstitution de la liste des URL disponibles.

Wapiti propose deux types différents de scan :

Le « mode normal » : ce mode va directement effectuer des requêtes (similaires à des requêtes cURL) sur la cible
Le « mode Headless » : avec ce mode, Wapiti va lancer un navigateur sans interface graphique pour analyser des applications web, en particulier celles basées sur JavaScript. Il permet une meilleure interaction avec les Single Page Applications (SPAs) et la détection optimale des défauts de sécurité liés à l’exécution dynamique du JavaScript

Le scan passif

Liste non exhaustive des actions effectuées par le scan passif :

Analyse des flags des cookies pour détecter les configurations non sécurisées
Analyse de la politique de sécurité du contenu (CSP) pour détecter d’éventuelles faiblesses
Analyse des en-têtes HTTP pour détecter des configurations non sécurisées
Détection des technologies web utilisées par le site
Énumération des modules WordPress

Pour plus d’informations, vous trouverez la liste des modules ici.

Le scan actif

Liste non exhaustive des actions effectuées par le scan actif :

Recherche des défauts de sécurité concernant l’injection CRLF (Carriage Return Line Feed)
Recherche des défauts de sécurité CSRF (Cross-Site Request Forgery)
Identification des potentiels points d’injection
Recherche des défauts de sécurité d’injection SQL
Découverte des fichiers de sauvegarde qui pourraient divulguer des informations sensibles
Tentatives de brute-forcer les formulaires de connexion
Recherche des mauvaises configurations ou des fichiers .htaccess accessibles qui pourraient être exploités
Tentatives d’injections SQL
Évaluation des méthodes HTTP qui sont autorisées par le serveur
Recherche des défauts de sécurité de redirection ouverte
Identification des défauts de sécurité Server-Side Request Forgery (SSRF)
Recherche des défauts de sécurité de type Cross-Site Scripting (XSS)
Vérification de la présence de la vulnérabilité Log4Shell

Pour plus d’informations, vous trouverez la liste des modules ici.

Les métadonnées

Les métadonnées peuvent donner des indications quant à l’état du scan effectué. Elles sont affichées en deux colonnes, nommées “Clé” et “Valeur”.

Les pages parcourues

La clé se présente sous la forme suivante : crawled_pages.[active|passive]. La colonne `"Valeur"` indiquera le nombre de pages parcourues en mode actif ou passif, sur le port indiqué.

Afin de connaitre la liste des URL parcourues par les scans actif et passif, ouvrir depuis l’onglet « Analyses » de la fiche de l’actif concerné, les détails du script « Scan d’application web (OWASP) - Mode [passif/actif] ».

Valeur à 1 ou 0

Si la colonne "Valeur" indique "0", cela peut signifier qu’il y a eu un souci lors de l’authentification vers la page demandée
Si la colonne "Valeur" indique "1", alors que vous avez sélectionné une portée de scan plus large, plusieurs interprétations sont possibles

Il est possible que l’adresse cible utilise diverses redirections, perturbant alors le bon fonctionnement du scan.

Par exemple, si la cible renseignée commence par http, alors que le site utilise https, la redirection du port 80 vers 443 peut interférer avec le scan. Un autre exemple commun, si la cible est https://www.example.com, alors que le site est https://www.example.com, cela va également entrainer une redirection.

L’adresse d’une cible réseau doit impérativement être directement l’adresse à scanner sans redirection. L’utilisation d’une adresse répondant par une redirection entrainera l’échec du scan.