Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

La vérité sur l'attaque "VLAN hopping"

La vérité sur l'attaque "VLAN hopping"
2011-12-052013-02-11sécurité des réseauxfr
En résumé la victime reçoit des trames dans un VLAN qui n'est normalement pas accessible à l'attaquant. Mais, comme déjà indiqué, une réponse éventuelle de la victime ne parvient pas à l'attaquant. Cette attaque a donc un intérêt très...
Publié le 5 Décembre 2011 par Pascal Bonnard dans sécurité des réseaux
superman

Voilà un sujet qui n'est presque pas documenté en français. Tout au plus peut-on trouver des traductions automatiques depuis des sources en anglais qui sont loin d'être fiables.

cela commence avec la définition de l'attaque

DTP : pour certains auteurs, il s'agit de transformer une interface "access" en interface "trunk" à l'aide deDTP (Dynamic Trunking Protocol), déjà signalé comme "LA" faille. L'attaquant a accès à tous les VLAN connus du switch attaqué. Les conséquences sont innombrables, on peut difficilement imaginer pire.

Double-tag : pour d'autres auteurs, il faut avoir accès à une interface "trunk" et utiliser le "double tagging". Ceci permet d'envoyer des trames vers un équipement raccordé sur un autre trunk du switch. Les conséquences d'une telle attaque sont bien moins graves, car les réactions éventuelles de la victime ne sont pas retransmises sur l'interface de l'attaquant.

D'autres auteurs regroupent dans la définition à la fois le DTP et le Double-tag mais ils mettent en avant les conséquences du seul DTP.

Pour encore embrouiller le tout, on voit aussi trainer des textes de Camille la Bille pour expliquer que ses produits sont exempts de toute défaillance. Et bien sûr, des contributions qui reprennent ces textes...

un peu d'histoire...

Avant la normalisation dite Dot1q, il y avait des protocoles propriétaires pour faire la même chose. Ces protocoles propriétaires utilisaient des adresses mac spéciales. Le hardware des équipements était justement prévu pour examiner les adresses mac des trames, mais pas plus. Des constructeurs ont ensuite fait en sorte que leur machines puissent fonctionner avec le protocole propriétaire mais aussi avec le Dot1q. Dès lors, le hardware d’une interface "access" laissait entrer des trames Dot1Q (je ne sais pas avec quelles conséquences). A cette époque, Camille la Bille écrivait que cela couterait cher de modifier le hardware pour régler un problème qui n'existait pas avec le protocole propriétaire.

Ensuite, Camille la Bille à dit à son chef de produit qu'il fallait améliorer tout cela dans une nouvelle ligne de produits doté d'un hardware plus efficace. Camille la bille à confié le nouveau produit à un laboratoire de test indépendant chargé de vérifier qu'en aucun cas une trame Dot1q n'était acceptée par une interface "access", y compris avec du LAG et du Spanning Tree... Dès lors, Camille la Bille a cité ce rapport, avec la modestie qui convient, mais en soulignant que tous ses protocoles ne présentatient donc aucun risque.

A propos d'intrusion sur un VLAN , voyez le post de mon collègue Cédric  comment accèder au VLAN VoIP.  Vous trouverez, pour ajouter de la confusion,  certains auteurs sur la toile qui appellent aussi cela "vlan hopping", pourquoi pas ???  Et par curiosité, jetez un oeil sur mon post Etherpin, où je décris un "vlan hopping" qui marche très bien (en fait, qui marche parfaitement bien).

comprendre l'attaque par "double tagging"

Comme vous le savez, le VLAN natif permet d’assurer la compatibilité entre les trames Dot1Q et les trames Ethernet natives. Une trame Ethernet native est acceptée dans le VLAN Natif. Par défaut, elle est retransmise sans étiquette Dot1Q.

Mais, comme disait un Corse célèbre, un petit dessin vaut mieux qu'un long discours… Alors voilà comment ça marche.

attaque par double tagging

En résumé la victime reçoit des trames dans un VLAN qui n’est normalement pas accessible à l’attaquant. Mais, comme déjà indiqué, une réponse éventuelle de la victime ne parvient pas à l’attaquant. Cette attaque a donc un intérêt très limité.

A noter qu’on trouve sur la toile de nombreuses explications fantaisistes du fonctionnement de l’attaque. Il est souvent dit que SW1 supprime l’étiquette VLAN1 de la trame qui vient de l’attaquant. Cette erreur provient à l’origine d’un texte de Camille la Bille, qui avait écrit quelque chose comme « The first tag (which corresponds to the VLAN that the attacker is really a member of) is stripped off by a first switch the packet encounters, and the packet is then forwarded.» (cité depuis en.wikipedia.org). Comme si un switch allait dévétir une trame de son vlan ... Un jour peut-être j’irais rectifier ce wiki.

Docteur Ethernet vous salue bien !!!

credit images : © julien tromeur et © 3nko - fotolia.com

4 Commentaires

  • 4 Janvier 2012
    2012-01-04
    par
    Pascal
    @Willy
    Merci pour ce commentaire.
    Quand on fait du routage sur un Catalyst, il faut prendre un minimum de précautions: mettre les ACL qui vont bien au lieu de configurer des IP@ vite fait mal fait.
    Pour le reboot, je confirme, il peut y avoir des surprises, du genre un BPDU qui s'échappe, et l'équipement d'en face qui bloque le port.
  • 14 Décembre 2011
    2012-01-04
    par
    Willy
    Bonjour Pascal,

    je suis content de voir un article là-dessus. Ca fait 10 ans que je fustige les gens qui ont un VLAN natif valide sur les ports trunk exactement pour cette raison, mais la précipitation et la flemme l'emportent toujours sur la sécurité.

    Il y a d'autres méthodes pour faire du VLAN hopping, notamment avec les switches qui possèdent une adresse IP dans différents VLAN. Il suffit alors de spoofer l'IP d'un serveur à scanner dans l'autre VLAN et d'envoyer un SYN vers un port qui répond sur le switch (ex: 22 ou 23). Le switch va vouloir répondre alors le SYN/ACK de l'autre côté, mais pour ça va devoir faire une requête ARP d'abord. S'il n'a pas de réponse, il n'enverra pas son paquet. Selon les stacks IP employées, on peut alors regarder les ID IP générés par le switch (ex: en réponse à un ping) pour savoir si un paquet a été émis de l'autre côté entre temps ou pas, et déterminer de ce fait si l'IP qu'on a spoofée existe ou non.

    Enfin une autre piste est de provoquer un reboot du switch, ce qui est parfois possible notamment sur des floods de broadcasts ou de multicasts, vu que les mises à jour ne sont jamais effecutées sur ce type d'équipement. Bien souvent quand un switch reboote, tous les ports son grands ouverts dans le VLAN1 pendant les quelques secondes que le switch met à charger sa conf, et on peut alors communiquer librement avec les voisins. Pendant un court instant. Ca ne passe pas inaperçu toutefois !

  • 5 Décembre 2011
    2012-01-04
    par
    Pascal
    @Michal:
    Ha, je vois qu'il y a des connaisseurs !! En fait, je recommande de déclarer en Vlan natif un Vlan qui n'est pas utilisé ailleurs dans le switch. De la sorte, il n'y a pas de fuite possible. Quant au STP, je fais en sorte de ne pas en avoir besoin. Voir à ce sujet mes autres posts.
  • 5 Décembre 2011
    2012-01-04
    par
    Michal
    Hello Pascal , intéressant et content de voir des articles ce ce genre sur le blog d'OBS. Concernant le "native VLAN" on peut avoir des résultats intéressants quand le CDP est désactivé au niveau du lien trunk entre deux switches. Avec le CDP désactivé,  meme si le native VLAN-id est différent des deux cotés le lien trunk monte sans problème malgré tout et une fuite de trafic inter-vlan peut avoir lieu facilement , d'ou aussi l'intérêt de tagger le native VLAN. Par contre le tagging de native VLAN a du sens si c'est fait dans toute de la topologie ethernet. Mais dans ce cas le tagging de "VLAN native" peut aussi poser des problèmes au niveau du forwarding de certains messages BPDU du PVSTP+ ou MSTP qui eux sont parfois envoyer non-tagges ( p.ex. en fonction de la version du code utilisée )  et surtout quand on a un environnement multi-constructeurs. 
    Cordialement ,  Michal

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage