登陆 注册

企业安全实战:看快手如何干掉Fastjson

Guy_Psycho 2020-08-13 安全快讯漏洞事件

从2017年1月份到现在,Fastjson已出现三次无任何条件限制的远程代码执行漏洞。   


文/廖新喜

Fastjson 漏洞史

Fastjson是一个阿里巴巴开发的java高性能JSON库,应用范围非常广,在github上star数已经超过2.2万。从2017年1月份到现在,Fastjson 已出现三次无任何条件限制的远程代码执行(RCE)漏洞,在其中两次版本更新中,Fastjson官方在知情的情况下从未披露其更新涉及到漏洞,导致这些漏洞以0day在野,有的长达一年之久。另外其涉及到远程代码执行漏洞更新已有10多次,小编也做过好几次贡献,业内苦Fastjson 久已。下图是一个四哥给的调侃:

四哥给的调侃真的只是调侃吗?下面我们来具体看下Fastjson的更新历史:

画红框框的都修复了无任何限制的RCE漏洞,并且前两次中都没提到一个漏洞字眼,可想而知,根本就没把漏洞当做一回事,更谈不上CVE等漏洞管理跟踪措施。

快手Fastjson应急那些事

Fastjson使用非常广泛,在各大互联网公司各大框架中都有涉及。在 2019 年,快手因为 Fastjson 发起两次应急响应,分别是针对Fastjson-1.2.48版本的漏洞应急和Fastjson-1.2.60版本的漏洞应急。

在第一次应急中,由于该漏洞是无任何限制的RCE 0day,我们验证完PoC之后,就推动主站自查,在24小时内完成了升级。漏洞很严重,当时内部有些研发可能感知没那么清楚,为了产生更大的威慑力,我们在某个业务站点getshell,截了几张大大的getshell图丢到大群里,大家的动作立马快速了很多。主站主要靠人找服务就完成了升级,但是其他业务去找到所有存量还是有一定挑战的。下面是我们当时做的一些事情:

1.扫描器构造PoC发动扫描,安全组编写了Fastjson的扫描插件,对公司所有站点发起了扫描,还真发现一个漏洞。

2.利用快手代码搜索平台搜索代码仓库,当时还没有第三方库平台,惭愧。

3.从制品库搜索,解压了所有jar包,搜索相应代码,找出相应责任人。

第二次应急是针对Fastjson-1.2.60版本的,有了第一次的经验,从容了一些,搞定PoC,快速推动业务升级即可。

在2020年5 月末 Fastjson 又出 超级RCE 0day,各个安全团队都是焦头烂额,快手安全组从容了很多,我们只剩下个位数仓库受影响。

形成替代方案

在Fastjson -1.2.48和Fastjson -1.2.60版本漏洞的应急中,我们一直在反思,是不是得干掉Fastjson,怎么说服业务干掉Fastjson。对于Fastjson的代码质量,基础架构部有一些研究基础,认为Fastjson代码质量不是很好,这为后续推动Fastjson下线奠定了基础。

于是安全组调研了自身封装的Jackson和gson,形成一个初步结论,具体如下表:


安全性

性能

业务需求

Fastjson

1.漏洞通报机制差,0day漏洞满天飞,飞一年半载的不在话下。

2.全局安全风险

3.代码质量差,如dos漏洞

4.官方在testcase中泄露漏洞PoC

适配度佳

Jackson2.x(xxxx in KF)

1.已自行封装,去除不安全属性;

2.漏洞管理机制好,CVE通告

3.从架构上无全局风险

自行封装版本加入afterburner,性能强

自行封装,适配度佳

gson

基本无安全风险,代码质量高

一般

需自行评估

推动替代

有了前面的替代方案,接下来就是推动替代,说实话这真是一个很艰难的任务,对我们的挑战非常大。

第一要务是管住增量,目前是在第三方库的引入上未做强制卡点,但是对于Fastjson这种高危库,安全组在白盒扫描器中添加了相应规则,发现有新增的Fastjson,及时提醒业务方不允许使用。另外也在Check-style禁用了Fastjson,这样研发在开发的过程中就会感知到引入了高危的组件。

其次是存量Fastjson的替换,和基础架构组对出替代方案,依照业务优先级,优先推动主站等核心业务做替换,这些核心业务本身也很重视安全问题,几方立马就把这个事情推动下去了。这里面的核心挑战就是核心业务核心组件存在Fastjson依赖,第一步得把这里面的依赖给去除,否则其他位置还会间接引入Fastjson依赖。推完核心业务,接着按照类似模式推动对外业务,接着推动对内业务,历时快一年总共推动了不到1000个仓库完成替换。目前已经干掉了95%+Fastjson依赖。

对于快手来说,在安全工程师不会被饿死这件事上,fastjson已经难以做贡献了(小编表示好慌)。

第三方库漏洞管控

第一次应急的过程中还在愁怎么找全Fastjson,不管是快手代码搜索平台还是制品库,都存在覆盖面不全的问题。后面为了提升应急速度,特别是这种第三方库漏洞的应急速度,从gitlab拉取了所有第三方库,通过和第三方漏洞库比较,形成了 Java 三方依赖安全检测。

第三方库漏洞甚至供应链漏洞已经成为不容忽视的一个漏洞形态,我们接下来也会投入更多力量到第三库漏洞管控上,欢迎大家一起交流进步。


转载自 快手安全应急响应中心

已有1条评论
  • 2020-08-26 14:07:23

    https://github.com/fangjinuo/easyjson
    采用类似于slf4j的方案,直接干掉fastjson,无需代码改动,替换Jar包即可。

请关注微信公众号
微信二维码
不容错过
Powered By HeiBaiTeam.