Découverte active
La découverte active consiste en la sollicitation des machines du réseau afin d’en déterminer leur nature. Cette méthode peut être dangereuse si certains hosts ne sont pas prêts à être sollicité de manière importante. C’est pour cette raison qu’une découverte passive du réseau préalable peut être nécessaire. Il est possible que toutes les machines n’aient pas été découvertes lors de la phase de découverte passive, il va donc falloir limiter dans un premier temps l’intensité de la découverte active.
On va donc utiliser une commande qui réalise des requêtes ARP. Toutes les machines en IPv4 capables de communiquer avec le LAN doivent être capables de répondre aux requêtes ARP. Les principales limites de cette méthode sont que les machines doivent être démarrées et les paquets ARP ne traversent pas les routeurs. Pour cette dernière raison, en fonction d’où se trouve KALI01 sur le réseau, la découverte peut grandement être limitée par un routeur au milieu du réseau. Il faudra donc utiliser des méthodes de découverte basées sur TCP et/ou UDP et/ou ICMP.
Découverte sommaire du réseau
sudo arp-scan --localnet --retry=1 --bandwidth=16000 --vlan=0 &> ./activ/arp-scan.log
rapport
Le flag –retry indique qu’une seule requête sera envoyée par hosts IP. Cela limite l’impacte de la découverte sur le réseau et la machine qui le compose. Le flag –bandwith limite la taille des paquets ARP en sortie de KALI01 à 16Kb/secondes au lieu de 256Kb/secondes par défaut. Cette réduction est importante pour éviter un encombrement du réseau (tempête ARP) qui pourrait provoquer un déni de services. Le flag –vlan cible un vlan particulier
┌──(kali㉿kali)-[~/ARS_DM6]
└─$ cat activ/arp-scan.log
Interface: eth0, type: EN10MB, MAC: 00:0c:29:b3:b1:80, IPv4: 192.168.2.21
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.2.1 00:0c:29:a0:b9:3f VMware, Inc.
192.168.2.2 00:0c:29:57:80:1f VMware, Inc.
192.168.2.3 00:0c:29:14:7d:40 VMware, Inc.
192.168.2.4 00:0c:29:2c:79:b2 VMware, Inc.
192.168.2.10 00:0c:29:d6:ab:a4 VMware, Inc.
192.168.2.14 00:0c:29:ed:be:d7 VMware, Inc.
192.168.2.222 00:0c:29:d2:88:50 VMware, Inc.
7 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 8.915 seconds (28.72 hosts/sec). 7 responded
Découverte au-delà de la couche 2
IPv4
Comme précisé précédemment, le protocol ARP ne suffit pas pour réaliser une découverte réseau complète. Il faut s’appuyer sur des protocoles qui traversent les équipements de couches 3 tels que les routeurs.
ICMP
ICMP est un protocol dit de couche 3 intermédiaire, qui ne constitue pas une liaison entre la couche 2 et ses couches supérieures. Il peut être très utile pour une découverte puisqu’il ne présente pas d’indication de ports et est par conséquent pas limité au type d’ouverture des ports de la machine cible. Il n’est alors pas nécessaire d’adresser tous les ports de la machine cible comme cela pourrait être nécessaire avec les protocoles TCP et UDP.
La première manière la plus évidente et les plus rapides consiste en l’envoie d’un ping en broadcast sur l’ensemble du réseau si on connaît sa range d’IP, ou sur l’ensemble des adresses publiques de la RFC 1918.
Ici, nous savons que l’ensemble du réseau est contenu dans l’espace d’adressage 192.168.0.0/16. C’est donc sur cet espace d’adressage que nous allons adresser notre ping en broadcast.
ping -b 192.168.255.255 -c 1
Le flag -b indique que la commande ping est effectuée en broadcast, le flag -c indique qu’un seul paquet est envoyé dans le réseau.
Nous n’utiliserons pas cette commande pour notre découverte réseau, car elle présente de nombreux inconvénients. La plupart des machines modernes ne répondent pas aux sollicitations en broadcast, les routeurs bloquent généralement les broadcast, et si les machines venaient à toutes répondre simultanément, le réseau pourrait être saturé, des réponses seraient perdues.
Nous allons donc uniquement nous appuyer sûr de l’unicast, beaucoup plus lent que du multicast mais ses limitations ne nous permettent pas de l’utiliser de manière décente.
nmap propose une fonctionnalité qui permet de déterminer si une machine est active grâce à une ou plusieurs requêtes ICMP:
sudo nmap -v -sn -PE -PP -PM 192.168.0.0/16 --max-retries 1 -oX nmap-ping-scan-ICMP.xml
rapport .HTML
Le flag -sn permet de faire un “ping scan” sans se préoccuper des ports de la machine ciblée, mais seulement si la machine cible est “UP” ou “DOWN”. Les flags -PE -PP -PM permettent d’envoyer 3 pings distincts via le protocole ICMP respectant respectivement les normes RFC 1122, RFC 792, RFC 950. Sur le rapport d’exécution, les IPs des machines ayants répondu favorablement à la sollicitation sont affichées en vert. Le flag –max-retries 1 permet d’éviter que plusieurs paquets réseau identiques soient émis lorsque KALI01 ne reçoit pas de réponse de la part de l’hôte adressé. Ce dernier flag permet un gain en temps de processing considérable.
Malgré la norme, tous les systèmes ne répondront au ne répondent pas aux requêtes envoyées dans la commande précédente. Le flag -sn lorsqu’il est utilisé seul (sans -P*), des paquets ICMP, UDP et TCP vont être envoyés.
sudo nmap -v -sn 192.168.0.0/16 --max-retries 1 -oX nmap-ping-scan.xml
rapport .HTML
Les commandes qui balaient des espaces d’adressage peuvent rapidement prendre plusieurs dizaines de minutes jusqu’Ã plusieurs jours.
Découverte DNS
L’énumération DNS peut apporter des informations intéressantes sur la présence de nouvelles adresses et de services.
dig 192.168.0.0/16 +nocomments +noquestion +nostats +noadditional
┌──(kali㉿kali)-[~/ARS_DM6/activ]
└─$ dig 192.168.0.0/16 +nocomments +noquestion +nostats +noadditional
; <<>> DiG 9.18.1-1-Debian <<>> 192.168.0.0/16 +nocomments +noquestion +nostats +noadditional
;; global options: +cmd
. 372 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022061800 1800 900 604800 86400
Synthèse
Toutes les commandes vues précédemment, y compris dans la section découverte passive, peuvent être synthétisées dans un seul script qui permettra de recueillir toutes les adresses IPv4 avant d’envisager des analyses plus en détail de machines trouvées. Voici le script qui construit le fichier ips.txt:
#!/bin/bash
#####################################################
# REGEX
#####################################################
ip_regex="\([0-9]\{1,3\}[.]\)\{3\}[0-9]\{1,3\}"
space_regex="[[:space:]]"
mac_regex="\([0-9a-f]\{2\}[:]\)\{5\}[0-9a-f]\{2\}"
#####################################################
# PATH
#####################################################
root_dir='.'
database_ip="${root_dir}/database_ip.txt"
report_dir="${root_dir}"
#####################################################
# FUNCTION HELPER
#####################################################
if [[ ! -f "${database_ip}" ]]; then
DIR=$(dirname "${database_ip}")
FILE=$(basename "${database_ip}")
mkdir -p "${DIR}"
touch "${FILE}"
fi
# save_ips "192.168.2.2" "192.168.2.1" "192.168.2.222"
# $1 ips
save_ips() {
for ip in "$@"; do
grep -q "^${ip}$" "${database_ip}"
if [ $? -eq 1 ]
then
echo "${ip}" >> "${database_ip}"
echo "add: ${ip}"
fi
done
}
# $1 function name
IN() {
echo "in: ${1}"
}
# $1 function name
OUT() {
echo "out: ${1}"
}
#####################################################
# DECOUVERTE PASSIVE
#####################################################
# Consultation simple de la table ARP de ma machine
arp_func() {
IN "${FUNCNAME[0]}"
cmd=$(arp -a | grep "${mac_regex}" | grep -o "${ip_regex}")
save_ips ${cmd}
OUT "${FUNCNAME[0]}"
}
arp_func
#####################################################
# DECOUVERTE ACTIVE
#####################################################
# Solliciter toutes les machines du réseau local avec des requêtes ARP
arp_scan_func() {
IN "${FUNCNAME[0]}"
cmd=$(arp-scan --localnet --retry=1 --bandwidth=16000 --vlan=0 | grep -o "${ip_regex}")
save_ips ${cmd}
OUT "${FUNCNAME[0]}"
}
arp_scan_func
# Solliciter toutes les machines du réseau local avec des ping (ICMP)
nmap_ICMP_func() {
IN "${FUNCNAME[0]}"
cmd=$(nmap -sn -PE -PP -PM 192.168.0.0/16 --max-retries 0 | grep "Nmap scan report for" | grep -v "\[host down\]" | grep -o "${ip_regex}")
save_ips ${cmd}
OUT "${FUNCNAME[0]}"
}
nmap_ICMP_func
# Solliciter toutes les machines du réseau local avec les protocoles ICMP, UDP et TCP
nmap_ICMP_UDP_TCP_func() {
IN "${FUNCNAME[0]}"
cmd=$(nmap -sn 192.168.0.0/16 --max-retries 1 | grep "Nmap scan report for" | grep -v "\[host down\]" | grep -o "${ip_regex}")
save_ips ${cmd}
OUT "${FUNCNAME[0]}"
}
nmap_ICMP_UDP_TCP_func
# Solliciter toutes les machines du réseau local avec les protocoles ICMP, UDP et TCP
dig_DNS_func() {
IN "${FUNCNAME[0]}"
cmd=$(dig 192.168.0.0/16 +nocomments +noquestion + nostats +noadditional | grep -o "${ip_regex}")
save_ips ${cmd}
OUT "${FUNCNAME[0]}"
}
dig_DNS_func
####################################### END
exit 0
La commande masscan aurait pu être utilisée si les premières commandes passives avaient décelé un grand nombre d’hosts sur le réseau. Étant donné le peu de machines, nmap est privilégiée pour sa précision.
Le protocole SNMP
Le protocole SNMP occupe une place particulière dans le domaine de la cartographie réseau puisqu’il est dédié à cette tâche. En effet, défini dans la RFC 1157, il permet de déployer des agents SNMP sur les machines hôtes du réseau qui auront pour rôle d’interagir avec le ou les SNMP managers. De nombreuses informations relatives à l’état des hôtes peuvent transiter grâce à ce protocole tel que l’OS son OS, son pourcentage d’occupation RAM, disque, CPU, etc.
Il est donc pertinent de scanner le réseau à la recherche de tels agents. Pour ce scan, le port standard 161 sera sollicité en UDP ainsi que le port commun d’utilisation dans un cadre privé 10161.
nmap --script-updatedb -sU -p snmp,10161 -v --max-retries 0 -iL ips.txt -oX nmap-ping-scan-SNMP.xml
rapport .HTML
-iL permet de fournir un fichier en guise d’input pour la commande. Le flag -sU permet de se limiter à un scan de port UDP.
On remarque dans ce rapport que le port 161 de la machine 192.168.2.222 est sur écoute en UDP, nous allons donc l’interroger afin qu’il nous livre les informations qu’il expose sur l’hôte.
┌──(kali㉿kali)-[~/ARS_DM6/activ]
└─$ snmpwalk -v1 192.168.2.222 -c public
iso.3.6.1.2.1.1.1.0 = STRING: "Linux L01 5.4.0-113-generic #127-Ubuntu SMP Wed May 18 14:30:56 UTC 2022 x86_64"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
iso.3.6.1.2.1.1.3.0 = Timeticks: (241560) 0:40:15.60
iso.3.6.1.2.1.1.4.0 = STRING: "Me <me@example.org>"
iso.3.6.1.2.1.1.5.0 = STRING: "L01"
iso.3.6.1.2.1.1.6.0 = STRING: "Sitting on the Dock of the Bay"
iso.3.6.1.2.1.1.7.0 = INTEGER: 72
iso.3.6.1.2.1.1.8.0 = Timeticks: (9) 0:00:00.09
iso.3.6.1.2.1.1.9.1.2.1 = OID: iso.3.6.1.6.3.10.3.1.1
iso.3.6.1.2.1.1.9.1.2.2 = OID: iso.3.6.1.6.3.11.3.1.1
iso.3.6.1.2.1.1.9.1.2.3 = OID: iso.3.6.1.6.3.15.2.1.1
iso.3.6.1.2.1.1.9.1.2.4 = OID: iso.3.6.1.6.3.1
iso.3.6.1.2.1.1.9.1.2.5 = OID: iso.3.6.1.6.3.16.2.2.1
iso.3.6.1.2.1.1.9.1.2.6 = OID: iso.3.6.1.2.1.49
iso.3.6.1.2.1.1.9.1.2.7 = OID: iso.3.6.1.2.1.4
iso.3.6.1.2.1.1.9.1.2.8 = OID: iso.3.6.1.2.1.50
iso.3.6.1.2.1.1.9.1.2.9 = OID: iso.3.6.1.6.3.13.3.1.3
iso.3.6.1.2.1.1.9.1.2.10 = OID: iso.3.6.1.2.1.92
iso.3.6.1.2.1.1.9.1.3.1 = STRING: "The SNMP Management Architecture MIB."
iso.3.6.1.2.1.1.9.1.3.2 = STRING: "The MIB for Message Processing and Dispatching."
iso.3.6.1.2.1.1.9.1.3.3 = STRING: "The management information definitions for the SNMP User-based Security Model."
iso.3.6.1.2.1.1.9.1.3.4 = STRING: "The MIB module for SNMPv2 entities"
iso.3.6.1.2.1.1.9.1.3.5 = STRING: "View-based Access Control Model for SNMP."
iso.3.6.1.2.1.1.9.1.3.6 = STRING: "The MIB module for managing TCP implementations"
iso.3.6.1.2.1.1.9.1.3.7 = STRING: "The MIB module for managing IP and ICMP implementations"
iso.3.6.1.2.1.1.9.1.3.8 = STRING: "The MIB module for managing UDP implementations"
iso.3.6.1.2.1.1.9.1.3.9 = STRING: "The MIB modules for managing SNMP Notification, plus filtering."
iso.3.6.1.2.1.1.9.1.3.10 = STRING: "The MIB module for logging SNMP Notifications."
iso.3.6.1.2.1.1.9.1.4.1 = Timeticks: (8) 0:00:00.08
iso.3.6.1.2.1.1.9.1.4.2 = Timeticks: (8) 0:00:00.08
iso.3.6.1.2.1.1.9.1.4.3 = Timeticks: (8) 0:00:00.08
iso.3.6.1.2.1.1.9.1.4.4 = Timeticks: (8) 0:00:00.08
iso.3.6.1.2.1.1.9.1.4.5 = Timeticks: (9) 0:00:00.09
iso.3.6.1.2.1.1.9.1.4.6 = Timeticks: (9) 0:00:00.09
iso.3.6.1.2.1.1.9.1.4.7 = Timeticks: (9) 0:00:00.09
iso.3.6.1.2.1.1.9.1.4.8 = Timeticks: (9) 0:00:00.09
iso.3.6.1.2.1.1.9.1.4.9 = Timeticks: (9) 0:00:00.09
iso.3.6.1.2.1.1.9.1.4.10 = Timeticks: (9) 0:00:00.09
iso.3.6.1.2.1.25.1.1.0 = Timeticks: (80091972) 9 days, 6:28:39.72
iso.3.6.1.2.1.25.1.2.0 = Hex-STRING: 07 E6 06 13 00 12 14 00 2B 02 00
iso.3.6.1.2.1.25.1.3.0 = INTEGER: 393216
iso.3.6.1.2.1.25.1.4.0 = STRING: "BOOT_IMAGE=/boot/vmlinuz-5.4.0-113-generic root=UUID=f14f550a-3ad7-46c8-b113-bed67d117930 ro quiet splash
"
iso.3.6.1.2.1.25.1.5.0 = Gauge32: 1
iso.3.6.1.2.1.25.1.6.0 = Gauge32: 326
iso.3.6.1.2.1.25.1.7.0 = INTEGER: 0
End of MIB
Découverte agressive
À ce stade, toutes les machines n’ont pas forcément toutes été découvertes. La découverte s’affinera au fur et à mesure des jours et des lancements de découvertes.
Maintenant que nous sommes en mesure de déterminer les adresses IPs des machines du réseau, nous allons pouvoir passer à l’étape d’analyse de chacune de ces machines.
Dans cette phase, nous allons nous consacrer à la découverte des OS de chaque machine, les services qu’elles exposent et leurs liaisons réseau avec KALI01
Une fois les machines découvertes, il peut être intéressant de déterminer les liens réseau qui relient les machines entrent-elles.
Ces opérations sont très coûteuses en temps, il faut donc créer un fichier contenant toutes les IPs déjà découvertes :
sudo nmap --script-updatedb -A --version-all --osscan-guess --script path-mtu -v --max-retries 0 -iL ips.txt -oX nmap-ping-scan-MTU.xml
rapport .HTML
Le flag –script-updatedb permet la mise à jour des scripts nmap. Le flag -A permet la détection d’OS, la détection des services, les scripts de scans et les chemins réseau vers chaque cible. On peut ajouter à cela le flag –osscan-guess qui augmente au maximum la précision de l’empreinte des OS. –version-all augmente l’agressivité de détection des services, –script path-mtu est un script additionnel qui permet de calculer la MTU minimum pour chaque route de KALI01 vers ses hôtes cibles.
Il pourrait être intéressant de déployer des agents SNMP sur le réseau pour éviter les méthodes de cartographie / découverte approximatives et dangereuses pour l’intégrité du réseau.
Vulnérabilité des services
Dans cette partie, nous allons analyser les vulnérabilités potentielles des services exposés par les hôtes du réseau.
Installation du script vulscan:
cd /usr/share/nmap/scripts
sudo git clone https://github.com/scipag/vulscan.git
cd vulscan/utilities/updater
sudo chmod +x updateFiles.sh
Il faut maintenant mettre à jour les bases de données de vulscan:
./updateFiles.sh
Bases de données :
┌──(kali㉿kali)-[/usr/share/nmap/scripts/vulscan]
└─$ find . -name "*.csv"
./openvas.csv
./xforce.csv
./scipvuldb.csv
./securityfocus.csv
./cve.csv
./securitytracker.csv
./osvdb.csv
./exploitdb.csv
sudo ln -s `pwd`/scipag_vulscan /usr/share/nmap/scripts/vulscan
L’installation est terminée.
sudo nmap -v --script-updatedb -sV --version-all --script vuln,vulscan/ -iL ips.txt --max-retries 0 -oX nmap-ping-scan-VULN.xml
Pour exploiter les vulnérabilités, nous utilisons les scripts vuln et vulscan (précédemment installés). Pour cette commande nmap, nous recourons à l’analyse des services via la flag -sV avec la précision maximale –version-all sur lequel les scripts vont s’appuyer. Cesdeux scripts vont chercher des vulnérabilités de manière active, en envoyant des paquets réseau spécifiques aux ports ouverts et de manière passive en répertoriant les vulnérabilités de grande renommée (CVEC par exemple) d’une technologie.
IPv6
En IPv6, le préfixe des IPs locales (local link) est fe80::/10, ce qui indique théoriquement 2^118 IPv6. Il est donc impossible de s’appuyer sur un scan séquentiel ici.
ICMPv6
Le processus de découverte du réseau en IPv6 va être similaire à l’IPv4 à l’exception près qu’elle va uniquement s’appuyer sur le protocol ICMPv6, protocol incontournable de cette nouvelle version d’IP. La stack IPv6 ne possède pas de broadcast comme IPv4, cependant, il existe un ensemble de préfixes standard qui permettent de solliciter en multicast des équipements du réseau local.
Pour cette découverte, nous utiliserons le package thc-ipv6 composé de plusieurs outils dont atk6-alive6:
┌──(kali㉿kali)-[~]
└─$ sudo atk6-alive6 eth0
Alive: fe80::20c:29ff:fe14:7d40 [ICMP echo-reply]
Alive: fe80::20c:29ff:fe2c:79b2 [ICMP echo-reply]
Alive: fe80::af08:1fb8:b67a:56ba [ICMP echo-reply]
Alive: fe80::20c:29ff:fea0:b93f [ICMP echo-reply]
Alive: fe80::8123:3e41:549f:bbf6 [ICMP parameter problem]
Alive: fe80::c5df:fb69:c231:273d [ICMP parameter problem]
Alive: fe80::4590:7053:1cb:b8fd [ICMP parameter problem]
Scanned 1 address and found 7 systems alive
Afin d’obtenir le match entre les adresses mac déjà obtenues et ces nouvelles adresses IPv6, on peut s’appuyer sûr un sniffer de paquets réseau. Ici, nous avons utilisé Wireshark et avons pu établir la table suivante :
00:0c:29:14:7d:40 fe80::20c:29ff:fe14:7d40
00:0c:29:a0:b9:3f fe80::20c:29ff:fea0:b93f
00:0c:29:ed:be:d7 fe80::c5df:fb69:c231:273d
00:0c:29:d2:88:50 fe80::af08:1fb8:b67a:56ba
00:0c:29:57:80:1f fe80::8123:3e41:549f:bbf6
00:0c:29:d6:ab:a4 fe80::4590:7053:1cb:b8fd
00:0c:29:2c:79:b2 fe80::20c:29ff:fe2c:79b2
Cette commande sollicite les voisins grâce à l’adresse multicast standard ff02::2. En envoyant un paquet ICMPv6 à cette adresse, tous les hosts actifs du réseau local doivent répondre pour communiquer leur adresse mac respective. Ce fonctionnement a pour but de remplacer le protocol ARP IPv4. Inopinément, il n’est pas vraiment utile dans la mesure où ce processus est automatiquement réalisé lorsqu’une machine rejoint le réseau en IPv6 (passivement donc).
Cette méthode ne permet pas cependant d’aller voir au-delà des routeurs. Aucune chance donc d’atteindre la DMZ. Comme précisé précédemment, il n’est pas envisageable de faire une découverte séquentielle sur les adresses IPv6 ff80::/10 car beaucoup trop nombreuses.
Découverte agressive
Nous relançons la découverte des OS et des services précédemment réalisés, car les résultats peuvent différer et même complètement inédits.
sudo nmap -6 --script-updatedb -A --version-all --osscan-guess --script path-mtu -v --max-retries 0 -iL ips6.txt -oX nmap-ping-scan-MTU-6.xml
sudo nmap -6 -v --script-updatedb -sV --version-all --script vuln,vulscan/ -iL ips6.txt --max-retries 0 -oX nmap-ping-scan-VULN-6.xml
Ici, par exemple, grâce à la sollicitation IPv6, on a pu déterminer que fe80::20c:29ff:fe14:7d40 était un Linux 4.19 à 92%, et fe80::af08:1fb8:b67a:56ba un Linux 5.4 à 96%.
Cependant, la stack IPv6 du réseau n’étant pas développée, nous n’avons pu obtenir que de très maigres informations.
Voici la cartographie du réseau LAN jusqu’à la couche L3 que nous avons pu établir avec ces découvertes réseau :
Et la cartographie de la DMZ:
MAC
Afin de découvrir les adresses MAC de manière active, et donc beaucoup plus efficace, nous pouvons forcer des requêtes ARP sur le réseau et voir lesquels donnent des réponses avec leurs MAC.
Cela prend quelque seconde mais avec la commande arp-scan --localnet exécuté en root, nous arrivons assez vite à avoir toutes les adresses MAC de notre réseau.
Pour ce qui est des informations du constructeur, il n’existe pas de solution outre celle présentée dans le scan passif.