Swan(sea) Song – personal research during my six years at Swansea ... and bey...
NoSQL - No Security?
1. NoSQL – No Security?
A way to lose even more stuff
Gavin Holt (@GavinHolt)
2. /me
Third Year Ethical Hacking & Countermeasures Student
Business Systems Developer for a utilities company (Responsible for Internal
Workflow Application and building towards whole ERP)
Background in Web Applications
3. What we will cover today
What is Big Data?
What is NoSQL?
Why NoSQL Security is an issue
Traditional Database Attack Vectors
NoSQL Attack Vectors
Securing NoSQL Installations
4. What is Big Data?
Datasets that are so large or complex that they are difficult
to process using traditional database processing
applications
6. 2.5 Petabytes
(1048576 Gigabytes)
The size of Walmarts transaction
data (The Economist)
7. 40 Terabytes per second
Data generated by experiments
on the LHC at CERN
(The Economist)
8. 72 Hours per Minute
Video uploaded to YouTube
(Google Inc.)
9. That is a lot of data
Trying running that lot in M$ Access!
Data of this scale and complexity needs a different approach, different tools and
different storage mechanisms that create similar, but distinctly different problems for
developers.
11. What is NoSQL?
Umbrella term for Database Management Systems that do not use the Relational
Model
Identifying 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
15. Eventual Consitancy
There is always going to be a delay when writing
Performance gains of NoSQL vs MySQL mean that it is favoured when consistency is
important
22. NoSQL holds a lot of stuff
If a data breach on *relatively* small database is bad, what is a breach on a Big Data
database?!
Incorrectly configured and implemented – NoSQL is just a way to lose more data even
quicker than before!
24. Redis is designed to be accessed by NoSQL doesn’t
trusted clients inside trusted
environments. This means that like the outside
usually it is not a good idea to world.
expose the Redis instance directly
• Redis
to the internet or, in general, to an
environment where untrusted
clients can directly access the Redis
TCP port or UNIX socket.
In general, Redis is not optimized
for maximum security but for
maximum performance and
simplicity. (Redis Documentation)
25. The most effective way to reduce NoSQL doesn’t
risk for MongoDB deployments is
to run your entire MongoDB like the outside
deployment in a trusted world.
environment. (mongoDB • Redis
Documentation) • MongoDB
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 obvious
that putting a default installation into the wild is adventurous. Any rogue client could
come along and delete a database.” (CouchDB Documentation)
NB: Newer versions have began to only allow access from localhost upon installation
30. Basics of SQL Injection
SQL SELECT command has three basic parts
SELECT – The Data you want
FROM – Where you want it from
WHERE – What selection criteria to use
SELECT * FROM `users` WHERE `email`=gavin@pwned.org AND `password`=‘letmein’
Attacker Submits
Email: gavin@pwned.org
Password: X’ OR 1=1–
SELECT * FROM `users` WHERE `email`=gavin@pwned.org AND `password`=‘X’ OR
1=1–
1 ALWAYS equals 1
Logs user in
34. Authentication – Source of the problem
Both CouchDB and mongoDB both have limited security by default.
Does not scale well beyond the local security system
35. Weak authentication methods
HTTP/RESTful authentication
HTTP BASIC or Cookie Based
Vulnerable to replay and MITM Attacks
Inherently insecure if SSL is not implemented or is compromised
37. Weak Password Storage
Passwords should NEVER be stored in plain text
But they are:
Redis, Some configurations of CouchDB
Passwords should be hashed or encrypted (or both!)
Password = MD5(“My Password”+salt)
Access to password storage should be limited
38. Password Brute Forcing
Online 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
40. Injection
Database diversity is awesome for flexible linking to various applications
It also gives us a tonne of attack surfaces
Command-based queries
CQL
JSON
BSON
Javascript
Injection Attack Surfaces are increasing
As well as traditional Query injection. We now have Schema and Javascript Injection
41. Schema Injection
Used to override existing fields
JSON Object
QUERY
Last 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. Schema Injection - Mitigations
MySQL mitigates this using strongly typed tables and fields
Key Enforcement
Whitelist POST data that can be modified from any given page
Blacklist application managed data
“admin” can never by set via POST
Manage your JSON
When adding to objects, concatenate keys as opposed to the string of text
43. Query Injection
JSON (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 applications
Language Specific issues
PHP Superglobals
String to JSON Conversion
44. PHP Superglobals
PHP Automagically converts superglobal values to multidimensional arrays
Handy 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. PHP Superglobals
This means that an Attacker can insert MongoDB operations into the query by
GETting or POSTing keys
Forgot.php?email=gavin@pwned.org&security_questions[$ne]=1
Array(
“email” => “gavin@pwned.org”,
“security_question” => array(“$ne”=>1)
);
$ne = Not Equal.
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. Javascript Injection (SSJI)
Client Side JavaScript injection (More commonly XSS) is Number 2 on the OWASP Top
Ten
Used to steal auth cookies
Impersonate Users
Create inline phishing sites
Self Replicating worms
Nasty Stuff
But Server-side is MUCH worse
48. Javascript Injection (SSJI)
$where clauses
Built with user input
Injected from manipulating querystrings
Eval clauses
Map/Reduce (Compensates for a lack of Native SQL Functions)
49. Mitigating Injection Attacks
Use safe strings / JSON Operators
Escape Inputs
Avoid concatenation when building queries
User native JSON Objects where avalible
Be careful using GET & POST Variables
Check for $operators
Validate all Non-JSON Strings
Validate Schemas before committing to DB
Identify and Sanitize JavaScript inputs
Check for server-side JavaScript injection on IPS/WAF (It won’t hurt!)
53. Encryption
Protecting 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 functions
NoSQL
In Transit
Some SSL Support
At Rest
Not a lot
55. CSFR can be used to bypass firewalls
Diagram from Adobe Security Labs
56. CSFR
Not particularly useful for stealing data
<script>
var xhr = new XMLHttpRequest();
xhr.open('get', 'http://nosql:5984/_all_dbs');
xhr.send();
</script>
Just as easy to make a user run the following
Same Origin policy won’t allow this
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. POST is all an Attacker needs
Inserting Data
Inserting Script Data
Execute any REST command from inside the firewall
60. Understand your solution
No two NoSQL solutions are the same
RTFM
Understand 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. Validate your inputs
The NoSQL attack surface is diverse
Scheme, Query and JavaScript injection attacks affect different solutions differently
Understand how these attacks affect your application and NoSQL Enviroment
Continue to validate for traditional SQLi and XSS attacks, as well as NoSQLi and SSJI
attacks
62. NoSQL – No Security?
A way to lose even more stuff
Gavin Holt (@GavinHolt)
