事情围观: 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 权限。
经过对捕获的事件进行分析,整个入侵流程大概是包含以下几个环节:
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 哈哈。谢谢理解
|