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

Angular, N’Tier et HttpOnly

Avec l’apparition au cours de la décennie 2010 des environnements de travail Javascript de plus en plus puissants, l’architecture N’Tiers, si elle était déjà une norme dans le contexte d’application d’entreprises au cours des années 2000, a pu voir son modèle s’étendre à de nombreuses solutions Web. Ce modèle repose sur l’utilisation de technologies exécutées par le navigateur. Or, il arrive parfois que cette couche doive gérer une partie de l’authentification de l’utilisateur, pourtant une recommandation courante sur l’authentification est qu’elle ne doit jamais être côté client. Aussi, les cookies devraient toujours posséder l’attribut HttpOnly, empêchant leur lecture par une couche Javascript et ce afin d’empêcher tout vol de session lors d’une attaque de type XSS. Pourtant, cet attribut empêche littéralement l’application front-end de travailler avec ces éléments. Comment gérer au mieux ces questions sur ce type de déploiement ?

Lire l'article

Cybersécurité bancaire en Europe : les nouvelles mesures de la BCE, les risques et les solutions

La cybersécurité est devenue une préoccupation majeure pour le secteur financier, confronté à une digitalisation croissante de ses activités. Alors que la Banque Centrale Européenne (BCE) intensifie ses efforts pour renforcer la résilience face aux cybermenaces, cet article explore le contexte actuel, les initiatives de la BCE et les recommandations de Digitemis pour faire face à l’intensification des menaces sur le secteur.

Lire l'article