Découverte passive
La découverte passive consiste en l’écoute de l’activité du réseau auquel on est relié sans interaction avec celui-ci afin de déterminer la nature des machines qui le compose. Ce type de découverte est à privilégier lorsqu’on cartographie un réseau, car il évite que des interactions inadaptées aient lieu avec des équipements du réseau. Certains équipements industriels pourraient ne pas supporter une découverte active agressive et cessaient de fonctionner, avec toutes les conséquences que cela pourrait impliquer. KALI01 est la machine qui va nous permettre de réaliser cette écoute du réseau. N’étant pas un carrefour de passage des paquets réseau par nature comme pourrait l’être un routeur, un proxy, un load balancer, etc…, l’écoute se limite aux broadcasts et aux rares paquets qui nous seront directement adressés. Hormis pour les anciennes architectures réseaux composées de hubs ou des architectures très spécifiques, le broadcast IP n’est pas intensivement utilisé. On ne s’attend donc pas à recevoir beaucoup de données réseau provenant d’une écoute passive, à l’exception des requêtes du protocole ARP.
Focus sur le protocole ARP (Address Resolution Protocol)
Ce protocole de faire la liaison entre la couche 2 (MAC) et la couche 3 (IP) du modèle OSI. Il permet aux différents hosts d’un même LAN de communiquer via la couche 2 et les adresses MAC sur le protocole Ethernet. Les équipements intermédiaires tels que les switchs et les bridges sont des équipements de couche 2 qui ne sont en conséquence pas en mesure de comprendre les protocoles de couche 3 (IP). Or la plupart des configurations d’hosts réseau s’opèrent via des addresses IP, éventuellement locales (RFC 1918), pour de la configuration : DNS, gateway, … Il est alors primordial que les paquets soient au minimum de couche 2 afin de pouvoir passer au travers des équipements intermédiaires du LAN, cela implique donc la connaissance de chaque couple (MAC,IP) des machines que l’on souhaite adresser depuis le LAN. D’où l’intérêt du protocol ARP qui permet de mettre en relation chaque IP avec l’adresse MAC correspondante.
Toutes les interfaces réseau dotées d’une adresse IP possèdent alors un cache ARP, qui correspond à une table appairant MAC & IP. C’est cette table que nous allons examiner dans un premier temps pour commencer la découverte passive du réseau.
arp a
Cette commande permet de consulter le cache ARP de la machine courante.
┌──(kali㉿kali)-[~]
└─$ arp -a
? (192.168.2.222) at 00:0c:29:d2:88:50 [ether] on eth0
? (192.168.2.1) at 00:0c:29:a0:b9:3f [ether] on eth0
? (192.168.2.2) at 00:0c:29:57:80:1f [ether] on eth0
On obtient alors 3 couples (IP,MAC). L’inconvénient principal de cette commande est qu’elle fixe l’état du cache ARP à un instant donné. Il serait plus pertinent d’avoir une écoute continue de cet état.
sudo netdiscover -pP &> ./passiv/netdiscover.log
rapport
netdiscover permet d’exploiter le protocole ARP pour de la découverte active ou passive. Dans cas, seule la découverte passive sera exploité grâce au flag -p. L’output de la commande sera ensuite redirigé dans un fichier grâce au flag -P (majuscule).
┌──(kali㉿kali)-[~/ARS_DM6]
└─$ cat passiv/netdiscover.log
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.2.10 00:0c:29:d6:ab:a4 1 60 VMware, Inc.
192.168.2.1 00:0c:29:a0:b9:3f 1 60 VMware, Inc.
192.168.2.14 00:0c:29:ed:be:d7 1 60 VMware, Inc.
La colonne “MAC Vendor / Hostname” indique à quel constructeur appartient la MAC de la machine. Cela est possible grâce aux OUIs (Organizationally Unique Identifiers) qui correspondent aux préfixes MACs attribués aux constructeurs enregistrés auprès de l’IEEE. Dans ce cas, on peut voir que le constructeur est systématiquement “VMware, Inc.” du fait de l’émulation de l’ensemble du réseau. En pratique ça pourrait être “Dell Inc.”, “ASUSTek COMPUTER INC.”, “Apple, Inc.”, etc…
Écoute indifférenciée du trafic
Plusieurs outils de KALI01 permettent de réaliser cette écoute.
sudo p0f -i eth0 -p -o ./passiv/p0f.log
rapport
p0f avec l’option -p permet de réaliser une écoute passive du réseau de l’interface eth0 via l’option -i. En l’état, il n’y a aucune raison qu’une machine sollicite KALI01, cependant pour la démonstration, un service tourne sur le 8834 et nous permettra d’entrer en communication (TCP) avec KALI01 depuis une machine du LAN.
┌──(kali㉿kali)-[~/ARS_DM6]
└─$ sudo p0f -i eth0 -p -o ./passiv/p0f.log
--- p0f 3.09b by Michal Zalewski <lcamtuf@coredump.cx> ---
[+] Closed 1 file descriptor.
[+] Loaded 322 signatures from '/etc/p0f/p0f.fp'.
[+] Intercepting traffic on interface 'eth0'.
[+] Default packet filtering configured [+VLAN].
[+] Log file './passiv/p0f.log' opened for writing.
[+] Entered main event loop.
.-[ 192.168.2.10/52831 -> 192.168.2.21/8834 (syn) ]-
|
| client = 192.168.2.10/52831
| os = Windows NT kernel
| dist = 0
| params = generic
| raw_sig = 4:128+0:0:1460:mss*44,8:mss,nop,ws,nop,nop,sok:df,id+:0
|
`----
p0f a bien intercepté les paquets émis par ADM01 pour démarrer la communication avec KALI01 sur le port 8834. La connexion repose sur le protocole TCP/IP, et c’est grâce à ce protocole que l’empreinte de l’OS distant va pouvoir être réalisée. Chaque OS implémente la stack TCP/IP d’une manière qui leur est propre. De ce fait, on peut facilement déterminer l’OS avec lequel KALI01 communique pour peu que l’on ait au préalable une base de données référençant les différentes empreintes possibles pas OS.
Cette base de données se trouve au chemin suivant sur KALI01 :
/etc/p0f/p0f.fp
ICMPv6
En IPv6, il n’existe plus de broadcast, il n’y a donc presque aucune chance d’être adressé de façon indifférenciée. Cependant, de nombreux mécanismes permettent aux machines du réseau de nous solliciter par l’intermédiaire d’adresses multicast afin de compléter leur entrée dans le réseau. Le protocole DHCP en IPv4 a été remplacé par le protocole ICMPv6 et l’adresse standard ff02::1. Celle-ci permet d’adresser tous les routeurs du réseau local à la recherche d’informations de routage comme on pouvait les trouver avec un serveur DHCP. Lorsque nous nous sommes connectés au réseau, un paquet ICMPv6 a été envoyé à l’adresse ff02::1 et les routeurs y ont répondu. On est donc en mesure de les identifier. De la même manière, en remplacement du protocole ARP, le protocole ICMPv6 peut une nouvelle fois être utilisé en multicast avec l’adresse ff02::2 afin de réaliser une découverte de la couche 2 du réseau LAN.
Toutes ces informations peuvent être accédées de la manière suivante :
┌──(kali㉿kali)-[~]
└─$ ip -6 neigh show
fe80::20c:29ff:fe14:7d40 dev eth0 lladdr 00:0c:29:14:7d:40 STALE
fe80::20c:29ff:fe2c:79b2 dev eth0 lladdr 00:0c:29:2c:79:b2 STALE
fe80::20c:29ff:fea0:b93f dev eth0 lladdr 00:0c:29:a0:b9:3f router STALE
fe80::8123:3e41:549f:bbf6 dev eth0 lladdr 00:0c:29:57:80:1f STALE
fe80::c5df:fb69:c231:273d dev eth0 lladdr 00:0c:29:ed:be:d7 STALE
fe80::af08:1fb8:b67a:56ba dev eth0 lladdr 00:0c:29:d2:88:50 STALE
fe80::4590:7053:1cb:b8fd dev eth0 lladdr 00:0c:29:d6:ab:a4 STALE
On remarque ainsi grâce à cette commande l’équivalent de la table ARP en IPv4 avec des informations supplémentaires. Ici, on remarque que l’adresse mac 00:0c:29:a0:b9:3f correspond à un routeur, car sollicité avec l’adresse de destination multicast ff02::1.
Le principal inconvénient de cette commande est qu’elle n’écoute pas en continu le réseau. On peut donc s’appuyer sur d’autres outils pour cela :
sudo atk6-passive_discovery6 eth0
MAC
Afin de pouvoir connaître les adresses MAC présentent sur le réseau, nous utilisons la commande netdiscover -p exécuté en root.
L’interface suivante apparait.
Pour pouvoir récupérer les adresses MAC du réseau de maniere passive, il n’y a pas beaucoup de solutions.
En termes de réseau, nous pouvons seulement écouter les requêtes ARP qui sont broadcastées sur le réseau. Le désavantage est que cette méthode est très longue et nous sommes dépendants du comportement des autres machines.
Nous regardons maintenant comment obtenir des informations associées à l’adresse MAC, comme des informations sur le fabricant.
Il est possible de le faire manuellement avec des sites spécialisés comme macaddress.io (1).
Entrer l’adresse MAC (1) et appuyer sur “Search” (2).
Nous pouvons voir les informations associées.
Nous regardons désormais comment automatiser cette étape dans notre script.
Se rendre sur “https://standards-oui.leee.org/oui/oui.txt" (1).
Chercher l’adresse MAC testé sur le site pour comparer les informations (2).
Nous trouvons le préfixe de l’adresse (3).
Les informations correspondent bien (4).
Le fichier oui.txt est présent sur les machines kali Linux. Nous repérons ce fichier (1).
Nous pouvons voir, encore une fois, que les informations correspondent bien (3).
Enfin, pour mettre ce fichier à jour, il est possible de l’importer en spécifiant un chemin.
Nous le plaçons dans un dossier particulier pour pouvoir l’utiliser dans le script.
