Redis Exploitation Toolkit - A tool to pwn Redis server before the bad guys do!
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ RET | Redis Exploitation Toolkit v1.0
.-`` .-```. ```\/ _.,_ ''-._ by Shivam Bathla <@_shivambathla>
( ' , .-` | `, )
|`-._`-...-` __...-.``-._|'` _.-'|
| `-._ `._ / _.-' |
`-._ `-._ `-./ _.-' _.-' Because Redis is more than a database ;)
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
According to monthly DB-Engines rankings, Redis is often the most popular key-value database. The attack surface of Redis servers is only going to get bigger — a boon for the malicious actors! To help defend Redis Servers, I've developed Redis Exploitation Toolkit: a framework that helps you exploit Redis servers and find loopholes, before an adversary does.
Redis Exploitation Toolkit is a modular tool that finds flaws in remote or local Redis deployments and even tries to exploit some weaknesses, up to gaining code execution on the server. This tool performs a variety of attacks including:
- Enumeration Attacks (ACL, Auth, Keys, Misc)
- Command Execution Attacks (via Webshell, SSH, and Crontab techniques)
- Module Load (loads a Redis module giving you the ability to run arbitrary commands, obtain a reverse shell session and even launch a bind shell!)
Redis Exploitation Toolkit can be launched in automated mode to perform exploitation by itself and report all its findings to the user! This tool will be released with the standard MIT license and any contributions that can enhance this tool are welcome.
Installing this tool is quite easy.
Git clone:
You can clone the repo and pip install the requirements and you are ready to go!
$ git clone https://github.com/DeadlyHollows/Redis-Exploitation-Toolkit.git
$ cd Redis-Exploitation-Toolkit
$ python3 -m virtualenv env # Not mandatory but good to have. You must have virtualenv installed to run this.
$ . env/bin/activate # If you are use virtualenv, then you need to active it
$ pip3 install -r requirements.txt
Docker image:
The tool is also available as a docker image and can be downloaded as follows:
docker pull shivambathla/ret:redis-exploitation-toolkit
The available target Redis server images can be downloaded as follows:
docker pull shivambathla/ret:protected-mode
docker pull shivambathla/ret:no-protected-mode
That's it!
$ python3 ret.py --help 130 ⨯
usage: ret [-h] [-s REDIS_SERVER_HOSTNAME] [-p REDIS_SERVER_PORT] [-U REDIS_USER] [-P REDIS_USER_PASSWORD] [-q] [-y] [-seq ATTACK_SEQUENCE_FILE]
[-d INTER_ATTACK_DELAY] [-t EXEC_TIMEOUT] [-v] [-i | -r ATTACK_PATH | -a]
Redis Exploitation Toolkit
optional arguments:
-h, --help show this help message and exit
-s REDIS_SERVER_HOSTNAME, --host REDIS_SERVER_HOSTNAME
Redis Server Hostname/IP (default: 127.0.0.1)
-p REDIS_SERVER_PORT, --port REDIS_SERVER_PORT
Redis Server Port (default: 6379)
-U REDIS_USER, --user REDIS_USER
Redis User (default: 'default')
-P REDIS_USER_PASSWORD, --pass REDIS_USER_PASSWORD
Redis User Password (default: '')
-q, --quiet Do not show the tool banner
-y, --assume-defaults
Assume the default option for the answers requested by the tool (default: False)
-seq ATTACK_SEQUENCE_FILE, --attack-sequence-file ATTACK_SEQUENCE_FILE
For 'mode=auto', specify the file containing the sequence of attacks to be launched (default: './sequence.json')
-d INTER_ATTACK_DELAY, --delay INTER_ATTACK_DELAY
Delay (in seconds) between the attacks in auto mode (default: 0.3)
-t EXEC_TIMEOUT, --exec-timeout EXEC_TIMEOUT
Timeout (in seconds) for executed system commands (default: 60)
-v, --verbose Enable verbose mode (default: False)
-i, --interactive Run in interactive mode (default: False)
-r ATTACK_PATH, --run ATTACK_PATH
Launch specified attack [format: module/sub-module/attack] (example: 'rce/exec/ssh')
-a, --auto Run in automated mode (default: False)
This tool can operate under two modes:
By default, you get an interactive shell where you can enter the names of the attack modules and their sub-modules and execute the currently available attacks.
With the interactive module, you get a lot of fun stuff essentially for free! These include:
- An embedded shell to execute system commands,
- An embedded redis shell to execute commands on the remote Redis server,
- Help messages and information on all the attack modules,
- List of available modules, sub-modules and the commands in them,
- Ability to run individual attacks without having to go through all the other available attacks.
We support the following general commands (from the interactive shell ofcourse):
- back / up : To move one step up. This will help you exit out of the current attack module heirarchy upto specified levels so you can move on to next set of attacks.
- reset: To reset to the root module.
- shell / sh: Launchs the embedded shell.
- redis-shell / rsh: Launchs the embdedded redis-shell.
- list: List the set of available attack modules/submodules.
- help / info: Returns the help message. Depending on our position in the attack modules, different types of results could be obtained. But in general, this should be your goto command for getting help for a particular attack module/sub-module, technique and anything else as well! The
infocommand also returns the same results, that is, it gets info about an attack module/sub-module or the selected attack technique. - run / exploit: Once you are on the attack technique level, you would run this command to launch the selected attack.
You need to specify -a or --auto flag to start the tool in automated mode.
In this mode, all the attacks are launched one after the other. Currently the attack sequence is decided manually. All the attack modules are arranged in such a manner that the attacks to be executed first are placed above those that are to be executed later in the exploitation process.
All you need to do is answer some questions (typically yes/no) or supply the wordlist. If nothing is supplied, the default options are taken into consideration and thus you can supply a number of enter commands to run it in a fully automated fashion.
Now I know pressing enter a lot of times could be painful and that's where the --assume-defaults (or -y) flag comes into the picture! It takes away all that pain of pressing enter lot of times and selects the default options for you. In some rare cases, you might be asked a question, for instance the path to a Redis module - this is something we cannot guess for you at this stage.
In this mode, you can launch individual attacks, instead of launching all the attacks in one shot done in the automated mode. Use this mode when you want to launch a quick attack without dealing with the interactive mode.
Currently two attack modules are available:
- enum: To perform enumeration attacks including Keys enum, redis users enum (Auth), and ACL entries enum.
- rce: To perform attacks providing an RCE opportunity. It comes with two modules with various code execution techniques and ability to module a malicious Redis module.
Use this attack module to perform a variety of enumeration attacks.
Currently available enum attacks are:
Under this sub-module, we have the following ACL-related attacks currently available:
- retrieve_acl_entries: Retrieves the ACL entries from a connected Redis instance.
- crack_acl_password_hashes: Cracks the ACL password hashes retrieved from the ACL entries. JTR is used to perform the hash cracking.
- retrieve_acl_logs: Retrieves the ACL logs. This information is valuable for both Red- and Blue-teams! For instance, a Red-teamer can harvest usernames (helpful to perform
AUTHattacks) from these logs whereas a Blue teamer can find the bruteforce attempts for a user from these logs.
Under this sub-module, we have the following AUTH-related attacks currently available:
- auth_existence_check: Checks if the Redis server requires authentication or is open for anyone to connect.
- crack_weak_auth: Performs a dictionary attack against the Redis server.
Under this sub-module, we have the following KEYS-related attacks currently available:
- keys_enum: Performs key enumeration attack.
For the keys_enum attack, you can provide a KEYS_FILE file containing the wordlist path for the parts of the keys. This file can be set in the config/settings.py file as well.
Another important thing to note is the depth (or the levels parameter).
Here are some example keys and their depths are indicated in brackets:
products (1)
products:all (2)
products:mac:101 (3)
products:mac:charger:102 (4)
As the depth/levels increase, the time it takes to generate the keys increases as well and so does the resources required to compute that many keys. Thus it is advisable to use a lower number whenever possible.
3 seems to be a sane default and you should keep it in the range of 2-4. That would be sufficient enough to cover most (if not all) the keys.
One more thing to note is that it's not the depth but the keys file that would be more important. If the keys file doesn't contains the parts that exist in a Redis server, then tuning the level won't help. As simple as that.
Under this sub-module, we have the following miscellaneous attacks currently available:
- monitor_server_commands: This will run the
MONITORcommand and thus we will get all the commands sent to the Redis server from the instance this command is run.
Of importance is the fact that this blocks the client and moreover, this command takes up a lot of server resources. And therefore it is quite noisy!
Use this attack module to perform a variety of attacks resulting in a remote code execution opportunity.
Currently available attack submodules and associated techniques are:
Use this attack module to perform a variety of attacks resulting in command execution.
Currently available attack techniques are:
All of the attack techniques listed under exec require you to have the permissions to execute the following commands on the Redis Server:
- CONFIG SET
- CONFIG GET (not mandatory but good to have)
- SAVE
- FLUSHALL/FLUSHDB (not mandatory but good to have)
- SET
All of the attack techniques leverage the RDB (dump) file to implant the payload in the WEBROOT directory or .ssh/authorized_keys file or the crontabs directory.
Use this technique to gain command execution by saving a webshell payload in the WEBROOT directory.
This technique only works if:
- A webserver is running (an obvious requirement)
- You know (or can guess) the WEBROOT directory (that's easy but not always...)
- You have access to the commands specified under the
execmodule - You have permissions to write to the WEBROOT directory. If the payload cannot be saved (because of missing permissions), then the attack won't work...
Use this technique to gain command execution by saving attacker's SSH key in the .ssh/authorized_keys file of the user you wish to attack.
This technique only works if:
- SSH service is running (an obvious requirement)
- You know (or can guess) the path to the SSH directory of the user you wish to attack (that's easy but not always...)
- You have access to the commands specified under the
execmodule - You have permissions to write to the SSH directory of the victim user. If the SSH keys cannot be saved (because of missing permissions), then the attack won't work...
Use this technique to gain command execution by saving your payload the crontabs directory.
This technique only works if:
- Cron service is running (an obvious requirement)
- You know (or can guess) the path to the crontabs directory (that should be easy as there are only a handful of options...)
- You have access to the commands specified under the
execmodule - You have permissions to write to the crontabs directory. If the cron job cannot be saved (because of missing permissions), then the attack won't work...
- In addition to all this, the file permissions as well as the file format must be correct! In Debian-based distros, the crontab file is expected to be in proper format, else the file is not executed. And in this case, the dump file is bound to have some binary gibberish in it that corrupts the crontabs directory!
Use this attack module to perform attack to load a malicious Redis module.
Currently this module contains one attack technique:
This attack will load a malicious Redis module allowing you to:
- Execute arbitrary commands (
SYS.EXEC) - Obtain a reverse shell (
SYS.REVSHELL) - Start a bind shell (
SYS.BINDSHELL)
Use this attack when:
- You have a Redis module uploaded on the Redis server host
- The uploaded module has execute permissions
- Redis server (the privileges with which it is running) has permissions to access the uploaded module
An important point to note is that if a module with the same name already exists on the target Redis server, the current action is to unload that module and load the supplied module. Only reason being that if you are running this attack, then we assume that you wish to load the module (and it is not currently loaded or is updated). And for that reason, we unload the existing module and load the specified module.
With this tool, two targets have also been provided:
- Protected mode enabled: Could only be attacked by local users only.
- Protected mode disabled: Could be attacked by remote users as well.
1. Is this tool free to use?
Yes this tool is opensource and is available under the MIT license.
2. How frequently does it receives updates?
Currently I am keeping the tool up-to-date, pushing some features on a day-to-day basics. More features and modules are on the way.
3. Why are you releasing an exploitation tool?
My goal with this tool release is to give back to the security community a tool that can help secure their Redis deployments before malicious actors discover it and exploit for mining cryptocurrency!
4. Do I need to know about Redis to use this tool?
Knowing about Redis would definitely come in handy but that's not a must. You can still use the tool based on your "pentester instinct" and get pretty good results.
5. Are you planning to add features that facilitate in defending the Redis instances?
Yes indeed! I am definitely planning to add mitigation steps to facilitate in patching the Redis servers as well. Automated patching is not my plan though since it can break existing installations and can have other serious consequences too. So that's something I would like to stay away from. Redis folks already do a great job with a lot of secure defaults for you. Beyond that, suggestions is the best that I can do. Enforcing those should definitely be upto the Redis instance maintainers.