couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: ransom note - couchdb exploit / privilege escalation ?
Date Fri, 20 Jan 2017 11:09:31 GMT
Hi Thomas,

thank you for offering to help. We first need to find out what is going
at all, so we can do the right thing.

We’ve already prepared many things to move away from Admin Party by
default in 3.0.

> Plus to mitigate risk (and limit interest), Fauxton should be
> minimalist (Once out of the "Admin Party" we should only see a login
> screen - no menu on the left [Especially the verify menu]).

There is a common misconception here: Fauxton is just a UI to the
APIs that are accessible. So even without Fauxton, that data is
available to anyone using curl. The real solution is to close the
API and adapt Fauxton.

* * *

That _all_dbs is still open the public is something I had wanted to
have changed for 2.0 but it slipped through the cracks. I’d be in
favour of making this reality for 3.0.

In addition, we are currently thinking of these changes to the default
setup for 3.0 and onwards:

- do not start without an admin account configured
- new databases created are server admin only until granted explicit user permission
  - I’d like to make this easy by allowing to use the HTTP body of PUT /dbname to
    create the _security object, so we can do PUT /dbname {"admins”: [...], "members”:[...]}
in one shot

That’s it for now, really, there are a few more unbaked ideas, but this should cover most
of the problems

Best
Jan
--



> On 20 Jan 2017, at 11:07, Thomas Guillet <guillet.thomas@gmail.com> wrote:
> 
> Hi all,
> 
> That is annoying... Good to read you have some backups and won't be
> too impacted by this issue.
> 
> I think it is important to make sure that a CouchDB instance (port
> 6984 or port 5984 behind a ssl proxy) is safe to expose to the wild.
> 
> In a way, that is related to Paul Hammant email "Admin Party" from
> Friday 6th of January.
> Out of the box, the instance may not be safe but it should be pretty
> easy (as part of the setup in Fauxton for instance).
> 
> I am thinking as an example, GET _users, _replicator should only be
> visible to server admins
> 
> Plus to mitigate risk (and limit interest), Fauxton should be
> minimalist (Once out of the "Admin Party" we should only see a login
> screen - no menu on the left [Especially the verify menu]).
> 
> I have some free time at the moment and I wish to deploy a secured
> CouchDB instance soon so let me know if I can be of any help. I tweak
> part of the 2.0.0 source code to prevent displaying to much data to
> anonymous user. (I hid _all_dbs to anyone but server admins for
> instance).
> 
> Thomas
> 
> 2017-01-19 23:16 GMT+01:00 Robert Samuel Newson <rnewson@apache.org>:
>> Hi Vivek,
>> 
>> We've received your report. I'm going to open a thread on our private security@ mailing
list and include you to continue discussing the details further.
>> 
>> For everyone else following dev@, we are investigating, and will report back here
as we progress.
>> 
>> B.
>> 
>> 
>>> On 19 Jan 2017, at 21:22, Vivek Pathak <vpathak@orgmeta.com> wrote:
>>> 
>>> Hi
>>> 
>>> I am building a site http://jobfairinsider.com/ which internally uses couchdb
1.6.1 for data hosting and management.  I have backups etc. - So the purpose of this post
is more to share details about the intrusion and to get everyone's feedback on how to investigate
it and avoid it in the future.
>>> 
>>> My setup has an admin user in couchdb whose password I dont think was compromised
(as confirmed by log grep on _session).  I had port 5984 open for some time while developing
and improving the site and its content.
>>> 
>>> The intrusion deleted all the databases and created a pleaseread database with
a ransom note.  The contents are available here: http://jobfairinsider.com:5984/_utils/document.html?pleaseread/5dc534179e5689037c222ed3fb36bf1b
>>> 
>>> The logs from couchdb are given at bottom.  I do not see _session to login but
the databases could all be deleted.  I was expecting this behavior:
>>> 
>>> [Thu, 19 Jan 2017 20:35:42 GMT] [info] [<0.4041.0>] 127.0.0.1 - - DELETE
/testdb 401
>>> 
>>> But what we got is given below.
>>> 
>>> Thoughts?
>>> 
>>> Thanks
>>> 
>>> Vivek
>>> 
>>> [Wed, 18 Jan 2017 10:23:44 GMT] [info] [<0.31649.25>] 37.48.125.116 - -
DELETE /jfidb 200
>>> [Wed, 18 Jan 2017 10:23:44 GMT] [info] [<0.674.0>] Closing index for db:
jfidb idx: _design/wax sig: "872546a6edf5e779549881653de29e3f"
>>> reason: normal
>>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.8281.0>] Index shutdown by monitor
notice for db: jfiurls idx: _design/content
>>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.23.26>] 37.48.125.116 - - DELETE
/jfiurls 200
>>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.8281.0>] Closing index for db:
jfiurls idx: _design/content sig: "440593a33a61f567c164d0ae5e4b95e2"
>>> reason: normal
>>> [Wed, 18 Jan 2017 10:23:45 GMT] [info] [<0.32659.25>] 37.48.125.116 - -
PUT /pleaseread 201
>>> [Wed, 18 Jan 2017 10:23:46 GMT] [info] [<0.642.26>] 37.48.125.116 - - POST
/pleaseread 201
>>> 
>>> 
>>> Copy of the ransom doc:
>>> 
>>>      |{ "|_id|": |"5dc534179e5689037c222ed3fb36bf1b"|, "|_rev|":
>>>      |"1-5abb0255ebabae409655d39b8f61a0fb"|, "|PLEASE_READ|": |"SEND
>>>      0.1 BTC TO THIS WALLET: 1LM1e9zB1ZG6fGsYjeCMxSuBGcbAo5bF85 IF
>>>      YOU WANT RECOVER YOUR DATABASE! SEND TO THIS EMAIL YOUR SERVER
>>>      IP AFTER SENDING THE BITCOINS r3l4x@sigaint.org HOW TO BUY
>>>      BITCOIN:
>>>      https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)"| }|
>>> 
>> 

-- 
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/


Mime
View raw message