Contourner un pare-feu local

Quand on souhaite sécuriser son réseau d’entreprise, on en vient à penser segmentation, et à organiser ses zones réseau par fonction, niveau de sensibilité des applications ou du niveau d’accessibilité requis.

La plupart du temps, on envisage d’isoler ses zones par la mise en place de pare-feu, de fermer les flux, et de ne les ouvrir qu'au fur et à mesure que les demandes d’accès se manifestent.

Tout comme les machines qui portent les applications, les utilisateurs sont, eux aussi, placés dans une zone du réseau, parfois en fonction du niveau de confiance qu’il leur est accordé. (Sont-ils présents physiquement sur site, connectés par câble, au wi-fi ? Ou peut-être sont-ils chez eux, connectés à travers le VPN de l’entreprise ?)

En cas de menace interne, si un employé est malveillant, ou si l’un des postes ou l’un des serveurs est compromis, le pare-feu a pour rôle principal de limiter le risque de mouvements latéraux.

Que se passe-t-il en cas de scan du réseau interne par l’acteur malveillant depuis la machine qu’il détient ? Le pare-feu bloque les flux non autorisés, et l’attaquant ne peut donc, en théorie, que découvrir les services que sa machine a le droit de contacter.

Cependant, un attaquant local dispose d’outils et de méthodes qui lui permettent de contourner cette segmentation dans un grand nombre de scénarios.

Mise en relief d’un exemple d’attaque qui relativise l’efficacité native des pare-feu locaux.

Le scénario est classique : nous disposons d’une zone réseau dans laquelle sont positionnés les postes des utilisateurs, et d’autres zones dans lesquelles sont placés les serveurs qui portent les applications. On dispose également d’un pare-feu central.

Chaque poste est configuré avec une adresse IP fixe, ce qui permet aux administrateurs du réseau de réaliser les ouvertures de flux directement au sein du pare-feu.

Usurpation d’adresses IP

La plupart des pentesters connaissent l’adage “Never trust user input” : on ne doit jamais faire confiance à une entrée utilisateur.

Plus particulièrement, on ne fait jamais confiance par défaut à une entrée fournie par un utilisateur.

L’ironie, dans la sécurité réseau, c’est que les adresses IP sources des paquets forgés par les machines sont, d’une certaine façon, des entrées utilisateur, et que ces mêmes adresses IP sont l'élément de base utilisé par les pare-feu pour autoriser ou bloquer les flux.

En partant de ce principe, un attaquant au sein d’une zone réseau, et disposant de droits suffisants sur sa machine peut :

Reconfigurer sa carte réseau afin de lui attribuer l’adresse IP d’un autre poste utilisateur
Utiliser des outils comme Scapy afin de forger des paquets IP présentant une adresse source falsifiée, et surtout injecter de tels paquets sur le réseau

Avec l’adresse IP d’un tiers, il devient possible pour l’attaquant de détecter les services que le pare-feu autorise sans avoir à compromettre la machine en question, en réalisant un scan réseau avec Nmap, Masscan ou en développant son propre outil au-dessus de Scapy.

Il sera peut-être confronté à quelques difficultés : notamment la gestion du conflit d’adresses IP au sein de la zone réseau, qui pourra nécessiter d’attendre la déconnexion de la machine portant la carte réseau usurpée, ou de pousser l’attaque un peu plus loin, par exemple en jouant avec de l’empoisonnement ARP, et en trompant les appareils sur la correspondance adresse MAC/adresse IP.

Méthode de découverte alternative : l’homme du milieu

Pour rester sur le thème des attaques ARP, une méthode plus silencieuse consiste à se faire passer pour le routeur de la zone, et d’intercepter les communications entre les postes utilisateurs et leurs destinations afin de générer une matrice de droits.

La méthode combine une découverte passive à travers la récolte des informations avec une attaque active, par l’empoisonnement des caches ARP des postes et du routeur. Pour ce faire :

L’attaquant génère des réponses ARP “is-at” en se faisant passer pour le routeur auprès des postes utilisateurs de la zone. Il en fait de même pour le routeur.
Il active le routage sur son poste afin de relayer les paquets reçus, qui ne lui sont pas destinés, et d'éviter un déni de service du réseau.
Il surveille les paquets sur ses interfaces réseau avec un outil comme Wireshark ou Tcpdump, et relève les adresses IP sources et de destination, ainsi que les ports des applications. Il consigne ensuite ces informations dans une matrice.

En conservant ce dispositif suffisamment longtemps, l’attaquant peut obtenir une visibilité des droits d’accès, identifier les applications, les postes autorisés à y accéder, et répéter l’opération d’usurpation des adresses IP de façon plus chirurgicale.

Changer de paradigme et éliminer une famille de risques

Les deux méthodes présentées dans cet article sont des attaques classiques des couches 2 et 3 OSI.

Il est possible de les atténuer de plusieurs façons, qui nécessitent la mise en œuvre de matériels et logiciels supplémentaires, d’un durcissement généralisé et une maintenance régulière par des experts réseau et sécurité.

Parmi les méthodes d’atténuation classiques, on retrouve :

La mise en place de sondes de sécurité au sein du réseau pour détecter les paquets anormaux, la réalisation de blocage et la levée d’alertes
La mise en place de contre-mesures de type Dynamic ARP Inspection pour lutter spécifiquement contre la famille d’attaques qui vise ARP.
La configuration de mécanismes de vérification type “Reverse Path Forwarding” (qui ne restent efficaces que dans le cas où l’usurpation d’adresses se réalise depuis des zones réseau différentes.)

En outre, lutter efficacement contre les attaques sur les réseaux locaux est coûteux et difficile. Une autre méthode, plus élégante, consiste à changer le paradigme de communication entre les utilisateurs et les applications, ou des applications entre elles, via l’usage du Zero Trust Network Access afin de :

S’affranchir de l’usage des adresses IP comme d’un élément de vérification. En remplacement, baser les accès sur l’identité même des utilisateurs, et non des machines ou des interfaces réseau
Fournir des accès “micro-segmentés” utilisateurs à applications, et non utilisateur à réseau. Éviter de se baser sur la position et la configuration du réseau pour autoriser ou non les accès.
Créer des tunnels sécurisés aux applications via les couches supérieures de l’OSI comme la couche 7 applicative pour se défaire des risques liés aux attaques des couches inférieures concernant les accès applicatifs.

Chimere est spécialisé dans cette approche, tenez vous au courant des prochains articles :