PROJET AUTOBLOG


Shaarli - Les discussions de Shaarli

Archivé

Site original : Shaarli - Les discussions de Shaarli du 23/07/2013

⇐ retour index

DNS Rebinding

lundi 29 juin 2015 à 17:08

« Le DNS Rebinding vise à permettre à un attaquant situé dans un réseau d'accéder à une application web située dans un autre réseau. Le cas typique est la tentative d'accès à une application web du réseau interne d'un organisme par un attaquant situé sur Internet. Pour ce faire, l'attaquant contourne certains mécanismes de cloisonnement des navigateurs web en employant des réponses DNS fluctuantes.

La communication entre l'attaquant et l'application web interne s'effectue à travers le navigateur connecté aux deux réseaux et employé comme plateforme de rebond.

Pour cela, l'attaquant piège l'utilisateur de façon à lui faire charger un code malveillant, généralement écrit en JavaScript, dans son navigateur. Ce code a alors pour objectif de récupérer les données du réseau inaccessiblement directement par l'attaquant pour ensuite les retransmettre sur le réseau où se situe ce dernier.

Les navigateurs protègent les utilisateurs contre des attaques venant de pages malveillantes, en isolant chaque site les uns des autres. Pour cela, une politique de restriction d'accès entre sites, appelée Same Origin Policy (SOP), est appliquée.

La SOP assure que chaque site est isolé en fonction de son « origine ». Cette notion d'origine est définie par le triplet protocole, domaine, et port. Par exemple, le triplet pour http://ssi.gouv.fr est le protocole http, le nom de domaine ssi.gouv.fr et le port 80.

Une page chargée depuis http://attacker.com/ n'aura donc pas le même triplet que http://intranet.local. Un script malveillant chargé depuis http://attacker.com ne pourra donc pas accéder aux applications web internes hébergées sous http://intranet.local/.

Le DNS Rebinding a pour objectif de contourner cette protection en faisant croire au navigateur que l'adresse IP à contacter pour accéder au site http://attacker.com/ n'est plus celle du site de l'attaquant, mais celle de l'application web interne ciblée. Ainsi, le triplet SOP reste identique mais les requêtes HTTP effectuées par le code malveillant sur la page http://attacker.com/ seront directement envoyées à l'application web interne.

Pour réaliser ce changement, l'attaquant fait varier l'adresse IP renvoyée par le service de résolution de noms de domaine DNS afin que le nom de domaine attacker.com pointe alternativement sur une machine contrôlée par l'attaquant, puis sur une machine à laquelle ce dernier n'a pas accès directement.

Il convient de noter que même si la navigateur utilisé comme plateforme de rebond dispose d'un cookie permettant l'accès à une session préalablement authentifiée auprès de l'application hébergée sur le réseau interne, l'attaquant effectuant un DNS Rebinding ne peut en tirer parti. En effet, le cookie de session est associé au nom de domaine légitime de l'application web ciblée et non à attacker.com, et n'est donc pas automatiquement adjoint par le navigateur.

[...]

L'attaquant obtient, par l'intermédiaire du navigateur de sa victime, la capacité d'interroger un serveur web hébergé sur un réseau auquel il ne peut pas accéder directement. Le navigateur joue alors le rôle de mandataire (proxy).

[...]

La protection principale intégrée dans les navigateurs est l'épinglage des réponses DNS (DNS pinning).

Le principe est le suivant : l'association du nom de domaine à son adresse IP est conservée par le navigateur pendant une durée prédéfinie, issue d'une politique propre à chaque navigateur, voire à chaque version de navigateur.

Cette protection présente des inconvénients. En effet, elle viole le protocole DNS et la volonté des administrateurs des noms de domaine légitimes qui configurent des durées de mises en cache courtes, parfois à dessein. C'est notamment le cas pour des techniques de répartition de charge (DNS round robin), de reprise à chaud (failover actif), ainsi que dans le cadre de contre-mesures aux dénis de service distribués et aux plans de reprise ou de continuité d'activité, suite à un incident.

[...]

Protections au niveau de l'infrastructure réseau

Certains résolveurs DNS tels que OpenDNS, Bind9 ou Unbound peuvent être configurés pour filtrer les réponses DNS suspectes reçues depuis l'Internet et ainsi supprimer celles contenant des adresses IP internes.

[...]

Protections au niveau de la configuration des postes clients
Ces guides préconisent l'utilisation d'un navigateur pour les accès aux réseaux internes et d'un deuxième navigateur pour la navigation sur Internet.

La mise en oeuvre de cette stratégie implique notamment que le navigateur ayant accès à Internet n'ait aucun moyen de contacter le réseau interne. Cela peut s'effectuer en appliquant une politique forçant le passage par un serveur mandataire, ou par l'emploi d'un pare-feu tenant compte des processus pour appliquer sa politique de filtrage.

[...]

Protections au niveau du serveur applicatif
Authentification

Une première étape est d'obliger une authentification par un mot de passe non prédictible avant d'accéder à l'application. Une authentification basée sur l'IP source est bien entendu inutile.
Protection de l'hôte virtuel par défaut

Une autre défense consiste à s'assurer que l'hôte virtuel (VirtualHost) par défaut n'offre aucun service. Cet hôte virtuel est, en effet, le seul pouvant être atteint dans le cadre d'une attaque par DNS rebinding. Cette contre-mesure peut être appliquée de deux manières, avec le serveur Apache. »
(Permalink)


Liens Ecyseo 29/06/2015

Intéressant
(Permalink)