Databases, Systems & Networks

1 – Le concept

L’attaque SynFlood est basée sur l’envoi massif de demande d’ouverture de session TCP. Les buts recherchés peuvent être :

• Le Buffer Overflow du process écoutant le port TCP de destination.
• La saturation du nombre d’ouverture de session TCP en cours.

2 – Le fonctionnement

2.1 – Schéma

2.2 – Envoi du SYN

Le fonctionnement est de générer une trame TCP de demande de synchronisation à destination de la cible. Cette demande de synchronisation SYN est la première étape d’une ouverture de session TCP. Voici le schéma de l’entête TCP avec ce fameux flag SYN basé sur 1 bit :

Les 5 autres flags doivent être positionnés à 0.

2.3 – Réception par la cible A

La cible recevant la synchronisation TCP mémorise cette demande nécessitant donc de la mémoire et du processeur. Voici l’état des connexions d’un Windows XP avant la réception d’un Synflood :

Et voici après la réception des demandes de SYN :

La cible passe les requêtes reçues en SYN_RECEIVED. Cet état est temporaire, le temps de durée de vie est variable en fonction de la pile IP.

Dans mon exemple, la cible tourne sur une station XP limitée en nombre de sessions simultanée. Ceci ayant pour conséquence l’indisponibilité temporaire du port ciblé.

* testé depuis la machine ayant effectuée le Synflood

2.4 – Réponse de la cible A

Après la réception d’une demande de SYN, la cible renvoi une réponse de type SYNACK en positionnant les flags SYN, ACK à 1 et les 4 autres à 0. Puis, elle attend l’accusé (ACK) finissant l’ouverture de session.

Voici une capture de trame effectuée à l’aide de Sniffer Pro 4.70.04.

2003.09.23 – Capture Synflood – SnifferPro.cap

* 10.10.101.4 – Correspond à la Cible A

Vous pourrez remarquer que les 11 premières réponses de la cible sont des SYNACK et que les suivantes sont des ACKRST ! De plus, dans cet exemple, on peut s’apercevoir que Windows n’ayant pas eu ses 11 ACK finalisant les ouvertures de session, ré-émet ses 11 premiers SYNACK au cas où les trames n’auraient pas abouti. Cela relève purement du fonctionnement normal de TCP, du mode connecté apportant la garantie de transfert. Mais cela peut servir dans le cadre d’une attaque spoofée à l’attention d’une seconde cible.

2.5 – Réponse de la cible B

Trois hypothèses en fonction de l’IP source que vous aurez .

• Le premier cas, correspond à ne pas utiliser l’IPspoofing et donc de faire correspondre la cible B à l’émetteur originel. Vous recevrez donc alors le SYNACK de la cible A et vous en ferez ce que vous désirez.
• La seconde hypothèse est de spécifier une IP non attribuée. La réponse de la cible A n’aboutira donc pas et n’engendrera donc pas de trafic supplémentaire. La durée en état d’attente d’établissement de session sur la cible sera au maximum. Excepté le cas où un routeur informe la cible A via ICMP du drop du paquet ou de l’IP non routable.
• La troisième possibilité est de spécifier une correspondance à un Hôte. Alors celui-ci répondra certainement (cela est dépendant de la pile IP) un RST indiquant : « Je ne comprend pas ce que tu veux, je n’ai jamais rien demandé, alors ferme cette demande d’ouverture de session qui n’existe pas ! ». Intéressant, ce point de vue qui génère encore du trafic supplémentaire.

Voici une capture de trame effectuée à l’aide de Sniffer Pro 4.70.04.

2003.09.23 – Capture 2 Synflood – SnifferPro.cap

* 10.10.101.254 – Correspond à la Cible A
* 10.10.101.4 – Correspond à la Cible B

Vous pourrez remarquer que l’on retrouve bien les trois trames qui sont le SYN spoofé en IP source 10.10.101.4, la réponse SYNACK de la cible A et le RST de la cible B qui n’a pas émis le SYN.

3 – Les conseils et astuces

• Il n’y a pas d’intérêt à remplir la data de TCP, car la réponse ne la prendra pas en compte et ne figurera pas dans la trame retour. Laissez le champ data vide afin de vous permettre d’économiser de la bande passante pour générer plus de SYN.
• Testez cette attaque avec comme IP source la cible A ou la 127.0.0.1 ou même 0.0.0.0. Certaines piles IP n’apprécient pas du tout.
• Une combinaison avec le smurf amplifiera le débit vers la cible A afin de l’engorger. Tester de spécifier comme IP source le broadcast du réseau cible!
• Un Synflood avec une IP source aléatoire et changeante à chaque SYN risque de blacklister la planète sur l’IDS qui protège la cible A. Le résultat sera un serveur devenu inaccessible à tous à cause de son défenseur.

4 – Les liens

– L’information de « CERT Coordination Center »

5 – Les outils

– SynFlood est un outil spécifique pour l’envoi massif de SYN. De plus, vous pourrez changer l’IP source à volonté.
– FrameIP vous permettra de générer tous type de paquet IP. Ainsi, vous pourrez émettre les SYN à volonté.

6 – La conclusion

Cette méthode à pour but de saturer le nombre de session de la cible. Il peut s’avérer sur certaine pile IP que le résultat soit le crash du daemon écoutant le port ciblé.

7 – Discussion autour de la documentation

Vous pouvez poser toutes vos questions, vos remarques et vos expériences à propos de l’attaque SynFlood. Pour cela, rendez-vous sur le Forum “Sécurité”.

Source: SynFlood par _SebF