wikinotes

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>cours informatique sécurité réseau}}

====== Menaces sur la couche réseau ======

Notes et transcriptions du cours [[cours:informatique:securite:securite_des_reseaux:000_start|Sécurité des Réseaux Informatiques]] proposé par **MinesTelecom** sur la plateforme **FUN-MOOC**.

**Semaine 1 : Menaces liées au réseau** -> **Menaces sur la couche réseau**.

===== Objectif =====

  * Connaître les vulnérabilités associées à la couche réseau
  * 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 IPv4 =====

Rappelons les 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 schématisée ci-dessous.

{{entete_ip.png}}

Illustrons un envoi de paquet IP de A.B.C.1 vers X.Y.Z.2.

{{envoi_paquet_ip_01.png}}

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.

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 (X.Y.Z.2), le paquet doit être envoyé vers E.F.G.2, ce qu’il fait alors.

{{envoi_paquet_ip_02.png}}

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 ou 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 qualifié de **best effort**.

La fiabilité est habituellement assurée par la couche transport, avec le protocole TCP par exemple.


===== Menaces sur la couche IP =====

==== DoS par reflexion ====

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 sur le schéma ci-dessous où l’attaquant ayant l'adresse IP A.B.C.D envoie un paquet avec comme adresse IP source W.X.Y.Z.

{{ip_spoofing.png}}

L’intérêt de cette attaque peut sembler limité de prime abord 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 (DoS) que l’on qualifiera d’attaque par réflexion et amplification. 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.

==== DoS par fragmentation ====

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;
  * 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.

{{dos_fragmentation.png}}

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**((**M**aximum **T**ransmission **U**nit)) 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.

==== IP spoofing sur la destination ====

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 de l' adresse de diffusion (broadcast) ou du 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 =====

**ICMP** est un protocole de diagnostic définit par la RFC 792 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.

{{entete_icmp.png}}

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

{{icmp_echo_request.png}}

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 tente de communiquer avec W.X.Y.Z. 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.

{{icmp_dest_unreachable.png}}

===== 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**((**T**ime **t**o **L**ive)) 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.

Également, 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.

On a vu également 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 peut être utilisé à des fins de reconnaissance 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 cependant être combiné avec 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.

{{ping_flooding.png}}

L’IP spoofing peut s'appuyer sur l'adresse de 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.

{{ping_flooding_broadcast.png}}

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 abordons 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é.

{{icmp_redirect_01.png}}

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.

{{icmp_redirect_02.png}}

==== 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 ou 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.

{{icmp_redirect_03.png}}

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 cet exemple, voici le message ICMP Redirect que l’attaquant 192.168.1.100 doit envoyer.

{{icmp_redirect_04.png}}

Si on regarde d’un plus près sa composition, on remarque que ce message ICMP est encapsulé dans un paquet IP (entête IP au dessus) 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 192.168.1.100.

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 la 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. L'attaquant doit donc indiquer comme adresse source l'adresse du routeur 192.168.1.10, l’IP spoofing permet de le faire.

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 délicat, c’est la dernière partie qui correspond à un paquet envoyé par la victime elle-même (le paquet initial ayant généré l'ICMP Redirect). Cette dernière pourra donc le vérifier.

Premièrement les adresses IP: on retrouve la victime comme adresse source (192.168.1.1) et la cible comme adresse destination (192.168.2.1).
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 (hote destination à mettre à jour). 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 initier un paquet pouvant avoir une réponse cohérente et prédictible. Il va donc usurper l’adresse IP de la cible pour envoyer un message à la victime (un ICMP echo request dont la réponse est prédictible). La victime y répondra alors et c’est cette même réponse prévue 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é.

{{icmp_redirect_05.png}}

En effet, il faut reconstruire la réponse 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é

Au final, 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.
wikinotes

Outils pour utilisateurs

Outils du site

Outils de la page
