Heyoka allie furtivité et rapidiité pour des tunnels DNS avec 60 pour-cents de données en plus par paquet

Par Rédaction, secuobs.com
Le 17/04/2009

---

Résumé : Heyoka rend les tunnels DNS plus furtifs via un système interne de gestion avancée de l'usurpation des adresses ip sources. De plus il offre un gain considérable de performances avec 60 pour-cents de données stockées en plus par paquet DNS. - Lire l'article



Pour sortir des données sensibles d'une entreprise, un attaquant interne fait la plupart du temps face à un contexte assez ouvert, utiliser un port autorisé en sortie par le pare-feu est alors une solution qui se caractérise autant par ses débits rapides que par ses fortes probabilités de détection. Dans un contexte plus cloisonné, l'encapsulation ( lien ) d'un protocole non autorisé (SSH, FTP, ...) au sein d'un protocole autorisé (ICMP) se caractérise elle aussi par des débits rapides, mais permet de contourner les systèmes de détection qui n'inspectent pas les paquets en profondeur ( DPI - lien ).

Si aucun protocole n'est alloué en sortie par le pare-feu, utiliser les serveurs Proxy et SMTP internes est envisageable. Les authentifications éventuellement associées, l'enregistrement par logs et l'unidirectionnalité SMTP sont cependant des inconvénients. Le tunnel DNS s'impose alors comme une solution adéquate pour une communication bidirectionnelle avec une machine distante dont l'attaquant contrôle le nom de domaine. Les hôtes internes sont autorisés à utiliser DNS, aucun scan du réseau n'est requis, les requêtes ne sont de plus pas enregistrées et surveillées.

Des outils pour créer et utiliser des tunnels DNS existent déjà depuis longtemps, OzymanDNS ( lien ), Dns2tcp ( lien ) et NSTX ( lien ) sont des exemples. Néanmoins, la faible capacité de stockage autorisée par paquet DNS implique une certaine lenteur qui s'avère peu pratique pour transférer des fichiers volumineux ou établir des sessions VNC/RDP ( lien ). De plus, la détection est facilitée ( MolTunnel - lien ) par le fait qu'une seule adresse IP génère une majorité du trafic DNS. Pour résoudre cela, deux chercheurs de la société Portcullis ( lien ) ont présenté Heyoka lors de la conférence SOURCE 2009 ( lien ).

A savoir que 255 caractères peuvent être stockés dans le champ hostname ( lien ) d'un paquet DNS, hostname est structuré en labels de 63 caractères maximum. La plus large possibilité pour le domaine evil.com étant la structure [0x3F][63chars][0x3F][63chars][0x3F][63chars][0x34][52chars][0x04]evil[0x03]com[0x00], 241 caractères utiles ici disponibles pour placer des données. Avec l'encodage base32 ( lien ), 5 bits par caractère sont autorisés, soit 1205 bits utiles par paquet pour evil.com. Un compteur d'état étant nécessaire pour fiabiliser la communication, cet espace est réduit à +/- 150 octets. Même pour des données compressées, cela reste peu.

Heyoka augmente cette capacité en profitant du fait que les codes des caractères ASCII ne sont les seuls à pouvoir être utilisés dans les labels vu que les chaînes binaires ( lien ) y sont aussi autorisées, impliquant dès lors 8 bits alloués par caractère au lieu de 5, soit 60 % de stockage en plus par paquet. Pour résoudre la détection par anomalie du volume DNS généré, Heyoka utilise une adresse IP source usurpée différente pour chaque paquet DNS. Les réponses ne seront alors pas retournées par la machine distante à l'hôte interne utilisé par l'attaquant mais vers les sources usurpées, soit une communication unidirectionnelle.

Heyoka utilise alors deux tunnels concurrents pour l'aspect bidirectionnelle, soit un premier pour que l'hôte interne envoie des paquets usurpées, contenant les données, à la machine distante et un second pour lui envoyer des paquets non usurpées uniquement destinés à ce qu'elle puisse elle aussi envoyer des données vers l'adresse IP valide de cet hôte interne. L'envoi de ces dernières étant conséquent au fait que la machine distante ait reçu des paquets de sources usurpées venant de l'hôte interne, la coordination entre ces deux types de paquets reçus par la machine distante étant gérée par un protocole interne de corrélation.

Heyoka devrait également inclure des mécanismes internes aux paquets afin de gérer les synchronisations, les négociations automatiques de l'encodage (binary, base32, base64) et la retransmission des paquets perdus (Pseudo TCP Over DNS UDP). D'autant que plusieurs serveurs DNS pourront être utilisés dans une même communication pour augmenter la bande passante et garantir la sauvegarde des tunnels lorsqu'un serveur DNS n'est plus disponible. Le support de plusieurs hôtes internes devrait de plus complexifier la détection des tunnels. Au final les protocoles de contrôle devrait tenir en six octets.

Le site officiel ( lien )
Le PDF de la présentation ( lien )

Source : Security Bloggers Network ( lien )