Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Subject: Re: ransom note - couchdb exploit / privilege escalation ?
To: dev@couchdb.apache.org
References: <CA+298Ujw5ooFSz0Zh4V6cRSOWsXSp9U6KODUTVp_XFAFdzJyDg@mail.gmail.com>
 <CAAwdm2OeE+tFqiDb5tCPRZ=xcRpG1LzaxsoYws++330JjSZwDA@mail.gmail.com>
 <8434d7e4-2a9a-d854-6582-bb00c554f448@orgmeta.com>
From: Vivek Pathak <vpathak@orgmeta.com>
Message-ID: <d95a4731-e506-e5de-4efd-d045ed567242@orgmeta.com>
Date: Mon, 23 Jan 2017 05:39:38 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <8434d7e4-2a9a-d854-6582-bb00c554f448@orgmeta.com>
Content-Type: multipart/alternative;
 boundary="------------52649A6C039D1813220BC1F6"
archived-at: Mon, 23 Jan 2017 10:39:46 -0000

--------------52649A6C039D1813220BC1F6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

As a follow up, I have a design question

http://docs.couchdb.org/en/2.0.0/intro/security.html#authentication-database 
says:

  * There is a special design document|_auth|that cannot be modified

However it looks like the admin user can delete the authentication 
database (thereby deleting _auth document as well).

Is there a convenience benefit of allowing this (eg: admin party is 
useful when you start off locally and dont care about security) ?

Thanks
Vivek


On 01/23/2017 05:27 AM, Vivek Pathak wrote:
> 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 127.0.0.1, 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@1.2.3.4
>
> 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 <hammant@apache.org>:
>>>> 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 - 
>>> http://paulhammant.com/2015/12/21/angular-and-svg-and-couchdb.
>>> 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
>


--------------52649A6C039D1813220BC1F6--