"NoSQL, no security?" AppSec USA 2012, Austin, Texas. Presented by Will Urbanski (@willurbanski)

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