je vous contacte aujourd’hui pour savoir si d’autres personnes recensent des hacks récents sur leurs installs de Dolibarr.
En effet depuis plusieurs semaines, je constates le hack de nombreuses instances de Dolibarr avec toujours la même méthode :
On me signale que la mise en page change, que des fonctionnalités ne fonctionnent plus.
Je constates la création d’un ou plusieurs users.
Je constates en base de données des nouvelles entrées dans llx_menu (avec du base64_encode dedans) > c’est cela qui provoque les soucis de mise en page.
Et en grattant plus loin aujourd’hui je découvre que la finalité était de déposer des fichiers pour installer un genre de cryptominer qui consomme des ressources CPU à fond (fichiers jsonx.php et payload.so dans /admin/menus) et un process nommé kthreaddi qui tourne).
Est-ce que d’autres personnes ont ces mêmes problèmes et savent comment ils arrivent à faire cela ?
J’ai rencontré le même hack avec les base64_decode dans llx_menu et par contre plusieurs fichiers jsonx.php.
j’ai corrigé le problème de fichier install.lock, modifier le pwd de la db, supprimé l’utilisateur admin / les fichiers jsonx.php / les lignes dans la table llx_menu. Quelle serait les autres autres choses à faire d’après vous ?
Je pense qu’il y a autre chose à corriger mais je n’ai pas encore tous les éléments de réponses.
Vu qu’il s’agit d’une faille avec SQL injection j’ai analysé les logs apache de mon site et le hacker a fait appel plusieurs fois à la fonction eval pour accéder à mon FS.
Il code en base64 les fonctions dont il fait appel.
Bonjour,
Je pense avoir subi le même genre d’attaque que vous sur 2 serveurs différents chez O2Switch …
Je pensais que l’attaque venait des Wordpress mais à la lecture de votre message j’ai un sérieux doute.
Si cela peut aider voici les scripts qui m’ont été communiqué par le support : sleep 2, lsphp, kthreaddi -B , bash -s kthreaddo
Avec pour conséquence une saturation des processus donc des erreurs 404,503,500… Mais rien de visible de mon coté.
He oui hélas. On ne rappellera jamais assez que les mises à jour (même si …), c’est important et indispensable pour la sécurité de vos serveurs et données qu’ils contiennent. Sans compter que le RGPD vous lie par la loi à vos clients, pensez y et si vous pensez que la sécurité de vos données a été impactée, faites une déclaration a la Cnil.
J’ai plusieurs instances de dolibarr chez O2Switch.
Je n’en ai eu qu’une seule impactée par cette attaque et effectivement c’était une instance que je n’avais pas protégé avec l’install.lock (c’était une instance de test - belle erreur que d’avoir négligé la sécurité dessus).
Le comportement sur mon serveur était : une fois j’ai eu tous les processus à 100%, j’ai cru à un problème de script php bloqué (genre une extension wordpress ou prestashop défaillante), j’ai reboot le tout et les processus étaient revenus à la normale mais j’avais des erreurs 503 de temps en temps sur des instances de dolibarr (aléatoirement et pas toutes). Après contact avec le support de l’hébergeur, ils avaient trouvé le fameux script malveillant que vous décrivez dans ce post…
J’ai beaucoup de chance d’être tombé sur ce post, j’ai un de mes server de test qui n’est pas sécurisé par install.lock et qui est également à 100% de CPU.
Ce crypto miner kthreaddi y tourne.
J’ai commencé sans succès par suivre ces recommandations: stackoverflow: kthreaddi-very-high-cpu
J’ai finalement trouvé ce post dolibarr et est découvert le compte admin créé (testadmin), les entrées SQL en base64 …
J’ai pu supprimer le compte admin, supprimer les entrées de la table llx_menu, ajouter le fichier.lock, supprimer le jsons.php.
Malheureusement, je ne parviens pas à localiser k1.sh pour voir ce que ce hack a pu lancer sur mon server.
La solution la plus simple serait de réinstaller le serveur avec dolibarr de Zero mais rien ne tourne sur mon instance affectée, je suis donc très intéressé si quelqu’un pouvait pousser le contenu de ce k1.sh ? pour m’aider à y voir plus clair.
Vu la commande, le script gitlab est téléchargé dans le dossier /tmp puis executé depuis cet emplacement.
Edit: j’ai téléchargé le fichier gitlab, et extrait les chaines de caractères avec strings gitlab
Au vu des chaines de caractères qu’il y a dans ce programme, il va visiblement ajouter une relance du script dans /etc/init.d/ ce qui fait qu’à chaque redémarrage il risque de se réinstaller.
Après avoir supprimé tous les dossiers et fichiers temporaires dans le dossier /tmp/ , j’ai effectivement l’utilisation de mon processeur qui est revenue a la normale.
Par contre, j’ai toujours des utilisateurs ‹ testadmins › qui se créent aléatoirement.
Je continue mes recherches et je vous tiendrai au courant de mes trouvailles i ca peut aider.
Dans la table llx_user il y a la date de création du user avec heure, minutes secondes. Donc avec l’heure précise de création des users testadmins vous pouvez filtrer les logs pour essayer de trouver plus facilement ce qui déclenche cette création de users.
Pour le fichier install.lock, non il n’était pas en place. Je l’ai crée hier. Je suis donc bien responsable de l’erreur.
Pour les entrées dans la base de données, je ne sais pas comment filtrer les logs. Il faut rajouter un module ou je vais ça en commande terminal dans mon Ubuntu ?
Non …
