This page has been robot translated, sorry for typos if any. Original content here.

Scripting interdomaine

Introduction

L'idée d'écrire cet article m'est venue après qu'il était nécessaire de donner à un novice une référence à une explication détaillée et compréhensible de ce terme. Après avoir gravi les moteurs de recherche, j'ai été surpris de constater que trouver un tel article n'est pas assez facile. Le terme non plus n'a pas du tout été expliqué, soit en deux mots et en anglais :) . En attendant, les vulnérabilités de Windows de ce type se trouvent assez souvent et elles sont plus que graves! Par conséquent, dans cet article, j'ai essayé de décrire ce type d'attaques, les particularités de l'exploitation de ce type de vulnérabilités et de protection contre celles-ci, ainsi que de donner des exemples concrets, aussi détaillés et clairs que possible. Bien entendu, l'article a été écrit pour les débutants, mais j'espère que cela sera utile pour les lecteurs plus expérimentés.

Qu'est-ce que le script interdomaine?

Initialement, le script inter-domaines (CDS) était associé à des failles dans le modèle de sécurité de tous les "ânes" connus, à savoir Internet Explorer (IE). Cependant, depuis Les caractéristiques architecturales des navigateurs modernes ne diffèrent pas beaucoup les unes des autres, alors les attaques de ce type sont actuellement soumises à presque tous les navigateurs Web connus. Néanmoins, les différences existantes entre les programmes de cette classe conduisent au fait que le CDS le plus souvent trouvé est "indépendant du navigateur", par exemple, il fonctionne sur Internet Explorer, mais ne fonctionne pas sur Opera ou inversement.
La base des vulnérabilités telles que CDS est le concept de "domaine". Dans ce contexte, la signification de ce concept est quelque peu différente de celle généralement acceptée. "Domain" n'est pas seulement l'adresse du site Internet, ni même la "zone de l'espace de noms Internet hiérarchique" - ce concept dénote une certaine "limite de sécurité", qu'aucun script utilisateur n'est autorisé à dépasser.
La base du modèle de sécurité de tout navigateur Web est le principe selon lequel les ressources de différents domaines (pages, scripts, etc.) ne peuvent en aucun cas se croiser, c'est-à-dire pour accéder au contenu interne et aux données les uns des autres. Si cela était possible, par exemple, un script sur la page d'accueil du jeune pirate informatique de Vasya pourrait accéder aux données de la boîte aux lettres Mail.Ru d'un utilisateur sans méfiance que Vasya a attiré sur sa page. Ce serait amusant. :) !! De plus, selon l'architecture de Windows et les concepts de construction de navigateurs modernes, toute ressource réseau du réseau local et le propre système de fichiers du client sont également des «domaines», ce qui signifie qu'il est possible d'y accéder depuis des scripts comme n'importe quelle ressource sur Internet! En fait, c'est le système de fichiers local du client qui est le plus souvent la cible d'attaques inter-domaines.
Dans le même temps, l'interaction entre les ressources (pages et scripts) à l'intérieur du domaine (et de tous ses sous-domaines!) Est autorisée par le concept de sécurité Microsoft et n'est en principe pas limitée. Il est difficile de juger si c'est vrai ou non, mais qu'est-ce qui est si simple :) Et en même temps, les possibilités de navigation sur le Web augmentent, c'est certain.
Alors, qu'est-ce que le script inter-domaines? Dans le contexte de ce qui précède, ce terme peut être traduit par "script interdomaine"; "Le franchissement de limites de domaine par script" est une violation de cette ligne de sécurité chérie, dont l'accès donne accès aux données provenant d'autres domaines, y compris le système de fichiers local du client. Cette violation s'accompagne le plus souvent de la possibilité d'écrire et d'exécuter du code HTML et Java arbitraire dans d'autres domaines, de lire des données d'autres domaines (formulaires de mot de passe ou fichiers sur le système client) et même d'exécuter des commandes arbitraires sur l'ordinateur distant.
Souvent, le concept de script interdomaine est remplacé par le concept de script intersite (XSS). En effet, il arrive souvent que les manifestations externes de ces vulnérabilités soient très similaires, en particulier lorsque CDS insère du code Java dans le contexte d’un autre domaine. Cependant, malgré la similitude, l’essence de ces vulnérabilités est différente:
Premièrement, la portée de XSS est par définition limitée à un domaine. Tandis que CDS est généralement affecté par tous les domaines + le système de fichiers local du client.
Deuxièmement, la cause des vulnérabilités de XSS réside dans les erreurs des scripts situés sur le serveur et consiste généralement en un filtrage insuffisant des données reçues de l'utilisateur. La source des vulnérabilités du CDS est le logiciel client (navigateur et système d'exploitation), qui n'est généralement pas associé aux données utilisateur.
Eh bien, il ne faut pas oublier que le niveau de danger que représente l’exploitation d’un attaquant par XSS est bien inférieur à celui de CDS. Après tout, dans le premier cas, il y aura une fuite de données d’utilisateur confidentielles (mots de passe, etc.), et seulement d’un site, et avec CDS, il est possible de voler des données confidentielles sur tous les sites. vous permet de prendre le contrôle total.

Comment ça marche?

Alors, pourquoi ce type d'attaque est-il possible? La raison en est que la même "ligne de sécurité" entre les domaines est créée artificiellement, que tout le travail de prévention des scripts inter-domaines est effectué par le navigateur Web et ses composants. Il n'y a pas de restrictions architecturales. Il y a donc toujours une possibilité d'erreurs dans les procédures de vérification, la possibilité de les contourner, ce qui se fait avec succès aujourd'hui.
Pendant plus de dix ans d'utilisation des navigateurs Web, de nombreuses méthodes ont été trouvées pour surmonter les limites du domaine chéri du domaine. Cependant, la plupart d’entre eux peuvent être divisés en deux classes:
1. utilisation des erreurs de sécurité dans le modèle de navigateur orienté objet;
2. Utilisez un lien intermédiaire pour effectuer une attaque.
Considérons ces classes d'attaques plus en détail.
Le cœur de la première est une architecture orientée objet clairement exprimée des navigateurs modernes et de la machine virtuelle Java. En effet, tout ce que nous voyons à l'écran d'un navigateur Web est constitué d'objets de certaines classes avec leurs propriétés, événements et méthodes. En utilisant ce modèle orienté objet et les scripts Java, nous pouvons accéder à tout élément de la page chargé dans le navigateur, y lire et écrire des données, ouvrir de nouvelles fenêtres, etc. De plus, en utilisant des scripts, il est possible de contrôler partiellement les éléments du navigateur Web et même les actions des utilisateurs: Avance / Retour aux pages, ajout aux Favoris, etc.
Toutefois, les fenêtres ou éléments de page individuels d'un navigateur Web peuvent appartenir à des domaines différents, ce qui signifie qu'il est nécessaire d'empêcher leur accès. Vous ne pouvez pas autoriser un script personnalisé à ouvrir un autre domaine dans une nouvelle fenêtre de navigateur, mais vous pouvez écrire quelque chose là-bas ou le prendre à partir de là. Vous ne pouvez pas autoriser un script sur une page avec un cadre où la ressource d'un autre domaine est chargée, peut accéder à cette image et accéder à ses données. De plus, les fuites de données d'un domaine à un autre sont possibles non seulement à travers les propriétés, mais aussi à travers les méthodes et les événements des objets! Dire qu'un script sur la page du jeune pirate Vasi, où il a attiré un utilisateur sans méfiance, ne devrait pas "savoir" sur quelles touches il appuie lorsqu'il entre le mot de passe pour se connecter à Mail.Ru, ouvert dans une autre fenêtre du navigateur. Eh bien, il y en a beaucoup d'exemples!
Malheureusement, et peut-être heureusement;), de tels contrôles de sécurité sont souvent effectués de manière incorrecte, et parfois même complètement absents! Par conséquent, il devient possible d'accéder à des éléments de pages provenant d'autres domaines, de lire des données à partir de ceux-ci, d'écrire leur code Java dans le contexte d'autres domaines, etc. En raison de l'architecture assez complexe du modèle orienté objet, de tels "trous" s'y trouvent souvent. Voici un exemple de cette classe d’attaques (exemple 1).
Pour effectuer des attaques de deuxième classe, utilisez des intermédiaires. Que dois-je faire lorsque l'accès direct à un autre domaine est interdit? C'est vrai! Faire le tour! Et soudain, il y a quelqu'un qui fait quelque chose à qui cet appel n'est pas interdit, et il pourra y prendre des données et nous les transférer, ou vice versa - pour écrire nos données dans le contexte d'un autre domaine. Le plus vulnérable de ce point de vue est la technologie ActiveX de Microsoft. La technologie ActiveX fournit à l'utilisateur des objets, leurs propriétés et méthodes utilisées par le système d'exploitation à des fins auxiliaires. Par exemple, pour afficher les fichiers d'aide Windows (* .chm) via le navigateur Web, utilisez le composant ActiveX HTML Help. N'est-ce pas pratique? Cependant, les objets ActiveX agissent souvent comme une sorte de "cheval de Troie"! Le fait est qu'il existe un moyen de gérer ces composants (téléchargement, accès à leurs propriétés et méthodes) via une page Web. Pour ce faire, utilisez la balise. Mais souvent, ces objets ActiveX contiennent des méthodes pour manipuler le système de fichiers, lancer des applications, naviguer dans des pages Web, etc. Ainsi. il est possible de faire toutes ces actions de l'extérieur et, en outre, de procéder à un échange complet de données avec la victime! Par exemple, lisez le contenu des fichiers clients locaux et renvoyez ces données au script ou utilisez ActiveX pour ouvrir un autre domaine et écrivez son code Java dans son contexte. C'est avec cette classe d'attaques qu'il est parfois possible d'exécuter du code arbitraire (exécutant cmd.exe avec les paramètres requis) sur le système client. Actuellement, ce type de CDS est également largement distribué et trouve constamment de nouveaux objets ActiveX vulnérables. Voici un exemple d'une telle vulnérabilité (exemple 2).
Outre les classes de CDS considérées, il existe d'autres moyens de contourner les restrictions interdomaines. Certes, ces méthodes sont souvent très exotiques et rares. Par exemple, la vulnérabilité Cross-Cookie découverte en juillet 2004 (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Il permettait dans certaines conditions d'accéder (lecture / écriture) aux cookies d'autres domaines. Et c'était l'un des rares cas où de nombreux navigateurs étaient vulnérables: IE, Mozilla, Opera, Konqueror.
Ainsi. Le CDS est actuellement un type d'attaque très répandu et de nouvelles manières d'exploiter ces vulnérabilités sont constamment découvertes (le «vecteur d'attaque»).

Exemples de CDS

Pour rendre tout ce qui est décrit ci-dessus plus clair, prenez quelques exemples de vulnérabilités réelles du CDS. Tous ont été trouvés dans Internet Explorer et vous permettent d’insérer votre code Java dans le contexte d’autres domaines. Habituellement, cela est utilisé pour voler des cookies ou effectuer des actions arbitraires dans la session utilisateur en cours.

Exemple 1. Vulnérabilité inter-domaines de redirection de nom de méthode similaire - CAN-2004-0727 (MS04-038)

Cette vulnérabilité a été découverte en juillet 2004 et est associée à une erreur de sécurité dans le modèle orienté objet de IE (la première classe de vulnérabilités de CDS parmi celles présentées ci-dessus).
Son essence est la suivante. Comme vous le savez, pour charger une autre page dans la fenêtre de navigateur actuelle (éventuellement depuis un autre domaine), vous pouvez utiliser la propriété location.href ou la méthode location.assign (). Cependant, après le chargement de la page requise, une nouvelle exécution du code Java du script en cours est impossible - sinon, le script pourrait charger Mail.Ru et exécuter des actions arbitraires dans le contexte de ce domaine. Cependant, il était possible de contourner cette restriction en redirigeant la méthode location.assign () vers la même fenêtre mais différente (après tout, nous avons un modèle orienté objet et nous pouvons assigner les méthodes des différents objets). En conséquence, il est devenu possible d'exécuter du code Java dans le contexte de la fenêtre en cours, mais après avoir téléchargé la page requise - comme requis! Le script suivant effectue les actions requises:


w = window.open ("javascript: setInterval (function () {try {x = opener.location.href;} catch (e) {location.assign ('javascript: alert (document.cookie)'); window.close ();}}, 100) ");
w.location.assign = location.assign;
location.href = "/ cliquez sur http: // localhost";


Tout d'abord, une nouvelle fenêtre s'ouvre, qui attend que la page (dans notre cas avec localhost) soit chargée dans la fenêtre principale (actuelle). Pendant ce temps, le script réaffecte les méthodes location.assign () et commence à charger la fenêtre principale de la page demandée (localhost). Dès que le téléchargement est terminé, le déclencheur déclenche un déclencheur dans la boucle de la nouvelle fenêtre, assigne le code Java à la méthode assign (en raison de la réaffectation des méthodes, l'insertion se produit dans le contexte de la fenêtre principale). À la suite de l'exécution du script dans le contexte de localhost, il exécute document.cookie.
Apparemment, les développeurs Microsoft n'ont pas fourni la fonction de redirection et n'ont pas inséré de contrôle de sécurité (ou inséré de manière incorrecte) dans cet événement. Pour exploiter cette vulnérabilité, Active Browsing doit être activé dans votre navigateur. En savoir plus sur cette vulnérabilité et trouver un exemple concret d'un exploit ici: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Exemple 2. Vulnérabilité inter-domaines du contrôle ActiveX du composant d'édition DHTML CAN-2004-1319 (MS05-013)

Cette vulnérabilité a été découverte à la fin de l’année dernière, mais elle n’a été corrigée qu’en février. Il fait référence au deuxième type d'attaques de CDS par rapport à celles examinées ci-dessus, à savoir utilise un intermédiaire (ActiveX DHTML) pour mener l'attaque. Pour exploiter cette vulnérabilité avec succès, vous devez exécuter la séquence d'actions suivante:
1. Téléchargez ActiveX DHTML. Cela se fait à l'aide d'une balise.




2. Téléchargez la page souhaitée sur l'objet ActiveX (domaine arbitraire). Cela se fait en exécutant notre script dans le contexte de l'ActiveX DHTML.

exploit.DOM.Scrypt.execScript ("window.name =" new "; open (" http: // localhost "," new ");");

3.Et bien, et après cela, vous pouvez déjà intégrer notre code HTML et Java. Il sera exécuté dans le contexte du domaine chargé. Tout est simple à déshonorer :) !!

exploit.DOM.Scrypt.execScript ("alert (document.cookie)");

Quelles sont les causes de cette vulnérabilité? Je voudrais en distinguer deux:
Tout d'abord, la possibilité d'exécuter en externe des scripts arbitraires dans l'objet ActiveX - à mon avis, c'est trop de liberté!
Deuxièmement, lors du chargement d'une page dans ActiveX DHTML, tout y est chargé - même les cookies! Question: Pourquoi? Cet objet ActiveX peut être utilisé pour éditer des pages et pourquoi des cookies sont nécessaires - ce n'est pas clair ...
Naturellement, pour exploiter cette vulnérabilité, il est nécessaire que le navigateur permette l'exécution d'ActiveX. En savoir plus sur cette vulnérabilité et trouver un exemple concret d’exploitation ici: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Comment se défendre?

Protéger des scripts inter-domaines n'est pas si simple. Parce que Les variantes d'exploitation (le "vecteur d'attaques") de ces vulnérabilités sont très diverses, la plupart des mesures étant de nature très limitée et temporaire. Il est presque impossible de bloquer tous les "vecteurs d'attaque". Par conséquent, je donnerai quelques recommandations qui ne peuvent que réduire le risque d'une attaque réussie, mais pas complètement.
1. Maintenir la prudence lors de la navigation sur le Web.
Pour exécuter avec succès presque tous les types de CD, vous devez d’abord attirer un utilisateur non méfiant sur une page d’exploitation, après quoi il subira cette attaque. Vous ne pouvez pas faire confiance aux liens, comme par hasard, jetés dans la conversation, diverses "pages d'accueil", etc. C'est probablement la principale recommandation de tous. Malheureusement, correctement appliqué XSS peut rayer toutes les précautions.
2. Installer des correctifs pour le système d'exploitation et le navigateur.
Habituellement, pour toutes les vulnérabilités publiées sur Internet, le fabricant (même Microsoft :) ) produit rapidement un patch (patch). Il protégera contre cette vulnérabilité particulière, mais pas contre d’autres personnes qui n’ont pas encore été trouvées (ou trouvées, mais pas rendues publiques). Naturellement, les vulnérabilités examinées dans les exemples ont déjà été corrigées depuis longtemps par Microsoft et quiconque le souhaitait en a déjà pris soin.
3. Désactiver dans le navigateur ActiveX et Active Scripting.
Cette mesure rendra impossible l’exécution d’ActiveX et l’exécution de scripts Java ou VBS. Cela rendra vraiment la plupart des attaques de CDS inefficaces, même si cela peut affecter de manière significative les fonctionnalités des sites visités. Cependant, le CDS pour une attaque réussie ne nécessite pas toujours le support du navigateur ActiveX ou Active Scripting - et ce n’est pas la panacée pour tous les maux!
4. Travaillez sur Internet uniquement avec des droits limités.
La mise en œuvre de cette recommandation permettra, même en cas d’attaque réussie, de réduire les dommages éventuels. Comme vous le savez, le navigateur (et donc tous les scripts qu'il contient) est exécuté avec les droits de l'utilisateur actuel. Ne laissez pas le pirate Vasya obtenir cmd.exe avec les droits d'administrateur :) !!
Suite à toutes ces recommandations, il sera difficile d'attaquer pour les scripts inter-domaines!