GitHub敏感信息泄露监控

Feei <feei#feei> 01/2018

1. 漏洞背景

GitHub作为开源代码平台,给程序员提供了交流学习的地方,提供了很多便利,但如果使用不当,比如将包含了账号密码、密钥等配置文件的代码上传了,导致攻击者能发现并进一步利用这些泄露的信息,就是一个典型的GitHub敏感信息泄露漏洞。

2. 解决思路

2.1. 制度为辅

新入职员工往往这方面的意识较为薄弱,通过对新入职员工的专项安全培训,着重普及下在工作和生活中因为意识不足所导致的一些安全问题及应对方法。让新人对此有个基础的意识,知道上传GitHub代码会有风险,并将其加入到内部的信息安全守则或红线中,有据可依也有据可罚,对恶意上传者起到一定的威慑,对于老员工也有一定的意识提升。进一步可以细化GitHub开源规范,让开源流程化,也让安全团队介入其中进行评估。

2.2. 技术为主

2.2.1. 内外网隔离

从代码泄露最终的结果上看,直接影响的是外网可访问的接口被利用,比如邮箱账号密码泄露的话会被攻击者所登陆并拿到邮件信息、组织架构及花名册等;数据库使用外网IP会导致数据被盗取等。 所以可以先从内外网隔离来做,规范代码中统一使用内部接口、内部IP,迫不得已的外部接口可以通过增加二次验证、限制访问源IP等策略进行加固。 这样这样泄露出去的代码无法对企业造成直接影响,至于代码本身存在的一些漏洞就需要依靠白盒代码审计日积月累了。

2.2.2. 实时监控

经过内外网隔离后,代码虽然无法造成直接的危害,但毕竟是公司资产,涉及公司声誉,还是需要进一步解决。所以实时的监控很有必要,我们如果能在第一时间内发现泄露的信息并找到对应人及时删除,造成的影响将会被降到最低。

2.3. 技术方案

监控核心思路可以通过GitHub搜索代码中的特征来发现泄露的信息。

同类型项目Hawkeye使用的是代理爬取的方式进行定期搜索,但代理爬取的方式有诸多弊端,最大缺点是爬取的时候GitHub是一个黑盒,你不知道他是什么频率限制规则,也不知道他什么时候改变规则,一切都存在不确定性。

虽然GitHub API也有频率限制,但他的文档中明确了频率限制的策略,我们可以通过做好频率控制避免触发GitHub API限制规则。

对于绝大多数的企业,做好以下两条就不会被触发GitHub频率限制规则。目前已经试验过的2000条扫描规则15个token在多种时间频率下未发现问题。

3. 最佳实践

3.1. 收集特征

那如何找到我们的特征呢,GitHub作为一个开源代码托管平台,代码首当其中,但也会有人将GitHub仅当做版本控制系统来管理自己的文档、资料。这类资料都有一个共同特征,里面包含企业的专属特征:代码中接口的调用包含内部API地址、代码头部包含企业的Copyright信息、代码包名包含企业的主域名等。

3.1.1. 常见几类特征

3.1.2. 如何找到其它企业内部特征?

可以从域名特征入手,最简单的通过一些特定关键词:

搜索GitHub代码,根据代码人工确认是否是误报。找到某个确定是该企业的工程后,分析改工程其它类型的特征即可,对于下属企业可以通过域名注册人反查并循环前面的逻辑。 比如要找蘑菇街的内部特征,可以通过在GitHub中搜索mogujie dev即可找到属于蘑菇街的工程,继而我们再从这类工程中找到真正的内部域名和其它类型特征。

实践例子

声明:通过本篇内容任何人都可以轻易找到任何公司的内部特征,例子只为提升理解,若觉得侵权请联系我删除。 仅列取部分典型厂商的典型内部特征作为讲解。

3.1.3. 了解搜索特性有利于特征收集

3.3. 告警与响应

在告警这块早期为了告警速度与响应速度,选择了邮件的方式,在后续的实践过程中我们也尝试想改成管理后台、Slack等形式,但综合评估后觉得邮件是最佳实践。

3.3.1. 漏洞告警实践

3.3.2. 漏洞响应实践

使用邮件来管理这类漏洞,证实存在或有研究价值的漏洞可以打上不同颜色星标,继而提交给对应厂商或发送给应急响应小组。而证实误报的可以删除到垃圾桶,定期通过优化代码和规则解决;

3.4. 误报与漏报

3.4.1. 误报

我们目前积累的常见的误报规则

3.4.2. 漏报

我们可以不断补充规则来覆盖尽可能多的特征场景,但还是避免不了漏报,毕竟不是所有的项目都遵守或符合我们的特征。如果企业安全团队推动力比较强,可以考虑给所有项目都加上一个文件,内容可以是一个索引标记,之后就根据这些索引标记输出为监控规则来实现无漏报。

4. 漏洞现状

为了优化速度及误报问题,我们将国内的漏洞盒子、补天及乌云历史上的厂商都加入到监控列表中进行测试,我们仅拿着这一类漏洞刷某漏洞平台全部厂商进了排名榜前十,漏洞报告太多导致触发邮箱频率限制规则被ban了,由此可见这类问题在国内的多么普遍。

有SRC(漏洞应急响应中心)的厂商我们都会尽量将漏洞反馈过去,每月单漏洞收入超过10k+,但大多数厂商是没有对外接收漏洞的渠道,为避免这类漏洞被人恶意利用,我们开源了整个项目,所有厂商可以免费使用,移步https://github.com/FeeiCN/GSIL,据了解国内已有数十家互联网公司在使用GSIL,包括蘑菇街、美丽说、小店、大搜车、农信银行、泰康保险、传化集团、投哪儿网、广发证券等(如果你也在使用GSIL并希望出现在此列表请通过feei#feei.cn联系我)。

除了针对各个企业的特征外,我们还发现了一些通用特征,这些特征往往造成的影响更大,比如针对企业邮箱私密文档公私密钥通用连接组件的规则所捕获的信息也经常会涉及到各家企业,比如之前某家云厂商员工将某个系统上传到GitHub,其中包含了可通过公开API调用的公私密钥,可控制其数万台服务器全部权限。

而且越来越多的线索表明这类漏洞越来越多的被恶意利用,比如之前曾发现黑灰产通过大批量监控收集所有泄露的AppIdAppSecret来控制微信公众号进一步达到盈利目的、通过泄露的SSH/Redis账号密码获取主机权限并挖矿等。

只有将问题充分暴露出来,大家才会正视并解决问题。

引用参考