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
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
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
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
35. Authorization
• Specifies access rights to
resources and operations within
the database
• SQL’s Data Control Language
(DCL)
– GRANT, REVOKE
35 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
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
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
So what are the implications of Schema injection? Well for starters, there can be performance implications for the database. We can also do fun things like apply different data types to different keys in different rows. So our password in document #1 can be a string, while our password in document #2 could be an integer. Again, normally these constraints would be enforced by an application, but since they aren’t an attacker may be able to use this to their advantage, perhaps to bypass a login mechanism.To mitigate these attacks in a NoSQL environment we need to ensure that only valid keys are explicitly allowed into the database. Additional, unnecessary keys should be blocked or dropped. This is not an issue in the SQL world because the strongly typed table environment prevents any additional schemas from being added, and what benefit could you gain from creating extra, unused tables?And here’s the scary part, a lot of frameworks are already advocating or implementing code that simpy iterates over the post data. This is a Bad Idea™. From a penetration testers perspective, this is a gold mine.
10k passwords on a VM, in about 30 seconds.~ 1,000,000 passwords in a little under an hour