L’histoire d’une attaque par Phishing indétectable

Le fameux cadena vert affiché par les navigateurs n’est plus gage de sûreté! Un expert en sécurité a découvert une vulnérabilité permettant de tromper l’utilisateur en lui faisant croire qu’il se trouve sur un site fiable alors qu’en réalité il est sur un site contrôlé par un hacker. Cette vulnérabilité ouvre la porte à des attaques par phishing particulièrement vicieuses puisque indétectables, ou presque…

 

 

 

Lors de séances de sensibilisation, nous donnons des préconisations simples qui permettent de détecter une tentative d’attaque par Phishing et ainsi éviter de se faire prendre. Nous conseillons aux utilisateurs du système d’information de vérifier plusieurs éléments avant de continuer sur un site web “sécurisé” :

– Verifier le nom complet (Fully Qualified Domain Name) présenté par le navigateur et valider qu’il s’agit bien du site auquel l’utilisateur souhaite accéder,

– Verifier que le navigateur présente un cadena et/ou la mention “secure” avant d’autoriser une connexion au site,

– Refuser la connexion à un site web pour lequel le navigateur présente une alerte de sécurité (Phishing, Certificat invalide, …)

Ce sont quelques conseils simples qui permettent, s’ils sont correctement suivis, de limiter le nombre d’utilisateurs se faisant avoir par une attaque par Phishing.

Cependant, Xudong Zheng, un expert en sécurité, a récemment publié un article démontrant à quel point il était facile de réaliser une attaque par Phishing presque indétectable, même en suivant les conseils précédemment cités. L’expert utilise une attaque reposant sur l’utilisation de l’encodage Punycode et les Homoglyphes pour dissimuler l’URL réelle accédée par l’utilisateur.

Cette attaque est critique pour les entreprises car elle expose les utilisateurs du SI à des Phishing extrêmement difficiles à détecter. De plus, les attaques par homographes existent depuis plusieurs années mais les navigateurs Internet bénéficient en général de mécanismes de protections pour éviter qu’une telle exploitation soit réalisable.

 

Qu’est ce qu’un homoglyphe ?

 

Très bonne question, un homoglyphe est un caractère qui s’écrit de la même façon qu’un autre mais qui est différent. On pourrait croire qu’il s’agit d’une phrase sortie tout droit d’un cours de philosophie, et pourtant, cela est réellement possible. Pour l’illustrer, prenons l’exemple du caractère “i” sur plusieurs polices de caractères différentes. Dans certains cas, on représente le “I” majuscule par un “l” minuscule.

L’homoglyphe est apparu notamment à l’ère de l’informatique en faisant référence aux polices de caractères et à la manière de représenter des caractères appartenant à une langue étrangère.

L’expert s’appuie sur la représentation de certains caractères de l’alphabet cyrillique pour obfusquer l’URL présentée dans le navigateur et faire croire à l’utilisateur qu’il se connecte sur le site “apple.com”.

Un mot composé de un ou plusieurs homoglyphes est un homographe.

 

Qu’est ce que le Punycode ?

 

Le Punycode est un mécanisme d’encodage permettant de représenter des caractères spéciaux  unicodes en utilisant uniquement un sous-ensemble de caractères ASCII à savoir les 26 lettres de l’alphabet latin, les 10 chiffres et le caractère “-”.

Initialement, les noms de domaine ne supportaient que les caractères ASCII. Pour contourner cette limitation, il fallait trouver un mécanisme permettant de représenter les caractères non-ascii. Cela a donné naissance à l’internationalisation des domaines et le punycode est une des solutions permettant d’arriver à cette fin.

En utilisant le Punycode, on s’assure de toujours présenter des caractères supportés par les services de résolution de noms sur Internet. Les domaines écrits dans des langues étrangères ou utilisant des caractères spéciaux sont alors normalisés en utilisant ce type d’encodage.

 

Qui est touché par cette attaque ?

 

Vous êtes un utilisateur de Firefox, Chrome ou Opera? Alors vous êtes probablement vulnérable à cette attaque!

Ce type d’attaque a déjà été rapportée par le passé mais l’impact médiatique n’avait jamais été aussi grand qu’avec cette publication.

Google a déjà annoncé qu’un correctif serait intégré dans Chrome 59 et qu’il serait également inclus dans Chrome 58. Mozilla semble, quant à lui, plus indécis sur la correction ou non de cette vulnérabilité dans son navigateur Firefox.

Les navigateurs Internet Explorer sont vulnérables si plusieurs langages sont activés dont celui utilisé par le pirate (le cyrillique dans le cadre du PoC).

 

Un Proof of Concept en 3 étapes

 

    • Enregistrer un nom de domaine

L’expert a tout d’abord enregistré un domaine “www.аррӏе.com” en utilisant l’encodage Punycode donnant le nom de domaine: www.xn--80ak6aa92e.com.

    • Générer un certificat SSL valide

Il a ensuite généré un certificat SSL valide auprès d’une autorité de certification publique, en l’occurence “let’s encrypt”.

    • Monter un serveur web

La dernière étape est la plus simple, il suffit de mettre en ligne un serveur web et lui assigner le nom de domaine précédemment choisi.

L’expert a ainsi mis en ligne un service web présenté comme étant le site du géant américain “www.apple.com” pour une grande partie des utilisateurs sur Internet.

 

Xudong Zheng détaille la vulnérabilité et le proof of concept qu’il a mis en place dans un article de blog.

Quel est l’impact ?

 

Comme nous l’avons mentionné précédemment, il faut former un homographe du domaine que l’on souhaite imiter. Il se trouve que l’alphabet cyrillique comporte un certains nombre de caractères similaires au nôtre, tels que:

  • a (\u0430)
  • p (\u0440)
  • l (\u04CF)
  • e (\u0435)
  • c (\u0441)
  • x (\u0445)
  • s (\u0455)
  • y (\u0443)
  • j (\u0458)
  • I (\u0456)
  • h (\u04BB)
  • o (\u043E)

Il y a probablement beaucoup plus d’homoglyphes dans l’unicode, mais ceux-ci sont déjà bien suffisant pour couvrir de nombreux noms de domaine. Nous avons donc voulu mesurer l’impact réel de cette vulnérabilité et, pour cela, nous avons récupéré la liste du top 1 million de sites web depuis Alexa. Nous avons ensuite récupéré les noms de domaine ne contenant que les lettres ayant un équivalent quasi exact dans l’alphabet cyrillique, auquel nous avons également ajouté le caractère ‘-’ (‘\\u2010’). Voici ce qu’il en ressort:

  • 14870 sites sont directement impactés
  • Parmi ces sites se trouvent de grands noms tels que Apple, Paypal, Yahoo ou HP.

L’outil permettant d’arriver à ce résultat est disponible dans notre dépôt sur GitHub.

L’impact est d’autant plus grand en raison de la facilité à exploiter cette vulnérabilité. En effet, comme nous l’avons vu dans la section précédente, il suffit de remplacer chacun des caractères par son équivalent en cyrillique, puis de calculer son punycode avec, par exemple, https://www.punycoder.com/.

Avez-vous été victime de ce type de phishing ?

 

Il existe plusieurs moyens de savoir si vous avez été victime ou non d’une attaque par Phishing de ce type.

L’une d’elle consiste à analyser les logs de vos proxy web. Les noms de domaine étranges devraient ressortir de la liste des requêtes HTTP réalisées par vos utilisateurs.

Cependant, nous le savons bien, on ne peut pas espérer trouver toutes les informations dans les logs de ces équipements puisqu’en général, un certain nombre de machines sur le réseau contournent (ou tentent de contourner) ce système de sécurité.

L’autre option est alors d’analyser les requêtes DNS réalisées par les différents équipements. Chez e-Xpert Solutions, nous avons activé le logging des query DNS sur nos serveurs de noms. Voici un exemple d’une entrée dans le fichier de logs:

01-Apr-2017 07:42:00.000 queries: info: client 192.168.1.42#64052: query: www.google.com IN A +ED (192.168.1.3)

On peut alors facilement extraire, à partir de ces logs, les noms de domaines en utilisant la commande suivante :

zcat /var/named/chroot/var/log/querylog*.gz | sed -e ‘s/.*query: \\(.*\\) IN.*/\\1/’ | grep -v “in-addr.arpa” | sort -u >> domains.txt

La liste des domaines est alors extraite et sauvegardée dans le fichier domains.txt. Nous pouvons encore lancer une nouvelle analyse sur ce fichier pour découvrir cette fois la liste des domaines encodés avec du Punycode et nous obtenons le résultat suivant:

xn--foroporlaniez-skb.org.ar

En supposant que vous êtes au bénéfice d’un SIEM comme, par exemple, Splunk, il devient facile de retracer les résolutions de hostnames encodés avec du Punycode depuis les X derniers mois ou années tenant compte de l’historique de logs sauvegardés dans la solution.

Comment protéger ses utilisateurs ?

 

Encore une fois, il n’y a pas une réponse à cette question, mais plutôt un éventail de possibilités qui s’offrent à vous.

La méthode brutale

Une des solutions pourrait être l’interdiction de visiter des sites dont les noms ont été internationalisés. C’est un peu drastique et risque de causer des frustrations, voir des problèmes métiers si l’accès à certains de ces sites est absolument nécessaire. Ce n’est pas une solution gérable à long terme.

La méthode passive

L’autre solution est d’attendre la sortie d’un correctif pour les différents navigateurs et s’assurer que ces derniers sont correctement patchés. Malgré tout, il arrive souvent qu’un administrateur installe d’anciennes versions de Firefox ou Chrome et notamment dans le cadre des “Portables apps” qui ont toujours quelques versions de retard.

La méthode hybride

C’est nécessairement la méthode que je recommande activement. En suivant les trois étapes suivantes, vous pourrez limiter les risques et agir rapidement en cas d’attaque.

Activer le logging des query DNS sur les serveurs de noms, stocker les logs et les analyser régulièrement pour identifier des domaines encodés avec du Punycode,

Mettre en place des mécanismes proactifs qui identifient ce type d’attaques et bloquent l’accès aux sites web concernés. Nos solutions technologiques nous permettent d’actionner ces mécanismes et ainsi réduire la surface d’attaque possible.

Mettre à jour les navigateurs lorsqu’un correctif est disponible et interdire l’utilisation de versions antérieures de ces navigateurs (en filtrant les User-Agent dans les requêtes HTTP par exemple).

Vous craignez une attaque ou pensez avoir déjà subi furtivement ce type d’attaque ? Nos experts peuvent très certainement vous aider et vous accompagner dans l’identification de ces risques et à la mise en place de solutions de remédiations adéquates.

Here you can create the content that will be used within the module.

Publication Github


Yann Desmarest

Yann Desmarest

Innovation Center Manager