• Save
NoSQL, no security?
Upcoming SlideShare
Loading in...5
×
 

NoSQL, no security?

on

  • 4,198 views

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

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

Statistics

Views

Total Views
4,198
Views on SlideShare
4,001
Embed Views
197

Actions

Likes
7
Downloads
0
Comments
2

6 Embeds 197

http://data.story.lu 185
https://twitter.com 4
https://si0.twimg.com 3
http://www.bugsec.org 3
http://www.slashdocs.com 1
http://feedly.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • hie, i like this presentation very much and want to download it just for the academic purposes. is it possible that i could get a copy of this presentation ???
    Are you sure you want to
    Your message goes here
    Processing…
  • nice analysis.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

NoSQL, no security? NoSQL, no security? Presentation Transcript

  • NoSQL, no security?Will UrbanskiVulnerability Management, Dell SecureWorks
  • What we will cover today§ Why look at NoSQL security?§ Relational Database attack vectors§ NoSQL attack vectors§ Securing NoSQL deployments2 10/27/12
  • Why look at NoSQL security?3 10/27/12
  • NoSQL is popular•  Scalability•  Redundancy•  Flexibility•  Rapid development / deployment•  Cost4 10/27/12
  • “Redis is designed to be accessed by trusted clients inside trustedenvironments. This means that usually it is not a good idea to exposethe Redis instance directly to the internet or, in general, to anenvironment where untrusted clients can directly access the Redis TCPport or UNIX socket.” [redis.io]5 10/27/12
  • “The most effective way to reduce risk for MongoDB deployments is torun your entire MongoDB deployment, including all MongoDBcomponents in a trusted environment” [mongodb.org]6 10/27/12
  • “When you start out fresh, CouchDB allows any request to be made byanyone. [..] it should be obvious that putting a default installation intothe wild is adventurous. Any rogue client could come along and deletea database.” [guide.couchdb.org]7 10/27/12
  • 8 Confidential 10/27/12
  • 9 Confidential 10/27/12
  • Relational Databases (RDBMS)•  Relative Feature Parity•  Integrated Security Features –  Authorization –  Authentication –  Confidentiality10 10/27/12
  • RDBMS Attack Surfaces•  Software vulnerabilities •  Injection Attacks•  Credential brute forcing •  Privilege escalation –  Offline storage –  Authentication protocols•  Authorization weaknesses •  Insecure configurations –  MITM –  Replay attacks11 10/27/12
  • Does NoSQL mean “No Security”?12 10/27/12
  • Injection13 10/27/12
  • 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 increasing14 10/27/12
  • Collections Tables Collections15 10/27/12
  • 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 documents16 10/27/12
  • 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
  • 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
  • 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
  • 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 conversion20 10/27/12
  • 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
  • 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.pdf22 10/27/12
  • 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 views23 10/27/12
  • 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 attacks24 10/27/12
  • Authentication25 10/27/12
  • Authentication•  Authentication issues: –  Weak authentication methods –  Weak password storage methods –  Password bruteforcing opportunities•  RDBMS –  Rich authentication support –  Account credentials are hashed when stored offline26 10/27/12
  • 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 localhost27 10/27/12
  • Weak authentication methods1.  HTTP/RESTful authentication2.  Non-HTTP/RESTful authentication28 10/27/12
  • 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 compromised29 10/27/12
  • Non-HTTP/RESTful solutions•  Ideally would use a challenge-response authentication protocol•  Should be resistant to replay attacks•  Clear-text passwords should be avoided30 10/27/12
  • 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 limited31 10/27/12
  • 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 identified32 10/27/12
  • 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 supported33 10/27/12
  • Authorization34 10/27/12
  • Authorization•  Specifies access rights to resources and operations within the database•  SQL’s Data Control Language (DCL) –  GRANT, REVOKE35 10/27/12
  • NoSQL Authorization•  Architecture dependent•  Per-database, not per-collection•  Generally course-grained36 10/27/12
  • Each architecture is different•  No corollary for SQL’s DCL•  Common authorization features: –  ADMIN role –  Differentiation between Read and Write –  Authorization not required until enabled37 10/27/12
  • Inventive Solutions•  Validation Functions•  Role-based Access Control –  User roles –  Security groups•  Command Renaming –  Authorization through obscurity38 10/27/12
  • Confidentiality39 10/27/12
  • 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 functions40 10/27/12
  • 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 databases41 10/27/12
  • Securing NoSQL42 10/27/12
  • Securing NoSQL•  Trusted operating environment –  Scoping –  Identifying ingress and egress•  Compliance Issues –  PCI•  Compensating Controls –  Architecture limitations43 10/27/12
  • #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 Depth44 10/27/12
  • #2 Beware architecture creep•  Additional architecture may be required•  Increased TCO, deployment times•  Identify these needs during development45 10/27/12
  • #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
  • #4 Work with Vendors•  Dynamic projects; quick release cycles•  If your NoSQL solution doesnt support the features you need, ask for them.•  Several of the shortcomings we have discussed today are “on the roadmap”47 10/27/12
  • Thank you! I value your feedback Twitter: @willurbanski48 10/27/12
  • 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 Pullen49 10/27/12