Attaque avec adresse IP forgée

bruno.treguier_at_shom.fr@nullepart.invalid devait dire quelque chose
comme ceci :

L'IP spoofing est tout sauf une légende urbaine, c'est d'ailleurs cette
technique (entre autres) qui a été utilisée par Kevin Mitnick lors de sa
célèbre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation IP +
SYN flooding + prédiction des numéros de séquence TCP).

Sauf que ce que tu décris là n'est pas une attaque à proprement parler
mais un scan de port. S'il y a un service TCP en écoute sur le port, il
essayera de répondre à la poigné de main. La machine dont l'adresse IP
a été usurpée n'ayant aucune trace d'une tentative de connexion en cour
répondra d'un RST ce qui incrémentera le numéro de séquence TCP. Si la
pile IP n'a pas une forte randomisation du numéro de séquence TCP il
suffit donc (façon de parler puisqu'il faut aussi prédire le numéro de
séquence) d'interroger le port de l'hôte usurpé, avant et après le
scan. Si le numéro de séquence a été incrémenté deux fois, c'est que le
RST a effectivement été envoyé et donc que le port est ouvert.
Par contre j'ai d'énormes doutes concernant la paternité de Mitnick,
vue que ce scan n'a été intégré à nmap qu'au environ de 2002 si ma
mémoire est bonne.

Dans le cadre d'une véritable attaque, l'IP spoofing nécessite d'avoir
le controle sur, au choix, le routeur situé avant la cible ou celui
situé avant la machine dont l'adresse IP est usurpée. Autrement les
paquets arriveront fort logiquement sur la machine usurpée et
l'usurpation ne servirait à rien. C'est cela qui rend l'IP spoofing
anecdotique, d'autant plus de nos jours où le premier pirate venu peut
disposer d'un botnet de quelques centaines de machines ou plus.

Eric Razny n'était pas loin de dire :

Pourquoi se compliquer la vie ? Prenons les faits, seul un pirate
voulant absolument rentrer sur la machine fera un scan de port
systématique avec analyse du service qui répond, or une telle personne
finirait de toute façon par comprendre ton mécanisme d'ouverture de
fenêtre.

Si tu paramètre correctement ton port-knocking j'en doute!

Bof. A l'époque des botnets les données ne sont plus les mêmes. Si
chaque (séquence de) port est testé par une machine tirée au hasard et
que le port lui-même, ou la séquence de port, est aussi tirée au
hasard. Si tu laisses un délais de 2 minutes entre chaque test, que tu
places un prérequis disant qu'une même machine ne peut pas intervenir
deux fois de suite et que deux (séquences de) ports qui se suivent ne
peuvent pas être faites l'une après l'autre, le tout couplé avec un
tableau de flags pour être sûr de faire tous les tests et de ne pas les
faire deux fois, non seulement ce n'est qu'une question de temps mais
en plus bon courage à l'IDS pour arriver à détecter le scan.
La seule chose que montreront les logs, c'est qu'un paquet de machines
font toc toc au hasard, ce qu'il faudra débrouiller du bruit de fond
fait par tous les kiddies qui trainent sur le réseau. Le seul handicap
c'est le temps nécessaire pour le scan, mais là encore les botnets ont
changé la donne, tu lances ton script et ensuite tu fais ta vie en
attendant d'avoir un résultat.
Le port knocking reste un plus, mais le considérer comme sûr est une
faille en soit, il protége encore des kiddies, mais d'eux seuls.


[snip]

pour les logs mettre ssh ailleurs que sur le 22/TCP c'est clairement
mieux. Par contre les deux solutions présentées ici ont le même défaut
qui peut être rédhibitoire : en "extérieur" certains opérateurs ne
laissent passer que certains ports, assez souvent 22 à ma grande joie
d'ailleurs, mais en en bloquent d'autre. Quand tu as besoin de ton ssh le
changement de port n'est pas la panacée en ce cas.

En tout état de cause, l'obscurité n'a jamais été un réel plus en
matière de sécurité. Un SSH bien configuré et les patchs de sécurité
appliqués en temps et en heure restent la défense la plus efficace, le
reste n'étant qu'une question de confort personnel.

Le 21/12/2009 à 14:29, Stephane Catteau a écrit :

bruno.treguier_at_shom.fr@nullepart.invalid devait dire quelque chose
comme ceci :

L'IP spoofing est tout sauf une légende urbaine, c'est d'ailleurs cette
technique (entre autres) qui a été utilisée par Kevin Mitnick lors de sa
célèbre attaque contre les ordinateurs de Tsutomu Shimomura (usurpation IP +
SYN flooding + prédiction des numéros de séquence TCP).

Sauf que ce que tu décris là n'est pas une attaque à proprement parler
mais un scan de port. S'il y a un service TCP en écoute sur le port, il
essayera de répondre à la poigné de main. La machine dont l'adresse IP
a été usurpée n'ayant aucune trace d'une tentative de connexion en cour
répondra d'un RST ce qui incrémentera le numéro de séquence TCP.

Bonjour Stéphane,

Renseigne-toi sur l'attaque en question, c'était très loin de n'être
qu'un scan de ports ! Il y a beaucoup de sources pour cela. L'un des
préalables à l'attaque de Mitnick consistait justement à faire taire la
machine légitime (et ainsi l'empêcher de répondre par un RST) en
l'inondant de paquets SYN et saturer les buffers prévus pour les
nouvelles connexions (ce qui est maintenant contourné par les SYN cookies).

Si la
pile IP n'a pas une forte randomisation du numéro de séquence TCP il
suffit donc (façon de parler puisqu'il faut aussi prédire le numéro de
séquence) d'interroger le port de l'hôte usurpé, avant et après le
scan. Si le numéro de séquence a été incrémenté deux fois, c'est que le
RST a effectivement été envoyé et donc que le port est ouvert.

Hmmm. Je pense que tu es en train de confondre avec le "dumb scan", là,
qui utilise effectivement une technique utilisant non pas les numéros de
séquence TCP, mais un champ IP qu'on appelle habituellement "IP ID" et
qui s'incrémente de façon simple sur beaucoup d'implémentation de piles
IP. Cette technique permet à un pirate de scanner des ports sans révéler
son adresse IP.

Par contre j'ai d'énormes doutes concernant la paternité de Mitnick,
vue que ce scan n'a été intégré à nmap qu'au environ de 2002 si ma
mémoire est bonne.

Ce n'est pas parce que ça n'a été intégré qu'en 2002 à nmap que ça
n'existait pas avant ! :-) Mais là on ne parle pas de la même chose de
toute façon...

Dans le cadre d'une véritable attaque, l'IP spoofing nécessite d'avoir
le controle sur, au choix, le routeur situé avant la cible ou celui
situé avant la machine dont l'adresse IP est usurpée. Autrement les
paquets arriveront fort logiquement sur la machine usurpée et
l'usurpation ne servirait à rien.

Ce que tu décris là est une attaque "man in the middle", rien à voir
avec l'IP spoofing, à mon avis...

Bonne fin de journée,

Cordialement,

Bruno

bruno.treguier_at_shom.fr@nullepart.invalid devait dire quelque chose
comme ceci :

Renseigne-toi sur l'attaque en question, c'était très loin de n'être
qu'un scan de ports ! Il y a beaucoup de sources pour cela. L'un des
préalables à l'attaque de Mitnick consistait justement à faire taire la
machine légitime (et ainsi l'empêcher de répondre par un RST) en
l'inondant de paquets SYN et saturer les buffers prévus pour les
nouvelles connexions (ce qui est maintenant contourné par les SYN cookies).

Ce qui n'est qu'un DoS et ne permet toujours pas à Mitnick de rentrer.


[snip]

Hmmm. Je pense que tu es en train de confondre avec le "dumb scan",

Possible.

Par contre j'ai d'énormes doutes concernant la paternité de Mitnick,
vue que ce scan n'a été intégré à nmap qu'au environ de 2002 si ma
mémoire est bonne.

Ce n'est pas parce que ça n'a été intégré qu'en 2002 à nmap que ça
n'existait pas avant ! :-)

Ca avait été intégré suite à la publication de la méthode. Tsutomu
Shimomura s'y connait suffisement pour comprendre ce qui lui était
arrivé et a l'égo qui va avec sa profession, il n'aurait pas gardé ça
pour lui ;)

Mais là on ne parle pas de la même chose de toute façon...

vi.

Dans le cadre d'une véritable attaque, l'IP spoofing nécessite d'avoir
le controle sur, au choix, le routeur situé avant la cible ou celui
situé avant la machine dont l'adresse IP est usurpée. Autrement les
paquets arriveront fort logiquement sur la machine usurpée et
l'usurpation ne servirait à rien.

Ce que tu décris là est une attaque "man in the middle", rien à voir
avec l'IP spoofing, à mon avis...

Non. Un man in the middle est destiné à intercepter une connexion
légitime, je parle bien d'IP spoofing. Dans le cadre d'une connexion
TCP, à moins d'un simple DoS il faut d'abord passer la poignée de main
et donc une discussion bilatérale. Or la machine usurpée n'acceptera
jamais de donner suite à une poignée de main qu'elle n'a pas initiée,
il faut donc que les paquets soit routée vers la machine de
l'attaquant, ce qui ne peut se faire qu'en ayant la main sur l'un des
deux routeurs terminaux. La seule exception c'est lorsque l'usurpation
se passe au sein d'un LAN, parce que c'est le seul cas où l'on a la
garantie d'être derrière le même routeur que la machine usurpée. Là
oui, si on attribue son adresse IP à notre machine et que l'on arrive à
DoSer la machine usurpée, on prendra sa place dans le réseau. Mais dans
le cadre d'une attaque in the wild, il n'y a quasiment aucune chance
d'y arriver si on ne place pas un tunnel Ip entre un routeur et notre
machine ; même si la machine usurpée est sur le même netbloc que la
notre il n'y a aucune garantie que le plan de routage du FAI
permettrait de prendre sa place autrement.

Cela dit, on en revient à ce que je répondais à Eric, l'heure est aux
botnets, ce qui change la donne. De nos jours l'IP spoofing n'a de sens
que pour contourner un filtrage par adresse IP. Dans tous les autres
cas de figure cacher l'adresse IP source est une complication inutile,
perdre une machine du botnet étant au final sans grande importance.
Cela d'autant plus que l'agonie massive des services abuses fait qu'en
général on ne perd même pas la machine utilisée.

Rebonjour Stéphane,

Le 21/12/2009 à 16:27, Stephane Catteau a écrit :

bruno.treguier_at_shom.fr@nullepart.invalid devait dire quelque chose
comme ceci :

Renseigne-toi sur l'attaque en question, c'était très loin de n'être
qu'un scan de ports ! Il y a beaucoup de sources pour cela. L'un des
préalables à l'attaque de Mitnick consistait justement à faire taire la
machine légitime (et ainsi l'empêcher de répondre par un RST) en
l'inondant de paquets SYN et saturer les buffers prévus pour les
nouvelles connexions (ce qui est maintenant contourné par les SYN cookies).

Ce qui n'est qu'un DoS et ne permet toujours pas à Mitnick de rentrer.

Mais si, ce DoS est justement destiné a bâillonner la machine usurpée !
Plus bas dans ton message, tu dis que jamais une machine usurpée
n'acceptera de donner suite à un 3-way-handshake dont elle n'est pas à
l'origine: je suis tout à fait d'accord. Pour éviter qu'elle ne réagisse
violemment à l'attaque en aveugle menée par Mitnick en balaçant des RST
à tout va, il fallait donc la faire taire, c'est précisément à cela que
ce DoS à base de SYN flooding sert.

Ensuite, Mitnick a exploité une relation de confiance préexistante entre
la machine usurpée (localisée chez Shimomura) et un serveur de l'UCSD
sur lequel celui-ci avait un compte.

Au final, Mitnick est bel et bien rentré sur la machine de Shimomura,
avec les droits root, qui plus est.

[snip]

Hmmm. Je pense que tu es en train de confondre avec le "dumb scan",

Possible.

Certain. ;-)

Ce que tu décris là est une attaque "man in the middle", rien à voir
avec l'IP spoofing, à mon avis...

Non. Un man in the middle est destiné à intercepter une connexion
légitime, je parle bien d'IP spoofing. Dans le cadre d'une connexion
TCP, à moins d'un simple DoS il faut d'abord passer la poignée de main
et donc une discussion bilatérale. Or la machine usurpée n'acceptera
jamais de donner suite à une poignée de main qu'elle n'a pas initiée,
il faut donc que les paquets soit routée vers la machine de
l'attaquant, ce qui ne peut se faire qu'en ayant la main sur l'un des
deux routeurs terminaux.

Non, voir ci-dessus. ;-)

La seule exception c'est lorsque l'usurpation
se passe au sein d'un LAN, parce que c'est le seul cas où l'on a la
garantie d'être derrière le même routeur que la machine usurpée. Là
oui, si on attribue son adresse IP à notre machine et que l'on arrive à
DoSer la machine usurpée, on prendra sa place dans le réseau. Mais dans
le cadre d'une attaque in the wild, il n'y a quasiment aucune chance
d'y arriver si on ne place pas un tunnel Ip entre un routeur et notre
machine ; même si la machine usurpée est sur le même netbloc que la
notre il n'y a aucune garantie que le plan de routage du FAI
permettrait de prendre sa place autrement.

Sur un LAN les choses sont effectivement beaucoup plus simples, mais via
des liaisons WAN, avec des routeurs qu'on ne maîtrise pas, le seul moyen
d'usurper une machine est de la faire taire avant... D'où le DoS.

Pour plus d'infos, voir ici le post de Shimomura lui-même, expliquant
comment il s'était fait avoir (ce qui a dû lui en coûter, vu l'ego du
bonhomme, comme tu le disais):

http://www.cs.berkeley.edu/~daw/security/shimo-post.txt

Cela dit, on en revient à ce que je répondais à Eric, l'heure est aux
botnets, ce qui change la donne. De nos jours l'IP spoofing n'a de sens
que pour contourner un filtrage par adresse IP. Dans tous les autres
cas de figure cacher l'adresse IP source est une complication inutile,
perdre une machine du botnet étant au final sans grande importance.
Cela d'autant plus que l'agonie massive des services abuses fait qu'en
général on ne perd même pas la machine utilisée.

Tout à fait d'accord avec cette dernière partie.

Cordialement,

Bruno