Unauthorized access to Redis results in remote access to server Permissions
Recently, the Rubik's Cube security team has detected a new type of attacks against unauthorized access to Redis. In specific conditions, remote attacks can cause server crashes, the Rubik's Cube security team promptly researched and evaluated the attack method, and notified some users to fix it through the cube matrix intelligence system. The following describes how the vulnerability works and how it is reproduced.
Vulnerability principle and recurrence
Before reproduction, we will first introduce two basic knowledge:
1) SSH password-free logon. in Linux, you can set SSH password-free logon by using the "Public/Private Key" authentication. That is, you must first create a pair of public/private keys on the client (Public Key File :~ /. Ssh/id_rsa.pub; private key file :~ /. Ssh/id_rsa ). Then put the public key on the server (~ /. Ssh/authorized_keys) and keep the private key. when using ssh to log on, the ssh program will send a private key to match the public key on the server. if the match is successful, you can log on.
2) Redis can be remotely managed through Redis-CLI to set the default path of Redis and database cache files.
The method is as follows:
Config set dir/xxx
Config set dbfilename xxxx
Set xxxx "xxx"
Save
These two common O & M methods are combined under the following conditions:
1. Start Redis with the ROOT account
2. No Password Authentication for Redis service or Weak Password Authentication
3. The server opens the SSH service and allows you to log on with a key. You can remotely write a public key and directly log on to the remote server.
For example:
First, generate a key pair locally:
Connect to the target redis server remotely through redis-clis and execute the following command
Config set dir/root/. ssh/
Config set dbfilename authorized_keys
Set xxxx "\ n \ nssh-rsa key_pub \ n", where key_pub is the generated public key, you can save the public key on the remote server, therefore, you do not need to enter the account and password during logon.
At present, the Rubik's Cube security team has detected that some customers' Redis has been intruded by this vulnerability, and the written public key is found in their cache database. It is recommended that you check the internal network immediately.
Vulnerability repair
The vulnerability can be fixed as follows:
1) do not use the root permission to start the redis service;
2) Enable Password Authentication for redis access and add IP address access restrictions;
3) Try not to open the SSH service directly to the public network.