Dénis de Service {Les attaques par déni de service distribué}

II Le déni de service: Techniques

     D'un point de vue technique, ces attaques ne sont pas très compliquées, mais pourtant efficaces contre tout type de machine.
Globalement, on peut séparer les DoS en deux types:

• les attaques au niveau réseau
• les attaques au niveau applicatif

Au niveau réseau, le pirate peut viser la couche IP en exploitant une mauvaise gestion des anomalies protocolaires par le système ou une particularité de conception des protocoles eux-même. Une des plus anciennes attaques à utiliser les anomalies est probablement le "Ping of Death" qui utilise un problème de gestion de la défragmentation IP. Le "SYN Flood", quant à lui, se sert du protocole TCP pour épuiser les ressources du serveur visé. Ce type de DoS présente plusieurs avantages: il est généralement facile à implémenter, facile à mettre en place de façon distribué et plus générique que les attaques de type applicatif.
En effet, celles-ci sont plus ciblées. Le pirate vise le(s) service(s) fourni(s) par la machine, par exemple un serveur Web ou une base de données; ou même une architecture plus complexe, comprenant plusieurs services: une infrastructure VoIP ou autre.

Au fil du temps, beaucoup d'attaques sont apparues et nous n'allons pas essayer d'en dresser une liste. Nous illustrerons chaque type par un ou plusieurs exemples connus et représentatifs du moyen utilisé, afin de comprendre et de mesurer les caractéristiques des DoS.

1. Le SYN Flood

     Le "SYN Flood" illustre parfaitement le cas d'attaque sur les conceptions de protocole. Le "SYN Flood" est une des premières attaques de type DoS et toujours une des plus utilisées à nos jours. Elle exploite le protocole TCP. Pour comprendre correctement son principe, il faut donc connaître le fonctionnement de TCP et la particularité de son établissement de connexion.

L'établissement de connexion selon TCP: Three-Way Handshake

Quand un client veut établir une connexion à un serveur, les deux machines échangent une séquence de message permettant d'établir ladite connexion. Cette suite de message est constituée de 3 phases, d'où son nom Three-Way Handshake.

• Phase 1: le client demande une connexion en envoyant un message SYN (pour SYNchronize) au serveur.
• Phase 2: le serveur lui répond qu'il accepte sa demande et lui envoie un message SYN-ACK (SYNchronize-ACKnowledgment).
• Phase 3: le client répond à son tour avec un message ACK (ACKnowledgment) ; la connexion est alors établie.

Comment utiliser ce mécanisme d'établissement en trois phases pour rendre un service inaccessible? Il faut savoir que le serveur s'attend à recevoir l'ACK du client en phase 3 et comme il ne peut prédire le temps d'arrivé de cette réponse, il entame automatique une période d'attente.
Laisser le plus grand nombre de connexions TCP en attente d'accusé de réception, voilà la solution. Le pirate envoie un grand nombre de demandes de connexion SYN (Phase 1), mais ne répondra jamais au serveur par l'accusé ACK tant attendu (Phase 3). Les connexions en attente sont alors semi-ouvertes et occupent des ressources mémoires, du temps CPU, etc... 

Deux conséquences sont envisageables:

• le serveur refuse les nouvelles connexions émanant de bons clients,
• voire s'effondre suite à la saturation des ressources.

Cette attaque présente de nombreux avantages! En terme de bande passante, un paquet SYN ne fait que 64 octets... et en terme de simplicité, il est vraiment très facile de mettre cette technique en place et de provoquer rapidement des dégâts: n'importe quel générateur de paquet sait créer un paquet avec le flag SYN à 1 et créer un flood en une unique ligne de commande!

De plus, en combinant cette attaque avec la technique de l'IP Spoofing (le pirate usurpe une adresse IP), les SYN-ACK du serveur cible n'encombreront pas la bande passante du pirate...

2. L'UDP Flood

     Ce déni de service exploite le protocole UDP et mise sur le fait que le flux UDP est prioritaire à celui de TCP. Sur cet exemple, il s'agit aussi d'une utilisationdétournée de la conception des protocoles UDP et TCP. L'inondation de requêtes UDP est la clef de cette attaque: afin de parasiter le trafic, créer une congestion et saturer la bande passante du serveur cible, on noye ce dernier dans un flux UDP et celui-ci ne peut plus créer de nouvelles requêtes vers son véritable trafic TCP.

L'exemple maitre de ce DoS est le Chargen Denial of Service Attack. Ancienne attaque, elle se contre très facilement mais illustre parfaitement le terme d'inondation.

Simple, elle consiste à créer un jeu de ping-pong entre deux machines et qui emploie deux services: Echo et CharGen (le service CharGen génère des caractères tandis que Echo se contente de réémettre les données qu'il reçoit). Il suffit donc de faire communiquer ces deux services! 

Le pirate envoie une requête sur le port CharGen (19/UDP) d'une machine A indiquant (IP Spoofing) comme adresse source celle d'une machine B et comme port source, le port Echo (7/UDP). La machine A émet des caractères aléatoires et les envoie sur le service Echo de la machine B. Cette dernière renvoie les données sur le CharGen A, qui réémet des caractères aléatoires et les envoie à B... ainsi de suite jusqu'à la saturation de la bande passante. 

3. Attaque par fragmentation

     Voyons maintenant comment certains DoS exploitent une mauvaise gestion des anomalies protocolaires. L'attaque par fragmentation utilise une faille propre à certaines implémentations de pile IP comme celles de Windows 95 ou NT. Cette vulnérabilité concerne la gestion de la défragmentation IP (réassemblage des fragments IP).

Une attaque connue utilisant ce principe est le Teardrop. Il en existe des variantes: Bonk, Boink et Newtear par exemple, mais le fonctionnement reste le même.

Le pirate génère un Teardrop en fragmentant ses paquets IP de telle manière que lors de leur défragmentation par le serveur, ils se chevauchent (overlapping). Les paquets fragmentés contiennent en fait des informations de décalage (offset) erronées. Certaines parties des fragments sont alors écrasées; les mauvaises implémentations ne gèrent pas cette exception et provoquent un crash des systèmes visés.

Le Ping-of-Death (PoD) tire aussi parti d'une mauvaise implémentation de la défragmentation IP. 

Comme l'indique la RFC 791 sur IP, un paquet a une longueur maximale de 65535 octets. Un Ping-of-Death, c'est tout simplement un ping qui a une longueur de données supérieure à cette taille limite. Le système d'exploitation cible reçoit les fragments du PoD, les réassemble afin de reconstituer le paquet d'origine et va se figer ou planter si sa pile s'avère incapable de gérer cette opération illégale. 

4. Smurf ou l'attaque par réflexion

     Le "Smurf". Derrière ce nom, quelque peu barbare, se cache tout simplement l'exploitation du broadcast pour paralyser une cible...

Voyons-en un exemple avec le Ping Flood ("ICMP echo request/reply"). Voici le fonctionnement de cette attaque:

Le pirate récupère l'adresse IP du serveur visé. Il envoie ensuite un paquet ICMP Echo Request spoofé à une adresse de diffusion (broadcast). Ce ping est alors "démultiplié"; toutes les machines composant le réseau vont alors répondre à cette requête par un ICMP Echo Reply et la cible va recevoir tout le flux généré par ces réponses. Si le réseau compte un grand nombre de système, le trafic généré par ces réponses peut être considérablement volumineux.

L'impact de ce DoS est double; il sature la machine de l'adresse IP usurpée et il congestionne le trafic du réseau.

Bien qu'on puisse penser qu'il s'agisse d'un DDoS, ce n'est pas le cas. Il s'agit d'une attaque par rebond, qui détourne des systèmes intermédiaires participant à leur insu à ce DoS.

5. L'amplification DNS: une attaque récente

     Il y a quelques années, un nouveau type de DoS a fait son apparition: l'attaque par amplification DNS. De même que pour le "Smurf", le pirate ne cible pas directement la victime mais se sert de machines "innocentes": les serveurs DNS récursifs ouverts. Ceux-ci autorisent tout le monde à les interroger sur n'importe quel site. L'attaquant doit identifier un grand nombre de serveurs récursifs ouverts et va alors trouver une résolution DNS intéressante: c'est-à-dire ayant un enregistrement au champ TXT de taille la plus importante possible. Il ne plus qu'à effectuer ces demandes de résolution, en spoofant l'adresse IP de la victime, et les DNS répondent comme il se doit à la victime.

Ce qui est remarquable pour ce DoS, c'est l'amplification engendrée: une question est constituée de dizaines d'octets et la réponse peut représenter plusieurs milliers d'octets. Dans un cas examiné au Defcon, un paquet de 20 octets a grossi jusqu’à peser 8,5 Kilooctets. Le ratio volume-réponse/volume-requête est alors plus que considérable.