Détection du pharming côté client vers une redirection du GET HTTP

Détection du pharming côté client vers une
redirection du GET HTTP

Notre proposition de détection du pharming côté client se base sur une étude du code source HTML de la page web, combinée à des requêtes DNS. Dans le Chapitre 5, nous avons présenté une première solution de détection du pharming au sein de laquelle la page web visitée est comparée à une page web dite de référence, grâce à la substitution du nom de domaine par une adresse IP au sein de l’URL légitime. Bien que les résultats obtenus au travers de cette première proposition se soient avérés encourageants, ils ont également mis en exergue un certain nombre de faiblesses de l’approche proposée. Dans ce chapitre, nous développons donc une seconde approche qui améliore la proposition précédente. Nous y expliquons notamment les modifications majeures apportées pour la récupération de la page de référence, désormais basée sur une redirection de la requête HTTP vers une adresse IP déterminée (c.-à-d. l’adresse IP de référence). Nous y détaillons également la combinaison de multiples techniques d’analyse du code source de la page web, afin de déterminer un seuil de décision. Les tests réalisés dans cette seconde proposition portent sur 328 URLs de login légitimes, évaluées depuis 11 localisations géographiques réparties sur 5 continents, ainsi que sur 75 nouveaux couples de pages légitimes-contrefaites. Ensuite, nous explicitons les limitations associées aux deux approches proposées ainsi que les verrous techniques demeurant à l’issue de notre étude (cf. section 6.2). Ce chapitre fait partie de nos contributions : cette seconde proposition a été publiée et présentée à la conférence Network and System Security (NSS) en Septembre 2011 [GL11]. 6.1 Seconde proposition : vers une redirection du GET HTTP Notre seconde proposition a été élaborée avec le quadruple objectif : de pallier les défauts et problèmes majeurs rencontrés dans la première approche, d’augmenter la base de résultats, d’améliorer les techniques de comparaison et enfin, de définir un seuil de décision. Les verrous demeurant à l’issue de notre première proposition sont : – un taux d’échec trop élevé pour la récupération de la page de référence PageRef, – la difficulté d’identification et d’élimination des pages d’erreur, – et enfin, l’absence d’identification de l’adresse IPdef, utilisée pour la récupération de la page par défaut PageDef. 6.1.1 Fonctionnement général En premier lieu, nous nous sommes attachés à répondre au problème majeur du taux d’échec de récupération de PageRef. Si nos hypothèses sur les causes probables de ce taux d’erreur (cf. section 5.3.5.3) s’avèrent exactes, nous devons trouver un moyen de transmettre l’information du FQDN demandé, lors de la requête de l’URL de référence. La piste idéale se révèle être la réécriture du paquet afin de conserver l’URL d’origine intacte (et donc transmettre le FQDN), tout en imposant l’adresse du serveur destination. En conséquence, le fonctionnement de notre seconde proposition se déroule de la manière suivante (cf. figure 6.1) : Pour chaque page de login, le FQDN de l’URL visitée est extrait afin de générer deux requêtes DNS : l’une est envoyée au serveur DNS par défaut (DNSdef ), l’autre est adressée au serveur DNS de référence (DNSref ). DNSdef retourne plusieurs adresses IP, dont celle utilisée pour l’affichage de la page web dans le navigateur (IPdef ), tandis que DNSref retourne une ou plusieurs adresses IP (IPref ), incluant ou excluant IPdef. Dans le cas où l’adresse IPdef est incluse dans la réponse IPref, le site est considéré comme légitime. Dans le cas contraire, nous procédons à l’analyse de la page web : – la page web visitée (PageDef ), telle qu’affichée dans le navigateur, est récupérée à partir de IPdef. – La page de référence (PageRef ) est récupérée grâce à l’envoi d’une requête GET HTTP, utilisant l’URL originale, à destination de IPref. Considérons l’exemple suivant : l’URL visitée par l’Internaute est https://www.amazon.com/gp/ yourstore?ie=UTF8&ref_=pd_irl_gw&signIn=1. La page affichée a été récupérée depuis le serveur web possédant l’adresse IP : 72.21.210.250 (IPdef ), adresse connue grâce à la technique de récupération de PageDef utilisée dans cette approche (cf. section 6.1.4). Le serveur DNS de référence interrogé retourne l’adresse IP : 207.171.166.252 (IPref ). La page de référence est alors récupérée en envoyant un GET HTTP, contenant l’URL https://www.amazon.com/gp/yourstore? ie=UTF8&ref_=pd_irl_gw&signIn=1, à l’adresse IP destination IPref : 207.171.166.252. Les codes sources HTML des deux pages webs (PageDef et PageRef ) sont ensuite comparés (cf. figure 6.1), grâce aux techniques énoncées en sections 5.2.2 et 6.1.5. Enfin, la légitimité de la page web visitée est déterminée en comparant le pourcentage de similitude obtenu entre les deux pages (PageDef et PageRef ) à un seuil de décision pré-défini. 

Définition du serveur de référence

Au vu des résultats obtenus précédemment, nous avons élaboré un nouveau scénario de définition du serveur de référence. L’utilisateur aurait alors le choix entre deux propositions : 1/ le choix du DNSref est laissé à son appréciation parmi une liste de serveurs prédéfinis (= choix exposé dans la première proposition), ou 2/ le programme sélectionne et utilise – de manière automatique et aléatoire – un serveur DNSref, parmi une liste de serveurs pré-définis. Cette sélection, qui serait renouvelée à chaque vérification d’une page de login, est proposée grâce aux résultats très similaires obtenus auprès des différents serveurs DNS de référence. L’avantage de ce deuxième scénario – qui serait celui recommandé – serait de proposer une meilleure résistance aux attaques (cf. section 4.1.2.1), grâce au choix aléatoire effectué pour DNSref, renouvelé à chaque vérification.

Conditions d’expérimentation 

Sur le même principe que celui utilisé lors de notre première proposition (cf. section 5.3.2), nous avons évalué l’efficacité de notre proposition à partir de deux types de comparaisons : – des comparaisons de couples de pages de login légitimes récupérées depuis plusieurs localisations géographiques et plusieurs serveurs DNS (c.-à-d. le serveur DNS par défaut de l’utilisateur ainsi que nos trois serveurs DNS de référence : OpenDNS, GoogleDNS et DNSAdvantage). L’ensemble des couples de pages légitimes ont été collectées entre Mars et Juin 2011. – des comparaisons de couples de pages de login légitimes-contrefaites, visuellement très similaires. L’ensemble des pages contrefaites (et légitimes associées) utilisées ici ont été récupérées entre Décembre 2010 et Juin 2011. Les tests effectués se sont ensuite déroulés en deux temps : – Une première analyse qui a deux objectifs : 1/ Mesurer l’efficacité de cette seconde proposition visà-vis de la précédente, tant au niveau des résultats IP que de l’analyse sur le code source HTML dans son intégralité, et 2/ Explorer de nouvelles techniques de comparaison pour n’en retenir que les plus pertinentes. Pour la suite du chapitre, cette première analyse sera nommée Analyses pour la définition des techniques de comparaison les plus pertinentes. – Une deuxième analyse visant à définir le seuil de décision ainsi que la méthode de comparaison finale des pages webs (à partir des techniques de comparaison retenues en première analyse). Pour la suite du chapitre, cette deuxième analyse sera nommée Analyses pour l’élaboration de la méthode de comparaison finale. 

Couples de pages légitimes

 Nous avons établi un panel de 328 URLs de login décomposé de la manière suivante : – 224 nouvelles URLs (dont 2 à FQDN commun). Ces 224 URLs ont été sélectionnées en utilisant les mêmes critères que précédemment, à savoir : diversifier les secteurs d’activités, multiplier les TLDs ainsi que les langages des pages webs. – et les 104 URLs à FQDN uniques utilisées dans la première proposition. L’intégration de ces 104 URLs a pour objectif d’avoir un premier indicateur de la variabilité temporelle des résultats obtenus précédemment (cf. sections 5.3.4.2 et 5.3.5.2). Classification des 328 URLs de login : Nous avons classifié les 328 URLs sélectionnées selon les 5 secteurs d’activités identifiés dans la première proposition, à savoir : banques, réseaux sociaux, e-commerce, email et autres (cf. section 5.3.2.1 pour plus de détails sur les classifications). La répartition des catégories, par ordre d’importance, reste identique à l’étude précédente, avec une nette prédominance des sites bancaires (cf. tableau 6.1). Les 328 URLs sélectionnées sont issues de 48 TLDs différents, divisables en 2 catégories : les cc-TLD et les g-TLD. Pour une meilleure lisibilité, les TLDs sélectionnés ont été regroupés par continent (cf. tableau 6.2). A nouveau, la répartition des TLDs reste à peu près similaire à l’étude précédente, même si leur nombre a plus que doublé. On constate également l’apparition d’un nouveau g-TLD : COOP pour Cooperative.