Sniffer un reseau switche
babas666
"Ettercap est un sniffer évolué permettant entre autre le
sniff sur réseau switché "
Comment cela est il possible????
Cedric Blancher
> Lu dans un thread un peu plus bas :
> "Ettercap est un sniffer évolué permettant entre autre le
> sniff sur réseau switché "
C'est tout simplement par qu'un switch n'est pas fait pour faire de la
securite.
Le principe est l'ARP Poisoning.
Quand un hote A veut communiquer avec un hote B sur ethernet, il
commence par envoyer une requete ARP. Cette requete demande tout
simplement l'adresse MAC correspondant a l'adresse IP de B. B repond que
la MAC associee a l'IP est la sienne, et on peut commencer a s'envoyer
des trames ethernet.
Pour ne pas envoyer une requete ARP a chaque fois qu'on veut emettre une
trame, on tient un cache ou on stocke les resolutions ARP deja faites.
Il se trouve que ce cache se met aussi a jour dynamiquement simplement
en regardant les reponses aux requetes ARP. Et c'est la qu'on agit.
Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et
B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC
associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais
avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur
cache ARP a jour.
Lorsque A va vouloir envoyer un paquet a B, il va consulter sa table ARP
pour envoyer la trame correspondante. Or, l'adresse MAC qui s'y trouve
est la mienne : donc il m'envoit la trame. Et idem pour B.
A present, je route le traffic entre A et B. Je peux donc l'intercepter,
le modifier, prendre la place d'un des deux hotes, etc...
Comme un switch fonctionne au niveau 2, il est _incapable_ de detecter
ce type d'attaque, meme s'il possede une table port/MAC statique. Pour
qu'il le detecte, il faut un switch plus etoffe qui est capable
d'associe une IP a une adresse MAC et donc tenir une table port/MAC/IP.
Cette attaque vise les hotes, mais on peut aussi attaquyer le switch.
Dans le cas d'un switch tout simple, on peut meme sniffer en spoofant
une adresse MAC, ou simplement en creant une MAC storm qui, sur certains
equipements affoles cette attaque, entraine le passage en mode hub du
switch.
Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP
statique.
--
J'aimerai savoir s'il est possible de monter un réseau ethernet SANS
HUB. comme on le fait entre 2 machines (en croisant les fils), on en a
environ une quinzaine... est-ce que quelqu'un sait comment faire ??
-+- in Guide du Neuneu Ethernet - Ether pas net, Hub lie moi-+-
Nicob
Traduction en français d'une partie de la "Sniffing FAQ" :
http://madchat.org/coding/trafic.ana/switched_sniffing-fr.htm
Les docs de dsniff traduites par Groar :
http://www.groar.org/trad/dsniff/dsniff-2.3/french-txt/
Xavier Henner
> statique.
ou alors un programme genre arpwatch qui va enregistrer tous les changements de
table ARP.
Des que qq'un s'amuse ca va envoyer un mail d'alerte.
--
euclide
Cedric Blancher
Sauf que ca n'empeche rien. Ca te signale juste l'operation.
Si je fais l'attaque a 4 heures du mat', je doute qu'il y ait grand
monde pour recevoir le mail. Sans parler que je suis tout a fait en
mesure d'operer le meme genre d'action sur le serveur de mail principal
:)
--
L'usenet est un NG comme les autres , non ? C'est quoi ces règles à dix
sous , là ? C'est ici qu'on se prend la tête ?
-+- D23 in GNU - Le neuneu a dissous, et dissous c'est pas cher -+-
Xavier Henner
> Dans sa prose, Xavier Henner (euc...@nerim.net.nospam) nous ecrivait :
> >> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP
> >> statique.
> > ou alors un programme genre arpwatch qui va enregistrer tous les changements
> > de table ARP.
> > Des que qq'un s'amuse ca va envoyer un mail d'alerte.
>
> Sauf que ca n'empeche rien. Ca te signale juste l'operation.
> Si je fais l'attaque a 4 heures du mat', je doute qu'il y ait grand
> monde pour recevoir le mail. Sans parler que je suis tout a fait en
> mesure d'operer le meme genre d'action sur le serveur de mail principal
> :)
pas faux (enfin pour ce genre de probleme j'ai tendence a rediriger les mails
vers un bipper ou un tel portable)
mais le snif sur un LAN c'est généralement une attaque interne.
Donc prévenir le sysadmin et collecter les preuves peut servir rapidement a
vir^H^H^Hrégler le problème.
Et je vois plutot ca comme un moyen de prévention : on fait la publicité du
système bien fort par des courriers internes, ou en envoyant un mail a l'alias
général pour demander qui a changé son adresse IP.
Ca refroidit généralement le warlord.
Dans le cas de l'attaque qui vient de l'extérieur par une machine compromise,
on est prévenu plutot rapidement et on peut isoler la machine.
--
euclide
zejames
http://www.greyhats.org/outils/ettercap/README.fr
http://www.greyhats.org/outils/ettercap/README.PLUGINS.fr
zejames
--
Ce message a été posté via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr
Sebastien Reister
Hash: SHA1
>
> Comme un switch fonctionne au niveau 2, il est _incapable_ de
> detecter ce type d'attaque, meme s'il possede une table port/MAC
> statique. Pour qu'il le detecte, il faut un switch plus etoffe qui
> est capable d'associe une IP a une adresse MAC et donc tenir une
> table port/MAC/IP. Cette attaque vise les hotes, mais on peut aussi
> attaquyer le switch. Dans le cas d'un switch tout simple, on peut
> meme sniffer en spoofant une adresse MAC, ou simplement en creant
> une MAC storm qui, sur certains equipements affoles cette attaque,
> entraine le passage en mode hub du switch.
>
> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP
> statique.
>
Désolé, mais sur un switch tu peut associer un port physique a une
adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
Simple, rapide, efficace!!!
Donc ce faire passer pour un autre sur un switch n'est pas aussi
facile que ça quand le switch est bien configurer (on retombe
toujours sur la même chose finalement).
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
Comment: Netscape PGP Plugin -- http://bear-software.freeservers.com/
iQA/AwUBPHJyk7+JLqWYEox5EQJPawCeO0SQfJdq8Q7Mep02TxzHSsgyhHcAoOu9
Q1jylbILpyzSLL6c1KJ+HMz/
=Duwf
-----END PGP SIGNATURE-----
Vincent Bernat
11:41, Cedric Blancher <blan...@cartel-securite.fr> disait:
> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et
> B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC
> associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais
> avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur
> cache ARP a jour.
Mais chacun ne va pas protester quand il va voir ta prise de pouvoir
(en voyant passer ta trame ARP forgée prétendant que tu prends sa
place) ?
--
THE BOYS ROOM IS NOT A WATER PARK
THE BOYS ROOM IS NOT A WATER PARK
THE BOYS ROOM IS NOT A WATER PARK
-+- Bart Simpson on chalkboard in episode 3F03
Da Jackal
> adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
>
> Simple, rapide, efficace!!!
>
> Donc ce faire passer pour un autre sur un switch n'est pas aussi
> facile que ça quand le switch est bien configurer (on retombe
> toujours sur la même chose finalement).
En pratique ça devient rapidement ingérable si tu veux laisser un peu de
liberté à des utilisateurs bricoleurs :-) donc ça dépend aussi du profil des
utilisateurs.
Y'a aussi le problème de la saturation des tables de correspondance MAC
adresses / Port qui transforme facilement en quelques secondes un switch en
HUB pour les nouvelles machines non référencées dans la table du switch (en
plus du problème de l'ARP Spoofing)...
(c'est comme ça que réagissent les switches CISCO par exemple, certains
switches plantent --> voir macof)
Da Jackal
VANHULLEBUS Yvan
> Désolé, mais sur un switch tu peut associer un port physique a une
> adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
>
> Simple, rapide, efficace!!!
>
> Donc ce faire passer pour un autre sur un switch n'est pas aussi
> facile que ça quand le switch est bien configurer (on retombe
> toujours sur la même chose finalement).
Non: ce que tu dis n'est valable que pour les switches *managables*.
Le switch "de base" ne permet pas du tout ce genre de configuration
(d'ailleurs, le switch de base ne permet aucune configuration...).
A +
VANHU.
Cedric Blancher
>> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP
>> statique.
> Désolé, mais sur un switch tu peut associer un port physique a une
> adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
Sauf que si tu lisais ce que je te racontes, tu aurais compris que quand
on fait de l'ARP spoofing, on ne change pas d'adresse MAC. Ce qu'on
change, c'est l'association MAC/IP au niveau du cache de la cible. Du
point de vue du switch, rien n'a change, on ne l'a d'ailleurs meme pas
attaque.
> Simple, rapide, efficace!!!
Pas dans ce cas la, je te fais la demo quand tu veux.
> Donc ce faire passer pour un autre sur un switch n'est pas aussi
> facile que ça quand le switch est bien configurer (on retombe
> toujours sur la même chose finalement).
Personnellement, pour un switch ne gerant pas les associations
port/MAC/IP, je trouve ca trivial*, mais bon ;)
* test et approuve sur un 2924XL avec couples port/MAC en dur.
--
Halaud, enhoiré ! Le GCU passe encore mais le GNU, jamais.
-+- BL in Guide du Neuneu Usenet : A l'infu de fon flein gré.-+-
Cedric Blancher
> OoO En cette fin de matinée radieuse du mardi 19 février 2002, vers
> 11:41, Cedric Blancher <blan...@cartel-securite.fr> disait:
>> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et
>> B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC
>> associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais
>> avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur
>> cache ARP a jour.
> Mais chacun ne va pas protester quand il va voir ta prise de pouvoir
> (en voyant passer ta trame ARP forgée prétendant que tu prends sa
> place) ?
Mais non, parce que justement tu es sur un environnement switche, et
c'est ca qui est beau : c'est ce qui etait sense t'empecher de sniffer
qui empeche la veritable station de detecter le poisoning !
Alors que la requete ARP est envoye en broadcast ethernet, la reponse a
cette requete est envoyee en unicast, puisqu'on sait a qui on repond.
Donc, tes reponses ARP forgees sont envoyees en unicast a la cible (A
par exemple). Donc, tout est switche, la machine que tu usurpes (B dans
ce cas) ne recoit rien.
On dit "merci qui ?"... Merci le switch ! :))))
Daniel Polombo
>
>> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et
>> B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC
>> associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais
>> avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur
>> cache ARP a jour.
>
> Mais chacun ne va pas protester quand il va voir ta prise de pouvoir
> (en voyant passer ta trame ARP forgée prétendant que tu prends sa
> place) ?
Ben non, puisque le réseau est switché, il n'y a que ta victime qui
reçoit tes paquets :-)
De plus, je ne crois pas qu'une machine soit capable de remarquer qu'une
autre machine essaye de s'approprier son adresse MAC. Faudrait éplucher
un peu plus ARP.
--
Quelqu'un connait il la vitesse en mètres par seconde du
chameau d'Egypte ?
-+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
Xavier Henner
> Vincent Bernat said :
> >
> >> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et
> >> B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC
> >> associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais
> >> avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur
> >> cache ARP a jour.
> >
> > Mais chacun ne va pas protester quand il va voir ta prise de pouvoir
> > (en voyant passer ta trame ARP forgée prétendant que tu prends sa
> > place) ?
>
> Ben non, puisque le réseau est switché, il n'y a que ta victime qui
> reçoit tes paquets :-)
> De plus, je ne crois pas qu'une machine soit capable de remarquer qu'une
> autre machine essaye de s'approprier son adresse MAC. Faudrait éplucher
> un peu plus ARP.
bah si on sniffe les échanges ARP on peut voir l'attaque se dérouler
d'ou la présence conseillée d'un arpwatch dans un réseau dont on n'est pas sur.
Ca permet de voir très vite qui joue aux rigolos et de sévir.
--
euclide
Daniel Polombo
> bah si on sniffe les échanges ARP on peut voir l'attaque se dérouler
> d'ou la présence conseillée d'un arpwatch dans un réseau dont on n'est pas sur.
> Ca permet de voir très vite qui joue aux rigolos et de sévir.
Oui. Mais dans ce cas il te faut un port du switch qui monitore tout le
trafic (avec toutes les implications que ça peut avoir sur le
dimensionnement dudit port :-)
--
Créer une hiérarchie supplementaire pour remedier à un problème (?) de
dispersion est d'une logique digne des Shadocks.
* BT in: Guide du Cabaliste Usenet - La Cabale vote oui (les Shadocks aussi) *
Xavier Henner
> Xavier Henner said :
>
> > bah si on sniffe les échanges ARP on peut voir l'attaque se dérouler
> > d'ou la présence conseillée d'un arpwatch dans un réseau dont on n'est pas sur.
> > Ca permet de voir très vite qui joue aux rigolos et de sévir.
>
> Oui. Mais dans ce cas il te faut un port du switch qui monitore tout le
> trafic (avec toutes les implications que ça peut avoir sur le
> dimensionnement dudit port :-)
>
reste que la soltion completement secure reste de figer les tables arp
des machines importantes.
avec une commande globale pour réinitialiser quand on ajoute une
machine
--
euclide
Daniel Polombo
> ou mettre un arpwatch sur toutes les machines.
>
> reste que la soltion completement secure reste de figer les tables arp
> des machines importantes.
Ces deux solutions présentent l'immense inconvénient de réclamer de la
maintenance sur chaque machine. De plus, je ne suis pas convaincu que ça
soit possible sur toutes les plate-formes (pas de noms, pas de noms :).
Je préfère personnellement les switchs capables de faire du verrouillage
à la fois sur la MAC et l'IP : si sur un port donné tu n'as pas et la
bonne MAC et la bonne IP, zou, au trou. C'est déjà plus délicat à
bypasser, sans être aussi lourd à mettre en oeuvre.
--
Moi si je devais voter pour ce forum, je serais d'accord pour
virer tous les abrutis!!!
-+-DF in Guide du Neuneu Usenet - Ce neuneu s'autodétruira dans 1 mn -+-
Nicob
<pol...@cartel-securite.fr> wrote:
>Ces deux solutions présentent l'immense inconvénient de réclamer de la
>maintenance sur chaque machine. De plus, je ne suis pas convaincu que ça
>soit possible sur toutes les plate-formes (pas de noms, pas de noms :).
Ok, pas de noms .....
Y avait pas un problème sous NT qui faisait que même les entrées ARP
qualifiées de statiques (-s) pouvaient être overwritées via le rézo ?
Nicob
Bon, un coup de Google et je me réponds à moi-même :
http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0568.html
Sebastien Reister
Hash: SHA1
> Sauf que si tu lisais ce que je te racontes, tu aurais compris que
> quand on fait de l'ARP spoofing, on ne change pas d'adresse MAC. Ce
> qu'on change, c'est l'association MAC/IP au niveau du cache de la
> cible. Du point de vue du switch, rien n'a change, on ne l'a
> d'ailleurs meme pas attaque.
Soit j'ai lu en diagonale, j'aurais du me mefier!!!
Mea Culpa
>
> > Simple, rapide, efficace!!!
>
> Pas dans ce cas la, je te fais la demo quand tu veux.
>
non, non c bon je te crois.
> > Donc ce faire passer pour un autre sur un switch n'est pas aussi
> > facile que ça quand le switch est bien configurer (on retombe
> > toujours sur la même chose finalement).
>
> Personnellement, pour un switch ne gerant pas les associations
> port/MAC/IP, je trouve ca trivial*, mais bon ;)
Malgré tous mon assertion "La sécurité passe par une bonne
configuration de tous les éléments du reseau." reste vrai.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
Comment: Netscape PGP Plugin -- http://bear-software.freeservers.com/
iQA/AwUBPHTI3b+JLqWYEox5EQJW/QCgv3nXptsyMYErV5IpQe0PMYHN9mkAn2jr
64AR5s2xo0DYO4XTXgg1BcAW
=vL8S
-----END PGP SIGNATURE-----
Bad Max
>
> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP
> statique.
>
>
Ou de dire au switch de limiter le nombre d'adresses MAC par port. Et
de n'en mettre qu'une seule. Mieux, on peut même entrer l'@ MAC de ta
machine et émettre une alarme en cas de changement et bloquer le port
en même temps (un bête Cisco Catalyst 1924 permet la manip).
Bad Max
> Dans sa prose, Sebastien Reister (s...@ffgolf.org) nous ecrivait :
>
>>>Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP
>>>statique.
>>>
>>Désolé, mais sur un switch tu peut associer un port physique a une
>>adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
>>
>
> Sauf que si tu lisais ce que je te racontes, tu aurais compris que quand
> on fait de l'ARP spoofing, on ne change pas d'adresse MAC. Ce qu'on
> change, c'est l'association MAC/IP au niveau du cache de la cible. Du
> point de vue du switch, rien n'a change, on ne l'a d'ailleurs meme pas
> attaque.
>
Et comment gère-tu le fait que la 1ère requète ARP sera vue en même
temps par ta machine et la machine désignée ? Elle va en effet répondre
probablement en premier. Est-ce que tous les OS réagissent de la même
façon ? De plus, tiennent-ils compte des requètes reçues APRES en avoir
reçue une autre ?
Cedric Blancher
> Ou de dire au switch de limiter le nombre d'adresses MAC par port. Et
> de n'en mettre qu'une seule. Mieux, on peut même entrer l'@ MAC de ta
> machine et émettre une alarme en cas de changement et bloquer le port
> en même temps (un bête Cisco Catalyst 1924 permet la manip).
C'est moi ou j'ai l'impression que personne ne me lit ?
Quand tu fais de l'ARP spoofing, tu ne changes pas ton adresse MAC. Donc
tu peux n'avoir qu'une adresse MAC par port, ca marchera aussi !...
> Et comment gère-tu le fait que la 1ère requète ARP sera vue en même
> temps par ta machine et la machine désignée ? Elle va en effet répondre
> probablement en premier. Est-ce que tous les OS réagissent de la même
> façon ? De plus, tiennent-ils compte des requètes reçues APRES en avoir
> reçue une autre ?
Decidemment, va falloir apprendre a lire.
On ne repond pas a des requetes, on envoie des _reponses_ sans qu'il y
ait eu de requete pour que la cible, voyant ces trames, modifie
d'elle-meme son cache ARP. Il n'y a aucune requete de la part de
personne. De toute maniere, une fois l'operation effectuee, l'hote cible
n'emet plus de requete ARP pour l'IP qu'on a ARP spoofee, puisqu'elle
est en cache, et B ne verra plus de reponse ARP pour l'IP spoofee,
puisque ces reponses sont en unicast.
Donc on revise un peu ARP, et puis des papiers sur la question :
<http://www.sans.org/newlook/resources/IDFAQ/switched_network.htm>
Pour proteger un OS contre ca, soit on lui colle une table ARP statique,
en renseignant par exemple le fichier /etc/ethers, soit on force une
expiration rapide des entrees, comme sous Solaris :
ndd -set /dev/ip ip_ire_flush_interval 60000
ndd -set /dev/arp arp_cleanup_interval 60
Pour coller un expiration a 1 min au lieu de 20.
--
Le dino, c'est celui qui comprend un message qu'il ne lit pas.
Le neuneu, c'est celui qui ne comprend pas un message qu'il lit.
-+-GF in Guide du Neuneu Usenet - Et c'est ainsi qu'Allah est grand-+-
VANHULLEBUS Yvan
> C'est moi ou j'ai l'impression que personne ne me lit ?
Si, ceux qui connaissent deja :-)
> Pour proteger un OS contre ca, soit on lui colle une table ARP statique,
> en renseignant par exemple le fichier /etc/ethers, soit on force une
> expiration rapide des entrees, comme sous Solaris :
>
> ndd -set /dev/ip ip_ire_flush_interval 60000
> ndd -set /dev/arp arp_cleanup_interval 60
>
> Pour coller un expiration a 1 min au lieu de 20.
Meme pas: il suffit d'emmettre cette reponse ARP a intervalle regulier
pour pouvoir continuer a sniffer tranquille....
Alors bon, tu peux toujours ramener l'expiration a quelques secondes,
mais ca risque d'avoir de facheuses consequences sur les performances
du reseau, et ca ne *garantit* toujours pas qu'on ne peut pas sniffer
du tout (mais on a beaucoup moins de chances d'intercepter l'ensemble
du traffic).
Seule la table ARP statique est donc efficace contre ce genre de
sniff...
A +
VANHU.
Frederic Raynal
Cedric Blancher <blan...@cartel-securite.fr> wrote:
>
> On ne repond pas a des requetes, on envoie des _reponses_ sans qu'il y
> ait eu de requete pour que la cible, voyant ces trames, modifie
> d'elle-meme son cache ARP. Il n'y a aucune requete de la part de
> personne. De toute maniere, une fois l'operation effectuee, l'hote cible
> n'emet plus de requete ARP pour l'IP qu'on a ARP spoofee, puisqu'elle
> est en cache, et B ne verra plus de reponse ARP pour l'IP spoofee,
> puisque ces reponses sont en unicast.
Je ne suis pas tout à fait d'accord ... en tout cas pour un noyau Linux
2.4.0 : je l'explique et je le prouve ;-)
Attention :
Tout ce qui suit est testé et approuvé (par mes soins) avec un noyau
linux 2.4.0 : je ne sais pas ce qu'il en est pour les autres versions du
noyau et pour les autres OS.
Le problème :
La mise à jour du cache ne se fait pas tant qu'il n'y a pas eu de
"question" ARP. En revanche, une fois qu'une réponse a été émise, le
cache accepte plusieurs réponses, et c'est la dernière reçue qui
l'emporte (je ne sais pas quel est le "temps d'acceptation" de la
réponse).
Exemple :
Les protagonistes sont :
- charly : machine depuis laquelle je lance l'attaque
(MAC=00:C0:FD:02:06:FF)
- bosley : machine dont je veux usurper l'adresse MAC
(MAC=00:C0:4F:9C:0E:3E IP=192.168.10.66)
- kelly : machine cible sur laquelle je veux usurper l'adresse MAC de
bosley (IP=192.168.24.103 et dont on se fout de l'adresse MAC)
** Depuis charly
[rot@charly]# arpspoof -t 192.168.24.103 192.168.10.66
0:c0:4f:9c:e:3e 0:d0:b7:c9:74:13 0806 42: arp reply 192.168.10.66 is-at
0:c0:4f:9c:e:3e
0:c0:4f:9c:e:3e 0:d0:b7:c9:74:13 0806 42: arp reply 192.168.10.66 is-at
0:c0:4f:9c:e:3e
0:c0:4f:9c:e:3e 0:d0:b7:c9:74:13 0806 42: arp reply 192.168.10.66 is-at
0:c0:4f:9c:e:3e
Je lance le spoof et tout se passe maintenant sur kelly :
** Sur la cible (kelly - 192.168.24.103) :
[root@kelly /root]# arp
Address HWtype HWaddress Flags Mask Iface
charly ether 00:C0:FD:02:06:FF C eth0
kelly n'a fait encore aucune requête ARP => le cache de kelly ne contient
pas bosley. On lance une commande qui nécessite une "question" ARP :
[root@kelly /root]# traceroute bosley
traceroute to bosley (192.168.10.66), 30 hops max, 38 byte packets
1 bosley (192.168.10.66) 2.349 ms 0.429 ms 0.414 ms
Puis on regarde le cache ARP :
[root@kelly /root]# arp
Address HWtype HWaddress Flags Mask Iface
bosley ether 00:C0:4F:9C:0E:3E C eth0
charly ether 00:C0:FD:02:06:FF C eth0
Tiens, il a la bonne adresse :( Mais après qq secondes, on regarde à
nouveau :
[root@kelly /root]# arp
Address HWtype HWaddress Flags Mask Iface
bosley ether 00:C0:FD:02:06:FF C eth0
charly ether 00:C0:FD:02:06:FF C eth0
Bingo !
Je ne sais pas si ce comportement est normal ou pas, mais je constate
juste ce qui se passe.
Je suppose que le décalage entre les 2 caches résulte d'une course et
que dans un premier temps, c'est bosley qui gagne, mais qu'ensuite, la
cache est mis à jour par les réponses de charly (si qq'un peut
confirmer, infirmer ou préciser ;)
Je serai très curieux de savoir comment ça se passe avec d'autres OS et
versions du noyau. Donc si qq'un a le matériel, le temps et le courage
de faire les tests, merci de me tenir informé ;)
--
Frédéric RAYNAL
http://minimum.inria.fr/~raynal
<pub>
Rédacteur en chef de M.I.S.C. - Multi-Systems & Internet Security
Cookbook
</pub>
Cedric Blancher
> Cedric Blancher <blan...@cartel-securite.fr> wrote:
>> On ne repond pas a des requetes, on envoie des _reponses_ sans qu'il y
>> ait eu de requete pour que la cible, voyant ces trames, modifie
>> d'elle-meme son cache ARP. Il n'y a aucune requete de la part de
> La mise à jour du cache ne se fait pas tant qu'il n'y a pas eu de
> "question" ARP. En revanche, une fois qu'une réponse a été émise, le
> cache accepte plusieurs réponses, et c'est la dernière reçue qui
> l'emporte (je ne sais pas quel est le "temps d'acceptation" de la
> réponse).
Ceci est tout a fait exact, je me suis mal exprime, du fait qu'ayant
passe tout cela sous silence. Je voulais mettre le doigt sur le fait que
nos "reponses" ne correspondent pas a une requete effectuee. Ce qui fait
que quand on envoie notre reponse, personne ne voit de requete
correspondante, donc personne ne repond en meme temps ou avant nous.
Ceci pour bien differencier l'ARP spoofing, base sur de la corruption de
cache, d'attaque en DNS spoof basique par exemple, ou on va tenter de
repondre a des requete DNS _avant_ le serveur valide.
Par contre, ta demonstration est excellente, je n'avais en effet pas
teste le poisoning sur une table vide (enfin, ne contenant pas d'entree
adequat). Merci donc ;)
> Je suppose que le décalage entre les 2 caches résulte d'une course et
> que dans un premier temps, c'est bosley qui gagne, mais qu'ensuite, la
> cache est mis à jour par les réponses de charly (si qq'un peut
> confirmer, infirmer ou préciser ;)
/usr/src/linux/net/ipv4/arp.c
Une entree ARP n'est cree que s'il y a eu requete, ou si quelqu'un nous
demande notre adresse ARP, partant du principe que si quelqu'un nous
demande notre adresse, c'est pour nous causer, donc on le met dans le
cache.
Ceci peut etre vachement interessant en fait, puisque ca nous
permettrait de creer l'entree sans pour autant que la machine decide de
causer avec l'IP que nous voulons voler :
C ----- from MACb, ARP whohas IPa ----> A
B <---- from MACa, ARP MACa has IPa --- A
C ----- from MACc, ARP MACc has IPb --> A
Probleme : notre premiere requete spoofe l'adresse MAC de B, donc si le
switch lock les adresses MAC, ca passe pas et on se fait jeter.
D'ailleurs, je pense que des outils du genre arpredirect ou hunt peuvent
utiliser cette technique. En effte, on se fait jeter par le switch de
temps a autre avec arpredirect.
> Je serai très curieux de savoir comment ça se passe avec d'autres OS et
> versions du noyau. Donc si qq'un a le matériel, le temps et le courage
> de faire les tests, merci de me tenir informé ;)
Ben je vais tester avec ce que j'ai sous le coude ;)
--
/* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
* way.
*/
2.4.3 linux/net/core/netfilter.c
Cedric Blancher
> Probleme : notre premiere requete spoofe l'adresse MAC de B, donc si le
> switch lock les adresses MAC, ca passe pas et on se fait jeter.
Got it ! :)))))
Je lance ma requete ARP avec en source MACc,IPb et en destination
MACa,IPa. D'une part, ca ne part pas en broadcast, donc l'hote spoofe ne
voit rien, et d'autre part, comme c'est une requete farpaitement valide,
il y repond et me colle l'entree que je veux dans le cache.
Teste et approuve sur 2.4.16.
Donc une fois cette action realisee, l'entree est cree, directement avec
la bonne IP, je n'ai plus qu'a l'entretenir avec arpspoof.
Ceci dit, des requetes ARP qui partent pas en broadcast, ca devrait
faire couiner un eventuel IDS.
--
Il est horrible de penser que le cerveau de certains pose un problème.
Il me paraît plus charitable de supposer qu'il n'en ont pas.
-+- JL in: Guide du Cabaliste Usenet - Le neurone de la Cabale -+-
Frederic Raynal
Cedric Blancher <blan...@cartel-securite.fr> wrote:
> Dans sa prose, Frederic Raynal (ray...@minimum.inria.fr) nous ecrivait :
> > Cedric Blancher <blan...@cartel-securite.fr> wrote:
>
> Par contre, ta demonstration est excellente, je n'avais en effet pas
> teste le poisoning sur une table vide (enfin, ne contenant pas d'entree
> adequat). Merci donc ;)
De rien (/me rougit)
> > Je suppose que le décalage entre les 2 caches résulte d'une course et
> > que dans un premier temps, c'est bosley qui gagne, mais qu'ensuite, la
> > cache est mis à jour par les réponses de charly (si qq'un peut
> > confirmer, infirmer ou préciser ;)
>
> /usr/src/linux/net/ipv4/arp.c
Oui, bon, ben ça va ... c'est juste que j'ai eu la flemme de regarder ;)
Pour me rattraper, j'ai jeté un rapide coup d'oeil à 2 versions de ce
fichier (kernel 2.2.20 vs. 2.2.17) et je n'ai pas noté de différences
fondamentales dans le traitement des "réponses" ARP (en dehors du
support de plus de matériel).
> Une entree ARP n'est cree que s'il y a eu requete, ou si quelqu'un nous
> demande notre adresse ARP, partant du principe que si quelqu'un nous
> demande notre adresse, c'est pour nous causer, donc on le met dans le
> cache.
Tiens, je viens de voir la même chose dans le fichier cité précédemment ;-)
> Probleme : notre premiere requete spoofe l'adresse MAC de B, donc si le
> switch lock les adresses MAC, ca passe pas et on se fait jeter.
yep :(
Il faudrait faire ça de manière indirecte, mais je ne vois vraiment pas
comment (i.e. forcer la machine dont on veut usurper l'adresse MAC à
envoyer une "question" ARP à la cible ... mais une "question" avec
IP(usurpée) && MAC(attaquant), ce qui ne me semble pas gagné)
Je vais peut-être aller prendre un café moi, au lieu de délirer.
> D'ailleurs, je pense que des outils du genre arpredirect ou hunt peuvent
> utiliser cette technique. En effte, on se fait jeter par le switch de
> temps a autre avec arpredirect.
arpspoof rulez ;-)
> Ben je vais tester avec ce que j'ai sous le coude ;)
Génial, merci :
--
Frédéric RAYNAL
http://minimum;inria.fr/~raynal
<pub>
Rédacteur en chef de M.I.S.C.
Vincent Bernat
Cedric Blancher <blan...@cartel-securite.fr> disait:
>> Probleme : notre premiere requete spoofe l'adresse MAC de B, donc si le
>> switch lock les adresses MAC, ca passe pas et on se fait jeter.
> Got it ! :)))))
> Je lance ma requete ARP avec en source MACc,IPb et en destination
> MACa,IPa. D'une part, ca ne part pas en broadcast, donc l'hote spoofe ne
> voit rien, et d'autre part, comme c'est une requete farpaitement
> valide, il y repond et me colle l'entree que je veux dans le cache.
Sur un réseau non switché, est-ce que la machine "spoofée" verra
"naturellement" (sans sniffer) cette mauvaise requête qui porte son
nom ?
Cedric Blancher
> Cedric Blancher <blan...@cartel-securite.fr> disait:
>> MACa,IPa. D'une part, ca ne part pas en broadcast, donc l'hote spoofe ne
>> voit rien, et d'autre part, comme c'est une requete farpaitement
>> valide, il y repond et me colle l'entree que je veux dans le cache.
> Sur un réseau non switché, est-ce que la machine "spoofée" verra
> "naturellement" (sans sniffer) cette mauvaise requête qui porte son
> nom ?
Bien sur, mais sur un reseau non switche, je n'ai pas besoin de ca pour
voir le trafic qui m'interesse ;)
--
Oû trouver un mail bombing? Je me suis fait bomber a plus de 3000 mail
et ça continue. J'en ai marre et je veux me défendre. Qqun peut -il me
dire oû je peux trouver ce genre de programme?
-+- G in : Guide du Neuneu Usenetien - La course aux armements -+-
Vincent Bernat
16:04, Cedric Blancher <blan...@cartel-securite.fr> disait:
>> Sur un réseau non switché, est-ce que la machine "spoofée" verra
>> "naturellement" (sans sniffer) cette mauvaise requête qui porte son
>> nom ?
> Bien sur
Cela ne me semble pas évident : la requête est en unicast, donc la
machine "spoofée" ne devrait pas l'analyser, sauf si elle est en
promisc ?
> mais sur un reseau non switche, je n'ai pas besoin de ca pour
> voir le trafic qui m'interesse ;)
L'intérêt de la méthode, c'est que, comme tu as dis, à tout moment, tu
peux prendre la place de l'une des machines.
--
> C'est malheureux de constater k'apres kelkes millers d'années d'evolution,
> les hommes sont encore au stade *primitive* : peur de ce k'on ne connait
> pas, juger ses sembles a tout prix, coller une etiquette et j'en passe.
-+- Gl in : Guide du Neuneu d'Usenet - fufe, c'est du Darwin -+-
Bertrand
Juste pour apporter ma modeste contrubition dans ce debat fort interessant
:o) et puisque on parle de Windows, une attaque de DoS conssistait a envoyer
a un PC plein de paquets ARP avec l'adresse MAC de la victime et une IP
aleatoire : le PC affichait des milliers de messages "conflit d'adresse IP"
et plantait...
(je trouve ces attaques debiles, mais ce qui l'est encore plus c'est la
reaction dudit OS......)
@+
Bertrand
"Nicob" <use...@nicob.net> a écrit dans le message de news:
8lh97u82c05drp079...@4ax.com...
Cedric Blancher
>>> "naturellement" (sans sniffer) cette mauvaise requête qui porte son
>>> nom ?
>> Bien sur
> Cela ne me semble pas évident : la requête est en unicast, donc la
> machine "spoofée" ne devrait pas l'analyser, sauf si elle est en
> promisc ?
Regarde ce que ca donne d'envoyer des reponses ARP spoofees a un Windoww
sur sa propre IP...
> L'intérêt de la méthode, c'est que, comme tu as dis, à tout moment, tu
> peux prendre la place de l'une des machines.
Oui, mais la seule condition vraiment utile pour cela est de voir le
trafic, le reste, on le gere de maniere fort honorable de toute maniere.
Nicob
wrote:
>On 22 Feb 2002 10:54:17 GMT,
>Cedric Blancher <blan...@cartel-securite.fr> wrote:
>
>> Une entree ARP n'est cree que s'il y a eu requete, ou si quelqu'un nous
>> demande notre adresse ARP, partant du principe que si quelqu'un nous
>> demande notre adresse, c'est pour nous causer, donc on le met dans le
>> cache.
>
>Tiens, je viens de voir la même chose dans le fichier cité précédemment ;-)
Pour info, Ettercap >= 0.6.0 applique cette fonctionnalité.
D'après le README et à propos du kernel Linux 2.4.x :
"Donc, si le noyau reçoit une REQUETE il enregistera l'information...
Ca signifie quoi ? si ettercap envoie des REQUETES corrompues au lieu
de REPONSES corrompues, le noyau mettra à jour le cache ? La réponse
est OUI !!
ettercap 0.6.0 et suivants utilise cette NOUVELLE METHODE de
CORRUPTION de cache. Il enverra alternativement des REQUETES et des
REPONSES car d'autres OS ne disposent pas de cette "fonctionnalité".
(Traduction par Julien Bordet)
Nicob