I recently updated mongometer to make it a bit more flexible. Shortly after releasing the new version, one of the users fed back an issue via a comment on the post. I booted up my machine, opened up my IDE, found the issue and had pushed the fix out to github within half-an-hour. This isn’t a quick turn-around, success story post. It quickly dawned on me that if I was going to do anything in the future with mongometer, I should really know a little more about how a user authenticates against a database within MongoDB. (I don’t want to spend more than an hour or so on this as I’ve just cracked open a bottle of Nyetimber Classic Cuvee – I’m also cooking a chicken pie (ping me if you want the recipe) and I’d rather be finished this post before I finish the bottle.) Before diving into any documentation that may exist around MongoDB Security, I’ll start with a few observations.
So in typical man style, let’s kick the tyres and then if required, RTFM. Start up a mongod instance.
$ /usr/lib/mongodb/2.3.2/bin/mongod --port 27001 --fork --dbpath /data/db/2.3.2 --logpath /data/db/2.3.2/mongod.log $ ./mongo --port 27001
Create an admin user
> use admin
> db.addUser('mongouser','mongopass')
1Restart mongod
$ sudo kill -15 $(ps -ef | grep mongo | grep -v grep | cut -f8 -d' ') $ /usr/lib/mongodb/2.3.2/bin/mongod --port 27001 --fork --auth --dbpath /data/db/2.3.2 --logpath /data/db/2.3.2/mongod.log $ ./mongo --port 27001
Authenticate to admin
> use admin
switched to db admin
> db.aut('mongouser','mongopass')
Thu Jan 31 13:53:31.271 javascript execution failed (shell):1 TypeError: Property 'aut' of object admin is not a function
db.aut('mongouser','mongopass')
^ > db.aut('mongouser','mongopass')Ooops. Fat-fingered it. Hang on, I think I’ve found Issue #1
Issue #1
If an admin user mistypes the auth command and not the credentials, then the actual credentials stay in the shell history, which persists across sessions. Any other user could potentially come along and view the shell history and pick the credentials up.
On the other hand, if the command is correct and either the username or password or both are incorrect, or indeed if the authentication attempts succeeds, then the command is not kept in the history. (The command history for the mongo shell is available in the same way as on a linux box – using the up arrow)
> db.auth('mongouser','mongopass0')
{ ok: 0.0, errmsg: 'auth fails' }
0
> db.auth('mongouser0','mongopass0')
{ ok: 0.0, errmsg: 'auth fails' }
0
> db.auth('mongouser0','mongopass')
{ ok: 0.0, errmsg: 'auth fails' }
0 Ok. Let’s authenticate against admin and continue.
> use admin
switched to db admin
> db.auth('mongouser','mongopass')
1 Oooops. I almost missed one there.
Issue #2
Until the mongod instance is restarted, any user can…
> use admin
switched to db admin
> db.system.users.find()
{ '_id' : ObjectId('510a58c6de50e136190f9ed7'), 'user' : 'mongouser', 'readOnly' : false, 'pwd' : 'c49caa1cb6b287ff6b1deaeeb8f4d149' } …grab the usernames and hashes. So, now that I’ve restarted the mongod instance, any user is going to have to authenticate against admin to be able to view the contents of system.users. Now, continuing on from entering incorrect credentials, I’m going to launch a dictionary attack and see what happens. Oh dear. Found another issue.
Issue #3
There is no lock-out. I wrote a quick hack to connect to the mongod instance, to switch over to admin and attempt to log in. Using a rather large dictionary (with ‘mongopass’ tacked on at the end) I attempted to log in over a million times. This was only a crude single-threaded attempt that took around 17 seconds to complete, but it shows that there is no account lock out. I’m confident I could put together a multi-threaded brute-forcer if required. I’ll need to look into this further to see if there is any brute forcing/dictionary attack alerting that can be configured or whether there is a lock-out policy that can be applied. I’m not ready to RTFM just yet. Let’s take a closer look at the format of the password in system.users.
c49caa1cb6b287ff6b1deaeeb8f4d149
That looks like an MD5 to me. Let’s take a look in the code, which is available to cruise on github. Wow! I got luck straight off-the-bat. db.js has the following method:
function _hashPassword(username, password) {
return hex_md5(username + ':mongo:' + password);
} With hex_md5 then referencing native_hex_md5 within utils.cpp:
void installGlobalUtils( Scope& scope ) {
scope.injectNative( 'hex_md5' , native_hex_md5 );
scope.injectNative( 'version' , native_version );
scope.injectNative( 'sleep' , native_sleep );
installBenchmarkSystem( scope );
}
static BSONObj native_hex_md5( const BSONObj& args, void* data ) {
uassert( 10261, 'hex_md5 takes a single string argument -- hex_md5(string)',
args.nFields() == 1 && args.firstElement().type() == String );
const char * s = args.firstElement().valuestrsafe();
md5digest d;
md5_state_t st;
md5_init(&st);
md5_append( &st , (const md5_byte_t*)s , strlen( s ) );
md5_finish(&st, d);
return BSON( '' << digestToString( d ) );
}Time for a quick recap. Just in case you missed anything:
- the hashing algorithm is MD5; my least favourite hashing algorithm.
- the string to be hashed is in the form
username + ':mongo:' + password; using the same ‘salt’ is non-optimal… - the string
:mongo:is global; I’m not really sure why it’s there at all tbh.
I think this is probably enough to go with for now, else this will turn into a tl;dr and I may exceed my self imposed time constraints. Thinking back to any discussions I had with regards to MongoDB, the same statements always arose within the context of Security.
- Authentication is off by default.
- MongoDB was always meant to be deployed in a trusted environment
I have to say that even with authentication on, we still have some gnarly issues. Further, I don’t think a trusted environment exists. Right then, time to RTFM with regards to Security. I’m hoping to find a roadmap defined that will deal with the issues stated above or there are already some mitigating steps that can be taken. So, there are some Authentication features coming out in the near future. It looks like the new authentication features are only available under the MongoDB Subscriber Edition, I’m not sure what that means tbh… I also came across this know issue, which forms the basis for…
Issue #4
‘if a user has the same password in multiple databases, the hash will be the same on all database. A malicious user could exploit this to gain access on a second database use a different users’ credentials.’ [sic] Let’s break that down.
‘if a user has the same password in multiple databases, the hash will be the same on all database.’
Yes. Correct. Same username, same password and same ‘salt’ (ie the ‘:mongo:’ string’) equals same hash. OK, cool, let’s move on.
‘A malicious user could exploit this to gain access on a second database use a different users’ credentials.’ [sic]
A malicious user could exploit this if, and only if they have a non-readonly user on both databases involved.
If they only have readonly access, then they cannot list the system.users collection. In which case they will never see that the hashes are the same across different databases in the first place. If they are not readonly, then they could list the system.users collection and take the hashed passwords offline to crack.
You’re going to have to move into cracking territory if the hashes don’t match across databases, in summary:
- the user attribute would have be the same. The odds of different users on different databases having the user could be high.
- the pwd attribute would have be the same. The odds of different users creating the same pwd is probably quite high.
- the ‘salt’ is the same, so it has no real relevance here.
So the problem here is that a user (that is not readonly) can pull all the password hashes for a given database and take them offline to crack. The malicious user already has the user name and the ‘salt’, all they have to find is the password.
Conclusions
Issue #1
This one is a bit of a pain tbh. When the command is entered correctly (ignoring whether the credentials are correct or not) the command is not shown in the history. When the command is not entered correctly, then it is difficult to know what to exclude from the command history. I guess you could retrospectively remove commands that resulted in errors (ie invalid commands) that preceded the authentication. That is not a solution…
Issue #2
There may be an argument that once the admin user is created in system.users in the admin database that a restart should be forced.
Issue #3
A no-brainer. I’ve written password policies on multiple occasions (what a fun life I live, eh?), account lock-out is password 101.
Issue #4
It seems that creating a ‘salt’ (‘:mongo:’) per database would resolve the issue. Looking at the code, it looks like the implementation is a doddle, a quick and easy win. Adding the option to manually set it would be grand. Implementing a unique ‘salt’ under the covers such that users didn’t have to think about it would be equally grand. So, Nyetimber finished, post finished. I’m not saying that there is anything in this post that is new or clever, it’s a cursory glance. I’m not having a go; everything I’ve mentioned is merely observation. I install mongo on almost a daily basis because it’s a great product, I do however like having a balanced view and identifying any elephants in the room. I’d be interested in any feedback.
Reference: MongoDB Authentication from our JCG partner Jan Ettles at the Exceptionally exceptional exceptions blog.
