系列 | 浅谈带外应用测试（一）

带外应用安全测试技术(OAST)经常出现在渗透测试与自动化漏洞检测的文章与实际案例中，但相关详细介绍及分析较为少见。本系列文章将通过58集团内部动态安全应用安全测试(DAST)与带外应用安全测试(OAST)联动的一些案例尝试对OAST技术进行分析并寻找一些新的利用方式，希望能起到抛砖引玉的作用，期待大家的真知灼见。

什么是带外应用安全测试(OAST)

带外应用安全测试(OAST)在原有信道的基础上通过建立新的信宿(相对于请求目标)，进而创建新的通信信道，通过新信道中的数据交互的信息判断漏洞是否存在。

OAST的一些优势

提高检测率

由于OAST判断漏洞是否存在的信息与请求响应信息并不在同一个信道，这就意味着，OAST可以检测到DAST检测不到的一些漏洞场景，包括但不限于：

1、无回显漏洞

2、异步逻辑漏洞(不能立刻给出响应的漏洞，也叫延迟漏洞)

3、中间链路漏洞(在请求目标前后，请求流量可涉及到的日志或逻辑会使中间链路系统(数据记录、日志处理系统)触发漏洞，但请求目标没有漏洞)

零误报率

由于OAST的判断依据为是否与新信宿产生交互通信，所以需要将原有DAST的请求载荷换成适用于OAST的请求载荷。一旦存在与新信宿产生交互就是触发漏洞，不存在误报。

无感知与无害化

这一点每个人的需求都不一样，从业务角度来说就是对资产和业务无害化，保证安全测试下应用程序能够稳定运行，从渗透角度来说就是无感知，保证扫描过程中绕过现有安全防护规则，漏洞触发行为尽量避免被安全产品识别。由于OAST的请求载荷只有漏洞存在时才会触发，请求本身并不会对系统进行影响(不包括QPS)，且新的通信信道可依赖于多种协议，这也进一步给检测提供了无感知的机会。

OAST与DAST的联动

基于binlog记录检测SQL注入

传统检测SQL注入的方式大多基于目标响应页面的布尔化特征，而这种方式检测无疑有着开发成本高、高误报以及高漏报的缺点；同时在无害化方面来说，SQL注入的动辄数十条至百条payload很容易造成大量的脏数据，构造的各种高危语句有可能会对数据库造成损害。所以在这样的情况下我们依赖于OAST技术尝试并实现了基于日志检测SQL注入的方法(ps：此方式只适用于甲方，并且有统一的数据库管理系统)。

经过调研，我们找到了一个符合我们检测方式的目标表，events_statements_summary_by_digest。它按照每个库级别对象和语句事件的原始语句文本统计值（md5 hash字符串）进行统计，该统计值是基于事件的原始语句文本进行精炼，而这种精炼的方式正是我们检测的关键。

SQL语句：SELECT * FROM users WHREE id='1';精炼后的语句：SELECT * FROM `users` WHERE ID = ?SQL语句：SELECT id,username FROM `users` WHERE id='2';精炼后的语句：SELECT ID , `username` FROM `users` WHERE ID = ?SQL语句：SELECT id,username FROM `users` WHERE id>'3' limit 0,1;精炼后的语句：SELECT ID , `username` FROM `users` WHERE ID > ? LIMIT ?, ...SQL语句：INSERT INTO users(`id`, `username`, `password`) VALUES (7, 'test', 'test');精炼后的语句：INSERT INTO `users` ( `id` , `username` , `password` ) VALUES (...)

从上面例子我们可以看到，SQL语句精炼的方式就是将关键字(select,where,limit)以及表名、列名等留下来，而我们的具体的数据都被转化成了特殊字符，最重要的是出错的SQL语句也会被记录下来。

回到SQL注入本身，我们判断是否存在注入的一个重要点就是传入的字符串能否逃逸出来被当作正常SQL语句执行，那么逃逸之后如何让日志将那条逃逸掉的SQL语句记录下来呢，那就是我们要造出来一个不会被精炼掉的字符串，这个其实也很好办到，下面举一个检测SQL注入的例子。

正常的输入：1正常的SQL语句：select * from users where id='1';正常的精炼语句：SELECT * FROM `users` WHERE ID = ?非法的输入：1' and 58anquan and ''='非法的SQL语句：select * from users where id='1' and 58anquan and ''='';非法的精炼语句：SELECT * FROM `users` WHERE ID = ? AND `58anquan` AND ? = ?

那么在这样的情况下，我们可以把所有数据库的events_statements_summary_by_digest表信息收集起来，在此表中查含有58anquan的数据，就可以定位到哪个数据库存在SQL注入。同时我们可以在58anquan后面加上一个能够关联到具体url以及参数的唯一id，这样可以直接定位到出现问题的接口，漏洞修复也比较方便。

SQL检测方式

基于LDAP/RMI协议请求检测LOG4J漏洞

漏洞探测联动常见的形式还有反连平台，当前市面上主流为DNS反连平台和HTTP反连平台。其中DNS反连平台利用了DNS请求会留下日志记录的原理，发现触发漏洞的目标。但是我们发现仅用DNS与HTTP并不能满足所有的需求。

以2021年公开的Log4j漏洞为例，其归根结底是一个非常简单的JNDI注入漏洞，但是由于该框架流行度高，且漏洞利用门槛低，导致该漏洞影响范围极广，危害巨大。企业外部黑客针对于该漏洞的主流探测方式为从公开的DNS反连平台获取子域名，将子域名拼接至漏洞利用代码中，使目标漏洞触发时对子域名进行请求解析，这样便能达到探测漏洞进而进行敏感信息外带的目的。

但该方法其实并不适用于企业内部的漏洞应急与探测，一是DNS请求记录获取的IP并不是真实漏洞触发目标的ip，虽然我们将请求目标的特征以uuid的形式拼接至域名(例如我们扫描aa.58.com会将反连平台域名置换为aaa58com.58dnslog.com),但如果存在中间链路触发漏洞的情况(请求流量使数据采集系统或日志采集系统触发漏洞)就会产生触发误报。二是由于我们在漏洞探测时通常并不会真正创建一个恶意类供目标去加载，加载请求如果不能及时断开，服务打印日志的线程会阻塞，如果服务存在线程池的话，阻塞的多了，就有可能把线程池打满导致服务受到影响。

所以想满足既可以获取到触发漏洞的真实目标地址又能够主动断开远程加载资源的请求这两个条件就需要寻找新的方式。很快我们发现ANTENNA的多协议组件(很早以前)便能够很好的解决上述问题。这也让当时58集团黑盒团队在极快的时间内完成了Log4j漏洞探测。

该组件的工作原理也并不复杂，组件基于socket模拟LDAP与RMI协议通信交互，当目标触发漏洞将向ANTENNA平台域名请求含有目标信息的资源地址，组件接收到LDAP/RMI协议请求进行报文解析，获取请求资源信息与目标绑定并主动断开连接。关于模拟LADP/RMI协议的技术近期网上也有很多人分享，这里便不过多说明。

集团ANTENNA平台LDAP组件工作方式

总结

上述只是带外应用安全测试技术一些比较浅显的利用层面。OAST的应用目前发展逐渐趋于成熟，开源产品也是层出不穷，个人认为依然有更多的利用层面与方式等待大家去挖掘与发现，后续也会和大家分享其余的一些利用方式与ANTENNA开源的一些计划。也期待大家有更多的利用场景分享。