Fig.2: Fragment 2
Fig.3: Paquet défragmenté
original in fr Eric Detoisien
Eric Detoisien est spécialiste en sécurité informatique. Passionné par tous les domaines liés à la sécurité, il fait partie des experts du groupe rstack - www.rstack.org -
Cet article a été publié dans un numéro spécial sur la sécurité de Linux Magazine France. L'éditeur, les auteurs, les traducteurs ont aimablement accepté que tous les articles de ce numéro hors-série soient publiés dans LinuxFocus. En conséquence, LinuxFocus vous "offrira" ces articles au fur et à mesure de leur traduction en Anglais. Merci à toutes les personnes qui se sont investies dans ce travail. Ce résumé sera reproduit pour chaque article ayant la même origine.
Cet article présente les différentes attaques externes qu'un pirate peut utiliser à l'encontre des machines d'un réseau. Nous aborderons ce sujet au travers des principales attaques réseaux, des attaques via les applications et des attaques de type déni de service.
Les attaques réseaux s'appuient sur des vulnérabilités liées directement aux protocoles ou à leur implémentation. Il en existe un grand nombre. Néanmoins, la plupart d'entre elles ne sont que des variantes des cinq attaques réseaux les plus connues aujourd'hui.
D'après la RFC (Request For Comment) 791 (IP), tous les noeuds Internet (routeurs) doivent pouvoir transmettre des paquets d'une taille de 68 octets sans les fragmenter d'avantage. En effet, la taille minimale de l'en-tête d'un paquet IP est de 20 octets sans options. Lorsqu'elles sont présentes, la taille maximale de l'en-tête est de 60 octets. Le champ IHL (Internet Header Length) contient la longueur de l'en-tête en mots de 32 bits. Ce champ occupant 4 bits, le nombre de valeurs possibles vaut de 2^4 - 1 = 15 (il ne peut pas prendre la valeur 0000). La taille maximale de l'en-tête est donc bien 15*4 = 60 octets. Enfin, le champ Fragment Offset qui indique le décalage du premier octet du fragment par rapport au datagramme complet est mesurée en blocs de 8 octets. Un fragment de données occupe donc au moins 8 octets. Nous arrivons bien à un total de 68 octets.
L'attaque consiste à fragmenter sur deux paquets IP une demande de connexion TCP. Le premier paquet IP de 68 octets ne contient comme données que les 8 premiers octets de l'en-tête TCP (ports source et destination ainsi que le numéro de séquence). Les données du second paquet IP renferment alors la demande de connexion TCP (flag SYN à 1 et flag ACK à 0).
Or, les filtres IP appliquent la même règle de filtrage à tous les fragments d'un paquet. Le filtrage du premier fragment (Fragment Offset égal à 0) déterminant cette règle elle s'applique donc aux autres (Fragment Offset égal à 1) sans aucune autre forme de vérification. Ainsi, lors de la défragmentation au niveau IP de la machine cible, le paquet de demande de connexion est reconstitué et passé à la couche TCP. La connexion s'établit alors malgré le filtre IP.
Les figures 1 et 2 montrent les deux fragments et la figure 3 le paquet défragmenté au niveau de la machine cible :
Fig.1: Fragment 1
Fig.2: Fragment 2
Fig.3: Paquet défragmenté
Toujours d'après la RFC 791 (IP), si deux fragments IP se superposent, le deuxième écrase le premier. L'attaque consiste à forger deux fragments d'un paquet IP. Le filtre IP accepte le premier de 68 octets (voir Tiny Fragments) car il ne contient aucune demande de connexion TCP (flag SYN = 0 et flag ACK = 0). Cette règle d'acceptation s'applique, là encore, aux autres fragments du paquet. Le deuxième (avec un Fragment Offset égale à 1) contenant les véritables données de connexion est alors accepté par le filtre IP. Ainsi, lors de la défragmentation les données du deuxième fragment écrasent celles du premier à partir de la fin du 8ème octet (car le fragment offset est égal à 1). Le paquet réassemblé constitue donc une demande de connexion valide pour la machine cible. La connexion s'établit malgré le filtre IP.
Les figures 4 et 5 montrent les deux fragments et la figure 6 le paquet défragmenté au niveau de la machine cible :
Fig.4: Fragment 1
Fig.5: Fragment 2
Fig.6: Paquet défragmenté
Le but de cette attaque est l'usurpation de l'adresse IP d'une machine. Ceci permet au pirate de cacher la source de son attaque (utilisée dans les dénis de services dont nous discuterons plus tard) ou de profiter d'une relation de confiance entre deux machines. Nous expliquerons donc ici cette deuxième utilisation de l'IP Spoofing.
Le principe de base de cette attaque consiste à forger ses propres paquets
IP (avec des programmes comme hping2 ou nemesis)
dans lesquels le pirate modifiera, entre autres, l'adresse IP source. L'IP
Spoofing est souvent qualifié d'attaque aveugle (ou Blind Spoofing).
Effectivement, les réponses éventuelles des paquets envoyés ne peuvent pas
arriver sur la machine du pirate puisque la source est falsifiée. Ils se
dirigent donc vers la machine spoofée. Il existe néanmoins deux méthodes
pour récupérer des réponses :
Le Blind Spoofing s'utilise contre des services de type rlogin ou rsh. En effet, leur mécanisme d'authentification se base uniquement sur l'adresse IP source de la machine cliente. Cette attaque relativement bien connue (surtout grâce à Kevin Mitnick qui l'avait utilisée contre la machine de Tsutomu Shimomura en 1994) se déroule en plusieurs étapes :
showmount -e qui montre où
sont exportés les systèmes de fichiers ou rpcinfo
qui apporte des informations supplémentaires;
echo ++ >> /.rhosts. Pour cela il forge un paquet avec le
flag TCP PSH (Push) : les données reçues sont
immédiatement transmises à la couche supérieure, ici le service rsh,
pour que celle-ci les traitent. Il lui est alors possible de se
connecter sur la machine directement via un service de type rlogin ou
rsh sans IP Spoofing.
La figure 7 résume les étapes de l'IP Spoofing :
Pic.7: IP Spoofing appliqué au service rsh
Le pirate utilise la machine A tandis que la C représente la machine
de confiance. La notion A(C) signifie que le paquet est envoyé par A
avec l'adresse IP Spoofée de C. A noter l'existence du programme
mendax qui met en oeuvre ces différents mécanismes de
l'IP Spoofing.
Le TCP Session Hijacking permet de rediriger un flux TCP. Un pirate peut alors outrepasser une protection par un mot de passe (comme telnet ou ftp). La nécessité d'une écoute passive (sniffing) restreint le périmètre de cette attaque au réseau physique de la cible. Avant de détailler cette attaque, nous expliquerons quelques principes fondamentaux du protocole TCP.
Nous ne dévoilerons pas ici les arcanes du protocole TCP, mais préciserons uniquement les points essentiels à la compréhension de l'attaque. L'en-tête TCP est constitué de plusieurs champs :
La figure 8 schématise l'établissement d'une connexion
TCP (Three Way Handshake) :
Fig.8 : Three Way Handshake
Dans ce cas, il s'agit de la machine A qui a initialisé une connexion TCP sur la machine B. De même, la figure 9
montre un transfert de données TCP :
Fig.9 : Échange de données:
Les numéros de séquence vont évoluer en fonction du nombre d'octets de données envoyés. Le numéro de séquence est représenté par Seq, le numéro d'acquittement se trouve après les flags PSH et ACK et le nombre d'octets de données envoyé se trouve entre parenthèses.
Cette attaque crée un état de désynchronisation de chaque côté de la connexion TCP, rendant possible le vol de session. Une connexion est désynchronisée lorsque le numéro de séquence du prochain octet envoyé par la machine A est différent du numéro de séquence du prochain octet à recevoir par B. Et réciproquement, il y a désynchronisation lorsque le numéro de séquence du prochain octet envoyé par la machine B est différent du numéro de séquence du prochain octet à recevoir par A.
Dans l'exemple de la figure 9, à la fin de la première étape quand B reçoit son paquet, A attends un paquet avec un numéro d'acquittement de x+60. Si le prochain paquet qu'envoie B n'a pas ce numéro d'acquittement alors A et B sont dits désynchronisés.
Concrètement, un pirate avec une machine C veut voler une session Telnet établie entre les machines A et B. Dans un premier temps, la machine C sniffe le traffic Telnet (port TCP 23) entre A et B. Une fois que le pirate estime que A a eu le temps de s'authentifier auprès du service Telnet de la machine B, il désynchronise la machine A par rapport à B. Pour cela, il forge alors un paquet avec, comme adresse IP source, celle de la machine A et le numéro d'acquittement TCP attendu par B. La machine B accepte donc ce paquet. En plus de désynchroniser la connexion TCP ce paquet permet au pirate d'injecter une commande via la session Telnet préalablement établie par A. En effet, ce paquet peut transporter des données (flag PSH égal à 1).
La figure 10 résume cette attaque :
Fig.10: TCP Session Hijacking
La machine B accepte bien la commande envoyée par C, elle acquitte donc ce paquet en envoyant un paquet à A avec le flag ACK. Entre temps, si A a envoyé un paquet à B celui-ci n'a pas été accepté du fait de numéro de séquence qui n'est pas celui attendu par B.
Un problème apparaît alors : le Ack Storm. Il s'agit d'une multitude de ACK qui sont générés. Ils apparaissent lorsque A envoie un paquet TCP avec un numéro de séquence non valide (car A est désynchronisé) B le jette et envoie à A un ACK avec le numéro de séquence qu'il attend. De son côté, A reçoit ce ACK et comme le numéro de séquence ne correspond pas à celui attendu il renvoie à son tour un ACK à B et B refait la même chose...
Ce problème du Ack Storm peut être réglé si le pirate utilise l'ARP
Spoofing. Dans ce cas, la machine C empoisonnera le cache ARP de la
machine B en lui indiquant que l'adresse IP de A est désormais
associée à l'adresse MAC de C. Ces différentes techniques sont
implémentées par le programme hunt.
Cette attaque, appelée aussi ARP Redirect, redirige le trafic réseau d'une ou plusieurs machine vers la machine du pirate. Elle s'effectue sur le réseau physique des victimes. Au préalable nous ferons un rappel sur l'utilité et le fonctionnement du protocole ARP.
Le protocole ARP (Address Resolution Protocol) implémente le mécanisme de résolution d'une adresse IP en une adresse MAC Ethernet. Les équipements réseaux communiquent en échangeant des trames Ethernet (dans le cas d'un réseau Ethernet bien sûr) au niveau de la couche liaison de données. Pour pouvoir échanger ces informations il est nécessaire que les cartes réseau possèdent une adresse unique au niveau Ethernet, il s'agit de l'adresse MAC (Media Access Control).
Quand un paquet IP doit être envoyé la machine expéditrice a besoin de l'adresse MAC du destinataire. Pour cela une requête ARP en broadcast est envoyée à chacune des machines du réseau physique local. Cette requête pose la question : "Quelle est l'adresse MAC associée à cette adresse IP ?". La machine ayant cette adresse IP répond via un paquet ARP, cette réponse indiquant à la machine émettrice l'adresse MAC recherchée. Dès lors, la machine source possède l'adresse MAC correspondant à l'adresse IP destination des paquets qu'elle doit envoyer. Cette correspondance sera gardée pendant un certain temps au niveau d'un cache (pour éviter de faire une nouvelle requête à chaque paquet IP envoyé).
Cette attaque corrompt le cache de la machine victime. Le pirate envoie des paquets ARP réponse à la machine cible indiquant que la nouvelle adresse MAC correspondant à l'adresse IP d'une passerelle (par exemple) est la sienne. La machine du pirate recevra donc tout le trafic à destination de la passerelle, il lui suffira alors d'écouter passivement le trafic (et/ou le modifier). Il routera ensuite les paquets vers la véritable destination.
L'ARP Spoofing sert dans le cas où le réseau local utilise des switchs. Ceux-ci redirigent les trames Ethernet sur des ports différents selon l'adresse MAC. Il est dès lors impossible à un sniffer de capturer des trames au-delà de son brin physique. L'ARP Spoofing permet ainsi d'écouter le trafic entre des machines situées sur des brins différents au niveau du switch.
Pour mettre en oeuvre une attaque par ARP Spoofing, le pirate va
utiliser un générateur de paquet ARP comme ARPSpoof ou
nemesis. Soit la machine victime 10.0.0.171,
sa passerelle par défaut 10.0.0.1 et la machine du pirate
10.0.0.227. Avant l'attaque un traceroute donne comme
résultat :
[root@cible -> ~]$ traceroute 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets 1 10.0.0.1 (10.0.0.1) 1.218 ms 1.061 ms 0.849 ms
Et le cache ARP de la machine cible est :
[root@cible -> ~]$ arp Address HWtype HWAddress Flags Mask Iface 10.0.0.1 ether 00:b0:c2:88:de:65 C eth0 10.0.0.227 ether 00:00:86:35:c9:3f C eth0
Le pirate lance alors ARPSpoof :
[root@pirate -> ~]$ arpspoof -t 10.0.0.171 10.0.0.1 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
Les paquets envoyés sont des paquets ARP empoisonnant le cache ARP de
la machine 10.0.0.171 avec des ARP Reply indiquant que
l'adresse MAC associée à 10.0.0.1 est maintenant
00:00:86:35:c9:3f.
Désormais, le cache ARP de la machine 10.0.0.171 est :
[root@cible -> ~]$ arp Address HWtype HWAddress Flags Mask Iface 10.0.0.1 ether 00:00:86:35:c9:3f C eth0 10.0.0.227 ether 00:00:86:35:c9:3f C eth0
Pour vérifier que le trafic passe maintenant par la machine
10.0.0.227 il suffit de faire un nouveau traceroute vers
la passerelle 10.0.0.1 :
[root@cible -> ~]$ traceroute 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets 1 10.0.0.227 (10.0.0.227) 1.712 ms 1.465 ms 1.501 ms 2 10.0.0.1 (10.0.0.1) 2.238 ms 2.121 ms 2.169 ms
Le pirate est désormais capable de sniffer le trafic de la machine
10.0.0.171 vers 10.0.0.1. Il ne faut pas que le
pirate oublie d'activer le routage IP sur sa machine
10.0.0.227 (avec l'IP Forwarding - activer la clé
net.ipv4.ip_forward dans /etc/sysctl.conf ou
fragrouter).
Le protocole DNS (Domain Name System) a pour rôle de
convertir un nom de domaine (par exemple www.test.com) en son adresse
IP (par exemple 192.168.0.1) et réciproquement, à savoir
convertir une adresse IP en un nom de domaine. Cette attaque consiste
à faire parvenir de fausses réponses aux requêtes DNS émisent par une
victime. Il existe deux méthodes principales pour effectuer cette
attaque.
L'en-tête du protocole DNS comporte un champ identification qui permet de faire correspondre les réponses aux demandes. L'objectif du DNS ID Spoofing est de renvoyer une fausse réponse à une requête DNS avant le serveur DNS. Pour cela il faut prédire l'ID de la demande. En local, il est simple de le prédire en sniffant le réseau. Néanmoins, cela s'avère plus compliqué à distance. Cependant il existe plusieurs méthodes :
Dans tous les cas, il est nécessaire de répondre avant le serveur DNS, en le faisant tomber via un déni de service par exemple.
Pour parvenir à ses fins, l'attaquant doit contrôler un serveur DNS
(ns.attaquant.com) ayant autorité sur le domaine
attaquant.com. Le serveur DNS cible
(ns.cible.com) est supposé avoir des numéros de séquence
prévisibles (s'incrémentant de 1 à chaque nouvelle requête).
L'attaque se décompose en quatre étapes :
www.attaquant.com au serveur DNS du domaine
cible.com comme le montre la figure 11;ns.cible.com
attaquant.com;www.spoofed.com qui a
normalement l'adresse IP 192.168.0.1. Le pirate
émet une requête DNS de résolution du nom
www.spoofed.com vers
ns.cible.com. Immédiatement après, il envoie
une multitude de réponses DNS falsifiées (donnant comme adresse
IP celle du site de l'attaquant 10.0.0.1) à cette
même requête en ayant spoofé l'adresse IP source avec celle du
serveur DNS du domaine spoofed.com. L'ID de chaque
réponse sera incrémenté de 1 à partir de celui récupéré lors de
la deuxième étape (ID = 100) pour augmenter la chance de tomber
sur le bon numéro d'ID réponse, dans le cas où
ns.cible.com aurait du répondre à d'autres requêtes
et donc incrémenté son ID DNS. La figure 12 détaille cette étape.
www.spoofed.com
récupérera l'adresse IP de la machine de l'attaquant et sera redirigée
vers son site qui pourra être une copie du vrai site pour tromper les
internautes et leur voler des informations confidentielles.
Les serveurs DNS possèdent un cache gardant en local, pendant un certain temps, les réponses de requêtes passées. Ceci pour éviter de perdre du temps à interroger chaque fois le serveur de nom ayant autorité sur le domaine demandé. Ce deuxième type de DNS Spoofing va consister à corrompre ce cache avec de fausses informations. Voici un exemple de cache poisoning :
Les conditions de l'exemple précédent sont toujours valables. Voici les différentes étapes de l'attaque :
www.attaquant.com au serveur DNS du domaine
cible.com;www.attaquant.com au serveur DNS
de l'attaquant; www.cible.com pourra avoir un
enregistrement DNS falsifié renvoyant l'adresse IP de
www.attaquant.com au lieu de la bonne adresse IP.Les attaques applicatives s'appuient principalement sur des vulnérabilités spécifiques aux applications utilisées. Cependant, certaines attaques peuvent être classées par type.
Un des premiers problèmes de sécurité engendré par les applications est celui des erreurs de configurations. Nous distinguerons deux types d'erreurs : les installations par défaut et les mauvaises configurations à proprement parler.
Des logiciels, comme les serveurs Web, installés par défaut ont souvent des sites exemples qui peuvent être utilisés par des pirates pour accéder à des informations confidentielles. Par exemple, il peut y avoir des scripts permettant d'obtenir les sources des pages dynamiques ou des informations sur le système utilisé. En outre, lors d'une telle installation une interface d'administration à distance est disponible avec un login/mot de passe par défaut (trouvable dans le guide d'administration de l'application). Le pirate a donc la main sur le site et peut le modifier selon son bon vouloir.
Les principales failles générées par une mauvaise configuration sont des listes d'accès mal paramètrées. Le pirate accède alors à des pages et autres bases de données privées.
Comme exemple classique de problème de configuration, les erreurs de paramétrage du serveur Web Lotus Domino sont courantes. En effet, lors de l'installation de ce serveur, des bases Lotus de configuration sont accessibles sans aucune liste de contrôle d'accès. Concrètement, si la base Lotus names.nsf est accessible via un navigateur Web sans demande d'authentification, il est alors possible d'obtenir de nombreuses informations comme le nom de tous les utilisateurs Lotus. Cette base n'est qu'un exemple, et Lotus Domino en contient un nombre important de sensibles.
Une mauvaise programmation des logiciels entraîne obligatoirement des "bugs". Ceux-ci seront la source des failles de sécurité les plus importantes. Ces vulnérabilités quand elles sont découvertes vont permettre d'exécuter des commandes non autorisées, obtenir le source de pages dynamiques, rendre indisponible un service, prendre la main sur la machine, etc. Les plus connus de ces "bugs" et les plus intéressants en ce qui concerne leur exploitation sont les buffer overflow.
Le dépassement de pile est une faille due à une mauvaise
programmation. Effectivement, un buffer overflow apparaît quand une
variable passée en argument d'une fonction est recopiée dans un buffer
sans que sa taille n'aie été vérifiée. Il suffit que la variable ait
une taille supérieure à l'espace mémoire réservé pour ce buffer pour
qu'un dépassement de pile se produise. Celui-ci sera exploité en
passant dans la variable un fragment de programme capable de faire
démarrer un shell tout en obligeant ce débordement de pile à se
produire. Dans le cas où un pirate réussi cette attaque il obtiendra
alors le moyen d'exécuter à distance des commandes sur la machine
cible avec les droits de l'application attaquée. Le buffer overflow et
son exploitation ont été le sujet d'une série d'articles sur la programmation
sécurisée :
Une mauvaise programmation des scripts a souvent une répercution sur la sécurité d'un système. En effet, il existe des moyens d'exploiter des failles de scripts développés en Perl qui permettront de lire des fichiers hors racine Web ou d'exécuter des commandes non autorisées. Ces problèmes de programmation ont été évoqués dans l'un des articles ci-dessus, sur les failles des développements en Perl et PHP (Partie 6, les scripts CGI).
L'objectif principal de cette attaque est de détourner le trafic entre deux machines. Cela pour intercepter, modifier ou détruire les données transmises au cours de la communication. Cette attaque est plus un concept qu'une attaque à part entière. Il existe plusieurs attaques mettant en oeuvre ce principe du Man in The Middle, comme le DNS Man in the Middle qui qu'une utilisation du DNS Spoofing pour détourner le trafic entre un client et un serveur Web. De même, une application récente a été élaborée pour détourner du trafic SSH.
Cette attaque porte bien son nom puisque qu'elle aboutira à l'indisponibilité du service (application spécifique) ou de la machine visée. Nous distinguerons deux types de déni de services, d'une part ceux dont l'origine est l'exploitation d'un bug d'une application et d'autre part ceux dus à une mauvaise implémentation d'un protocole ou à des faiblesses de celui-ci.
Tout comme les vulnérabilités d'une application entraînent la possibilité de prendre le contrôle d'une machine (exemple du buffer overflow), elles peuvent aussi amener à un déni de service. L'application sera alors indisponible par saturation des ressources qui lui sont allouées ou un crash de celle-ci.
Il existe différents types de déni de service utilisant les spécificités des protocoles de la pile TCP/IP.
Nous avons vu qu'une connexion TCP s'établie en trois phases (TCP Three Way Handshake). Le SYN Flooding exploite ce mécanisme d'établissement en trois phases. Les trois étapes sont l'envoi d'un SYN, la réception d'un SYN-ACK et l'envoi d'un ACK. Le principe est de laisser sur la machine cible un nombre important de connexions TCP en attentes. Pour cela, le pirate envoie un très grand nombre de demandes de connexion (flag SYN à 1), la machine cible renvoie les SYN-ACK en réponse au SYN reçus. Le pirate ne répondra jamais avec un ACK, et donc pour chaque SYN reçu la cible aura une connexion TCP en attente. Etant donné que ces connexions semi-ouvertes consomment des ressources mémoires au bout d'un certain temps la machine est saturée et ne peut plus accepter de connexion. Ce type de déni de service n'affecte que la machine cible.
Le pirate utilise un SYN Flooder comme synk4, en indiquant le port TCP cible et l'utilisation d'adresses IP source aléatoires pour éviter toute identification de la machine du pirate.
Ce déni de service exploite le mode non connecté du protocole UDP. Il crée un "UDP Packet Storm" (génération d'une grande quantité de paquets UDP) soit à destination d'une machine soit entre deux machines. Une telle attaque entre deux machines entraîne une congestion du réseau ainsi qu'une saturation des ressources des deux hôtes victimes. La congestion est plus importante du fait que le trafic UDP est prioritaire sur le trafic TCP. En effet, le protocole TCP possède un mécanisme de contrôle de congestion, dans le cas où l'acquittement d'un paquet arrive après un long délai, ce mécanisme adapte la fréquence d'émission des paquets TCP, le débit diminue. Le protocole UDP ne possède pas ce mécanisme, au bout d'un certain temps le trafic UDP occupe donc toute la bande passant n'en laissant qu'une infime partie au trafic TCP.
L'exemple le plus connu d'UDP Flooding est le Chargen Denial of
Service Attack. La mise en pratique de cette attaque est simple,
il suffit de faire communiquer le service chargen d'une
machine avec le service echo d'une autre. 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 alors au pirate d'envoyer des paquets UDP sur le
port 19 (chargen) à une des victimes en spoofant
l'adresse IP et le port source de l'autre. Dans ce cas le port source
est le port UDP 7 (echo). L'UDP Flooding entraîne une
saturation de la bande passante entres les deux machines. Un réseau
complet peut donc être victime d'un UDP Flooding.
Les dénis de service de type Packet Fragment utilisent des faiblesses dans l'implémentation de certaines pile TCP/IP au niveau de la défragmentation IP (réassemblage des fragments IP).
Une attaque connue utilisant ce principe est Teardrop. L'offset de fragmentation du second fragment est inférieur à la taille du premier ainsi que l'offset plus la taille du second. Cela revient à dire que le deuxième fragment est contenu dans le premier (overlapping). Lors de la défragmentation certains systèmes ne gèrent pas cette exception et cela entraîne un déni de service. Il existe des variantes de cette attaque : bonk, boink et newtear par exemple. Le déni de service Ping of Death exploite une mauvaise gestion de la défragmentation au niveau ICMP, en envoyant une quantité de données supérieure à la taille maximum d'un paquet IP. Ces différents dénis de services aboutissent à un crash de la machine cible.
Cette attaque utilise le protocole ICMP. Quand un ping (message ICMP ECHO) est envoyé à une adresse de broadcast (par exemple 10.255.255.255), celui-ci est démultiplié et envoyé à chacune des machines du réseau. Le principe de l'attaque est de spoofer les paquets ICMP ECHO REQUEST envoyés en mettant comme adresse IP source celle de la cible. Le pirate envoie un flux continu de ping vers l'adresse de broadcast d'un réseau et toutes les machines répondent alors par un message ICMP ECHO REPLY en direction de la cible. Le flux est alors multiplié par le nombre d'hôte composant le réseau. Dans ce cas tout le réseau cible subira le déni de service, puisque l'énorme quantité de trafic généré par cette attaque entraîne une congestion du réseau.
Les dénis de services distribués saturent le réseau victime. Le principe
est d'utiliser plusieurs sources (daemons) pour l'attaque et des
maîtres (masters) qui les contrôlent. Les outils de DDoS
(Distributed Denial of Service) les plus connus sont Tribal
Flood Network (TFN), TFN2K, Trinoo et Stacheldraht. La figure 13 montre un
réseau typique de DDoS :
Pic.13: Réseau DDoS
Le pirate utilise des maîtres pour contrôler plus facilement les sources. En effet, il a besoin de se connecter (en TCP) aux maîtres pour configurer et préparer l'attaque. Les maîtres se contentent d'envoyer des commandes aux sources en UDP. S'il n'y avait pas les maîtres, le pirate serait obligé de se connecter à chaque source. La source de l'attaque serait détectée plus facilement et sa mise en place beaucoup plus longue.
Chaque daemon et master discutent en échangeant des messages spécifiques selon l'outil utilisé. Ces communications peuventt même être cryptées et/ou authentifiées. Pour installer les daemons et les masters, le pirate utilise des failles connues (buffer overflow sur des services RPC, FTP ou autres). L'attaque en elle-même est un SYN Flooding, UDP Flooding ou autre Smurf Attack. Le résultat d'un déni de service est donc de rendre un réseau inaccessible.
Aujourd'hui, la sécurité contre les attaques à distance se renforce de plus en plus contrairement à la sécurité interne. Ce parent pauvre de la protection contre les pirates laisse encore de belles perspectives à des attaques en local comme le TCP Session Hijacking, l'ARP Spoofing et le DNS Spoofing. Par ailleurs, la prédiction de numéro de séquence (coeur de l'IP Spoofing) et les variantes de Fragments Attacks apparaissent uniquement à cause de bugs au niveau des OS des équipements réseaux. En ce qui concerne les attaques applicatives, elles ont encore de beaux jours devant elles grâce à la complexité sans cesse croissante des applications liées au Web et aux délais de plus en plus courts imposés aux développeurs et aux administrateurs. Quant aux dénis de service, ils seront toujours aussi redoutables dans leur forme distribuée tant que tout le monde ne sera pas sensibilisé à la protection de leur machine personnelle.