HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > IPv6: Les dangers du Routing Header Type 0
Accéder au : Site HSC des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|IPv6: Les dangers du Routing Header Type 0  

par Nicolas Collignon (27/02/2007)


----------[ IPv6 : Les dangers des "Routing Headers Type 0" ]-------------



This article is available in english at ipv6-rt0.html.en .



--[ 1. Introduction ]---------------------------------------------------

Cette brève présente les en-têtes de routage de type 0 du protocole IPv6
et leurs dangers.

Les en-têtes de routage, "Routing Headers" (RH) en anglais, sont une
extension au protocole IPv6 permettant d'altérer les mécanismes de
routage d'un paquet sur le réseau. Il en existe à ce jour (27/02/2007)
3 types.

Le type 0 permet de spécifier un ou plusieurs routeurs intermédiaires
pour le chemin aller d'un paquet.

Le type 1 a été réservé pour l'architecture réseau expérimentale Nimrod.
Nimrod est une architecture de routage distribuée où l'intelligence du
réseau est centralisée dans des sous-systèmes, pas forcement en rapport
avec la topologie du réseau. Les spécifications du type 1 des en-têtes
de routage sont obsolètes depuis janvier 1996.

Le type 2 est une version limitée du type 0, il permet de spécifier un
seul routeur intermédiaire. Dans la pratique, les RH de type 2 sont
utilisés pour la mobilité IPv6 (MIPv6) afin de spécifier l'adresse mère
(Home Address, HoA) de l'hôte mobile (Mobile Node, MN).

Cette brève évoque 4 menaces à considérer avec les en-têtes de routage:
 - le contournement d'ACL: IPv6 vers IPv6 et IPv6 vers IPv4 ;
 - l'évasion de périmètre ;
 - les problématiques de la facturation au volume ;
 - les possibilités d'optimisation d'un scan réseau.



--[ 2. Routing Headers Type 0 ]-----------------------------------------

Le concept est assez similaire au "source routing" IPv4 délaissé depuis
longtemps, principalement à cause de certaines problématiques de
sécurité.

Avec le "source routing" IPv4, il est possible de modifier le chemin d'un
paquet mais l'adresse de destination des paquets IPv4 reste fixe sur la
totalité du trajet, de l'émetteur au récepteur.
A contrario, avec les en-têtes de routage IPv6, l'adresse de destination
de l'en-tête IPv6 change après le passage dans chaque relais.

Évolution de l'adresse source (src), de l'adresse de destination (dest),
ainsi que la liste des routeurs intermédiaires du RH (RH) sur le chemin
d'un paquet:


        src: A                src: A               src: A
       dest: B               dest: C              dest: D
         RH: C, D              RH: D

  A  ----------------> B ----------------> C ---------------->  D

  ^                                                             |
  |                                                             |
  +-------------------------------------------------------------+
                            src: D
			   dest: A

Les RH sont une extension standard du protocole IPv6, ils possèdent une
structure très générique :



	0     8    16    24    32
      0 +-----+-----+-----+-----+  --> bits
	|  N  |  L  |  T  |  C  |
      4 +-----+-----+-----+-----|   N: extension suivante (ex: UDP)
	|                       |   L: taille de l'extension
	|  données spécifiques  |   T: type de RH
        |     au type de RH     |   C: nombre de relais restants
	|          ...          |
 octets v                       v



Ci-dessous, la structure d'un RH de type 0, le type le plus générique :


        0      8       16      24      32
      0 +-------+-------+-------+-------+
        |   N   |   L   |   0   |   C   |
      4 +-------+-------+-------+-------|
        |   0       0       0       0   |
      8 +-------------------------------+
        |                               |
        |    Adresse du routeur n°1     |

        |                               |
     24 +-------------------------------+
        |                               |
        |    Adresse du routeur n°2     |

        |                               |
     40 +-------------------------------+
        |              ...              |
        v                               v

Certaines implémentations de la pile IPv6 limitent le nombre de routeurs
intermédiaires utilisables dans un RH, d'autres permettent d'utiliser
autant de routeurs que possible tant que le paquet n'est pas fragmenté.

Le support du type 0 est obligatoire pour une implémentation qui
respecte l'intégralité de la RFC 2460, contrairement aux types 1 et 2.

Presque toutes (sinon toutes) les implémentations du protocole IPv6 ne
permettent pas l'utilisation d'en-têtes de routage avec le protocole
TCP. Seuls les protocoles UDP et ICMPv6 sont supportés.




--[ 3. Contournement d'ACLs ]-------------------------------------------

Toutes les méthodes de contournements d'ACL expliquées ci-dessous sont
basées du fait que l'adresse de destination stockée dans l'en-tête IPv6
n'est pas l'adresse de destination finale.
Il est nécessaire d'inspecter le contenu de l'en-tête de routage pour
identifier le destinataire final. Les différents cas d'ACL abordés par
la suite concernent uniquement des filtrages par l'adresse de
destination.




----[ 3.1 IPv6 vers IPv6 ]----------------------------------------------

Le premier cas étudié concerne le contournement d'un pare-feu qui filtre
en sortie les connexions à destination d'un serveur sur un réseau IPv6.
En utilisant un RH pour contacter le serveur, le client peut outrepasser
une règle de filtrage du pare-feu basée sur l'adresse de destination.
Quand le paquet est traité par le pare-feu, l'adresse de destination est
celle du relais, et non celle du serveur:


                               +--- Relais IPv6 ---+
                               |                   |
                               |                   v
   Client IPv6 --------> Pare-feu -----XX-----> Serveur IPv6

L'utilisation des Routing Header permet de contourner le pare-feu sur
le trajet aller des paquets mais le flux de retour (serveur -> client)
est filtré. Par contre si le serveur possède une pile IPv6 modifiée
où si son implémentation le permet, il est possible d'utiliser aussi
des Routing Headers pour les paquets réponses et ainsi de monter un tunnel
bidirectionnel pour contourner le pare-feu.

Dans ce cas, du point de vue du pare-feu, à aucun moment les paquets
en provenance:
 - du client n'ont pour adresse de destination celle du serveur
 - du serveur n'ont pour adresse de destination le client

         +--- Relais IPv6 ---+    +--- Relais IPv6 ---+
         |                   |    |                   |
         v                   v    v                   v
   Client IPv6 <----XX----> Pare-feu <----XX----> Serveur IPv6


----[ 3.2 IPv6 vers IPv4  ]---------------------------------------------

Les 2 versions du protocoles IP vont cohabiter un certain laps de temps
sur les réseaux d'entreprise. La mise en place de filtrage sur une
version du protocole IP doit prendre en compte les mécanismes de
cohabitation pour éviter des accès non autorisés.

Il existe de nombreux relais IPv6 vers IPv4 publiques et gratuits sur
Internet IPv6. C'est pourquoi mettre en place un filtrage de type
blacklisting sur certaines adresses IPv4 publiques est inutile si un
accès est autorisé sur l'internet IPv6.

Contournement d'une ACL IPv4 via un relais publique IPv6 vers IPv4:

                           6 +--- Relais IPv6/IPv4 ---+ 4
                             |                        |
                             v                        v
   Client IPv6 <--------> Pare-feu <----XX----> Serveur IPv4




--[ 4. Évasion de périmètre ]-------------------------------------------

On distingue 4 périmètres pour les adresses IPv6:
 - Node-Local  Limité à 1 hôte (localhost)
 - Link-Local  Limité au lien réseau
 - Site-Local  Périmètre large et administrable (ex: Intranet)
 - Global      Internet IPv6

En théorie, il n'est pas possible d'utiliser une adresse d'un périmètre
donné pour d'autres périmètres. Ce problème de périmètre existait déjà
avec IPv4 : il n'est pas possible de contacter une adresse IPv4 globale
avec une adresse du sous réseau 192.168.0.0/16.

La majorité des implémentations du protocole IPv6 se contentent de
vérifier qu'il n'y a pas d'adresses Multicast dans la liste des routeurs
avant de faire suivre les paquets. Par contre elles vérifient rarement
que toutes les adresses des routeurs appartiennent toutes au même
périmètre.

      Internet            Intranet       Lien        hôte
      [global]             [site]       [link]      [node]

   A ---------> Pare-Feu ---------> B ---------> C ::1

       2000::              fec0::       fe80::

Évidemment, il n'est pas possible de recevoir de réponse pour ce genre de
paquet car le destinataire:
 - essayera de répondre à une adresse dont le périmètre diffère de son
   adresse source et les routeurs ne laisseront pas passer les réponses
 - n'utilisera pas d'en-tête de routage (comportement par défaut).

Bien que l'évasion de périmètre semble peu intéressante si on ne peut
pas recevoir de réponse, elle illustre les effets de bord des en-têtes de
routage.
Si le destinataire final utilise lui aussi des RH pour répondre, alors
l'évasion de périmètre pose un réel problème de sécurité.




--[ 5. Surfacturation de trafic ]---------------------------------------

Pour certains types d'infrastructure réseau, la quantité de trafic émit
et reçu peut être facturée au volume de données ou à la durée des
communications.

Considérons un réseau:
  - avec N hôtes et un client malveillant
  - sur lequel une somme S est facturée par octet de données UDP émis.
  - avec un MTU permettant de stocker K relais dans l'en-tête de routage
    d'un paquet IPv6 sans fragmentation.
  
Un client malveillant pourrait utiliser les en-têtes de routage afin de
facturer N clients au lieu d'un seul, lui-même.

Facturation classique:
   Coût pour l'attaquant:   S
   Coût pour les N hôtes:   0

Surfacturation:
   Coût pour l'attaquant:   S
   Coût pour les N hôtes:   S x MAX(K, N)


      +--> Client B ----> Client C ----> Client D ---+
      |                                              |
      |                                              v
   Client A <------------------------------------- Serveur


La majorité des implémentations d'IPv6 n'inspectant pas le contenu du RH,
il est possible de générer des boucles de routage.

Le client A facture plusieurs fois les clients B et C:

              +----------+  ---->  +----------+
      +-----> | Client B |  <----  | Client C | ------+
      |       +----------+  ---->  +----------+       |
      |                                               v
   Client A <------------------------------------- Serveur


Par exemple, sur un réseau
  - de 4 clients (N=3)
  - avec une facturation de 1 centime d'euro par paquet envoyé (S=1)
  - avec la possibilité d'utiliser jusqu'à 23 routeurs intermédiaires. (K=23)

Coût pour l'attaquant       =>  1 centime
Coût effectif sur le réseau => 23 centimes  (S x K)




--[ 6. Accélération d'un scan ICMPv6 ]----------------------------------

La transparence du réseau est un objectif recherché par les créateurs du
protocole IPv6, il est donc relativement rare de voir des pare-feu IPv6
filtrant le protocole ICMPv6.

Il est possible d'optimiser un "ping" scan d'adresses IPv6 sur un réseau
où les hôtes IPv6 répondent au paquet ICMPv6 "Echo Request" en utilisant
les en-têtes de routage de type 0.

En effet au lieu de tester la présence d'un seul hôte par paquet
envoyés, il est possible de tester jusqu'à K adresses par paquet si le
MTU du réseau permet de stocker les adresses de K relais IPv6 dans
l'en-tête IPv6 sans fragmentation.

Supposons qu'un scanner souhaite détecter la présence des hôtes A, B et
C sur le réseau. Au lieu de simplement envoyer un ping à destination de
chaque machine, le scan peut être optimisé en rajoutant une liste de
routeurs intermédiaires avec une en-tête de routage type 0.

Ainsi:
  - si l'hôte A répond, les adresses de A, B et C sont valides
  - si un paquet ICMPv6 "Unreachable" est renvoyé, l'adresse de
    l'émetteur du paquet réponse est le dernier relais valide.

Ci-dessous, un ping vers A permettant de détecter la présence de B et C
sur le réseau:
                                  +------+  Host B
                                  ^      |
		                  |      v
     Scanner <--------> Routeur R +      +  Host C
                                  ^      |
			          |      v
                                  +------+  Host A

Dans ce cas:
  - si A répond "Echo Reply"  => A, B, C sont valides
  - si B répond "Unreachable" => B est valide
  - si C répond "Unreachable" => B, C sont valides
  - si R répond "Unreachable" => B est invalide




--[ 7. Filtrage ]-------------------------------------------------------

Ci-dessous, quelques règles de filtrage permettant de bloquer les
en-têtes de routage :


  * Cisco IOS < 12.2(15)T
    deny ipv6 any any routing

  * Cisco IOS>= 12.2(15)T
    no ipv6 source-route

  * Linux netfilter
    ip6tables -A INPUT -m rt --rt-type 0 -j DROP

  * ipf
    block in proto udp from any to any with v6hdrs routing


--[ 8. Conclusion ]-----------------------------------------------------

Les interprétations des RH dans les piles IPv6 sont assez différentes,
certaines piles sont très restrictives concernant la liste des routeurs
intermédiaires et le périmètre de leurs adresses. D'autres piles sont
au contraire très souples. Par exemple, la pile GNU/Linux permet de
contacter l'adresse localhost (::1) d'une machine distante via Internet.

A moins d'avoir une sérieuse raison d'utiliser les RH, il est
préferrable de les bloquer ou, au minimum, de vérifier que les adresses
des routeurs intermédiaires appartiennent toutes au même périmètre.

Avant de mettre en place un contrôle d'accès sur un réseau IPv6, il est
impératif de vérifier que les équipements de filtrage sachent inspecter
le contenu des en-têtes de routage ou qu'il puisse bloquer un type
d'extension IPv6 donné.


                  -- Nicolas Collignon <Nicolas(dot)Collignon(at)hsc.fr>


--[ 9. Références ]-----------------------------------------------------


 - RFC2460 - Internet Protocol Version 6
   RFC du protocole IPv6 et notamment du "Routing Headers Type 0".
   http://www.ietf.org/rfc/rfc2460.txt

 - draft-ietf-nimrod-rh1-00 - Nimrod Routing Header
   Draft obsolète depuis janvier 1996 sur le "Routing Header Type 1".
   http://www.ir.bbn.com/projects/nimrod/draft-ietf-nimrod-rh1-00.txt

 - RFC3775 - Mobility Support in IPv6
   RFC sur le support de la mobilité et le "Routing Header Type 2".
   http://www.ietf.org/rfc/rfc3775.txt

 - Deploying IPv6 Networks - Cisco Press
   ISBN 1-58705-210-5

 - IPv6 : Théorie de pratique - O'Reilly
   ISBN 284177337X
   http://livre.point6.net


Dernière modification le 27 mars 2007 à 13:49:00 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants