couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vivek Pathak <>
Subject Re: ransom note - couchdb exploit / privilege escalation ?
Date Mon, 23 Jan 2017 10:27:04 GMT
Sorry for delayed response (I had to restore the backups and harden the 
server a bit in order to deal with the ongoing attempts to grab my 
data).   And thank you all to those who helped.

Looks like this was a plain password sniffing of admin password. No 
evidence of guessing or repeated attempts - and it was not a simple 
password to guess or crack.

I believe the admin password could only be sniffed because it was on 
open port 5984.   I was careless because the site was in development.

So now I have couchdb listening on, and the admin password is 
now randomly generated 18 characters (dont know good if the centos 7 rng 
has trapdoor though).  The need for replication and UI access via _utils 
can be satisfied by setting up a ssh tunnel via a random port, eg:

     ssh -N -L 57237:localhost:5984  user@

Next is to move to https - and that should complete the securing 
aspect.  Also ended up creating offline backup on a stopped ec2 instance 
- this should come handy if the attack become really serious.

Thank you

On 01/20/2017 09:09 AM, Thomas Guillet wrote:
> @Paul: I agree, it is pretty straightforward to have some basic settings on.
> Could we rely on the cluster_setup endpoint to secure the instance?
> If that is considered to be the first 'mandatory step' of a live
> instance, it would be nice as an almost out-of-the-box secure set up.
> (Plus, you can always "curl" the endpoint instead of "perl" the local.ini)
> SSL-only is tricky as the http server can't be deactivated in
> local.ini but in default.ini (from memory).
> @All: What do you consider a same/secure set up? What are the known
> unsecured features/weaknesses of CouchDB.
> @Vivek: You issue worries me quite a lot. Do you have a better idea of
> what happened?
> I saw you are using HTTP instead of HTTPS, were you using in encrypted
> connection to exchange your credentials and session?
> Is your instance behind a proxy? (nginx or alike) They may have other
> logs to help us investigate.
> 2017-01-20 12:49 GMT+01:00 Paul Hammant <>:
>>> tee-hee, that was my wishful thinking, less actual planning :)
>>> As usual, there is no estimate for now.
>> Don't worry - my open source commitments slip by five years at a time, but
>> I thought I'd ask just in case.
>> It might be better to focus on a series of post-install scripts for 2.x
>> that lock down a couch.
>> I was *very* excited by my first (and more or less only) exposure to
>> CouchDB for -
>> As part of that I wanted to make it easy for the reader to turn on CORS:
>> perl -p -i -e 's/;enable_cors/enable_cors/'
>> /usr/local/etc/couchdb/default.ini
>> perl -p -i -e 's/enable_cors = false/enable_cors = true/'
>> /usr/local/etc/couchdb/default.ini
>> perl -p -i -e 's/;origins/origins/' /usr/local/etc/couchdb/default.ini
>> perl -p -i -e 's/origins = /origins = */' /usr/local/etc/couchdb/default.ini
>> perl -p -i -e 's/origins = \*\*/origins = */'
>> /usr/local/etc/couchdb/default.ini
>> That's to turn on CORS (CouchDB v1.6.x), for the blog entry.
>> I'll bet that it's only another eight "one-liners" (Perl or not) to go
>> SSL-only, cancel the AdminParty, and generate a unique admin password.
>> - Paul

View raw message