J’avais une liste assez longue de serveurs Rsync sous la main et avec Nmap je voulais m’assurer qu’aucun module (~répertoire) n’était accessible « anonymement » (comme lors d’un pentest par exemple).
Mais avec Nmap je ne pouvais uniquement voir les modules ou lancer un bruteforce (test de couples login/mot de passe) mais c’est tout. Je cherchais le moyen d’identifier si on pouvait accéder à ces modules et lire le contenu (lecture seule à minima), à la manière du script NSE smb-enum-shares pour le protocole SMB.
N’ayant pas de solution, j’ai crée ce script Bash qui est capable d’analyser une grande liste de hosts (adresses IP ou noms d’hôtes) en parallèle (réglable) et d’identifier ceux qui utilisent Rsync pour la synchronisation à distance :
Paramètre « p » pour le mode parallèle
Mode séquentiel par défaut
Il permet de parcourir les modules visibles et tente de se connecter sur chacun d’eux de manière anonyme pour identifier ceux qui sont accessibles. Tous les serveurs et modules accessibles sont ensuite enregistrés dans un fichier texte (commande Rsync complète pour validation) :
Déployer et lancer automatiquement le scanner MassVulScan depuis des instances OpenStack du Cloud Public d’OVH.
Introduction
Les entreprises, notamment, devraient s’assurer de ne pas exposer sur l’Internet des ports réseaux de manière indésirable.
Dans ce but, j’ai voulu aller plus loin avec le scanner MassVulScan en permettant d’effectuer un scan depuis n’importe où sur l’Internet sans devoir louer plusieurs serveurs chaque mois et tout réinstaller à chaque fois.
En effet, lorsque l’on utilise continuellement la ou les mêmes adresses IP source pour scanner son réseau on risque de masquer certaines failles de sécurité : certaines autorisations (théoriquement) accordées qu’à celles-ci, utilisation de mécanismes de sécurité comme fail2ban qui les bloqueraient..
Du coup, malgré des scans réguliers, certains ports peuvent rester ouverts longtemps à tout va sans que l’on s’en aperçoive.. je parle par expérience !
J’ai donc cherché et réfléchi à une solution qui répondrait à ce cahier des charges :
Facilité, simplicité et rapidité du déploiement
Lancement automatique d’un scan complet
Faible coût de fonctionnement et ne payer qu’à l’usage
Fournisseur Cloud disposant de plusieurs Data Center répartis sur la planète
Fournisseur Cloud tolérant cette pratique
Solution
Voici le script Bash que j’ai développé qui répond à mes besoins : osic4MVS
osic4MVS a.k.a. OpenStack Instance Creation For MassVulScan
J’ai retenu le fournisseur de Cloud OVH que j’utilise de longue date, meilleur rapport qualité/prix selon moi. La facturation du Cloud Public est claire (à la demande et sans coûts cachés), la tarification est attractive (0.03$ CAD pour mes scans sur BHS3), et leur interface Web est simple et efficace.
Le script Bash va donc s’appuyer sur l’API d’OVH pour déployer en quelques minutes un instance OpenStack sur laquelle sera installée MassVulScan.
Prérequis
Script
Le script Bash ne fonctionne que sur les OS de la famille Debian.
Le serveur à partir duquel sera lancé ce script devra avoir accès à l’Internet, plus précisément :
ICMP Echo Reply (ping)
SSH port TCP 22
Voici la liste des paquets à installer, suivant si vous utilisez Python 2.x ou Python 3.x :
Vous devez bien-sûr posséder un compte OVH et créer votre projet Cloud Public : OVHCloud
Ici mon projet s’appelle tout simplement « SCANS » :
Mon projet « SCANS »
Ensuite il faut créer un utilisateur OpenStack, rendez-vous dans : Public Cloud / Project Management / Users & Roles
Comptes utilisateurs et rôles
Ajoutez un nouvel utilisateur (avec une description) en lui affectant le rôle « Compute Operator » :
Ce rôle est suffisant pour le fonctionnement du script
On ne peut pas choisir le nom d’utilisateur qui est généré aléatoirement sous la forme « user-XXXXXXXXXXXX », tout comme le mot de passe. Voici notre nouvel utilisateur créé pour notre démonstration :
Nouvel utilisateur en cours de création – Notez bien le mot de passe
N’oubliez pas de noter le mot de passe ! En cas d’oubli, cliquez sur les trois petits points à droite du compte utilisateur pour accéder aux options et en regénérer un nouveau :
Les options du compte utilisateur
Profitez-en pour télécharger de suite le fichier OpenStack RC qui correspond en fait à vos variables d’environnement, il nous sera utile pour la suite. Lors du téléchargement on vous demandera sur quelle région ( = quel Data Center et pays) ce fichier s’appliquera, j’ai choisi ici l’Amérique du nord et leur centre Canadien BHS3 :
Sélectionner une région ou plutôt un centre de données attaché au fichier OpenStack
Rendez-vous sur l’interface Web Horizon pour gérer votre instance OpenStack : Public Cloud / Management Interfaces / Horizon
Choisissez bien votre région, ici BHS3 :
Choisir la région, ici BHS3, Canada
Ensuite, nous allons générer une paire de clés SSH : Project / Compute / Key Pairs
Créez votre paire de clés comme ici, elle se nommera « demo » :
Création d’une paire de clés SSH (privée/publique)
Une fois la création terminée, votre clé SSH privée sera automatiquement téléchargée, comme ici :
Ma clé privée pour la démonstration
C’est terminé, nous avons donc nos quatre éléments importants pour le script Bash :
Un compte utilisateur OpenStack chez OVH Cloud Public
Un fichier OpenStack RC contenant nos variables d’environnement
Ensuite, afin d’automatiser l’utilisation nous allons indiquer le mot de passe directement dans le fichier OpenStack RC. Commentez les lignes 25 à 27 puis ajoutez-en une nouvelle contenant le mot de passe de l’utilisateur OpenStack, comme ceci :
On ajoute le mot de passe de l’utilisateur
Sans cela, il vous sera demandé de saisir le mot de passe plusieurs fois durant le déroulement du script Bash.
Après, déposez votre clé privé et votre fichier OpenStack RC dans un endroit sécurisé et protégez-les comme ici :
chmod 600 openrc.sh
chmod 600 demo.pem
Lecture/écriture pour le propriétaire uniquement, cela peut-être le compte « root », utilisez ensuite « sudo » pour appeler le script Bash par exemple.
Utilisation
On y arrive !!!
Un beau menu vous attend 🙂
Vous aurez besoin de préciser quatre arguments pour pouvoir lancer le script Bash :
Le chemin vers le ou les fichiers contenant les noms d’hôtes et/ou adresses IPv4, format CIDR
Un fichier obligatoire : celui contenant les hosts à scanner
Un fichier optionnel : celui contenant les hosts à exclure
Pour exclure les passerelles de vos opérateurs par exemple
Le chemin vers votre fichier OpenStack RC
Le chemin vers votre clé SSH privée
Le nom de votre clé publique SSH
Le script doit être lancé avec les droits « root » (avec « sudo » ou non), comme ceci :
Après avoir vérifié les arguments passés, le script Bash effectuera les étapes suivantes :
Vérifier l’accessibilité du Cloud Public d’OVH
Vérifier les instances OpenStack existantes
Analyse du ou des fichiers sources (pour ne garder que les entrées valides)
Création de l’instance
Attente de la disponibilité du serveur (ping + SSH)
Déploiement du scanner MassVulScan
Envoi du ou des fichiers hosts
Lancement du scan MassVulScan : Masscan puis Nmap + vulners.nse
Récupération des rapports en local via SCP (si il y a lieu)
Suppression des sessions screen et OpenStack
Screen
Il vous sera possible de suivre l’installation et le scan en live si vous le souhaitez à travers une session screen. Comme ici avec le précédent scan de démonstration :
Session screen pour le suivi ou surveillance
En l’occurrence, vous aurez juste à taper dans un second terminal (droits « root ») :
screen -r scan_2021-07-30_121820
Et pour sortir sans fermer la session, faites au clavier :
CTRL + A et D
Courriels
Pour s’assurer du bon fonctionnement du script et/ou si vous prévoyez de lancer un gros scan de plusieurs heures, vous avez la possibilité de renseigner une ou plusieurs adresses courriels et un serveur SMTP(S).
Vous serez avertis à trois moments différents :
Au démarrage effectif du scan
A la fin du scan vous recevrez les rapports (si il y a lieu)
Une fois la session screen et instance OpenStack supprimées
Il vous suffit pour cela de modifier les variables suivantes dans le script :
smtp_server = serveur SMTP(S) à utiliser
from_address = adresse email d’émission/retour
recipient = liste des destinataires (séparer par une virgule », »)
auth_user_pass = utilisateur et mot de passe encodés dans un URI (si besoin)
Un exemple ci-dessous pour l’encodage dans un URI :
Des exemples ci-dessous de courriels envoyés depuis les serveurs d’OVH :
Exemples de courriels envoyés durant la vie du script
Conclusion
J’utilise régulièrement cet outil (professionnellement) pour m’assurer de ne pas laisser de ports ouverts par inadvertance, surtout lorsque l’on travaille à plusieurs. Il suffit d’une erreur humaine ou d’appliquer une mise à jour pour se retrouver exposer sans le vouloir.
Vous pouvez programmer un lancement hebdomadaire via une tache cron, comme ici toutes les fins de semaine :
Je cherchais le moyen d’obtenir à intervalles réguliers la bande passante consommée (en entrée et sortie) de chacune de mes interfaces réseaux, notamment celles « virtuelles », à savoir des VPN (IPSec), sur mes firewalls.
Pour une architecture réseau en étoile (Hub and spoke en anglais) le plus simple est bien-sûr d’interroger l’équipement central qui s’interconnecte avec chacun des sites distants. Ce qui était mon cas.
L’objectif étant au final d’obtenir un fichier source avec toutes les valeurs me permettant ainsi d’alimenter un script pour ensuite générer une carte d’utilisation de bande passante (network weathermap en anglais) rafraîchie toutes les 5 secondes. Comme ci-dessous :
Script Bash
Explications
Vous trouverez plus bas le script Bash que j’ai utilisé pour récupérer les données via SNMP et les traiter. Comme les compteurs des interfaces réseaux s’incrémentent sans cesse, l’idée est de prendre les valeurs à l’instant T puis de les reprendre à l’instant T + 5 secondes.
Puis par un simple calcul on obtient la bande passante consommée en entrée et sortie. Enfin, en appelant régulièrement le script (crontab ou boucle), vous obtiendrez différentes valeurs qui pourraient alimenter d’autres scripts comme PHP Weathermap par exemple, que j’utilise.
Pensez à mettre les bons paramètres (variables) avant de lancer le script :
J’utilise SNMPv2 dans mon cas car les données récupérées ne sont pas sensibles et il suffit de bien configurer les droits.
J’utilise la MIB standard (ISO/CCITT) pour interroger le firewall, ce qui est le cas avec beaucoup de fournisseurs/marques avec laquelle ils sont compatibles.
Par contre, il était important de prendre les compteurs 64 bits (ifHCInOctets/ifHCOutOctets) et non 32 bits (ifInOctets/ifOutOctets), au risque de voir le compteur repartir à zéro rapidement, surtout si vous avez de gros liens/débits.
Pour finir, vous aurez juste à retirer le nom de fichier « bandwidth.txt » de la ligne 62 pour le générer et le conserver sur disque pour l’intégrer avec un autre script si besoin.
Code source
Voici le script en question, suffisamment commenté je pense :
Voilà, j’espère que ce sera utile à certains d’entre vous. A noter que ce script Bash devrait pouvoir fonctionner tel quel avec d’autres équipements que les Fortigate.
Pour d’autres types de réseaux ou besoins, on pourrait très bien imaginer avoir une liste de firewall en entrée qui serait parcouru et ainsi chacun serait interrogé avec ce script en parallèle pour gagner du temps. Je ferai un article là dessus aussi je pense.
Dernière chose, pour ceux qui s’interrogent sur la mise en forme du code dans l’article, j’ai utilisé l’excellent site : https://carbon.now.sh/
Il y a quelques temps, je cherchais le moyen d’identifier rapidement et efficacement tous les ports accessibles sur différents sites distants connectés à Internet (la quantité de hosts publics représentait un /24). Et je voulais m’assurer, par la même occasion, qu’il n’y avait aucun host qui exposait un service comportant des failles connues.
Jusqu’à présent j’utilisais indépendamment différents outils comme les classiques, mais efficaces, Masscan et Nmap pour obtenir ce que je voulais. Après traitement des résultats, j’exportais cela dans un fichier texte ou un bête fichier HTML. C’est plutôt fastidieux et le processus mal optimisé.
J’ai commencé à chercher un outil qui permettait d’identifier rapidement les ports ouverts et de ne scanner que les hosts ayant un ou plusieurs de ces ports ouverts (et que ceux-ci). Le tout en traitement parallèle afin de gagner du temps. Et pour finir, qu’un beau rapport soit généré, facilement exploitable. Mais n’ayant pas trouvé ce que je cherchais, j’ai décidé de le développer moi-même (en bash) et le voici ! MassVulScan.sh !
L’idée est de combiner la puissance du scanner Masscan pour trouver des ports ouverts, l’efficacité du scanner Nmap pour identifier les services ouverts et leur version, et enfin le script NSE vulners.nse pour identifier les vulnérabilités potentielles (CVE).
Pour accélérer la phase de reconnaissance de Masscan, une phase préalable de découverte permet d’identifier rapidement les hosts en ligne à scanner.
Une fois la phase de reconnaissance terminée, le fichier de sortie est traité afin de trier et rassembler tous ports à scanner par host. Ce qui permet d’optimiser les scans de Nmap. Il y aura autant de sessions Nmap qu’il y aura de hosts à scanner avec des ports ouverts (deux sessions différentes par host si des ports sont découverts avec TCP et UDP).
Pour finir, deux rapports seront générés, l’un concernant les hosts ayant de potentielles vulnérabilités et le second concernant l’exhaustivité des hosts ayant des un ou plusieurs ports ouverts.
Pour ceux qui utilisent un OS de la famille Debian, leur installation ou mise à jour sera automatique 🙂
Paramètres
-f | –include-file : fichier des hosts à scanner, IP ou nom d’hôtes (paramètre obligatoire)
-x | –exclude-file : fichier des hosts à exclure du scan
-i | –interactive : choix des ports à scanner, vitesse (Masscan) et script NSE
-c | –check : détection des hosts en ligne
-a | –all-ports : scan exhaustif de tous les ports (1-65535, TCP/UDP), à 2k paquets/seconde et script vulners.nse
-r | –report : conserver la liste des adresses IP ayant un ou plusieurs ports ouverts
-n| –no-nmap-scan : détecter uniquement les ports ouverts
Explications
Le seul paramètre obligatoire est le fichier en entrée (-f | –include-file) qui doit inclure la liste des hosts ou sous-réseaux à scanner. J’ai fait ce choix car dans mon cas, de nombreux sous-réseaux (privés ou publiques) sont scannés, c’est plus simple à gérer avec des commentaires pour chacun.
Par défaut, seuls les 1000 ports les plus populaires seront scannés à une vitesse maximum de 2500 paquets par minute (pour Masscan) avec le script vulners.nse.
Il est aussi possible d’exclure des hosts ou sous-réseaux (-x | –exclude-file), même format de fichier que le fichier en entrée.
A noter que le script est compatible avec des adresses IP ou des noms d’hôtes.
Un autre paramètre peut être ajouté (-c | –check) si l’on souhaite au préalable identifier les hosts qui sont en ligneavant de lancer la phase d’identification des ports ouverts avec Masscan. Cela peut être un gain de temps considérable pour Masscan.
Une autre option disponible (-a | –all-ports) permet d’indiquer au script de scanner la totalité des ports de 1 à 65535 pour les protocoles TCP et UDP à une vitesse maximum de 2000 paquets par minute (pour Masscan). Attention, sur certains réseaux cela peut être trop élevé, passez par le mode interactif dans ce cas (ci-dessous). En effet, il peut y avoir des perturbations et vous risqueriez de perdre le contrôle… je vous suggère d’utiliser la commande « timeout » si vous n’êtes pas sûr de vous au début, c’est bien pratique.
Un autre paramètre est le mode interactif (-i | –interactive) qui vous permet de choisir la liste des ports à scanner ainsi que la vitesse de scan de Masscan et le script NSE (nmap) à utiliser.
Fonctionnement et particularités
Interfaces réseaux
J’ai commencé récemment à m’amuser sur le site de pen-testing https://www.hackthebox.eu, j’ai ainsi eu l’occasion de tester mon script et de l’améliorer pour le coup.
Il faut savoir que pour accéder aux différents labs, un VPN est monté avec OpenVPN. Dans mon cas, une nouvelle interface « tun0 » est créée avec une IPv4 dans le subnet 10.10.14.0/23, ainsi qu’une route pour atteindre les différents serveurs virtuels (10.10.10.0/24 via 10.10.14.1).
Le problème c’est que Masscan, qui est appelé au début du script, n’utilisera par défaut que l’interface qui possède la route par défaut, en l’occurrence celle d’Internet (« eth0 » par exemple)… du coup impossible de scanner les serveurs.
Le script détectera donc si plusieurs interfaces réseaux existent et vous demandera de sélectionner celle à utiliser pour atteindre les hosts. Pas de problèmes pour Nmap qui gère cela correctement : le scan d’un côté pour identifier les services (interface « tun0 ») et la récupération des CVE associées via une API chez https://vulners.com (interface « eth0 »).
Masscan -> Nmap, passage de relais
Dans un soucis d’efficacité, le script rassemblera tous les ports identifiés comme ouvert par host. C’est à dire qu’une fois que Masscan aura identifié tous les ports ouverts, le script fera un tri pour que Nmap puisse lancer la reconnaissance de services uniquement sur les ports ouverts. Exemple de fichier intermédiaire trié et préparé pour Nmap :
Fichiers d’entrées TCP et UDP pour Nmap
Nmap, plus rapide avec le parallélisme
Toujours dans un soucis de performance, le script lance autant d’instances Nmap qu’il y a de hosts à scanner, elle fonctionnent toutes en parallèles :
Lancement des scans Nmap
Ce qui fait que le temps maximum d’exécution de Nmap dépendra donc uniquement du scan qui aura pris le plus de temps, et non du temps total des scans Nmap si nous étions en mode « série » (à la queue leu-leu).
Il y a une gestion de queue avec une limite de 50 scans en parallèles maximum (variable à changer si besoin). Dès qu’un scan est terminé, un autre prend le relais.
Identification des CVE avec vulners.com
Pour l’identification des CVE, le script s’appuie donc sur le site de https://vulners.com via une API. Il en existe d’autres mais c’est le plus fiable que j’ai trouvé. De plus, il trie directement les CVE par ordre de criticité, ce qui est bien pratique :
Exemple de vulnérabilités identifiées et triées pour un host donné sur le port SMB/SAMBA
Le site fait un gros travail pour fournir des données les plus à jour possibles.
Rapports
Si après analyse des hosts ont été détectés comme « potentiellement » vulnérables, un fichier au format TXT sera généré comportant uniquement ceux-ci. Cela permet de se concentrer dessus (avec tentative de résolution reverse DNS) :
Rapport sur les hosts vulnérables
Ensuite, un second fichier au format HTML sera cette fois généré comportant l’exhaustivité des hosts identifiés avec des ports ouverts. Pour ce dernier, j’utilise l’excellent template Nmap XSL avec bootstrap « nmap-bootstrap.xsl » qui produit de beaux rapports et qui surtout permet de filtrer et trier nos résultats :
Rapport Nmap avec le template « nmap-bootstrap.xsl » sur les hosts ayant des ports ouverts
Performance
Pour évoquer la performance du script, un dessin vaut mieux qu’un long discours. Ci-dessous une capture d’écran du déroulement complet d’un scan dont voici les caractéristiques :
à raison d’une cadence de 2500 paquets par seconde (Masscan)
puis 82 scans Nmap lancés en parallèles pour détecter les services actifs et vulnérabilités éventuelles
concernant 236 ports ouverts
et enfin génération des rapports
Seulement 03h30 pour scanner 235 hosts sur 131068 ports…
Il est toujours possible d’améliorer encore la vitesse d’execution du script en augmentant le nombre de paquets par seconde de Masscan, tout dépend de la qualité de vos liens Internet et de votre réseau interne.
Mais attention à ne pas perturber votre infrastructure, changez la valeur graduellement.
Mot de la fin
Voilà, j’espère que cet article vous donnera envie de tester mon script.
J’apporte régulièrement de nouvelles fonctions et cherche à l’optimiser constamment, je suis ouvert aux critiques et propositions d’amélioration.
Dernière chose, mon anglais n’est pas parfait, soyez indulgent ! (je parle du script).
Merci de m’avoir lu jusqu’au bout, j’attends vos commentaires maintenant 😉
