trycatchhcf/packetwhisper
PacketWhisper : Exfiltrez furtivement des données et déjouez l'attribution en utilisant des requêtes DNS et de la stéganographie textuelle. Évitez les problèmes associés aux méthodes d'exfiltration DNS typiques. Transférez des données entre des systèmes sans que les appareils communicants se connectent directement entre eux ou à un point de terminaison commun. Pas besoin de contrôler un serveur de noms DNS.
PacketWhisper - Transférez discrètement des données et évitez l'attribution en utilisant des requêtes DNS et la stéganographie basée sur du texte, sans nécessiter de serveurs de noms ou de domaines contrôlés par l'attaquant ; contournez les dispositifs DLP/MLS ; déjouez les contrôles de listes blanches de données et de serveurs de noms DNS. Convertissez tout type de fichier (exécutables, Office, Zip, images) en une liste de noms de domaine pleinement qualifiés (FQDN), utilisez les requêtes DNS pour transférer les données. Simple mais extrêmement efficace.
(Mise à jour du 27/05/2020 : Oui, je vais migrer tous mes projets Github vers Python3 au cours de l'été 2020.)
Joe Gervais (TryCatchHCF)
L'exfiltration DNS traditionnelle repose sur l'une des méthodes suivantes : le tunneling DNS ; le masquage de données dans les champs de requête DNS ; ou des charges utiles encodées/chiffrées qui sont divisées et utilisées comme sous-domaines dans la requête DNS. Toutes ces méthodes nécessitent que l'attaquant contrôle un domaine et/ou un serveur de noms DNS associé pour recevoir les données, ce qui conduit à l'attribution. Ces approches sont également vulnérables à la liste noire (courante) et à la liste blanche (de plus en plus courante) des serveurs de noms DNS. Un autre problème est que les analystes DFIR connaissent ces méthodes, et les systèmes SIEM les détectent et émettent souvent des alertes lorsqu'ils les voient.
PacketWhisper surmonte ces limitations.
Et si les données pouvaient être transférées en utilisant les propres serveurs DNS mis en liste blanche de la cible, sans que les systèmes communicants ne se connectent jamais directement les uns aux autres ou à un point de terminaison commun ? Même si la frontière réseau employait une liste blanche de données pour bloquer l'exfiltration ?
Pour y parvenir, PacketWhisper combine les requêtes DNS avec la stéganographie textuelle. En s'appuyant sur le Cloakify Toolset, il transforme la charge utile en une liste de chaînes FQDN. PacketWhisper utilise ensuite cette liste de FQDNs pour créer des requêtes DNS séquentielles, transférant la charge utile à travers (ou à l'intérieur) les frontières réseau, avec les données cachées à la vue de tous, et sans que les deux systèmes ne se connectent jamais directement l'un à l'autre ou à un point de terminaison commun. Les chiffrements utilisés par PacketWhisper offrent plusieurs niveaux de tromperie pour éviter de générer des alertes ainsi que pour induire en erreur les tentatives d'analyse.
Pour recevoir les données, vous capturez le trafic réseau contenant les requêtes DNS, en utilisant la méthode la plus pratique pour vous. (Voir 'Capturer le fichier PCAP' ci-dessous pour des exemples de points de capture.) Vous chargez ensuite le fichier PCAP capturé dans PacketWhisper (fonctionnant sur le système de votre choix), qui extrait la charge utile du fichier et la Décloakifie pour la retrouver dans sa forme originale.
DNS est un protocole intéressant à utiliser car, même s'il s'agit d'un moyen relativement lent de transférer des données, DNS est presque toujours autorisé à travers les frontières réseau, même sur les réseaux les plus sensibles.
Note importante : Nous utilisons les requêtes DNS pour transférer les données, pas les résolutions DNS réussies. PacketWhisper n'a jamais besoin de résoudre avec succès l'une de ses requêtes DNS. En fait, PacketWhisper ne regarde même pas les réponses DNS. Cela élargit nos cas d'utilisation et souligne le fait que nous n'avons jamais besoin de contrôler un domaine pour lequel nous faisons une requête, ni de contrôler un serveur de noms DNS traitant les requêtes DNS.
Ainsi, avec PacketWhisper, nous transformons une charge utile qui ressemble à ceci :
En une liste de FQDNs comme ceci :
Ce que PacketWhisper transforme en requêtes DNS qui apparaissent dans le trafic réseau comme ceci :
Que vous capturez sous forme de fichier PCAP n'importe où sur le chemin de résolution DNS, puis chargez ce PCAP dans votre copie locale de PacketWhisper pour récupérer la charge utile :
Voir les diapositives DEF CON 26 (incluses dans le projet) de ma présentation Packet Hacking Village. Les diapositives présentent le contexte de l'exfiltration DNS, la stéganographie textuelle / Cloakify Toolset, et comment PacketWhisper les combine pour créer une méthode de transfert de données. J'ai spécifiquement conçu les diapositives pour être utiles seules, donc le contexte et les informations devraient être complets. Cependant, vous pouvez également regarder la vidéo de ma présentation DC26 Packet Hacking Village qui fournit un contexte supplémentaire.
J'ai inclus un fichier PCAP d'exemple dans le projet (astucieusement nommé 'sample.pcap') qui contient des charges utiles distinctes pour chacun des chiffrements. Ils auraient pu être n'importe quel type de fichier, bien sûr, mais dans ce cas, j'ai simplement transmis des fichiers texte dans le PCAP. Chargez-le dans PacketWhisper et essayez-le !
Pour un test rapide dans votre propre environnement, exécutez PacketWhisper depuis une VM, puis envoyez un fichier tout en effectuant une capture de paquets sur l'interface réseau de la VM via le système hôte. Vous pouvez ensuite charger le fichier PCAP dans l'instance PacketWhisper qui vous convient pour décoder le fichier. Souvenez-vous que ce n'est pas un transfert rapide. Les fichiers plus petits et la patience sont vos alliés.
Question : 'Pourquoi n'avez-vous pas utilisé Scapy ou la bibliothèque dnspython ?'
Réponse : Je déteste les dépendances de projet dans mes outils opérationnels. Je garde mes projets aussi atomiques et autonomes que possible pour une fiabilité maximale, surtout côté client où je peux ne pas contrôler l'environnement et/ou avoir des privilèges minimaux. Grâce à la structure de PacketWhisper, je peux le faire fonctionner sur un hôte shell limité simplement en tarant le projet et en l'extrayant sur l'hôte cible.
Question : 'Pourquoi PacketWhisper n'est-il pas un fork du projet Cloakify Toolset ?'
Réponse : Même réponse que ci-dessus. Nous n'avons besoin que d'un sous-ensemble très spécifique des capacités de Cloakify, et ajouter tout le reste à PacketWhisper ne ferait qu'encombrer le répertoire et ajouter des outils/chiffrements qui ne peuvent pas être utilisés par PacketWhisper. Comme je possède les deux projets, je promets de synchroniser les changements entre les deux.
$ python packetWhisper.py
Les chiffrements basés sur les FQDN comprennent 3 catégories :
FQDNs à sous-domaines aléatoires uniques
MODE DE CHIFFREMENT RECOMMANDÉ POUR LA PLUPART DES CAS D'UTILISATION
Ce sont des FQDNs avec des éléments aléatoires intégrés dans les sous-domaines. Cela aide à prévenir la mise en cache DNS, tout en nous permettant de transférer des données au-delà des dispositifs réseau NATés qui peuvent se trouver sur le chemin des requêtes DNS. Comme l'adresse IP du système émetteur n'est pas disponible au-delà du dispositif NAT, les sous-domaines générés par le chiffrement contiennent des éléments d'étiquettes uniques pour nous aider à identifier les charges utiles PacketWhisper dans la capture de paquets.
Ces chiffrements imitent les formats de divers services qui s'appuient sur des sous-domaines complexes pour identifier une session, un utilisateur, un contenu mis en cache, etc. Cette approche aide les requêtes DNS de PacketWhisper à se fondre dans le reste du trafic réseau.
La première partie du nom de sous-domaine est en fait une chaîne provenant de la liste de chiffrement. Le reste du nom de sous-domaine est randomisé pour rendre chaque FQDN unique, ce qui empêche la mise en cache DNS de fermer prématurément le chemin de requête DNS. Nous ajoutons ensuite le nom de domaine. Nous construisons les FQDNs de cette manière pour qu'ils ressemblent aux FQDNs habituels associés au domaine sélectionné, afin de mieux se fondre dans le trafic web normal observé sur n'importe quel réseau.
FQDNs uniques répétés
Créés pour se démarquer de toutes les autres requêtes DNS sur le réseau, mais sans aucune randomisation. Cela signifie que la mise en cache DNS peut interférer, mais en contrepartie, vos requêtes DNS seront faciles à trouver même dans la plus grande collection de pcaps multi-clients. Cela est dû au fait que les FQDNs sont des points de terminaison étranges, comme la liste des 'Johns' (aliens Red Lectroid) au sein de la fictive Yoyodyne Propulsion Systems du film 'Buckaroo Banzai Across the 8th Dimension'.
FQDNs de sites web courants
Ce sont des FQDNs construits à partir d'URLs de sites web courants.
REMARQUE : Comme la plupart des environnements sont NATés en périphérie (supprimant la visibilité de l'adresse IP du client), ce mode n'est généralement utile que pour transférer des données entre des systèmes connectés au même réseau local /24 (par exemple, le wifi invité de votre café préféré).
Comme les chiffrements de sites web courants n'ont que l'adresse IP source comme moyen de distinguer leurs requêtes de toutes les autres requêtes DNS similaires sur le réseau, PacketWhisper transmet une requête DNS 'séquence de frappe' unique au début et à la fin de la charge utile, ce qui nous aide à identifier l'hôte émetteur dans le fichier pcap plus tard.
Exemple de FQDN : www.github.com
Une fois que vous avez sélectionné un chiffrement, PacketWhisper encode (Cloakifie) la charge utile en une liste de chaînes FQDN selon le chiffrement souhaité. Il génère ensuite séquentiellement des requêtes DNS pour envoyer les données le long du chemin de résolution DNS. PacketWhisper ajoute un petit délai entre chaque requête DNS, ce qui aide à éviter les requêtes DNS désordonnées.
L'élément clé ici est bien sûr la capacité à capturer le trafic réseau contenant les requêtes DNS générées par PacketWhisper. Il existe de nombreuses options, car vous n'avez besoin d'être qu'à un endroit quelconque, avec une visibilité sur le chemin des requêtes DNS.
Exemples de points de capture :
Utilisez votre imagination. Tout dispositif le long du chemin de résolution DNS est une option, y compris les écrans muraux. 'Attendez, quoi ?'
REMARQUE : Les connexions VPN bloquent la visibilité entre l'hôte et le nœud de sortie VPN. Si le client à partir duquel vous transférez a une connexion VPN active, vous ne pourrez voir aucune requête DNS à moins de pouvoir capturer en amont du nœud de sortie VPN. Même une capture sur le même système échouera. Comme beaucoup d'entre vous utilisent probablement des VPN, si vous voulez tester PacketWhisper, essayez de transmettre depuis une machine virtuelle hébergée (VM) et capturez le trafic sur l'interface réseau de la VM sur le système hôte.
Une fois que vous avez capturé le fichier pcap, récupérez la charge utile en exécutant PacketWhisper sur un système disposant de tcpdump (inclus sur Linux et MacOS) ou WinDump (Windows) installé. PacketWhisper vous demandera quel chiffrement a été utilisé, puis extraira la charge utile du pcap, et enfin décodera la charge utile extraite avec le chiffrement correspondant.
Note importante : Dans un même PCAP, vous pouvez transmettre une charge utile par chiffrement utilisé. Un PCAP contenant plusieurs charges utiles utilisant le même chiffrement posera problème. Par exemple, mon fichier 'example.pcap' fourni contient 5 charges utiles, une pour chacun des chiffrements opérationnels actuellement disponibles. Si l'une des charges utiles avait utilisé le même chiffrement qu'une autre, PacketWhisper ne parviendrait à extraire aucune des deux. La solution simple est de diviser le fichier PCAP (c'est pourquoi le code de transmission de PacketWhisper imprime l'horodatage UTC au début et à la fin de la transmission). Je travaille sur la possibilité d'autoriser plusieurs charges utiles utilisant le même chiffrement, la solution est déjà en place, je dois juste m'y atteler.
Assurez-vous que votre fichier PCAP est bien au format PCAP. Si vous avez utilisé tcpdump ou WinDump pour capturer le fichier, tout va bien. Wireshark propose cependant une grande variété d'options 'Enregistrer sous...' pour sauvegarder le trafic Wireshark, dont une seule est réellement compatible tcpdump/PCAP. Je travaille sur un meilleur rapport d'erreurs pour aider à détecter les erreurs tôt.
Ce n'est pas un schéma de chiffrement sécurisé. PacketWhisper n'est pas un schéma de chiffrement sécurisé. Il est vulnérable aux attaques par analyse de fréquences. Utilisez la catégorie de chiffrements 'FQDNs à sous-domaines aléatoires uniques' pour ajouter de l'entropie et aider à dégrader les attaques par analyse de fréquences. Si la confidentialité de la charge utile est requise, veillez à chiffrer la charge utile avant de l'utiliser avec PacketWhisper.
Ce n'est pas une méthode de transfert à large bande passante. PacketWhisper repose sur des requêtes DNS, qui sont basées sur UDP, ce qui signifie que l'ordre de livraison (voire la livraison réussie) de la requête n'est pas garanti. PacketWhisper ajoute par défaut un petit délai (1/2 seconde) entre chaque requête DNS. Vous pouvez transférer des charges utiles en toute sécurité à un rythme d'environ 7,2 Ko par heure (120 octets par minute). Cela est basé sur la taille de la charge utile d'origine, pas sur le fichier de sortie Cloakifié. Vous pouvez opter pour aucun délai entre les requêtes, ce qui accélère considérablement le transfert mais au risque d'augmenter le bruit réseau et de corrompre la charge utile.
Et avouons-le, si vous disposez de modes de transfert de données non DNS, vous pouvez simplement utiliser le projet principal Cloakify Toolset pour cacher le fichier à la vue de tous (peut-être transformer la charge utile en une liste de monstres PokemonGo avec des coordonnées LatLon) et utiliser toute la large bande passante disponible via FTP/HTTP/etc. DNS est extrêmement utile lorsque d'autres protocoles sont bloqués, mais soyez toujours conscient de vos options.
DNS est DNS. Différents systèmes d'exploitation ont des politiques de mise en cache DNS différentes, etc. Les réseaux peuvent être en panne, isolés, etc. PacketWhisper inclut une vérification manuelle rapide pour voir s'il peut résoudre des FQDNs courants, mais DNS est souvent une affaire compliquée. Souvenez-vous du vieux mantra de dépannage informatique : 'C'est toujours DNS.'
Voir les diapositives DEF CON 26 (incluses dans le projet) de ma présentation Packet Hacking Village. Les stratégies d'atténuation sont couvertes vers la fin de la présentation. Comme pour tout, la 'Sécurité en profondeur' est votre alliée, d'autant plus que les chemins de résolution DNS traversent de vastes étendues de terrain qui échappent au contrôle de votre organisation.
Je vais ajouter des modes pour MDNS et LLMNR, des modes de diffusion DNS en réseau local. Ceux-ci sont destinés à être utilisés par des systèmes connectés au même réseau local, et supprimeront la nécessité pour le dispositif de capture d'avoir accès au mode Promiscuous lors des captures de paquets wifi. (Ces protocoles envoient du trafic vers x.y.z.255 sur le réseau hôte, diffusant du trafic à tous les autres systèmes sur le même réseau local.)
J'ajouterai également plus de chiffrements, mais pour les besoins quotidiens, la collection actuelle de chiffrements est tout ce dont j'ai jamais eu besoin. Vous en tirerez un bon parti.
Je travaille également sur la possibilité d'autoriser plusieurs charges utiles utilisant le même chiffrement dans un seul fichier PCAP. La solution est déjà prototypée, mais elle rend le flux d'extraction PCAP plus laid pour l'utilisateur. Opérationnellement, cela pourrait être plus de problèmes que de bénéfices. Je préfère toujours une fonctionnalité opérationnelle plus propre qu'une complexité de couteau suisse.
