Extrait
de la Sniffing
FAQ de Robert Graham
Translation by eberkut - http://www.chez.com/keep
3.8 Comment puis-je sniffer un réseau commuté ?
En théorie, vous ne pouvez pas sniffer un réseau commuté. Tout ce que le sniffing ferait sera de voir votre propre trafic de toute façon. En pratique, il y a de nombreuses méthodes.
Voyez le projet HUNT à http://www.cri.cz/kra/index.html pour plus d'infos.
| Opération : | Requête | |
| Alice : | 192.0.2.173 | 00-40-05-A4-79-32 |
| Bob : | 192.0.2.1 | ?? ?? ?? ?? ?? ?? |
L'échange entier pourrait ressembler au diagramme ci-dessous. Alice a un paquet IP d'une certaine sorte (disons ping ICMP) à envoyer à Bob. Afin de trouver l'adresse MAC de Bob, Alice lui envoie une requête ARP. Bob répond à Alice, lui disant son adresse MAC. Maintenant Alice envoie son paquet IP à cette adresse MAC Ethernet.
Alice ----> ARP broadcast request ----> Bob Alice <---- ARP unicast response <---- Bob Alice ----> ICMP ping request ----> Bob Alice <---- ICMP ping response <---- Bob Alice <---- ICMP ping request <---- CharlesMaintenant Bob a un paquet IP à envoyer à Alice. En théorie, Bob aurait besoin d'envoyer une requête ARP à Alice afin de trouver son adresse MAC. Mais il ne le fait pas. C'est parce qu'il s'est rappelé son information d'adresse MAC qui a été envoyé dans la requête ARP originale.
En fait, chacun sur l'Ethernet local a vu cette demande puisqu'elle a été diffusé à l'ensemble du réseau. Ainsi si Charles veut à ce moment pinger Alice, il n'a pas besoin de lui envoyer de requête ARP non plus, bien qu'il n'ait pas été impliqué dans l'échange initial.
Des émissions sont envoyées à chacun sur un switch Ethernet. Par conséquent, vous pouvez renverser le switch en envoyant des requêtes ARP en prétendant être quelqu'un d'autre comme adresse source. Vous pouvez annoncer une requête ARP en prétendant être le routeur, dans ce cas chacun essayera de router à travers vous. Ou vous pouvez envoyer une requête ARP juste a l'adresse MAC de la victime, en prétendant être le routeur, auquel cas la victime vous expédiera des paquets. Réciproquement, vous pouvez envoyer une requête ARP à l'adresse MAC du routeur en prétendant être la victime.
Dans toutes ces cas, vous devez être disposés à expédier des paquets dans la vraie direction, autrement vous interrompez la transmission.
Voyez http://www.zweknu.org/src/MiM/ pour des programmes d'exemples.
Un hacker (Mark) peut retourner ceci en envoyant une redirection à Alice en prétendant qu'elle peut lui envoyer des paquets à Bob.
Heureusement, beaucoup de machines ne supportent pas ce dispositif parce qu'il est relativement nouveau. Maintenant que les implications de sécurité sont bien connues, beaucoup de nouveaux systèmes ne le supporteront toujours pas.
Voyez http://www.l0pht.com/advisories/rdp.txt pour plus d'information.
Le problème évident est que la victime elle-même enverra toujours des trames avec son adresse MAC (causant le retournement du switch). Un autre problème est que si la victime ne reçoit pas la trame, alors il y a rupture de transmission, et il n'y aura plus rien à sniffer.
Il y a quelques solutions à ce problème, dépendant de ce que vous voulez faire. Vous pouvez vouloir renverser une connexion authentifiée, dans ce cas vous faites un DoS sur la victime (la rendant offline), réorientez le switch, et poursuivre la connexion comme si rien ne s'est produit. Par exemple, disons qu'Alice a une connexion telnet au serveur BOB. Vous faites un DoS sur la machine d'Alice, la mettant offline. Vous envoyez alors des paquets avec l'adresse MAC d'Alice, faisant vous envoyer tous les paquets destinés à elle par le switch. Afin de prendre sa connexion, vous vous faites envoyer par le serveur un paquet TCP (i.e. employez le service d'entretien pour inciter une connexion). A ce moment, vous commencez simplement à renverser les numéros de séquence et d'acknowledgment pour poursuivre la connexion telnet.
Une autre solution à ce problème est d'échantillonner le trafic. Envoyez les paquets avec la MAC de la victime à des intervalles occasionnels. Vous obtiendrez probablement les paquets à venir destinée à la victime, mais elle fera un timeout et récupérera la connexion. L'utilisateur victime notera des délais réseau occasionnels.
Une solution similaire est que quand vous recevez un paquet entrant, renvoyez le en broadcast. De cette façon la victime reçoit toujours le paquet. Un flux régulier du trafic d'outgong et des émissions du trafic entrant vous permettra de récupérer un bon pourcentage du trafic initial.
Dans beaucoup de cas, un intrus peut faire un telnet sur le switch ou le reconfigurer avec SNMP. Beaucoup de switches sont installés par défaut ou des backdoors passwords.
Le SNMP est en particulier amusant parce que l'intrus peut 'morceler' tous les mots de passe jusqu'à ce que il/elle trouve le correct (cependant la plupart viennent par défaut avec "public" ou "privé"). Dans certains cas, l'admin réseau configure le switch pour permettre seulement le SNMP depuis l'adresse IP de la console de gestion réseau. Cependant, cette même console de gestion réseau enverra probablement d'autres paquets SNMP : le sniffing d'émission ou juste le SNMP entrant dirigé à l'hôte indiqueront probablement qui est la console de gestion SNMP, pour laquelle l'IP Spoofing ne peut être employé pour contrôler le switch. De même les transferts de zone DNS pourraient indiquer des noms suggestifs tels que "hpov.example.com" (hpov = HPOpenView, une console populaire de SNMP).