Brupsuite被动扫描Log4j2插件临时修改
字数 1088 2025-08-07 08:21:54

BurpSuite被动扫描Log4j2漏洞插件分析与修改指南

1. 背景介绍

Log4j2漏洞(CVE-2021-44228)是2021年底爆发的严重远程代码执行漏洞,影响范围极广。本文记录了对BurpSuite被动扫描Log4j2漏洞插件的分析过程和修改经验。

2. 插件原理解析

2.1 插件工作流程

  1. 被动扫描机制:插件通过BurpSuite的被动扫描功能检测HTTP请求中的潜在注入点
  2. DNSLOG验证:利用DNS回显技术确认漏洞存在
  3. 参数遍历:检测GET、POST、Cookie等参数位置

2.2 项目结构分析

D:.
│  .gitignore
│  pom.xml
│  README.md
│
├─screenshots
│      detected.png
│
└─src
    └─main
        └─java
            └─burp
                │  BurpExtender.java
                │  Log4j2Issue.java
                │
                ├─dnslog
                │  │  IDnslog.java
                │  │
                │  └─platform
                │          Ceye.java
                │          DnslogCN.java
                │
                ├─scanner
                │      Log4j2Scanner.java
                │
                └─utils
                        HttpUtils.java
                        ScanItem.java
                        SslUtils.java
                        Utils.java

2.3 核心代码分析

2.3.1 Log4j2Scanner.java

  • 定义漏洞利用Payload
  • 遍历请求参数(GET/POST/Cookie)
  • 替换参数值为恶意Payload
  • 调用CheckResult验证漏洞

2.3.2 Dnslog平台实现

DnslogCN.java核心功能

  1. initDomain() - 获取DNSLOG子域名
  2. getNewDomain() - 生成随机子域名
    public String getNewDomain() {
        return Utils.getCurrentTimeMillis() + Utils.GetRandomString(5) + "." + rootDomain;
    }
    
  3. CheckResult() - 检查DNS解析结果

3. 问题发现与解决

3.1 原始问题

  1. DNSLOG.CN平台不可用
  2. POC构造不完整(缺少闭合括号)
  3. 检测效率低下

3.2 解决方案

3.2.1 替换DNSLOG平台

使用https://log.xn--9tr.com/替代原DNSLOG.CN平台

新平台特点

  • 需要Token验证
  • 请求格式不同:
    • 获取子域:GET https://log.xn--9tr.com/new_gen?t=0.3113540327207853
    • 获取结果:需要将domain和token放入Cookie

3.2.2 代码修改实现

JSON解析实现

private JSONObject sloveJSON(String respStr) throws IOException {
    JSONObject object = null;
    try{
        object = JSONObject.parseObject(respStr);
    }catch (JSONException e) {
        e.printStackTrace();
    }
    return object;
}

请求构造

public Request.Builder GetDefaultRequest(String domain,String token,String url) {
    CacheControl NoCache = new CacheControl.Builder().noCache().noStore().build();
    int fakeFirefoxVersion = GetRandomNumber(45, 94 + Calendar.getInstance().get(Calendar.YEAR) - 2021);
    Request.Builder requestBuilder = new Request.Builder()
            .url(url);
    requestBuilder.header("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:" + fakeFirefoxVersion + ".0) Gecko/20100101 Firefox/" + fakeFirefoxVersion + ".0");
    requestBuilder.header("Cookie", "key=" + domain + "; " + "token=" + token);
    return requestBuilder.cacheControl(NoCache);
}

4. 优化建议

  1. 减少DNSLOG依赖

    • 搭建私有DNSLOG平台
    • 使用JNDI监听器替代DNSLOG
  2. 性能优化

    • 精简参数遍历数量
    • 增加请求间隔避免被封禁
  3. 功能增强

    • 增加检测类型
    • 忽略静态文件检测
    • 增加绕过POC

5. 相关资源

  1. 原项目地址:https://github.com/whwlsfb/Log4j2Scan
  2. 修改版地址:https://github.com/K0uaz/Log4j2Scan_K

6. 总结

通过本次插件分析和修改实践,展示了如何:

  1. 分析现有安全工具的工作原理
  2. 针对实际问题进行定制化修改
  3. 将想法转化为实际可用的工具
  4. 思考工具优化方向

这种"分析-修改-优化"的思路适用于大多数安全工具的二次开发场景。

BurpSuite被动扫描Log4j2漏洞插件分析与修改指南 1. 背景介绍 Log4j2漏洞(CVE-2021-44228)是2021年底爆发的严重远程代码执行漏洞,影响范围极广。本文记录了对BurpSuite被动扫描Log4j2漏洞插件的分析过程和修改经验。 2. 插件原理解析 2.1 插件工作流程 被动扫描机制 :插件通过BurpSuite的被动扫描功能检测HTTP请求中的潜在注入点 DNSLOG验证 :利用DNS回显技术确认漏洞存在 参数遍历 :检测GET、POST、Cookie等参数位置 2.2 项目结构分析 2.3 核心代码分析 2.3.1 Log4j2Scanner.java 定义漏洞利用Payload 遍历请求参数(GET/POST/Cookie) 替换参数值为恶意Payload 调用CheckResult验证漏洞 2.3.2 Dnslog平台实现 DnslogCN.java核心功能 : initDomain() - 获取DNSLOG子域名 getNewDomain() - 生成随机子域名 CheckResult() - 检查DNS解析结果 3. 问题发现与解决 3.1 原始问题 DNSLOG.CN平台不可用 POC构造不完整(缺少闭合括号) 检测效率低下 3.2 解决方案 3.2.1 替换DNSLOG平台 使用 https://log.xn--9tr.com/ 替代原DNSLOG.CN平台 新平台特点 : 需要Token验证 请求格式不同: 获取子域: GET https://log.xn--9tr.com/new_gen?t=0.3113540327207853 获取结果:需要将domain和token放入Cookie 3.2.2 代码修改实现 JSON解析实现 : 请求构造 : 4. 优化建议 减少DNSLOG依赖 : 搭建私有DNSLOG平台 使用JNDI监听器替代DNSLOG 性能优化 : 精简参数遍历数量 增加请求间隔避免被封禁 功能增强 : 增加检测类型 忽略静态文件检测 增加绕过POC 5. 相关资源 原项目地址: https://github.com/whwlsfb/Log4j2Scan 修改版地址: https://github.com/K0uaz/Log4j2Scan_ K 6. 总结 通过本次插件分析和修改实践,展示了如何: 分析现有安全工具的工作原理 针对实际问题进行定制化修改 将想法转化为实际可用的工具 思考工具优化方向 这种"分析-修改-优化"的思路适用于大多数安全工具的二次开发场景。