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 and the returned values will be readable
```text
nc -vn 10.10.10.10 6379
info
[ ... Redis response with info ... ]
client list
[ ... Redis response with connected clients ... ]
CONFIG GET *
[ ... Get config ... ]
```
\*\*\*\*[**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 sadboxed**. In the linked post you can see **how to abuse it** using the **dotfile** 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**.
You can **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`
Several times redis will be configured to be **accessible anonymously**. In this case you won't need to use any username and password. Talk to redis service and **execute** the **`info`** command, it will let you know a **lot of information** about the server: SO running, Clients, memory...
Another **interesting command** to run is **`config get *`** this will let you know several **strings** related to the service and one of them could be the home of the redis user \(_/var/lib/redis,_ another possible path could be _/home/redis/.ssh_\), and knowing this you know where you can write the `authenticated_users` file.
You can also use `keys *` to list the keys and the `get <key>` to get them.
192.168.0.24:6379> get 351115ba5f690fb9b1bdc1b41e673a94 #This is a key list on the last command
```
**Other redis commands** [**can be found here**](https://redis.io/topics/data-types-intro) **and** [**here**](https://lzone.de/cheat-sheet/Redis)**.
Dump the database with**[ **redis-dump**](https://www.npmjs.com/package/redis-dump)\*\*\*\*
### **Automated Exploitation**
To exploit a **bad configured Redis** you should try: [https://github.com/Avinash-acid/Redis-Server-Exploit](https://github.com/Avinash-acid/Redis-Server-Exploit)
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:
```text
-ERR wrong number of arguments for 'get' command
-ERR unknown command 'Host:'
-ERR unknown command 'Accept:'
-ERR unknown command 'Accept-Encoding:'
-ERR unknown command 'Via:'
-ERR unknown command 'Cache-Control:'
-ERR unknown command 'Connection:'
```
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.
### Example: Gitlab SSRF + CRLF to Shell
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._