tcstool/fireawayOutil d'audit et de contournement de pare-feu de nouvelle génération
v0.2
Fireaway est un outil d'audit, de contournement et d'exfiltration de données contre les règles d'inspection de couche 7/AppID sur les pare-feu de nouvelle génération, ainsi que contre d'autres mécanismes de défense par inspection approfondie des paquets, tels que la prévention des pertes de données (DLP) et les proxys conscients des applications. Ces tactiques reposent sur le principe de devoir autoriser les connexions à s'établir à travers le NGFW afin de voir les données de couche 7 pour les filtrer, ainsi que sur l'usurpation d'applications pour cacher les canaux de communication dans les journaux du pare-feu comme un trafic utilisateur normal, par exemple la navigation sur Internet. Dans le cas du contournement des outils de prévention des pertes de données, Fireaway envoie des données en petits « morceaux », qui ne correspondent pas aux déclencheurs d'expressions régulières et aux autres règles DLP, et intègre également des données dans des en-têtes HTTP usurpés d'applications légitimes que la plupart des technologies de prévention des pertes de données ne sont pas conçues pour inspecter. L'outil a également réussi à vaincre les moteurs de détection d'anomalies et d'heuristiques grâce à sa capacité à usurper les en-têtes d'applications et à y cacher des données.
Démarrage du serveur FireAway : Généralement, le serveur FireAway est démarré du côté de la sortie du pare-feu (par exemple un serveur sur Internet) et écoute sur un port présumé fermé pour voir si des règles basées sur les applications autorisent le trafic sur ce port, ou pour recevoir des morceaux de données brutes afin de déterminer si le DLP ou les proxys applicatifs peuvent les identifier :
python fa_server.py <port d'écoute> <numéro de mode>
Le serveur peut être démarré dans quatre modes :
Mode test (mode 0) – Reçoit des données envoyées séquentiellement ou des données de test générées aléatoirement. Les données sont écrites telles quelles et aucun réassemblage n'est nécessaire.
Réception séquentielle de morceaux (mode 1) – Les données sont envoyées à un ou plusieurs serveurs dans des tailles de morceaux définies par le client de manière séquentielle. fa_server enregistre l'horodatage de la réception du morceau dans la sortie et utilise l'heure de réception comme clé d'ordre lors du réassemblage. Une « clé de réassemblage » générée par le serveur sera également utilisée avec fa_assembler.py. Il s'agit d'une clé de 4 caractères générée aléatoirement servant de délimiteur entre les morceaux, avec l'idée que ces caractères n'existent pas dans les morceaux de données transmis.
Réception aléatoire de morceaux (mode 2) – Les données sont envoyées à un ou plusieurs serveurs dans un ordre aléatoire. Ce mode dépend de la transmission d'un message de « clé de séquence » du client vers un serveur aléatoire du pool. Au démarrage de chaque serveur, le serveur demande de saisir un « identifiant de clé de séquence ». Celui-ci doit être un motif non présent dans le fichier transmis afin que le serveur puisse identifier correctement les données reçues sur une connexion comme la clé de séquence. ASSUREZ-VOUS QUE LE MÊME IDENTIFIANT DE CLÉ DE SÉQUENCE EST UTILISÉ SUR TOUS LES SERVEURS ! Le client sélectionnera aléatoirement un serveur pour transmettre la clé de séquence, il est donc important que tous les serveurs puissent localiser la clé de séquence dans leurs données reçues. La clé de séquence sera enregistrée par le serveur récepteur dans un fichier nommé 'SequenceKey.txt'.
Réception de morceaux d'applications usurpées (mode 3) – Des données encodées en Base64 sont envoyées à un ou plusieurs serveurs à l'intérieur d'en-têtes HTTP usurpant des applications légitimes. Ce mode générera également une « clé de réassemblage » à utiliser avec le script fa_assembler.
Toutes les données reçues par les serveurs sur le port spécifié seront sauvegardées dans le fichier ReceivedData.txt dans le répertoire à partir duquel le serveur a été lancé. Si le serveur détecte des tailles différentes dans la quantité de données reçues (indiquant qu'un filtrage du pare-feu a eu lieu), cette sortie sera affichée sur la console du serveur :
Got the same or lower amount of data on two consecutive runs. If sending test data, maximum data leak size may have been reached.
Démarrage du client FireAway / Usurpateur d'application : Le client FireAway dispose de trois modes :
Mode test (mode 0) – Envoie des données aléatoires dans des tailles de morceaux croissantes pour voir la quantité de données pouvant être envoyées avant que les contrôles de couche 7 ne s'engagent et n'arrêtent le flux de trafic.
Mode d'exfiltration séquentielle (mode 1) – Ouvre un fichier et l'envoie en morceaux d'une taille spécifiée. Les données sont transmises séquentiellement.
Mode d'exfiltration aléatoire (mode 2) – Ouvre un fichier et l'envoie en morceaux d'une taille spécifiée, mais dans un ordre aléatoire. Lors de l'utilisation de ce mode, le client demande l'identifiant de la clé de séquence. Il s'agit de la valeur spécifiée sur les serveurs distants, et le client étiquette la clé de séquence générée avec l'identifiant, qui est transmis à un serveur aléatoire si une liste est fournie ou à l'adresse IP du serveur spécifié, avant la transmission du fichier.
Pour démarrer le client de base :
python fa_client.py <IP du serveur FireAway ou chemin du fichier de liste de serveurs> <Port du serveur FireAway> <Mode client>
La liste des serveurs doit être un simple fichier texte contenant une liste d'adresses IP, une par ligne. Si un seul serveur est utilisé, une seule IP peut être spécifiée à la place.
Le client d'usurpation d'application dispose de deux modes :
Mode test (mode 0) – Envoie des données de test aléatoires à l'intérieur d'en-têtes HTTP dans des morceaux de plus en plus grands pour déterminer la quantité de données pouvant être envoyées avant que les contrôles de couche 7 ne s'engagent et n'arrêtent le flux de trafic.
Mode d'exfiltration encodé en Base64 (mode 1) – Encode un fichier d'entrée en Base64 et transmet des morceaux du fichier encodé à l'intérieur d'en-têtes HTTP générés aléatoirement pour contourner le DLP et masquer la transmission comme une application légitime.
Pour démarrer le client d'usurpation d'application :
python fa_spoof.py <IP du serveur FireAway ou chemin du fichier de liste de serveurs> <Port du serveur FireAway> <Mode client>
L'usurpation d'application insérera aléatoirement des en-têtes HTTP à l'intérieur d'en-têtes d'applications d'apparence légitime (par exemple Facebook, LinkedIn, etc.) avec les morceaux de données pour polluer les journaux avec diverses applications afin de masquer l'exfiltration de données.
Réassembleur Fireaway : Le réassembleur Fireaway (fa_assembler.py) est utilisé pour réassembler les données reçues par les serveurs Fireaway. L'assembleur dispose de trois modes, qui correspondent au mode des serveurs qui ont reçu les données :
Mode 1 – Réassemble les données reçues dans un ordre séquentiel par les serveurs en mode 1. L'assembleur demandera de spécifier la clé de réassemblage pour le fichier contenant les données reçues pour chaque serveur, c'est-à-dire la valeur aléatoire que le serveur a générée et affichée au démarrage. Cette valeur peut également être trouvée en examinant les fichiers avec les morceaux reçus, et en regardant les quatre premiers caractères.
Mode 2 – Réassemble les données reçues dans un ordre aléatoire par les serveurs en mode 2. L'assembleur demandera le chemin vers la clé de séquence, qui a été reçue du client par un serveur aléatoire pendant la transmission. Il demandera également les clés de réassemblage pour chaque fichier.
Mode 3 – Réassemble les données encodées en Base64 reçues dans les en-têtes HTTP d'applications usurpées. Ces données, comme pour le Mode 1, demanderont également la clé de réassemblage.
Pour démarrer le réassembleur :
python fa_assembler.py <mode de réassemblage> <chemins séparés par des virgules vers les fichiers à réassembler>
La sortie sera sauvegardée dans le nom de fichier spécifié.
Veuillez signaler tout problème ou question via Github.