diff --git a/data.json b/data.json index 33456483..097241e9 100644 --- a/data.json +++ b/data.json @@ -21514,5 +21514,11 @@ "https://mp.weixin.qq.com/s/CdDIutoSqe9FE3HekP5jBA": "成为CNNVD漏洞库支撑单位，助力网络安全！申请全流程解读，专业团队助您高效通过", "https://mp.weixin.qq.com/s/BoddBQjCcWeyrWyRzYUOxw": "2026HW必修高危漏洞集合2.0", "https://mp.weixin.qq.com/s/G4JXqTu1wHpBVw-PMW_vCQ": "【热点安全风险】6月30日 | 继DirtyFrag后又一Dirty系列漏洞：DirtyClone（CVE-2026-43503） Linux内核提权漏洞需重点关注", - "https://mp.weixin.qq.com/s/JXbjJjLgAPxlAC8hsPS0nw": "CNVD漏洞周报2026年第25期" + "https://mp.weixin.qq.com/s/JXbjJjLgAPxlAC8hsPS0nw": "CNVD漏洞周报2026年第25期", + "https://mp.weixin.qq.com/s/ESnN73pNv9zxhGsv6hAIFw": "【CVE-2026-55200】libssh2 RCE 漏洞（PoC 已公布）", + "https://mp.weixin.qq.com/s/dXlT4uDqLoDnl4G-Qgb5xQ": "国安部预警：AR 手游采集 300 亿实景数据，民用地理数据存在军事化泄密风险 ；CNVD2026 第 25 期漏洞周报：零日漏洞占比超八成 | 牛览", + "https://mp.weixin.qq.com/s/nxKVyCI5hAuNkq2601sC-Q": "渗透测试|从账号枚举到未授权访问，再到白盒RCE的一次渗透测试实录", + "https://mp.weixin.qq.com/s/-pUahaI_I_0nG3XeYVFWTQ": "微步 XGPT 发现 Apple 内核漏洞并获致谢", + "https://mp.weixin.qq.com/s/8tGezd4UbB89lPQywQeqGA": "炸场！GitHub公开海量未报送0day PoC，多款常用软件高危", + "https://mp.weixin.qq.com/s/rxNHcc9vEJiJczCTSGZ21g": "7月社区投稿活动 | 漏洞挖掘∕AI渗透" } \ No newline at end of file diff --git a/doc/2026-06/7月社区投稿活动 漏洞挖掘∕AI渗透.md b/doc/2026-06/7月社区投稿活动 漏洞挖掘∕AI渗透.md new file mode 100644 index 00000000..3a4f5869 --- /dev/null +++ b/doc/2026-06/7月社区投稿活动 漏洞挖掘∕AI渗透.md @@ -0,0 +1,101 @@ +# 7月社区投稿活动 | 漏洞挖掘/AI渗透 +掌控者 + 掌控者 掌控安全EDU 2026-06-30 06:41 + +# 2026 | 07 月社区投稿活动 +### 本期活动奖金池 + +**30000金币** +(1000金币=100大洋，可在社区商城提现)，打空截止，不另外追加奖金池 +### 活动时间 + +7 月 1 日- 8 月 1 日 +### 投稿要求 + +**文章内容必须为原创内容，Track社区首发且未在公众号中发布过** +1. 文章简洁，格式美观大方，敏感内容请注意脱敏处理。 +2. 文章通过后，如果发现一稿多投，打赏的金币将收回。 +#### 3. 针对【漏洞复现】文章稿件要求如下： + +近三个月出现的热点大型漏洞分析复现，可根据情况给到1000 至 3000+ 金币稿费，具体稿费可添加审核微信咨询： + +1、详细的漏洞介绍 + +2、详细的环境搭建 + +3、详细的漏洞分析 + +4、详细的漏洞利用思路及复现 + +5、内容为原创Track社区首发 + +6、优秀原创案例： +flysheep | 飞塔漏洞分析报告之CVE-2024-21762 + +**封神台漏洞复现靶场 WriteUp 固定奖励 300 金币** + +**获取投稿活动咨询、投稿审核等 可联系审核微信：hackerxhz666，添加时请备注：track-你的社区昵称** +### 集赞奖励计划 +##### 在平台投稿审核通过的文章，将自动加入集赞奖励计划(奖励系统自动触发)： +- 5个赞，奖励 20 个金币 + +- 10个赞，奖励 40 个金币 + +- 20个赞，奖励 100 个金币 + +注：单人点赞有次数限制，恶意刷赞将被检测，请不要恶意刷赞。 + +**新增规则：在 掌控安全EDU 公众号发布的投稿文章，三天内点赞数超过20可额外获取100金币奖励** +### 本月活动文章主题：漏洞挖掘 + +**本月收录优秀面试经验贴，可以与其他投稿活动奖励叠加~****优秀面试经验贴案例：** +https://bbs.zkaq.cn/t/32026.html******面试经验模板贴：** +https://bbs.zkaq.cn/t/2956.html + +**特别优秀文章可以给到单篇 2000-3000 金币及以上的奖励，特别优秀文章：攻防对抗详细内容、对抗绕过成功等技巧性知识、知识点全面总结等，此类文章投稿请作者单独添加审核微信：hackerxhz666，备注：track-你的社区用户名** + +### 7 月主题投稿活动： + +**对于符合 7 月活动文章主题且文章稿费****≥2500 金币（≥250 元） 的 实战攻防文章****，每篇给予****额外的 300 金币****投稿活动奖励(注：此活动与每月日常投稿活动不叠加)。** + +### 每月日常投稿活动： +

投稿活动奖励

文章篇数

额外奖励

1

共发表 1 篇有效文章

100 金币（不限新老用户）

2

共发表 3 篇有效文章

300 金币

3

共发表 5 篇有效文章

500 金币

+ +**投稿活动奖励范畴：对于稿费 ≥ 2500 金币（≥250 元）的文章不参与每月日常投稿活动以及请不要设置文章付费门槛，因为我们会给到您足够的稿费！** + +**注：所有投稿活动奖励仅针对通过审核的有效文章，额外奖励可叠加，立即结算生效。实战文章若未达到 300以上（包括300）金币的文章，不计入投稿活动奖励范围** + +#### 长期收文章类型： +``` +实战纪实类(各大src、护网项目、实战渗透报告)  代码审计类（需写清楚完整的代码审计流程） 二进制安全研究 恶意样本分析 安全开发、漏洞利用武器化研究 CTF Writeup【暂时不做收录】 +``` + + +**对所有的投稿文章，默认作者授权允许本公司以原创的方式将文章转载到微信公众号中（微信公众号原创发布时 作者署名：zkaq-作者的社区名字）** + +注: + +1.如对该授权存在异议，请在文章中进行标注。文章仍可通过审核发布在平台，但社区将不奖励任何金币。其他用户阅读后打赏的金币仍归作者所有. + +2.对于实战类型的文章，请作者自行脱敏。对一些通杀漏洞的分析等文章，请作者在文章末尾提供修复建议 +### 稿件审核标准 + +文章的审核将从以下4个维度进行审核，并且会在稿件打赏中标明等级，及相应的金币数量 +``` +技术深度    一级 1000-3000金币    二级 500-1500金币    三级 100-500金币技术广度、普适性    一级 1500-3000金币    二级 700-1500金币    三级 100-700金币文章可读性、完整性    一级 200金币    二级 100金币文章稀缺度(稀缺度需要有技术深度) ：    一级 1000-2000金币    二级 700-1000金币    三级 0-700金币 +``` + +注：天梯会公示在社区、优秀文章也会推荐到正式课全群。如有他人打赏，打赏的金币归作者所有 + +### 加入 Track 社区微信群 + +添加官方微信：**hackerxhz666** +，邀请您加入群聊。添加时请备注 ：Track-你的 Track 社区昵称。 + + +### 最后 + +欢迎各位白帽参与投稿，获取投稿活动咨询、投稿审核沟通等 可联系审核微信：**hackerxhz666** +，添加时请备注：track-你的社区用户名，另外所有最终解释权归 Track 社区官方所有。 + + diff --git a/doc/2026-06/【CVE-2026-55200】libssh2 RCE 漏洞（PoC 已公布）.md b/doc/2026-06/【CVE-2026-55200】libssh2 RCE 漏洞（PoC 已公布）.md new file mode 100644 index 00000000..1b839d69 --- /dev/null +++ b/doc/2026-06/【CVE-2026-55200】libssh2 RCE 漏洞（PoC 已公布）.md @@ -0,0 +1,256 @@ +# 【CVE-2026-55200】libssh2 RCE 漏洞（PoC 已公布） +原创 骨哥说事 + 骨哥说事 骨哥说事 2026-06-30 04:08 + +

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

# + +# + +****# 防走失：https://gugesay.com/ + +**不想错过任何消息？设置星标****↓ ↓ ↓** +# + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/hZj512NN8jlbXyV4tJfwXpicwdZ2gTB6XtwoqRvbaCy3UgU1Upgn094oibelRBGyMs5GgicFKNkW1f62QPCwGwKxA/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/TKdPSwEibsZhJ3XEyGicGFwgS6trricDwH50yicEKBmxYT8wWuEsokwwnbB6cH9Q5MibkXRZ6nBgYwOqjRSslMWsCC3iarRBDUjTEtg2SZa1q6yz8/640?wx_fmt=png&from=appmsg "") + +一个被标识为 **CVE‑2026‑55200** + 的关键内存安全漏洞影响了广泛使用的 **libssh2** + 库，并使系统暴露于潜在的远程代码执行风险之下。该漏洞源于 SSH 传输层在数据包长度值处理过程中缺乏适当的验证，使得攻击者能在特定条件下触发越界内存写入。 + +libssh2 普遍嵌入在自动化平台、开发工具、备份系统和基础设施管理软件中。由于其广泛的采用，其数据包处理逻辑中的缺陷可能对 Linux 服务器、云工作负载和嵌入式环境产生深远影响。 + +通过 CVE 项目和美国国家漏洞数据库 (NVD) 发布的公开漏洞记录将此问题归类为 **高风险至严重级别** +，主要原因是在某些部署场景中，它可以被远程通过网络触发，且无需事先进行身份验证。 +## 理解 libssh2 在现代基础设施中的作用 + +libssh2 是一个用 C 语言编写的客户端 SSH 实现库。该库并非像 OpenSSH 那样提供独立的 SSH 服务，而是设计为嵌入其他应用程序内部使用。 + +常见的用例包括： +- 自动化部署系统 + +- CI/CD 流水线 + +- 基础设施自动化工具 + +- 远程备份代理 + +- 网络设备管理软件 + +- 嵌入式 Linux 设备 + +许多程序依赖 libssh2 来执行任务，例如通过 SCP/SFTP 传输文件、执行远程命令或建立加密隧道。 + +由于该库直接处理 SSH 协议数据包，其传输层中的解析错误可能会暴露内存安全问题。 +## CVE‑2026‑55200 背后的漏洞 + + +安全公告和漏洞数据库将 **CVE‑2026‑55200** + 描述为 libssh2 的 SSH 传输层中的 **越界写入条件** +。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/TKdPSwEibsZiab0n7ICibfl8OenoEBmFNmr99a8sfwLrGF5v5zy5icopGVElbKwkHugONia9Fn45ILjA7ib6LH5bDEVukdV6AmP2LoDH16Mau435w/640?wx_fmt=png&from=appmsg "") + +该缺陷发生在处理入站 SSH 数据包期间。每个 SSH 数据包都包含一个长度字段，用于定义有效载荷的大小。正确的实现必须在分配内存或复制数据包内容之前，验证该值是否在预期范围内。 + +在受影响的 libssh2 版本中，数据包长度字段在用于内存操作之前可能未得到充分验证。在某些条件下，攻击者可以发送特制的数据包，从而导致内存破坏。 + +该风险模式的简化表示如下： +``` +uint32_t packet_length = read_packet_length();char *buffer = malloc(packet_length);memcpy(buffer, incoming_data, packet_length); +``` + +如果 packet_length + 由攻击者控制且未与合理的限制值进行比对验证，操作可能会尝试复制超出已分配内存边界的数据。 + +此类越界写入非常危险，因为它们可能破坏相邻的内存结构，最终可能导致进程崩溃，甚至在有利条件下导致受控的执行流程。 +## 此类漏洞为何危险 + +网络协议实现内部的内存破坏漏洞在历史上就与严重的安全后果相关联。 + +可能的结果包括： + +**拒绝服务** +：通过应用程序崩溃实现**堆破坏** +：破坏程序执行的稳定性**控制流操纵** +：在有利条件下可导致远程代码执行 + +CVE‑2026‑55200 的精确可利用性取决于几个因素： +- 编译器的保护机制 + +- 操作系统的缓解措施 + +- 宿主应用程序如何集成 libssh2 + +- 内存分配器的行为 + +由于利用技术在披露后往往会不断发展演进，安全研究人员通常将可远程触发的堆破坏漏洞视为高风险。 +## 攻击面与暴露场景 + + +![](https://mmbiz.qpic.cn/mmbiz_png/TKdPSwEibsZjiaKS4Ricgwt7lAhf9paHt7uwRP38Y6kJibVjg1WFq3TebqDj2MDr6CFZsh1k8hAMAib16PZjkNtcxdSxP2aT4Na0U9rCj0ywibNxk/640?wx_fmt=png&from=appmsg "") + +尽管 libssh2 本身不是服务器，但嵌入它的应用程序经常暴露 SSH 连接功能。 + +存在以下几种实际的攻击场景。 +### 攻破自动化系统 + +部署流水线经常使用 SSH 库来连接基础设施节点。如果运行 libssh2 的流水线组件与攻击者控制的主机通信，恶意数据包可能会触发该漏洞。 +### 客户端利用 + +当客户端应用程序连接到恶意的 SSH 服务器时，服务器可能会发送旨在利用数据包解析弱点的特制数据包。 +### 中间人注入 + +在攻击者可以拦截流量的环境中，恶意中间人可能在加密协商完全建立之前，将畸形数据包注入 SSH 会话。 +## 利用所需的条件 + +根据公开可用的漏洞记录，该攻击特征通常包括： + +
因素
描述
攻击向量
网络
所需权限
无
用户交互
在部分场景下无需
复杂度
低至中等（取决于环境）
+ +这些特征解释了为何此漏洞在漏洞数据库中获得了高严重性评分。 +## 受影响的 libssh2 版本 + +公开的漏洞公告报告称，该缺陷影响 **libssh2 1.11.1 及更早版本** +。 + +捆绑了这些版本的软件包也可能继承该漏洞。 + +通常分发 libssh2 的操作系统包括： +- Debian 系发行版 + +- Ubuntu 各版本 + +- SUSE Linux Enterprise + +- 其他 Linux 和类 Unix 环境 + +但是，暴露与否取决于处理 SSH 流量的应用程序是否实际使用了存在漏洞的库。 +## 检测存在漏洞的系统 + +漏洞管理的第一步是确定该库是否存在。 + +在 Debian 或 Ubuntu 系统上： + +dpkg -l | grep libssh2 + +在基于 RPM 的系统上： + +rpm -qa | grep libssh2 + +安全扫描工具也纳入了对此问题的检查。例如，Nessus 等漏洞扫描平台通过专门的检测插件引用了此问题。 +## 运行时的迹象 + +在某些情况下，利用尝试可能会产生可检测的信号。 + +示例包括： + +
信号
可能的含义
SSH 客户端突然崩溃
可能为恶意数据包处理所致
日志中的段错误
内存损坏
异常的数据包大小
特制的传输层有效载荷
+ +在主动调查期间，监控这些信号可以帮助事件响应人员。 +## 与其他 libssh2 漏洞的关系 + +CVE‑2026‑55200 与其他 libssh2 问题（包括 **CVE‑2026‑55199** +）一同披露，后者涉及影响同一库的另一个技术缺陷。 + +尽管这两个漏洞在技术上有所不同，但它们说明了网络库中的一个反复出现的主题：复杂的数据包解析逻辑与不充分的输入验证相结合。 + +当多个漏洞影响同一组件时，修补变得尤为紧迫，因为攻击者可能会串联这些弱点或选择最容易的利用路径。 +## 实用的缓解策略 + +缓解措施通常遵循分层方法。 +### 升级库文件 + +最直接的修复方法是安装漏洞披露后发布的、已打补丁的 libssh2 版本。 + +主要 Linux 发行版的软件包维护者通常会向后移植安全补丁到受支持的版本。 +### 限制网络暴露 + +不需要外部 SSH 连接的系统应强制执行防火墙限制。 +### 强化运行时保护 + +现代操作系统包含各种缓解技术，增加了利用难度： +- 地址空间布局随机化 + +- 栈保护 + +- 强化内存分配器 + +尽管这些机制不能消除漏洞，但它们通常会提高可靠利用的难度。 +## 防御性监控策略 + +防御者应将网络协议解析漏洞视为潜在的入侵途径。 + +推荐的监控技术包括： +- SSH 会话遥测 + +- 崩溃日志聚合 + +- 数据包大小的异常检测 + +- 漏洞扫描关联 + +将运行时监控与补丁管理相结合，可以降低新披露的漏洞在生产环境中仍然可被利用的可能性。 +## 关于 CVE‑2026‑55200 的常见问题 +### CVE‑2026‑55200 究竟是什么？ +- libssh2 库中的一个内存破坏漏洞。 + +- 通过畸形的 SSH 数据包处理触发。 + +- 在数据包处理期间可能导致越界写入。 + +### 哪些系统最可能受到影响？ +- 嵌入 libssh2 1.11.1 及更早版本的应用程序。 + +- 运行依赖该库的自动化工具的 Linux 服务器。 + +- 通过 libssh2 API 执行 SSH 连接的软件。 + +### OpenSSH 内部使用 libssh2 吗？ +- 不，OpenSSH 是 SSH 协议的独立实现。 + +- 仅运行 OpenSSH 的系统不会自动受到影响，除非另一个应用程序捆绑了 libssh2。 + +### 远程代码执行是否确定会发生？ +- 不一定。 + +- 内存破坏漏洞有时只会导致崩溃。 + +- 可利用性取决于内存布局、缓解措施和应用程序上下文。 + +### 管理员如何快速检查暴露情况？ +- 使用包管理器识别已安装的 libssh2 版本。 + +- 审查使用 SSH 功能的应用程序中的软件依赖项。 + +- 运行具有最新检测签名的漏洞扫描。 + +### 如果无法立即打补丁，最快的缓解措施是什么？ +- 将 SSH 连接限制在受信任的网络。 + +- 监控应用程序日志是否有崩溃。 + +- 应用临时的网络过滤规则。 + +### 嵌入式设备有风险吗？ +- 潜在的风险是存在的。 + +- 许多嵌入式系统使用像 libssh2 这样的轻量级 SSH 库。 + +- 如果包含了存在漏洞的版本，供应商必须发布固件更新。 + +## 结语视角 + +CVE‑2026‑55200 凸显了基础设施安全中一个反复出现的挑战：广泛使用的库悄然成为关键的攻击面。即使漏洞存在于依赖项深处，它也可能暴露整个自动化系统或基础设施流水线。 + +对于防御者而言，教训是明确的：跟踪依赖项、快速打补丁，并验证暴露情况，而不是假设安全。网络协议库中的内存破坏漏洞仍然是最危险的漏洞类别之一，尤其是当它们可以通过网络访问时。 + +原文： +https://www.penligent.ai/hackinglabs/cve-2026-55200/ + +- END - + +**感谢阅读，如果觉得还不错的话，动动手指给个三连吧～** + diff --git a/doc/2026-06/国安部预警：AR 手游采集 300 亿实景数据，民用地理数据存在军事化泄密风险 ；CNVD2026 第 25 期漏洞周报：零日漏洞占比超八成 牛览.md b/doc/2026-06/国安部预警：AR 手游采集 300 亿实景数据，民用地理数据存在军事化泄密风险 ；CNVD2026 第 25 期漏洞周报：零日漏洞占比超八成 牛览.md new file mode 100644 index 00000000..95861820 --- /dev/null +++ b/doc/2026-06/国安部预警：AR 手游采集 300 亿实景数据，民用地理数据存在军事化泄密风险 ；CNVD2026 第 25 期漏洞周报：零日漏洞占比超八成 牛览.md @@ -0,0 +1,278 @@ +# 国安部预警：AR 手游采集 300 亿实景数据，民用地理数据存在军事化泄密风险 ；CNVD2026 第 25 期漏洞周报：零日漏洞占比超八成 | 牛览 + 安全牛 2026-06-30 04:37 + +**点击蓝字 关注我们** + + + +![](https://mmbiz.qpic.cn/mmbiz_png/wKeDC5RjIzER2iaMYCN8JrnObkQ7fE8ApFibFtdpL7bvGLKaQPBMSHsibFOh2f5ACUqZ3LYS6ribbIUH9PU4tnibXUuwOF8YpmA9zQYbM8UpWGvs/640?wx_fmt=png&from=appmsg "") + + +新闻速览 + + +- CNVD2026 第 25 期漏洞周报：零日漏洞占比超八成，多款海外软件高危漏洞集中爆发 + + +- CNVD发布上周关注度较高的产品安全漏洞 + + +- 国安部预警：AR 手游采集 300 亿实景数据，民用地理数据存在军事化泄密风险 + + +- 美国最高法院裁定Geofence Warrants受第四修正案约束，手机位置数据隐私获强化保护 + + +- 美国悬赏1000万美元通缉UNC4221与UNC5792，指向俄罗斯黑客基础设施打击升级 + + +- 美国保险监管机构确认网络攻击事件影响，多州监管体系启动应急响应 + + +- 新型内核逃逸利用链曝光：恶意 IPv6 分片数据包突破容器隔离 + + +- Fortinet发布FortiSOC，以Agentic AI打造统一SOC平台 + + +- 美国参议院推出 AI AGENT 法案，FTC 将搭建 AI 智能体安全认证注册体系 + + +- 美国查封近400个世界杯盗播网站，警示恶意软件传播风险 + + + + +特别关注 + + +**CNVD2026 第 25 期漏洞周报：零日漏洞占比超八成，多款海外软件高危漏洞集中爆发** + +2026 年 6 月 22 日至 28 日，CNVD 发布本年度第 25 期漏洞周报，本周安全漏洞整体威胁评级为中，全网共收录漏洞 532 个，高危漏洞 337 个，漏洞平均分值 6.85；其中 0day 漏洞 464 个，占比高达 87%，出现 Textpattern CMS 文件上传、CouchCMS 跨站脚本等可直接攻击的零日漏洞。 + + +本周共收到党政、企事业单位事件型漏洞 3543 个，环比上周上涨 5%。漏洞类型以 WEB 应用为主，共计 322 个，其次为应用程序 112 个，网络设备、操作系统、工控系统漏洞均有收录。厂商维度，Adobe、WordPress、Google、H3C、Microsoft、Cisco 等产品均曝出漏洞，其余厂商漏洞合计占比 82%。 + + +本周多类海外主流软件集中披露高危漏洞：Microsoft Office、Excel、Hyper-V 存在代码执行、信息泄露漏洞；Google Chrome 存在堆溢出、沙箱逃逸风险；Cisco 多款协作、网管设备存在命令注入、XML 注入漏洞；Adobe 设计软件存在越界写入高危漏洞，上述厂商均已推送补丁。Textpattern CMS4.8.7 存在未修复文件上传漏洞，攻击者上传恶意 PHP 文件即可执行任意命令。 + + +安全机构提示，各单位及时升级微软、谷歌、思科、Adobe 产品补丁，使用 Textpattern CMS 的单位持续跟踪厂商修复公告，同步做好 WEB 应用、网络设备漏洞巡检处置。 + + +原文链接： + +https://www.cnvd.org.cn/webinfo/show/12516 + + +**CNVD发布上周关注度较高的产品安全漏洞** + +2026年6月22日至28日，全网披露多款境内外主流软硬件产品高危安全漏洞，覆盖办公软件、网络设备、操作系统、浏览器等常用品类，存在信息泄露、命令注入、代码执行、拒绝服务等多重风险，对企业及个人用户设备安全造成威胁。 + + +境外产品方面，Microsoft Excel接连曝出信息泄露（CNVD-2026-24917、CNVD-2026-24914）、代码执行（CNVD-2026-24916）漏洞，恶意攻击者可借此窃取敏感数据、执行任意系统代码。Cisco IMC存在命令注入漏洞，因输入验证缺陷，可被利用执行任意命令。Google Chrome Codecs组件存在堆缓冲区溢出漏洞，攻击者可构造恶意页面实现沙箱逃逸。 + + +境内产品漏洞同样频发。Tenda W15E路由器因参数校验缺失存在缓冲区溢出漏洞，可被触发拒绝服务攻击。Huawei HarmonyOS、EMUI存在多处授权漏洞，涉及权限管理缺陷，会引发设备功能异常、泄露服务机密。Zyxel多款路由器存在资源管理错误、认证后命令注入漏洞，可被发起Slowloris攻击、执行系统命令，设备运行安全风险较高。 + + +原文链接： + +https://www.cnvd.org.cn/webinfo/show/12521 + + + +热点观察 + + +**国安部预警：AR 手游采集 300 亿实景数据，民用地理数据存在军事化泄密风险** + +2026 年 6 月 29 日，国家安全部发布安全预警，外媒披露某知名 AR 手游关联 AI 公司累计收集用户近 300 亿份环境扫描数据，用于空间识别 AI 模型训练，该企业与境外军工存在合作，数据模型存在军事应用风险，凸显民用数据军事化带来的安全威胁。 + + +AR (增强现实) 游戏以实景互动为包装，依托多传感器采集三维点云、空间深度、物体尺寸，信息采集量远超普通拍照；用户常一键授权定位、相机权限，软件后台静默上传数据，采集行为隐蔽；每帧画面绑定高精度 GPS、海拔、时间戳，可完整还原空间轨迹。 + + +此类数据滥用存在三重风险：一是多源数据交叉比对可还原用户隐私，民众被动成为境外军事项目数据源；二是企业突破商业伦理，引发 AR、位置服务行业信任危机；三是海量地理数据可构建高精度三维国土模型，外泄后将形成关键军事情报，直接威胁国家安全。 + + +官方给出防护指引：安装 AR、地图类应用遵循最小必要权限原则，闲置时关闭后台；不在军工、港口、科研院所等敏感区域拍摄扫描；警惕以游戏测试、街景调研为名的数据采集兼职。 + + +公众发现非法测绘、窃取地理数据线索，可通过 12339 举报渠道上报。 + + +原文链接： + +https://mp.weixin.qq.com/s/Yw_yEUuyUB1g3dYL1H9J9w + + +**美国保险监管机构确认网络攻击事件影响，多州监管体系启动应急响应** + +美国保险监管机构近日确认发生一起影响行业系统的网络安全事件，该事件涉及第三方服务供应链及保险相关数据系统访问异常，引发对保险行业数据安全与监管机制的进一步关注。 + + +根据公开信息，此次事件由美国National Association of Insurance Commissioners（NAIC，美国全国保险监督官协会）相关系统被发现存在异常访问行为后触发调查。初步分析显示，攻击者可能通过供应链环节或外部服务接口获取了部分敏感数据访问权限，但目前尚未确认大规模核心保险理赔数据库被完全泄露。 + + +事件发生后，多州保险监管机构已联合启动应急响应机制，并要求相关保险公司审查自身系统安全状态，包括身份认证机制（IAM）、API访问控制以及第三方供应商风险管理流程。业内指出，保险行业长期依赖大量外包数据处理与云服务，使其成为典型的“高价值低防护一致性”攻击目标。 + + +技术层面分析认为，此类攻击往往利用credential stuffing（凭证填充攻击）、API滥用或供应链渗透方式实现初始突破，再通过横向移动获取更多系统权限。部分专家指出，事件暴露出保险行业在zero trust architecture（零信任架构）落地方面仍存在不足，尤其是在跨机构数据共享与访问控制粒度方面。 + + +监管机构强调，后续将进一步强化对保险行业网络安全合规要求，并推动统一的数据泄露通报机制，以减少类似事件对消费者隐私与金融稳定性的潜在影响。 + + +原文链接： + +https://www.infosecurity-magazine.com/news/us-insurance-regulator-confirms/ + + + +安全事件 + + +**美国最高法院裁定Geofence Warrants受第四修正案约束，手机位置数据隐私获强化保护** + +美国最高法院近日以6∶3裁定，在Chatrie v. United States案中认定，执法部门使用Geofence Warrants（地理围栏搜查令）获取手机位置历史数据属于《美国宪法》第四修正案意义上的“搜查”，必须符合第四修正案关于隐私保护和搜查令的要求。 + + +Geofence Warrants是一种数字取证手段，执法机构可要求Google等科技公司提供特定时间、特定区域内所有设备的位置数据，以筛选嫌疑人或证人。该技术因可能一次性收集大量无关人员信息，被隐私保护组织长期批评具有“拖网式搜查”特征。 + + +本案源于一起银行抢劫案。警方依据Google保存的Location History（位置历史）锁定Okello Chatrie，并最终完成定罪。政府主张，仅调取有限时间的位置记录，不应视为第四修正案意义上的搜查；但最高法院多数意见认为，用户对手机位置历史具有“合理隐私期待（reasonable expectation of privacy）”，即使相关数据保存在第三方科技公司，执法部门调取该数据仍构成搜查。法院同时否定了“用户自愿放弃隐私”的观点，指出智能手机和定位服务已成为现代生活的基础功能，用户并非真正主动放弃隐私。 + + +公开资料显示，仅约三分之一Google账户开启Location History，但涉及用户规模仍超过5亿。Google此前也承认，Geofence Warrants存在将大量无关用户纳入调查范围的风险。分析认为，该判决将对美国数字取证、电子证据获取及执法机构使用位置数据的合规流程产生深远影响，并进一步强化数字时代的隐私保护标准。 + + +原文链接： + +https://therecord.media/supreme-court-geofencing-ruling-fourth-amendment + + +**美国悬赏1000万美元通缉UNC4221与UNC5792，指向俄罗斯黑客基础设施打击升级** + +美国近日宣布对两名与俄罗斯相关的网络犯罪嫌疑人提供最高1000万美元悬赏，目标分别涉及被追踪为UNC4221与UNC5792的黑客活动集群。该悬赏由美国U.S. Secret Service（美国特勤局）推动，旨在获取能够识别或定位相关关键人员的信息，以打击持续针对全球关键基础设施与企业的网络攻击活动。 + + +根据安全机构分析，UNC4221与UNC5792被认为是与俄罗斯相关的高活跃威胁组织，长期从事包括勒索软件部署、凭证窃取以及对企业网络的渗透攻击。这些组织通常采用多阶段攻击链条，包括初始钓鱼邮件投递、漏洞利用进入内网、横向移动以及数据加密或窃取，并通过加密通信基础设施进行指挥控制（C2 communication）。 + + +美国方面指出，这些组织的活动已对能源、金融、医疗及政府机构构成持续威胁，部分攻击事件涉及大规模数据泄露与业务中断。悬赏计划属于“Rewards for Justice”或类似跨机构网络安全执法机制的一部分，强调通过国际合作与情报共享提升溯源能力。 + + +安全专家认为，此类高额悬赏不仅是执法手段，也是一种对黑产生态的战略性威慑，意在削弱黑客组织的人员稳定性与运营信任链。同时，这也反映出当前国家级网络对抗已从技术层面扩展至情报战与经济激励层面。 + + +原文链接： + +https://therecord.media/10million-reward-us-russian-hackers-unc4221-unc5792 + + +**美国查封近400个世界杯盗播网站，警示恶意软件传播风险** + +美国司法部（DOJ）宣布开展代号Operation Offsides的专项执法行动，查封近400个非法直播2026年FIFA世界杯赛事的互联网域名，旨在打击借赛事牟利的国际盗版网络，保护赛事版权和用户网络安全。此次行动由National Intellectual Property Rights Coordination Center联合Homeland Security Investigations（HSI）及多国执法机构共同实施，是美国历年来针对世界杯盗播规模最大的一次行动。 + + +据DOJ介绍，被查封网站未经授权实时转播世界杯比赛，相关域名由FIFA协助识别，beIN Media Group、NBCUniversal、Warner Bros.、Motion Picture Association旗下Alliance for Creativity and Entertainment（ACE）以及UFC等机构提供了调查支持。执法行动重点打击位于秘鲁和保加利亚的服务器及域名，并在克罗地亚、罗马尼亚、波兰和哥伦比亚同步开展协调行动。 + + +HSI指出，非法流媒体不仅侵犯版权，还可能成为网络攻击载体。此类网站通常存在恶意软件传播、不安全连接、信息窃取等风险，用户访问后可能导致个人信息和金融数据泄露。美国司法部表示，将继续追查盗播平台运营者，并联合国际执法和私营部门持续打击数字盗版活动，在维护知识产权的同时降低相关网络安全风险。 + + +原文链接： + +https://therecord.media/us-takes-down-hundreds-world-cup-streaming-sites + + + +安全攻防 + + +**新型内核逃逸利用链曝光：恶意 IPv6 分片数据包突破容器隔离** + +安全研究人员公开披露了名为IPV6_FRAG_ESCAPE的容器逃逸Proof of Concept（PoC），目标为RHEL10和CentOS环境。该PoC展示了攻击者如何利用IPv6分片（IPv6 Fragmentation）相关机制，从非特权（unprivileged）容器突破隔离边界，最终在宿主机上获得Root权限，进一步加剧了容器化基础设施的安全风险。 + + +根据披露信息，该PoC无需容器内Root权限，仅依赖普通容器权限即可发起攻击。其核心思路是利用Linux内核对IPv6分片数据包的处理逻辑，通过构造特定网络数据触发容器与宿主机之间的隔离缺陷，实现Container Escape，并在宿主机执行任意命令。研究人员已公开完整PoC代码，以帮助安全研究人员验证漏洞影响，但同时也意味着未及时加固的系统面临更高的被利用风险。 + + +此次披露再次表明，容器安全不仅依赖Namespace、cgroups等隔离机制，网络协议栈同样可能成为突破口。对于运行RHEL10、CentOS等平台的企业，建议及时关注相关安全更新，限制非必要IPv6功能，加强容器网络访问控制，并持续监测异常IPv6流量及容器逃逸行为，以降低潜在攻击风险。 + + +原文链接： + +https://securityonline.info/ipv6-frag-escape-container-escape-poc/ + + + +产业动态 + + +**美国参议院推出 AI AGENT 法案，FTC 将搭建 AI 智能体安全认证注册体系** + +2026 年 6 月 29 日，外媒 Cyberscoop 披露美国民主党参议员 Mark Warner 发布《AI AGENT Act》讨论草案，针对可自主代用户购物、发帖、修改账号的 AI 智能体建立联邦监管框架。 + + +法案要求月活超 5000 万的大型互联网平台，向用户开放至少一家通过联邦合规认证的 AI 智能体服务商。由 FTC 授权第三方机构开展资质审核，厂商需满足隐私、数据安全基础标准，纳入官方可信服务商名录；违规企业将被移出注册清单。 + + +法案明确两大核心安全约束：所有 AI 智能体必须绑定真人运营者身份，实现行为可追溯；内置权限管控机制，用户可随时授予、撤销 AI 代操作权限。当前 AI 智能体存在私自下单、泄露隐私、违背用户意愿执行操作等风险，且 AI 与 AI 自动交互场景增多，身份溯源与安全管控需求迫切。 + + +行业数据显示，23% 美国民众月度内使用 AI 完成采购，2030 年 AI 代理或将承载数千亿美元线上交易。同期美国政府同步推进大模型出口管制，Anthropic 旗下 Mythos 5、Fable 5 模型受限，行政令推出前沿模型自愿 30 天安全测试机制。 + + +该草案仅为征求意见稿，后续将调整完善后提交参议院审议。安全从业者提示，AI 智能体自主操作权限、身份绑定、权限回收三类机制将成为全球 AI 合规核心管控要点。 + + +原文链接： + +https://cyberscoop.com/ai-agent-act-senate-draft-bill-mark-warner/ + + + +新品发布 + + +**Fortinet发布FortiSOC，以Agentic AI打造统一SOC平台** + +Fortinet宣布推出统一安全运营中心（SOC）平台FortiSOC。该平台采用云交付（SaaS）模式，并引入Agentic AI，将六大安全运营能力整合至单一平台，帮助企业简化SOC建设，提升威胁检测、调查与响应效率。 + + +FortiSOC基于Fortinet现有SecOps技术构建，集成了安全信息与事件管理（SIEM）、安全编排自动化与响应（SOAR）、Threat Intelligence、身份威胁检测与响应（ITDR）、用户与实体行为分析（UEBA）以及Case Management等能力，实现统一的数据分析、告警关联和事件响应。平台融合FortiGuard Labs威胁情报，可自动关联资产、身份和安全事件，并借助Agentic AI自主完成告警调查、威胁分析，向分析人员推荐或执行响应措施，同时保留人工审核机制。 + + +Fortinet表示，FortiSOC采用统一控制台和单一订阅模式，可减少多工具部署和运维复杂度，降低SOC运营成本。平台内置数千个SOAR自动化Playbook，并支持与Fortinet及第三方安全产品双向集成，帮助企业实现跨网络、终端、云和身份环境的统一可视化与自动化响应。 + + +此外，Fortinet强调，现有FortiAnalyzer、FortiSIEM和FortiSOAR产品将继续独立提供和持续更新，而FortiSOC则作为统一云平台，为不同规模企业提供从基础SOC建设到高级安全运营的完整演进路径。 + + +原文链接： + +https://www.expresscomputer.in/news/fortinet-launches-fortisoc-a-unified-soc-platform-powered-by-agentic-ai/136369/ + + + + + + +**联系我们** + +合作电话：18610811242 + +合作微信：aqniu001 + +联系邮箱：bd@aqniu.com + + + + + + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/wKeDC5RjIzH8rJqB674leuOXFjXOOJRd34sOa14ZjY59E0B2yr9hryGhTxSBCMZqaLicRBVMPiacBs7KktJMuo0oia0bRdyb4gqpFexxAPspaU/640?wx_fmt=gif&from=appmsg "") + + diff --git a/doc/2026-06/微步 XGPT 发现 Apple 内核漏洞并获致谢.md b/doc/2026-06/微步 XGPT 发现 Apple 内核漏洞并获致谢.md new file mode 100644 index 00000000..27775279 --- /dev/null +++ b/doc/2026-06/微步 XGPT 发现 Apple 内核漏洞并获致谢.md @@ -0,0 +1,34 @@ +# 微步 XGPT 发现 Apple 内核漏洞并获致谢 +微步情报局 + 微步情报局 微步在线研究响应中心 2026-06-30 07:23 + +漏洞概况 + + +今天Apple官方发布  +Apple iOS、iPadOS、macOS + 26.5.2版，修复了WebKit、Kernel 等组件的多个漏洞。 +其中CVE-2026-43722由微步XGPT发现并报送Apple官方。 + +![](https://mmbiz.qpic.cn/mmbiz_png/T4OSm0sXdEOH9tDgfo5FUN2FdIlbaxbpAeH9XbLicWnEkAy08GGpKA251dMia7kYc1CqCUP8Ta9wlMju2DCKfTibb0xR2Ch76GsEXtrqzSIdC0/640?wx_fmt=png&from=appmsg "") + +该漏洞由于 +XNU Kernel 未验证 page_starts_offset 和 page_extras_offset，攻击者可利用此漏洞触发内核堆越界读，进而通过重定向链写入系统级共享区域页面。精心构造的攻击可能可以实现从非特权用户到 root 的本地权限提升。 +修复方案 + +### 官方修复方案 + +Apple 建议所有用户尽快通过设置 > 通用 > 软件更新进行升级。官方修复通告地址：： + +https://support.apple.com/en-us/127594 + +微步产品支撑 + + +微步漏洞情报于 +2026-06-29 +收录该漏洞。 + +微步下一代威胁情报平台NGTIP及X情报社区已于漏洞收录时向漏洞订阅用户推送该漏洞情报，并将持续推送后续更新；对于已经录入资产的用户，支持实时自动化排查受影响资产。 + + diff --git a/doc/2026-06/渗透测试从账号枚举到未授权访问，再到白盒RCE的一次渗透测试实录.md b/doc/2026-06/渗透测试从账号枚举到未授权访问，再到白盒RCE的一次渗透测试实录.md new file mode 100644 index 00000000..9eb69827 --- /dev/null +++ b/doc/2026-06/渗透测试从账号枚举到未授权访问，再到白盒RCE的一次渗透测试实录.md @@ -0,0 +1,361 @@ +# 渗透测试|从账号枚举到未授权访问，再到白盒RCE的一次渗透测试实录 + flower安全 2026-06-30 07:18 + +**本篇文章共 8000字，完全阅读全篇约10分钟 州弟学安全，只学有用的知识** + +一、前言 + +**大家好，我是州弟。** + +刚结束了陕西省丝绸之路网络安全论坛的分享，回到项目上继续干活。最近发现大家都在关注同一个问题：黑盒渗透测试的门槛越来越高，WAF、EDR、云原生防护层层叠加，传统的大范围扫描基本刚起手就被封禁。但反过来想，防御方堆叠的设备越多，开发和运维在代码层和业务层留下的疏漏往往就越隐蔽，也越有意思。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/mOj9kVLGEa1aibQrD2ib0YaZxGhIVBxg2fUKqiadJdMaPwy8ibhU7RZzdCcy2SOr7iaTuGUsFJH3E3hS9Nmxs7WfxGzIZSdqVtBia3esxBw0yROOA/640?wx_fmt=jpeg&from=appmsg "") + +回到正题。这次分享的是一个我们最近帮客户做的授权渗透测试项目。目标是一家企业，互联网暴露面不多，常规扫描基本捞不到什么明显的入口。但渗透测试这件事，很多时候不是看工具多先进，而是看能不能沉下心把有限的面梳理清楚，从一条小程序的接口里找到突破口，再从黑盒的线索过渡到白盒的源码审计，最终拿到服务器的权限。 + +整个流程走下来，我最大的感受是：黑盒和白盒从来不是割裂的。黑盒划定战场，白盒理解战场上的每一条战壕是怎么挖的。只有两边结合起来，你才能知道漏洞是怎么从一行不严谨的代码，一步步演变成可以远程执行命令的致命风险的。 + +**本文涉及的所有测试行为均在客户授权范围内进行，目标系统名称、域名、IP、数据均已脱敏，请勿在未授权环境下尝试。** +## 二、信息收集与目标定位 + +拿到目标后，照例先做信息收集。这家企业属于个企性质，没有复杂的下属单位或集团架构，所以不需要做股权穿透和关联资产梳理，直接进入到备案查询和资产测绘环节。 + +由于互联网侧的暴露面确实很少，没有成规模的Web站点，也没有开放的测试环境。我把主要精力放在了小程序上。现在越来越多的企业把核心业务逻辑放在微信小程序里，前端只是展示层，真正的数据交互全靠后端API。这种架构下，小程序的前端代码和后端接口往往是安全链条上最薄弱的环节。 + +![通过资产测绘工具定位到目标企业的小程序入口，互联网暴露面较少，小程序成为主要测试对象](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa3seKfz6jNlOPu442qnibNxKSc2DibIBIu1d8cjAFn3ggxkF54PclghYvsbqMRmJUjAbGKOQxRV1JdJ1PsOfphaXicKYUUBp16V6U/640?wx_fmt=png&from=appmsg "") + +通过资产测绘工具定位到目标企业的小程序入口，互联网暴露面较少，小程序成为主要测试对象 + +这里顺带提一个知识点。很多师傅在渗透测试初期容易陷入一个误区，就是拿到目标后急着上扫描器，恨不得半小时内出结果。但对于暴露面少的目标，扫描器能覆盖的范围非常有限，反而容易触发封禁。我的习惯是先做人工的资产梳理，把域名、备案、小程序、公众号、App、云存储桶这些面全部列出来，再判断哪个面的概率最高。这次的小程序就是经过这样的筛选后才确定为首要目标的。 +## 三、黑盒测试阶段 +### 3.1 账号枚举 + +**危害等级：中危** + +打开小程序后，首先映入眼帘的是一个登录页面。没有注册入口，也没有找回密码的明显按钮，这意味着所有用户账号都是后台预置的。面对这种封闭系统，我的第一个念头是：先试试账号枚举，看看能不能区分出"账号不存在"和"密码错误"这两种响应。 + +![小程序登录入口，无注册功能，属于预置账号的封闭系统](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa0KujuVkY8dXicZuHWdThaicib6J84PT9gHDuuJ0Qx0DRCxA73HHHWrkarfiaEz5mxUP38M4TrF84gxjrEgGFjcBkwsq7pIkrCp2Ls/640?wx_fmt=png&from=appmsg "") + +小程序登录入口，无注册功能，属于预置账号的封闭系统 + +我先用 admin + 作为账号，随意输入一个密码提交。后端返回的响应是"账号或密码错误"。接着我换了一个明显不存在的账号 admin1 +，再次提交。这次后端返回的却是"系统异常"。 + +![账号存在但密码错误时，后端返回"账号或密码错误"](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa3rPzbaO0UxqmBYb8qIpwfnYolszBOFas7kWnHR2rS26HwAgDXhVgC8SrlDweNTD0Lmkk9Ol45HaEMFBnT3guywyv7YicSXG7YI/640?wx_fmt=png&from=appmsg "") + +账号存在但密码错误时，后端返回"账号或密码错误" + +![账号不存在时，后端返回"系统异常"，与账号存在时的响应不同](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa1c63czU2ZfgiaGqubVYiaqVlEf867hhLLrLAOyv2CKPLhTsvp207Wt9QhJehNqApMOvjo1YKibcxz0iaxW0hAyeL5eJJFZ5rPlgPM/640?wx_fmt=png&from=appmsg "") + +账号不存在时，后端返回"系统异常"，与账号存在时的响应不同 + +两种截然不同的错误提示，说明后端在账号校验和密码校验的环节没有统一异常处理。账号存在时走到密码比对逻辑，返回密码错误；账号不存在时直接抛出空指针或数据库查询异常，被全局异常拦截器捕获后返回系统异常。这个差异虽然本身不能直接造成数据泄露，但它为后续的暴力破解提供了精准的账号字典。 + +**修复建议** +：统一登录失败的响应文案，无论账号是否存在、密码是否正确，均返回"账号或密码错误"。同时建议在登录接口增加速率限制，同一IP或同一账号在短时间内连续失败多次后触发图形验证码或临时锁定。 +### 3.2 未授权访问 + +**危害等级：高危** + +接下来我尝试对小程序进行反编译，提取前端源码中的API接口。这里用到了 TscanPlus 的反编译功能，直接把小程序包解开，提取出所有的后端接口路径。 + +![通过 TscanPlus 反编译小程序，提取出大量后端 API 路由路径，为后续接口测试提供目标](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa07mafibjNrDfWO1Lew2QpAUm77b4cVnPHsKSuSYsPYn1YDEp2AyKROcFhR3hbW5ObTV9licrXaOfZhrNeIkpGLK3LyZX5iaaagOg/640?wx_fmt=png&from=appmsg "") + +通过 TscanPlus 反编译小程序，提取出大量后端 API 路由路径，为后续接口测试提供目标 + +拿到接口列表后，我用 BurpSuite 对这些接口做了批量 Fuzz。结果发现一个比较严重的问题：接近一半的接口在没有携带任何 Cookie、Token 或鉴权参数的情况下，直接返回了敏感数据。这些数据包括员工工资发放记录、用户ID、手机号等。 + +![未携带任何凭证直接访问某接口，后端返回了包含员工信息数据列表](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa1XERHZd46g7NsjXVdKnrJwpQ4JibaUxWR0DkUeg5gnrTvEb6GcNtIDpyDmCxjvf3jGic4umuuQzE1q3BHMhTv8v92L6DOrm6TK0/640?wx_fmt=png&from=appmsg "") + +未携带任何凭证直接访问某接口，后端返回了包含员工信息数据列表 + +![未携带任何凭证直接访问某接口，后端返回了包含工资信息的敏感数据列表](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa2SWLtKKs8dibVfMY2Sm2gwtaibNyIZiaExRKyzVMHbWz2HoEevA2AKmmO28Q7iaicb4X5SiadTosghvOb73icAdhorgnfIuONeiapdAbU/640?wx_fmt=png&from=appmsg "") + +未携带任何凭证直接访问某接口，后端返回了包含工资信息的敏感数据列表 + +这说明后端在接口设计上完全没有做身份校验。很多开发者在写小程序接口时，默认前端小程序是"自己人"，不会有人直接调用后端接口，于是省去了鉴权环节。但实际情况是，小程序的前端代码对攻击者来说是完全透明的，反编译之后所有接口都暴露无遗。 + +**修复建议** +：所有涉及敏感数据的接口必须接入统一的鉴权中间件，校验请求中携带的 Token 或 Session 是否有效，并确认该用户是否有权限访问当前资源。禁止基于前端隐藏或 obscurity 的访问控制。 +### 3.3 登录鉴权绕过 + +**危害等级：高危** + +未授权访问已经能拿到不少数据，但我心里清楚，真正的危害在于能不能拿到一个合法身份，进入系统内部做更深层的操作。于是我把注意力转回登录接口。 + +在测试登录的过程中，我注意到响应体里有一个 status + 字段。前面测试账号枚举时已经看到，无论是账号不存在还是密码错误，这个 status + 的值都是 1 +。这让我产生了一个想法：如果我在客户端把响应拦截下来，把 status + 改成 0 +，会发生什么？ + +![正常登录失败时，响应体中 status 字段值为 1，前端据此判断登录失败](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa2ia2XW82OJJTcvL26kN30gZzM4MMwcOYials5jRjVicA4hoFfibs8InolBvNaxLtNrEqemjyQ7UwrKMLC2Z35r8HuticHQ2n1mMRmw/640?wx_fmt=png&from=appmsg "") + +正常登录失败时，响应体中 status 字段值为 1，前端据此判断登录失败 + +我用 BurpSuite 拦截了登录失败的响应包，把 status + 从 1 + 改为 0 +，然后放行。 + +![通过 BurpSuite 拦截响应，将 status 字段修改为 0 后放行](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa3FAnbwPtfpChibadPfMqfGJFJ9VXdp9cyEibdzzCyUhhKiabyDXmZR4pfVIwUICiaKyLOmRwpvRiazn6OkS7orHqvwIywQib8jIQG6U/640?wx_fmt=png&from=appmsg "") + +通过 BurpSuite 拦截响应，将 status 字段修改为 0 后放行 + +结果出乎意料。前端收到 status=0 + 后，直接认为登录成功，跳转进了小程序的主界面。虽然后端并没有返回任何 Cookie、Token 或 SessionID，但前端的所有功能模块都已经对我开放了。我可以正常浏览、操作、提交数据。 + +![前端仅依据 status 字段判断登录状态，修改后成功绕过登录限制进入系统](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa0cqrm2oomOMyd2W9F3oqspEOSiafrN9xfF5GriaTAEIenI8FyzvKKJBL1FN06rRC9WCb4hcECl8ydicXYUQdU2nWkIKcEvqXXVF4/640?wx_fmt=png&from=appmsg "") + +前端仅依据 status 字段判断登录状态，修改后成功绕过登录限制进入系统 + +进去之后我随手点了点工资管理模块，发现增删改查全部可以操作。 + +![绕过登录后，可直接对工资数据进行增删改查操作，业务权限未做后端校验](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa0nicBN2hjkK9pJaP6n4u0zRX5m5icRqp0D2joOg9jgn3yIRfgQUSWtRYpQeT93s9jicz0I44W5XbDrF4zdbAqAeW1fjjm5xn21lY/640?wx_fmt=png&from=appmsg "") + +绕过登录后，可直接对工资数据进行增删改查操作，业务权限未做后端校验 + +更离谱的是，我在个人设置里看到了修改密码的功能，而这个功能居然不需要输入原密码，直接输入新密码就能提交成功。 + +![系统提供的修改密码功能未要求输入原密码，存在严重的逻辑缺陷](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa2Pt8icsfpyPu0pOgEJyZW4jAecJqXvbXfV6lj8brIKZpdnMibwbMdsbm6tNGmLhI1NJbkNliaOE4EQDkdu58SLPzjvYwlicvrxLfc/640?wx_fmt=png&from=appmsg "") + +系统提供的修改密码功能未要求输入原密码，存在严重的逻辑缺陷 + +这个发现让我停下来想了一下。前端校验绕过在很多系统里都存在，但通常后端还会再做一次校验。而这个系统的问题在于，前端把 status + 作为唯一的状态标识，后端则完全依赖前端传递的状态，或者根本没有在后续请求中校验用户身份。这种前后端信任链的断裂，是典型的逻辑漏洞。 + +**修复建议** +：登录状态必须由后端生成并维护，通过 HTTP Only Cookie 或安全的 Token 机制下发给前端。前端可以缓存状态以提升体验，但每一个涉及敏感操作的接口都必须独立校验后端凭证。修改密码等高危操作必须强制验证原密码或二次身份验证。 +### 3.4 根目录的意外发现 + +黑盒测试到这里，逻辑漏洞已经挖得差不多了。但我心里一直有个念头：能不能再进一步，拿到服务器权限？小程序是黑盒，看不到后端架构，也没有明显的上传点或框架特征。我试着访问了一下域名的根路径，想看看有没有目录遍历或者默认页面暴露信息。 + +结果让我愣了一下。根目录居然可以直接访问，而且里面放着一个源码压缩包。 + +![访问目标域名根路径，发现可直接列目录，且存在完整的源码压缩包](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa0BJX7VAsL6EeiakQ1JBZVkpxG8bWgOeicWlkQA9Aq1Yf1bJEOVciayAUJguoLPDmNgylLgNq4VIg15xChqZ8xbv9jjCz57TIespA/640?wx_fmt=png&from=appmsg "") + +访问目标域名根路径，发现可直接列目录，且存在完整的源码压缩包 code.rar + +这里需要解释一个细节。我们平时访问小程序，请求的 URL 通常是 http://target.com/API/xxx/xxxlist + 这种形式，很少会有人去访问 http://target.com/ + 这个根路径。开发者和运维也往往会忽略对根目录的权限管控，认为"反正用户不会访问这里"。但渗透测试恰恰需要这种"非常规"的访问习惯，把每一级目录都递归访问一遍，很多时候会有意外收获。 + +拿到源码压缩包后，整个项目的性质就从黑盒变成了白盒。我知道后端是 .NET 技术栈，WebAPI 架构，SQL Server 数据库。接下来的工作就是反编译和代码审计。 +## 四、白盒代码审计阶段 +### 4.1 反编译与审计思路 + +下载源码压缩包后解压，发现里面主要是 bin/ + 目录下的 DLL 文件。这说明下载的是编译后的发布包，而不是原始工程文件。对于 .NET 程序来说，这不算太大的障碍，因为 dnSpy 可以很好地反编译 IL 代码，还原出接近原始的 C# 源码。 + +![源码压缩包内为 .NET 编译后的发布文件，核心逻辑集中在多个 DLL 中](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa1eBY6ibT76Q1Zeicib5HAgia4HtfIS7frbrAibk3X358gWDn6icCZA3G2UqicDk6iaqZ3Kd71pI27AsRJMSbtV0fbUjnahIcRfBOOI7Ps/640?wx_fmt=png&from=appmsg "") + +源码压缩包内为 .NET 编译后的发布文件，核心逻辑集中在多个 DLL 中 + +![将 dnSpy 和源码包放在同一目录下，准备对 DLL 进行批量反编译分析](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa0tdwztzbYCVPGDibBowqkKH2ibsxCSm1kbzBjU6qUQ72Fx0PWWrDUAXONQdDZzJceyuDFjuqysvE8xOg5YiaP1ic4aAxeiavZpjfCs/640?wx_fmt=png&from=appmsg "") + +将 dnSpy 和源码包放在同一目录下，准备对 DLL 进行批量反编译分析 + +在开始审计之前，我先用 AI 辅助做了一个审计规划。这里我把提示词贴出来，供有类似需求的师傅参考。这个提示词的核心思路是：不给大模型过于死板的任务清单，而是让它自主规划审计路径，同时明确漏洞类型和输出要求，避免遗漏。 +``` +你现在是一名具有非常丰富的代码审计工程师，你接下来需要按照如下进行代码审计：1. 当前目录下的 code.rar 你需要进行解压到一个目录中，先了解其文件目录层级、语言等；2. 自主进行规划，使用当前目录下的 dnspy 工具对所有 dll 文件进行反编译处理；3. 确认所有文件反编译成功后，可以开启多个 agent 进行全量代码审计，审计漏洞范围包括不限于：   水平越权、垂直越权、IDOR、强制浏览、CORS 配置错误、   SQL 注入、NoSQL 注入、OS 命令注入、LDAP 注入、XPath 注入、表达式注入、模板注入、CRLF 注入、日志注入、   暴力破解、凭证填充、弱口令、会话固定、密码重置缺陷、MFA 绕过、JWT 漏洞、硬编码凭证、   自动更新无签名、反序列化、依赖篡改、CI/CD 完整性缺失、   错误信息泄露、Fail-Open、空指针、资源耗尽、SSRF 等漏洞；4. 在代码审计完毕后需要对其进行测试验证，目标地址为：http://xxxx.com/，确定漏洞存在之后再输出对应报告；5. 报告需要包含：存在问题的文件、对应代码问题、测试 POC 以及修复建议等。 +``` + +这里多说一句。有些师傅觉得给 AI 列太多漏洞类型会限制它的发挥，但我实际用下来的感受是：如果你不给示例，AI 在审计过程中确实会出现遗漏。比如它可能扫完了 SQL 注入和越权，但完全没提文件上传。这不是 AI 能力问题，而是上下文窗口和注意力分配的问题。所以我的做法是：先给一份全面的漏洞类型清单让 AI 做第一轮扫描，然后再针对特定类型做第二轮深度追问。这样两轮下来，覆盖率会高很多。 + +反编译完成后，我得到了接近 400 个 C# 源文件。接下来进入正式的漏洞分析。 + +注：以下代码审计过程我将大模型审计完毕且成功利用的结果以手工图示的方式进行展示 +### 4.2 任意文件上传至 RCE + +**危害等级：严重** + +在反编译后的 CommonController.cs + 中，定位到了一个全局文件上传方法 FileUpload +。这个方法的参数签名是： +``` +public Task FileUpload(string Filetype, string Type, string ID) +``` + +从代码逻辑看，它支持两种文件类型：Filetype=0 + 代表图片上传，Filetype=1 + 代表视频上传。上传的图片会被保存到 Upload/Photo/日期/ + 目录下，视频则保存到 Upload/Video/日期/ + 目录下。 + +![CommonController.cs 中的 FileUpload 方法，根据 Filetype 参数决定保存目录为 Photo 或 Video](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa2UNLNibUFLic65fOzIepg3QrO6THqA22Xg4NlTAK47QCTmutXlh5vgsAJKWWGI02GAmmKjsmfQCS0RxSqyHCPXaas3r6VaBOYY8/640?wx_fmt=png&from=appmsg "") + +CommonController.cs 中的 FileUpload 方法，根据 Filetype 参数决定保存目录为 Photo 或 Video + +继续往下读代码，这里发现了一个非常典型的逻辑分支遗漏。当 Filetype=0 +（图片模式）时，后端对文件扩展名做了白名单校验，只允许 gif、jpg、jpeg、png、bmp + 这几种格式。 + +![Filetype=0 时，后端对文件扩展名进行白名单校验，仅允许常见图片格式](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa1Q5Rpu7wKneYeknhnpY1UqJLRHNrA6DZ8P9piakGhKd6iaZ86ZlqPCctkL3oxzhbgz26FkG1I2EYib7Pr399ia1SKrWdLv0RDMH08/640?wx_fmt=png&from=appmsg "") + +Filetype=0 时，后端对文件扩展名进行白名单校验，仅允许常见图片格式 + +但当 Filetype=1 +（视频模式）时，代码直接进入了 else + 分支，没有任何扩展名校验，只是生成一个随机 GUID 作为文件名，然后直接调用 fileinfo.CopyTo() + 保存到 Upload/Video/ + 目录下。 + +![Filetype=1 时，代码直接保存文件，未对扩展名进行任何白名单或黑名单校验](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa1ZbVkHRlcZPjDqk3T8oFLpdxxOxRLJOibibwNpt5xOFPH6CAWq9qtTRDDoFMOGD2y3zQLzVcDibuBYc9Rq97o5tJITeqsV5LUQxI/640?wx_fmt=png&from=appmsg "") + +Filetype=1 时，代码直接保存文件，未对扩展名进行任何白名单或黑名单校验 + +这个发现可以意识到，这是一个典型的"白名单绕过"场景，但绕过的方式不是构造特殊文件名，而是直接利用业务逻辑的分支差异。开发者可能认为"视频上传"和"图片上传"是两个完全不同的业务场景，视频不会被浏览器解析，所以不需要做严格的类型校验。但他忽略了一个关键点：IIS 服务器上，.aspx + 文件无论放在哪个目录下，只要处于 Web 根目录内，都会被 ASP.NET 引擎解析执行。 + +于是构造 POC。通过 Filetype=1 + 触发视频上传分支，上传一个 .aspx + 的 WebShell： +``` +POST /api/Common/FileUpload?Filetype=1&Type=0&ID=1 HTTP/1.1Host: targetContent-Type: multipart/form-data; boundary=X--XContent-Disposition: form-data; name="file"; filename="shell.aspx"Content-Type: application/octet-stream<%@ Page Language="C#" %><% System.Diagnostics.Process p=new System.Diagnostics.Process();p.StartInfo.FileName="cmd.exe";p.StartInfo.Arguments="/c "+Request["cmd"];p.StartInfo.UseShellExecute=false;p.StartInfo.RedirectStandardOutput=true;p.Start();Response.Write(p.StandardOutput.ReadToEnd());p.WaitForExit();%>--X-- +``` + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa3u0fOB5x08ibWCX3WS6thgsFMIicgc7QiciaiaWW772ia1pzYT65WKEo89LPXMJNhnVyfEAs2sDIGoK1ZCq7SeJ9guweoXgLIdsS9B8/640?wx_fmt=png&from=appmsg "") + +通过 Filetype=1 分支上传 shell.aspx，后端返回上传成功，文件已保存至 Video 目录 + +上传成功后，直接访问返回的文件路径，执行 ping + 命令发现可以出网： + +![通过浏览器访问上传的 aspx 文件并传入 cmd 参数，成功执行 ping](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa0pDhjHmjtIh3tVWXUZlIfBB3MotQ2WAoG6BQDdAo73VONLHmkzHD9JtD6UWEo2cnrMYoS5mTcepcjDTZy23H1o2MibCeroe3lE/640?wx_fmt=png&from=appmsg "") + +通过浏览器访问上传的 aspx 文件并传入 cmd 参数，成功执行 ping + +拿到 Shell 权限的那一刻，当时非常兴奋，过后反而冷静了下来，思考一下这个漏洞的典型之处：一个 if-else + 分支里，前半段有校验，后半段完全放开。这种漏洞在代码审计中非常常见，但黑盒测试几乎不可能发现，因为你不知道后端有两个分支，也不知道视频上传接口会接受什么文件。这就是白盒审计的价值所在。 + +**修复建议** +：所有文件上传接口必须统一进行扩展名白名单校验，且白名单应由安全配置中心统一下发，不允许各业务分支自行决定是否校验。同时，上传目录应设置为不可执行权限，或者将用户上传的文件存储在 Web 根目录之外，通过专门的文件服务（如 OSS、CDN）进行访问，避免上传文件被解析执行。 +### 4.3 SQL 注入 + +**危害等级：严重** + +拿到源码后，SQL 注入是重点关注的方向。在 .NET 项目中，SQL 注入的排查有一个相对固定的模式：先找 DAL 层（数据访问层），看有没有直接拼接 SQL 字符串的方法，再往上追溯到 Controller 层，看用户输入是怎么流进这些方法的。 + +在 GSDsystem.DAL + 命名空间下搜索 DbHelperSQL +，很快发现了一个高危模式：GetSelectList(string strWhere) + 这个方法在多个 DAL 类中重复出现，它的内部实现都是把 strWhere + 参数直接拼接到 SQL 语句的 WHERE + 子句中，没有任何参数化处理。 + +![Sys_User.cs 中的 GetSelectList 方法，将传入的 strWhere 直接拼接到 SQL 字符串中，未使用 SqlParameter](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa1CNhbz1QVQFGYfK8NriceicSVrbAkPjN9EDGWq5aAff88g1ictXibubiawvN0yIsCib0GP2VSnoCKsbUc6p5V16ibQgrtKvzULsxFmQM/640?wx_fmt=png&from=appmsg "") + +Sys_User.cs 中的 GetSelectList 方法，将传入的 strWhere 直接拼接到 SQL 字符串中，未使用 SqlParameter + +进一步全局搜索 GetSelectList +，发现基于这个方法的查询调用在项目中普遍存在，无一例外都是直接拼接 WHERE + 语句。 + +![项目中大量 Controller 调用 GetSelectList，且均传入用户可控的参数构造 strWhere](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa2TjdN24NZkGREuQ4ojeSB26eYHeEPF2oZ8hVYuy9gE5eibLWqgXpAFYhGZ6zfenEEyFIgEubo1bONT52ic4ia7JGaZNiaRn3XRR7A/640?wx_fmt=png&from=appmsg "") + +项目中大量 Controller 调用 GetSelectList，且均传入用户可控的参数构造 strWhere + +既然 DAL 层是危险方法，下一步就是往 Controller 层追溯，看谁调用了它，以及调用时传入的 strWhere + 是怎么构造的。以 CommonController.GetWareHouseList + 为例： +``` +string GUID = obj.GUID;string Where = " GUID='" + GUID + "'";DataSet dsData = new GSDsystem.DAL.tb_WareHouses().GetSelectList(Where); +``` + +obj.GUID + 来自前端 POST 的 JSON 数据，没有任何过滤或类型校验，直接拼进了 SQL 条件。完整的攻击链路如下： +``` +用户 POST JSON {"GUID":"evil"}  → obj.GUID 取值（无过滤）  → 拼入 Where = " GUID='" + GUID + "'"  → 传参 GetSelectList(Where)  → DAL 层拼成 "select ... from tb_WareHouses where GUID='evil'"  → DbHelperSQL.Query() 执行  → SQL 注入 +``` + +![CommonController.cs 中直接拼接用户传入的 GUID 参数，传入 DAL 层的危险方法](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa1icOPy7bovEQurV9AjgoIibUSuJeSIicRTY9b1KdkXcTp7ZlwGBHDuVp50dAQ2dar8RggRnWqMm1DRmtsia4PRiceEiaia8JBHwulbd4/640?wx_fmt=png&from=appmsg "") + +CommonController.cs 中直接拼接用户传入的 GUID 参数，传入 DAL 层的危险方法 + +接下来需要确认接口的 URL 路径。打开 WebApiConfig.cs +，可以看到项目使用了标准的 ASP.NET WebAPI 路由模板： + +![路由模板为 api/{controller}/{action}/{id}，因此 CommonController.GetWareHouseList 对应 /api/Common/GetWareHouseList](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa36UZb5VHIcZtxUoNOEAdexXa3hBoClB1GKLYEflaeVia40wCicIruI780k84lYnYgpI9eVICKbq1VGrmePH61KzHbqsUlWL2Tmc/640?wx_fmt=png&from=appmsg "") + +路由模板为 api/{controller}/{action}/{id}，因此 CommonController.GetWareHouseList 对应 /api/Common/GetWareHouseList + +根据路由规则，CommonController.GetWareHouseList + 对应的访问路径就是 POST /api/Common/GetWareHouseList +。构造时间盲注 POC： +``` +POST /api/Common/GetWareHouseList HTTP/1.1Host: target.comContent-Type: application/json{"GUID":"1'; WAITFOR DELAY '0:0:5'--"} +``` + +![通过构造时间盲注 Payload，成功触发 5 秒延迟，确认 SQL 注入漏洞存在](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa0T1rODsUcCSZmC6WHPL9zIBO8A470gN23pUT9uDcYyeKgaXUjNTm9AlZYMn7nGkpKkwueicIbzoEbxMRy2tpWapx3MUANIcv5E/640?wx_fmt=png&from=appmsg "") + +通过构造时间盲注 Payload，成功触发 5 秒延迟，确认 SQL 注入漏洞存在 + +实际上，经过完整的代码审计，可以发现项目中基于 GetSelectList +、GetListExpand +、GetRecordCount + 等危险方法的 SQL 注入点共有 11 处，分布在 CommonController +、WechatController + 和 PDAClientController + 中。这些注入点全部可以线上验证，且数据库为 SQL Server，支持 WAITFOR DELAY + 时间盲注和 xp_cmdshell + 等高级利用。 + +**修复建议** +：立即对所有 DAL 层的方法进行参数化查询改造，使用 SqlParameter + 传递所有用户输入，禁止任何形式的字符串拼接构造 SQL。对于遗留的 strWhere + 模式，应逐步废弃，改为强类型的查询对象或 ORM 框架（如 Entity Framework、Dapper）的参数化查询方式。 +### 4.4 硬编码密钥与数据库凭证 + +**危害等级：高危** + +在审计过程中，还做了另一个方向的排查：硬编码敏感信息。很多开发者在代码中习惯把密钥、连接串、私钥直接写死在常量里，认为编译成 DLL 后就没人能看到了。但反编译工具可以非常轻松地还原这些字符串。 + +全局搜索 PRIKEY +，在 AppConstants.cs + 中直接拿到了 RSA 2048 位的私钥，以及支付接口的 APPID + 和 CUSID +。 + +![反编译后可直接查看 AppConstants.cs 中的明文私钥和支付接口配置信息](https://mmbiz.qpic.cn/sz_mmbiz_png/mOj9kVLGEa0gp0cq0KMrO3rq3QiaSuSXuN34puCmK2YXPVJT4UzTu7vPV1VKcJDWguuHBIFZg4Yeasr2zzg7Ny0x9c4qaduiazPgkiaXqgKOsM/640?wx_fmt=png&from=appmsg "") + +反编译后可直接查看 AppConstants.cs 中的明文私钥和支付接口配置信息 + +继续搜索数据库连接串，在 PubConstant.cs + 中找到了经过 DES 加密的数据库连接串，但加密密钥也是硬编码的 GSDsystem +。用同样的密钥解密后，直接拿到了数据库的 IP、库名、账号和密码。 + +![数据库连接串使用 DES 加密，但密钥硬编码在代码中，解密后可获取完整的数据库访问凭证](https://mmbiz.qpic.cn/mmbiz_png/mOj9kVLGEa2Ze5UKhOSXTLdNDtogVl3M43UGja6aUyFPrrpjvFZkSxSRJOte23qQ0MwglXvsND7bbiccQOXEf7k3Va5PDmtJ8L22fEW1kdicg/640?wx_fmt=png&from=appmsg "") + +数据库连接串使用 DES 加密，但密钥硬编码在代码中，解密后可获取完整的数据库访问凭证 + +这里需要强调一个认知误区。有些开发者觉得"我加密了连接串，所以是安全的"。但问题在于，密钥和密文放在同一个文件里，反编译后攻击者可以同时拿到两者，加密就形同虚设。正确的做法是把密钥放在独立的密钥管理服务（KMS）或硬件安全模块（HSM）中，应用程序运行时通过受控的 API 获取，而不是把密钥和密文绑在一起分发。 + +**修复建议** +：所有密钥、连接串、私钥等敏感信息必须从代码中移除，迁移到环境变量、配置中心或 KMS 中。代码仓库中不应出现任何生产环境的凭证信息。对于已泄露的密钥，应立即轮换。 +## 五、修复建议汇总 + +把这次审计发现的问题归类后，我们给客户提交了一份修复优先级清单： + +
优先级
漏洞类型
修复要点
P0
任意文件上传致 RCE
统一上传白名单；上传目录设置为不可执行；建议使用独立文件存储服务
P0
SQL 注入（11处）
全面参数化查询改造；废弃 strWhere 拼接模式；引入 ORM 或参数化封装
P1
硬编码密钥与凭证
迁移至 KMS/环境变量；立即轮换已泄露密钥
P1
登录鉴权绕过
后端统一维护登录状态；所有敏感接口独立校验 Token
P2
未授权访问
所有接口接入统一鉴权中间件；敏感数据接口增加权限校验
P2
账号枚举
统一登录失败响应文案；增加登录速率限制和图形验证码
P2
修改密码无原密码校验
强制原密码验证；增加操作日志审计
+## 六、总结与思考 + +这次渗透测试从黑盒到白盒，最终拿到 RCE，整个过程其实没有用什么高深的技术，更多的是耐心和逻辑推演。我想分享几点个人的感受，供正在学习渗透测试的师傅参考。 + +**第一，黑盒和白盒要结合起来看。** + 黑盒测试帮你快速定位系统的薄弱环节，比如未授权接口、逻辑绕过；但如果你想理解漏洞的根因，必须回到代码里。这次如果只做黑盒，我可能只能提交几个中高危的逻辑漏洞，止步于"修改密码不用原密码"这种层面。但拿到源码后，我才看到文件上传分支的遗漏、SQL 注入的架构性设计缺陷、硬编码的密钥。这些才是真正的致命伤。 + +**第二，AI确实已经在改变我们的工作方式。** + 这次审计从反编译到漏洞扫描，再到部分 POC 的验证，AI 都帮了大忙，效率比纯人工提升了不止一个量级。但我越来越觉得，越是在这种时候，越要保持清醒。AI 可以帮你快速覆盖代码、生成 Payload，但它对业务逻辑的理解是片面的，对真实环境的判断是有盲区的。所以我的习惯是：AI 输出的每一个高危结论，都必须经过人工复核和二次验证，特别是在交付客户之前，绝不能把 AI 的初筛结果直接当成最终报告。另外，在写提示词的时候，一定要给 AI 划定明确的边界，禁止它执行 **rm、drop** + 这类破坏性操作，任何涉及写盘、删数据、改配置的命令，都必须人工确认后再执行。把 AI 当作一个高效的助手，而不是一个可以背锅的替罪羊，这样才能真正用好它。 + +**第三，渗透测试的终点不是拿到 Shell。** + 拿到 RCE 后，工作其实才刚刚开始。我们需要整理证据链，评估影响范围，给出可落地的修复方案，并帮助客户验证修复效果。对客户来说，一个能复现的 POC 和一份清晰的修复清单，远比一个 Shell 更有价值。 + +希望这篇文章能给正在做渗透测试或代码审计的师傅带来一些启发。如果你有不同的思路或更好的工具推荐，欢迎在评论区交流。 + +往期文章分享 +
学习干货 | 年薪25W！从传统自动化测试到大模型安全测试，粉丝分享真实的转型复盘笔记
应急响应|客户勒索病毒中招 无安全设备下的五分钟极速溯源复盘
渗透测试 | 近期高危逻辑漏洞挖掘实战合集 (越权漏洞 / 支付漏洞 / 账号接管)
学习干货|首发黑灰产靶场之恶意浏览器插件窃密与远控溯源复盘
网安话题 | 热门榜单答疑第一期：从AI大模型安全到行业发展探讨
学习干货 | 新手必练！真实复现DMZ区攻防场景与排查思路（附开源环境）
应急响应|全网首发！变种勒索病毒仿真靶场：从排查到解密(附开源训练环境)
应急响应|记一次针对AIR勒索病毒的溯源过程
学习干货|从网线到攻防，一起学习网络基础、安全原理与密码学知识！建议收藏
应急响应|某项目特洛伊挖矿木马靶场复现(附开源环境)
学习干货|从迷茫到前行：我的网络安全学习之路
应急响应|2025年勒索病毒排查溯源指南(附开源训练环境)
应急响应真没这么难！速看某公交系统靶机应急响应排查思路
渗透测试|小白也能学会渗透测试！某医院HIS系统渗透测试靶场学习
应急演练|深入浅出分析某海外能源巨头勒索模拟演练过程
应急响应|学校不教的我来教！某学校系统中挖矿病毒的超详细排查思路
开源万岁|我妈说我奶想学习了，让我给搭建一个知识库学学IT
渗透测试|倒反天罡！转发给你的老师《0基础也能学渗透测试+代码审计电商平台靶场》让他重修
渗透测试|学校教不会的我来教，一篇文章学习渗透测试那些事(某金融程序靶场测试的项目式教学)
+ + diff --git a/doc/2026-06/炸场！GitHub公开海量未报送0day PoC，多款常用软件高危.md b/doc/2026-06/炸场！GitHub公开海量未报送0day PoC，多款常用软件高危.md new file mode 100644 index 00000000..a7ac84b6 --- /dev/null +++ b/doc/2026-06/炸场！GitHub公开海量未报送0day PoC，多款常用软件高危.md @@ -0,0 +1,53 @@ +# 炸场！GitHub公开海量未报送0day PoC，多款常用软件高危 +原创 hacking + hacking Hacking黑白红 2026-06-30 05:44 + +近日GitHub匿名账号bikini上线仓库 exploitarium ，短时间热度暴涨，收获2.3k Star、534次Fork。 + +可谓是匿名仓库爆火，大量零日漏洞利用代码开源， +引发全网网安圈震动。 + + +![](https://mmbiz.qpic.cn/mmbiz_jpg/TVljsu2eAicIRCicGEVZEcVxuIibzxHsAetOEA4h9WELsXeQ1P4TccO5CatKzsr0r9vlBPqlp5UGIJD5AmJYIMYDyUicyVsyKrJ7tlcmeib6WZTU/640?wx_fmt=jpeg "") + + +项目地址：https://github.com/bikini/exploitarium + + +仓库内批量上传全套可直接利用的漏洞PoC，关键风险点在于： + + +这批漏洞均未提前同步厂商，属于未修复0day零日漏洞，攻击者拿到代码即可发起渗透攻击，厂商暂无对应补丁。 + + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/TVljsu2eAicJk1y2ltXgKu5c72oia3HRiaUOJKfszC690Af3epLwboZwP6VL6Z9GBfprrlhDSHkqOq0nWY1tyliaVtvcAibsCHg4ctyTTTTHnWlI/640?wx_fmt=jpeg "") + + 覆盖品类十分全面，包含桌面工具、服务器组件、Web框架、容器、远程控制软件、浏览器等。 + + +波及大众高频使用产品： + +7-Zip、Docker、Firefox、RustDesk、PHP 8.5.7、Nmap、FFmpeg、OpenVPN等，企业与个人终端均大面积暴露风险。 +仓库作者初衷，暗藏巨大安全隐患 仓库自述内容显示，作者并未走正规漏洞报送流程，称公开PoC是为吸引新人进入安全研究领域，还提醒用户不要恶意滥用。 + +但PoC完整可执行，门槛极低，黑产、黑客无需专业漏洞挖掘能力，复制代码就能实施远程代码执行、权限绕过、本地提权、文件逃逸、数据窃取等攻击。以往稀缺的0day攻击武器，如今全网公开下载，大幅降低网络攻击成本。 +涉及典型高危漏洞一览 仓库收录数十套完整利用链，典型风险包括： 1. Docker容器拷贝路径逃逸、AnyDesk打印机COM身份伪造； + +2. Firefox浏览器私密链接数据窃取、Flowise API网关远程代码执行； + +3. RustDesk会话权限绕过、7ZIP rar5权限提升链漏洞； + +4. PHP、libssh2、Nmap、ImageMagick等开源组件内存破坏漏洞。 +企业&个人紧急防护建议 1. 资产梳理：自查服务器、办公终端是否部署上述受影响软件，暂时限制公网暴露管理端口； + +2. 访问管控：远程控制、容器服务仅内网访问，开启IP白名单与双因素认证； + +3. 流量监测：部署IPS、沙箱，重点监控异常代码执行、文件外发行为； + +4. 持续跟踪：同步厂商安全公告，漏洞补丁发布后第一时间升级； + +5. 红线提醒：禁止运维、开发人员下载、传播该仓库PoC，避免合规与安全风险。 零日漏洞无补丁窗口期风险极高，本次批量公开事件，给政企、互联网企业敲响警钟，需立刻开展内部资产自查，缩小攻击面。 + + +作者：hacking。前北漂程序员，现在做安全。文章数据来自网络，大模型优化，侵权删。 +