Tunnel DNS : introduction aux risques de fuite de données

Cet article introduit les risques existants d’utilisation du protocole DNS par un cheval de Troie afin d’établir une communication, et ainsi, par exemple, sortir des informations confidentielles depuis un ordinateur interne à l’entreprise sans être bloqué par les éventuels proxy ou firewall, ni détecté par les éventuels système de détection d’intrusion.

Le tunnel DNS n’est pas une technique nouvelle et pourtant, encore aujourd’hui, il est souvent possible d’en établir depuis des réseaux restreints.

Les premiers projets de tunnels DNS font leur apparition à la fin des années 90[1]. En 2000 apparaît NSTX un protocole de transfert de données basé sur DNS[2]. En 2004, Dan Kamynski mets l’accent sur les tunnels DNS lors d’une conférence Black Hat[3]. Depuis, la situation actuelle n’a pas vraiment évolué.

Aujourd’hui, alors que cette technique est bien connue, il est presque toujours possible d’établir un tunnel DNS hors d’un réseau d’entreprise.

Pour comprendre pourquoi, regardons de plus près la résolution d’une requête DNS légitime :

;; QUESTION SECTION:
;www.kyos.ch.            IN    A

;; ANSWER SECTION:
www.kyos.ch.        84390    IN    CNAME    kyos.ch.
kyos.ch.        84390    IN    A    93.88.240.240

La requête va être transférée de relais en serveur jusqu’à trouver le serveur DNS connaissant l’adresse IP de www.kyos.ch. La réponse prendra le même chemin en retour.

Si l’on remplace les noms de sous-domaine dans la requête par des données encodées, celle-ci seront transportées jusqu’au serveur, de la même manière qu’une requête légitime. On peut ainsi établir une connexion bidirectionelle entre le client et le serveur à l’insu du firewall.

;; QUESTION SECTION:
;.kyos.ch.            IN    A

;; ANSWER SECTION:
.kyos.ch.        84390    IN    CNAME    .kyos.ch.
.kyos.ch.        84390    IN    A    93.88.240.240

Cette technique a été utilisée historiquement pour obtenir un accès internet (par modem) via les numéros gratuits de Microsoft. Il est aussi envisageable de l’utiliser pour exfiltrer des informations confidentielles hors de l’entreprise.

La dépendance des réseaux au protocole DNS empêche de prendre des mesures simples pour empêcher cette fuite de données (fermeture de port). De plus, il est difficile pour un firewall de décider si une requête est légitime en se basant uniquement sur le nom d’hôte.

Dans les prochains articles nous verrons plus en détails comment mettre en œuvre un tunnel DNS et des moyens pour le détecter.

Eric Lederrey

[1] https://groups.google.com/group/muc.lists.bugtraq/browse_thread/thread/3328f580a5b30806/c8ed462bac818e40?hl=fr&q=dns+tunnel#c8ed462bac818e40

[2] https://slashdot.org/story/00/09/10/2230242/IP-Tunneling-Through-Nameservers et https://thomer.com/howtos/nstx.html

[3] https://www.blackhat.com/presentations/bh-usa-04/ bh-us-04-kaminsky/bh-us-04-kaminsky.ppt