Bonjour
J’ai mis à jour mon environnement de démonstration il y a quelques semaines avec la version 15.0.3 de dolibarr
quelle n’a pas été ma surprise en voyant apparaitre un nouvel utilisateur admin sur cet environnement (et le module dolicloud installé permettant de récupérer l’ensemble des fichiers sur mon environnement)
Je n’ai malheureusement pas la possibilité de tracer l’attaque, j’ai en tout cas bloqué tout création / modification d’utilisateur sur mon environnement (dans le fichier user.class.php, ajouté un return 0, au début de la fonction insert et update) et je conseille à tous ceux qui ont un environnement accessible de l’extérieur d’en faire de meme.
Ton instance de démo semble posséder de nombreux modules externes, qui contrairement à Dolibarr n’ont pas fait l’objet de campagne de bug bounty. Il convient donc dans un premier temps d’abord de sécuriser ces modules.
Que dit la page Home - Setup - Security de Dolibarr ? (copie écran)
Est-ce que l’ensemble des valeurs appliquées correspondent bien au valeurs recommandées ?
Pour info, le site demo.dolibarr.org est en ligne et accessible publiquement (pas de modules externes, recommandations de sécurité appliqués à 100% sauf les fonctions expérimentales non activées). Le site fait l’objet de tentatives de hacks régulières manifestes (plusieurs par jour), mais aucune « escalation of privileges » n’a pu être constaté pour faire une action réservée à l’admin depuis le compte demo qui est publique… pour l’instant en tout cas.
Bonjour Laurent
j’ai pris le temps d’analyser l’attaque à partir des fichiers de log d’ovh et il semble que le soucis vient d’un oublie de ma part lors de mon installation (j’ai oublié de créer le fameux fichier install.lock).
La question que je me pose c’est si l’absence de ce fichier doit permettre ou non une telle attaque?
Le processus d’install a pour but d’installer l’appli y compris la création d’un compte utilisateur admin. Donc en effet, sans le fichier install.lock, il est possible de créer un compte admin. C’est le comportement attendu.
C’est pourquoi dans une telle config, il y a un warning sur la page d’accueil. Il doit aussi y avoir une alerte sur la page d’info de sécurité.
Il faut toujours apprendre de ce que font les autres, j’ai installé un wordpress et tenté de relancer l’installation pour créer un nouveau compte admin, cela est naturellement impossible.
A titre d’info dans les principes de déclaration de faille, il n’est pas expressément notifié qu’il faille ajouter ce fichier.
Je vais donc voir comment empêcher la création d’un nouveau compte admin si il y en a déjà un en activité, même si le fichier install.lock (et le fichier conf.php) est déjà présent.
Bonjour,
faut il uniquement s’inquiéter parce que l’install crée des droits administrateur - dont quiconque interviendrait dans le même dossier durant ce temps de l’upgrade peut abuser en installant un admin ? Le risque n’est il pas pire encore et le logiciel pirate a la possibilité d’installer des fichiers modifiés malicieusement et autre chose de manière invisible? Ne faut il pas carrément penser à restreindre l’accès aux dossiers au seul initiateur de l’upgrade? Je ne suis que simple intégrateur mais j’imagine que cela ne peut pas se faire directement sous Dolibarr…
