自建dnslog的福音

前言

近期随着各种高危漏洞的出现，dnslog平台成了香饽饽，各种burpsuit的检测插件横空出世，由于都是使用的知名的公开dnslog平台，就一度出现了知名dnslog平台被玩坏了的情况出现，对于红队从业人员来说，真的苦不堪言。使用自建dnslog平台就非常有必要了，于是乎有了此文章，充分利用团队dnslog平台，在成熟burpsuit插件的基础上，新增自建dnslog平台的利用，在检测效果上相当丝滑，可大大提高fastjson、log4j2等漏洞的检测效果。

# 团队dnslog平台自建指南 https://github.com/rabbitmask/dnslog

框架识别

惯例，开工之前先选好顺手的工具，这里最终选择pmiaowu师傅的burpsuit插件（以fastjson插件为例），自我感觉也对它比较了解，新增一个dnslog平台的处理，不就是新增一个判断新dnslog的方法就行了嘛

先看一下代码的框架:

Application：重头戏之一，这个项目文件夹下是执行命令相关的一些balabalaBootstrap:这个项目文件夹下是burpsuit相关和插件的配置文件定义CustomErrorException:异常捕捉的总接口DnsLogModule:重头戏之二，dnslog平台相关的处理，包括获取临时域名、获取dnslog的结果等pom.xmljava依赖，这里因需要处理json请求，所以添加了fastjson依赖其他的基本上都是固定的部分，可以不用细看

行动开始

copy一份原有的dnslog处理的java文件，结合ceye平台处理的java文件，在此基础上修改，这里命名为Wingsdnslog.java，与原有的dnslog处理在同一级目录下，文件位置见上图。

# 借鉴的两个dnslog平台的处理方法burp.DnsLogModule.ExtensionMethodDnsLogCn.javaburp.DnsLogModule.ExtensionMethodCeye.java

配置文件内容读取：

1.配置文件位置resources/config.yml2.从配置文件读取dnslog平台的名字，判断使用哪个dnslog平台,这里设置为Wingsdnslog3.根据实际情况从配置文件读取其他参数，这里读取的是token值

此部分代码如下：

public class Wingsdnslog extends DnsLogAbstract {    private IBurpExtenderCallbacks callbacks;    private String dnslogDomainName;    private String dnslogUrlName;    private String token;    private YamlReader yamlReader;    public Wingsdnslog(IBurpExtenderCallbacks callbacks) {        this.callbacks = callbacks;        this.dnslogDomainName = "http://x.x.x.x";        this.dnslogUrlName = "http://x.x.x.x";        this.setExtensionName("Wingsdnslog");        this.yamlReader = YamlReader.getInstance(callbacks);        String Wings = this.yamlReader.getString("dnsLogModule.Wings");        this.token = CustomHelpers.getParam(Wings, "token").trim();        this.init();    }

配置文件新增内容如下：

# dnsLog模块dnsLogModule:......  # Wingsdnslog......  Wings: "token=;"

下一步就是获取临时域名：

借用上面读取到的token值，构造POST请求包，并读取response内容中临时的dnslog子域名

private void init() {        String url = this.dnslogUrlName + "/api/verifytoken";        String userAgent = "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36";        HttpRequest request = new HttpRequest(url, "POST");        request.header("Content-Type", "application/json");        request.header("User-Agent", userAgent);        // 将请求体信息放入send中        request.send("{"token":""+this.token+""}");        request.readTimeout(3 * 1000);        request.connectTimeout(3 * 1000);        // 设置 Wingsdnslog 的临时域名        String temporaryDomainName1 = request.body();        JSONObject object = JSONObject.parseObject(temporaryDomainName1);        String temporaryDomainName = object.getString("Msg");        this.setTemporaryDomainName(temporaryDomainName);    }

下一步获取dnslog请求结果：

借用上面获取到的临时子域名及token，构造GET请求包获取当前临时子域名下的dns请求结果。(RCE部分单独写的，基本上不用改)

public String getBodyContent() {        String url = this.dnslogUrlName + "/api/getDnsdata";        String userAgent = "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36";//        清空后再请求        HttpRequest request = HttpRequest.get(url);        request.trustAllCerts();        request.trustAllHosts();        request.followRedirects(false);        request.header("User-Agent", userAgent);        request.header("Accept", "*/*");        request.header("token", this.token);        request.readTimeout(3 * 1000);        request.connectTimeout(3 * 1000);        String body1 = request.body();        if (body1.equals("[]")) {            return null;        }        return body;    }

到这里，自有dnslog平台的处理就结束了，是不是就已经改完了呢？测试后发现凉凉，全是不想看到的not found。只能再分析代码，跟踪方法继续找问题。

代码分析

代码分析前，先确定自己改的这部分dnslog平台的处理代码没有有没有问题，毕竟是个新手，先测试获取临时子域名部分是没有问题的，其次临时子域名的dns请求结果部分，经过测试也是OK的。

基于此，基本上排除了dnslog平台处理的基础问题，思考过后，怀疑有可能是不同dnslog平台的返回数据不一致，而数据处理出了问题。

那就从数据处理部分开始入手，平常用的多，所以知道插件是根据请求子域名中的随机字符串来判断，是否存在漏洞。

直接追踪getBodyContent方法发现，发现是在命令执行的代码部分调用了。

查看这部分代码，首先是对返回结果做了一次判断，返回结果的长度>=1，就跳出循环。(看作者注释)此处理解为若判断条件成立，就认为dnslog平台收到过目标的RCE的请求了，然后跳出从列表中获取payload，不断尝试RCE请求的循环。

然后延迟8s后，等待二次请求dnslog结果的验证（防止漏报）。

也就是说，条件成立，不会对目标发送RCE请求，想到这里，好像明白了点什么。。

接着去看团队的dnslog平台的返回结果

果然，这里即使dnslog没有收到任何请求，返回的结果也不是空，所以，到了上面那步判断，就跳出循环，其实没有发送RCE的请求。

成果收获

既然找到问题所在，那就简单多了，在Wingsdnslog.java文件，对dnslog返回的有效结果增加一个去空处理不就行了，先从json数据中取Msg的值，把Msg值中的[]去空，上面那部分判断不就能过了。

JSONObject object = JSONObject.parseObject(body1);String body = object.getString("Msg");body = body.replace("[","");body = body.replace("]","");

清理后重新打包，测试发现这次插件报了熟悉的有漏洞的提醒

既然调试好了，不多测几次，都对不住这几天的投入，又点了另一个有漏洞的网站，带着美滋滋的心情，却发现，not found，这又是神马情况，不是已经改好了嘛。。。

安慰自己一番后，带着拔凉拔凉的心又回去看代码，又经过反复测试，最终找到问题所在。

上面确实通过去空，解决了返回结果长度判断的问题，但团队的这个dnslog平台，dnslog结果不会自动清空，从而就出现了第二及以上次请求的时候，因为有一些结果存在，导致返回结果长度>=1了，辗转反侧，还是卡在了第一次遇到的问题上面。

细想之下，这里就有两种解决方法：

注释掉这部分判断代码：

文件位置burp.Application.RemoteCmdExtension.ExtensionMethodRemoteCmdScan.java

最简单粗暴的方法，但没有中途退出循环条件，就面临着每次都要把所有payload全部请求一遍的问题，动静会很大，被ban的可能性也更大。

Application：重头戏之一，这个项目文件夹下是执行命令相关的一些balabalaBootstrap:这个项目文件夹下是burpsuit相关和插件的配置文件定义CustomErrorException:异常捕捉的总接口DnsLogModule:重头戏之二，dnslog平台相关的处理，包括获取临时域名、获取dnslog的结果等pom.xmljava依赖，这里因需要处理json请求，所以添加了fastjson依赖其他的基本上都是固定的部分，可以不用细看0

2. 增加清除历史记录部分的代码

在Wingsdnslog.java中增加清除功能，在每次请求临时子域名的请求结果之前，先清除历史dns请求记录，这样就能保证每次请求结果之前，dnslog结果是空的，就不用再注释掉上面代码了，做到尽量少更改文件。

Application：重头戏之一，这个项目文件夹下是执行命令相关的一些balabalaBootstrap:这个项目文件夹下是burpsuit相关和插件的配置文件定义CustomErrorException:异常捕捉的总接口DnsLogModule:重头戏之二，dnslog平台相关的处理，包括获取临时域名、获取dnslog的结果等pom.xmljava依赖，这里因需要处理json请求，所以添加了fastjson依赖其他的基本上都是固定的部分，可以不用细看1

再经过这番处理，终于改出了大成的一版，以后可以非常丝滑的进行渗透了，👩再也不用担心我会因为dnslog平台出现的各种各样的莫名其妙的的问题而与众多漏洞擦肩而过了。

参考链接

Application：重头戏之一，这个项目文件夹下是执行命令相关的一些balabalaBootstrap:这个项目文件夹下是burpsuit相关和插件的配置文件定义CustomErrorException:异常捕捉的总接口DnsLogModule:重头戏之二，dnslog平台相关的处理，包括获取临时域名、获取dnslog的结果等pom.xmljava依赖，这里因需要处理json请求，所以添加了fastjson依赖其他的基本上都是固定的部分，可以不用细看2