S1.

L2
Menaces sur la couche liaison
Jérôme FRANCOIS

Bonjour,

Les objectifs

L’objectif de ce cours est d’une part de connaître les vulnérabilités associées à la couche réseau et de
comprendre comment celles-ci peuvent être exploitées pour mener une attaque impactant les
fonctionnalités réseaux et ainsi les machines qui y sont connectées.

Le protocole Internet (IPv4)

Nous voyons sur l'écran un rappel des fondamentaux du protocole IP dans sa version 4, la plus
couramment utilisée. Nous n’aborderons pas la version 6. Contrairement à la couche MAC qui permet
de transférer des trames entre des nœuds adjacents, c’est-à-dire sur le même lien local, IP permet aux
nœuds situés dans différents réseaux et domaines de communiquer. Il offre donc un adressage global
à Internet que l’on retrouve au niveaux des adresses source et destination de l’entête ici.

Ainsi sur cet exemple A,B,C,1 veut envoyer un paquet IP à X,Y,Z,2. Pour ce faire, il doit passer par
deux routeurs intermédiaires et le paquet est envoyé à chaque nœud suivant grâce à une table de
routage.
Par exemple, A.B.C.1 l’envoie d’abord vers le premier routeur qui est configuré comme sa passerelle
par défaut. Ce dernier regarde alors dans sa table de routage et voit que pour atteindre le sous réseau
X.Y.Z.0/24 auquel appartient la destination, le paquet doit être envoyé vers E.F.G.2, ce qu’il fait alors.

A la réception du paquet, ce dernier routeur remarque que la destination est sur un même sous réseau
dont il fait partie, il le transmet donc directement sur le réseau local (au niveau 2), en spécifiant
l’adresse MAC associée à l’adresse IP de la destination.

Tout au long de ce cheminement, les adresses IP ne sont pas modifiées. Cependant, la taille des
données émises dépend des contraintes des couches inférieures et le paquet peut dont être amené à
être fragmenté.

On retrouve alors cette information au niveau de l’entête.

Concernant les tables de routages, elles peuvent être construites de manière statique soit
automatiquement par des protocoles de routage comme RIP ou OSPF mais cela n’est pas l’objet du
cours. Enfin, en termes de fiabilité, seule une somme de contrôle ou checksum permet de vérifier
l’intégrité de l’entête d’un paquet à sa réception. Aucun mécanisme n’existe au niveau de la source
pour s’assurer de sa bonne transmission ou au niveau de la destination pour redemander une
transmission d’un paquet ou d’un fragment manquant. On est dans un mode dit de best effort. La
fiabilité est habituellement assurée par la couche transport, avec le protocole TCP par exemple.

Les menaces portant sur la couche IP

L’entête IP n’est pas protégé des modifications arbitraires. Il est possible de créer un paquet quel qu’il
soit ou d’en modifier un existant, il restera juste à recalculer alors le checksum. Une des attaques les
plus basiques que l’on nomme IP spoofing consiste simplement à usurper une adresse IP en l’utilisant
comme adresse source.

C’est ce que l‘on voit ici où l’attaquant envoie un paquet avec comme adresse IP source W.X.Y.Z.
L’intérêt de cette attaque peut sembler limité puisque l’attaquant ne recevra pas les réponses en retour.
Plus généralement cela ne lui permet pas de recevoir le trafic à destination de l’adresse usurpée.
Cependant, cela lui permet de cacher sa véritable adresse IP notamment lorsque les paquets
contiennent une charge malveillante. Ainsi il peut difficilement être localisable et filtré. De plus,
même si l’attaquant ne reçoit pas la réponse, celle-ci est bien envoyée à l’hôte usurpé. C’est donc un
moyen indirect pour atteindre ce dernier, par réflexion. En choisissant bien le type d’application visée,
il est notamment possible de faire en sorte que la réponse générée soit bien plus volumineuse que la
requête voire engendrer un grand nombre de réponses à une seule requête.

Indirectement cela peut surcharger le réseau et l’hôte usurpé en créant ainsi une attaque par déni de
service que l’on qualifiera d’attaque par réflexion et amplifiée. L’efficacité de ce type d’attaque
dépend fortement des protocoles utilisés dans les couches supérieures. Par exemple, une unique
requête DNS engendre de nombreux échanges entre différents serveurs, ce qui fait de ce protocole,
souvent non filtré, un candidat idéal pour les attaquants.

La deuxième attaque introduite ici repose sur la fragmentation. En effet, la fragmentation suppose la
nécessité de reconstruire le paquet initial car les fragments peuvent arriver dans le désordre.
Cependant, cette reconstruction peut échouer pour différents raisons : s’il manque des parties si les
fragments se superposent voire si l’ensemble reconstruit est finalement plus grand que la taille du
paquet indiquée dans l’entête IP.

Dans cet exemple, il manque le second fragment et le dernier fragment dépasse le taille globale du
paquet.
Une implémentation du protocole qui oublierait de gérer ces exceptions serait donc encline à des
problèmes de fonctionnement et donc à une attaque par déni de service. C’est une attaque plutôt
ancienne qui est en principe justement bien gérée au niveau des implémentations mais qui parfois
refait surface avec des nouvelles mises à jour de système. De manière générale, on conseille
également de considérer un MTU (Maximum Transmission Unit) de 1500 octets correspondant à
Ethernet et qui évitera dans la plupart des cas le recours à la fragmentation. Cependant on ne peut
garantir que le paquet ne sera jamais fragmenté car on ne maîtrise pas le chemin que prendra le paquet
IP.

Enfin, il est également possible d’utiliser n’importe quelle adresse destination et notamment énumérer
toutes les possibilités au sein d’un sous réseau IP voire Internet. L’utilisation d’une adresse de
diffusion en broadcast ou en multicast facilite cela également. Cela permet de contacter rapidement
un grand nombre d’hôtes pour, par exemple, faire un scan avec ICMP, que l’on verra juste après, à
large échelle.

Le protocole ICMP (Internet Message Control Protocol)

ICMP est un protocole de diagnostic que l’on qualifie généralement de niveau 3 même s’il s’exécute
au dessus d’IP. L’entête ICMP est assez simple puisque l’on retrouve un type et un code qui détermine
l’opération de diagnostic ou le code de retour. On peut retrouver de l’information complémentaire
dans les options et même ajouter des données. En termes de fiabilité, seul un checksum est une fois
de plus calculé.

Nous ne rentrons pas ici dans les détails des fonctionnalités d’ICMP mais reprenons quelques unes
des plus classiques, notamment dans un contexte de sécurité. La première est le fameux ping. Cela
consiste pour une machine à envoyer un message echo request, type 8 code 0. Si l’hôte en face
désigné par son adresse IP est atteignable alors ce dernier va répondre avec un echo reply (type 0,
code 0).

Il est également possible d’ajouter des données dans l’echo request que l’echo reply doit retourner
intacte.

Un message ICMP de type 3 est une erreur informant de la non accessibilité d’un hôte. Dans
l’exemple ici, la machine A.B.C.D communique avec W.X.Y.Z.

Si celle-ci disparaît et que le paquet IP est transmis jusqu’au dernier routeur à droite, alors celui-ci
informe qu’il ne connaît pas de route vers W.X.Y.Z et donc que cette dernière n’est pas joignable
Une variante est lorsque le sous-réseau lui-même n’est plus accessible. Dans ce cas le code est 0 et le
type toujours 3.

Les menaces portant sur ICMP

Quel rapport entre ICMP et la sécurité ? Tout d’abord ICMP est un protocole de diagnostique qui
permet de récupérer des informations opérationnelles sur le statut d’un réseau. Il est clair que ces
informations peuvent être également utilisées par un attaquant pour forger au mieux son attaque. Par
exemple, un simple ping permet à l’attaquant de découvrir si oui ou non une machine est accessible.
En combinant cela avec une énumération systématique des adresses IP (ou ping sweep) on peut donc
avoir une vue des machines actives et donc ensuite les viser par une attaque.

Traceroute est un outil qui utilise ICMP pour identifier la route, c’est-à-dire les nœuds intermédiaires,
vers une destination. Rappelons que le champ TTL de l’entête IP est un compteur qui décroît à chaque
saut et qui lorsqu’il arrive à 0 permet de jeter le paquet et évite ainsi qu’il puisse continuer à être
transmis indéfiniment.

Pour réaliser un TraceRoute, une succession d’echo requests avec un TTL (Time-to-Live) croissant
permet de recevoir des messages d’erreur de la part des nœuds où les messages echo requests ont
expiré. Selon le système ou l’outil utilisé, on peut trouver différentes variantes comme l’envoi de
messages UDP, plutôt qu’ICMP echo request, mais résultant toujours par l’envoi d’erreurs ICMP
lorsque les paquets expirent. Connaître les chemins utilisés apporte également une aide précieuse à
un attaquant. Par exemple, ce dernier peut préférer lancer une attaque par déni de service vers un
routeur intermédiaire au cœur d’une topologie. Il impactera ainsi un plus grand nombre de machine
dont le trafic passe par ce dernier. Egalement, en regardant la valeur du TTL retournée, on est capable
de connaître quel est le type de machine qui a répondu en devinant le TTL d’origine de l’echo reply.
C’est une technique de fingerprtinting ou prise d’empreinte. Lors d’un traceroute, on peut également
repérer des sauts cachés, c’est-à-dire des machines, tels que des firewalls, qui volontairement ne
répondent pas aux paquets qui expirent mais les ignorent.

Aussi, on a vu que l’on peut insérer des données dans certains messages ICMP, comme par exemple
dans un echo request. Cela est un moyen pour un attaquant de transmettre plus ou moins discrètement
des données dans un canal de communication auxiliaire.

ICMP peut également indirectement fermer une connexion TCP par exemple si un hôte n’est plus
joignable. Habillement utilisé par un attaquant, il peut en résulter une attaque de déni de service et je
vous laisse consulter le RFC 5927 pour plus de détails.
Le ping est utile à des fins de reconnaissances mais aussi dans le cadre d’un déni de service par
inondation ou flooding.

Dans le cas le plus simple, l’attaquant envoie un grand nombre d’echo request à la victime. Cependant
il recevra aussi les réponses le surchargeant à son tour.

Il peut être plus habile en utilisant l’IP spoofing. Dans ce cas les réponses sont envoyées à l’adresse
IP usurpée, qui sera alors aussi sujette à l’attaque par déni de service.

Encore mieux, il peut combiner l’IP spoofing avec le broadcast. Ainsi de nombreuses machines
recevront le ping et y répondront en envoyant un echo reply vers l’adresse usurpée, qui est en fait
véritablement la victime de l’attaque par inondation.

Cette attaque nommée SMURF est assez ancienne. En fait, beaucoup des attaques basées sur ICMP
ne sont plus efficaces tant que des bonnes pratiques sont appliquées. En principe, une grande partie
du trafic ICMP est bloqué en entrée d’un réseau et les broadcasts sont souvent bloqués également. Il
est également conseillé que les paquets IP sortant d’un réseau aient une adresse IP dans l’espace des
adresses routées par les routeurs de ce réseau… malheureusement cette dernière recommandation est
encore rarement appliquée.

ICMP Redirect

Nous voyons ici une autre fonctionnalité d’ICMP : la fonction Redirect. Dans l’exemple proposé,
l’hôte 192.168.1.1 envoie un paquet à 192.168.2.6. Celui-ci est donc transféré selon les tables de
routage hors 192.168.1.1 n’a connaissance que de sa passerelle par défaut à qui le paquet est envoyé.
Celle-ci route alors le paquet vers le routeur 192.168.1.10 qui dispose également d’une interface en
192.168.2.1 vers le réseau local où se trouve la destination finale. Cela fonctionne mais on se rend
compte que le chemin traversé n’est pas optimal. En effet, la source, 192.168.1.1 étant dans le même
sous-réseau que le routeur en bas de la figure, il aurait pu lui envoyer directement.

Sa passerelle par défaut va ainsi le lui informer en envoyant un message ICMP redirect (type 5 code
1). Ce dernier spécifie que l’hôte 192.168.2.6 est joignable par un chemin plus direct, via
192.168.1.10.
Les prochains paquets prendront alors directement ce chemin.

L’attaque ICMP Redirect

Comme un attaquant peut lui aussi envoyer des paquets ICMP redirect, il est possible pour ce dernier
de rediriger le trafic vers un hôte de son choix qui pourra agir comme un simple trou noir et donc
faire un déni de service. Il peut au passage regarder le contenu des paquets jetés. Pire encore il peut
réaliser une attaque de type Man-in-the-Middle en interceptant silencieusement le trafic tout en
continuant à router les paquets vers la destination finale. Cette attaque sera d’autant plus intéressante
si elle peut être menée dans les deux sens de la communication. Ainsi, l’ensemble de la
communication sera interceptée.

Dans l’exemple de droite, voici le message ICMP Redirect que l’attaquant 192.168.1.100 doit envoyer.
Si on regarde d’un plus près sa composition, on remarque que ce message ICMP est encapsulé dans
un paquet IP (en haut) et contient également une partie du paquet IP d’origine. Celui-ci correspond
au paquet qui a entraîné l’erreur (celui initialement envoyé). On le retrouve partiellement avec d’une
part son entête IP complète et les 8 premiers octets après celle-ci. Un attaquant doit donc remplir
l’ensemble de ces champs de manière correcte. En effet, la moindre erreur pourrait invalider son
message ICMP Redirect qui n’aurait alors aucun effet.

Commençons par l’entête ICMP c’est la plus simple.

Suivant la spécification, l’attaquant doit donc définir le type à 5 et le code à 1, il précise aussi une
nouvelle passerelle à utiliser, dans le cas ici, lui-même. Ensuite, l’entête IP qui correspond au paquet
qui contient le message ICMP redirect.

L’adresse de destination est la victime à qui l’on veut changer sa route. Seule petite difficulté, il est
usuel aujourd’hui de n’autoriser ces messages que de la part de la ou des passerelles déjà existantes.
Pas très compliqué, on a vu comment faire, l’IP spoofing règle ce problème. Pour le reste de l’entête
c’est assez direct, le champ protocole est positionné à ICMP, la version IP à IPv4, on calcule les
différentes tailles et checksum. En fait ce n’est pas compliqué car l’émetteur de ce message est
l’attaquant lui-même qui se fait passer pour la passerelle par défaut.

Ce qui est plus dur, c’est la dernière partie qui correspond à un paquet envoyé par la victime elle-
même. Cette dernière pourra donc le vérifier. Premièrement les adresses IP, c’est assez simple. On
retrouve ici la victime comme adresse source et la cible comme adresse destination.
La cible est l’hôte pour lequel on veut rerouter le trafic lorsque la victime le contactera. On remarquera
d’ailleurs que l’entête ICMP elle-même ne reprécise pas cette information. Cette partie est donc bien
utile à la victime pour mettre à jour sa table de routage. Par contre, pour le moment aucune idée des
8 octets à rajouter ici ou du reste de l’entête du paquet IP inclus dans la réponse ICMP

Un problème majeur ici, c’est que cela suppose que la victime ait envoyé un paquet à la cible. Sans
quoi le message ICMP redirect n’a pas de sens et sera donc invalidé au niveau de la victime.
L’attaquant doit donc au préalable déclencher ce paquet. Il va donc usurper l’adresse IP de la cible
pour envoyer un message à la victime, celle-ci y répond alors et c’est cette réponse que l’on doit
retrouver dans notre message ICMP. Il faut donc que l’on complète l’ensemble des champs, le plus
simple la version du protocole IP, ici en IpV4 mais pour le reste c’est un peu plus compliqué.

En effet, il faut deviner quelle réponse a pu être envoyée par la victime. Il faut donc choisir un message
dont on arrive à prédire plus ou moins certainement la réponse engendrée. Rappelons qu’un paquet
IP n’engendre pas de réponse en soi et qu’il faut donc qu’il encapsule un protocole de plus haut niveau.
Si on prend TCP ou UDP pour générer la requête, nous devons spécifier le port de destination. Selon
l’état du service associé, la réponse différe. Plus simplement, la réponse à une requête ICMP request
(ICMP reply) est déterministe si la destination (dans notre cas la victime) est active. En effet, lorsque
l’attaquant va envoyer un ICMP echo request (ici à gauche) à la victime en usurpant l’adresse de la
cible on retrouve dans la réponse les informations suivantes:
- Type 0 code 0 par spécification
- Une copie conforme de la partie identifier, sequence number, data
- le checksum qui pourra alors être calculé
- Nous avons alors les 8 octets à rajouter

Reprenons donc dans le message ICMP redirect la partie qui nous manque :
on retrouve la version v4 pour IP, une taille d’entête à 5 qui est la plus courante (cad sans option), le
type of service à 0 car d’après le RFC 1349 tout message ICMP d’erreur doit avoir cette valeur, le
protocole ICMP.

Pour la partie fragmentation, celle-ci peut être modifiée au cours du routage du paquet car la
fragmentation peut être dû à un lien intermédiaire. La machine victime ne peut donc l’utiliser pour
vérifier qu’il s’agit bien du paquet qu’elle a envoyé. Ici on a simplement indiqué qu’il n’y avait pas
de fragmentation et on utilise un numéro d’identification aléatoire, mais sans aucun impact.
Une fois que tout ça est rempli, on peut calculer la taille totale du paquet et le checksum.
On voit alors qu’un attaquant peut tout à fait forger l’ICMP redirect en incluant la partie IP du message
qui a engendré l’erreur sans l’avoir observé. Il lui a juste fallu envoyer en premier lieu un paquet
ICMP echo request déclencheur pour lequel le contenu de l’echo reply est déterminable à l’avance.