引言:
近两年,百度的OpenRasp在安全业内大火,各大厂的安全团队都在纷纷跟进研究,捣鼓自己的IAST/RASP产品。作为一支有追求的安全团队,自然要推动这类新兴技术在行内落地。但想要大面积覆盖全行应用中,项目的推广、适配、运维方面的挑战都是不小的。这里分享我们实践的一个新思路,能有效的达到快速部署的目的。
IAST/RASP的原理这里就不介绍了,其主要优点就是检测精准。技术是好技术,但要在企业中大规模部署,它的缺点也很明显:
要实现大规模部署,我行几千应用系统、几万服务器的适配、测试、部署、维护…这推广、维护工作太重。
虽然在c0debreak大佬团队的努力下,rasp agent对服务器的性能影响已可控制到3%左右。但在银行交易系统中,我们也不敢轻易“玩火”,只能将目标锁定在后管类系统上。
好吧,觉得以上难搞也许是我的缺点。
除此之外,我行自动发版工具会将tomcat容器整包替换,导致之前部署的raspAgent丢失。虽然这个问题很好解决,但是提议的两个方案,都以不符合管理规范而惨遭否决。
如果不用从0推广Agent、不用适配测试、不用运维就能实现IAST/RASP能力的落地,那就好了~
理想一定要有,万一实现了呢。
然后,就有了以下这个思路:
实现也很简单,一些APM应用监控平台(如CAT、WiseAPM、Dapper等,我行使用的是CAT,本文以CAT为例)的客户端同IAST/RASP agent实现原理一致,用的是java字节码技术,通过插桩记录程序运用时的堆栈数据,来分析应用健康度。而它所监控的数据就有安全所感兴趣的,比如说原生sqllog、关联的接口信息、服务器信息等等。一般此类APM都是由架构运维部门负责,且基本能够覆盖绝大数业务系统,已完成从0到1的大面积推广及运维保障。如果安全赋(寄)能(生)在它们的agent上,就能解决我们的问题。
CAT架构
要基于CAT的Agent实现IAST/RASP的漏洞检测能力,规则放在客户端运行,CAT那边肯定是不会同意的,且可能对应用影响较大,不建议介入太深。只能看看安全关心的应用数据,然后再进行离线分析就可以了。当然具体能检测哪些问题,还是要看CAT做了哪些函数的插桩埋点,这里就不再赘述。下面以SQL注入为例,介绍下我们的实践过程。
为什么要从SQL注入入手。原因有两点:
1.此类APM平台,基本上都有SQL性能分析,所以基本上都可以提供原生SQL数据,这是现成的。而其他漏洞可能还需要增加埋点。
2.去年我们团队搞了大半年的被动扫描器,由于SQL注入黑盒测试造成大量脏数据,以及准确率等问题,一直比较头疼。正好借此机会来优化一下。
首先需要CAT对原生sql进行一定的处理,补充记录所属应用、服务器IP、sql关联的接口等信息,最终形成sqllog。输出如下格式:
{"appid":"xxxx","ip":"192.168.1.100","source":"URL:/xxx/abc/custInfo.do","sql":"select * from t_user where username = ?"}
剩下就是将全行集成CAT的应用记录的所有sqllog收集下来,集中推送到安全的kafka中,再设计检测程序逐条消费。架构如下:
由于依赖于CAT,我们的项目代号为BlackCAT(黑猫警长)。上图中,被动扫描器只在主动式IAST场景下的充当无脑发包器,对抓的所有流量进行全量标记盲打,与BlackCAT分析引擎无需联动。有溯源必要时,可在request中加一些特征标识,如在url后或header中追加BlackCAT参数,通过catlog同步通知BlackCAT即可。
以mybatis项目监测情况为例,#{param}和${param}插桩JDBC记录到的sql是不一样的。预编译的sql的入参是占位符“?”,而使用拼接的sql可以看到入参内容。
预编译:
select * from t_user where username = ?
拼接:
select * from t_user where username = “helen”
但在真实复杂的应用场景中,还无法仅凭是否有占位符来判断是否存在sql注入,很多情况下,应用内部的sql也有很多,所有要确认是存在漏洞,还需要找到用户入口。
理清了数据以及确定目标,就可以去设计离线检测策略了。目前我们共实现三种检测逻辑:mark标识位、黑名单检测、入参比对,分别对应测试环境中IAST漏洞扫描以及生产环境中RASP攻击监测(RASP暂时只实现告警)。
mark标识位(主动式 IAST):
在被动扫描器上新增一个iast插件,对测试区全部流量进行参数注入,在value后拼接上一个标记字符串。
POST /xxx/abc/custInfo.do HTTP/1.1Host: 192.168.1.100:80User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36Accept: */*Referer: http://192.168.1.100/adminAccept-Language: zh-CN,zh;q=0.9Cookie: token=123456789username=helenMarkedbyscanner
BlackCAT异步监控分析全行应用的执行SQL。如在发现某些SQL中有标识位进入,则可判断该属主应用使用了拼接SQL且存在用户入口,存在安全漏洞。
select * from t_user where username = "helenMarkedbyscanner"
标识位检测日志
黑名单检测(RASP攻击告警)
这里目前实施了两种方式:
1.通过黑名单规则检索sql中的可疑的payload,这点参考WAF策略。相较于WAF,好在如果发现有payload进入sql,那就存在漏洞且攻击成功。但由于都是维护黑名单规则,即可能存在误报漏报。
2.统计在sql中检索单引号数量,判断总数是否为奇数引号。一般如出现奇数引号,可能为人为注入测试,可判断有潜在攻击者,且已发现漏洞。
入参比对(被动式IAST及RASP攻击告警)
入参比对是将request中的入参值与关联的sql的入参进行比对。
如发现二者入参数存在一致的value,则可确认存在漏洞,因为用户输入参数被拼接带入了sql中去。
在此基础上,再判断是否为攻击,可通过value是否被带入未转义的特殊字符(如空格,引号,斜杠等等),value是否包含除字符串以外的其他元素。如为真,存在攻击;也可以直接提取原生sql的查询条件value,分析对比请求入参是否能在提取的value中找到。如为假,则存在攻击。
到此为止,我们就基于CAT初步实现了IAST/RASP能力了,虽然初期检测逻辑还略显粗糙,但在实际应用中,还是取得了不错的效果。测试区上线短短1周内,自动发现SQL注入30多例,内部安全同事的sql注入测试百余起。后期就是继续增加埋点和优化策略,来增加检测的漏洞类型。
测试区IAST漏洞扫描
生产区RASP攻击检测告警
这种美其名曰安全赋能,实则抱大腿的合作模式,其好处就在于可以快速、无感地推动IAST/RASP能力的大规模覆盖,且无需担心对应用有任何影响。当然,这样的IAST/RASP能力覆盖面取决于应用监控CAT的推广程度。在我行,全行绝大数应用都已集成CAT,其中包括各类重要核心应用。现在无论是生产还是测试,都不用考虑那些头疼的推广适配、部署运维,只要牢牢的抱住大腿…
参考: