Redis is an open source (BSD licensed), in-memory **data structure store**, used as a **database**, cache and message broker (from [here](https://redis.io/topics/introduction)). By default and commonly Redis uses a plain-text based protocol, but you have to keep in mind that it can also implement **ssl/tls**. Learn how to [run Redis with ssl/tls here](https://fossies.org/linux/redis/TLS.md).
Redis is a **text based protocol**, you can just **send the command in a socket** and the returned values will be readable. Also remember that Redis can run using **ssl/tls** (but this is very weird).
The **first command** you could try is **`info`**. It **may return output with information** of the Redis instance **or something** like the following is returned:
**By default** Redis can be accessed **without credentials**. However, it can be **configured** to support **only password, or username + password**.\
It is possible to **set a password** in _**redis.conf**_ file with the parameter `requirepass`**or temporary** until the service restarts connecting to it and running: `config set requirepass p@ss$12E45`.\
In cases like this one you will **need to find valid credentials** to interact with Redis so you could try to [**brute-force**](../brute-force.md#redis) **\*\*it.**\
**In case you found valid credentials you need to** authenticate the session\*\* after establishing the connection with the command:
**Valid credentials** will be responded with: `+OK`
### **Authenticated enumeration**
If the Redis instance is accepting **anonymous** connections or you found some **valid credentials**, you can **start enumerating** the service with the following commands:
**Other Redis commands** [**can be found here**](https://redis.io/topics/data-types-intro) **and** [**here**](https://lzone.de/cheat-sheet/Redis)**.**\
Note that the **Redis commands of an instance can be renamed** or removed in the _redis.conf_ file. For example this line will remove the command FLUSHDB:
More about configuring securely a Redis service here: [https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-redis-on-ubuntu-18-04](https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-redis-on-ubuntu-18-04)
You can also **monitor in real time the Redis commands** executed with the command **`monitor`** or get the top **25 slowest queries** with **`slowlog get 25`**
Inside Redis the **databases are numbers starting from 0**. You can find if anyone is used in the output of the command `info` inside the "Keyspace" chunk:
In that example the **database 0 and 1** are being used. **Database 0 contains 4 keys and database 1 contains 1**. By default Redis will use database 0. In order to dump for example database 1 you need to do:
In case you get the follwing error `-WRONGTYPE Operation against a key holding the wrong kind of value` while running `GET <KEY>` it's because the key may be something else than a string or an integer and requires a special operator to display it.
To know the type of the key, use the `TYPE` command, example below for list and hash keys.
**Dump the database with npm**[ **redis-dump**](https://www.npmjs.com/package/redis-dump) **or python** [**redis-utils**](https://pypi.org/project/redis-utils/)\*\*\*\*
Info from [**here**](https://web.archive.org/web/20191201022931/http://reverse-tcp.xyz/pentest/database/2017/02/09/Redis-Hacking-Tips.html). You must know the **path** of the **Web site folder**:
Please be aware **`config get dir`** result can be changed after other manually exploit commands. Suggest to run it first right after login into Redis. In the output of **`config get dir`** you could find the **home** of the **redis user** (usually _/var/lib/redis_ or _/home/redis/.ssh_), and knowing this you know where you can write the `authenticated_users` file to access via ssh **with the user redis**. If you know the home of other valid user where you have writable permissions you can also abuse it:
1. Following the instructions from [https://github.com/n0b0dyCN/RedisModules-ExecuteCommand](https://github.com/n0b0dyCN/RedisModules-ExecuteCommand) you can **compile a redis module to execute arbitrary commands**.
2. Then you need some way to **upload the compiled** module
3.**Load the uploaded module** at runtime with `MODULE LOAD /path/to/mymodule.so`
4.**List loaded modules** to check it was correctly loaded: `MODULE LIST`
[**Here**](https://www.agarri.fr/blog/archives/2014/09/11/trying\_to\_hack\_redis\_via\_http\_requests/index.html) you can see that Redis uses the command **EVAL** to execute **Lua code sandboxed**. In the linked post you can see **how to abuse it** using the **dofile** function, but [apparently](https://stackoverflow.com/questions/43502696/redis-cli-code-execution-using-eval) this isn't no longer possible. Anyway, if you can **bypass the Lua** sandbox you could **execute arbitrary** commas on the system. Also, from the same post you can see some **options to cause DoS**.
The master redis all operations are automatically synchronized to the slave redis, which means that we can regard the vulnerability redis as a slave redis, connected to the master redis which our own controlled, then we can enter the command to our own redis.
A master-slave connection will be established from the slave redis and the master redis:
redis-cli -h 10.85.0.52 -p 6379
slaveof 10.85.0.51 6379
Then you can login to the master redis to control the slave redis:
redis-cli -h 10.85.0.51 -p 6379
set mykey hello
set mykey2 helloworld
```
## SSRF talking to Redis
If you can send **clear text** request **to Redis**, you can **communicate with it** as Redis will read line by line the request and just respond with errors to the lines it doesn't understand:
Therefore, if you find a **SSRF vuln** in a website and you can **control** some **headers** (maybe with a CRLF vuln) or **POST parameters**, you will be able to send arbitrary commands to Redis.
In **Gitlab11.4.7** were discovered a **SSRF** vulnerability and a **CRLF**. The **SSRF** vulnerability was in the **import project from URL functionality** when creating a new project and allowed to access arbitrary IPs in the form \[0:0:0:0:0:ffff:127.0.0.1] (this will access 127.0.0.1), and the **CRLF** vuln was exploited just **adding %0D%0A** characters to the **URL**.
Therefore, it was possible to **abuse these vulnerabilities to talk to the Redis instance** that **manages queues** from **gitlab** and abuse those queues to **obtain code execution**. The Redis queue abuse payload is:
_For some reason (as for the author of_ [_https://liveoverflow.com/gitlab-11-4-7-remote-code-execution-real-world-ctf-2018/_](https://liveoverflow.com/gitlab-11-4-7-remote-code-execution-real-world-ctf-2018/) _where this info was took from) the exploitation worked with the `git` scheme and not with the `http` scheme._