Une attaque de réinitialisation TCP est effectuée à l'aide d'un seul paquet de données de quelques octets au maximum. Le segment TCP remplacé par l'usurpation d'identité, créé et transmis par l'attaquant, trompe les deux victimes pour mettre fin à la connexion TCP, interrompant la connexion entre elles, ce qui pourrait être critique.
- Apprenez les bases de TCP
- Apprenez comment fonctionne l'attaque.
- Lançons une attaque contre nous-mêmes avec un simple script Python.
Avant de commencer à analyser la mécanique de l'attaque, voyons d'abord comment elle est utilisée dans le monde réel.Comment l'attaque de réinitialisation TCP est-elle utilisée dans le grand pare-feu?
Great Firewall (GFW) est un ensemble de systèmes et de techniques utilisés par le gouvernement chinois pour censurer Internet pour les utilisateurs chinois internes. GFW bloque et rompt activement les connexions avec les serveurs à l'intérieur et à l'extérieur du pays, et surveille également passivement le trafic Internet de contenu interdit.Pour empêcher les utilisateurs de se connecter même à des serveurs interdits, GFW utilise des techniques telles que la pollution DNS et le blocage IP(les deux coûtent des articles séparés). Cependant, le pare-feu GFW doit parfois être autorisé à établir une connexion, mais à le rompre au milieu. Par exemple, cela est nécessaire si vous souhaitez effectuer une analyse lente et en attente de la connexion, par exemple, sa corrélation avec d'autres actions. Ou il est utilisé si le pare-feu doit analyser les données échangées au cours du processus de connexion, puis utiliser ces informations pour décider de continuer ou de les bloquer. Par exemple, le trafic vers un site Web d'actualités peut être autorisé, mais les vidéos contenant des mots clés interdits seront censurées.Pour cela, GFW a besoin d'outils capables d'interrompre les connexions déjà établies. Un tel outil est une attaque de réinitialisation TCP.Comment fonctionne une attaque de réinitialisation TCP?
Dans une attaque de réinitialisation TCP, l'attaquant rompt la connexion entre les deux victimes, envoyant un ou les deux faux messages leur disant de se déconnecter immédiatement. Ces messages sont appelés segments de réinitialisation TCP . En fonctionnement normal sans la participation d'un attaquant, les ordinateurs envoient des segments de suppression TCP lorsqu'ils reçoivent du trafic TCP inattendu et souhaitent que l'expéditeur arrête de l'envoyer.L'attaque de réinitialisation TCP exploite malicieusement ce mécanisme, incitant les victimes à mettre fin prématurément aux connexions TCP en leur envoyant de faux segments de réinitialisation. Si le faux segment de réinitialisation est effectué correctement, le récepteur le prendra pour le segment réel et fermera la connexion de sa part, interrompant la transmission d'informations sur cette connexion. Pour poursuivre l'échange de données, les victimes peuvent essayer de créer une nouvelle connexion TCP, mais l'attaquant peut avoir la possibilité de réinitialiser cette nouvelle connexion. Heureusement, comme un attaquant a besoin de temps pour créer et envoyer un faux paquet, la suppression des attaques n'est vraiment efficace que contre les connexions à long terme. Connexions à court terme. par exemple, utilisé pour transférer de petites pages Web, ont généralement le temps de remplir leur mission au moment oùquand l'attaquant pourra les réinitialiser.L'envoi de faux segments TCP est en quelque sorte un processus facile, car ni TCP ni IP n'ont leurs propres moyens de vérifier l'identité de l'expéditeur. Il existe une extension IP appelée IPSec qui fournit l'authentification, mais elle n'est pas si largement utilisée. Les fournisseurs de services Internet doivent refuser de transmettre des paquets IP provenant d'une adresse IP manifestement fausse, mais il est allégué que ce contrôle est très médiocre. Tout ce que le destinataire peut faire est de prendre l'adresse IP source et le port à l'intérieur du paquet ou du segment à leur valeur nominale et, si possible, d'utiliser des protocoles de niveau supérieur, tels que TLS , pour identifier l'expéditeur . Cependant, comme les paquets de vidage TCP font partie du protocole TCP lui-même, ils ne peuvent pas être vérifiés à l'aide de ces protocoles de haut niveau.Malgré la simplicité de l'envoi de faux segments, la création d'un faux segment et l'exécution d'une attaque de réinitialisation TCP réussie peuvent toujours être une tâche ardue. Pour comprendre pourquoi cela se produit, nous devons comprendre le fonctionnement du protocole TCP.Comment fonctionne TCP
Le but du protocole TCP est d'envoyer au destinataire une copie exacte du bloc de données. Par exemple, si mon serveur envoie du HTML via TCP à votre ordinateur, la pile TCP de votre ordinateur (la partie de son système d'exploitation qui traite TCP) devrait sortir mon HTML exactement sous la même forme et dans l'ordre dans lequel mon serveur l'a envoyé.Cependant, mon HTML n'est pas transmis sur Internet d'une manière aussi parfaitement ordonnée. Il est divisé en plusieurs petits fragments (appelés segments TCP ), chacun étant transmis individuellement sur Internet et recréé dans l'ordre transféré par la pile TCP de votre ordinateur. Cette sortie restaurée est appelée un flux TCP . Chaque segment TCP est transmis dans son propre paquet IP , cependant, pour comprendre l'attaque, nous n'avons pas besoin de connaître les détails de l'IP.La conversion de segments en un flux nécessite des précautions car Internet n'est pas fiable. Les segments TCP peuvent être perdus. Ils peuvent être hors service, envoyés deux fois, endommagés et subir de nombreuses autres mésaventures. Par conséquent, le but du protocole TCP est d'assurer une transmission de données fiable sur un réseau peu fiable. TCP effectue cette tâche, exigeant que les deux côtés de la connexion maintiennent un contact étroit entre eux et transmettent constamment des informations sur les blocs de données reçus. Cela permet aux expéditeurs de comprendre les données que le destinataire n'a pas encore reçues et de retransmettre les données perdues.Pour comprendre le fonctionnement du processus, nous devons comprendre comment les expéditeurs et les récepteurs utilisent les numéros de séquence TCP pour le marquage et le suivi des données transmises via TCP.Numéros de séquence TCP
Chaque octet transmis sur une connexion TCP a un numéro de séquence qui lui est attribué par l'expéditeur. Les machines réceptrices utilisent des numéros de série pour déplacer les données reçues dans la commande d'origine.Lorsque deux machines négocient une connexion TCP, chaque machine envoie un autre numéro de séquence de démarrage aléatoire . Il s'agit du numéro de séquence que la machine attribuera au premier octet qu'elle envoie. Chaque octet suivant reçoit le numéro de séquence de l'octet précédent plus 1. Les segments TCP contiennent des en-têtes TCP , qui sont des métadonnées attachées au début du segment. Le numéro de séquence du premier octet dans le corps du segment est inclus dans l'en-tête TCP de ce segment.Il convient de noter que les connexions TCP sont bidirectionnelles, c'est-à-dire que les données peuvent être transmises dans les deux sens, et chaque machine dans une connexion TCP agit à la fois comme un expéditeur et un récepteur. Pour cette raison, chaque machine doit attribuer et traiter son propre ensemble indépendant de numéros de séquence.Confirmation de réception des données
Lorsqu'une machine reçoit un segment TCP, elle indique à l'expéditeur du segment qu'il a été reçu. Le destinataire le fait en envoyant un segment ACK(abréviation de «accusé de réception»), contenant le numéro de séquence de l' octet suivant qu'il s'attend à recevoir de l'expéditeur. L'expéditeur utilise ces informations pour comprendre que le récepteur a bien reçu tous les autres octets jusqu'à ce nombre.Un segment est ACKindiqué par la présence d'un indicateur ACKet le numéro de confirmation correspondant dans l'en-tête TCP du segment. Il n'y a que 6 drapeaux dans le protocole TCP, y compris (comme nous le verrons bientôt) un drapeau RST(abréviation de «reset» - «reset»), indiquant le segment de réinitialisation.Remarque: TCP permet également l'utilisation d' accusés de réception sélectifs , qui sont transmis lorsque le récepteur a reçu certains segments, mais pas tous, dans la plage de nombres. Par exemple, "J'ai reçu les octets 1000-3000 et 4000-5000, mais pas 3001-3999". Par souci de simplicité, je ne considérerai pas les ACK sélectifs dans notre discussion sur les attaques de réinitialisation TCP.Si l'expéditeur transmet des données mais ne reçoit pasACKpour eux pendant un certain intervalle de temps, il suppose que les données ont été perdues et les renvoie, en leur donnant les mêmes numéros de série. Cela signifie que si le récepteur accepte deux fois les mêmes octets, il utilise trivialement les numéros de séquence pour se débarrasser des doublons sans interrompre le flux. Le destinataire peut accepter des données en double parce que le segment d'origine a été reçu plus tard, après qu'il a été envoyé à nouveau, ou parce que le segment d'origine a été reçu avec succès, mais que le segment correspondant a été ACKperdu sur le chemin de l'expéditeur.Bien que ces données en double soient assez rares, le gaspillage excessif de ressources qui en résulte ne pose pas de problèmes. Si toutes les données parviennent tôt ou tard au destinataire et que les données correspondantes ACKparviennent à l'expéditeur, la connexion TCP fait son travail.Choisir un numéro de série pour un faux segment
Lors de la création d'un faux segment, l' RSTattaquant doit lui donner un numéro de série. Les destinataires sont très heureux que vous ayez besoin d'accepter des segments avec des numéros de série incohérents et de les connecter indépendamment dans le bon ordre. Cependant, leurs capacités sont limitées. Si le destinataire reçoit un segment avec un numéro de séquence qui est «trop» hors service, il rejette un tel segment.Par conséquent, pour une attaque de réinitialisation TCP réussie, un numéro de séquence plausible est requis. Mais qu'est-ce qui est considéré comme un tel nombre? Pour la plupart des segments (bien que, comme nous le verrons plus loin, pas pour RST), la réponse est déterminée par la taille de la fenêtre TCP .Taille de la fenêtre TCP
Imaginez un ancien ordinateur du début des années 1990, connecté à un réseau de fibre optique gigabit moderne. Un réseau ultrarapide peut transférer des données vers cet ordinateur âgé à une vitesse incroyable, plus rapidement que la machine ne peut les traiter. Cela nous dérange, car le segment TCP ne peut pas être considéré comme reçu tant que le récepteur ne peut pas le traiter.Les ordinateurs ont une mémoire tampon TCP dans laquelle les nouvelles données arrivant en attente de traitement pendant que l'ordinateur travaille sur les données qui arrivent avant. Cependant, ce tampon a une taille limitée. Si le destinataire n'est pas en mesure de faire face à la quantité de données qui lui est transmise par le réseau, le tampon débordera. Lorsque le tampon est plein, le destinataire n'a d'autre choix que de se débarrasser des données redondantes. Le destinataire n'envoie pas ACKde données supprimées, l'expéditeur doit donc les renvoyer lorsqu'il y a de l'espace libre dans le tampon du destinataire. Peu importe la vitesse à laquelle le réseau peut transmettre des données si le destinataire n'a pas le temps de les gérer.Imaginez un ami trop zélé qui vous envoie un flux entier de lettres à votre courrier plus rapidement que vous ne pouvez le lire. Il y a un certain espace tampon à l'intérieur de votre boîte aux lettres, mais une fois qu'il est plein, toutes les lettres non placées tomberont au sol, où les renards et autres créatures les mangeront. Un ami devra renvoyer les lettres qu'il a mangées, mais pour l'instant vous aurez le temps de recevoir ses précédents messages. L'envoi d'un trop grand nombre de lettres ou d'un volume de données que le destinataire n'est pas en mesure de traiter est un gaspillage d'énergie et de canal de transmission.«Trop» - de combien de données s'agit-il? Comment l'expéditeur comprend-il quand envoyer plus de données et quand vaut-il la peine d'attendre? C'est là que la taille de la fenêtre TCP est utile.. La taille de la fenêtre du destinataire est le nombre maximal d'octets non acquittés que l'expéditeur peut lui transférer à tout moment. Supposons que le destinataire signale que sa taille de fenêtre est de 100 000 (nous découvrirons bientôt comment il transmet cette valeur), de sorte que l'expéditeur envoie 100 000 octets. Supposons qu'au moment où l'expéditeur a transmis un cent millième d'octet, le récepteur ait envoyé les segments ACKpour les 10 000 premiers de ces octets. Cela signifie que 90 000 octets n'ont pas encore été confirmés. Étant donné que la taille de la fenêtre est de 100 000, l'expéditeur peut transférer 10 000 autres octets avant d'attendre de nouveaux ACK. Si, après avoir envoyé ces 10 000 octets supplémentaires,ACKs'il n'a pas été reçu, l'expéditeur s'exécutera dans sa limite de 100 000 octets non confirmés. Par conséquent, l'expéditeur devra attendre et cesser d'envoyer des données (sauf pour la retransmission de données qu'il considère comme perdues) jusqu'à ce qu'il en reçoive de nouvelles ACK.Chaque côté de la connexion TCP notifie à l'autre la taille de sa fenêtre pendant le processus de prise de contact qui est effectué lorsque la connexion est ouverte. De plus, la taille des fenêtres peut être modifiée dynamiquement pendant le processus de connexion. Un ordinateur avec un grand tampon TCP peut annoncer une grande taille de fenêtre pour maximiser le débit. Cela permet à la machine qui communique avec elle de transmettre en continu des données via une connexion TCP sans pause ni attente de confirmation. Un ordinateur avec un petit tampon TCP peut être contraint de signaler une petite taille de fenêtre. Parfois, les expéditeurs remplissent complètement la fenêtre et sont obligés d'attendre que certains segments soient confirmés. La bande passante en souffre, mais il est nécessaire que les tampons TCP ne débordent pas.
max_seq_no), que l'expéditeur peut envoyer à l'heure actuelle:max_seq_no = max_acked_seq_no + window_size
max_acked_seq_no- Il s'agit du numéro de séquence maximum pour lequel le destinataire a envoyé ACK. Il s'agit du numéro de séquence maximal que l'expéditeur sait que le destinataire a exactement reçu. Étant donné que l'expéditeur ne peut transmettre que des window_sizeoctets non confirmés, le numéro de séquence maximal qu'il peut envoyer est max_acked_seq_no + window_size.Pour cette raison, la spécification TCP indique que le destinataire doit ignorer toutes les données qu'il reçoit qui ont des numéros de série en dehors de la fenêtre valide. Par exemple, si le destinataire a confirmé tous les octets jusqu'à 15 000 et que la taille de sa fenêtre est de 30 000, il recevra toutes les données avec un numéro de série compris entre 15 000 et (15 000 + 30 000 = 45 000). De plus, le destinataire ignore complètement les données avec des numéros de série en dehors de cet intervalle. Si un segment contient des données, dont certaines se trouvent dans cette fenêtre et d'autres en dehors, alors les données à l'intérieur de la fenêtre seront acceptées et confirmées, mais les données à l'extérieur seront rejetées. Notez que nous ignorons toujours la possibilité des sélectionsACK qui ont été brièvement évoquées au début du post.Dans le cas de la plupart des segments TCP, cette règle nous donne un intervalle de numéros de séquence acceptables. Cependant, comme mentionné précédemment, les RSTrestrictions imposées sur les segments sont encore plus strictes que les restrictions sur les segments de transmission de données ordinaires. Comme nous le verrons bientôt, cela a été fait pour compliquer la conduite d'une variante d'une attaque de réinitialisation TCP appelée «attaque de réinitialisation TCP aveugle» .Numéros de séquence acceptables pour les segments RST
Les segments réguliers sont acceptés si leur numéro de séquence se situe entre le prochain numéro de séquence attendu et ce numéro plus la taille de la fenêtre. Cependant, les paquets RSTne sont reçus que lorsque leur numéro de séquence est exactement égal au prochain numéro de séquence attendu. Revenons à l'exemple précédent, dans lequel le destinataire a envoyé le numéro de confirmation 15 000. Pour que le paquet RSTsoit reçu, son numéro de séquence doit être exactement 15 000. Si le destinataire reçoit un segment RSTavec un numéro de séquence différent de 15 000, il ne l'acceptera pas.Si le numéro de séquence est en dehors de l'intervalle, le récepteur l'ignore complètement. Cependant, s'il se trouve dans la fenêtre des numéros de séquence attendus, le récepteur envoie un «défi ACK» («appel ACK»). Il s'agit d'un segment qui indique à l'expéditeur que le segment RSTa un numéro de séquence non valide. Il indique également à l'expéditeur le numéro de séquence que le destinataire attend. L'expéditeur peut utiliser ces informations de l' ACKappel pour recréer et renvoyer les siennes RST.Jusqu'en 2010, TCP n'a pas imposé ces restrictions de segment supplémentaires RST. Les segments ont été RSTacceptés ou rejetés conformément aux mêmes règles que les autres. Cependant, cela a également simplifié les attaques aveugles de réinitialisation TCP aveugles .Attaques TCP aveugles
Si l'attaquant a la capacité d'intercepter le trafic échangé entre ses victimes, il peut lire les numéros de série et de confirmation des paquets TCP des victimes. Il peut utiliser ces informations pour sélectionner les numéros de série à attribuer à ses faux segments RST. Cependant, si l'attaquant ne peut pas intercepter le trafic des victimes, il ne saura pas quels numéros de séquence insérer. Mais il peut toujours transférer n'importe quel nombre de segments RSTavec un nombre quelconque de numéros de série différents, en espérant que l'un d'eux se révèle être correct. Une telle attaque est appelée attaque de réinitialisation TCP aveugle.Comme nous l'avons déjà dit, dans la version initiale du protocole TCP, l'attaquant n'avait qu'à récupérer le numéro de sérieRSTdans la fenêtre TCP du récepteur. Un article intitulé «Slipping in the Window» a montré que cela rendait les attaques aveugles trop faciles, car pour un succès presque garanti, un attaquant n'avait qu'à envoyer des dizaines de milliers de segments. Pour contrer cela, la règle qui obligeait le destinataire à accepter le segment a RSTété remplacée par le critère plus strict décrit ci-dessus. Grâce aux nouvelles règles pour effectuer des attaques de réinitialisation TCP, des millions de segments doivent être envoyés à l'aveugle, ce qui les rend pratiquement irréalisables. Voir RFC-5963 pour plus de détails .Effectuer une attaque de réinitialisation TCP contre nous-mêmes
Remarque: J'ai testé ce processus sur OSX, mais j'ai reçu quelques commentaires selon lesquels il ne fonctionne pas correctement sous Linux.Nous savons maintenant tout sur l'exécution d'une attaque de réinitialisation TCP. L'attaquant doit:- Regarder le trafic réseau ( «sniff» ) entre deux victimes
- Renifler le segment TCP avec le drapeau activé
ACKet lire son numéro confirmé - Créez un faux segment TCP avec l'indicateur activé
RSTet un numéro de séquence égal au numéro confirmé du segment intercepté (notez que cela implique une transmission lente, sinon le numéro de séquence sélectionné deviendra rapidement obsolète. (Pour augmenter les chances de succès, vous pouvez transférer plusieurs segments RSTavec un grand intervalle de numéros de séquence .) - Envoyez de faux segments à une ou aux deux victimes, en espérant que cela rompra leur connexion TCP
Pour nous entraîner, menons une attaque TCP contre nous-mêmes sur le même ordinateur, en communiquant avec nous-mêmes localhost. Pour cela, nous avons besoin de:- Configurer la connexion TCP entre deux fenêtres de terminal
- Écrivez un programme d'attaque qui traitera le reniflement du trafic
- Modifiez le programme pour qu'il produise et envoie de faux segments
RST.
Commençons.1. Etablissement d'une connexion TCP entre deux fenêtres de terminal
Nous allons configurer la connexion TCP à l'aide de l'outil netcat, qui par défaut est disponible sur de nombreux systèmes d'exploitation. Tout autre client TCP fera l'affaire . Dans la première fenêtre du terminal, nous exécuterons la commande suivante:nc -nvl 8000
Cette commande démarre un serveur TCP écoutant sur un port de notre machine locale 8000. Dans la deuxième fenêtre de terminal, exécutez la commande suivante:nc 127.0.0.1 8000
Cette commande tente de créer une connexion TCP à la machine par l'adresse IP du 127.0.0.1port 8000. Maintenant, entre les deux fenêtres du terminal, une connexion TCP doit être établie. Essayez de saisir quelque chose dans une fenêtre - les données devront être transmises via la connexion TCP et apparaître dans une autre fenêtre.2. Reniflement du trafic
Nous allons écrire un programme d'attaque qui effectue le reniflement du trafic à l'aide de la scapybibliothèque réseau Python populaire. Ce programme utilise scapy pour lire les données transférées entre deux fenêtres du terminal, bien qu'il ne fasse pas partie de la connexion.Le code du programme est publié dans mon référentiel sur GitHub . Le programme renifle le trafic de connexion et l'affiche sur le terminal. Le noyau principal du code est l'appel sniffde méthode à partir de la bibliothèque scapysituée à la fin du fichier:t = sniff(
iface='lo0',
lfilter=is_packet_tcp_client_to_server(localhost_ip, localhost_server_port, localhost_ip),
prn=log_packet,
count=50)
Ce morceau de code nous dit scapyde renifler les paquets sur l'interface lo0et de capturer les détails de tous les paquets dans le cadre de notre connexion TCP. L'appel a les paramètres suivants:iface- commandes scapyd'écoute de l'interface réseau lo0ou localhostlfilter — , scapy , IP- localhost . , , lo0. , .prn — , scapy , lfilter. . , RST.count — , scapy .
Pour tester ce programme, configurez la connexion TCP à partir de l'étape 1. Clonez mon référentiel GitHub, suivez les instructions de configuration et exécutez le programme dans la troisième fenêtre du terminal. Saisissez du texte dans l'un des terminaux de la connexion TCP. Vous devriez voir que le programme commencera à enregistrer des informations sur les segments de connexion.3. Envoi de faux colis RST
Nous avons établi une connexion et le programme peut détecter tous les segments TCP qui le traversent. Il ne nous reste plus qu'à modifier le programme pour qu'il effectue une attaque de réinitialisation TCP en transmettant de faux segments RST. Pour ce faire, nous allons changer la fonction prn(voir la liste des paramètres ci-dessus), appelée scapypour les packages qui répondent aux exigences de la fonction lfilter. Dans la version modifiée de la fonction, au lieu de simplement fixer le package correspondant, nous l'étudions, extrayons les paramètres nécessaires et utilisons ces paramètres pour créer et envoyer le segment RST.Supposons que nous ayons intercepté un segment allant de (src_ip, src_port)k (dst_ip, dst_port). Il a un drapeau ACKet le numéro de confirmation est 100 000. Pour fabriquer et envoyer un segment, nous:- IP- , . , . , .
RST , , RST- , ,
send scapy — .
Pour modifier notre programme précédent selon vos besoins, décommentez cette ligne et commentez la ligne au-dessus.Nous sommes maintenant prêts pour une attaque à grande échelle. Configurez la connexion TCP conformément à l'étape 1. Exécutez le programme d'attaque à partir de l'étape 2 dans la troisième fenêtre du terminal. Saisissez ensuite du texte dans l'un des terminaux de la connexion TCP. Dans le terminal où vous avez saisi le texte, la connexion TCP se coupera soudainement et mystérieusement. L'attaque est terminée!La poursuite des travaux
- Continuez d'expérimenter avec l'outil d'attaque. Suivez ce qui se passe si vous ajoutez ou soustrayez 1 du numéro de séquence du package
RST. Assurez-vous qu'il doit être exactement égal à la valeur du ackpaquet intercepté. - Wireshark
lo0 . TCP-, RST. ip.src == 127.0.0.1 && ip.dst == 127.0.0.1 && tcp.port == 8000 . - , .
RST, RST , . , RST, .
L'attaque de réinitialisation TCP est à la fois profonde et simple à la fois. Bonne chance avec vos expériences et faites-moi savoir si vous avez des questions ou des commentaires.