我是 printf520 提供今日热榜 API 的博主， Redis 感染了自动化挖矿蠕虫。目前已经修复
timeromantic · 2019-07-19 12:16:56 +08:00 · 8887 次点击这是一个创建于 1955 天前的主题，其中的信息可能已经有所发展或是发生改变。
首先谢谢发帖告知我 API 感染挖矿病毒的 V 友。 @zpfhbyx
事情围观： https://www.v2ex.com/t/584216#reply23
api 文档： https://www.v2ex.com/t/578957#reply6
目前已经做了修复处理
感染原因如下：
Redis 默认情况下，会绑定在 0.0.0.0:6379，在没有利用防火墙进行屏蔽的情况下，将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下利用 Redis 的相关方法，可以成功将自己的公钥写入目标服务器的 ~/.ssh 文件夹的 authotrized_keys 文件中，进而可以直接登录目标服务器；如果 Redis 服务是以 root 权限启动，可以利用该问题直接获得服务器 root 权限。
经过对捕获的事件进行分析，整个入侵流程大概是包含以下几个环节：
- 扫描开放 6379 端口的 Linux 服务器（后续感染扫描网段为 1.0.0.0/16 到 224.255.0.0/16 ）
- 通过 redis-cli 尝试连接 Redis 并执行预置在.dat 文件里的利用命令将 Redis 的数据文件修改为 /var/spool/cron/root，然后通过在 Redis 中插入数据，将下载执行脚本的动作写入 crontab 任务
- 通过脚本实现以上的相关行为，完成植入并启动挖矿程序
Redis 服务加固
- 导致入侵的主要原因是 Redis 未授权访问问题，所以如果要扼制入侵的入口，需要针对 Redis 服务进行加固，避免黑客通过该途径进行入侵植入挖矿蠕虫。
- 如无必要，修改 bind 项，不要将 Redis 绑定在 0.0.0.0 上，避免 Redis 服务开放在外网，可以通过 iptables 或者腾讯云用户可以通过安全组限制访问来源
- 在不影响业务的情况，不要以 root 启动 Redis 服务，同时建议修改默认的 6379 端口，大部分针对 Redis 未授权问题的入侵都是针对默认端口进行的
- 配置 AUTH，增加密码校验，这样即使开放在公网上，如果非弱口令的情况，黑客也无法访问 Redis 服务进行相关操作
- 使用 rename-command CONFIG "RENAME_CONFIG"重命名相关命令，这样黑客即使在连接上未授权问题的 Redis 服务，在不知道命令的情况下只能获取相关数据，而无法进一步利用
第 1 条附言 · 2019-07-19 20:45:24 +08:00
统一解释一下
调用我的 API 的 V 友们，我这里返回的 sort 值对于 JavaScript 来说，只是一个 json 的 string，对你们来说无任何影响。
调用我的 API 的 V 友们，我这里返回的 sort 值对于 JavaScript 来说，只是一个 json 的 string，对你们来说无任何影响。
 |
1
timeromantic OP @zpfhbyx 谢谢告知
|
 |
2
ResetTrap 2019-07-19 12:57:25 +08:00  4
redis 不是默认 127.0.0.1:6379 吗
|
 |
3
cmlanche 2019-07-19 13:00:24 +08:00
我的站的 redis 也被入侵了，开防火墙，重启下服务器就好了
|
 |
4
IsaacYoung 2019-07-19 13:05:34 +08:00 via iPhone
🐂🍺
|
 |
5
shmilypeter 2019-07-19 13:06:25 +08:00
谢谢告知，我打算好好研究下你的项目
|
|
6
timeromantic OP @cmlanche 嗯，是的，已经做了相关的处理
|
|
7
timeromantic OP @ResetTrap 127.0.0.1 只是你本地地址
|
 |
8
laoyur 2019-07-19 13:09:16 +08:00 2
redis 漏洞都爆出多久了
|
 |
9
nihaoaa 2019-07-19 13:10:04 +08:00
学到了
|
|
10
ResetTrap 2019-07-19 13:13:12 +08:00 1
@timeromantic #7 与此无关，redis 的默认配置是监听 127.0.0.1，除了本机是不能连接的，你肯定是把配置文件改成 0.0.0.0 了
|
 |
11
1iuh 2019-07-19 13:18:04 +08:00
什么时候被入侵，持续时间多久，期间 API 被调用多少次不披露一下么？
|
 |
12
chenqh 2019-07-19 13:20:25 +08:00
这种端口默认不是不开启的吗，在安全组那里
|
|
13
timeromantic OP @1iuh 昨天下午入侵的，持续时间为零，redis 跑在 docker 没有影响到主机
|
|
14
1iuh 2019-07-19 13:22:30 +08:00
另外，为什么你服务器被挂的挖矿程序会影响你 API 的返回数据？
 |
|
15
timeromantic OP api 返回的 sort 值是 redis 存的知乎点击量，病毒是把知乎的 key 设置成他的挖矿脚本了。我获取 sort 就带出来了
|
|
16
timeromantic OP @1iuh api 返回的 sort 值是 redis 存的知乎点击量，病毒是把知乎的 key 设置成他的挖矿脚本了。我获取 sort 就带出来了
|
 |
17
RicardoY 2019-07-19 13:27:28 +08:00
redis 默认情况下绑在 127.0.0.1 的呀
|
|
18
timeromantic OP |
|
19
ResetTrap 2019-07-19 13:29:51 +08:00
@timeromantic #18 那就是你操作问题了，相当于 0.0.0.0 了，这种方式很不推荐的
|
|
20
timeromantic OP |
 |
21
wh1012023498 2019-07-19 13:32:21 +08:00
= = 这个 redis 安全问题。。不是早就暴露了吗。。
|
 |
22
kzfile 2019-07-19 13:33:00 +08:00
我的也入侵了,结果因为是 windows 系统,挖矿脚本没跑起来
|
|
23
1iuh 2019-07-19 13:34:10 +08:00
据我所知，利用 redis 未授权漏洞是需要 flushall 的， 而且我想不到为什么还能只替换你知乎的 key。依据的你的描述来看，只是被脚本扫到了， 不是针对你的攻击。
另外你说持续时间为 0 这个我也无法认同，都有 V 友调用你接口发现问题了，怎么会持续时间为 0。 |
|
24
timeromantic OP @1iuh 我说的持续时间为零是指的。他的脚本并未成功在我服务器上面挖矿，跑在 docker 容器。不过入侵我的 redis 倒是有一段时间。调用我 api 的朋友是不受影响的
|
|
25
timeromantic OP @wh1012023498 老哥，又见到了你了，因为头像记得你
|
 |
26
zpfhbyx 2019-07-19 13:57:30 +08:00
 |
 |
27
ScepterZ 2019-07-19 14:20:15 +08:00
解决方法呢，有办法不让 docker 绑定 0.0.0.0 吗
|
|
29
ScepterZ 2019-07-19 14:23:16 +08:00
查了一下，docker run -p 127.0.0.1:6379:6379 就行了
|
 |
30
fuxkcsdn 2019-07-19 16:34:43 +08:00
容器运行默认都只绑定在 127.0.0.1 上
除非你启动容器时用 -P 或者 -p 6379:6379 根据你的描述应该是后者 |
|
31
fuxkcsdn 2019-07-19 16:35:49 +08:00
上面打错了
-p 6379:6379 也只会绑定在 127.0.0.1 上，应该是 -p 0.0.0.0:6379:6379 |
 |
32
x66 2019-07-19 16:42:37 +08:00
不懂就问：
1. 为什么是 cur ？而不是 curl ？ 2. 什么情况下请求者会受到这个 json 中的命令攻击？ |
 |
33
bin20060407 2019-07-19 16:45:50 +08:00
Redis 表示这锅我不背，默认是绑在 127.0.0.1 的
|
 |
34
mangoDB 2019-07-19 19:14:22 +08:00
借楼学习一下，那个挖矿脚本如何会被触发呢？
难道需要好奇心比较重的用户，手动执行吗？ |
 |
35
cuixiao603 2019-07-19 20:22:19 +08:00
同好奇如何触发
|
 |
36
Trim21 2019-07-19 20:27:34 +08:00 via Android
为啥这个 sort 会让 Redis 被入侵，有没有大佬解释一下…
|
 |
37
scnace 2019-07-19 20:51:28 +08:00 via Android
@cuixiao603 @mangoDB 触发应该是通过把 redis 的 dir 和 dbnamefile 指向 /etc/crontab 然后把这个 value 写入到 crontab 里面（但是好像 curl 拼错了？
LZ 能看下自己的 crontab 列表确认下吗？难道是写完之后又改回去了？ |
 |
39
sampeng 2019-07-19 23:35:49 +08:00 via iPhone
这个史前时代的问题…你居然把 redis 扔公网上。佩服佩服…
|
 |
40
JasperWong 2019-07-20 00:32:19 +08:00
我也中过这个
|
 |
41
Hopetree 2019-07-20 00:53:44 +08:00
我服务器的端口连 MySQL 的都不开，redis 的更不开，要用的时候可以开一下用一下，感觉挺方便啊
|
 |
43
Kinnice 2019-07-20 01:28:52 +08:00 via Android
@1iuh 调用他 API 的用户应该在 json 解析那一步就会报错了，应该影响不到安全问题，好奇心手动执行除外。
|
 |
45
imycc 2019-07-20 05:05:48 +08:00
@fuxkcsdn
-p 6379:6379 是将容器的 6379 映射到主机上 容器本身是监听了容器自己的 127.0.0.1 的（假设，我没注意过），但是映射到主机上时如果没有指定 host ip，就相当于在主机外网的 6379 端口上开了个 redis 服务。 |
|
46
imycc 2019-07-20 05:08:44 +08:00 1
使用 docker 或者使用 docker-compose，`-p`跟`--ports`如果没有必要就不要随便用~
只暴露那些需要外部访问的即可，同个机器上的调用可以用 link 来做。 如果需要暴露端口，有机房内网的话最好只是开在内网上。开到外网的话注意加上白名单。 |
 |
47
bghtyu 2019-07-20 08:46:49 +08:00 via Android 1
docker 的 -p 如果直接 6379:6379 是会默认绑定 0.0.0.0 的，而且还会自动打开防火墙的这个端口，不注意很容易被坑的，必须要-p 127.0.0.0:6379:6379 这样用才行
|
 |
48
tailf 2019-07-20 10:14:01 +08:00
这不是 redis 漏洞，是楼主不会做运维
|
|
50
timeromantic OP @tailf 哈哈，开发还是要多掌握一点运维的知识
|
 |
51
opengps 2019-07-20 18:55:55 +08:00
开发人员很多都不懂安全防御，不具备运维能力。
楼主能分析故障复盘原理已经是大佬了，能公开分析过程的更值得佩服，留名点赞！ |
|
52
timeromantic OP @opengps 哈哈。谢谢理解
|
Select Language