Malware JS : exfiltrez vos données via les DNS !

[Anonyme77]

Exfiltrez vos données via les DNS grâce au Malware JS

Quand on utilise un réseau wifi public, il faut toujours bien penser à sécuriser son accès à internet.

Comme tout bon hackadémicien, on pourrait se forcer à utiliser des sites en HTTPS et, mieux encore, à utiliser un plugin pour navigateur qui force ce protocole.
Par exemple

<a href="https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/">HTTPS Everywhere</a>

Cependant, nos accès à internet sont ils vraiment sécurisés de la sorte ?
On pourrait penser que oui, que c'est un bon début et qu'une bonne protection est déjà mise en place.

Et bien cette année, deux Hackers de la BlackHat nous ont montré que tel n'est en fait pas le cas.
Certaines informations telles que des informations peuvent toujours être dérobées.

Comment ? C'est ce que nous allons découvrir aujourd'hui.

I - PAC et WPAD, ces acteurs méconnus
Avant de présenter la faille et son fonctionnement, replongeons nous un peu dans nos cours du réseau.
Plus précisément dans la configuration du proxy sur un navigateur d'une machine client.

Vous avez séché vos cours de réseau et vous ne rappelez plus ce qu'est un proxy ?
Venez ici pour un petit rappel.

Ça va tout le monde voit ce que c'est maintenant ?
Lançons nous !

Pour configurer l'utilisation d'un proxy dans un browser, il existe plusieurs solutions :

• On configure l'accès au proxy à la main : Cette solution n'est pas pratique du tout, surtout en entreprise ou chaque machine devrait être configurée. Une par une. Imaginez le temps nécessaire.
• On récupère un PAC (proxy auto config) file sur le réseau : Cette solution est pratique. En effet, si on change les paramètres serveur du proxy. Il n'y a qu'un endroit à modifier et ce sont tous les clients qui s'adaptent.

1. Comment récupérer un pac file ?
Encore une fois, il existe deux manières de récupérer un pac file.

La première consiste a entrer manuellement l'url du pac file sur le réseau via une URL.
Grâce à cette url, le browser récupère le fichier et l'utilise.
Voici un exemple d'écran permettant de faire cette configuration :

La seconde technique consiste à utiliser la fonctionnalité nommée WPAD pour (Web Proxy Auto Discovery).
De cette manière, le browser commencera par faire une requête au DHCP afin de savoir si ce dernier contient dans sa configuration un lien vers le pac file.
Si le DHCP ne connait pas cette url, le browser fera en dernier recours une requête DNS à l'url wpad.domain/wpad.dat

Voici un écran de réglages pour cette seconde option :

Comme on peut le voir ici, c'est le navigateur qui va faire tout le travail !

2. Que contient un pac file ?
Nous avançons.
On sait maintenant à quoi sert un pac file et également comment en récupérer un.
Mais finalement, que contient il réellement ? Comment fait il pour faire toute la configuration ainsi tout seul ?

Un pac file est composé de code Javascript.
Cependant dans ce fichier, le langage est très limité.
En effet, dans celui-ci, pas d'objet Window ou même document !
Pas de fonction sur le DOM non plus donc.

Les seules fonctions disponibles sont celles-ci :

• Quelques fonctions réseaux : dnsDomainIs, isInNet, isPlainHostName, localHostOrDomainIs, dnsDomainLevels
• Quelques autres : dnsResolve, isResolvable, myIpAddress
• Quelques fonctions utilitaires : weekdayRange, dateRange, timeRange, shEpxMatch

Même la très fameuse fonction alert(), connue par tous les développeurs javascrit, n'est pas supportée par tout les browsers.

Ce fichier représente donc un peu le désert du javascript.
Cependant, pour que le pac file soit valide une fonction particulière doit y être implémentée.
C'est elle qui sera appelée par le browser pour connaitre la configuration de proxy à utiliser.

Évidement, d'autres fonctions peuvent également être implémentées mais celle-ci est particulière et obligatoire.
Voici son prototype :

FindProxyForURL(url, host)

Elle doit retourner une chaine de caractère tel que (par exemple) celle-ci :

"PROXY proxy.example.com:8080; DIRECT"

Cette chaine indique d'utiliser le proxy défini à l'adresse proxy.example.com et de s'y connecter sur le port 8080.
Au cas où ce dernier né répondrait pas, cette configuration dit au browser de tenter une connexion directe à l'url demandée.

II - La faille
La faille est liée au code javascript de ce fichier.

Vous n'avez pas d'idée ?

On sait que la fonction FindProxyForURL doit être implémentée et aussi que d'autres fonctions annexes peuvent être définies et utilisées.

Souvenez vous, une des fonction utilisable est dnsResolve qui permet de faire des requêtes DNS.
Hors, une requête DNS pourrait aider à faire transiter des données.

Quelles données me direz vous ?
Après tout, nous sommes en HTTPS non ?

Et bien ces données peuvent celles définies dans l'URL par exemple.
Et bien oui, FindProxyForURL reçoit l'url demandée par le navigateur !

Hors, les urls contiennent des tokens de connexion, des informations de recherche Google, ...

1. Un exemple simple
Imaginons que nous sommes infectés par un pac file frauduleux.

Ce dernier nous renvoie vers un proxy mais en profite pour voler nos informations de la manière suivante :

1. Il découpe l'url reçue par FindProxyForURL afin de récupérer les informations intéressantes. Admettons qu'il récupère mon pseudo (anonyme77) et mon mot de passe (SuperPassword) qu'un développeur maladroit à fait transiter dans l'url
2. Il fait une requête DNS à anonyme77.SuperPassword.serveurpirate.com
3. Il envoie la requête au proxy
4. Le proxy transfert la requête et nous envoie le résultat

Le résultat attendu est là.
Nous avons bien reçu notre page et ce de manière totalement transparente.
Cependant, dans l'entre fait l'identifiant et le mot de passe ont également été volés !

2. Et si on faisait encore plus fort ?
Voler des informations dans des URLs, c'est déjà très bien.
Le problème, c'est que tout les browsers et toutes les urls ne sont pas formés et ne réagissent pas de la même manière.
En plus, le découpage et l'envois des informations peut engendrer des latences dans le surf.

Nos deux hackers sont donc allés encore plus loin dans leurs recherches.

Ils ont permis un contrôle de la machine du client.
Comment ? Toujours via le DNS !

Pour ce faire, ils ont modifiés les réponses DNS (expliquées précédemment) envoyées par le serveur afin que ce dernier envois des commandes à la machine client.

Ces commandes sont ensuite interprétées par la function javascript eval.
Cette fonction permet un maximum de flexibilité dans les commandes envoyées au client dans la mesure où cette fonction javascript permet d'évaluer, ... du javascript.

Ainsi, il pourrait être possible de :

• Voler bien des informations informations (cookies, sessions, ...)
• Récupérer des données sur la machine du client
• Stocker des données sur la machine du client
• ...

3. Suis-je vulnérable ?
Cette faille étant liée à la configuration de proxys dans l'OS ou le navigateur, vous ne pouvez pas être vulnérable si vous n'en utilisez pas.
Si toutefois vous en utilisez quand même un, soyez certains de bien utiliser un proxy que vous connaissez, en qui vous avez confiance et que vous configurez à la main.

III - Comment se protéger de cette faille ?
Pour se protéger de cette faille, il existe plusieurs solutions et à plusieurs niveaux :

• Au niveau utilisateur : désactiver WPAD dans les réseaux inconnus et si possible utiliser un browser qui affiche le moins possible d'informations dans l'URL
• Au niveau de l'entreprise : Ne pas utiliser WPAD et vérifier qu'il est bien désactivé dans le backend
• Du côté serveur et développement : Enlever les informations de connexions des URLs et en mettre le plus possible dans le corps de page ou les cookies.

IV - Conclusion
Cette attaque est une preuve de plus qu'il ne faut jamais faire confiance à un réseau inconnu.
Un peu de défiance peut parfois vous sauver de bien lourds problèmes.
La sécurité est une habitude à prendre, une chose à laquelle il faut toujours penser.

Il faut ici bien se rendre compte qu'on ne parle pas ici d'une attaque sur HTTPS.
On ne casse pas de chiffrement. On ne fait que récupérer des informations déjà disponibles et <b>non chiffrées</b>.
Le surf en HTTPS ne nous protège donc pas de tout.

Comme toujours je suis disponible pour toutes vos questions.
N'hésitez pas à me contacter !

Sources
https://n0where.net/poc-javascript-malware-pacdoor/
https://fr.wikipedia.org/wiki/Fichier_.PAC
https://en.wikipedia.org/wiki/Web_Pr...overy_Protocol
https://www.blackhat.com/docs/us-16/...Unholy-PAC.pdf
https://github.com/SafeBreach-Labs/pacdoor
http://arstechnica.com/security/2016...ows-and-linux/