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

Crossing Scripting de domaine

Introduction

L'idée d'écrire cet article m'est venue après qu'il ait été 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 trouver que trouver un tel article n'est pas assez facile. Le terme soit n'a pas été expliqué du tout, soit en deux mots et en anglais :) . En attendant, les vulnérabilités de Windows de ce type se retrouvent assez souvent et elles sont plus que sérieuses! 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 la protection contre celles-ci, ainsi que de donner des exemples concrets aussi détaillés et clairs que possible. L'article a été écrit surtout, bien sûr, pour les débutants, mais j'espère qu'il sera utile pour les lecteurs plus expérimentés.

Qu'est-ce que Cross Domain Scripting?

Initialement, Cross-Domain Scripting (CDS) était associé à des failles dans le modèle de sécurité de tous les "ânes" connus, 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 sujettes à 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", c'est-à-dire qu'il fonctionne par exemple sur IE, mais ne fonctionne pas sur Opera ou vice versa.
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. "Domaine" n'est pas seulement l'adresse du site sur Internet, et même pas la "zone de l'espace de noms Internet hiérarchique" - ce concept dénote une certaine "frontière de sécurité" qu'aucun script utilisateur n'est autorisé à sortir.
La base du modèle de sécurité de tout navigateur Web est le principe selon lequel les ressources des différents domaines (pages, scripts, etc.) ne peuvent pas se croiser d'une quelconque manière, 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 Vasya pourrait accéder aux données de la boîte aux lettres Mail.Ru d'un utilisateur peu méfiant 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 aussi des «domaines», ce qui signifie qu'il est possible d'y accéder à partir de scripts! 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 tous ses sous-domaines!) Est autorisée par le concept de sécurité de Microsoft et n'est en principe pas limitée. Il est difficile de juger si c'est juste ou non, mais quoi de plus simple :) et en même temps les possibilités de surfer sur le web sont en expansion, 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 inter-domaines"; "Scripted domain boundaries crossing" est une violation de cette ligne de sécurité chère, accès pour lequel donne accès aux données 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 le contexte d'autres domaines, lire des données d'autres domaines (par exemple, des mots de passe ou des fichiers sur le système client).
Souvent, le concept de script interdomaines 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, notamment 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 XSS réside dans les erreurs des scripts situés sur le serveur, et, en règle générale, consiste en un filtrage insuffisant des données reçues de l'utilisateur. La source des vulnérabilités CDS est le logiciel client (navigateur et système d'exploitation), et il n'est généralement pas associé aux données utilisateur.
Eh bien, nous ne devons pas oublier que le niveau de danger de l'exploitation réussie d'un attaquant par XSS est beaucoup plus faible que celui de CDS. Après tout, dans le premier cas, il y aura une fuite de données confidentielles (mots de passe, etc.) et seulement d'un site. Avec CDS, il est possible de voler des données confidentielles sur n'importe quel site et d'exécuter des commandes arbitraires sur le système client. vous permet de prendre le contrôle complet.

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 pour empêcher les scripts interdomaines est effectué par le navigateur Web et ses composants - il n'y a pas de restrictions architecturales. Donc, il y a toujours une possibilité d'erreurs dans les procédures de vérification, la possibilité de les contourner, ce qui est fait avec succès maintenant.
Pour plus d'une décennie d'utilisation des navigateurs Web, de nombreuses façons ont été trouvées pour surmonter la frontière de domaine chéri du domaine. Cependant, la plupart d'entre eux peuvent être divisés en deux classes:
1. Utilisation d'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.
Au 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 l'on voit sur l'écran d'un navigateur web sont des 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 à n'importe quel é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 en partie les éléments du navigateur même et même les actions de l'utilisateur: déplacement vers l'avant / vers les pages, ajout aux favoris, etc.
Cependant, des fenêtres individuelles ou des éléments de page dans un navigateur Web peuvent appartenir à différents domaines, ce qui signifie qu'il est nécessaire d'en interdire l'accès. Vous ne pouvez pas autoriser un script personnalisé à ouvrir un autre domaine dans une nouvelle fenêtre de navigateur, avoir la possibilité d'écrire quelque chose là-bas ou de 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, pourrait accéder à cette image et accéder à ses données. De plus, la fuite de données d'un domaine à l'autre est possible non seulement à travers des propriétés, mais aussi à travers des méthodes et des événements d'objets! Dites un script sur la page du jeune pirate Vasi, où il a attiré un utilisateur peu méfiant, ne devrait pas "savoir" quelles touches il appuie lorsqu'il saisit le mot de passe pour se connecter à Mail.Ru, ouvert dans une autre fenêtre du navigateur. Eh bien, il y a beaucoup de tels exemples!
Malheureusement, et peut-être heureusement;), de telles vérifications de sécurité sont souvent effectuées incorrectement, et parfois même complètement absentes! Par conséquent, il devient possible d'accéder à des éléments de pages provenant d'autres domaines, d'en lire les données, 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" se trouvent souvent dans celui-ci. Voici un exemple de cette classe d'attaques (exemple 1).
Pour effectuer des attaques de seconde classe, utilisez un intermédiaire. Que dois-je faire lorsque l'accès direct à un autre domaine est interdit? C'est vrai! Aller autour! Et soudain, il y a quelqu'un qui va quelque chose à qui cet appel n'est pas interdit, et il pourra prendre des données à partir de là et nous les transférer, ou vice versa - é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 qui sont utilisés par le système d'exploitation à des fins auxiliaires. Par exemple, pour afficher les fichiers d'aide de Windows (* .chm) via le navigateur Web, utilisez le composant ActiveX de l'aide HTML. N'est-ce pas pratique? Cependant, souvent les objets ActiveX agissent 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 l'étiquette. Mais souvent, ces objets ActiveX contiennent des méthodes de manipulation du système de fichiers, de lancement d'applications, de navigation dans des pages Web, etc. Ainsi. il y a une possibilité de faire toutes ces actions de l'extérieur et, de plus, de procéder à un échange complet de données avec la victime! Par exemple, lisez le contenu des fichiers client locaux et renvoyez ces données au script ou utilisez ActiveX pour ouvrir un autre domaine et écrire son code Java dans son contexte. C'est avec cette classe d'attaques qu'il est parfois possible d'exécuter du code arbitraire (en 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).
En plus des classes CDS considérées, il existe d'autres moyens de contourner les restrictions interdomaines. Certes, souvent ces méthodes sont très exotiques et sont 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 (lire / écrire) 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. CDS est actuellement un type d'attaque très courant et de nouvelles façons d'exploiter ces vulnérabilités sont constamment découvertes (le «vecteur d'attaque»).

Exemples de CDS

Pour rendre plus clair tout ce qui est décrit ci-dessus, prenez quelques exemples de vulnérabilités réelles de la 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 noms de méthodes similaires - 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 CDS de celles discuté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 à partir d'un autre domaine), vous pouvez utiliser la propriété location.href ou la méthode location.assign (). Cependant, après avoir chargé la page requise, il est impossible de poursuivre l'exécution du code Java du script en cours, 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 mais différente fenêtre (après tout, nous avons un modèle orienté objet et nous pouvons assigner les méthodes des différents objets les uns aux autres). 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 (fonction () {try {x = opener.location.href;} capture (e) {location.assign ('javascript: alert (document.cookie)'); window.close ();}}, 100) ");
w.location.assign = location.assign;
location.href = "/ click? http: // localhost";


D'abord, une nouvelle fenêtre s'ouvre, qui dans la boucle attend que la page (dans notre cas avec localhost) soit chargée dans la fenêtre principale (courante). Pendant ce temps, le script réattribue 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 trigger déclenche un trigger dans la boucle de la nouvelle fenêtre, assigne le code Java à la méthode assign () (la réaffectation des méthodes se fait dans le contexte de la fenêtre principale) et la nouvelle fenêtre se ferme immédiatement. À 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 prévu la fonction de redirection et n'ont pas inséré de vérification de sécurité (ou inséré de manière incorrecte) dans cet événement. Pour exploiter cette vulnérabilité, vous devez activer la navigation active dans votre navigateur. En savoir plus sur cette vulnérabilité et trouver un exemple d'exploitation 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 se réfère au 2ème type d'attaques CDS de celles considérées ci-dessus, c'est-à-dire utilise un intermédiaire (DHTML ActiveX) pour mener l'attaque. Pour réussir à exploiter la vulnérabilité, vous devez effectuer la séquence d'actions suivante:
1. Téléchargez DHTML ActiveX. Ceci est fait avec l'aide d'une étiquette.




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

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

3.Well, 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 distinguerais deux d'entre eux:
Tout d'abord, la possibilité d'exécuter de manière externe des scripts arbitraires à l'intérieur de l'objet ActiveX - à mon avis, c'est trop de liberté!
Deuxièmement, lors du chargement d'une page dans DHTML ActiveX, tout est chargé là-bas - même les cookies! Question: Pourquoi? Cet objet ActiveX peut être utilisé pour éditer des pages et pourquoi il y a des cookies nécessaires - ce n'est pas clair ...
Naturellement, pour exploiter cette vulnérabilité, il est nécessaire que le navigateur autorise l'exécution ActiveX. En savoir plus sur cette vulnérabilité et trouver un exemple de travail d'un exploit ici: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Comment te défendre?

Protéger des scripts inter-domaines n'est pas si facile. Parce que Les variantes d'exploitation (le «vecteur d'attaques») de ces vulnérabilités sont très diverses, la plupart des mesures seront de nature très limitée et temporaire. Il est presque impossible de bloquer tous les "vecteurs d'attaque". Par conséquent, je vais donner quelques recommandations qui sont seulement capables de réduire le risque d'une attaque réussie, mais pas de protéger complètement.
1. Rester prudent lorsque vous surfez sur le Web.
Pour exécuter avec succès presque tous les types de CDS, vous devez d'abord attirer un utilisateur peu méfiant vers une page d'exploitation, après quoi il subira cette attaque. Vous ne pouvez pas faire confiance aux liens, comme si par hasard, jeté dans la conversation, diverses "pages d'accueil", etc. C'est probablement la principale recommandation de tous. Malheureusement, XSS correctement appliqué peut rayer toutes les précautions.
Installez les correctifs 2.Operately 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 :) ) dans un court laps de temps produit un patch (patch). Il protégera contre cette vulnérabilité particulière, mais pas d'autres non encore trouvées (ou trouvées, mais non publicisées). Naturellement, les vulnérabilités examinées dans les exemples ont déjà été corrigées depuis longtemps par Microsoft, et celui qui le voulait a déjà pris soin de sa sécurité.
3. Désactivation 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 la plupart des attaques CDS inefficaces, bien que cela puisse affecter de manière significative la fonctionnalité des sites visités. Cependant, pas toujours CDS pour une attaque réussie nécessite le soutien du navigateur ActiveX ou Active Scripting - et ce n'est pas une panacée pour tous les maux!
4. Ne travaillez sur Internet qu'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 :) !!
Suivre toutes ces recommandations aidera à devenir difficile à attaquer pour les scripts inter-domaines!