Community mailing list archives
Re: Seems Odoo just got hackedby
"The only exposed port was 8069 being mapped to 80 by the docker network layer. "
IMHO, there should be a reverse proxy like Apache or Nginx in between these (maybe HAProxy). I don't "trust" small time HTTP implementations. (also how do you work around long polling?)
There must be a lot of more interesting logs than these. None of these should have been able to compromise anything unless there are seriously bad implementation details in werkzeurg...
My opinion based on the limited information would be less 'compromised' and more 'crashed by ulimit, RAM or other resource constraint'.
None of the provided logs appear to even threaten werkzeurg or Odoo specifically.
On Sep 24, 2015, at 2:58 PM, David Arnold <email@example.com> wrote:Thanks for all the support and comments.Actually, the instance was indeed compromised and did not function. curl on localhost odoo server did not return.Actually also the docker daemon was out of function and, to me seemed compromised as well. Restart of the services was not possible.The actual usage pattern supports that just after the last legal user log in two days ago, the instance stopped working (in between, the strange logs arose)This is indicating, yet not proving, that the attacker got onto the server and compromised it. The only exposed port was 8069 being mapped to 80 by the docker network layer.This is indicating, yet not proving, that the attacker exploited the Odoo website surface by some means. Cloudflare is used and was seemingly not configured/unable to block this specific attack.stat -c%s filename of suspect session file gives 100, so it seems to be empty sessions, the valid sessions among empty ones is.Well, to conclude, I know that I know nothing, except something was compromised. It corresponds to more knowledgeable people to judge upon what really happend. If I can provide additional useful information, I'm happy to do so. If anyone can help me ascertain any type hypothesis to narrow down probable investigation, I'm glad either.Thanks a lot. Best, DavidEl jue., 24 sept. 2015 a las 16:03, Jared Kipe (<firstname.lastname@example.org>) escribió:
First of all, anything ending in 404 is probably not an issue. That means the HTTP server (werkzeug/odoo) correctly determined that the url was not something it could deliver.Having a session does NOT mean you were hacked. You will get a new session generated simply by visiting the login page and not passing a current valid session_id. (at least on v9)Experimentally, in v9 and ubuntu14.04:* a 'fresh' empty session is 92 bytes. (will depend on browser header for language accept)* looking in the sessions after trying various things have taught me the user name is for sure in the session, and there is some component of the password (hash?) in the session if you POST to /web/loginKeep in mind that Odoo is going to make a session regardless on if the client on the other side actually stores the cookie and re-uses it in the next request. Thus you will have a lot of sessions when people are attacking like this or DoS'ing.With a reverse proxy like NGINX or Cloudflare or something you should be able to rate-limit or block this sort of thing completely.JaredThe modifying date of the sessions coinciding with the following line of the supposed attack procedure is a string indication of a hacked password. werkzeug: 188.8.131.52 - - [23/Sep/2015 06:13:23] "GET /pma/scripts/setup.php HTTP/1.0" 404 -Best, David2015-09-24 13:19 GMT-05:00 Nhomar Hernández <email@example.com>:Trace your password.Sorry sent before re read... here I tried to say: Encrypt your connection with ssl to avoid somebody read or trace your passwords.