Couchdb: user: rootbakseven shows in _users but was not created

Created on 3 Mar 2019  路  12Comments  路  Source: apache/couchdb

I have discovered that my docker container which i recreate daily dose not save the admin password.
After this discovery i have searched for modifications in my databases and the _users database.

The user "rootbakseven" was show, i deleted him.
He has had no speciale roles.

The user is not shown in _global_changes even not my deleten of this account.

Is he an user of one of the couchDB processes or some user created by some "hacker"?

Why is the default setting "all permissions for anyone" what is with the "Secure by Default" philosophy?

bug needs-triage

Most helpful comment

@i5heu CouchDB 3.0 will be secure by default, this is in our roadmap. See https://github.com/apache/couchdb/issues/1504 .

All 12 comments

CouchDB is "secure by default" since it's binded to your loopback address. If you change that address and make CouchDB public, you have to and some securities (eg: create an admin?)

Also, the rootbakseven is not a user created by CouchDB. It must have been created by a bot or crawler.

Okay thank you for the information.

Why is the creation of the user not shown in the _users or in _global_chages?

security Docs: https://docs.couchdb.org/en/master/intro/security.html

_global_changes only includes the list of databases sorted by the last time they were updated. New users are not recorded there.

Thanks for your help!

I'm experiencing the same issue. I made sure the I've set-up a strong/long admin password.
The server I've installed is just for development purposes at the moment.
I've installed the CouchDB server on a blank Ubuntu server, and user the firewall to expose only port 22(SSH) and 5984 to the internet.
The user keeps showing up in the _users database.
I noticed this, because I'm developimg template/boilerplate system running only CouchDB in the back-end and JavaScript in the front-end. The only communication with the server, from my side is via the Fauxton utlility and the Javascript fetch-API.
I thoucht it was a hacker, but then I decided to re-install a blank server, and the rootbakseven user appeared again.
I use Ubuntu 18.10 and CouchDB 2.3.1

The _users database contains no users by default, so the presence of any document in there indicates someone/something has created it.

Assuming you've followed the couchdb install steps (or used the wizard in the dashboard which automates them), you have defined at least one admin account (which is not stored in the _users database) with, hopefully, a strong password. This step ensures that anonymous users cannot create or delete databases, nor can they grant themselves access to existing databases. However, they can still make documents in the _users database or any other database that allows anonymous writes.

The next major release of CouchDB will change the default permissions of a new database to "admin only" from the current default of allowing anyone to read/write, but you can set this for yourself;

curl -X PUT http://user:pass@localhost:5984/_node/_local/_config/couchdb/default_security -d '"admin_only"'

Or you can set the _security object of each database (including _users) to suit your specific needs.

Thank you rnewson.
Problem solved.

After examining couchdb logs, I found that there are someone from ip address 185.242.6.4 and 185.242.6.3 creating the rootbakseven user. Other offending ip addresses that made random users are:
219.78.51.195
222.133.177.93
221.127.8.185
86.106.156.192

I'm thinking of creating a honeypot couchdb server, just for collecting offending ip addresses and creating and publishing the list for others to use.

@jacorall This isn't the place to share that information, especially since machines that are scanning your network will likely be from all over the globe, many on dynamically assigned addresses.

Feel free to set up your own blogpost with info about what you find and share a link to it here.

The _users database contains no users by default, so the presence of any document in there indicates someone/something has created it.

This was the mistake i made.

Maybe a warning sign in fauxton with "Public write/read" would lead to more safety.

@i5heu CouchDB 3.0 will be secure by default, this is in our roadmap. See https://github.com/apache/couchdb/issues/1504 .

Additional data point: I noticed this user in my _users database as well after I opened up my Google Cloud deployment to external IPs. It kept reappearing even after I deleted it, but I thought it might be just an artifact. I left it alone but realized that my CPU utilization always spiked literally from 0 to 100% some time after server restarts, which led me to this thread.

After implementing some basic user validation and deleting the user, my CPU utilization has dropped back down. Definitely some crypto mining going on.

Was this page helpful?
0 / 5 - 0 ratings