Cobra(眼镜蛇)-白盒审计静态代码安全扫描与分析系统
作者:admin | 时间:2016-12-14 01:29:38 | 分类:黑客工具 隐藏侧边栏展开侧边栏
0x00 介绍
眼镜蛇(Cobra)是一款定位于静态代码安全分析的工具,目标是为了找出源代码中存在的安全隐患或者漏洞。
为什么我们需要一款代码审计系统?
公司越来越大,开发人员也越来越多。每个研发人员的安全素质都不一样,虽然在公司核心项目上可以采取框架层安全防护,但各类新项目太多,无法做到每个项目都使用相同框架,都去集成安全组件。
所以对于公司所有的项目必须有一道防护来保障基本安全,代码安全审计即可作为这一道安全手段。
业内调研
目前业内已经有很多款代码审计工具了
名称 | 是否开源 |
---|---|
w3af | 是 |
Android Scan | 是 |
CMS Scan | 是 |
GrepBugs | 是 |
Pixy | 是 |
RIPS | 是 |
SWAAT | 否 |
CodeSecure Verifier | 否 |
PHP-SAT | 是 |
Yasca | 是 |
这些项目专注的点都不一样,极少数商用的是定位于企业内代码审计的,但都是闭源的。
还没有一款开源的,并且定位于企业级使用的。
作为甲方企业,我们所需要的:
- 能快速扫描新型漏洞(Web应用每天都会有新的漏洞/攻击手法出现,一定要能快速响应新型漏洞的扫描)
- 能够扫描多种开发语言(大公司肯定不会只有一种开发语言,这就涉及到需要支持多种语言)
- 能够自动扫描、自动报告(人工参与每个项目成本太大)
根据我们的目的筛选比较后发现,没有一款符合我们的需求。
于是我们选择了做一套符合企业级的代码审计系统。
如何做一套代码审计系统?
代码审计大体方式可以分为两种:静态和动态,
1. 静态审计
通过静态分析源码,发现源码中的逻辑、数据处理、函数使用不当来确认源码中可能存在的漏洞。
同时静态分析技术目前也分为几种。
1.1 规则匹配
说白了就是根据指定的规则扫描代码中的问题。
比如在PHP Kohana框架内,是有封装好统一的取参数的方法,并且经过安全过滤的。而可能出现的情况是新来的研发人员不熟悉导致使用了PHP内置的$_GET
/ $_POST
,从而导致XSS,这时就可以使用$_GET
/ $_POST
作为规则,找出源码中所有出现这些函数的地方。
这种方式也是很多白帽审计代码时用到的,虽然很直接了当,但是误报会比较多。
1.2 代码解析法
通过解析代码的语法,分析出代码执行流程。
1.3 数据流转分析
通过Fuzz输入数据,跟踪数据流转,来判断是否存在风险。
2. 动态审计
通过运行需要审计的代码,跟踪数据的流转来判断系统中是否存在漏洞。
我们一开始只打算扫我们关心的漏洞类型:高危文件、高危函数以及常规Web漏洞。
所以我们第一个版本只做静态审计中的规则匹配法,关于误报问题我们在实际扫描中采用了多种方式进行改进,确保误报率在5%以下。
企业应该在什么环节加入代码审计?
1. 代码提交时
代码提交时检测问题是最忌时机,具体可以通过hook svn或git的commit来扫描提交的代码。
优点:及时
缺点:影响提交效率
2. 代码提交后
通过设置定时任务在凌晨进行有规律的代码审计,结果通过邮件或BUG系统同步给提交人。
优点:不影响代码提交
缺点:可能代码已经上线才扫到问题
3. 代码发布时
代码发布前的测试环境进行扫描,上线前必须已经扫描完毕并且没有高危漏洞。
优点:不会出现代码已经上线才扫到问题,确保所有上线代码都经过扫描
缺点:发现的不及时
企业可以先接入在代码发布时,通过设置定时任务扫描来保证及时性和线上代码的覆盖率。
通过我们实际使用感受,发现还有更多用法:
1. 用来判断新漏洞的影响
比如用来判断ImageMagick在公司所有项目中的影响,我们就可以通过设置扫描规则来扫描公司所有项目,看哪些项目有调用ImageMagick并且没有可以利用的。
2. 用来检测明显代码逻辑问题
开发人员不小心将==写成=,造成逻辑问题,甚至可能引发安全问题。
或者是少些了结束的分号,但测试没有覆盖到,导致线上5xx。
这些问题也可以通过代码审计发掘出来。
还有其它更多的使用技巧,后续再慢慢补充...
目前项目进展
目前第一个版本已经上线运行,人工核查后发现扫描结果还是很不错的。
为了填补这块的空白,也为了让更多企业用上并减少安全问题,所以将代码开源到Github上,所有企业可以免费试用。
0x01 目标用户
1. 互联网企业
互联网公司可以将Cobra部署在企业内,供开发人员使用,用来扫描项目风险. 也可以集成到内部的代码发布系统,让Cobra成为发布系统中的一环,扫描开发人员提交到线上的代码的安全性,从而限制不安全的代码上线,减少线上风险。
2. 安全公司
安全公司为互联网公司进行安全测试时,可以通过Cobra的全局项目扫描功能对甲方的所有项目进行自动代码安全审计。
3. 白帽
白帽们可以通过定制完善Cobra扫描规则, 对开源项目进行代码审计,发现其中漏洞。
0x02 应用场景
1.漏洞出现前(检测)
我们将互联网上常见的漏洞梳理为Cobra的检测规则,能够在漏洞被白帽子发现前就扫描出风险点并解决,防范于未然。
例: 提前检测代码中是否存在高危文件(.tar.gz/.rar/.bak/.swp),可以避免高危文件被下载。
2.漏洞出现中(扫描)
当企业收到白帽子提交的漏洞后,企业会在第一时间修复漏洞,并可以通过Cobra来添加扫描规则检测企业的所有项目是否存在类似漏洞。
例: 出现了ImageMagick漏洞后,可以通过Cobra设置扫描规则对历史所有项目进行快速扫描,几分钟内就能知道企业数十个项目中哪些有用到ImageMagick组件,哪些存在漏洞,哪些可以免疫。
3.漏洞出现后(限制)
当企业修复漏洞后,可以通过设置修复/验证规则来限制以后所有提交的代码都需要过修复/验证规则,否则不予上线,减少相同漏洞再次出现的可能性。
0x03 项目演示
Cobra自助扫描
Cobra扫描报告
Cobra管理后台
0x04 扫描方式
提供自助操作界面供扫描,同时也提供标准全功能API接口供第三方系统调用(比如发布系统)
0x05 漏洞类型
除了常见的应用程序漏洞,还包括一些代码逻辑漏洞以及文件权限、敏感文件等 具体参见Cobra Vulnerabilities
扫描文件涵盖所有常见文件类型,注册检测规则支持Java、PHP两种语言。 具体参见Cobra Support Language
另外扫描的准确度、范围都是受各自开启的规则数影响的。
0x06 扫描过程
扫描器采用多进程设计,可以做到多任务并发扫描,每个扫描进程间互相不会受影响。并发数大小受机器硬件因素决定,可快速增加机器以扩展并发扫描效率。 扫描器对一般项目扫描能做到每秒n万个文件(1 < n < 10),扫描时间主要受触发的规则数所影响。
0x07 扫描结果
每次扫描完成后,会通知对应的责任人,并生成一张扫描报告。报告内会分析出现漏洞的代码并给修该漏洞的修复方式。 同时可以通过Cobra API获取扫描结果,发布系统可以根据扫描结果里面的建议决定此次是否允许发布上线。
0x08 规则的有效性
新规则的录入时,可以先对历史项目进行测试验证,待误报率降低后再讲该规则状态改为线上开启。 也可以针对自己的业务,手动的关闭一些特殊规则。
0x09 误报
规则验证的结果还是会存在误报,我们可以通过两个方式解决误报问题。 1. 优化规则 - 通过对误报的分析去优化规则的检测逻辑 2. 白名单 - 某些状态下我们需要某个规则对某个文件的某行放行(比如某些框架层的eval($cmd)),则可以使用白名单
TODO
- 完善安装流程文档
- 导出表结构文件
- 同步通用扫描规则