Recent and ongoing brute-force scan on Odoo installations
Affects: Internet-facing Odoo servers with default passwords Credits: Christophe Hanon Disclosed: January 27, 2017 OVE ID: OVE-20170127-0001
Update 1 (2017-01-30) : reports of botnet-like scripts
We have received reports of compromised servers on which a proxy script was found to be running, presumably started through the backdoor installed during the attack. Such a script will usually be visible in the process list as an unknown process listening on an unusual TCP port, such as 9999. You may also have seen an increase in bandwidth use, as a consequence of traffic tunnelled through the proxy.
Some reports mention this process was started from an executable odoo.py file located in the data_dir, next to the sessions and filestore directories, and contains a copy of this generic proxy script.
I. Background
Odoo SA recently became aware of an ongoing brute-force scan attack
targeting Odoo servers that are publicly accessible on the Internet.
If you own or operate an Odoo installation that is publicly accessible,
you are a likely target for this attack. In that case we urge
you to verify that you are not using default passwords, that your
servers have not been compromised, and that you have appropriate
mitigation strategies in place.
This is particularly true if you have test/dev/staging databases hosted
on internet-facing servers, possibly next to your production databases.
Such databases are often more likely to use default passwords.
Odoo Online services have not been impacted, are not vulnerable, and
are closely being monitored.
II. Attack Description
No exploit is involved in this attack, the main entry point is
a database with a default login/password combination.
Several different IP addresses were used to scan many network
blocks, looking for Odoo servers answering to XML-RPC requests on
common ports (8069, 80, 443, perhaps others).
Some known scanner IPs: 164.132.96.170, 197.2.230.86
Known activity period: January 19, 2017 to January 27, 2017 (ongoing!)
After locating an Odoo server, the scanner tries to obtain the list of
available databases by sending an HTTP POST to /xmlrpc/2/db or /xmlrpc/db,
and then attempts to login on each database with the default login/password
combination: admin/admin.
This is usually visible in the Odoo server logs as multiple failed
login attempts for the 'admin' user on each database: (...) Login failed for db:<DB_NAME> login:admin
and/or possibly a successful login if the attack succeeded: (...) successful login from 'admin' using database '<DB_NAME>'
As soon as the scanner managed to gain entry to a database using a
default admin password, it attempts to install a malicious
module from the Odoo Apps Store. This would be visible in the Odoo
server logs as follows:
(...) Downloading module `upload_github_odoo` from OpenERP Apps
(...) Copy downloaded module `upload_github_odoo` to `<LOCAL_PATH>`
This malicious module has been removed from the Apps Store as soon as
it was identified, on January 25. The same module was later uploaded
with another name, and similarly removed.
After installing this module, the attacker would use it to download
and install another piece of code to allow remote execution of
arbitrary commands, further compromising the machine.
This would typically be visible in the server logs as well:
(...) Downloading module `<MODULE>` from github
(...) Copy downloaded module `<MODULE>` to `<LOCAL_PATH>`
If successful up to this point, the attacker would be able to remotely
execute arbitrary commands by sending XML-RPC requests.
III. Impact
After successfully gaining admin access to a vulnerable database, the
attacker installed a malicious module to enable remote command execution.
This may have been used to execute arbitrary code as the user
running the Odoo service, granting access to local files and local services.
Files and environments accessed in this manner may contain sensitive
information such as passwords that could allow the user to gain elevated
privileges on the hosting environment itself.
It is not known whether the attacker has used any of the compromised
installations to actually execute commands.
IV. Detecting a successful attack
If you have internet-facing Odoo deployments, please read carefully the
attack description in section II, and verify your server logs for
any occurrence of the scanner IPs or of any of the suspicious log
messages.
A compromised database will have an entry labelled "Zip Install" or
"upload_github_odoo` in the list of installed modules.
We urge you to verify your logs even if you do not believe that you
were using default passwords, to be on the safe side!
If one of your databases was compromised, you should assume that
your databases and your server files may have been accessed and
modified. As a precaution, act as if the whole machine was compromised,
and start by immediately taking it offline for analysis and
reinstallation.
V. Mitigation by Odoo SA
Odoo SA has taken multiple steps to limit the extent of this attack and
improve the safety of Odoo users:
The malicious Apps were removed as soon as they were identified.
This blocked the main escalation step between admin account compromise
and remote command execution. (As of 2017-01-25 11:16 CET +01:00)
In order to entirely prevent similar attacks with other malicious Apps,
the one-click automatic installation of Odoo Apps has been entirely
blocked on the Odoo Apps Store (as of January, 25, 19:40 CET +01:00).
This is effective for all Odoo versions, without requiring local patches.
This forces all users to perform the installation of Odoo Apps
manually for the moment, but most importantly blocks the channel used to
distribute the remote privilege code used in this attack.
The one-click installation system may be reactivated in the future,
with other security measures in place.
Based on an analysis of the activity on the Odoo Apps Store, Odoo SA
is collecting the list of IPs that seem to have been compromised
(this list cannot be disclosed, for obvious reasons)
Whenever these IPs can be traced back to an administrator, Odoo SA is
contacting the administrators directly to warn them about the attack.
As of Odoo 9, the default admin/admin combination is not used anymore
for new databases created via the Odoo database manager screen.
Odoo SA is planning further improvements to the database creation
mechanism and password management, such as warning administrators that
would still be using default credentials.
Extra verification steps will be implemented for modules published on
the Odoo Apps Store, some of them automated and some of them manual,
in order to increase the security of the users.
V. Local Mitigation
All Odoo server administrators are strongly encouraged to follow best
practices when deploying Odoo services, such as:
Always secure the super-admin and all admin accounts with strong
passwords and unique usernames. Never use default passwords!
Restrict access to the database manager once the system is setup
Use appropriate database filters (--db-filter parameter)
Security Advisory (ODOO-SA-2017-01-27-1)
Recent and ongoing brute-force scan on Odoo installations
Affects: Internet-facing Odoo servers with default passwords
Credits: Christophe Hanon
Disclosed: January 27, 2017
OVE ID: OVE-20170127-0001
Update 1 (2017-01-30) : reports of botnet-like scripts
We have received reports of compromised servers on which a proxy script was found to be running, presumably started through the backdoor installed during the attack. Such a script will usually be visible in the process list as an unknown process listening on an unusual TCP port, such as 9999. You may also have seen an increase in bandwidth use, as a consequence of traffic tunnelled through the proxy.
Some reports mention this process was started from an executable
odoo.py
file located in thedata_dir
, next to thesessions
andfilestore
directories, and contains a copy of this generic proxy script.I. Background
Odoo SA recently became aware of an ongoing brute-force scan attack
targeting Odoo servers that are publicly accessible on the Internet.
If you own or operate an Odoo installation that is publicly accessible,
you are a likely target for this attack. In that case we urge
you to verify that you are not using default passwords, that your
servers have not been compromised, and that you have appropriate
mitigation strategies in place.
This is particularly true if you have test/dev/staging databases hosted
on internet-facing servers, possibly next to your production databases.
Such databases are often more likely to use default passwords.
Odoo Online services have not been impacted, are not vulnerable, and
are closely being monitored.
II. Attack Description
No exploit is involved in this attack, the main entry point is
a database with a default login/password combination.
Several different IP addresses were used to scan many network
blocks, looking for Odoo servers answering to XML-RPC requests on
common ports (8069, 80, 443, perhaps others).
Some known scanner IPs: 164.132.96.170, 197.2.230.86
Known activity period: January 19, 2017 to January 27, 2017 (ongoing!)
After locating an Odoo server, the scanner tries to obtain the list of
available databases by sending an HTTP POST to /xmlrpc/2/db or /xmlrpc/db,
and then attempts to login on each database with the default login/password
combination: admin/admin.
This is usually visible in the Odoo server logs as multiple failed
login attempts for the 'admin' user on each database:
(...) Login failed for db:<DB_NAME> login:admin
and/or possibly a successful login if the attack succeeded:
(...) successful login from 'admin' using database '<DB_NAME>'
As soon as the scanner managed to gain entry to a database using a
default admin password, it attempts to install a malicious
module from the Odoo Apps Store. This would be visible in the Odoo
server logs as follows:
This malicious module has been removed from the Apps Store as soon as
it was identified, on January 25. The same module was later uploaded
with another name, and similarly removed.
After installing this module, the attacker would use it to download
and install another piece of code to allow remote execution of
arbitrary commands, further compromising the machine.
This would typically be visible in the server logs as well:
If successful up to this point, the attacker would be able to remotely
execute arbitrary commands by sending XML-RPC requests.
III. Impact
After successfully gaining admin access to a vulnerable database, the
attacker installed a malicious module to enable remote command execution.
This may have been used to execute arbitrary code as the user
running the Odoo service, granting access to local files and local services.
Files and environments accessed in this manner may contain sensitive
information such as passwords that could allow the user to gain elevated
privileges on the hosting environment itself.
It is not known whether the attacker has used any of the compromised
installations to actually execute commands.
IV. Detecting a successful attack
If you have internet-facing Odoo deployments, please read carefully the
attack description in section II, and verify your server logs for
any occurrence of the scanner IPs or of any of the suspicious log
messages.
A compromised database will have an entry labelled "Zip Install" or
"upload_github_odoo` in the list of installed modules.
We urge you to verify your logs even if you do not believe that you
were using default passwords, to be on the safe side!
If one of your databases was compromised, you should assume that
your databases and your server files may have been accessed and
modified. As a precaution, act as if the whole machine was compromised,
and start by immediately taking it offline for analysis and
reinstallation.
V. Mitigation by Odoo SA
Odoo SA has taken multiple steps to limit the extent of this attack and
improve the safety of Odoo users:
The malicious Apps were removed as soon as they were identified.
This blocked the main escalation step between admin account compromise
and remote command execution. (As of 2017-01-25 11:16 CET +01:00)
In order to entirely prevent similar attacks with other malicious Apps,
the one-click automatic installation of Odoo Apps has been entirely
blocked on the Odoo Apps Store (as of January, 25, 19:40 CET +01:00).
This is effective for all Odoo versions, without requiring local patches.
This forces all users to perform the installation of Odoo Apps
manually for the moment, but most importantly blocks the channel used to
distribute the remote privilege code used in this attack.
The one-click installation system may be reactivated in the future,
with other security measures in place.
Based on an analysis of the activity on the Odoo Apps Store, Odoo SA
is collecting the list of IPs that seem to have been compromised
(this list cannot be disclosed, for obvious reasons)
Whenever these IPs can be traced back to an administrator, Odoo SA is
contacting the administrators directly to warn them about the attack.
Odoo 8, 9 and 10 have been updated to help server administrators further
secure their installations, by blocking the one-click installation of
Odoo Apps locally as well.
Please refer to Issue The one-click deployment of Odoo Apps should be controllable by sysadmins #15225 for more details, and the list of corrected
revisions.
The one-click deployment of Odoo Apps should be controllable by sysadmins #15225
As of Odoo 9, the default admin/admin combination is not used anymore
for new databases created via the Odoo database manager screen.
Odoo SA is planning further improvements to the database creation
mechanism and password management, such as warning administrators that
would still be using default credentials.
Extra verification steps will be implemented for modules published on
the Odoo Apps Store, some of them automated and some of them manual,
in order to increase the security of the users.
V. Local Mitigation
All Odoo server administrators are strongly encouraged to follow best
practices when deploying Odoo services, such as:
passwords and unique usernames. Never use default passwords!
either via GitHub or by downloading the latest version from
https://www.odoo.com/page/download or http://nightly.odoo.com
valid SSL certificate
from each other
Please refer to the Odoo deployment documentation for more information:
http://www.odoo.com/documentation/10.0/setup/deploy.html
VI. Further Information
Please contact our Security Team if you need to further discuss this
Security Advisory:
https://www.odoo.com/page/responsible-disclosure
The text was updated successfully, but these errors were encountered: