Tweet
Bonjour.
Nous allons voir comment exploiter le Checksum Overflow. Cette technique consiste à envoyer un très grand nombre d'en-têtes IP à une machine victime, sans inclure le résultat du calcul du flags checksum. La machine victime devra donc utiliser ses propres ressources pour calculer les multiples cheksum reçues et saturera sa mémoire de calcul ; cela peut mener à un DoS (ou à un DDoS si on utilise la broadcast d'une passerelle).
I) Pré-requis (connaissances)
Chaque trame IP (paquet de donnée) transitant entre deux machines est composé d'un header appelé en-tête IP. Cet en-tête contient toutes les données nécessaires afin que la machine recevant la trame associée puisse en valider la conformité, et donc lui faire confiance. Un en-tête IP d'une trame standard se compose comme ceci:
En-tête IP:
Les champs qui nous intéressent ici sont le CHECKSUM, l'IP SOURCE et l'IP DESTINATION.
Le checksum est une séquence (codée sur 16 bits) qui doit être calculée par les acteurs du réseau (NAT, PAT, Routeurs...) afin de valider la conformité des trames IP émises. Le checksum doit être recalculée à chaque modification de la trame IP associée. On comprend donc que si l'on envoit une trame IP non-spécifique à une machine, elle devra elle même calculer le checksum afin de s'assurer que la trame IP reçue est valide.
Il faut aussi savoir que par défaut c'est le protocole TCP qui est utilisé (bidirectionnel), et que donc, en plus d'envoyer une trame IP, une trame TCP est aussi envoyée (contenant les data de session) avec un en-tête contenant lui aussi un checksum. La machine qui reçoit une trame IP non-spécifique doit alors calculer deux checksum.
II) Exploitation
Nous devons saturer le processeur de la machine cible. Il nous faut donc construire une trame IP (la trame TCP correspondante sera construite automatiquement) non-spécifique (sans checksum de contrôle) et l'envoyer à la machine victime qui devra dépenser des ressources pour calculer ces checksum.
Pourquoi ne pas en plus utiliser le Broadcast Smurfing ? En effet, si l'on envoi la trame IP non-spécifique sur l'adresse broadcast d'un réseau (ou plusieurs réseaux) comportant plusieurs machines (des centaines) avec comme IP SOURCE celle de la machine victime et comme IP DESTINATION celle de la broadcast, la trame IP sera envoyée par des centaines de machines en même temps, et la machine cible devra calculer plusieurs milliers de checksum.
Les trames TCP non-spécifiques satureront la pile TCP de la victime, et les trames IP non-spécifique satureront la mémoire du processeur dépassée par tous les calculs à effectuer. Cela conduit irrémédiablement à un DoS (ou DDoS) par dépassement (overflow) de la mémoire de la victime, ou tout du moins à un lag démoniaque.
Afin de procéder à la construction de la trame, il est nécessaire de passer par un Byte-per-Byte Building Script (C,C++,Python..) ou tout simplement en utilisant des logiciels déjà prévus à cet effet, comme le très efficace FrameIP -> http://www.frameip.com/frameip/
III. Protection
Il est possible de s'en prémunir en utilisant un IDS (Intrusion detection system) et en le configurant de manière à analyser le traffic réseau, et notamment les trames IP en transit, afin de détecter les trames non-spécifiques (sans CHECKSUM) et ainsi de les rediriger vers la machine source, ou tout simplement de les bloquer et de les vider dans la pile.
Cependant, si cette attaque est utilisée parallèlement à une attaque Man In The Middle, alors toutes les trames reçues seront non-spécifiques et les bloquer avec un IDS reviendrait à placer soi-même sa machine en DoS par rapport au reste du réseau.
Nous allons voir comment exploiter le Checksum Overflow. Cette technique consiste à envoyer un très grand nombre d'en-têtes IP à une machine victime, sans inclure le résultat du calcul du flags checksum. La machine victime devra donc utiliser ses propres ressources pour calculer les multiples cheksum reçues et saturera sa mémoire de calcul ; cela peut mener à un DoS (ou à un DDoS si on utilise la broadcast d'une passerelle).
I) Pré-requis (connaissances)
Chaque trame IP (paquet de donnée) transitant entre deux machines est composé d'un header appelé en-tête IP. Cet en-tête contient toutes les données nécessaires afin que la machine recevant la trame associée puisse en valider la conformité, et donc lui faire confiance. Un en-tête IP d'une trame standard se compose comme ceci:
En-tête IP:
Code:
- VERS /IHL - SERVICE - LONGUEUR TOTALE - IDENTIFICATION - FLAGS - TTL - PROTOCOLE - CHECKSUM - IP SOURCE - IP DESTINATION
Les champs qui nous intéressent ici sont le CHECKSUM, l'IP SOURCE et l'IP DESTINATION.
Le checksum est une séquence (codée sur 16 bits) qui doit être calculée par les acteurs du réseau (NAT, PAT, Routeurs...) afin de valider la conformité des trames IP émises. Le checksum doit être recalculée à chaque modification de la trame IP associée. On comprend donc que si l'on envoit une trame IP non-spécifique à une machine, elle devra elle même calculer le checksum afin de s'assurer que la trame IP reçue est valide.
Il faut aussi savoir que par défaut c'est le protocole TCP qui est utilisé (bidirectionnel), et que donc, en plus d'envoyer une trame IP, une trame TCP est aussi envoyée (contenant les data de session) avec un en-tête contenant lui aussi un checksum. La machine qui reçoit une trame IP non-spécifique doit alors calculer deux checksum.
II) Exploitation
Nous devons saturer le processeur de la machine cible. Il nous faut donc construire une trame IP (la trame TCP correspondante sera construite automatiquement) non-spécifique (sans checksum de contrôle) et l'envoyer à la machine victime qui devra dépenser des ressources pour calculer ces checksum.
Pourquoi ne pas en plus utiliser le Broadcast Smurfing ? En effet, si l'on envoi la trame IP non-spécifique sur l'adresse broadcast d'un réseau (ou plusieurs réseaux) comportant plusieurs machines (des centaines) avec comme IP SOURCE celle de la machine victime et comme IP DESTINATION celle de la broadcast, la trame IP sera envoyée par des centaines de machines en même temps, et la machine cible devra calculer plusieurs milliers de checksum.
Les trames TCP non-spécifiques satureront la pile TCP de la victime, et les trames IP non-spécifique satureront la mémoire du processeur dépassée par tous les calculs à effectuer. Cela conduit irrémédiablement à un DoS (ou DDoS) par dépassement (overflow) de la mémoire de la victime, ou tout du moins à un lag démoniaque.
Afin de procéder à la construction de la trame, il est nécessaire de passer par un Byte-per-Byte Building Script (C,C++,Python..) ou tout simplement en utilisant des logiciels déjà prévus à cet effet, comme le très efficace FrameIP -> http://www.frameip.com/frameip/
III. Protection
Il est possible de s'en prémunir en utilisant un IDS (Intrusion detection system) et en le configurant de manière à analyser le traffic réseau, et notamment les trames IP en transit, afin de détecter les trames non-spécifiques (sans CHECKSUM) et ainsi de les rediriger vers la machine source, ou tout simplement de les bloquer et de les vider dans la pile.
Cependant, si cette attaque est utilisée parallèlement à une attaque Man In The Middle, alors toutes les trames reçues seront non-spécifiques et les bloquer avec un IDS reviendrait à placer soi-même sa machine en DoS par rapport au reste du réseau.
Commentaire