Cas pratique - Sécurité de la couche 2

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.
====== Vulnérabilités de la couche 2 ======

===== Introduction =====

Si notre réseau initial comportait des concentrateurs((https://fr.wikipedia.org/wiki/Hub_Ethernet)) à la place des commutateurs, l'ensemble des données seraient transmises sur tout le réseau quelles que soient les sources et destinations. Il serait trivial de capturer l'intégralité des paquets en écoutant passivement le réseau (//sniffing//) au moyen de logiciel comme [[http://www.tcpdump.org/|tcpdump]]. \\ 

Nous allons voir dans ce chapitre comment capturer et rejouer des paquets qui ne nous sont pas destinés à travers le réseau de l'entreprise Corporate. 
\\

----

===== ARP: fonctionnement =====
==== Coté hôtes ====
Exécutons la commande ''arp'' depuis un ordinateur (linux) : 
{{ :ppe:layer2:arpcmd.png?nolink&550 |}} \\
On peut voir les adresses IP correspondant aux adresses MAC des interfaces de deux hôtes sur le réseau. 

Initialement, cet ordinateur ne connaît pas l'adresse physique de celui qu'il veut contacter, il va donc émettre une trame de diffusion. L'hôte concerné répondra avec une trame à destination du demandeur. \\
Voici un exemple de trame ARP : 
{{ :ppe:layer2:tramearp.png?nolink&550 | source : Wikipédia }}

Une fois que l'hôte de départ connaît l'adresse physique du destinataire, il rajoute cette entrée dans son cache ARP. \\
==== Côté commutateur ====
De son côté, le commutateur tient à jour une table d'adresses MAC correspondant aux ports sur lesquels sont branchés les interfaces des hôtes. Cet aspect sera abordé dans le chapitre suivant et va nous permettre de sécuriser en partie notre réseau en contrôlant l'association adresse MAC - port. 

===== Usurpation =====

Démontrons qu'on peut facilement se faire passer pour celui qu'on n'est pas : nous allons usurper l'identité d'un hôte et d'un serveur afin de capturer les données qu'ils s'échangent. 

==== Contexte ==== 

Reprenons notre réseau initial et intéressons nous au directeur de l'entreprise CORPORATE qui consulte le site "Facebouc", fameux réseau social d'entreprise situé à l'adresse [[http://sio.pqd.fr/sitetest/|http://srv-web.corpora.te]] accessible uniquement depuis le réseau local. 

Schématiquement nous avons : 
{{ :ppe:layer2:schemaweb.png?nolink |}}
\\
<note important>Pour des raisons de praticité des manipulations qui vont suivre, j'ai placé le serveur intranet dans le réseau local. S'il s'était trouvé dans le réseau 172.20.0.0/16, il aurait fallu changer la cible "10.80.80.80" en "10.0.19.77" (adresse de la passerelle dans notre réseau local) dans la suite.</note>
\\
\\
Notre directeur ignore qu'un collaborateur fâché avec l'entreprise a décidé de jouer les pirates en herbe. Présent dans l'entreprise, il branche son ordinateur portable sur une prise réseau murale.

Le serveur DHCP faisant son travail à merveille, nous avons maintenant le schéma suivant : \\
{{ :ppe:layer2:schemaweb2.png?nolink |}}

==== Démonstration ====

Le "champ de bataille" dans le cadre de la démonstration :\\
{{ :ppe:layer2:home_attack.jpg?direct&600 |}}
\\
Le PC de la direction fonctionne tant bien que mal sous Windows 8 et le serveur web fonctionne sous Linux Debian 7 à jour. Quant à notre apprenti pirate, il s'est procuré une distribution "live" ressemblant étrangement à un mélange entre [[https://tails.boum.org/index.fr.html|TAILS]] et [[https://www.kali.org/|Kali]]. 
\\
\\
Notre pirate utilise [[https://ettercap.github.io/ettercap/|Ettercap]], outil permettant de capturer des paquets, visualiser les connexions, empoisonner les caches ARP et bien d'autres choses fort sympathiques.\\
Pour ce faire il va scanner les hôtes du réseau et trouver notre serveur web et notre PC client : 
{{ :ppe:layer2:capture_du_2016-12-11_19_10_14.png?direct&600 |}}
\\
puis il va cibler d'un côté notre client (10.1.2.3) et de l'autre notre serveur web (10.80.80.80).\\ \\
Il ne lui reste plus qu'à procéder à l'empoisonnement des tables ARP des deux hôtes en leur faisant croire qu'ils s'adressent à leur destinataire prévu et retransmettre les paquets "normalement" jusqu'au destinataire afin que personne ne soupçonne l'attaque (principe de l'attaque de l'homme du milieu). 
{{ :ppe:layer2:capture_du_2016-12-11_19_12_12.png?direct&600 |}}
\\
\\

Notre directeur se rend sur son réseau social d'entreprise préféré et rentre son identifiant et son mot de passe : 
{{ :ppe:layer2:accueilweb.png?direct&600 |}}
\\
Or, sur cette page non chiffrée, il transmet ces éléments en clair et notre pirate capture aisément ces informations : 
{{ :ppe:layer2:capture_du_2016-12-11_19_47_26.png?direct&600 |}}
\\
et voilà ce qu'il voit : 
{{ :ppe:layer2:capture_du_2016-12-11_19_48_01.png?direct&600 |}}
\\
\\
Notre directeur imprudent s'est fait voler ses identifiants et notre collaborateur indélicat part insérer quelques articles bien sentis en se faisant passer pour son patron. 
\\
==== Analyse ====
Les causes sont doubles : 
  * Absence de chiffrement de la page web consultée: les données transitent en clair sur le réseau.
  * Absence de protection contre l'empoisonnement ARP sur les équipements de niveau 2 : on peut changer d'adresse MAC à la volée, forger des trames pour corrompre les caches ARP des hôtes du réseau sans qu'on s'en rende compte. 
\\
Dans le [[ppe:layer2:ps_snooping|prochain chapitre]] nous verrons comment surveiller le réseau pour être alerté en cas de comportement suspect et utiliserons port security pour se prémunir de l'attaque vue plus haut. 
\\
===== DHCP Spoofing =====
==== Contexte ====

Reprenons notre réseau initial et intéressons nous au serveur DHCP qui délivre la configuration réseau aux hôtes situés sur le réseau 10.0.0.0/8.
Configuration : 
  * OS : Debian 8
  * DHCPD : isc-dhcp-server
  * Adresse IP : 10.0.19.31
  * Configuration pour les clients: 
    * Intervalle d'adresses attribuées : 10.1.0.0 - 10.1.100.100
    * Passerelle : 10.0.19.77 (routeur)
    * domaine : corpora.te

Les commutateurs n'ont pas de paramètres spécifiques hormis leur nom (SW1, SW2 et SW3) et l'auto MDIX activé.  
\\
Notre collaborateur indélicat souhaite maintenant récupérer l'ensemble du trafic sortant sur Internet depuis le réseau local de l'entreprise, en se branchant sur une prise murale dans un bureau du secrétariat, et en s'attribuant lui-même une adresse IP dans le réseau.  

{{ :ppe:layer2:dhcpcontexte.png?nolink&500 |}}
\\
Le PC pirate va offrir un service DHCP aux hôtes situés sur réseau (10.0.0.0/8) et se faire passer pour la passerelle par défaut : 

Configuration : 
  * OS : Debian 8 modifiée
  * DHCPD : isc-dhcp-server
  * Adresse IP : 10.0.10.10
  * Configuration pour les clients: 
    * Intervalle d'adresses attribuées : 10.1.0.0 - 10.1.100.100
    * **Passerelle : __10.0.10.10__ (lui-même)**
    * domaine : corpora.te

Il suffira au pirate de router correctement l'ensemble des paquets qui transitent par lui entre les hôtes du réseau local et le routeur de l'entreprise. 
<note tip>Dans le cas présent, le "premier" disponible répondra. On pourrait tout aussi occuper toutes les adresses disponibles du serveur DHCP au moyen de logiciels comme Yersinia((http://www.yersinia.net/attacks.htm)) et ainsi être le seul serveur disponible pour attribuer des adresses.</note>

<note important>Par définition la passerelle n'interceptera pas les paquets faisant l'objet d'une remise directe au sein du même réseau.</note>
==== Démonstration ====

Le directeur de l'entreprise Corporate souhaite consulter son compte en banque en ligne. 
En temps normal, il allume son poste de travail et reçoit la configuration réseau suivante du serveur DHCP situé à l'adresse 10.0.19.31 :
{{ :ppe:layer2:confdhcp1.png?nolink&450 |}}
Or, notre pirate situé sur le réseau exécute son serveur DHCP de son côté et au démarrage du système, le poste de travail du directeur reçoit cette configuration : 
{{ :ppe:layer2:confdhcp2.png?nolink&450 |}} \\
Le directeur de Corporate se rend sur le site web de sa banque en ligne au moyen de son navigateur préféré depuis son poste de travail:
{{ :ppe:layer2:ca1.png?nolink&600 |}}
et renseigne son identifiant et mot de passe pour consulter ses comptes
{{ :ppe:layer2:ca2.png?nolink&600 |}}\\
\\
Notre pirate ne rate rien de ce qui transite par son ordinateur désigné comme passerelle par défaut:  
Nous voyons le site consulté : {{ :ppe:layer2:dhcpattack1.png?nolink&600 |}} \\ \\
Et nous pouvons tranquillement analyser les trames pour récupérer login et mot de passe : \\
{{ :ppe:layer2:dhcpattack2.png?nolink&600 |}}{{ :ppe:layer2:dhcpattack3.png?nolink&700 |}}
\\
==== Analyse ====
Ici aussi les causes sont doubles : 
  * Absence de chiffrement de la page web consultée: les données transitent en clair sur le réseau.
  * Absence de protection contre un serveur DHCP pirate: celui-ci émet des trames DHCP OFFER sans cesse et répond aux demandes DHCP DISCOVER pour fournir la configuration en premier. 
\\
Dans le [[ppe:layer2:ps_snooping|prochain chapitre]] nous verrons comment utiliser la technique du DHCP snooping pour protéger notre réseau d'un serveur DHCP indésirable.
\\
\\

===== Conclusion =====

Nous avons préparé, exécuté et analysé deux types d'attaques montrant la faiblesse de la sécurité de la couche 2. 
Ces attaques ne sont naturellement pas exhaustives... nous pouvons évoquer rapidement la saturation des tables d'adresses MAC pour bloquer le fonctionnement des commutateurs ou encore l’accaparement de toutes les adresses délivrées par le serveur DHCP par notre machine pirate avec yersinia((http://www.yersinia.net/attacks.htm)) ou gobbler((https://sourceforge.net/projects/gobbler/)) par exemple.\\ \\ \\
Allons au [[ppe:layer2:ps_snooping|chapitre suivant]] pour aborder les techniques pour s'en prémunir et/ou atténuer leurs effets.  


\\
\\
\\
\\
//Auteur : Pol-Quentin Dupont - Toute reproduction autorisée en mentionnant l'auteur.//