NoSQL Exploitaiton Framework – Automating Squeezing Information out of Redis Servers

N.B : This is a series of blog posts i have planned to keep demoing out the features of the framework as well as some research i have done on NoSQL databases.

Introduction to Redis

Redis is NoSQL database, which stores everything in RAM as key/value pairs. By default, a text-oriented interface is reachable on port TCP/6379 without authentication. Redis is easy to abuse and hence has opened its way to a lot of vulnerabilities.

If you are looking for some path breaking research or stuff this is not the post, its just the automation stuff

Articles i would mention to Readup :

* http://www.agarri.fr/kom/archives/2014/09/11/trying_to_hack_redis_via_http_requests/
* http://benmmurphy.github.io/blog/2015/06/04/redis-eval-lua-sandbox-escape/
* http://www.slideshare.net/torque59/exploiting-nosql-like-never-before

More technical “know how” could be read on Redis at : http://redis.io

Squeezing Info Out/ Enumerating Redis Servers

In this blog post we look at how sensible information can be leaked out of Redis with help of the NoSQL Exploitation Framework.Lets get started,So Redis has this interesting API to list clients connected to it.
You might be thinking the importance of clients connected to the server, Actually it does mind,there might be the sites which have been connected to the Redis server instance fetching info,or as a matter of fact there might be other clients and as always said “Dig deep”.

While Pentesting an IP is worth a shot ,so the client details is accessible Using the “client list” command in Redis.
This feature has been added to the NoSQL Exploitation Framework and automatically lists you with available clients.

Basic Redis Enumeration using NoSQL Exploitation Framework

We will also look at File enumeration using the framework, Redis sandbox allows this feature to Open a named file and execute it’s contents as a Lua chunk , this is done using the dofile.
So what we could do is simple, we could enumerate the file space using the error message,
This feature can be abused to load Valid Linux Environment variables , which contain system info which in turn could lead to system enumeration

Here I have used a Redis-lab instance to demo out the Vulnerability.

Here you could see that , we were able to enumerate the OS version as well as the environment path, this was discussed earlier in my presentation at HITB 2014 later a blog post by Nicolas @agarri added more light to it :).

Redis DOS Vulnerability – The problem lies since Redis is single threaded , it does not allow you to run multiple scripts at a time , writing a infinite while loop could actually eat up the resources.

Exploitation – There was some great break through research done by Peter Cawley’s work with Lua bytecode type confusion and then followed by Ben Murphy http://benmmurphy.github.io/blog/2015/06/04/redis-eval-lua-sandbox-escape/

I have added a module within the framework to detect RCE based on article.


Comments

  1. Heya Francis!

    It is great to see that you’re actively developing your NoSQL Exploitation Framework – it’s an impressive and valuable tool which I’ve covered in Redis Watch #44 (https://redislabs.com/redis-watch-archive/44). The modules you’ve added are very valuable but I’d like to expand on the risk and mitigation for each exploit.

    I agree that that CLIENT LIST could be used to “dig deeper” as a stage in a more complex attack, but you can mitigate this simply by renaming the command if that is a concern. Furthermore, there’s an open Redis Change Proposal (https://github.com/redis/redis-rcp/blob/master/RCP1.md) that is designed to provide better authentication and ACL for controlling access to groups of commands. Given the above, this is considered low risk.

    Redis’ Lua dofile could indeed be present a risk although our engineers have put in extensive efforts in trying to develop an exploit for it without avail. That said and besides the possibility of someone finding a way to use that exploit, dofile’s inclusion in Redis’ sandbox is unwarranted since it serves no real value to Redis users. In the past I’ve proposed to remove it (see https://github.com/antirez/redis/pull/2271) and I believe it will be accepted.

    That said, the current upgrade to our Redis Cloud service (we’ve been pushing it gradually over the last several weeks) actually includes this very change, namely blocking dofile. A chance would have it, you experimentation above is likely to be last time anyone will be able to dofile on Redis Cloud 😉

    The Lua bytecode exploit is indeed (pontentially) serious business and the fixes have been provided almost immediately (https://redislabs.com/blog/cve-2015-4335-dsa-3279-redis-lua-sandbox-escape).

    The framework’s value is in exposing these exposed areas – the good news is that there are resolutions for all of these so if one of the modules executes successfully, you can plug that hole easily.

Leave a Reply

Your email address will not be published / Required fields are marked *