We collaborate with various individuals and external companies. We grant them access to the systems they need to work on, including Odoo. The collaboration goes well, the freelancer resolves tasks, creates accounts for new users, and introduces new features. But one day, for whatever reason, you decide to change the person you work with. Since the collaboration was going well, you exchange thanks. You archive that user's account, and after some time, strange things start happening in your Odoo...

Beware of such situations, because they happen more often than it seems. And when an attack occurs, originating from someone you collaborated with, it is doubly dangerous and takes away a large portion of trust in people. After all, the collaboration was good, and the developer was always nice and helpful in meetings.

But what's next? How to react to such an incident? What should you check in Odoo? After all, Odoo is software where we can define automated functions along with executable code. Potential traps left by our former colleague can be anywhere.

In the described case, the situation happened in Odoo hosted on Odoo.sh — a very popular PaaS system. The incident was not related to advanced attack methods. It was simply an ordinary developer who (probably) felt offended by the termination of the collaboration and hid various authentication methods in the system, through which they made normal work impossible.

Discovering such an attack is a big surprise. Time is of the essence. How can you effectively revoke all permissions? On the Odoo website, there is no single list indicating what to do step by step in this case, and technical support can be very slow. So I made decision to share such list here, on my blog.

Odoo.sh

Remove GitHub users who should not have access to the repository.

Remove SSH keys (configured in the project)

Remove Deploy Keys

Odoo

System Parameters

API Keys

Users

Login Providers

Scheduled Actions

Automated Actions

Server Actions

Views

Payments

Shipping Methods

Email Servers

This list may not be complete!

You might have installed modules containing malicious code, something might have changed since this post was written... or I simply missed something. Your server logs will best answer the question — how the attacker gained access.

If you need help — contact me!