[SERVER-60230] MongoDB aduit filter for drop collection can be bypassed Created: 27/Sep/21  Updated: 18/Oct/21  Resolved: 18/Oct/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.4.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Zhu Eddie Assignee: Eric Sedor
Resolution: Duplicate Votes: 0
Labels: Bug
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-50994 Audit of dropCollection during dropDa... Closed
Operating System: ALL
Steps To Reproduce:

1. Specify the filter in mongodB cofiguration file.
filter: '{ atype:

{ $in: [ "createCollection", "dropCollection" ] }

}'

2.Open a session, watch for any audit log change:
tail -f auditLog.bson

3.Open another session and login as root
mongo admin -u admin -p 123456

4. Add a new database test
MongoDB Enterprise > use test
switched to db test

5. Create a collection, as you can see, the audit log will have the relevant entry.
MongoDB Enterprise > db.t1.insert({name:'david'})
WriteResult({ "nInserted" : 1 })

6. Drop a collection, the audit filter also works well.
db.t1.drop()
true

7. Create the collection again
MongoDB Enterprise > db.t1.insert({name:'david'})
WriteResult({ "nInserted" : 1 })

8.Show Collections
MongoDB Enterprise > show collections
t1

9. Drop database test
MongoDB Enterprise > db.dropDatabase()

{ "dropped" : "test", "ok" : 1 }

10.
MongoDB Enterprise > db.getName()
test

11.Show Collections
MongoDB Enterprise > show collections

As you can see, after dropping the database, the collection is removed cascadingly without leave any audit entry.

Participants:

 Description   

MongoDB server version: 4.4.1
CentOS Linux release 7.6.1810 (Core)

 
MongoDB audit filter is able to audit the createCollection and dropCollection actions.
But with method db.dropDatabase, the attacker could bypass the audit filter by removing the current database.



 Comments   
Comment by Eric Sedor [ 06/Oct/21 ]

Hi zhuqiangtj@gmail.com,

This looks like it may have been addressed for standalone nodes MongoDB 5.0, in SERVER-50994, which ensures that standalone node types (mongos, mongod in standalone mode) always audit these operations as part of auditing a dropDatabase operation.

It sounds like you are seeing this behavior on a standalone node (versus a replica set node), is that right? If so, you should be able to either upgrade to MongoDB 5.0 or run on version 4.4 as a replica set.

Does this help?

Eric

Generated at Thu Feb 08 05:49:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.