Re: ransom note - couchdb exploit / privilege escalation ?

[Paul Hammant]

What would happen if local.ini were deleted post-install, and all hardening
modifications were to default.ini (as I did for the CORS toggle-flip) ?


> 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).
>

Re: ransom note - couchdb exploit / privilege escalation ?

[Robert Newson]

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  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 :
> 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
>> 
> 

Re: ransom note - couchdb exploit / privilege escalation ?

[Vivek Pathak]

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 :

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

Re: ransom note - couchdb exploit / privilege escalation ?

[Vivek Pathak]

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 :

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

Re: ransom note - couchdb exploit / privilege escalation ?

[Robert Newson]

A reminder that the security sensitive discussion with Vivek is happening 
elsewhere. We don't want to reveal any issue that might be found until we have 
a fix, if  it turns out to be an avoidable fault in couchdb. The discussion of 
improved 3.0 defaults can continue here or in a new thread. 

Sent from my iPhone

> On 20 Jan 2017, at 14:09, 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 - 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

Re: ransom note - couchdb exploit / privilege escalation ?

[Thomas Guillet]

@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 - 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

Re: ransom note - couchdb exploit / privilege escalation ?

[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 - 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

Re: ransom note - couchdb exploit / privilege escalation ?

[Jan Lehnardt]

> On 20 Jan 2017, at 12:32, Paul Hammant  wrote:
> 
> Hey Jan. In a thread "CouchDB Next" in Sept, Couch DB 3.0 was thought to be
> 3-6 months in the future. What's the current thinking?

tee-hee, that was my wishful thinking, less actual planning :)

As usual, there is no estimate for now.

Best
Jan
--

> 
> - Paul
> 
> On Fri, Jan 20, 2017 at 6:09 AM, Jan Lehnardt  wrote:
> 
>> 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 
>> 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 :
 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  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 

Re: ransom note - couchdb exploit / privilege escalation ?

[Paul Hammant]

Hey Jan. In a thread "CouchDB Next" in Sept, Couch DB 3.0 was thought to be
3-6 months in the future. What's the current thinking?

- Paul

On Fri, Jan 20, 2017 at 6:09 AM, Jan Lehnardt  wrote:

> 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 
> 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 :
> >> 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  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, 

Re: ransom note - couchdb exploit / privilege escalation ?

[Jan Lehnardt]

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  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 :
>> 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  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 
>>> 

Re: ransom note - couchdb exploit / privilege escalation ?

[Thomas Guillet]

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 :
> 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  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 r3...@sigaint.org HOW TO BUY
>>   BITCOIN:
>>   https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)"| }|
>>
>

Re: ransom note - couchdb exploit / privilege escalation ?

[Robert Samuel Newson]

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  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 r3...@sigaint.org HOW TO BUY
>   BITCOIN:
>   https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)"| }|
> 

ransom note - couchdb exploit / privilege escalation ?

[Vivek Pathak]

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 r3...@sigaint.org HOW TO BUY
   BITCOIN:
   https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)"| }|