L’importance de définir un but à un test d’intrusion

La valeur ajoutée d’un test d’intrusion, si on le compare à un simple scan de vulnérabilités, est le fait de mettre les résultats obtenus dans un contexte spécifique permettant de déterminer les vrais risques encourus par une société à cause d’une certaine vulnérabilité. Par exemple, un scanner automatisé ne sera pas en mesure de différencier l’impact d’une injection SQL sur un serveur Web hébergé chez un fournisseur externe ne contenant aucune donnée sensible et une injection SQL sur un site dont la base de données est hébergée sur le réseau interne et dont la compromission aboutirait à un accès distant sur le réseau privé de l’entreprise.

Il est donc évident que le contexte dans lequel une faille est découverte est important. Le pentester peut alors utiliser son expérience pour déterminer la criticité de cette dernière. Mais souvent cela ne suffit pas à donner une réelle idée du risque encouru par la société. En effet, en tant que pentester, il n’est pas toujours facile d’identifier quels sont les actifs critiques d’une société. Est-ce que le vol du contenu d’un site d’e-banking a le même impact que sur un site journalistique? La réponse semble évidente, du fait que la plupart des informations sur le deuxième site est de toute façon accessible à tout le monde. Mais dans la plupart des cas, la réponse n’est pas aussi simple et il est toujours embêtant de passer du temps à exploiter une faille pour récupérer des données pour se rendre compte au final qu’elles n’ont aucune réelle valeur pour le client.

Afin d’éviter ce type de problème, il est très important de définir un ou plusieurs buts lors du démarage d’un test d’intrusion. Un simple “piratez notre réseau” ne suffit pas. Afin que le test soit réussi et surtout utile pour un client, il faut tout d’abord déterminer avec lui quels sont les vrais risques liés à une attaque informatique pour l’entreprise. Quelle information doit être protégée à tout prix? Cela permet alors aux pentesters de cibler plus précisément leurs attaques et au final de pouvoir présenter des résultats pertinents qui peuvent être utilisés pour améliorer le niveau de sécurité.

On peut par exemple imaginer quelques buts tels que les suivants:

  • Accéder à distance au réseau interne
    • Par des attaques techniques
    • Par du social engineering
  • Compromettre un compte administrateur de l’application X en partant d’un compte lambda
  • Devenir administrateur du domaine depuis un poste client

Certains de ces buts peuvent paraitre évidents et certains diront qu’il s’agit du but de tout test d’intrusion, mais ce n’est pas toujours le cas, d’où l’importance de définir à l’avance les buts du test en collaboration avec le client. Cela lui permettra d’exploiter de la meilleure manière les résultats du test.

Abuser le filtre XSS pour faciliter une attaque de ClickJacking

Le clickjacking est une attaque relativement répandue visant les utilisateurs d’un site vulnérable X. L’idée est de faire cliquer l’utilisateur sur un endroit du site en question sans qu’il ne s’en rende compte. Le plus souvent, cela est fait en utilisant une iframe cachée sous la souris de l’utilisateur.

[sourcecode language=”html”]<iframe src="http://vulnerable.com" style="position:absolute; opacity:0"></iframe>[/sourcecode]

Afin de contrer cette attaque, beaucoup de sites utilisent des scripts dits de framebusting permettant à une page de ne pas s’afficher si elle détecte qu’elle est à l’intérieure d’une frame.

Le problème le plus évident de ces scripts est que si l’utilisateur a désactivé javascript, la page est tout de même affichée. En partant de ce principe, il est possible d’abuser le filtre XSS d’Internet Explorer 8 par exemple pour le convaincre que le script de framebusting est en fait une attaque XSS. Ceci aura pour conséquence de désactiver le script et de permettre l’attaque de ClickJacking. Typiquement il suffit de créer l’iframe de la manière suivante.

[sourcecode language=”javascript”]<iframe src="http://vulnerable.com/?toto=<script>/*code_frame_busting*/</script>" style="position:absolute; opacity:0"></iframe>[/sourcecode]

Le navigateur détectera alors le code comme étant du XSS et ne l’exécutera pas, ce qui veut dire que la page s’affichera normalement dans la frame.

La méthode la plus efficace pour bloquer le ClickJacking est l’utilisation du header HTTP X-FRAME-OPTIONS qui permet à une page de spécifier par quels autres domaines elle peut être “framée”.

Pour plus d’informations, vous pouvez lire l’article suivant qui contient pas mal de détails sur les différentes techniques de framebusting et de contournement.

http://seclab.stanford.edu/websec/framebusting/framebust.pdf