This topic created in 1933 days ago, the information mentioned may be changed or developed.
 |
1
Kirsk Jan 14, 2021 via Android  2
无脑拒绝阿里就没问题了
|
 |
2
wellsc Jan 14, 2021
kpi 产物
|
 |
3
EasyProgramming Jan 14, 2021
确实离谱
|
 |
4
LokiSharp Jan 14, 2021 4
这不是漏洞，这是自家的后门，是特性
|
 |
5
putaozhenhaochi Jan 14, 2021 via Android
话说 Nacos 阿里自己用吗
|
 |
6
mlhadoop Jan 14, 2021
https://github.com/alibaba/nacos/issues/273， 这些公司是不是要赶紧救火了？
|
 |
7
oxromantic Jan 14, 2021 3
离谱到在指出这个问题时(在项目里 hardcode 一个不是强制修改且不可修改 token)，开发还依然自以为是否定安全风险，安全经验少得可怜
|
 |
8
telung Jan 14, 2021
牛逼
|
 |
9
Finest Jan 14, 2021 2
|
 |
10
haosamax Jan 14, 2021
nacos 用的多吗，
|
 |
11
6IbA2bj5ip3tK49j Jan 14, 2021 4
前面那个 KomachiSion 简直离谱。
|
 |
12
janxin Jan 14, 2021
这是 feature
|
 |
13
MeteorCat Jan 14, 2021 via Android
直到出事了才知道肯承认是漏洞，真有你的
|
 |
14
xiangyuecn Jan 14, 2021
@xgfan #11 是不是也是看了想打人😂
|
 |
15
vone Jan 14, 2021
KomachiSion 是阿里的人吗，嘴硬的离谱 /doge 。
|
 |
16
lewis89 Jan 14, 2021 2
0202 年了 还有人用阿里的开源？ 谁用谁 SB
|
|
17
lewis89 Jan 14, 2021
另外微服务 只有傻逼才会开端口 把中间件的端口 暴露到公网上去
|
 |
18
Sum0l Jan 14, 2021
|
|
19
Sum0l Jan 14, 2021
已经修复了，自定义 user-agaent..
|
 |
20
guisheng Jan 14, 2021 1
「本来就不是给用户用的而是自己内部使用的机制，在使用文档上说明不妥。用户不知道才是正确的。」
|
 |
21
fibbery Jan 14, 2021
不过这玩意不都不暴露公网的吗，有这个必要吗?
|
 |
22
imn1 Jan 14, 2021
凡是“特殊”、“指定”才出现的，我基本认为是后门，因为这个是只能依靠“良心”计量的行为，🐶
|
 |
23
iceneet Jan 14, 2021 1
这是"feature"
|
 |
24
maskerTUI Jan 14, 2021
这后门简直离谱
|
 |
25
holdmycosmo Jan 14, 2021
真的有人把 nacos 暴露到公网出去么?是想随时随地用手机改配置啊
|
 |
26
dbpe Jan 14, 2021
这是 feature+1
|
 |
27
privil Jan 14, 2021
@worldtongfb #25 真的有。我擦，我醉了。
|
 |
28
xuanbg Jan 14, 2021
|
 |
29
expkzb Jan 14, 2021
乍一看以为是 macOS 打错字了，没想到是阿里的瓜
|
 |
30
nazor Jan 14, 2021
被之前的 fastjson 漏洞搞怕了，对待阿里的开源项目还是慎重吧。
|
|
31
xuanbg Jan 14, 2021
过滤器里面直接把那几个不需要鉴权的接口放白名单不好吗？
|
 |
32
murmur Jan 14, 2021
@worldtongfb 看了下 github 的交流记录，有人扫出了几十个暴露的，配合另外一个远程执行漏洞，好家伙
|
 |
33
PureWhiteWu OP 本来就不是给用户用的而是自己内部使用的机制，在使用文档上说明不妥。用户不知道才是正确的。
|
 |
34
swulling Jan 14, 2021 via iPhone 17
亲爱的黑客朋友们，如果你看到 Nacos 的这个安全漏洞，请不要惊慌。 这个漏洞纯属误报，只用于服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。请诸位黑客朋友遵守使用文档不要直接使用该漏洞哈。
另外我们已经拒绝了所有修复建议并标记 wantfix 。 |
 |
35
Aresxue Jan 14, 2021
正在用你敢信
|
 |
36
AA5DE3F034ACCB9E Jan 14, 2021
问题是态度还不行，没有为用户服务的心态，就想着自己的业务场景
|
 |
37
zengming00 Jan 14, 2021
真是荒唐可笑，有人记得 antd 的彩蛋事件吗？
|
 |
38
xeathen Jan 14, 2021
这个 komachi 嘴比铁还硬，还是 Apache Software Foundation 成员呢
|
 |
39
rapperx2 Jan 14, 2021
+1
|
 |
40
wsw Jan 14, 2021 1
 笑死我了 |
 |
41
GM Jan 14, 2021
@PureWhiteWu
用户不知道，但是想搞坏事的坏人知道，简直是完美的后门。 |
 |
42
Lax Jan 14, 2021
以前有个关于开源软件和闭源软件谁更安全的话题，一般认为在“代码功力一样的情况下，闭源软件比开源软件多个后门的可能性”。这下可好，开源软件也一样。到底是什么原因呢？
|
 |
43
YAR Jan 14, 2021
刚在生产环境搭完 nacos, 进来就看到这个......
|
 |
44
lxc404 Jan 14, 2021 3
随便拿钟馗之眼搜了台机器就试验成功了...这个漏洞真的太强了，之前把 nacos 账户密码改掉，要啥有啥
|
|
45
PureWhiteWu OP @YAR 哈哈哈哈哈哈，我不该发
|
 |
46
baobao1270 Jan 14, 2021
虽然说开源项目有免责条款
不过要是捅到网安部门就够各大企业喝一壶了吧 |
|
47
PureWhiteWu OP @baobao1270 不至于，网安才不会管这些事吧
|
|
48
baobao1270 Jan 14, 2021
@PureWhiteWu 不太清楚，但是之前不是什么护网吗，如果关键系统有漏洞还是会管的吧
|
 |
49
zifangsky Jan 14, 2021 2
好家伙，这两个漏洞一组合使用，黑客朋友第一时间就表示「阿里简直太贴心了」，顺便还给这个 feature 点个赞
|
 |
50
Visitor233 Jan 14, 2021
好家伙，本来用的好好的，居然被人捅出来了，黑帽子直接退出群聊
|
|
51
PureWhiteWu OP @Visitor233 都怪你们 23333
|
 |
52
KuroNekoFan Jan 14, 2021 via iPhone
回复有点开眼界了……
|
 |
53
scukmh Jan 14, 2021
都怪你们，用的好好地，捅出来干啥。（跑
|
 |
54
cs419 Jan 14, 2021
后门留的理直气壮
实在让人呸服 |
 |
55
Cat73 Jan 14, 2021 1
https://user-images.githubusercontent.com/9296576/104602646-97750f80-56b6-11eb-8ee8-7f030211f98b.png
配合知道创宇端口扫描效果极佳，果然无聊的人不止我一个，在我眼皮子底下这台服务器就中招了，多了个用户 知道创宇总共搜出来了 800 多台 Nacos 服务器，提前默哀 |
 |
56
zhleonix Jan 14, 2021
能这样设计的都不是正常人
|
 |
57
x66 Jan 14, 2021
好家伙，这个 issue 已经提出来半个月了，回复有点让我大吃一惊，建议以后阿里面试少问点什么原理，多问点安全相关的常识。
一句不应该把服务暴露到公网就完事了，那我想问下 nacos 为啥默认需要登陆呢？ |
 |
58
Jooooooooo Jan 14, 2021
一个后门是 feature
笑掉大牙 |
 |
59
hyqCrystal Jan 14, 2021
本来就不是给用户用的而是自己内部使用的机制，在使用文档上说明不妥。用户不知道才是正确的。
|
 |
60
waising Jan 14, 2021
楼上的回复看了一遍，不知道是真的没有用，还是真的不好用，那么大家都在用什么做注册中心和配置中心的
|
 |
61
nosilence Jan 15, 2021
@hyqCrystal #59 那性质就变成了特意留的后门
|
 |
62
so1n Jan 15, 2021 via Android
这个漏洞就算放在内网，有些员工也可以通过这个方法脱裤，很多小公司都是没审计的
|
 |
63
azh7138m Jan 15, 2021
看上去客户第一是不能得分了，希望能有人监督一下（）
|
|
64
azh7138m Jan 15, 2021
> I'm not sure whether the timing attack is send a long string to hold equals resource.
https://github.com/alibaba/nacos/pull/4683/files#r557138940 当场笑死 |
 |
65
sampeng Jan 15, 2021 via iPhone
我就拿他说的要服务间鉴权。看看别的产品怎么做的…他喵的另起一个端口啊。并且文档明确告知 a 端口对外，b 端口对内。
还嘴硬，不是说阿里内部大量使用么。内部员工脱个库玩玩 |
 |
66
mmdsun Jan 15, 2021 via Android
阿里出品必属于（）
|
 |
68
lovelive1024 Jan 15, 2021
“本来就不是给用户用的而是自己内部使用的机制，在使用文档上说明不妥。用户不知道才是正确的。”
真是有够搞笑的 |
 |
69
BrbiwsFtd9zDGZqB Jan 15, 2021 4
更有意思的是, 修复漏洞的 1.4.1 版本又出现了新的安全漏洞...
https://github.com/alibaba/nacos/issues/4701 |
 |
70
cutlove Jan 15, 2021
无内鬼，来点阿里笑话
|
 |
71
zpf124 Jan 15, 2021
@ily433664 "本来就不是给用户用的而是自己内部用来偷偷看看其他用户到底弄了些啥，在文档上说了的话你们就都给关了，我们还看啥。用户不知道才是正确的。"
|
 |
72
vipppppp Jan 15, 2021
试了一下，还真的是，阿里牛逼，还好我们的是内网的。。。
还有 naocs 的维护者的回复是真的牛皮 |
 |
73
gpg Jan 15, 2021
阿里开源真不敢用，一会儿爆一个 rec 。
|
 |
74
Yelp Jan 15, 2021
没办法的是，自家公司也会遇到，有些是真杠，有些是假杠
|
 |
75
chemzqm Jan 15, 2021
> 用户不知道才是正确的。
我只能说阿里真是人才辈出。你搞个黑盒完事了，还开源干嘛 |
 |
76
slyang5 Jan 15, 2021
这东西 暴露给公网干啥？ 感觉没什么问题吧
|
 |
78
AstroProfundis Jan 15, 2021
完全不熟悉开源社区的人来强行开源是这样的，要习惯 (doge)
|
 |
79
Roojay Jan 15, 2021
看了下 这个是被玩坏了😅
 |
 |
80
qjbcnrs Jan 15, 2021
@Roojay #79 好奇怪啊，我试了一下本地的和线上的，都不用加 ua，直接请求就能拿到
 |
|
81
Roojay Jan 15, 2021
@zhongjun96 #80 难道我被楼上钓鱼了🤡
|
 |
82
Jrue0011 Jan 15, 2021
@waising zookeeper cosul etcd，还有楼上说的携程的 apollo，甚至现在可能已经过时的 eureka，还是挺多的
不过我在小公司没搞过微服务所以都没用过，不评价哪个好。。。 |
|
83
PureWhiteWu OP @AstroProfundis 这已经和开源无关了吧……这种东西扔内网都过不了安全审计吧。。。
|
|
84
AstroProfundis Jan 15, 2021
@PureWhiteWu 我是说项目维护者对待这个漏洞报告的态度，至于漏洞本身能不能过审计是另外一个话题（
|
 |
85
chairuosen Jan 15, 2021
只能说业余，服务器互相调用就可以不鉴权了？
|
 |
87
spinecho Jan 15, 2021 via iPhone
@zhongjun96 你没开鉴权啊。
|
 |
88
no1xsyzy Jan 15, 2021 1
|
 |
90
Yanickkk Jan 15, 2021
吴老板你暴露了··
|
|
91
no1xsyzy Jan 15, 2021 1
@Lax 你还是重新看一下 Linus 定律原表达吧……
确切地说，不是 “后门的可能性”，而是 “后门不为人知的可能性”。 Kali 自带一大堆渗透用的开源后门呢…… 然而大家都很清楚，完全不会 surprise 。 “它是后门？那就对了！我这就把它传到那个有漏洞的服务器上…… 嘿嘿，现在它是我的了。” @baobao1270 免责条款无法免除法律明确指出不可被免责的部分。 实际上在国内免责条款效果比较弱。 |
 |
92
beyondex Jan 16, 2021
我看成 macOS
|
 |
93
sewer Mar 30, 2022
@AA5DE3F034ACCB9E 开源给你做外包？
|
Select Language