Le pharming et la comparaison de pages webs

Le pharming et la comparaison de pages webs

Le pharming

Les attaques de pharming sont une version sophistiquée des attaques de phishing. L’objectif est le même, à savoir : voler des informations confidentielles aux Internautes telles que des login, mots de passe, numéros de carte bancaire, etc. D’un point de vue technique, la mise en œuvre de ce type d’attaque diffère quelque peu : il faut certes la mise en ligne d’un site web contrefait mais, basée sur une corruption DNS réalisée en amont, l’attaque est cette fois-ci totalement imperceptible à l’utilisateur (sous réserve que l’imitation visuelle de la page web affichée soit de bonne qualité). En effet, grâce à une corruption/redirection effectuée au niveau DNS, l’utilisateur est automatiquement redirigé vers le site web contrefait dès lors qu’il tente d’accéder à son site habituel. Pourtant l’URL visitée est bien l’URL légitime. Ce type d’attaque peut être considérée comme plus passive que le phishing, car elle ne nécessite pas de campagne de diffusion incitant les Internautes à se rendre sur le site contrefait. Néanmoins elle n’en est que plus redoutable car difficilement détectable. Avant de s’intéresser aux attaques de pharming et aux moyens de prévention/détection associés, revenons à quelques rappels/considérations DNS nécessaires à la bonne compréhension de la suite de ce chapitre. 

Rappels DNS 

Dans le monde de l’Internet, les adresses IP sont utilisées afin d’échanger des messages entre machines. Sachant qu’une adresse IP est constituée de 4 à 8 blocs d’octets séparés par des caractères spéciaux1 , leur manipulation et leur mémorisation n’est pas tâche aisée. Le protocole DNS est donc un élément crucial de l’architecture réseaux d’Internet. A l’image de l’annuaire téléphonique qui permet de lier nom d’abonné et numéro de téléphone, le protocole DNS permet de faire la corrélation entre une adresse IP et le nom de domaine (ou plus exactement le FQDN2 ) associé. Afin de simplifier les échanges au travers d’un réseau, il est en effet plus simple d’utiliser un nom de domaine (p.ex. www. it-sudparis.eu) plutôt qu’une adresse IP (p.ex. 157.159.11.8). Par la même occasion, l’administration réseaux qui inclut des besoins de partage de charge ou une migration de serveurs s’en retrouve simplifiée. Le protocole DNS utilise le port 53, généralement en UDP pour les requêtes et TCP pour les transferts de zone2 . Il s’appuie sur les RFC fondatrices 1034 (concepts) et 1035 (implémentation). Celles-ci sont complétées par les RFC 2136, 2181, 4033 et 61953 qui apportent des spécifications complémentaires sur les enregistrements RR2 et introduisent les notions de sécurité. 

Architecture DNS

 Le DNS [AFNa] [Oll05] s’appuie sur une architecture client/serveur reposant sur 3 dispositifs : – Un espace de noms hiérarchique permettant de garantir l’unicité des noms de domaine, – Un système de serveurs distribués permettant la diffusion de ces noms de domaine, – Et un système client permettant de résoudre les noms de domaine. 

Espace de noms hiérarchique 

 La structure hiérarchique des noms de domaine est conçue comme une arborescence, ayant pour origine une racine représentée par un « . », afin que chaque nom d’hôte (c.-à-d. machine) soit unique. L’espace de nommage, c.-à-d. le chemin dans l’arbre inversé pour un nom d’hôte donné, comporte typiquement 4 niveaux : racine, TLD, domaine et hôte (cf. figure 4.1). Chaque nom d’hôte (sur 63 caractères maximum) doit être unique dans le domaine concerné. Un domaine peut être éventuellement re-découpé en sous-domaines intermédiaires, tant que le nom d’hôte complet (appelé FQDN et constitué des différents niveaux d’arborescence séparés par des « . ») n’excède par 255 caractères et 127 niveaux d’arborescence. Chaque responsable de domaine dispose d’une totale liberté de nommage de ses sous-domaines. Pour un minimum de structure, les TLD – également appelés domaines de premier niveau – suivent une codification spécifique établie par l’ICANN (pour Internet Corporation for Assigned Names and Numbers). Ils sont par ailleurs gérés soit directement par l’ICANN, soit par des organismes délégués appelés registres. Enfin, les noms de domaine sont achetés auprès d’un bureau d’enregistrement des domaines, appelé registrar. A noter qu’il est possible de consulter les données contenues par les registres via l’utilisation du protocole WHOIS (RFC 3912, port TCP 43). Les TLDs se décomposent en plusieurs groupes. Les plus connus sont les g-TLD pour generic TLD (p.ex. .COM, .ORG, .GOV, etc.), et les cc-TLD pour country-code TLD représentatifs d’un pays ou d’une zone géographique (p.ex. .FR pour la France, .EU pour l’Europe, etc.).

Système de serveurs distribués 

 Chaque domaine dispose d’un serveur DNS (au minimum), afin d’annoncer sur Internet les combinaisons FQDN/adresses IPs qu’il détient. Ainsi, il existe des centaines de milliers de serveurs DNS à travers le monde, chacun d’entre eux ne contenant que peu d’informations. A chaque requête DNS effectuée, ce sont en fait de nombreux serveurs DNS qui sont sollicités. On dit de l’architecture DNS qu’elle est un système décentralisé, reposant sur la délégation de domaine. En effet pour que l’ensemble de l’arborescence DNS soit gérable, à chaque niveau (nonterminal) on associe une zone par entité (cf. figure 4.1). Chaque zone est responsable, par délégation de la zone supérieure, de répondre aux requêtes DNS concernant les entités qu’elle détient (c.-à-d. de niveau inférieur). Traditionnellement, chaque zone contient (jusqu’à) 3 serveurs DNS (cf. figure 4.2) : un serveur primaire contenant les informations de zone (on parle alors de serveur « autoritaire » pour la zone), un serveur de noms secondaire généralement utilisé pour la continuité de services, et un serveur cache qui mémorise les réponses aux précédentes requêtes DNS avec une durée de vie limitée. Les transferts d’informations depuis le serveur DNS primaire vers le serveur DNS secondaire sont appelés transferts de zone.dans sa base, qu’elles concernent ou non sa zone. Les informations de sa propre zone sont concentrées dans un fichier (nommé fichier de zone) qui contient plusieurs enregistrements appelés Resource Record (RR), comme le présente la figure 4.2. Chaque enregistrement RR contient 5 informations (cf. tableau 4.1) : le FQDN, le Type d’enregistrement, la Classe, le TTL (pour Time To Live), ainsi que l’adresse IP associée. Les types d’enregistrements servent à donner une indication sur la teneur de l’hôte. Les plus connus sont : MX (pour Mail eXchange) utilisé pour décrire un serveur mail, NS (pour Name Server) utilisé pour décrire le serveur « autoritaire » de la zone, ou A (pour Address) utilisé pour décrire une machine/un hôte IPv4 (p.ex. un serveur web, un serveur ftp, etc.). Le TTL permet, quant à lui, d’associer une durée de vie (exprimée en secondes) à chaque enregistrement. Enfin, la Classe permet de décrire le système associé à l’enregistrement. On utilise ici IN pour indiquer Internet.

Système client

Le système client DNS, permettant de réaliser l’opération de résolution de domaine, est appelé résolveur (ou resolver en anglais). Installé côté client, il est appelé par les applications du système en vue d’effectuer les requêtes DNS. Ainsi, par l’intermédiaire du résolveur, une application souhaitant contacter un hôte par son nom de domaine envoie une requête au serveur DNS dont il détient l’adresse (typiquement celui du FAI, automatiquement configuré via DHCP, dans le cas d’un réseau personnel).