MongoDB Sharding and its Threats

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

2. Agenda • Sharding Components • Sharding mechanics • MongoDB Sharding Security • Weaknesses • Identified Threats

3. Main components • Shard • 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

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

5. Chunk splitting Chunk is a section of the entire range 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)

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

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

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

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

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

11. Sharding Mechanics

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

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

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

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

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

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

18. Transmission Security • SSL encryption (with CA validation) used for inter- server (between servers) data transmission security

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

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

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

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

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

24. THANKS!!!