What should I do if my Dolibarr has been hacked?
Be careful, we're not joking, this page is not here to scare you but rather to collect all the good ideas and comments on this subject as we go along.
A skilled hacker could get in without leaving too many traces, modify the RIB of your bank account and send your invoices to your customers with his RIB … by the time you realise the problem (generally 1 month or 2, the time to follow up customers telling them “you haven't paid” and them replying “yes, look”) … you will then be in the classic case of the fake RIB scam, it doesn't just happen to other people. (https://www.cybermalveillance.gouv.fr/tous-nos-contenus/fiches-reflexes/que-faire-en-cas-de-fraude-au-virement-ou-au-faux-rib)
If he's a little less of a “Dolibarr specialist”, stealing your e-mail account login and password will already be a nice trophy …
The absolute priority: make your dolibarr "inaccessible
- It's easier to say if it's installed on your company server or at home, cut the Internet connection.
- If it's on dedicated hosting, stop the web server (apache / nginx) - it's brutal.
- If it's on shared hosting (ovh, o2switch…) connect using sFTP and rename the folder where your dolibarr is located or go to your hosting management console to deactivate your website.
This is all the more urgent if your dolibarr is old. Don't leave a “roughly repaired” Dolibarr online if it's not on a “current” or “just previous” version. (For example, today the latest stable version is 17.0.2, 16.0.5 is considered reliable, but don't leave 11.0.0 online, for example).
Then think and act
You might say to yourself “the shot has been fired” … yes but no, don't go to sleep or wait until “next Monday” to move on …
Analyse the extent of the damage
Is it just a hacking attempt? A simple message on the home page? Or something more serious, with the creation of an administrator account and an open session? Or even worse, a local system account created with escalation of privileges (the absolute horror in this case is a total reinstallation of the server, which you need to plan, plus a security audit of your infrastructure to check that there has been no contagion).
At this stage, only a security and Dolibarr expert can really analyse the situation.
In any case, you will need to consult your web server's system logs (which are outside Dolibarr): copy them as soon as possible to avoid them being deleted by a scheduled log cleaning task (although normally there is a fairly long retention period).
With these logs you will be able to isolate the queries that have been carried out and thus take the measure of reality.
Example:
No big deal, he only downloaded the country flags … well, it would be strange if he'd stopped there!
192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/ax.png HTTP/1.1" 200 693 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/ky.png HTTP/1.1" 200 701 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/ck.png HTTP/1.1" 200 695 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/fo.png HTTP/1.1" 200 670 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/fk.png HTTP/1.1" 200 700 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/fj.png HTTP/1.1" 200 700 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/gs.png HTTP/1.1" 200 691 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/hm.png HTTP/1.1" 200 707 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/mh.png HTTP/1.1" 200 699 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/um.png HTTP/1.1" 200 698 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/sb.png HTTP/1.1" 200 697 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/pn.png HTTP/1.1" 200 697 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/sj.png HTTP/1.1" 200 684 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/tc.png HTTP/1.1" 200 695 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/vi.png HTTP/1.1" 200 704 ...
Another, much more critical example: he has downloaded the backup of your database. In this case, consider that you are dealing with a total data leak (see the RGPD paragraph at the end of this message).
192.168.99.99 - - [13/Apr/2023:12:24:17 +0200] "GET /document.php?modulepart=systemtools&attachment=1&file=backup%2Fmysqldump_dolibarr_13.0.5_202304131224.sql.gz HTTP/1.1" 200 6349611
Dolibarr user passwords
Some older versions of dolibarr stored user passwords “in clear text”, so it is absolutely urgent and a priority to inform your colleagues by phone or SMS but above all not by email (imagine that their email password is the same as the dolibarr password, it's bad practice but it's common) … explain the situation to them and tell them to change their password if it's the same on their mailbox and other online services.
And even if your recent Dolibarr stores encrypted passwords, consider them to be cracked: the hacker has the result of the encrypted password in his hands and with the help of recent techniques (and/or high computing power) he can possibly discover your password. Consider that it was in clear text and apply the same approach.
Other passwords stored in dolibarr
This list is not exhaustive:
- the e-mail account (in Home > Configuration > Emails) → replace the password for this e-mail account as a matter of urgency, as your hacker could use this e-mail account to send spam or worse: for example, to send invoices with a false RIB under your name because it was sent using your real e-mail server.
- users' e-mail accounts if they are configured to send/receive e-mail in Dolibarr with their account, if you have add-ons that allow this
- online services configured in add-on modules (or in the basic modules, for example the stripe account) this may be a login/password or an API key
- …/…
Bank details
Think about YOUR bank details and also those of your customers/suppliers if you store this information in your dolibarr.
Check that this information has not been altered, otherwise in a few months you may discover that you have transferred money to the account of a pirate who thought he was paying your supplier. Conversely, your invoices could show your pirate's bank details instead of your bank details and your customers will think they are paying you by sending them money.
The best solution in this case is to make a “diff” with a backup of your database prior to the attack…
SPAM
The attacker's sole aim may have been to use your hosting as a spam relay, so the security audit should ensure that no tools have been installed for this purpose.
Relay to hack another site
It is also possible that the attacker's objective was to use your hosting as a pivotal platform for hacking into another site. This is especially true now that there are organisations that refuse all incoming connections from an IP address geographically located in certain countries. Hackers in these countries set up “bounce” servers, and yours may be one of them.
Miscellaneous
etc.
RGPD
If the hacker has managed to connect, you should undoubtedly initiate the ad-hoc procedures required by law (the RGPD in this case):
What can you do to prevent it?
To avoid such a situation happening again as much as possible:
- update your dolibarr regularly (when a patch for your version is released, install it without delay as it is a patch for the current version, for example if you have version 16.0.4, install 16.0.5 as soon as it is released)
- set up a real backup policy, which means, among other things:
- if you make one invoice per week it's not the same as if you make 100 per hour
- ask yourself: am I prepared to lose: 1 hour's work, 4 hours' work, 8 hours' work, 1 week's work?
- move your backups
- on another server using a get technique, not a push technique
- check the backups, including restoring them to make sure they are usable
- install additional modules dedicated to security:
If you have access to your dolibarr server a number of simple measures can be taken to avoid or slow down this kind of problem:
- chmod -w or use any “read-only” device for your entire dolibarr code tree (htdocs), you will no longer be able to update or install modules via the web interface but at least a hacker won't be able to modify / write files either.
- chown files in the web tree so that they can be read by your “web server user” but cannot be modified. This is virtually the same as the previous point, except that if the user account in question is hacked, it will still not be possible to modify the files.