Description
Redis is subject to unauthorized access because of improper configuration, which may be exploited by attackers.
Under certain conditions, if Redis runs with the root account, hackers can write an SSH public key file to the root account, directly logging on to the victim server through SSH. This may allow hackers to gain server privileges and delete or steal data, or even lead to an encryption extortion, critically endangering normal business services.
Once a Redis server is invaded, attackers may directly add an account for remote logon to control the server through SSH. This will impose security risks to users’ Redis environment and Linux hosts and lead to deletion or leakage of important data, or even extortion.
Affected versions
To check whether a client is subject to this vulnerability, try to log on to Redis on a client without an account:
root@kali:~# redis-cli -h 10.16.10.2
redis 10.16.10.2:6379> keys *
1) "1"`
From the result, this Redis service is open to the Internet and has not enabled authentication.
Fix
At network layer
Specify the NIC used by the Redis service
Redis listens to
127.0.0.1
by default. Make sure the listener is local if you only need local communications.Note: This approach can alleviate the risk to Redis to some extent. If an attacker has a webshell, and Redis runs with the root account, the attacker can still use the Redis to activate a reverse shell and achieve permission elevation.
Locate
# bind 127.0.0.1
in theredis.conf
file, uncomment it, and then save the changes.Note:
- After the change, only local machines can access Redis. However, you can also specify the IP addresses allowed to access Redis.
bind 192.168.1.100 10.0.0.1
- You must restart Redis for the settings to take effect.
- After the change, only local machines can access Redis. However, you can also specify the IP addresses allowed to access Redis.
Set the firewall policy
If the Redis service in a normal business needs to be accessed by other servers, you can set the iptables policy to only allow specified IP addresses to access the Redis service.
iptables -A INPUT -s x.x.x.x -p tcp --dport 6379 -j ACCEPT
Account and authentication
Set the access password
Locate the
requirepass
field in theredis.conf
file and enter a password at the end. The Redis client also needs this password to access the Redis service.For example, open
/etc/redis/redis.conf
and create the password!QE%^E3323BDWEwwwe1839
:requirepass !QE%^E3323BDWEwwwe1839
Make sure the password is complex enough. Restart the service after the configuration to bring the changes into effect.
Least privilege
Change the account running the Redis service
Run the Redis service with an account with only necessary permissions and disable the logon permission for this account.
The following command creates a general-permission account with no home directory and cannot be logged on to:
useradd -M -s /sbin/nologin [username]
Refine service authorization
Redis does not support permission separation. So, no difference is found between the administrator and general account. As a result, attackers may log on to the database and perform any operation.
Therefore, we recommend that you disable the following important commands:
FLUSHDB, FLUSHALL, KEYS,PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME,DEBUG and EVAL
.In addition, Redis 2.8.1 and Redis 3.x series (earlier than v3.0.2) may have an EVAL sandbox escape vulnerability that can be exploited to run any Lua code.
The following configuration sets
config/flushdb/flushall
to empty, that is, disables the command. You can also give the command a name that is hard for attackers to decrypt.rename-command CONFIG ""
rename-command flushall ""
rename-command flushdb ""
rename-command shutdown shotdown_test
Save the changes and run
/etc/init.d/redis-server restart
to restart the database.
Install security patches
Pay attention to the latest security patches and upgrade Redis to the latest version to prevent new vulnerabilities from being exploited.