The document discusses security concerns regarding NoSQL databases. It covers common attack vectors like injection attacks that can affect both relational and NoSQL databases. It then focuses on specific issues in securing NoSQL deployments, including weak authentication methods, insecure password storage, lack of authorization support, and lack of confidentiality measures. The document advocates approaches like input validation, access control, and encryption to help mitigate risks in NoSQL systems.

1. NoSQL, no security?
Will Urbanski
Vulnerability Management, Dell SecureWorks

2. What we will cover today
§ Why look at NoSQL security?
§ Relational Database attack vectors
§ NoSQL attack vectors
§ Securing NoSQL deployments
2 10/27/12

3. Why look at
NoSQL security?
3 10/27/12

4. NoSQL is popular
• Scalability
• Redundancy
• Flexibility
• Rapid development / deployment
• Cost
4 10/27/12

5. “Redis is designed to be accessed by trusted clients inside trusted
environments. This means that usually it is not a good idea to expose
the Redis instance directly to the internet or, in general, to an
environment where untrusted clients can directly access the Redis TCP
port or UNIX socket.” [redis.io]
5 10/27/12

6. “The most effective way to reduce risk for MongoDB deployments is to
run your entire MongoDB deployment, including all MongoDB
components in a trusted environment” [mongodb.org]
6 10/27/12

7. “When you start out fresh, CouchDB allows any request to be made by
anyone. [..] it should be obvious that putting a default installation into
the wild is adventurous. Any rogue client could come along and delete
a database.” [guide.couchdb.org]
7 10/27/12

8. 8 Confidential 10/27/12

9. 9 Confidential 10/27/12

10. Relational Databases (RDBMS)
• Relative Feature Parity
• Integrated Security Features
– Authorization
– Authentication
– Confidentiality
10 10/27/12

11. RDBMS Attack Surfaces
• Software vulnerabilities • Injection Attacks
• Credential brute forcing • Privilege escalation
– Offline storage
– Authentication protocols
• Authorization weaknesses • Insecure configurations
– MITM
– Replay attacks
11 10/27/12

12. Does NoSQL mean “No Security”?
12 10/27/12

13. Injection
13 10/27/12

14. Injection Attacks
• Database diversity is increasing
› Command-based queries
› CQL
› JSON
› BSON
› Javascript
› Custom query languages
• Injection attack surface is increasing
– Query injection
– Schema injection
– Javascript injection
• Attack complexity is increasing
14 10/27/12

15. Collections
Tables Collections
15 10/27/12

16. Schema Injection
• Allows an attacker to insert arbitrary key/value pairs into a document
– Attacker can also change the data type of a key
• Feasible when an application iterates POST values to create
documents
16 10/27/12

17. Schema Injection
• Schema injection can also be utilized to override existing fields.
– JSON object (replacement occurs in code)
– Query (replacement occurs on DB)
• Last key takes precedence over previous fields.
17 10/27/12

18. Schema Injection
• If non user-specified attributes are included before POST is iterated,
the client can inject or modify protected attributes.
• Think ‘HTTP Parameter Pollution’
18 10/27/12

19. Schema Injection Mitigation
• RDBs mitigate this through the use of strongly typed tables.
• Key enforcement
– Whitelist POST data values that can be added to the document
› ‘email’, ‘firstName’, ‘lastName’ should always be set via POST.
– Blacklist application-managed keys
› ‘is_admin’ can never be set via POST.
• Replace or concatenate
– When using native JSON objects, add application-managed keys after
adding user inputs.
– When using strings, always concatenate application-managed keys.
19 10/27/12

20. Query Injection
• There are safe and unsafe ways to build JSON queries.
• The good news is…
– Most languages that have implemented JSON-like dictionaries as native
objects implement them safely.
– dict = {‘email’: email ,’password’: password}
• The bad news is…
– Strings still exist and can be abused to inject into queries on poorly written
applications.
– dict= “{‘email’:’%s’,’password’:’%s’}” % (email,
password)
• Language-specific constructs can also be abused
– PHP’s superglobals
– String to JSON conversion
20 10/27/12

21. PHP’s Superglobals
• PHP automatically converts superglobal values to multidimensional
arrays
– $_POST – for working with HTTP POST data
– $_GET – for working with HTTP GET data
• This is very handy when working with web forms
– <input type=“text” name=“person[name]” value=“”>
– Can be referenced via $_POST[‘person’][‘name’]
• PHP also uses arrays to represent MongoDB documents
– $user = array(
‘email' => ‘will@localhost',
‘password' => ‘mmmfrenchtoast',
‘date_created' => ‘2012-06-15’
);
21 10/27/12

22. PHP’s Superglobals
• Adversaries can weaponize superglobals by inserting MongoDB
comparison operations in HTTP GET or POST keys
– forgot_password.php?
email=will@localhost&security_question[$ne]=1
– Array (
“email” => “will@localhost”,
“security_question” => array(“$ne” => 1)
);
• Kudos to Bryan Sullivan @ Adobe for identifying and reporting this
http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf
22 10/27/12

23. Javascript Injection (SSJI)
• Native Javascript support
– Supports Map/Reduce functionality
– Compensates for a lack of native SQL functions
› Batch processing of collections
› Aggregation
• Persistent or passed via client
• MongoDB and CouchDB application architectures
– db.eval()
– $where
– Temporary views
23 10/27/12

24. Mitigating Injection Attacks
• Use safe string / JSON operations
– Escape input
– Avoid string concatenation when building queries
– Use native JSON-like objects when available
• Be careful when utilizing GET and POST variables
– Check for use of $operators
– Validate strings do not contain JSON
• Validate document schemas before writing to the database
• Identify and sanitize Javascript in application inputs
– Check for server-side Javascript injection on IPS/WAF, if applicable
• Ensure your defense in depth strategy is looking for these attacks
24 10/27/12

25. Authentication
25 10/27/12

26. Authentication
• Authentication issues:
– Weak authentication methods
– Weak password storage methods
– Password bruteforcing opportunities
• RDBMS
– Rich authentication support
– Account credentials are hashed when stored offline
26 10/27/12

27. Local-only security model
• “When you start out fresh, CouchDB allows any request to be made
by anyone. [..] Everybody has privileges to do anything.
Neat.” [guide.couchdb.org]
• “If there are no admin users, one may access the database from the
localhost interface without authenticating.” [mongodb.org]
• Limited security by default
• Localhost only
• Rapid development
• Ease of use
• Growing pains
• Authentication methods don’t always effectively scale beyond localhost
27 10/27/12

28. Weak authentication methods
1. HTTP/RESTful authentication
2. Non-HTTP/RESTful authentication
28 10/27/12

29. HTTP/RESTful authentication
• HTTP BASIC, DIGEST or Cookie-based auth
• May require a reverse proxy server
– Vulnerable to replay and MITM attacks
– Insecure if SSL/TLS/encryption is not implemented or compromised
29 10/27/12

30. Non-HTTP/RESTful solutions
• Ideally would use a challenge-response authentication protocol
• Should be resistant to replay attacks
• Clear-text passwords should be avoided
30 10/27/12

31. Weak password storage methods
• Passwords should never be stored in the clear
– Redis, CouchDB (some cases)
• Passwords should be hashed or encrypted
– Preferably with a secure hashing algorithm
– MongoDB
› MD5(username + “:mongo:” + password)
– CouchDB
› Salt is a randomly generated 128-bit UUID
› PW = “-hashed-” + SHA1(password + salt) + “,” + salt
• Access to password storage should be limited
31 10/27/12

32. Password bruteforcing
• Online password bruteforcing
– Redis’ AUTH commands are not rate limited or restricted in any way
– An attacker could repeatedly issue the AUTH command until the correct
password was identified
32 10/27/12

33. Authentication
• Authentication schemes vary widely depending on the NoSQL
database being used
• Native authentication schemes are relatively weak
– Replay attacks
– Password bruteforcing
– Information leakage
• Pluggable authentication is generally not supported
33 10/27/12

34. Authorization
34 10/27/12

35. Authorization
• Specifies access rights to
resources and operations within
the database
• SQL’s Data Control Language
(DCL)
– GRANT, REVOKE
35 10/27/12

36. NoSQL Authorization
• Architecture dependent
• Per-database, not per-collection
• Generally course-grained
36 10/27/12

37. Each architecture is different
• No corollary for SQL’s DCL
• Common authorization features:
– ADMIN role
– Differentiation between Read and
Write
– Authorization not required until
enabled
37 10/27/12

38. Inventive Solutions
• Validation Functions
• Role-based Access Control
– User roles
– Security groups
• Command Renaming
– Authorization through obscurity
38 10/27/12

39. Confidentiality
39 10/27/12

40. Confidentiality
• Protect data at rest and in transit
• Confidentiality in transit
– SSL/TLS
– Mutually verifiable (key exchange)
• Confidentiality at rest
– Integrated cryptographic functionality
– Ability to encrypt data in the database
– Easy access to hashing functions
40 10/27/12

41. NoSQL Confidentiality
• In transit
– Some SSL support
– HTTP/REST-based solutions generally recommend use of HTTPS reverse
proxies
– Non-REST based solutions recommend the use of stunnel, VPNs, or a
transport-layer encryption technology
• At rest
• Third party applications exist to provide advanced authorization and
confidentiality functionality to existing databases
41 10/27/12

42. Securing NoSQL
42 10/27/12

43. Securing NoSQL
• Trusted operating environment
– Scoping
– Identifying ingress and egress
• Compliance Issues
– PCI
• Compensating Controls
– Architecture limitations
43 10/27/12

44. #1 Understand your solution
• No two NoSQL solutions are the
same
– Read the manual!
• Understand the environment
– Define “trusted environment”
– Understand ingress/egress
• Architecture
– Software
– Capabilities
– Controls
• Defense in Depth
44 10/27/12

45. #2 Beware architecture creep
• Additional architecture may be
required
• Increased TCO, deployment
times
• Identify these needs during
development
45 10/27/12

46. #3 Always Validate
• The NoSQL injection attack surface is diverse
– Schema, query, and javascript injection attacks affect architectures
differently.
• Understand how these attacks can affect your application and NoSQL
environment
• Continue to validate for traditional (SQLi, XSS) and non-traditional
injection (NoSQLi, SSJI) attacks.
46 10/27/12

47. #4 Work with Vendors
• Dynamic projects; quick release cycles
• If your NoSQL solution doesn't support the features you need, ask for
them.
• Several of the shortcomings we have discussed today are “on the
roadmap”
47 10/27/12

48. Thank you!
I value your
feedback
Twitter: @willurbanski
48 10/27/12

49. Picture Credits
• 14 – Red Bull
• 15 – Flickr.com / ActiveGuy98
• 22 – Flickr.com / John Kannenberg
• 22 – Flickr.com / Angelberries
• 34 – mysecuritysign.com
• 54 – Flickr.com / James Pullen
49 10/27/12