couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: ransom note - couchdb exploit / privilege escalation ?
Date Mon, 23 Jan 2017 12:04:27 GMT
Hi Vivek,

Thanks for the update and thanks for persevering. I agree with you on likely cause here. 

To your follow up question, it's not intentional that _users can be deleted, its more a side
effect of admin privileges. CouchDB before 2.0 will create that db automatically if it's missing.
From 2.0 we can't automate it as we need to wait until the cluster is joined. 

Sent from my iPhone

> On 23 Jan 2017, at 10:39, Vivek Pathak <vpathak@orgmeta.com> wrote:
> 
> 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
>> 
> 


Mime
View raw message