La protection contre les canaux cachés avec Stormshield

Par Antoine Vermunt

Les pare-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 pare-feux Stormshield, ces attaques seront détectées et bloquées.

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. 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).

Côté attaquant

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

Côté victimes

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

Côté attanquant

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 firewall).

Côté attaquant

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 !

Côté victime

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 le programme Dnscat2 :

Côté attaquant

Côté victime Windows, on lance le script :

Côté victime

Côté attaquant, on obtient alors une invite de commande :

Côté attaquant

Les contre-mesures avec 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) :

La console Stormshield

Si l’on tente à nouveau de créer les canaux cachés précédents, voici les alarmes qui seront levées sur le firewall, et il ne sera pas possible à l’attaquant d’envoyer ses commandes :

Côté ICMP : Modification des données ECHO ICMP
Côté HTTP la connexion est bloquée
Alarme « Données additionnelles en fin de réponse » levée
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 votre solution. Dans les protections applicatives, le mode Firewall (FW) n’effectur 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 pare-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 pare-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…).

No Comments

Post A Comment