Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NoSQL - No Security?


Published on

Published in: Technology

NoSQL - No Security?

  1. 1. NoSQL – No Security?A way to lose even more stuffGavin Holt (@GavinHolt)
  2. 2. /meThird Year Ethical Hacking & Countermeasures StudentBusiness Systems Developer for a utilities company (Responsible for InternalWorkflow Application and building towards whole ERP)Background in Web Applications
  3. 3. What we will cover todayWhat is Big Data?What is NoSQL?Why NoSQL Security is an issueTraditional Database Attack VectorsNoSQL Attack VectorsSecuring NoSQL Installations
  4. 4. What is Big Data?Datasets that are so large or complex that they are difficultto process using traditional database processingapplications
  5. 5. 2.5 quintillion bytes (1 followed by 18 zeros) Data being generated every day (IBM)
  6. 6. 2.5 Petabytes (1048576 Gigabytes)The size of Walmarts transaction data (The Economist)
  7. 7. 40 Terabytes per second Data generated by experiments on the LHC at CERN (The Economist)
  8. 8. 72 Hours per Minute Video uploaded to YouTube (Google Inc.)
  9. 9. That is a lot of dataTrying running that lot in M$ Access!Data of this scale and complexity needs a different approach, different tools anddifferent storage mechanisms that create similar, but distinctly different problems fordevelopers.
  10. 10. What is NoSQL?“Not Only SQL”
  11. 11. What is NoSQL?Umbrella term for Database Management Systems that do not use the RelationalModelIdentifying NoSQL Systems: Generally don’t use tables Generally don’t use SQL for data manipulation Optimised for retrieves and appends Do very little other than record storage Highly scalable Focuses on huge quantities of data where a relational model isn’t required
  12. 12. Graph Data
  13. 13. Graph Data
  14. 14. Why use NoSQL?
  15. 15. Eventual ConsitancyThere is always going to be a delay when writingPerformance gains of NoSQL vs MySQL mean that it is favoured when consistency isimportant
  16. 16. User Updates Social NetworkSocial Network uses a load balancer
  17. 17. Writes don’t propagate immediatelyData is now inconsistent
  18. 18. Reading Stale DataUsers now being served old data from nodes that haven’t been updated
  19. 19. A more serious exampleData needs to be propagated quickly – NoSQL allows for thatDiagram from Adobe Security Labs
  20. 20. Why look at NoSQLSecurity?
  21. 21. NoSQL is Popular!ScalabilityRedundancyFlexibilityRapid Development / DeploymentCost
  22. 22. NoSQL holds a lot of stuffIf a data breach on *relatively* small database is bad, what is a breach on a Big Datadatabase?!Incorrectly configured and implemented – NoSQL is just a way to lose more data evenquicker than before!
  23. 23. NoSQL Solutions are easy to identifyProduct Default PortsMongoDB 27017 28017 27080CouchDB 5984Hbase 9000Neo4j 7474Riak 8098
  24. 24. Redis is designed to be accessed by NoSQL doesn’ttrusted clients inside trustedenvironments. This means that like the outsideusually it is not a good idea to world.expose the Redis instance directly • Redisto the internet or, in general, to anenvironment where untrustedclients can directly access the RedisTCP port or UNIX socket.In general, Redis is not optimizedfor maximum security but formaximum performance andsimplicity. (Redis Documentation)
  25. 25. The most effective way to reduce NoSQL doesn’trisk for MongoDB deployments isto run your entire MongoDB like the outsidedeployment in a trusted world.environment. (mongoDB • RedisDocumentation) • MongoDB
  26. 26. NoSQL isn’t fussy about who it talks to.“When you start out fresh, CouchDB allows any request to be made by anyone.Create a database? No problem, here you go. Delete some documents? Same deal.CouchDB calls this the Admin Party. Everybody has privileges to do anything. Neat.While it is incredibly easy to get started with CouchDB that way, it should be obviousthat putting a default installation into the wild is adventurous. Any rogue client couldcome along and delete a database.” (CouchDB Documentation)NB: Newer versions have began to only allow access from localhost upon installation
  27. 27. Relational DatabaseAttack Vectors
  28. 28. Relational Database Attack VectorsSoftware vulnerabilitiesCredential brute forcingAuthorization weaknessesInjection attacksPrivilege escalationInsecure configurations
  29. 29. SQL Injection: Basics
  30. 30. Basics of SQL InjectionSQL SELECT command has three basic parts SELECT – The Data you want FROM – Where you want it from WHERE – What selection criteria to useSELECT * FROM `users` WHERE `email` AND `password`=‘letmein’Attacker Submits Email: Password: X’ OR 1=1–SELECT * FROM `users` WHERE `email` AND `password`=‘X’ OR1=1–1 ALWAYS equals 1Logs user in
  31. 31. NoSQL VulnerabilitiesHow do these compare to traditional databases?
  32. 32. Authentication
  33. 33. AuthenticationNoSQL Weak authentication methods Weak password storage Password bruteforcing opportunitiesRelational Database Extensive authentication support Creds hashed with stored offline
  34. 34. Authentication – Source of the problemBoth CouchDB and mongoDB both have limited security by default.Does not scale well beyond the local security system
  35. 35. Weak authentication methodsHTTP/RESTful authentication HTTP BASIC or Cookie Based Vulnerable to replay and MITM Attacks Inherently insecure if SSL is not implemented or is compromised
  36. 36. Passwords
  37. 37. Weak Password StoragePasswords should NEVER be stored in plain text But they are: Redis, Some configurations of CouchDBPasswords should be hashed or encrypted (or both!) Password = MD5(“My Password”+salt)Access to password storage should be limited
  38. 38. Password Brute ForcingOnline password bruteforcing Redis’ AUTH commands are not rate limited or restricted in anyway An attacker can issue this command until the correct password is found
  39. 39. Injection
  40. 40. InjectionDatabase diversity is awesome for flexible linking to various applications It also gives us a tonne of attack surfaces Command-based queries CQL JSON BSON JavascriptInjection Attack Surfaces are increasing As well as traditional Query injection. We now have Schema and Javascript Injection
  41. 41. Schema InjectionUsed to override existing fields JSON Object QUERYLast keys take precedence over previous fields Allows attacker to overwrite protected attributes as POST is iterated on {"user":"gavin","admin":"False","password":"hacklab,"admin":"True""} When Processed {"user":"gavin","admin":"True","password":"hacklab"}Similar to HTTP Parameter Pollution
  42. 42. Schema Injection - MitigationsMySQL mitigates this using strongly typed tables and fieldsKey Enforcement Whitelist POST data that can be modified from any given page Blacklist application managed data “admin” can never by set via POSTManage your JSON When adding to objects, concatenate keys as opposed to the string of text
  43. 43. Query InjectionJSON (JavaScript Object Notation) The Good News: Most languages have implemented JSON safely as native objects The Bad News: Strings can still be used to inject into queries in poorly written applicationsLanguage Specific issues PHP Superglobals String to JSON Conversion
  44. 44. PHP SuperglobalsPHP Automagically converts superglobal values to multidimensional arraysHandy when dealing with web forms <input type=“text” name=“person[name]” /> Can be referenced as $_POST[‘person’][‘name’]PHP also uses arrays for MongoDB documents
  45. 45. PHP SuperglobalsThis means that an Attacker can insert MongoDB operations into the query byGETting or POSTing keys Forgot.php?[$ne]=1 Array( “email” => “”, “security_question” => array(“$ne”=>1) ); $ne = Not Equal.
  46. 46. Javascript Injection (SSJI)Browser Wars have given us incredibly fast and powerful JS engines But they are used for a lot more than just browsers Like…..NoSQL database engines
  47. 47. Javascript Injection (SSJI)Client Side JavaScript injection (More commonly XSS) is Number 2 on the OWASP TopTen Used to steal auth cookies Impersonate Users Create inline phishing sites Self Replicating wormsNasty StuffBut Server-side is MUCH worse
  48. 48. Javascript Injection (SSJI)$where clauses Built with user input Injected from manipulating querystringsEval clausesMap/Reduce (Compensates for a lack of Native SQL Functions)
  49. 49. Mitigating Injection AttacksUse safe strings / JSON Operators Escape Inputs Avoid concatenation when building queries User native JSON Objects where avalibleBe careful using GET & POST Variables Check for $operators Validate all Non-JSON StringsValidate Schemas before committing to DBIdentify and Sanitize JavaScript inputs Check for server-side JavaScript injection on IPS/WAF (It won’t hurt!)
  50. 50. Authorisation
  51. 51. AuthorisationMySQL – Fine Grained: SELECT UPDATE INSERT DELETENoSQL – Course Grained: READ WRITE
  52. 52. Encryption
  53. 53. EncryptionProtecting data at rest and in transit - MySQL In Transit SSL/TLS At Rest Integrated cryptographic functionally Ability to encrypt data in the database Easy access to hashing functionsNoSQL In Transit Some SSL Support At Rest Not a lot
  54. 54. Example of an Attack
  55. 55. CSFR can be used to bypass firewallsDiagram from Adobe Security Labs
  56. 56. CSFRNot particularly useful for stealing data <script> var xhr = new XMLHttpRequest();, http://nosql:5984/_all_dbs); xhr.send(); </script>Just as easy to make a user run the followingSame Origin policy won’t allow this
  57. 57. CSFR <form method=post action=http://nosql:5984/db> <input type=hidden name={"data"} value= /> </form> <script> // auto-submit the form </script>But it will allow this!Data stolen
  58. 58. POST is all an Attacker needs Inserting Data Inserting Script Data Execute any REST command from inside the firewall
  59. 59. Securing NoSQLOne does not simply secure NoSQL </meme>
  60. 60. Understand your solutionNo two NoSQL solutions are the same RTFMUnderstand the environment Most NoSQL solutions say they should only be operated in a “Trusted Enviroment” Define your trusted environment Understand what devices potentially have access to your NoSQL Server
  61. 61. Validate your inputsThe NoSQL attack surface is diverse Scheme, Query and JavaScript injection attacks affect different solutions differentlyUnderstand how these attacks affect your application and NoSQL EnviromentContinue to validate for traditional SQLi and XSS attacks, as well as NoSQLi and SSJIattacks
  62. 62. NoSQL – No Security?A way to lose even more stuffGavin Holt (@GavinHolt)