MongoDB Sharding and its Threats By: Anam Zahid MS(IT)-13

Agenda Sharding Components Sharding mechanics MongoDB Sharding Security Weaknesses Identified Threats

Main components Shard Config Server (meta data storage) Mongos A Shard is a node of the cluster Each Shard can be a single mongod or a replica set Config Server (meta data storage) Stores cluster chunk ranges and locations Can be only 1 or 3 (production must have 3) Not a replica set Mongos Acts as a router / balancer No local data (persists to config database) Can be 1 or many

Chunk is a section of the entire range Chunk Partitioning Chunk is a section of the entire range

Chunk is a section of the entire range Chunk splitting A chunk is split once it exceeds the maximum size There is no split point if all documents have the same shard key Chunk split is a logical operation (no data is moved) Once chunk size is reached, mongos asks mongod to split a chunk + internal function called splitVector() mongod counts number of documents on each side of split + based on avg. document size `db.stats()` Chunk split is a **logical** operation (no data has moved) Chunk is a section of the entire range

Balancing Balancer is running on mongos Once the difference in chunks between the most dense shard and the least dense shard is above the migration threshold, a balancing round starts

Acquiring the Balancer Lock The balancer on mongos takes out a “balancer lock” To see the status of these locks: use config db.locks.find({ _id: “balancer” }) Balancer lock actually held on config server.

Moving the chunk The mongos sends a moveChunk command to source shard The source shard then notifies destination shard Destination shard starts pulling documents from source shard

Committing Migration When complete, destination shard updates config server Provides new locations of the chunks

Cleanup Source shard deletes moved data Must wait for open cursors to either close or time out The mongos releases the balancer lock after old chunks are deleted

Sharding Mechanics

Sharding Security - Authentication Password Authentication or MongoDB-CR External Authentication PLAIN SASL (Simple Authentication and Security Layer) Kerberos Authentication using GSSAPI X.509 Certificate based authentication X.509 authentication for both user and intra-cluster authentication. 1 and 2 are supported in mongoDB enterprise only

MongoDB-CR Intra-Cluster authentication still use MongoDB-CR by using keyfile option Keyfile act as a shared password Same keyfile for all members of a cluster (including mongod and mongos) A Keyfile contains random characters in base64 set

SSL with X509 Certificate based Authentication The MONGODB-X509 mechanism authenticates a username derived from the distinguished subject name of the X.509 certificate presented by the driver during SSL negotiation. This authentication method requires the use of SSL connections with certificate validation and is available in MongoDB 2.5.1 and newer.

Kerberos Authentication 3. TCP:27017 Here is a Kerberos Service Ticket { user: ”username@EXAMPLE.COM", roles: ["readWrite"], userSource: "$external" } Key Distribution Center 1. I am “username@EXAMPLE.COM”, help me prove it to mongod (UDP:88) 2. Here is a Service Ticket Mongod 5. Welcome, here is Service 4. Keytab

PLAIN SASL(Simple Authentication and Security Layer) Proposed in RFC 4616 New in version 2.6. MongoDB Enterprise Edition versions 2.5.0 and newer support the SASL PLAIN authentication mechanism, initially intended for delegating authentication to an LDAP (Lightweight Directory Access Protocol) server. MongoDB Enterprise for Windows does not include LDAP support for authentication

Sharding Security - Authorization MongoDB System defined Access Control Roles read readWrite dbAdmin (clean, create, drop database etc) userAdmin (for a single database) readAnyDatabase readWriteAnyDatabase dbAdminAnyDatabase userAdminAnyDatabase (for all databases) clusterAdmin (no access to config. database but have only access to admin database) readWrite on config. database necessary for some sharding admin tasks (like stopping/starting the balancer), currently role based per database authorization UserAdmin – modify permissions and create new roles

Transmission Security SSL encryption (with CA validation) used for inter- server (between servers) data transmission security SSL (with CA validation) ensures that the hosts are who they say they are, but that’s separate from user authentication within MongoDB.

Data-at-rest Security 3rd Party Security Provider Gazzang’s ZnCrypt File system Encryption File System – All contents encrypted OS Gazzang Gazzang Key management

Security Weaknesses No Field level Access control No Strong internal security (e.g. MongoDB-CR is still used for intra-cluster authentication) No data integrity check Need application firewall for egress and ingress filtering of incoming connections within a sharded cluster Other Weaknesses No separate Audit log Database level locking support only Mongod audit logs only contains write operations with no mappings of these operations against user_id . This is because mongods are unaware of their data users in sharded environments. i-e rely on 3rd party tools for security (Gazzang Zncrypt)

Threats Malicious insider threat A malicious person injects its own shard in sharded cluster All Credentials for databases other than the admin database reside in the mongod instance that is the primary shard for that database. Readwrite access on config database is needed to add shards, once permitted a malicious user may access all collections in config database Man in the middle attack Can occur due to sending of plain data during transmission as SSL is not enabled by default in mongoDB. PLAIN SASL mechanism send passwords in PLAIN text format to the LDAP server Intra-cluster authentication still uses KeyFile and does not support Kerberos authentication

General Threats Additionally, Weak Auditing facilities in MongoDB may also cause Repudiation Attack Default Open ports e.g 28017, 27017 etc can cause Port scan attack Dos Attack Weak validation of input in MongoDB REST API can cause Cross Site Request Forgery (CSRF) Weak validation of input in PHP driver can results in NoSQL Injection Flaws in Rest API allows Stored Cross Side Scripting (XSS) Attack

References http://docs.mongodb.org/manual/core/inter-process-authentication/ http://api.mongodb.org/python/2.6.2/examples/authentication.html https://securosis.com/assets/library/reports/SecuringBigData_FINAL.pdf http://docs.mongodb.org/manual/reference/user-privileges/ http://www.slideshare.net/DefconRussia/firstov-attacking-mongo-db

THANKS!!!