Discussion :

[Détail]

Bonjour,

J'étudie en ce moment le fonctionnement de TCP.

Il est marqué un peu partout que lors de l'établissement de la connexion, les deux interlocuteurs choisissent leurs numéros de séquence (La machine A impose le sien dans le premier SYN et la machine B impose le sien dans le ACK + SYN de réponse) de manière aléatoire (ce que j'ai vérifié avec wireshark).

Cependant, je ne comprends pas pourquoi ces numéros doivent être choisis aléatoirement.
D'après ce que j'ai pu voir sur différents sites cela serait pour permettre plusieurs connexions simultanées mais je ne comprends pas vraiment pourquoi ....
Si quelqu'un a la motivation de m'expliquer le pourquoi du comment en détail ça serait gentil

Merci d'avance

[ram-0000]

C'est pour empêcher le piratage (je crois que c'est la méthode qu'utilisait MitNick lorsqu'il "travaillait").

Les N° de séquences sont les seuls éléments qui permettent d'identifier la session une fois que la session est ouverte (avec les N° de ports et les adresse IP mais oublions les). En effet, j'attends un paquet avec le SN (Sequence Number) 1000, un paquet arrive avec le SN 1000, c'est donc le bon, je peux le traiter.

Imaginons maintenant un scénario dans lequel tous les SN commencent à 0. Il est très facile pour un pirate d'attendre que la session soit ouverte par l'utilisateur légal et alors de s'insérer dans la session (il faudra peut être "tuer" l'utilisateur légal mais c'est une autre histoire). Imaginons maintenant que la session soit une session telnet administrateur (ssh cela ne marcherait pas à cause de la crypto) et que lors de mon insertion dans la communication, j'envoie "rm -rf /". Tu te retrouves avec une machine qui n'a plus d'OS. Le pirate dans ce cas, n'a même pas besoin du retour de la session, cela s'appelle du spoofing IP, il se fait passer pour quelqu'un d'autre et en plus, il présente le bon numéro de SN.

C'est pour cela que maintenant, les piles IP présentent des SN plus ou moins aléatoires (avec plus ou moins de succès d'ailleurs, certaines piles anciennes présentent des SN prédictibles). D'ailleurs l'outil nmap présente aussi dans son rapport sur la machine scannée le degré de prédictibilité de ce SN.

[JML19]

Bonjour

Ceci à pour but de personnaliser le dialogue.

Pour qu'un dialogue soit personnalisé il faut qu'il contienne des données uniques et facilement identifiable, pour permettre de savoir qui cause et combien de fois il a causé, avec combien de mot.

Les numéros de séquence sont utilisés pour décompter les données dans le flux d'octets.

Par exemple un hôte A discute avec un hôte B il faut identifier A et B et savoir combien d'octets ont été transmis.

A envoie un numéro de séquence égale à 25 fourni par son compteur qui se remettra à zéro au bout de 2^32-1 numéro

A envoie aussi à B un numéro d'acquittement dit aussi ACK = 50 par exemple ce numéro est donné aussi par un compteur interne.

Donc A est identifié par la séquence = 25 et l'ACK = 50.

Il transmet en même temps 12 octets de dialogue par exemple.

Il faut maintenant que B dise à A qu'il le reconnait et qu'il à bien reçu le dialogue mais de la façon que A sache aussi que c'est bien B qui lui répond.

B dispose donc de 3 indicateurs le numéro de séquence = 25, l'ACK = 50 et les 12 octets qu'il a reçu.

Pour répondre il va prendre l'ACK de A et lui réexpédier comme numéro de séquence donc B transmettra 50 comme numéro de séquence.

Ensuite il faut qu'il indique le nombre d'octet reçu de la façon où A puisse savoir que c'est bien le nombre d'octet que lui restitue B.

Pour ce faire il va prendre le numéro de séquence de A = 25 et y ajoutera le numéro d'octet reçu = 12 donc 25 + 12 = 37.

Ce chiffre de 37 il l'enverra comme un ACK = 37 vers A.

Donc A reçoit un numéro de séquence de B qui est 50 qu'il peut identifier car il s'agit de son propre ACK et un ACK qui contient son numéro de séquence avec le nombre d'octet.

Comme A connait son numéro de séquence il le retrancher à l'ACK pour contrôler le nombre d'octet qu'il a transmis donc 37 - 25 = 12 octets est bien le nombre d'octet.

Pour terminer il faut que A dise à B que tout est bon qu'il a bien identifié B lui aussi que cet échange c'est bien déroulé et que le nombre d'octet reçu est bien le bon.

Dans ce cas pour terminer A confirme la réception du segment en envoyant un ACK à B, avec comme numéro de séquence son nouveau numéro de séquence qu'il vient de recevoir comme ACK de B, à savoir numéro de séquence = 37 et comme ACK le numéro de séquence du segment précédemment reçu = 50, augmenté de la quantité de données reçues (ACK = 50 + 12 = 62).

[Détail]

@JML19 : C'était la notion d'aléatoire qui me posait problème, mais merci pour ce rappel

@ram-0000 : Mais du coup, si un attaquant envoie 2^32 segments avec un numéro de séquence différent sur chacun d'entre eux, il pourra quand même s'infiltrer dans la session non ? D'autre part, même si les numéros de séquences commençaient à zéro lors de l'établissement de la transmission, comment le pirate peut il connaître le bon numéro de séquence pour "infiltrer un segment" étant donné qu'il doit quand même y avoir quelques échanges qui feront monter le numéro de séquence avant de pouvoir envoyer des commandes (pour telnet) ?

[ram-0000]

@ram-0000 : Mais du coup, si un attaquant envoie 2^32 segments avec un numéro de séquence différent sur chacun d'entre eux, il pourra quand même s'infiltrer dans la session non ?

2^32=4 milliard (environ). A raison de 1000 paquets par seconde (c'est rapide) , cela fait 4 millions de secondes ce qui font 46 jours ... Tu veux jouer avec moi ?

D'autre part, même si les numéros de séquences commençaient à zéro lors de l'établissement de la transmission, comment le pirate peut il connaître le bon numéro de séquence pour "infiltrer un segment" étant donné qu'il doit quand même y avoir quelques échanges qui feront monter le numéro de séquence avant de pouvoir envoyer des commandes (pour telnet) ?

Si le SN commencait toujours à 0 (ou toute autre valeur arbitraire), il est très facile de deviner le SN du paquet lorsque le mot de passe saisi est valide et de s'insérer dans la session. Avec quelques tâtonnement, un peu d'observation wireshark, à +/- 10 paquets près, c'est facile et 20 essais (+/-10), ce n'est plus 4 milliards, c'est jouable en brute force.

[Détail]

Je pensais avoir un peu près compris le principe :
-> Attendre qu'une personne se soit connectée puis, en falsifiant l'IP source et le numéro de séquence envoyer un segment en se faisant passer pour elle.

Donc par exemple envoyer en continu un paquet avec l'ip source d'une machine se connectant régulièrement en telnet, un numéro de séquence de 30 (si l'ISN était de 0) contenant les données "rm -rf /" et attendre que quelqu'un se connecte ?

Mais je suis tombé sur un exemple d'attaque basé là dessus sur un site que je ne comprends pas

Voici les images :
http://www.firewall.cx/images/storie...ection-2-2.gif
http://www.firewall.cx/images/storie...ection-2-3.gif

Source : http://www.firewall.cx/networking-to...k-numbers.html

En fait dans l'exemple, ils disent (d'après ce que je comprends) que le pirate sniff les données pour déterminer quel est l'algorithme qui définit les numéros de séquence et ainsi prévoir le prochain "premier numéro de séquence", mais à ce moment là il peut tout aussi bien juste faire le calcul (ancien numéro + taille du payload du dernier segment) pour l'obtenir non ?

Merci d'avance

[JML19]

Bonjour

Je constate que ce qui t'intéresse c'est le piratage, dans ce cas je ne répondrai plus à tes questions.

[ram-0000]

Je constate que ce qui t'intéresse c'est le piratage, dans ce cas je ne répondrai plus à tes questions.

Faut pas le prendre comme cela, ce n'est pas parce que on s'intéresse à la technique que l'on est nécessairement un "pirate". Je connais cette technique (et beaucoup d'autres aussi) et cela ne fait pas de moi un pirate.

Connaitre et comprendre la technique du "buffer overflow" (c'est une autre technique de piratage) par exemple, cela peut être utile aux développeurs afin que justement ils ne laissent pas cette possibilité dans leur code et cela n'en fait pas pour autant des pirates.

[JML19]

Bonjour ram-0000

Oui je sais, mais cela ne semble pas être le cas du développeur conscient de la sécurité de son code.

[Détail]

@JML19 Avant toute chose, je voudrais quand même faire remarquer que le site que j'ai cité n'est en rien un site de piratage, c'est juste une "analyse en profondeur" de l'entête TCP qui explique le rôle de chaque champ.

D'autre part, mon premier but était de comprendre pourquoi les numéros de séquences étaient choisis aléatoirement, ram-0000 m'a expliqué que c'était pour des raisons de sécurité et j'ai pensé comprendre ses explications.
Seulement, en tombant sur l'exemple d'une attaque je me suis rendu compte que ce n'était pas le cas .... Si je ne suis pas capable de comprendre pourquoi une attaque via TCP fonctionne c'est que je n'ai pas compris le protocole (chose qui m’intéresse).

C'est quand même expéditif de dire que je suis motivé par le piratage juste parce que je cite une attaque via TCP pour montrer que je n'ai pas tout compris ...

Merci d'avance à ceux qui voudront bien me répondre.

[JML19]

Bonjour Détail

Oui j'ai bien compris, mais dans le doute je ne répondrais plus à tes questions.

[Détail]

Je vois, je vais en rester là avec mes numéros de séquences du coup.
Je risque quand même de revenir poser des questions (qui j'espère n'auront rien à voir avec la sécurité ) sur TCP dans quelques jours.

Merci pour les réponses apportées sur ce topic.

[JML19]

Oui aucun problème, si tu ne touches pas à la sécurité des réseaux et des applications, nous essayerons de faire notre possible pour te répondre.

Si un jour tu deviens un vrai professionnel des réseaux, il faudra toi aussi que tu limites ton plaisir de montrer tes connaissances sur les forums.

[sevyc64]

Parmi les personnes qui s’intéressent fortement au comment des techniques de piratages et autres, on trouve principalement 2 groupes :
- Les pirates, futur pirates, aspirants pirates, ce qui s'y croient, etc...
- Ceux d'en face, ceux qui luttent contre les pirates, ceux qui, simplement, essaye de s'en protéger et de renforcer leur sécurité

Le meilleur moyen de se protéger est avant tout de comprendre comment ça marche.
Et expliquer, diffuser, le pourquoi du comment et comment combattre, non seulement discréditera ces méthodes là auprès des pirates (ils n'aiment pas la place publiques, ils préfère ce qui est secret, connu de peu, d'eux même seulement), mais aussi et surtout enseignera et mettra dans la connaissance ceux qui luttent et ceux qui sont victimes et leur permettront de mieux se protéger.

Évidemment on ne peut pas éviter les petits kevins malins qui se feront une joie d'essayer ces méthodes là, se croyant les maitres du mondes, alors qu'ils ne maitrisent même pas vraiment leur propres machines. Il y a quelques années on disait "C'est un mal pour un bien", aujourd'hui le terme à la mode c'est "Dommage collatéral"

[JML19]

Bonsoir sevyc64

Oui il faut quand même faire attention à nos connaissances.

L'erreur serait de croire qu'elles sont insignifiantes.

[ram-0000]

Source : http://www.firewall.cx/networking-to...k-numbers.html

En fait dans l'exemple, ils disent (d'après ce que je comprends) que le pirate sniff les données pour déterminer quel est l'algorithme qui définit les numéros de séquence et ainsi prévoir le prochain "premier numéro de séquence", mais à ce moment là il peut tout aussi bien juste faire le calcul (ancien numéro + taille du payload du dernier segment) pour l'obtenir non ?

En fait, sur la 1ere diapo, le pirate sniff le traffic pour obtenir les SN initiaux. Sur la 2eme diapo, il "tue" l'initiateur de la session et ensuite se fait passer pour lui puisqu'il possède les SN valides, (il les a sniffé). Il n'a pas deviné les SN initiaux, il les a sniffés, ce qui n'a rien à voir.

Ce type d'attaque n'est possible que sur un réseau local car il faut être capable de sniffer la session initiale (et donc être sur le chemin entre l'initiateur et le serveur). De nos jours, cela devient plus difficile car avec les switch cela devient "délicat" de sniffer une session entre 2 autres machines (je n'ai pas dit que c'était impossible).

Pour en revenir à ta question initiale, "pourquoi de SN aléatoires ?". Si le pirate en herbe n'est pas capable de sniffer (ce qui de nos jours devient "délicat"), il ne lui reste plus qu'à deviner les SN initiaux pour pouvoir s'insérer dans la session (par spoofing IP). Si les SN initiaux commencent à 0, c'est facile à deviner. Par contre, si les SN initiaux sont "aléatoires" cela devient très très dur (voire impossible).

Les SN initiaux sont aléatoires pour justement éviter ce type d'attaque.

[Détail]

C'est ce que je pensais aussi mais vu qu'ils parlaient de prédiction des SN j'avais eu un doute ...

Par contre, le seul moyen pour Mr.Méchant d'obtenir les réponses du serveur à ses "paquets trafiqués" c'est de sniffer le réseau non ? Puisque l'adresse IP source du "paquet trafiqué" ne sera pas la sienne.

[ram-0000]

Par contre, le seul moyen pour Mr.Méchant d'obtenir les réponses du serveur à ses "paquets trafiqués" c'est de sniffer le réseau non ?

C'est une possibilité (parmi d’autres) mais cela marche de moins en moins avec le nouveau matériel (les switches, si tu n'es pas administrateur dessus, tu ne peux pas sniffer une session qui n'est pas pour toi).