Les pares-feux sont désormais systématiquement déployés dans les entreprises, et la plupart d’entre eux sont configurés pour filtrer les flux entrant et sortant de l’entreprise. Dans ces conditions, un attaquant ou un programme malveillant qui souhaite exfiltrer de l’information ou réaliser une prise de contrôle à distance d’une machine interne devra impérativement utiliser un des protocoles autorisés pour traverser le pare-feu en sortie.

Dans cet article nous allons montrer comment il est possible de créer des « canaux cachés », en détournant les protocoles usuels ICMP, HTTP et DNS pour encapsuler un « Reverse Shell » (invite de commande à distance) qui permettra à un attaquant extérieur d’avoir la main sur une machine interne de l’entreprise.

Enfin, nous verrons que grâce à l’IPS embarqué dans les pares-feux Stormshield, et prendra les mesures nécessaires afin de bloquer ces différentes attaques détectées.

Cette démonstration a été réalisée dans un but éducatif, en aucun cas vous ne devez reproduire la procédure sur un environnement ne vous appartenant pas !

Reverse Shell sur ICMP

Dans ce premier exemple, nous allons utiliser les messages ICMP Echo Request et Echo Reply pour « cacher » notre canal de commande. Nous allons utiliser l’outil ICMPsh et un simple Shell ICMP inversé avec un esclave sous Windows et un maître compatible POSIX en C, Perl ou Python, comme un Linux par exemple.

L’ICMPsh est un simple Shell ICMP inversé avec un esclave sous Windows et un maître compatible. Le principal avantage par rapport aux autres outils open source similaires est qu’il ne nécessite pas de privilèges administrateurs pour fonctionner sur la machine cible.

L’installation est assez simple et se lance en client portable côté Windows et un script Python côté Linux.

Côté Linux de l’attaquant, nous mettons le programme en écoute, en précisant l’IP du serveur et l’IP du client (ici sur le même réseau, mais le serveur pourrait être sur Internet évidemment).

L'usage de ce programme est relativement simple :

./icmpsh_m.py <serveur> <destination>

<serveur> : Adresse IP de notre Linux, faisant office de serveur

<destination> : Adresse IP de la victime, Windows cible

Affichage de la console Linux du côté de l'attaquant avec l'adresse IP du serveur et de destination

Côté Windows de la victime, nous exécutons le « client » ICMPsh, tout en précisant l’adresse IP du serveur :

Affichage de la console Windows PowerShell du côté de la victime

Côté Linux de l’attaquant, on voit désormais que nous avons la main sur son poste en ligne de commande :

Du côté de l'attaquant, nous obtenons par la suite un accès à l'Invite de Commande distant

Reverse Shell sur HTTP

Notre objectif est maintenant d’obtenir un Shell à distance, passant par le protocole HTTP à l’aide d’un script Python (exemple : https://github.com/mayurkadampro/HTTP-Reverse-Shell).

Côté Linux de l’attaquant, nous mettons en place notre serveur en écoute (ici sur le port 5003, mais dans le cas d’une attaque réelle cela serait sur le port 80, afin que ce dernier soit autorisé sur le pare-feu).

On lance le script Python faisant office de serveur malveillant

Côté Windows de la victime, nous exécutons le script « Client.pyw » et nous obtenons alors une connexion avec un Shell directement sous Windows !

Suite à notre attaque, nous remarquons que la connexion Shell est récupérée à distance

Reverse Shell sur DNS

Notre dernier objectif dans cet article est d’obtenir un Reverse Shell en passant par le protocole DNS sur le port 53. L’architecture repose sur un serveur Linux sur lequel un serveur Ruby exécutant DNSCat Server et un client Windows dans lequel le client DNSCat sera importé et lancé sur Powershell.

Côté Linux de l’attaquant, nous lançons l'utilitaire Dnscat2 :



On lance sur le serveur attaquant DNSCat2 suivit d'un domaine DNS

Même principe, on lance du côté du Windows de la victime sur PowerShell, le script client DNSCat2 avec le domaine précédemment spécifié et l'adresse IP du serveur DNS malveillant :

On obtient grâce à cela un accès distant à l'Invite de Commande avec les droits utilisateurs distants de la console PowerShell !

Une fois les procédures effectuées, nous obtenons ainsi un accès à l'Invite de Commande distant

Les contre-mesures avec les pares-feux Stormshield

Grâce à la protection IPS intégrée (et active par défaut) dans les pares-feux Stormshield, ce dernier analyse les flux transitant par les protocoles spécifiés et détectera l’usage anormal des protocoles.

Vérifier que sur vos flux sortants concernant les protocoles ICMP, DNS et HTTP, le niveau d’inspection est bien positionné à IPS (par défaut).

Il est important de garder à l’esprit que la sécurité IPS regroupe des fonctionnalités permettant de filtrer et de bloquer le trafic malveillant, comparé au niveau d’inspection IDS, qui va détecter l’attaque et l’option Firewall qui n’inspecte pas le trafic.

Pour activer l’IPS sur vos règles de sécurité, aller dans CONFIGURATION > POLITIQUE DE SECURITE > Filtrage et NAT.

Double-cliquez sur une de vos règles actuelles, aller dans le niveau d’inspection et sélectionnez IPS.

Sur l'interface des pares-feux Stormshield, lors d'une édition de règle de filtrage, il est important d'activer le niveau d'inspection IPS

Si maintenant nous tentons à nouveau de créer les canaux cachés précédents, voici les alarmes qui seront levées sur le firewall :

Des alarmes de type "Modification des données ECHO ICMP" sont générées du côté du Stormshield SNS

...et il ne sera pas possible à l’attaquant d’envoyer ses commandes :

Côté HTTP, la connexion est bloqué

Alarme « Données additionnelles en fin de réponse » levée

Du côté des DNS...

Côté DNS la communication ne peut s’établir

Alarme « DNS Tunneling » levée

Nous avons démontré l’efficacité de la protection IPS de Stormshield. Il est en effet très important de mettre la protection IPS pour toutes vos règles créées sur la solution.

Dans les protections applicatives, le mode Firewall (FW) n’effectue aucune vérification de sécurité, l’IDS ne détecte que l’attaque mais ne la bloque pas, contrairement à l’IPS où il détecte et bloque les attaques.

Il est à noter que d’autres canaux cachés existent, notamment via les flux chiffrés en TLS (HTTPS…), dans ce cas les pares-feux Stormshield sont capables de jouer le rôle de proxy TLS afin de continuer à analyser ces flux à la recherche d’abus sur les protocoles sous-jacents.

Enfin, sachez que les pares-feux Stormshield disposent d’une alarme « Détection de session Interactive » qui se base sur la statistique des données échangées sur une session et qui permet de détecter tout canal caché, y compris sur des sessions chiffrées (SSH, HTTPS…).

Il peut être intéressant de surveiller cette alarme (par défaut elle est positionnée sur « Ignorer ») pour vous assurer qu’il n’y a pas de flux illégitimes qui traversent votre firewall (ou tout simplement pour être alerté lorsqu’un administrateur se connecte en Telnet, SSH ou RDP sur une de vos machines…).