Hackers en série : Person of interest
26 août 2019
Focus sur : le domain fronting
Décryptage de la technique du domain fronting et de son utilisation à des fins malveillantes.
Cet article a pour but d’expliquer ce qu’est la technique du Domain Fronting ainsi que son utilisation à des fins malveillantes. Il s’agit d’une technique récente de plus en plus utilisée dans les attaques avancées dites « APT » (Advanced Persistent Threat) et les audits « Red Team » simulant des attaques réalistes envers des sociétés. Commençons dans un premier temps par poser quelques bases de cette technique afin de mieux visualiser un contexte d’attaque.
Qu’est-ce que le domain fronting ?
Lorsque nous essayons d’accéder à un site web en utilisant notre navigateur, nous entrons naturellement l’URL du site web, disons par exemple “google.com” et attendons d’avoir accès à la ressource demandée. Un enchaînement d’actions transparentes pour l’utilisateur se déroule en commençant par une résolution DNS puis l’envoi de notre requête par la suite.
Notre ordinateur doit contacter le serveur qui possède le contenu à afficher, dans notre exemple le serveur associé à “google.com”. Seulement, il ne sait pas comment le faire car il ne connait pas son adresse IP. Pour trouver l’adresse IP de ce dernier, il devra s’aider d’un serveur DNS.
Le serveur DNS (Domaine Name Server) permet en effet de faire le lien entre l’adresse IP des machines sur Internet et leur nom de domaine.
Dans le schéma ci-dessus l’utilisateur a réussi à obtenir l’adresse IP de la machine « www » qui correspond au serveur web du domaine google.com. Il pourra par la suite demander à ce dernier la ressource doodles.
Protocole HTTP
Il s’agit d’un protocole basé sur la technologie web, permettant à un client web (navigateur) d’échanger des ressources (pages HTML, contenus multimédias, etc.) avec un serveur web. Nous utilisons le protocole HTTP chaque fois que nous nous rendons sur un site web. Reprenons l’exemple de l’URL : http://www.google.com/doodles. Essayons de décomposer cette URL entrée dans le navigateur afin de voir ce qu’il en retourne :
Afin que notre requête entrée dans l’URL soit comprise par le serveur, des paramètres HTTP doivent se voir attribuer des valeurs particulières. Voici dans la spécification http simplifiée à quoi correspond la précédente requête envoyée :
Host
Pour qu’un serveur web puisse fournir une ressource pour un nom de domaine donné, il doit posséder ce qu’on appelle un Virtual Host ou un fichier d’ « hôtes virtuels » correspondant à ce nom de domaine. Le but de ce fichier est de distinguer les sites web hébergés sur le serveur par noms de domaine.
Il est en effet possible pour un serveur web disposant d’une adresse IP unique d’héberger plusieurs sites web accessibles par des noms de domaine différents. Ce qui veut dire que si des sites web sont configurés pour correspondre à l’adresse IP d’un seul serveur, il faudrait que ce dernier puisse savoir à quel site web les clients souhaitent se connecter.
CDN et Domain Fronting
Pour répondre aux besoins de plus en plus gourmands en ressources, un autre élément entre en jeu. Il s’agit des CDN.
CDN
Les CDN (Content Delivery Network ou Réseaux de Distribution de Contenus) sont comme des serveurs sauf qu’ils présentent des capacités bien plus larges en termes de mémoire et de puissance. En effet, les CDN possèdent exactement les mêmes fichiers “Virtual Host” mais aussi des clusters (serveurs), dispersés partout dans le monde. Nous pouvons citer des exemples de CDN tels qu’Amazon Cloudfront, Akamai, Cloudflare, OVH, etc.
L’avantage des CDN est qu’ils sont présents dans pratiquement tous les coins du monde. Un seul site web peut être configuré sur plusieurs clusters d’un CDN afin que des clients web du bout du monde aient toujours un serveur à proximité pour obtenir les ressources demandées.
Nous parlons des CDN car ils ont une grande importance dans la réalisation de la technique de Domain Fronting. En effet lorsque des sites web sont configurés sur des CDN connus et populaires, les équipes de détection ont parfois tendance à être moins vigilantes, ce qui favorise encore plus la réalisation de cette technique.
Domain Fronting
Lors de l’envoi d’une requête vers un serveur, la valeur du nom de machine présent dans l’URL est directement affecté au paramètre Host (confère figure2). Mais, en réalité, il n’est pas nécessaire que ces deux valeurs (nom de machine dans l’URL et valeur du Host HTTP) soient égales pour que la requête fonctionne. C’est la valeur du paramètre Host qui est prioritaire, c’est-à-dire celle qui sera traitée par le serveur web. En d’autres termes, il est possible de remplacer la valeur du Host par le nom de machine de notre choix.
Cependant, une condition à cela est que les deux noms de machine c’est-à-dire celui entré dans l’URL et celui affecté au paramètre Host aient leur fichier de configuration Virtual Host présent sur le même serveur web. Si un fichier de configuration Virtual Host existe donc sous le nom de machine indiqué dans le « Host », une réponse du serveur avec éventuellement la ressource demandée sera obtenue. Reprenons la figure 3 en changeant le « Host » et en supposant que la ressource /doodles existe sous www.google.cn:
Source : Orange Cyberdefense
Et voilà ! Nous venons de réaliser la technique de Domain Fronting !
En effet, le Domain Fronting consiste tout simplement à contourner des censures de sites web en dissimulant la réelle destination d’une connexion HTTP. C’est plus ou moins ce qu’on vient de faire à l’instant.
Enfin… vous avez dû remarquer que toutes les requêtes étaient en HTTP, ce qui pourrait être un peu contraignant : l’une des particularités de ce protocole est qu’il transmet toutes les informations en clair (sans chiffrement).
Si quelqu’un s’amusait à intercepter les communications pendant que nous utilisions la technique vue plus haut, il pourrait s’apercevoir que la valeur du Host a été modifiée pour communiquer avec un autre site web… et ça… nous préférerions l’éviter. Comment pourrait-on s’y prendre ?
Protocole HTTPS
Le protocole HTTPS n’est rien d’autre que le protocole HTTP encapsulé dans du TLS. Nous savons déjà ce qu’est le protocole HTTP. La deuxième partie, le TLS (anciennement appelé SSL), est un protocole de chiffrement : son but est de faire en sorte que le serveur web que nous contactons et que notre ordinateur et de facto navigateur web soient les seuls capables de lire et comprendre les données que nous échangeons. De plus le protocole HTTPS permet également d’assurer que la communication se fait entre les bons interlocuteurs. Pour cela, le TLS réalise une couche de chiffrement sur les requêtes/réponses que nous envoyons.
Source : Orange Cyberdefense
Avant de procéder à un quelconque chiffrement de requête, notre navigateur doit être en phase avec le serveur web en termes de protocole de chiffrement TLS. Pour cela, une première étape est réalisée entre notre navigateur et le serveur, appelée “négociation TLS”. Au cours de ce procédé :
- La phase de « Client Hello » envoyée par notre navigateur au serveur.
- Dans le cas où le serveur aurait plusieurs sites web configurés (comme le cas d’un CDN vu plus haut), il indique le nom de serveur qu’il souhaite contacter et avec lequel il voudrait réaliser une connexion chiffrée. La variable SNI (Server Name Indication) contient le nom de ce serveur.
- Celui-ci lui répond avec de nombreuses informations dont une : « Voici la liste des algorithmes de chiffrement que je comprends ».
- Le navigateur les vérifie…
- … compare la liste d’algorithmes fournie à la sienne…
- … et choisit un algorithme pour entamer la communication chiffrée.
- Il trouve un moyen d’échanger des clés avec le serveur, qui lui permettent de chiffrer et déchiffrer leur communication.
- A la fin de cette étape, plus aucune partie de la communication ne se fait en clair. Ils s’échangent des requêtes chiffrées que seuls eux deux peuvent déchiffrer.
- Si quelqu’un intercepte une telle requête chiffrée, il ne pourra pas lire le contenu de la requête à moins d’avoir une clé de déchiffrement dédiée.
Le SNI
Au cours d’un échange normal entre un client et un serveur, la valeur du SNI (Server Name Indication) est la même que celle du Host. C’est normal car le client souhaite établir une connexion chiffrée avec le serveur à qui il voudrait envoyer des requêtes.
La subtilité du Domain Fronting réside dans le fait qu’il est possible d’effectuer la négociation TLS (nom du serveur affecté au SNI) avec un nom de machine différent du nom de machine vers lequel les requêtes HTTPS sont envoyées. Il en résulte une négociation de la connexion TLS avec un serveur A suivie d’un échange de requêtes HTTPS avec un autre serveur B.
Vu que le paramètre Host ne pourra ensuite être inspecté par une autre entité que le serveur qui reçoit la requête (car c’est lui qui possède la clé de déchiffrement), nous pourrons donc « cacher » ce nom de serveur de toute sonde et ainsi communiquer avec lui de manière légitime.
Nous récapitulons cela dans la figure 5 :
Cette technique peut typiquement être utilisée lors des missions Red Team.
Red Team
Les entreprises souhaitent de plus en plus évaluer leur niveau de sécurité global (système d’information, physique, humain). Les missions Red Team permettent d’évaluer d’une part le niveau de sécurité d’un système d’information et d’autre part d’évaluer les actions des équipes de détection d’intrusion (SOC). Les attaques menées lors de ces missions peuvent donc être complexes et préparées de manière à les rendre indétectables.
Les entreprises clientes établissent le plus souvent des objectifs à atteindre par les équipes Red Team. En fonction de ces objectifs, des scénarios d’attaques réalistes sont mis au point afin de pouvoir éventuellement exfiltrer des données Les attaquants utilisent des serveurs de « Command and Control » appelés C&C pour communiquer avec les machines qu’ils ont compromises afin d’y tirer le maximum d’informations en post-exploitation. C’est là que la technique de Domain Fronting peut être intéressante.
En effet, si nous reprenons nos exemples précédents avec cette fois un site web appartenant à un attaquant, dont le nom de domaine est configuré dans un fichier VirtualHost d’un CDN.
Nous allons supposer que le serveur web de l’attaquant est à l’URL www.pierreantoine.tk et se trouve configuré sur le CDN Cloudflare.
Note importante : Depuis deux ans à peu près Cloudflare contribue à faire évoluer le concept de confidentialité et vie privée des utilisateurs à travers son concept de ESNI (Encrypted SNI). L’ESNI permet de dissimuler la valeur du « Server Name Indication » qu’un utilisateur désire contacter pendant l’établissement d’une connexion TLS puisque l’étape du « Client Hello » se déroule en clair. Comment ça marche ?
Tout se passe dans la résolution DNS du client ; en effet le serveur introduira une clé publique dont il possède la clé privée en guise d’enregistrements DNS que pourra requêter le client pendant sa résolution DNS. Le client, une fois en possession de cette clé publique en dérivera une clé symétrique qu’il utilisera pour chiffrer le paramètre SNI.
Le serveur détenant la clé privée correspondante pourra donc générer l’autre clé symétrique permettant de déchiffrer le SNI, rendant donc cette partie de la communication confidentielle entre le client et le serveur. Il est important de noter que cette extension ne marche qu’avec le protocole TLS1.3 pour la communication TLS chiffrée.
Une question légitime : ne suffit-il pas de voir la requête de résolution DNS du client pour connaître le nom du serveur et donc le SNI ? La réponse à cette question est le « DNS over TLS » (DoT). En utilisant ce protocole le client est sûr de réaliser une résolution chiffrée et d’être donc à l’abri d’inspections d’un tiers. Pour de meilleures explications, voici le lien du blog Cloudflare à ce sujet https://blog.cloudflare.com/encrypted-sni/ .
Pour revenir à notre sujet, lorsque l’attaquant utilise l’ESNI, il dissimule donc le serveur avec lequel il communique ; il peut également donner un SNI factice qui sera généralement celui du site « fronté ».
Retrouvons l’adresse IP de l’attaquant en consultant notre serveur DNS :
Effectuons une requête web sur le site de l’attaquant :
Le serveur web de l’attaquant étant configuré sur le CDN Cloudflare, il existe de fortes chances que ce soit sur un nœud dans lequel se trouvent configurés d’autres serveurs web. En jetant un coup d’œil sur tous les serveurs web configurés derrière cette adresse IP grâce à l’interface ipinfo.io, nous sommes en mesure d’en lister quelques-uns. Un serveur a particulièrement attiré notre attention, il s’agit du site jeandidier.tk (pour les soucis de l’exemple) et nous le désignerons comme le site « fronté ». Voyons à quoi ressemble ce site légitime :
L’attaquant pourrait utiliser le Domain Fronting pour faire croire que les machines qu’il a compromises communiquent avec un des multiples serveurs web configurés sur le CDN Cloudflare, en l’occurrence le serveur web jeandidier.tk.
Voyons la requête que ferait un des ordinateurs compromis :
Nous pouvons observer que le SNI entré par la machine compromise est celui du site jeandidier.tk cependant l’ESNI (Encrypted SNI) est celui de l’attaquant c’est-à-dire pierreantoine.tk.
Regardons de plus près le paramètre http Host :
Intéressons-nous aux captures réseaux pour savoir ce qu’il en résulte :
La valeur du SNI qui apparaît est en effet celle du serveur légitime que nous voulons faire semblant de contacter. Enfin nous nous intéressons à la réponse du serveur contacté par l’utilisateur :
L’attaquant arrive donc à communiquer avec son serveur (C&C) à partir de l’ordinateur et en ayant cependant un profil de communication réseau qui semble légitime. Il pourrait utiliser cette technique pour de l’exfiltration de données à travers le réseau de la victime.
Comment lutter contre le domaine fronting ?
Le moyen de prévention le plus efficace à ce jour serait une inspection complète des différentes requêtes HTTP(S). Pour ce faire la méthode de l’inspection SSL pourrait être une bonne approche.
Une manière efficace de lutter contre le domain fronting serait l’inspection des paquets HTTPS à la volée. En effet la technique de SSL/TLS inspection pourrait être utilisée pour inspecter dans les détails les connexions établies par les utilisateurs d’un domaine/entreprise et internet. Une contrainte relative à cette technique serait inhérente même à son principe de fonctionnement. En effet, le serveur ou intercepteur devrait donc arriver à faire correspondre plusieurs connexions chiffrées avec des serveurs sur internet, avec celles de ses utilisateurs d’entreprises. Ce qui demande une capacité de charge considérable sans ralentir le trafic.
Cependant, dès lors qu’il est possible de déchiffrer et avoir connaissance des serveurs contactés sur internet, il devient simple de les interdire ou les autoriser.
Pour connaître son niveau de sécurité, quoi de mieux qu’un test d’intrusion en conditions réelles ? Découvrez nos offres d’audits techniques en cliquant ici.
