Bypass CSRF token & referer protection avec une XSS

Au cours de récents audits de vulnérabilités, analyses de code et pentests, nous avons pu déceler des vulnérabilités de type CSRF permettant l’acquisition de privilèges, de changer des mots de passe d’administration ou bien même d’établir un reverse-shell sous certaines solutions.

Ces vulnérabilités CSRF étaient toutefois protégées par les mécanismes couramment employés, tels que l’utilisation de jeton de session (token) et/ou encore la validation du “referer“.

Souhaitant aller plus loin dans le cadre de ces analyses, nous avons creusé les possibilités de contourner (bypasser) ces restrictions sachant que des vulnérabilités de type XSS simples avaient également été décelées.

Il en ressort une méthodologie relativement facile à réaliser, qui permet de bypasser les protections CSRF (jeton de session et validation du referer) dès lors qu’une vulnérabilité XSS est présente et n’est pas protégée.

Pour amorcer cet article “retour d’expérience”, présentons succinctement les vulnérabilités CSRF, leurs impacts, et leurs moyens de protection.

Les vulnérabilités CSRF

CSRF, pour Cross-Site Request Forgery, sont principalement orientées vers des applications web. Elles exploitent les privilèges d’une session courante d’un utilisateur cible, sans que celui-ci n’en soit conscient, pour réaliser diverses actions notamment malveillante. Ces vulnérabilités sont classées dans le Top 10 de l’OWASP ; d’ailleurs, la définition qu’ils en donnent est la suivante :

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

Ces vulnérabilités souvent jugées non-critiques voire même ignorées sont d’une grande dangerosité. Il convient à tout développeur d’application web de s’en prémunir ainsi qu’aux internautes lambda d’adopter des pratiques limitant la portée des assaillants.

Les protections courantes des CSRF

Divers mécanismes existent et sont couramment employés pour se protéger de telles attaques. Parmi les plus connus on peut citer :

• La demande de confirmation d’action à l’utilisateur, ce qui peut alourdir l’enchaînement des formulaires web. De plus ce mécanisme n’est pas 100% fiable si l’attaquant génère la requête finale post-confirmation.
• Demande de confirmation de l’ancien mot de passe pour un quelconque changement de mot de passe.
• Exploitation de jeton de session (token), pour valider l’envoi de formulaire. Ces jetons peuvent disposer d’une validité temporelle, ainsi un jeton trop vieux ne pourra être exploité par un assaillant.
• Eviter la méthode GET pour réaliser des actions.
• Effectuer une vérification du « referer » (page de provenance) dans les pages sensibles. Le referer est une en-tête HTTP qui transite de page en page, indiquant la page de provenance de la requête. Ainsi une action critique sur un site web ne pourra se faire que si la requête a été émise d’une page du même site.

L’OWASP liste bon nombre de techniques de protection que nous vous invitons à respecter au mieux dans vos développements.

Contournement des protections par referer et token : retour d’expérience

Malgré les protections par jeton de session et validation du referer sur nos solutions à auditer, il a été possible de contourner ces mécanismes en exploitant une vulnérabilités de type XSS très simple. Ces solutions n’étant actuellement pas encore corrigées et étant en attente des retours des développeurs, nous détaillons par la suite que le procédé/scénario d’exploitation de ce mécanisme sans démonstration réelle.

L’idée est d’utiliser la vulnérabilité de type XSS, permettant l’injection de code JavaScript dans le contexte de la page, pour récupérer et utiliser les informations manquantes à la CSRF finale. Ces informations manquantes sont bien évidemment :

• Un referer de provenance valide
• Un jeton de session valide

Comme il est possible d’exécuter du code JavaScript dans le contexte de la page via la vulnérabilité XSS, il est tout à fait possible d’exécuter des requêtes AJAX en interne à la solution cible. Ces requêtes AJAX disposeront automatiquement d’un referer valide puisque émises depuis et vers la solution. Pour le jeton de session, une première requête AJAX sur une page contenant le jeton dans son code source (champ caché d’un formulaire par exemple) peut être réalisée. Le code source retourné (requête inter-domain et non cross-domain) contiendra le jeton qu’il suffira d’extraire. Avec un referer et un jeton tous deux valides, la CSRF dispose de tous les outils pour fonctionner convenablement.

Le schéma suivant illustre l’ensemble du scénario :

Cette technique a été employée avec succès afin d’obtenir un reverse-shell complet sur deux distributions Linux firewalls/routeurs.

Conclusion et sensibilisation

Il est important de garder à l’esprit que même avec les protections actuelles de CSRF, une simple vulnérabilité XSS permet de les mettre à mal. Les développeurs d’applications web, en plus d’effectuer des vérifications sur les jetons et le referer, doivent impérativement contrôler, nettoyer et valider l’ensemble des variables qui transites sur leurs pages (sanitization).

Pour tous les internautes soucieux de se prémunir au maximum du détournement de leurs sessions par CSRF, il n’est pas inutile de rappeler que :

• Les sessions et leurs jetons sont très prisés des assaillants, veuillez à ne pas les laisser ouvertes. Fermer vos sessions en cliquant sur « se déconnecter » plutôt que de fermer le navigateur directement.
• Eviter d’enregistrer vos identifiants (login/mot de passe) dans votre navigateur, les attaquants peuvent capturer ces informations à votre insu via l’autocomplete.
• Ne suivez pas de liens suspects, et assurez vous du lien pointé par un mot en regardant la cible qui apparaît en barre d’état de votre navigateur.
• Effacer votre historique, cache et cookies régulièrement (Shift + Ctrl + Suppr sur la plupart des navigateurs)
• Maintenez vous à jour au niveau du navigateur et de ses plugins
• N’hésitez pas à décentraliser vos sessions d’administration, en utilisant un autre navigateur dédié, ou le mode « navigation privée ».

Les équipes de développement de ces différentes solutions vulnérables à ce procédé ont été averties, nous sommes actuellement en attente de leurs retours et corrections.

Le contributeur de SYNETIS qui a mis en place ce mécanisme peut vous fournir le détail de son fonctionnement sur simple demande en envoyant un mail à info@synetis.com.

Yann CAM

Consultant Sécurité