3psilon website

Sommaire

 - Présentation
 - Fragments attacks
 - Tiny Fragments
 - Fragment Overlapping
 - IP Spoofing
 - TCP Session Hijacking
 - ARP Spoofing
 - DNS Spoofing
 - DNS ID Spoofing
 - DNS Cache Poisoning

---

Présentation

Comprendre les attaques pour mieux se défendre.

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.

Fragments attacks

Cette attaque outrepasse la protection des équipements de filtrage IP.

Pour sa mise en pratique, les pirates utilisent deux méthodes : les Tiny Fragments et le Fragment Overlapping. Ces attaques étant historiques, les pare-feux actuels les prennent en compte depuis longtemps dans leur implémentation.

Tiny Fragments

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 :

Fragment Overlapping

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 :

IP Spoofing

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 Source Routing : le protocole IP possède une option appelée Source Routing autorisant la spécification du chemin que doivent suivre les paquets IP. Ce chemin est constitué d’une suite d’adresses IP des routeurs que les paquets vont devoir emprunter. Il suffit au pirate d’indiquer un chemin, pour le retour des paquets, jusqu’à un routeur qu’il contrôle. De nos jours, la plupart des implémentations des piles TCP/IP rejettent les paquets avec cette option ;

  Le Reroutage : les tables des routeurs utilisant le protocole de routage RIP peuvent être modifiées en leur envoyant des paquets RIP avec de nouvelles indications de routage . Ceci dans le but de rerouter les paquets vers un routeur que le pirate maîtrise.

Ces techniques ne sont plus (ou difficilement) utilisables : l’attaque est donc menée sans avoir connaissance des paquets émis par le serveur cible.

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 :

  détermination de l’adresse IP de la machine de confiance en utilisant par exemple showmount -e qui montre où sont exportés les systèmes de fichiers ou rpcinfo qui apporte des informations supplémentaires ;

  mise hors service de l’hôte de confiance via un SYN Flooding par exemple (nous aborderons les dénis de service plus loin dans cet article). Cela est nécessaire pour que la machine ne puisse pas répondre aux paquets envoyés par le serveur cible. Dans le cas contraire elle enverrait des paquets TCP RST qui mettraient fin à l’établissement de la connexion ;

  prédiction des numéros de séquence TCP : à chaque paquet TCP est associé un numéro de séquence initiale. La pile TCP/IP du système d’exploitation le génère de manière linéaire, dépendante du temps, pseudo-aléatoire ou aléatoire selon les systèmes. Le pirate peut uniquement appliquer cette attaque à des systèmes générant des numéros de séquence prévisibles (génération linéaire ou dépendante du temps) ;

  l’attaque consiste à ouvrir une connexion TCP sur le port souhaité (rsh par exemple). Pour une meilleure compréhension, nous allons rappeler le mécanisme d’ouverture d’une connexion TCP. Elle s’effectue en trois phases (TCP Three Way Handshake) :

1. l’initiateur envoie un paquet comportant le flag TCP SYN et un numéro de séquence x, est envoyé à la machine cible ;
2. cette dernière répond avec un paquet dont les flag TCP SYN et ACK (avec un numéro d’acquittement de x+1) sont activés. Son numéro de séquence vaut y ;
3. l’initiateur renvoie un paquet contenant le flag TCP ACK (avec un numéro d’acquittement de y+1) à la machine cible.

Lors de l’attaque le pirate ne reçoit pas le SYN-ACK envoyé par la cible. Pour que la connexion puisse s’établir, il prédit le numéro de séquence y afin d’envoyer un paquet avec le bon numéro de ACK (y+1).

La connexion s’établit alors grâce à l’authentification par l’adresse IP. Le pirate peut donc envoyer une commande au service rsh pour obtenir des droits supplémentaires, comme 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 :

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.

TCP Session Hijacking

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 :

• le port source et le port destination, pour identifier la connexion entre deux machines ;
• le numéro de séquence qui identifie chacun des octets envoyés ;
• le numéro d’acquittement qui correspond au numéro d’acquittement du dernier octet reçu ;
• les flags, avec ceux qui vont nous intéresser sont :
  • SYN qui synchronise les numéros de séquence lors de l’établissement d’une connexion ;
  • le flag d’acquittement d’un segment TCP ;
  • PSH qui indique au récepteur de remonter les données à l’application.

La figure 8 schématise l’établissement d’une connexion TCP (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 : Échanges de données

Les numéros de séquence vont évoluer en fonction du nombre d’octets de données envoyées. 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.

ARP Spoofing

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 :

Le pirate lance alors ARPSpoof :
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 :

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 :
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).

DNS Spoofing

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.

DNS ID Spoofing

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 :

  essayer toutes les possibilités du champ ID. Cette méthode n’est pas très réaliste puisqu’il y a 65535 possibilités pour le champ ID (car ce champ est codé sur 16 bits) ;
  envoyer quelques centaines de requêtes DNS dans l’ordre. Cette méthode est bien évidemment peu fiable ;
  trouver un serveur qui génère des ID prévisibles (incrémentation de 1 de l’ID par exemple), ce genre de faille existe sur certaines version de Bind ou des machines Windows 9x.

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 :

1. l’attaquant envoie une requête DNS pour le nom www.attaquant.com au serveur DNS du domaine cible.com comme le montre la figure 11 ;

1. le serveur DNS cible a donc relayé la demande au DNS du domaine attaquant.com ;

1. l’attaquant est capable de sniffer la requête pour récupérer son ID (dans notre exemple l’ID a une valeur de 100) ;

1. l’attaque falsifie l’adresse IP associée à un nom de machine, ici la machine victime est 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’autre requête et donc incrémenté son ID DNS. La figure 12 détaille cette étape.

Le cache du serveur DNS cible est donc corrompu, et la prochaine machine demandant une résolution du nom 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.

DNS Cache Poisoning

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 :

  envoyer une requête DNS de résolution du nom www.attaquant.com au serveur DNS du domaine cible.com ;
  Le serveur DNS cible envoie donc une requête portant sur une résolution du nom www.attaquant.com au serveur DNS de l’attaquant ;

  Le serveur DNS de l’attaquant enverra une réponse avec des enregistrements falsifiés qui permettront d’assigner un nom de machine avec une adresse IP appartenant à l’attaquant. Par exemple, le site www.cible.com pourra avoir un enregistrement DNS falsifié renvoyant l’adresse IP de www.attaquant.com au lieu de la bonne adresse IP.