Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Est-ce que le MITM est facilement visible ?

JeBotPas

Bonjour,

Je ne bot pas, je ne fais que lire les paquets pour faire des outils d'optimisation. (achat / vente hdv etc ...).

J'apprends actuellement le réseau, je suis de base autodidacte en développement et mon poste actuel me demande une connaissance pousser en réseau pour gérer un parc informatique assez conséquent et complexe d'établissement public. (Les protocoles de sécurité bonjour !).

On va s'intéresse à la première partie du header du paquet. (Pour ceux qui viennent pas curiosité, en gros quand on envoie un paquet au serveur il envoie tout un header qui fait partie du protocole TCP).

Je viens ici justement pour apprendre et débattre le faite que le MITM est potentiellement visible ou non.

Le paquet commence donc avec:

AA AA AA AA AA AA (6 bytes représentant l'adresse MAC du serveur)
BB BB BB BB BB BB (6 bytes représentant l'adresse MAC du client)
08 00 (protocole IPV4)
XX (n° protocole et taille du protocole)
00 (service généralement c'est 00)
XX XX (Taille du paquet, comme D2 ça donne la taille après l'IPV4 jusqu'à la fin de la data)
XX XX (identification du protocole)
40 (sans le dernier bit = pas de coupures)
00 (+ le dernier bit de 40 = fragment)
XX (temps de vie ?)
XX (Protocole TCP ?)
XX XX (header checksum)
CC CC CC CC (IP du serveur)
DD DD DD DD (IP du client)

Nous voilà sur la fin de la première partie du paquet qui contient les informations basic (les adresses mac et protocole IPV) ainsi que la partie du protocole du TCP (il manque la partie "Control Protocole), je ne pourrais pas bien tout expliquer ni leurs utilités.

J'ai appris et je crois que c'est l'identifiant qu'il est généré de façon aléatoire par le client à la connexion puis qu'il augmente pour à la fois sécurisé la connexion puisque qu'un piratage simulant l'adresse mac de la personne devra avoir ce numéro d'identifiant de départ et qu'en plus ça permet de savoir dans quel ordre sont à lire les paquets reçus si plusieurs sont reçus.

Il y à aussi divers numéros généré comme le "header checksum" ou dans la deuxième partie il y à un "raw number" "acknowledgment number" ou encore un numéro "checksum".

Le cumule de toutes ces informations mal suivis, mal généré ne causerait il pas un ban facile pour les MITM ? Ça ce trouve il serait facile de ban pas mal de bots rien qu'avec ces infos mais que ce n'est pas utilisé ...

Voilà, je me pose juste la question, car ma méthode de lecture via les bibliothèque de Wireshark permettant en toute invisibilité récupérer les informations arrivant sur ma carte réseau, de trier l'IP que je souhaites et je reçois tout le paquet complet. (le protocole + les data).

Je voulais faire des tests car on peut y répondre et j'essaye d'apprendre pour justement générer les paquets manuellement car tout est à faire à la main !

Cela fait un peu comme un MITM 100% indétectable, mais ... En regardant de plus près je me suis dis, mais comment le client arrive à suivre si des numéros sont progressif et que hors client j'envoie des paquets avec un numéro supérieur que le prochain envoie du client ?? :'(

Par exemple je suis à 42755, j'envoie 42756 le client va renvoyer un avec le numéro 42756 ... J'ai peux être juste très mal compris l'utilité !

Merci pour ceux qui m'aiderons à mieux comprendre ou à ceux qui ferons avancer ce débat qui je penses sera torché par quelqu'un qui s'y connaît un peu en 1 seul message ^^'

JeBotPas

Pour revenir sur le sujet ..

En effet, le protocole TCP génère (normalement) un numéro de séquence au départ.

Ensuite, ce numéro augmente de la taille du paquet.

Prenons un exemple : je génère mon paquet avec le chiffre 1548 et j'envoie un paquet de 53 octets.

Le paquet suivant aura pour numéro de séquence 1601 (1548 + taille du paquet 53 = 1601).

Quand vous faites un bot, tout cela est généré à 100% de façon automatique par le protocole réseau qui sont déjà pré programmer.

Vous ne faites qu'utiliser des choses existantes.

Cependant, lors d'un MITM vous avez d'un côté le client qui à sa propre gestion TCP et votre bot qui lui à une autre gestion TCP.

Ce qui créer une incohérence au niveau des numéros de séquence.

Par exemple le client officiel est au numéro de séquence 15871 j'envoie via le bot un paquet de 100 octets, le client envoie un paquet de 50 octets le prochain numéro de séquence sera 15 921 au lieu de 16 021. Et c'est là qu'il y à un problème !

Je n'ai pas tester en pratique, seulement en théorie.

Seul un bot MITM partageant le même système d'envoie TCP que le client permet le bon suivis des chiffres, si vous avez votre propre envoie comme j'ai pu en voir qui sont en dehors du client, vous êtes sujet à être facilement repéré..

C'est pas du direct, car en cas d'un envoie qui n'arrive pas à sa source les chiffres peuvent ne pas être bon, cependant dans la logique du TCP c'est sensé renvoyer et réguler le numéro séquence. Ce qui ne sera jamais votre cas, en quelques heures vous êtes repéré.

tazman59

Hello,

Je ne connais pas les tréfonds du protocole TCP.

C'est smart d'avoir pensé à ça. A vrai dire le client Dofus 2 utilise dans son protocole (beaucoup plus haut niveau) une technique similaire qui permet de déceler les décalages quand un MITM envoie un paquet à la place du client. C'est une simple valeur incrémentée à chaque envoie de paquet.

Si le client officiel envoie 20 paquets au serveur et que le MITM en envoie 2, Le serveur recevra 22 paquets. Le client ne se doutant de rien incrémentera son nombre de paquet envoyés de 1 lors du prochain envoie. Donc 21. L'info étant transmise dans chaque paquet, le serveur détectera le décalage immédiatement. Ban.

Le moyen de bypass ça est tout simple. Depuis le MITM, il suffit de parser les headers de chaque paquet interceptés et d'incrémenter la valeur par le nombre de paquets que le MITM a envoyé de lui même.

Concernant tes inquiétudes concernant les décalages TCP. Je pense que tu oublies que la connexion client -> MITM et MITM -> serveur sont toutes les deux des connexions saines ! :)

Le client pense communiquer avec le vrai serveur, et le serveur pense communiquer avec le vrai client.

Ce que le client envoie au serveur est récupéré par le MITM. Et le MITM l'envoie au serveur et inversement.

Donc il ne peut pas y avoir de décalage dans les trames TCP entre le MITM et le serveur. (Ni même entre le client et le MITM).

Après oui, si par je ne sais quel moyen tu pouvais injecter de la data dans le flux TCP, alors là oui il y aurait forcément des décalages. :)

J'espère avoir répondu à tes questions.

fioutubs

T’as bien un décalage qui peut se créer si ton bot envoi des paquets à la volée alors que le Client « n’a rien envoyé ». Le bot sera à n_packet + 1 alors que le Client sera à n_packet. Cependant, essaye de créer un simple Client/Serveur Socket dans ton langage favori et de récupérer cette info à partir du Serveur via l’objet Socket, pas sûr que ce soit possible.