DIGITEMIS découvre deux vulnérabilités au sein de l’ERP/CRM Dolibarr [CVE-2018-16808 et CVE-2018-16809]

vulnerabilites dolibarr

Dolibarr est un ERP/CRM OpenSource gratuit. Lors de leurs activités de R&D, nos auditeurs ont découvert et remonté à l’éditeur deux vulnérabilités inconnues sur les versions 3.8.X à 7.X de Dolibarr.

Nous nous proposons de réaliser un retour sur la découverte et l’exploitation de ces deux vulnérabilités.

Découverte

Dolibarr se présente comme une solution CRM et ERP moderne permettant la gestion quotidienne d’une entreprise ou d’une association. Ce logiciel open-source est libre et gratuit et peut être autohébergé, mais il est également proposé en service packagé par certains prestataires de cloud.
Dolibarr est modulaire. Il est en effet possible d’activer de nombreux modules dans l’interface de configuration. Ces modules apportent de nombreuses fonctionnalités supplémentaires. L’un d’eux, qui a particulièrement intéressé nos auditeurs, est le module de notes de frais.

L’application s’appuie sur des listes de mots à bannir des champs utilisateurs pour retirer toute charge malveillante. Il parait donc évident que tout comportement déviant de cette liste passera entre les mailles du filet.

Le module en question permet de créer, éditer et supprimer des notes de frais. On y compte plusieurs champs (descriptions, prix unitaire, prix total, etc.). La création d’une note de frais ne permettait pas à nos auditeurs d’exploiter une vulnérabilité. En revanche, l’édition de cette même note de frais était exposée à deux vulnérabilités distinctes.

Les champs de description étaient sujets à des failles de type Cross-Site Scripting (XSS). Le point noir de ces dernières est le caractère permanent, puisque le contenu malveillant persiste sur l’application. Ainsi, à chaque fois qu’un utilisateur visualisera la note de frais, alors le contenu malveillant présent dans celle-ci sera exécuté.

La seconde vulnérabilité est une injection SQL dans le champ des prix. L’application s’attend à recevoir un nombre, mais ne contrôle pas la valeur qui lui est fournie. Il est donc possible d’injecter du code SQL et d’extraire des informations de la base de données uniquement via la valeur du prix.
Pour préciser le contexte technique, nous sommes dans une requête de mise à jour (UPDATE), dans un ou plusieurs champs de nombres et devons contourner une liste noire.
L’exploitation de l’injection n’est pas triviale puisque nous travaillons sur des entiers, dans une requête UPDATE et devons contourner les listes de mots en place, précédemment évoquées.
Concrètement, on pourrait demander à la base de données de nous afficher la valeur numérique du premier caractère du mot de passe de l’administrateur. Cette valeur serait alors conservée dans le prix de notre note de frais. De cette manière, nous pouvons itérer sur tous les caractères du mot de passe et ainsi l’extraire. Cette explication simpliste traduit le fait que nous pouvons par ce biais extraire toute information présente dans la base de données.

Exploitation

Synthétiquement, la faille XSS a pu être exploitée via un encodage en base64 ce qui nous permettait de contourner la liste en place. L’injection SQL était plus complexe sur les versions antérieures à 7.X puisqu’il était nécessaire de réaliser une injection dans plusieurs champs de nombres pour reconstruire la requête UPDATE à notre guise. En revanche, il était possible de réaliser une injection dans un unique champ lors des versions 7.X.
Les détails de l’exploitation des deux vulnérabilités sont décrits dans un ticket soumis aux développeurs de l’application.
Ce ticket relate à la fois les échanges par mail avec l’équipe de Dolibarr, les détails des vulnérabilités et la timeline des événements.

Conséquences

Dolibarr a corrigé ces vulnérabilités dès la version 7.0.1. Cependant, nos recommandations générales concernant le filtrage systématique des entrées n’ont pas été choisies. L’utilisation d’une liste noire est donc toujours d’actualité dans l’application, cette pratique n’est pas recommandée, puisque la sécurité repose uniquement sur l’exhaustivité de la liste en question.
Ces deux vulnérabilités sont référencées CVE-2018-16808 et CVE-2018-16809 par le MITRE.

Le détail de l’exploitation des deux vulnérabilités sur Github : https://github.com/Dolibarr/dolibarr/issues/9449

Je partage

Derniers articles

Illustration de sécurité WordPress avec logo central et éléments numériques de sécurité

Renforcer la sécurité WordPress, du développement des plugins à la configuration serveur

Il y a peu, dans le cadre de recherches sur des plugins WordPress, notre pentester Vincent Fourcade a découvert une injection de code, côté client, dans un module du célèbre CMS. Celle-ci fut vérifiée et validée par les équipes de WPScan. Aujourd’hui, une CVE lui a été attribuée. L’occasion de revenir aujourd’hui sur la sécurité, au sens large, dans le CMS WordPress, que ce soit au niveau de la couche applicative, de la configuration du serveur ou du bureau. C’est parti !

Lire l'article

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article