mirror of
https://github.com/gelusus/wxvl.git
synced 2025-05-29 17:51:07 +00:00
SAST国标分析︱灵脉AI深度兼容GB∕T 34943∕34944-2017源代码漏洞测试规范、北京警方通报：境外黑客组织利用ComfyUI漏洞对我实施攻击、Retire.js - 检测JavaScript依赖漏洞的安全工具、已公开漏洞的认知“真相”、逐帧分析：Kernel Streaming 持续暴露漏洞、自学黑客技术多长时间能达到挖漏洞的水平？零基础入门到精通，收藏这篇就够了、紧急预警！Samlify SSO 签名绕过漏洞（CVE-2025-47949）解析与防御指南、Mimo 回归：CVE-2025-32432 被用于加密货币挖矿和代理软件活动、【业界动态】ComfyUI存在多个高危漏洞、Vite开发服务器任意文件读取（CVE-2025-30208）、
This commit is contained in:
test
parent
65dcb17cd3
commit
7b44c0908e
12
data.json
12
data.json
@ -14533,5 +14533,15 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU2MDk1Nzg2MQ==&mid=2247624639&idx=3&sn=8cb76c24e331ca965cf8085ec68d31a0": "人工智能自动化模糊测试：如何自主发现汽车软件中的漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzA5MzE5MDAzOA==&mid=2664243080&idx=2&sn=f3ace9c6fac492cbef8ab21825036bda": "关注 | ComfyUI存在多个高危漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3NzkwMTYyOQ==&mid=2247489213&idx=1&sn=d4e4580e77b79aa9d7736bcd79a22ecc": "实战EDUSRC挖掘｜微信小程序渗透漏洞及getshell复盘",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493239&idx=1&sn=2ad4c6a9c3df1465a9ebfccfff088411": "漏洞预警 | FoxCMS SQL注入漏洞"
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493239&idx=1&sn=2ad4c6a9c3df1465a9ebfccfff088411": "漏洞预警 | FoxCMS SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzMDE5MDI5Mg==&mid=2247509231&idx=2&sn=0a6f372871ff311926ba91a8708e3f2e": "SAST国标分析︱灵脉AI深度兼容GB∕T 34943∕34944-2017源代码漏洞测试规范",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247514434&idx=2&sn=19b30608f4a701f991edf166024d4d6f": "北京警方通报：境外黑客组织利用ComfyUI漏洞对我实施攻击",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzA5NDI0NzY3Mg==&mid=2247484912&idx=1&sn=7868ebacb71e9eb162686ab99cf03d8d": "Retire.js - 检测JavaScript依赖漏洞的安全工具",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxNzA3MTgyNg==&mid=2247538958&idx=2&sn=609ff480e7b89259dea2743f02dd9059": "已公开漏洞的认知“真相”",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxODM5ODQzNQ==&mid=2247488566&idx=1&sn=02dcbc079feef0474efaac6fef9f91fc": "逐帧分析：Kernel Streaming 持续暴露漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzk1NzMwNTM5NQ==&mid=2247486150&idx=1&sn=cfa0a2b0886e123f79b42eb813ba429e": "自学黑客技术多长时间能达到挖漏洞的水平？零基础入门到精通，收藏这篇就够了",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU1NzczNTM1MQ==&mid=2247485317&idx=1&sn=0b31c80b87f34af3ab33021b8697920c": "紧急预警！Samlify SSO 签名绕过漏洞（CVE-2025-47949）解析与防御指南",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjYyMzkwOA==&mid=2247530246&idx=3&sn=bf5fc5129373658b9aeb7e2260f705d1": "Mimo 回归：CVE-2025-32432 被用于加密货币挖矿和代理软件活动",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzA3NzgzNDM0OQ==&mid=2664995100&idx=3&sn=3e84ad389f64c458d97638e803adceef": "【业界动态】ComfyUI存在多个高危漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU1NzczNTM1MQ==&mid=2247485317&idx=2&sn=04447863a12ee6db59848d6d73655902": "Vite开发服务器任意文件读取（CVE-2025-30208）"
|
||||
}
|
||||
81
doc/2025-05/Mimo 回归：CVE-2025-32432 被用于加密货币挖矿和代理软件活动.md
Normal file
81
doc/2025-05/Mimo 回归：CVE-2025-32432 被用于加密货币挖矿和代理软件活动.md
Normal file
@ -0,0 +1,81 @@
|
||||
# Mimo 回归：CVE-2025-32432 被用于加密货币挖矿和代理软件活动
|
||||
Ots安全 2025-05-28 06:35
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Sekoia 最新的威胁情报报告揭露了一起针对 CVE-2025-32432 的攻击活动。CVE-2025-32432 是一个影响 Craft CMS 平台的严重未经身份验证的远程代码执行 (RCE) 漏洞。此次攻击的幕后黑手是 Mimo 或 Hezb，他们部署了一套由 Webshell、加载器、挖矿程序和代理软件组成的恶意软件组合，以最大限度地利用受感染的系统牟利。
|
||||
|
||||
2 月 28 日至 5 月 2 日期间，研究人员观察到 Mimo 在野外利用此漏洞，使用多阶段感染链来传递一个名为“alamdar”的基于 Golang 的加载程序，然后安装 XMRig 矿工和 IPRoyal 代理软件。
|
||||
|
||||
该漏洞影响 Craft CMS 版本
|
||||
- 3.0.0-RC1 至 <3.9.15
|
||||
|
||||
- 4.0.0-RC1 至 <4.14.15
|
||||
|
||||
- 5.0.0-RC1 至 <5.6.17
|
||||
|
||||
该漏洞由Orange Cyberdefense发现，并于 2025 年 4 月 25 日公开披露。攻击者可以通过精心设计的 HTTP 请求，实现未经身份验证的远程代码执行 (RCE)。Sekoia 表示：
|
||||
|
||||
“攻击者利用 CVE-2025-32432 漏洞，通过部署 webshell 实现远程访问，从而获得对目标系统的未授权访问。”
|
||||
|
||||
两步攻击序列使用精心设计的 GET 请求来注入基于 PHP 的 webshell，然后使用 POST 请求来触发反序列化错误，从而允许执行 shell 命令。
|
||||
|
||||
一旦进入系统，攻击者就会获取并执行远程感染脚本 (4l4md4r.sh)。该脚本会执行系统侦察、终止竞争恶意软件并下载三个组件：
|
||||
- Alamdar 加载器（ELF 二进制文件）
|
||||
|
||||
- IPRoyal 代理软件 (hezb.x86_64)
|
||||
|
||||
- XMRig 加密货币矿工（alamdar）
|
||||
|
||||
该脚本执行已下载的名为 4l4md4r 的二进制文件……加载程序下载并执行住宅代理二进制文件 IPRoyal……以及 XMRig 矿工。
|
||||
|
||||
该加载程序使用恶意.so 库（alamdar.so）进行 LD_PRELOAD 劫持，通过拦截 readdir 和 getpid 等系统调用来隐藏其存在。
|
||||
|
||||
Mimo 的双重货币化策略反映了资源精明的网络犯罪分子的一种趋势：挖掘加密货币并通过住宅代理服务出售网络带宽。
|
||||
- XMRig：通过 MoneroOcean 矿池挖掘门罗币。
|
||||
|
||||
- 钱包：46HmQz11t8uN84P8xg…
|
||||
|
||||
- 每周收益：约 9.45 美元
|
||||
|
||||
- IPRoyal Pawns：
|
||||
|
||||
- 秘密地将受害者的 IP 地址货币化。
|
||||
|
||||
- 静默接受登录凭证和 TOS 接受。
|
||||
|
||||
“这一战略体现了一种务实的资源货币化方法，从计算能力和带宽中提取价值。”
|
||||
|
||||
通过广泛的 OSINT 和 IoC 分析，Sekoia 将此活动与 Mimo 入侵集联系起来——该入侵集至少自 2022 年以来一直活跃。别名 EtxArny 和 N1tr0 被认为是可能的操作员，基于以下几点：
|
||||
- TikTok 视频展示了 CVE 漏洞。
|
||||
|
||||
- 在代码和社交媒体中使用别名“4l4md4r”和“Hezb”。
|
||||
|
||||
- 共享加密货币钱包和基础设施。
|
||||
|
||||
“以别名‘EtxArny’运营的 TikTok 账户似乎采用了这种符号图案……并且可能与 Mimo 入侵组织有关。”
|
||||
|
||||
敦促运行 Craft CMS 的组织立即修补，检查日志中的 IOC 模式，并对系统二进制文件和出站连接实施严格控制。
|
||||
|
||||
|
||||
|
||||
感谢您抽出
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
来阅读本文
|
||||
|
||||
|
||||
|
||||
**点它，分享点赞在看都在这里**
|
||||
|
||||
94
doc/2025-05/Retire.js - 检测JavaScript依赖漏洞的安全工具.md
Normal file
94
doc/2025-05/Retire.js - 检测JavaScript依赖漏洞的安全工具.md
Normal file
@ -0,0 +1,94 @@
|
||||
# Retire.js - 检测JavaScript依赖漏洞的安全工具
|
||||
原创 qife 网络安全技术点滴分享 2025-05-28 00:35
|
||||
|
||||
# 项目概述
|
||||
|
||||
Retire.js是一个用于检测JavaScript项目中存在已知漏洞依赖的安全扫描工具。它能够识别网页应用和Node.js应用中使用的具有已知安全漏洞的JavaScript库和模块。
|
||||
## 主要特性
|
||||
- **多平台支持**
|
||||
：提供命令行工具、浏览器扩展和构建工具插件
|
||||
|
||||
- **全面检测**
|
||||
：通过多种方式检测漏洞依赖：
|
||||
|
||||
- 文件名/URL匹配
|
||||
|
||||
- 文件内容扫描
|
||||
|
||||
- 哈希值比对
|
||||
|
||||
- 沙箱执行检测(浏览器扩展)
|
||||
|
||||
- **丰富的输出格式**
|
||||
：支持文本、JSON、CycloneDX等多种报告格式
|
||||
|
||||
- **持续更新**
|
||||
：漏洞数据库定期更新
|
||||
|
||||
- **轻量级**
|
||||
：无复杂依赖，易于集成到开发流程中
|
||||
|
||||
## 安装指南
|
||||
### 命令行工具安装
|
||||
```
|
||||
npm install -g retire //前提要安装node.js
|
||||
```
|
||||
### 如下所示：
|
||||
|
||||
|
||||
### Chrome扩展安装
|
||||
1. 克隆仓库：git clone https://github.com/RetireJS/retire.js
|
||||
|
||||
1. 运行构建脚本：./build_chrome.sh
|
||||
|
||||
1. 在Chrome中加载解压的扩展：chrome://extensions/
|
||||
→ "开发者模式" → "加载已解压的扩展程序" → 选择chrome/extension
|
||||
目录
|
||||
|
||||
如下所示：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Firefox扩展安装
|
||||
### firefox在管理扩展中搜索retire.js安装即可
|
||||
|
||||
|
||||
## 使用说明
|
||||
### 基本扫描
|
||||
```
|
||||
//npm install -g retire 安装完以后 在命令行执行
|
||||
retire --path /path/to/scan --proxy http://127.0.0.1:21882 //在国内的话可能要用魔法
|
||||
```
|
||||
### 如下所示，--path 后面添加要检查的web项目（须包含前端源代码的）
|
||||
### 比如我这个前后端分离的项目中，前端项目用了axios依赖，它即检测到了该项目使用了axios依赖，并识别出了当前axios使用的版本以及可能存在的漏洞风险
|
||||
|
||||
|
||||
### 常用选项
|
||||
```
|
||||
# 指定扫描路径
|
||||
retire --path /path/to/scan
|
||||
|
||||
# 输出JSON格式报告
|
||||
retire --path /path/to/scan --outputformat json
|
||||
|
||||
# 忽略特定路径
|
||||
retire --path /path/to/scan --ignore "node_modules,bower_components"
|
||||
|
||||
# 指定漏洞严重级别阈值
|
||||
retire --path /path/to/scan --severity high
|
||||
```
|
||||
### Chrome扩展使用
|
||||
|
||||
安装后，扩展会自动扫描访问的网页，并在开发者控制台显示发现的漏洞。如下所示
|
||||
|
||||
|
||||
|
||||
FireFox扩展使用
|
||||
|
||||
与Chrome扩展使用一样
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
# SAST国标分析︱灵脉AI深度兼容GB/T 34943/34944-2017源代码漏洞测试规范
|
||||
原创 Xmirror 悬镜安全 2025-05-23 11:28
|
||||
数说安全 2025-05-28 06:30
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
随着信息技术的飞速发展，软件系统的规模和复杂度不断增加。在C/C++和Java语言编写的软件中，代码量庞大且结构复杂，这使得隐藏在源代码中的漏洞数量也随之增多。这些漏洞可能被攻击者利用，从而对软件系统的安全性、稳定性和可靠性造成严重威胁。这使得制定C/C++和Java语言源代码测试的标准尤为必要。
|
||||
|
||||
@ -10,22 +11,25 @@
|
||||
目前两项国家标准已在软件开发、安全测试、工具设计等领域广泛应用。由此为软件研发企业、测试机构等提供统一的测试规范和方法，保障软件产品和系统的质量。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**标准解读**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**一、GB/T 34943-2017《C/C++语言源代码漏洞测试规范》**
|
||||
|
||||
包含源代码漏洞测试的测试目的、测试过程、测试管理、测试工具、测试文档以及测试内容。标准中列出的测试内容共包含8大方面，共32类漏洞问题。
|
||||
|
||||
**测试目的：**发现、定位及解决软件源代码中的漏洞；为软件产品的安全性测量和评价提供依据。
|
||||
**测试目的：**
|
||||
发现、定位及解决软件源代码中的漏洞；为软件产品的安全性测量和评价提供依据。
|
||||
|
||||
**测试过程：**主要包括测试策划、测试设计、测试执行和测试总结四个阶段。
|
||||
**测试过程：**
|
||||
主要包括测试策划、测试设计、测试执行和测试总结四个阶段。
|
||||
|
||||
**测试内容：**根据软件开发中常用的概念来组织 C/C++语言源代码漏洞的类别，具体分为如下8个类别:
|
||||
**测试内容：**
|
||||
根据软件开发中常用的概念来组织 C/C++语言源代码漏洞的类别，具体分为如下8个类别:
|
||||
|
||||
a)行为问题——由于应用程序的意外行为而引发的漏洞。
|
||||
|
||||
@ -44,18 +48,19 @@ g)安全功能——软件安全功能如身份鉴别、访问控制、机密性
|
||||
h)Web问题——Web技术相关的漏洞。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**标准解读**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**二、GB/T34944-2017《Java语言源代码漏洞测试规范》**
|
||||
|
||||
整体架构与GB/T 34943-2017标准相同。标准中列出的测试内容共包含9大方面，共44类漏洞问题。
|
||||
|
||||
**测试内容：**标准根据软件开发中常用的概念来组织Java语言源代码漏洞的类别，具体分为如下9个类别：
|
||||
**测试内容：**
|
||||
标准根据软件开发中常用的概念来组织Java语言源代码漏洞的类别，具体分为如下9个类别：
|
||||
|
||||
a) 行为问题——由于应用程序的意外行为而引发的漏洞。
|
||||
|
||||
@ -78,9 +83,9 @@ i)用户界面错误——与用户界面相关的漏洞。
|
||||
|
||||
**应用场景与适用行业**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -102,31 +107,41 @@ i)用户界面错误——与用户界面相关的漏洞。
|
||||
|
||||
|
||||
**1. GB/T 34943-2017**
|
||||
- **系统软件开发行业**：操作系统、数据库管理系统、编译器等系统软件常使用 C/C++ 语言开发。这些软件是计算机系统的核心，任何漏洞都可能导致系统崩溃或数据丢失，遵循该标准能确保系统软件的稳定性和安全性。
|
||||
- **系统软件开发行业**
|
||||
：操作系统、数据库管理系统、编译器等系统软件常使用 C/C++ 语言开发。这些软件是计算机系统的核心，任何漏洞都可能导致系统崩溃或数据丢失，遵循该标准能确保系统软件的稳定性和安全性。
|
||||
|
||||
- **嵌入式系统行业**：工业控制、智能家居、汽车电子、航空航天等领域的嵌入式系统大量应用 C/C++ 语言。由于这些领域对可靠性和安全性要求苛刻，依据此标准进行源代码漏洞测试，可保障嵌入式系统在复杂环境下稳定、安全运行。
|
||||
- **嵌入式系统行业**
|
||||
：工业控制、智能家居、汽车电子、航空航天等领域的嵌入式系统大量应用 C/C++ 语言。由于这些领域对可靠性和安全性要求苛刻，依据此标准进行源代码漏洞测试，可保障嵌入式系统在复杂环境下稳定、安全运行。
|
||||
|
||||
- **游戏开发行业**：游戏开发，特别是对性能要求较高的 3A 游戏，在图形渲染、物理模拟等关键模块常采用 C/C++ 语言。遵循该标准有助于发现和修复潜在漏洞，提升游戏的稳定性和用户体验，同时保护玩家数据安全。
|
||||
- **游戏开发行业**
|
||||
：游戏开发，特别是对性能要求较高的 3A 游戏，在图形渲染、物理模拟等关键模块常采用 C/C++ 语言。遵循该标准有助于发现和修复潜在漏洞，提升游戏的稳定性和用户体验，同时保护玩家数据安全。
|
||||
|
||||
- **网络设备制造行业**：路由器、交换机等网络设备的操作系统和控制软件很多是基于 C/C++ 语言编写。通过按照该标准进行漏洞测试，可以提高网络设备的安全性，防止网络攻击，保障网络通信的稳定和安全。
|
||||
- **网络设备制造行业**
|
||||
：路由器、交换机等网络设备的操作系统和控制软件很多是基于 C/C++ 语言编写。通过按照该标准进行漏洞测试，可以提高网络设备的安全性，防止网络攻击，保障网络通信的稳定和安全。
|
||||
|
||||
**2. GB/T 34944-2017**
|
||||
- **互联网行业**：许多互联网公司使用 Java 开发 Web 应用程序、分布式系统、微服务等。如电商平台、社交媒体平台、在线支付系统等，需要确保 Java 源代码的安全性，防止漏洞被利用导致用户信息泄露等问题。
|
||||
- **互联网行业**
|
||||
：许多互联网公司使用 Java 开发 Web 应用程序、分布式系统、微服务等。如电商平台、社交媒体平台、在线支付系统等，需要确保 Java 源代码的安全性，防止漏洞被利用导致用户信息泄露等问题。
|
||||
|
||||
- **金融行业**：银行、证券、保险等金融机构的核心业务系统、网上银行、金融交易平台等常基于 Java 开发。这些系统对安全性和稳定性要求极高，遵循该标准可有效降低安全风险，保障金融交易的安全和稳定。
|
||||
- **金融行业**
|
||||
：银行、证券、保险等金融机构的核心业务系统、网上银行、金融交易平台等常基于 Java 开发。这些系统对安全性和稳定性要求极高，遵循该标准可有效降低安全风险，保障金融交易的安全和稳定。
|
||||
|
||||
- **企业信息化领域**：企业的 ERP 系统、办公自动化系统、客户关系管理系统（CRM）等大多采用 Java 开发。通过依据此标准进行漏洞测评，能保证企业内部信息系统的安全运行，提高企业运营效率。
|
||||
- **企业信息化领域**
|
||||
：企业的 ERP 系统、办公自动化系统、
|
||||
客户关系管理系统
|
||||
（CRM）等大多采用 Java 开发。通过依据此标准进行漏洞测评，能保证企业内部信息系统的安全运行，提高企业运营效率。
|
||||
|
||||
- **科研院校**：在科研项目中涉及 Java 语言的软件开发，以及相关专业教学中，该标准有助于培养学生的安全编程意识，保障科研项目软件的质量和安全性。
|
||||
- **科研院校**
|
||||
：在科研项目中涉及 Java 语言的软件开发，以及相关专业教学中，该标准有助于培养学生的安全编程意识，保障科研项目软件的质量和安全性。
|
||||
|
||||
|
||||
|
||||
|
||||
**灵脉AI完全覆盖双国家标准**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -135,7 +150,7 @@ i)用户界面错误——与用户界面相关的漏洞。
|
||||
|
||||
**1.灵脉AI对标能力示例**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**2.技术优势：用 "底层理解" 守护 C/C++ 代码安全**
|
||||
@ -159,7 +174,9 @@ i)用户界面错误——与用户界面相关的漏洞。
|
||||
**跨函数数据流追踪**
|
||||
|
||||
|
||||
通过调用图分析追踪变量在函数间的传递。例如，验证用户输入是否经过长度校验后才传递给malloc函数，确保符合 GB/T 34943 第 6.2.1.1 条要求。
|
||||
通过调用图分析追踪变量在函数间的传递。例如，验证用户输入是否经过长度校验后才传递给
|
||||
malloc函数
|
||||
，确保符合 GB/T 34943 第 6.2.1.1 条要求。
|
||||
|
||||
**4**
|
||||
|
||||
@ -176,7 +193,7 @@ i)用户界面错误——与用户界面相关的漏洞。
|
||||
|
||||
**1. 灵脉AI对标能力示例**
|
||||
|
||||
|
||||
|
||||
|
||||
**2.技术优势："Java 语义理解"，漏洞检测更智能**
|
||||
|
||||
@ -184,19 +201,22 @@ i)用户界面错误——与用户界面相关的漏洞。
|
||||
|
||||
|
||||
|
||||
**深度语法解析：**支持Java21新特性，精准识别现代Java语法中的安全隐患。
|
||||
**深度语法解析：**
|
||||
支持Java21新特性，精准识别现代Java语法中的安全隐患。
|
||||
|
||||
**2**
|
||||
|
||||
|
||||
|
||||
**污点跟踪分析：**通过数据流分析技术建立变量的污染路径，自动识别未经验证的外部输入如何流经系统并触发安全风险。
|
||||
**污点跟踪分析：**
|
||||
通过数据流分析技术建立变量的污染路径，自动识别未经验证的外部输入如何流经系统并触发安全风险。
|
||||
|
||||
**3**
|
||||
|
||||
|
||||
|
||||
**框架感知检测：**内置主流框架规则包，自动验证；
|
||||
**框架感知检测：**
|
||||
内置主流框架规则包，自动验证；
|
||||
|
||||
API接口安全 ：识别引入污点值的@GetMapping/@PostMapping端点；
|
||||
|
||||
@ -205,14 +225,14 @@ ORM框架：区分 MyBatis#{}预编译与${}动态拼接，标记未经验证的
|
||||
|
||||
**三、双标准能力矩阵：覆盖全语言、全场景的安全防护**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
灵脉AI支持基于合规标准维度展示任务缺陷
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
灵脉AI支持对缺陷进行过程间污点跟踪分析
|
||||
|
||||
@ -225,13 +245,17 @@ ORM框架：区分 MyBatis#{}预编译与${}动态拼接，标记未经验证的
|
||||
|
||||
某金融机构采用敏捷+DevOps开发模式，发版周期缩短至每周1次，但面临以下痛点：
|
||||
|
||||
**安全漏洞修复滞后：**传统人工代码审计周期长达2-3周，漏洞修复往往延迟至测试阶段甚至上线后。
|
||||
**安全漏洞修复滞后：**
|
||||
传统人工代码审计周期长达2-3周，漏洞修复往往延迟至测试阶段甚至上线后。
|
||||
|
||||
**跨部门协作低效：**安全团队与开发团队对部分漏洞定义理解不一致，需反复沟通确认。
|
||||
**跨部门协作低效：**
|
||||
安全团队与开发团队对部分漏洞定义理解不一致，需反复沟通确认。
|
||||
|
||||
**合规风险凸显：**金融行业监管要求必须符合 GB/T 34944-2017《Java 语言源代码漏洞测试规范》，但现有工具无法覆盖标准要求的 44 类漏洞。
|
||||
**合规风险凸显：**
|
||||
金融行业监管要求必须符合 GB/T 34944-2017《Java 语言源代码漏洞测试规范》，但现有工具无法覆盖标准要求的 44 类漏洞。
|
||||
|
||||
**开发人员安全能力不足：**80%的开发人员缺乏系统安全培训，难以识别隐蔽漏洞。
|
||||
**开发人员安全能力不足：**
|
||||
80%的开发人员缺乏系统安全培训，难以识别隐蔽漏洞。
|
||||
|
||||
**解决方案**
|
||||
|
||||
@ -245,13 +269,17 @@ ORM框架：区分 MyBatis#{}预编译与${}动态拼接，标记未经验证的
|
||||
|
||||
**用户收益**
|
||||
|
||||
**合规达标：**项目GB/T 34944漏洞覆盖率从42%提升至95%，通过监管机构年度审计。
|
||||
**合规达标：**
|
||||
项目GB/T 34944漏洞覆盖率从42%提升至95%，通过监管机构年度审计。
|
||||
|
||||
**修复周期缩短：**漏洞平均修复时间从14天降至7天，紧急修复工单减少75%。
|
||||
**修复周期缩短：**
|
||||
漏洞平均修复时间从14天降至7天，紧急修复工单减少75%。
|
||||
|
||||
**沟通成本降低：**跨部门漏洞争议减少80%，安全团队代码审查工作量下降60%。
|
||||
**沟通成本降低：**
|
||||
跨部门漏洞争议减少80%，安全团队代码审查工作量下降60%。
|
||||
|
||||
**开发能力提升：**开发人员安全漏洞识别准确率从35%提升至85%，安全编码意识显著增强。
|
||||
**开发能力提升：**
|
||||
开发人员安全漏洞识别准确率从35%提升至85%，安全编码意识显著增强。
|
||||
|
||||
|
||||
悬镜灵脉AI是落地实践应用安全左移的基石之一，是敏捷安全工具链中前置到安全编码阶段的重要赋能环节。悬镜敏捷安全工具链作为第四代DevSecOps数字供应链安全体系中的重要能力支撑，将不断提供更智能、更可信的创新供应链安全产品服务，持续守护中国数字供应链安全。
|
||||
@ -268,33 +296,12 @@ ORM框架：区分 MyBatis#{}预编译与${}动态拼接，标记未经验证的
|
||||
**↓**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
（2025.5.28数说安全发布）
|
||||
|
||||
＋
|
||||
|
||||
**推荐阅读**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzA3NzE2ODk1Mg==&mid=2647795666&idx=1&sn=c1e93a479b0d1b12f9e4a03b1c2e01f0&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzA3NzE2ODk1Mg==&mid=2647795771&idx=1&sn=b6f49879b2080b59f9a4605eb0b71e04&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzA3NzE2ODk1Mg==&mid=2647796169&idx=1&sn=3103b6b8a2eae2a9d49e15b226392bf6&scene=21#wechat_redirect)
|
||||
|
||||
[]()
|
||||
|
||||
**关于“悬镜安全”**
|
||||
|
||||
****
|
||||
|
||||
悬镜安全，起源于子芽创立的北京大学网络安全技术研究团队“XMIRROR”，作为数字供应链安全和DevSecOps敏捷安全开拓者，始终专注于以“AI智能代码疫苗”技术为内核，凭借原创专利级“多模态SCA+DevSecOps+SBOM风险情报预警”的第四代DevSecOps数字供应链安全管理体系，创新赋能金融、车联网、通信、能源、政企、智能制造和泛互联网等行业用户，构筑起适应自身业务弹性发展、面向敏捷业务交付并引领未来架构演进的共生积极防御体系，持续守护中国数字供应链安全。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
127
doc/2025-05/Vite开发服务器任意文件读取（CVE-2025-30208）.md
Normal file
127
doc/2025-05/Vite开发服务器任意文件读取（CVE-2025-30208）.md
Normal file
@ -0,0 +1,127 @@
|
||||
# Vite开发服务器任意文件读取（CVE-2025-30208）
|
||||
云梦DC 云梦安全 2025-05-28 06:05
|
||||
|
||||
一、漏洞概述
|
||||
|
||||
CVE-2025-30208 是 Vite 开发服务器（Dev Server）中曝出的超危漏洞（CVSS 评分9.8），允许攻击者通过构造特殊 URL 参数，绕过文件访问限制，直接读取服务器任意文件（如 /etc/passwd、/tmp/secret.txt 等），导致敏感信息泄露。
|
||||
|
||||
|
||||
|
||||
|
||||
1. 漏洞原理
|
||||
|
||||
@fs 机制缺陷：Vite 开发模式下使用 @fs 机制访问项目文件，但未正确处理 URL 查询参数中的特殊字符（如 ?raw?? 或 ?import&raw??）。攻击者通过添加此类参数，可绕过 server.fs.allow 白名单限制。
|
||||
|
||||
正则表达式逻辑漏洞：Vite 在处理请求时，多次移除 URL 结尾分隔符（如 ?），但未在正则匹配中同步处理，导致路径校验失效。
|
||||
|
||||
2. 漏洞影响
|
||||
|
||||
敏感文件泄露：攻击者可读取服务器任意文件，包括源码、数据库凭据、系统配置文件等。
|
||||
|
||||
利用条件简单：仅需暴露 Vite Dev Server（如配置 --host 或 server.host 对外开放），无需认证即可发起攻击。
|
||||
|
||||
二、受影响范围
|
||||
|
||||
1. 影响版本
|
||||
|
||||
以下 Vite 版本均存在风险：
|
||||
|
||||
6.x：<=6.2.2、<=6.1.1、<=6.0.11
|
||||
|
||||
5.x：<=5.4.14
|
||||
|
||||
4.x：<=4.5.9
|
||||
|
||||
概括：6.2.3、6.1.2、6.0.12、5.4.15、4.5.10 之前的版本均受影响。
|
||||
|
||||
2. 修复版本
|
||||
|
||||
官方已发布安全版本：
|
||||
|
||||
6.2.3+、6.1.2+、6.0.12+
|
||||
|
||||
5.4.15+、4.5.10+
|
||||
|
||||
建议立即升级至最新版本。
|
||||
|
||||
3. 受影响场景
|
||||
|
||||
生产环境错误配置：直接对外开放 Vite Dev Server（非代理模式）。
|
||||
|
||||
内网暴露风险：未限制内网访问权限，攻击者可横向渗透。
|
||||
|
||||
4. 不受影响场景
|
||||
|
||||
仅本地开发使用（未暴露端口）。
|
||||
|
||||
生产环境通过 Nginx/Tomcat 代理静态资源，未启用 Dev Server。
|
||||
|
||||
三、漏洞成因
|
||||
|
||||
核心问题：URL 解析逻辑与正则表达式处理不同步。
|
||||
|
||||
示例请求：http://localhost:5173/@fs/etc/passwd?import&raw??
|
||||
|
||||
绕过原理：Vite 移除 ? 后未重新校验路径，误将 /etc/passwd 视为合法请求。
|
||||
|
||||
四、漏洞利用示例
|
||||
|
||||
正常请求（触发403）
|
||||
```
|
||||
curl
|
||||
|
||||
"http://localhost:5173/
|
||||
@fs
|
||||
/tmp/secret.txt"
|
||||
|
||||
# 返回：403 Restricted（路径超出白名单）
|
||||
```
|
||||
|
||||
|
||||
|
||||
恶意请求（绕过限制）
|
||||
```
|
||||
curl "http://localhost:5173/@fs/tmp/secret.txt?import&raw??"
|
||||
# 返回文件内容（如："top secret content"）[3,4](@ref)
|
||||
```
|
||||
|
||||
|
||||
PoC 验证：
|
||||
|
||||
攻击者可通过浏览器直接输入 URL，或使用自动化工具（如 Nuclei）批量扫描。
|
||||
|
||||
全球受影响资产超 4.2万+（ZoomEye 数据）。
|
||||
|
||||
五、修复与缓解方案
|
||||
|
||||
1. 彻底修复方案
|
||||
|
||||
升级至安全版本：
|
||||
```
|
||||
# 根据项目版本选择对应命令
|
||||
npm install vite@6.2.3 --save-dev
|
||||
yarn upgrade vite@5.4.15
|
||||
```
|
||||
|
||||
|
||||
2. 临时缓解措施
|
||||
|
||||
限制访问范围：
|
||||
|
||||
关闭 --host 参数，仅允许本地访问。
|
||||
|
||||
通过防火墙或 Nginx 限制 IP 白名单。
|
||||
|
||||
拦截恶意请求：在代理层拦截含 ?raw??、?import&raw?? 的 URL。
|
||||
|
||||
显式禁止敏感路径：
|
||||
```
|
||||
// vite.config.js
|
||||
server: {
|
||||
fs: {
|
||||
deny: ["/etc/passwd", "/windows/win.ini"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
13
doc/2025-05/【业界动态】ComfyUI存在多个高危漏洞.md
Normal file
13
doc/2025-05/【业界动态】ComfyUI存在多个高危漏洞.md
Normal file
@ -0,0 +1,13 @@
|
||||
# 【业界动态】ComfyUI存在多个高危漏洞
|
||||
信息安全研究 2025-05-28 07:01
|
||||
|
||||
ComfyUI是一款AI绘图工具，专为图像生成任务设计，通过将深度学习模型的工作流程简化为图形化节点，使用户操作更加直观和易于理解。近期，北京市网络与信息安全信息通报中心发现，ComfyUI存在任意文件读取、远程代码执行等多个历史高危漏洞（CVE-2024-10099、CVE-2024-21574、CVE-2024-21575、CVE-2024-21576、CVE-2024-21577），攻击者可利用上述漏洞实施远程代码执行攻击，获取服务器权限，进而窃取系统数据。目前已有境外黑客组织利用
|
||||
ComfyUI漏洞对我网络资产实施网络攻击，伺机窃取重要敏感数据。
|
||||
|
||||
建议相关用户在确保安全的前提下，及时下载升级官方补丁堵塞漏洞，同时做好类似人工智能大模型应用的安全加固，确保网络和数据安全，发现遭攻击情况第一时间向当地公安机关报告。
|
||||
|
||||
（来源：国家网络安全通报中心）
|
||||
|
||||
|
||||
|
||||
|
||||
43
doc/2025-05/北京警方通报：境外黑客组织利用ComfyUI漏洞对我实施攻击.md
Normal file
43
doc/2025-05/北京警方通报：境外黑客组织利用ComfyUI漏洞对我实施攻击.md
Normal file
@ -0,0 +1,43 @@
|
||||
# 北京警方通报：境外黑客组织利用ComfyUI漏洞对我实施攻击
|
||||
安全内参 2025-05-28 08:05
|
||||
|
||||
**关注我们**
|
||||
|
||||
|
||||
**带你读懂网络安全**
|
||||
|
||||
|
||||
|
||||
目前已有境外黑客组织利用ComfyUI漏洞对我网络资产实施网络攻击，伺机窃取重要敏感数据。
|
||||
|
||||
|
||||
ComfyUI是一款AI绘图工具，专为图像生成任务设计，通过将深度学习模型的工作流程简化为图形化节点，使用户操作更加直观和易于理解。
|
||||
|
||||
近期，北京市网络与信息安全信息通报中心发现，ComfyUI存在任意文件读取、远程代码执行等多个历史高危漏洞（CVE-2024-10099、CVE-2024-21574、CVE-2024-21575、CVE-2024-21576、CVE-2024-21577），攻击者可利用上述漏洞实施远程代码执行攻击，获取服务器权限，进而窃取系统数据。
|
||||
|
||||
目前已有境外黑客组织利用ComfyUI漏洞对我网络资产实施网络攻击，伺机窃取重要敏感数据。
|
||||
|
||||
建议相关用户在确保安全的前提下，及时下载升级官方补丁堵塞漏洞，同时做好类似人工智能大模型应用的安全加固，确保网络和数据安全，发现遭攻击情况第一时间向当地公安机关报告。
|
||||
|
||||
|
||||
**推荐阅读**
|
||||
- [网安智库平台长期招聘兼职研究员](http://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247499450&idx=2&sn=2da3ca2e0b4d4f9f56ea7f7579afc378&chksm=ebfab99adc8d308c3ba6e7a74bd41beadf39f1b0e38a39f7235db4c305c06caa49ff63a0cc1d&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
- [欢迎加入“安全内参热点讨论群”](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247501251&idx=1&sn=8b6ebecbe80c1c72317948494f87b489&chksm=ebfa82e3dc8d0bf595d039e75b446e14ab96bf63cf8ffc5d553b58248dde3424fb18e6947440&token=525430415&lang=zh_CN&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
文章来源：国家网络安全通报中心
|
||||
|
||||
|
||||
点击下方卡片关注我们，
|
||||
|
||||
带你一起读懂网络安全 ↓
|
||||
|
||||
|
||||
|
||||
|
||||
157
doc/2025-05/已公开漏洞的认知“真相”.md
Normal file
157
doc/2025-05/已公开漏洞的认知“真相”.md
Normal file
@ -0,0 +1,157 @@
|
||||
# 已公开漏洞的认知“真相”
|
||||
摄星 数世咨询 2025-05-28 08:00
|
||||
|
||||
当我们过于追逐未公开漏洞与0day漏洞时，却往往忽视了更危险的威胁——那些已被公开却未被认知的漏洞。实际上存在的是，已公开你所知道的，已公开你所不知道的。这种认知上的选择性的安全盲区，本质上成为数字时代的"装聋作哑"。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**0****1**
|
||||
|
||||
|
||||
|
||||
**已公开编号漏洞的重叠度和差异**
|
||||
|
||||
|
||||
|
||||
当前，各国网络安全政策和战略，都强调了漏洞信息的收集、共享和利用。例如，美国的《国家网络安全战略》和中国的《网络安全法》、《网络安全漏洞管理规范》等，都要求加强漏洞信息的管理和服务，促使各国的国家级、行业级漏洞平台不断完善自身的漏洞数据收录和管理体系。
|
||||
|
||||
用户有80%的公开漏洞信息来自这些主流的漏洞平台。然而，由于收录标准、服务对象的差异，这些漏洞平台的漏洞数据既有不同程度的重叠度，又存在不同程度的差异性。随着网络安全形势的不断变化，这种差异化正越来越大。
|
||||
|
||||
根据CVE、CNVD、CNNVD、GitHub等漏洞平台公开的漏洞数据，我们发现，
|
||||
主流漏洞的重叠度竟然不到50%。而这种差异性正在给依赖单一漏洞平台的用户造成认知“盲区”。
|
||||
|
||||
|
||||
|
||||
|
||||
**0****2**
|
||||
|
||||
|
||||
|
||||
**已公开无编号漏洞分散且广泛存在**
|
||||
|
||||
|
||||
|
||||
安全团队或无暇顾及、或选择性认知，从而过度依赖编号漏洞进行风险评估。这种情况导致攻击面持续扩大。据Verizon《数据泄露报告》显示，
|
||||
58%的漏洞利用针对已公开但未修复的漏洞，其中34%涉及无标准编号的漏洞。
|
||||
|
||||
已公开无编号漏洞广泛存在于商业或厂商专有漏洞库、漏洞利用披露组织、学术研究机构、白帽社区、开源软件供应链、攻防演练、工控等行业专用及厂商安全公告中。
|
||||
|
||||
**0****1**
|
||||
|
||||
|
||||
**商业或厂商专有漏洞库**
|
||||
|
||||
|
||||
-厂商专有漏洞库：如微软、谷歌的漏洞库中，约15-30%漏洞未被CVE收录（如内部修复的0day或低危漏洞）。微软每月修复的漏洞中约10%未分配CVE编号（仅内部编号MSRC-XXX）；
|
||||
|
||||
-商业漏洞库（如Tenable、Qualys）：因数据来源和检测工具差异导致约40-60%数据重叠；
|
||||
|
||||
-云安全厂商（如Wiz）收录的云配置错误漏洞，80%未被CVE覆盖（如AWS S3存储桶公开访问等）。
|
||||
|
||||
**0****2**
|
||||
|
||||
|
||||
**漏洞利用披露组织**
|
||||
|
||||
|
||||
-如Exploit-DB、Packet Storm、Metasploit等，与CVE约60-80%重叠。
|
||||
|
||||
**0****3**
|
||||
|
||||
|
||||
**学术研究机构**
|
||||
|
||||
|
||||
-如高校安全实验室发现的漏洞，优先发表于论文而非公开平台，约50%未被商业数据库覆盖。
|
||||
|
||||
**0****4**
|
||||
|
||||
|
||||
**白帽社区**
|
||||
|
||||
|
||||
-典型的，如Bugcrowd等白帽、众测平台提交的漏洞，因厂商直接修复、保密协议或合规要求，约30%未同步至主流漏洞平台。
|
||||
|
||||
**0****5**
|
||||
|
||||
|
||||
**开源软件供应链**
|
||||
|
||||
|
||||
-开源供应链漏洞（如npm、PyPI包）在GitHub Advisory Database中收录率比CVE高35%；
|
||||
|
||||
**0****6**
|
||||
|
||||
|
||||
**攻防演练**
|
||||
|
||||
|
||||
-攻防演练中发现的0day漏洞，因内控或合规要求，约70%未进入漏洞平台数据库。
|
||||
|
||||
**0****7**
|
||||
|
||||
|
||||
**工控等行业专用及厂商安全公告**
|
||||
|
||||
|
||||
-典型的，如工控系统漏洞（如西门子ICS Advisory）中，因影响范围受限，约50%未分配CVE编号；
|
||||
|
||||
-国内操作系统的安全公告中，如龙蜥、统信、麒麟等，约20%的漏洞未提供漏洞编号。
|
||||
|
||||
**0****3**
|
||||
|
||||
|
||||
|
||||
**用户应对建议**
|
||||
|
||||
|
||||
|
||||
用户网络的复杂性和资产类型的丰富性，决定了在风险管理时，需要一个能够覆盖资产类型的漏洞库，避免风险识别“盲区”。
|
||||
|
||||
由于收录标准、来源、时效和服务领域聚焦而导致的漏洞数据重叠和差异，在全球范围内可达40-80%（因组织类型而异），因此
|
||||
需要建立一个多源互补的漏洞数据库，而非依赖单一数据库。
|
||||
|
||||
**0****1**
|
||||
|
||||
|
||||
**制定策略**
|
||||
|
||||
|
||||
基于成本、管理效率考虑，不应且无必要建立大而全的全球漏洞数据库，应根据国家、行业管理要求，结合软硬件供应链资产情况，建立与自身资产关联的定向漏洞数据库。
|
||||
|
||||
**0****2**
|
||||
|
||||
|
||||
**数据源与数据治理**
|
||||
|
||||
|
||||
-优先跟踪CVE、CNVD、CNNVD、GitHub、OSV等主流漏洞平台数据库（覆盖80%以上已公开编号漏洞）；
|
||||
|
||||
-跟踪软硬件清单相关的厂家安全公告、安全社区、漏洞利用披露网站等；
|
||||
|
||||
-参与白帽社区并订阅相关威胁情报；
|
||||
|
||||
-运用NLP技术消解多源漏洞平台重叠漏洞的描述差异，并进行合并；
|
||||
|
||||
-开发漏洞知识图谱，建立漏洞与威胁的关联模型；
|
||||
|
||||
**0****3**
|
||||
|
||||
|
||||
**重视厂商漏洞数据库，优化时效性**
|
||||
|
||||
|
||||
-主流漏洞收录平台一般会协调漏洞与补丁间的关系，通常在厂商推出补丁后才公开漏洞。例如，微软MSRC漏洞数据在每月第二个周二立即更新，早于CVE公开时间，部分Linux内核漏洞延迟数周才分配CVE编号。
|
||||
|
||||
-由于漏洞平台的审核和发布流程，厂商漏洞数据库或安全公告往往比漏洞平台平均早1-5天。漏洞扫描工具则更晚于漏洞平台公布的时间；
|
||||
|
||||
-对高危漏洞（如0day）应依赖厂商直接推送（如微软安全更新）、漏洞情报，而非等待CVE等漏洞平台同步。
|
||||
|
||||
|
||||
— 【 THE END 】—
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,73 @@
|
||||
# 紧急预警！Samlify SSO 签名绕过漏洞（CVE-2025-47949）解析与防御指南
|
||||
云梦DC 云梦安全 2025-05-28 06:05
|
||||
|
||||
引言
|
||||
|
||||
近日，Node.js生态中广泛使用的SAML单点登录库Samlify曝出超危漏洞CVE-2025-47949（CVSS v4.0评分9.9），攻击者可通过构造恶意SAML响应绕过身份验证，甚至直接获取管理员权限！这一漏洞已引发全球安全团队高度关注。本文将深度剖析漏洞原理、攻击手法及防御方案，帮助企业及时应对风险。
|
||||
|
||||
|
||||
一、漏洞本质：XML签名包装攻击（XSW）
|
||||
|
||||
SAML协议依赖XML数字签名确保身份断言（Assertion）的完整性。签名机制的核心在于<ds:Reference>元素中的URI属性，它指定了签名覆盖的XML元素（如[#AssertionID123]()
|
||||
）。然而，Samlify在解析SAML响应时存在逻辑缺陷：
|
||||
|
||||
|
||||
|
||||
签名验证与数据绑定分离：即使签名验证通过，Samlify未严格限定仅使用被签名覆盖的Assertion，而是可能错误提取未经验证的恶意Assertion。
|
||||
|
||||
多Assertion处理漏洞：若响应中包含多个Assertion（如攻击者注入的未签名Assertion），Samlify可能通过宽松的XPath查询（如//saml:Assertion）选择错误节点，导致身份决策被劫持。
|
||||
|
||||
攻击示例：
|
||||
```
|
||||
<samlp:Response ID="ResponseID1">
|
||||
<ds:Signature>
|
||||
<!-- 合法签名仅覆盖AssertionID_Original -->
|
||||
<ds:Reference URI="#AssertionID_Original"/>
|
||||
</ds:Signature>
|
||||
<saml:Assertion ID="AssertionID_Original">普通用户数据</saml:Assertion>
|
||||
<saml:Assertion ID="AssertionID_Malicious">管理员用户数据（未签名）</saml:Assertion>
|
||||
</samlp:Response>
|
||||
```
|
||||
|
||||
攻击者注入恶意Assertion后，Samlify可能误选AssertionID_Malicious作为认证依据。
|
||||
|
||||
二、影响范围与利用场景
|
||||
|
||||
受影响版本：Samlify 2.10.0之前的所有版本。
|
||||
|
||||
攻击成本：低。攻击者只需获取一次合法SAML响应并构造恶意断言，即可绕过认证。
|
||||
|
||||
危害后果：
|
||||
|
||||
非授权用户登录高权限账户（如管理员）。
|
||||
|
||||
企业关键系统（如OA、CRM）遭入侵，数据泄露风险激增。
|
||||
|
||||
三、修复方案与纵深防御
|
||||
|
||||
1. 紧急升级
|
||||
|
||||
立即升级至Samlify 2.10.0+版本。该版本通过以下改进彻底修复漏洞：
|
||||
|
||||
严格绑定签名与Assertion：仅允许使用签名中URI明确指定的Assertion。
|
||||
|
||||
拒绝多Assertion响应：若响应包含未签名Assertion，直接视为无效。
|
||||
|
||||
2. 配置强化
|
||||
|
||||
强制Assertion签名：配置SP（服务提供商）仅接受签名后的Assertion，而非仅验证Response签名。
|
||||
|
||||
校验Issuer与Audience：确保Assertion的颁发者（Issuer）和受众（Audience）符合预期，防止跨租户攻击。
|
||||
|
||||
3. 监控与应急
|
||||
|
||||
日志审计：监控SAML响应中的Assertion数量、签名范围异常，以及频繁认证失败事件。
|
||||
|
||||
渗透测试：模拟XSW攻击，验证修复有效性。
|
||||
|
||||
4. 通用安全实践
|
||||
|
||||
HTTPS全链路加密：防止SAML响应在传输中被篡改。
|
||||
|
||||
最小权限原则：限制SAML断言授予的权限，降低横向渗透风险
|
||||
|
||||
177
doc/2025-05/自学黑客技术多长时间能达到挖漏洞的水平？零基础入门到精通，收藏这篇就够了.md
Normal file
177
doc/2025-05/自学黑客技术多长时间能达到挖漏洞的水平？零基础入门到精通，收藏这篇就够了.md
Normal file
@ -0,0 +1,177 @@
|
||||
# 自学黑客技术多长时间能达到挖漏洞的水平？零基础入门到精通，收藏这篇就够了
|
||||
k哥网络安全 2025-05-28 02:13
|
||||
|
||||
|
||||
抱着一个明确的目的去学习，学习效果能够事半功倍，给你点个赞。
|
||||
|
||||
但值得注意的一个点是：
|
||||
> 任何未经授权的挖洞行为，都是违法的！！！
|
||||
|
||||
任何未经授权的挖洞行为，都是违法的！！！
|
||||
|
||||
任何未经授权的挖洞行为，都是违法的！！！
|
||||
|
||||
|
||||
这一点一定要切记！！！！！！！
|
||||
|
||||
接下来回归主题，你想挖漏洞做副业这个想法是好的，但有时候理想很丰满，现实很骨干。
|
||||
|
||||
从提问描述来看，你之前应该没有深入了解过网络安全，为了避免后面说的东西你理解不了，那我就从新手小白的角度对你的问题进行回答！
|
||||
|
||||
我把知乎上有关
|
||||
**自学网络安全、零基础入门网络安全**
|
||||
的回答大致都浏览了一遍，最大的感受就是“太复杂”，新手看了之后只会更迷茫，还是不知道如何去做，所以站在新手的角度去写回答，应该把回答写的简单易懂，“傻瓜式”的一步步告诉他们应该怎么去做。
|
||||
|
||||
最直接的方式就是给他们一套非常完整的系统视频课程，直接告诉他们，你只需要把这套教程的内容一节一节的都学会理解，把视频教程中所有的作业和案例都做出来，把视频教程中所有的项目都完成，你就可以找到一份网络安全岗位的工作，这是最简单明了的方式。
|
||||
|
||||
在文章的后半部分，我会把一套完整的教学视频发给大家直接学。
|
||||
#### 1、安全基础（Linux+MySQL+Python）
|
||||
|
||||
网络安全这个行业对于编程开发这一块还是有一定要求的，举个简单的例子，你如果想渗透某个网站，那你首先要知道如何去开发一个网站，你连最基本的sql语句都不会写，那又何谈去做sql注入呢。
|
||||
|
||||
所以对各种网络通信协议，对密码学，对前后端，数据库，服务器，shell脚本等内容没有一定的了解，又怎么可能成为一个优秀的hacker呢。
|
||||
|
||||
**要想控制一个人，首先你要了解他，你才能知道他的弱点，最后才能施展你的手段。**
|
||||
|
||||
但无论哪个过程，都需要花费很长的时间与精力去学习与钻研。
|
||||
|
||||
|
||||
|
||||
上面这部分是学习网络安全必备的基础，这部分内容没有多大难度，也没有任何的逻辑性难度，只要多练多看，这部分内容就是熟能生巧的事情。
|
||||
#### 2、安全入门（黑客工具+漏洞挖掘）
|
||||
|
||||
有了前面的计算机网络和编程基础，这一阶段就可以来正式入门网络安全了。
|
||||
|
||||
网络安全领域内几大典型的攻击手法：SQL注入、XSS、CSRF、SSRF、文件上传漏洞等等，每一个都需要详细学习，一边学习理论，一边动手实践。
|
||||
|
||||
|
||||
|
||||
**对了，在这里友情提示一下：**
|
||||
|
||||
**千万注意别拿互联网上的网站来攻击学习！**
|
||||
|
||||
**千万注意别拿互联网上的网站来攻击学习！**
|
||||
|
||||
**千万注意别拿互联网上的网站来攻击学习！**
|
||||
|
||||
**这是违法的行为，重要的事情说三遍**
|
||||
。
|
||||
|
||||
在学习的过程中，你自己可以在虚拟机中搭建一些包含漏洞的网站，拿自己建的网站练手，具体的实战靶场，我在后面也会给大家进行讲解。
|
||||
|
||||
|
||||
|
||||
除了这些攻击方法，这个时候我们也需要对常用渗透工具有一些简单的了解，这也是大部分同学非常感兴趣的一个版块，因为学会这些工具的使用，就可以晋升成为一个脚本小子了。
|
||||
|
||||
包含AWVS、sqlmap、Burp、nessus、chopper、nmap、Appscan等相关工具的使用。
|
||||
|
||||
了解该类工具的用途和使用场景，先用软件名字Google/百度，然后下载无后门版的这些软件进行安装；
|
||||
|
||||
**确立目标：找一份15K的网络安全岗位工作**
|
||||
|
||||
如果你只是想成为一个脚本小子或学着随便玩玩，就不需要再往下看了。下面的内容是写给想要从事网络安全工作人看的，还需要至少学习3个月的时间才能完成。
|
||||
|
||||
我在最上面说过对于新手来说，对他们最友好的方式就是给他们一套从零基础学习最完整的视频教程，然后告诉他们:你只需要把这教程的全部内容都学会，把所有的作业、案例、项目都用代码写出来，你就可以找到一份网络安全的工作。这样是对于新手最简单粗暴的方式，如果我们写的过于专业，他们只会越看越迷茫，对于新手来说就是越简单越好，傻瓜式的学习最有效果。
|
||||
#### 3、安全进阶（内网渗透+DDos攻防+**社会工程学）**
|
||||
|
||||
前面学习了一些Web安全的攻击手法，但光有这些还不够，当我们有流量攻击目标后，如何寻找攻击点，获取目标的信息至关重要。
|
||||
|
||||
|
||||
|
||||
这些信息包括：目标运行了什么操作系统，开放了哪些端口，运行了哪些服务，后端服务是什么类型，版本信息是什么等等，有哪些漏洞可以利用，只有获取到了这些信息，才能有针对性的制定攻击手段。
|
||||
|
||||
除此之外，外网环境和内网环境是不一样的，别到时候从外面渗透，进到里面之后傻眼了，因此收集内部信息的技巧也是重中之重，比如渗透测试架构和windows密码凭证收集等等。
|
||||
|
||||
真正意义上的网络渗透，我觉得应该不只是使用一些现成的工具，去挖一些上古时代的漏洞，而是拥有很强大的自学和分析、解决问题能力，再调用十八般武艺去攻破某个站点。里面不乏自己编写写脚本与工具，自己发现新的攻击注入方式。
|
||||
#### 4、核心能力（安全管理+逆向免杀+**代码审计）**
|
||||
|
||||
到了安全攻防的后期阶段，想成为一个安全高手，绝不只是固步自封在自己擅长的领域，需要多学习网络安全的其他领域，拓展自己的知识面。
|
||||
|
||||
|
||||
|
||||
比如等级保护、应急响应、风险评估、逆向免杀、代码审计、二进制漏洞攻击、木马技术、内核安全、移动安全、侧信道攻击等等，当然在学习的时候，不用像专业方向的同学那么深入，但需要涉猎了解，丰富自己的知识面，构建全方位的网路安全知识技能栈。
|
||||
#### 5、小结
|
||||
|
||||
网络安全要学习的内容非常多非常杂，我以前写过一篇关于网络安全技术知识点的文章，下面评论的人都说内容太多了，根本就学不完之类的话。后来我吸取了教训，对于新手一定要简单粗暴，不能太过于复杂，越是复杂新手看的越迷茫。所以我这次写的内容是精简，初步入行学习这些内容就足够了。
|
||||
#### 6、大多数人必然会放弃：
|
||||
|
||||
这件事情，或者说这个职业。首先你得初衷不能是因为赚钱，因为太容易走歪了，黑产盛行，巨大的利益不断诱惑着通往技术的心，圈内这种沉不下心来浮躁的环境影响了太多的人，当初一起的朋友，现在还有在里面没出来的。
|
||||
|
||||
网络安全涉及的方面太广，对于我们来讲，不是因为这是个工作，而是因为浓厚的求知欲，浓厚的兴趣所引导。
|
||||
|
||||
而没有浓厚的兴趣引导很容易半途而废，原因大部分在于，这个东西并不是想象中的那么美好，学的东西太多 且枯燥 你要承担短时间内没有回报的结果，这很容易让人放弃。
|
||||
|
||||
当然你决心要学的话，我想还是得先学习网络基础，网络交互原理。最好先把TCP/IP啃一遍。有了基础再学习漏洞原理，然后学一门语言来拓扑漏洞的存在原理，到后期可以自己写工具。由浅入深，知其然知其所以然。
|
||||
#### 7、总结
|
||||
|
||||
以上就是我对刚入行网络安全的朋友的一些个人的建议，最后有一点需要说明一下：
|
||||
|
||||
上面列举到的不同方向的技术不是严格意义独立的，相反，很多时候是相辅相成，需要结合起来，融会贯通。
|
||||
|
||||
每个人的认知是有限的，我也不例外。本篇回答只是我的一家之言，建议大家多看一些人的总结和经验，横向对比，兼听则明，偏听则暗。
|
||||
|
||||
如果你想通过自学进入网络安全这一行，我可以把我自己整理收藏的这些教程分享给你，
|
||||
里面不仅有web安全，还有渗透测试等等内容，包含电子书、面试题、pdf文档、视频以及相关的课件笔记，
|
||||
大部分我都看过，感觉还不错，如果需要的话自取。
|
||||
### 题外话
|
||||
|
||||
**黑客&网络安全如何学习**
|
||||
|
||||
今天只要你给我的文章点赞，我私藏的网安学习资料一样免费共享给你们，来看看有哪些东西。
|
||||
|
||||
**1.学习路线图**
|
||||
|
||||
|
||||
|
||||
攻击和防守要学的东西也不少，具体要学的东西我都写在了上面的路线图，如果你能学完它们，你去就业和接私活完全没有问题。
|
||||
|
||||
**2.视频教程**
|
||||
|
||||
|
||||
网上虽然也有很多的学习资源，但基本上都残缺不全的，这是我自己录的网安视频教程，上面路线图的每一个知识点，我都有配套的视频讲解。
|
||||
|
||||
内容涵盖了网络安全法学习、网络安全运营等保测评、渗透测试基础、漏洞详解、计算机基础知识等，都是网络安全入门必知必会的学习内容。
|
||||
|
||||
|
||||
|
||||
（都打包成一块的了，不能一一展开，总共300多集）
|
||||
|
||||
因篇幅有限，仅展示部分资料，需要见下图即可前往获取
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**3.技术文档和电子书**
|
||||
|
||||
|
||||
技术文档也是我自己整理的，包括我参加大型网安行动、CTF和挖SRC漏洞的经验和技术要点，电子书也有200多本，由于内容的敏感性，我就不一一展示了。
|
||||
|
||||
|
||||
|
||||
**4.工具包、面试题和源码**
|
||||
|
||||
|
||||
“工欲善其事必先利其器”我为大家总结出了最受欢迎的几十款款黑客工具。涉及范围主要集中在 信息收集、Android黑客工具、自动化工具、网络钓鱼等，感兴趣的同学不容错过。
|
||||
|
||||
最后就是我这几年整理的网安方面的面试题，如果你是要找网安方面的工作，它们绝对能帮你大忙。
|
||||
|
||||
这些题目都是大家在面试深信服、奇安信、腾讯或者其它大厂面试时经常遇到的，如果大家有好的题目或者好的见解欢迎分享。
|
||||
|
||||
参考解析：深信服官网、奇安信官网、Freebuf、csdn等
|
||||
|
||||
内容特点：条理清晰，含图像化表示更加易懂。
|
||||
|
||||
内容概要：包括 内网、操作系统、协议、渗透测试、安服、漏洞、注入、XSS、CSRF、SSRF、文件上传、文件下载、文件包含、XXE、逻辑漏洞、工具、SQLmap、NMAP、BP、MSF…
|
||||
|
||||
|
||||
|
||||
因篇幅有限，仅展示部分资料，需要见下图即可前往获取
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
919
doc/2025-05/逐帧分析：Kernel Streaming 持续暴露漏洞.md
Normal file
919
doc/2025-05/逐帧分析：Kernel Streaming 持续暴露漏洞.md
Normal file
@ -0,0 +1,919 @@
|
||||
# 逐帧分析：Kernel Streaming 持续暴露漏洞
|
||||
Angelboy securitainment 2025-05-28 08:17
|
||||
|
||||
> 【翻译】Frame by Frame, Kernel Streaming Keeps Giving Vulnerabilities
|
||||
|
||||
|
||||
|
||||
|
||||
这是一系列关于 Kernel Streaming 攻击面的研究。建议先阅读以下文章：
|
||||
- Windows Kernel 中的流媒体漏洞 - 内核代理 - 第一部分
|
||||
|
||||
- Windows Kernel 中的流媒体漏洞 - 内核代理 - 第二部分
|
||||
|
||||
欢迎阅读我关于 Windows 内核流媒体漏洞系列的第三部分。该研究也在 OffensiveCon 2025 上进行了展示。
|
||||
|
||||
在过去的一年中，我们发现了一个被忽视的漏洞类别，称为 Proxying to Kernel
|
||||
（内核代理），它导致了严重的后果，使得在 Windows 内核中的利用变得直接。然而，这只是 Kernel Streaming 漏洞的冰山一角。
|
||||
|
||||
|
||||
|
||||
在发现 Kernel Streaming 中的多个漏洞（包括与代理系列相关的漏洞）后，我们决定深入研究其内部机制。在 2023 年底到 2024 年底之间，我们识别了超过 20 个漏洞。其中大约 14 个与 AVStream 相关，大多数发生在帧处理过程中。在本文中，我将重点讨论这些与帧相关的问题。
|
||||
|
||||
让我们来谈谈内核流媒体帧。
|
||||
## Kernel Streaming 帧概述
|
||||
|
||||
|
||||
|
||||
在 Kernel Streaming 中，当从设备读取数据时，Kernel Streaming 会分配 KS 帧来承载流媒体数据，如视频或音频。
|
||||
```
|
||||
struct _KSPFRAME_HEADER
|
||||
{
|
||||
_LIST_ENTRY ListEntry;
|
||||
_KSPFRAME_HEADER *NextFrameHeaderInIrp;
|
||||
void *Queue;
|
||||
_IRP *OriginalIrp;
|
||||
_MDL *Mdl;
|
||||
_IRP *Irp;
|
||||
KSPIRP_FRAMING_ *IrpFraming;
|
||||
KSSTREAM_HEADER *StreamHeader;
|
||||
void *FrameBuffer;
|
||||
KSPMAPPINGS_TABLE *MappingsTable;
|
||||
unsigned int StreamHeaderSize;
|
||||
unsigned int FrameBufferSize;
|
||||
void *Context;
|
||||
int RefCount;
|
||||
void *OriginalData;
|
||||
void *BufferedData;
|
||||
int Status;
|
||||
unsigned __int8 DismissalCall;
|
||||
_KSPFRAME_HEADER_TYPE Type;
|
||||
_KSPSTREAM_POINTER *FrameHolder;
|
||||
unsigned int OriginalOptionsFlags;
|
||||
_KSPMDLCACHED_STREAM_POINTER *MdlCaching;
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
KS 帧中的帧缓冲区存储着实际的图像或音频数据。大多数帧缓冲区由 Memory Descriptor List (MDL) 描述，它映射了这些缓冲区的物理内存。如果您不熟悉 MDL 是什么，不用担心 —— 这里有一个快速概述。
|
||||
### MDL
|
||||
|
||||
MDL (Memory Descriptor List)
|
||||
是 Windows 内核模式下的一个结构体，用于描述虚拟内存缓冲区背后的物理页。它允许内核组件和驱动程序执行直接内存访问（DMA），并安全地在不同上下文之间共享缓冲区。MDL 在 Windows 内核中被广泛使用，通常与 IRP 结合用于 Direct I/O，以及在文件系统和网络驱动程序中进行数据传输操作。
|
||||
|
||||
MDL (Memory Descriptor List)
|
||||
结构体定义如下：
|
||||
```
|
||||
typedef struct _MDL {
|
||||
struct _MDL *Next;
|
||||
CSHORT Size;
|
||||
CSHORT MdlFlags;
|
||||
struct _EPROCESS *Process;
|
||||
PVOID MappedSystemVa;
|
||||
PVOID StartVa;
|
||||
ULONG ByteCount;
|
||||
ULONG ByteOffset;
|
||||
ULONG64 PFN[]; // Variable-length array of page frame numbers
|
||||
|
||||
} MDL, *PMDL;
|
||||
```
|
||||
|
||||
这是一个可变大小的结构体，其中 **PFN (Page Frame Numbers，页帧号)**数组存储在 MDL 的末尾。每个 PFN 对应 MDL 描述的虚拟缓冲区所对应的物理页。
|
||||
|
||||
在 Kernel Streaming 中，MDL 描述了一个同时映射到用户空间和内核空间的缓冲区，这两个映射都指向相同的物理内存。
|
||||
|
||||
|
||||
|
||||
因此，当从设备读取数据时，数据会同时写入用户模式和内核模式的缓冲区。
|
||||
|
||||
让我们快速了解一下 MDL 的典型用法。
|
||||
#### MDL 的基本使用
|
||||
|
||||
当内核需要访问用户模式内存时——特别是在提升的 IRQL 级别（如 DISPATCH_LEVEL
|
||||
）或 DPC（Deferred Procedure Call，延迟过程调用）中——它通常依赖 MDL 来安全地描述和锁定该内存。通常，这个过程会调用下图所示的一组 API。
|
||||
|
||||
|
||||
#### IoAllocateMDL
|
||||
|
||||
|
||||
|
||||
首先，内核调用 IoAllocateMdl
|
||||
来分配一个 MDL 结构体，根据提供的虚拟地址和长度初始化它来描述一个缓冲区。**但它不会初始化 MDL 中的 PFN（Page Frame Number，页帧号）数组。**
|
||||
#### MmProbeAndLockPages
|
||||
|
||||
|
||||
|
||||
接下来，内核调用 MmProbeAndLockPages
|
||||
来锁定与虚拟地址范围对应的物理页，并填充 MDL 内部的 PFN（Page Frame Number，页帧号）数组。
|
||||
#### MmMapLockedPagesSpecifyCache
|
||||
|
||||
|
||||
|
||||
当内核需要访问内存时，它会调用 MmMapLockedPagesSpecifyCache
|
||||
来**使用 MDL 中存储的 PFN**
|
||||
映射一个新的虚拟地址。
|
||||
|
||||
顺便说一下，也可以使用这个 API 将内核缓冲区映射到用户空间。
|
||||
#### MmUnlockPages/IoFreeMdl
|
||||
|
||||
内核使用完通过 MDL 映射的缓冲区后，必须调用 MmUnlockPages
|
||||
来释放锁定的物理页。最后，应该使用 IoFreeMdl
|
||||
释放 MDL 本身。
|
||||
|
||||
就本文而言，理解 Kernel Streaming 使用 MDL 来管理用户空间和内核空间之间共享的帧缓冲区就足够了。
|
||||
|
||||
如果您对 MDL 的更多细节感兴趣，这里有一些有用的参考资料：
|
||||
- Using MDLs
|
||||
|
||||
- Understanding Memory Descriptor Lists (MDLs) for Windows Vulnerability Research & Exploit Development
|
||||
|
||||
接下来，让我们看看一个典型的应用程序如何从网络摄像头读取数据——以及 Kernel Streaming 在底层如何实现这一功能。
|
||||
### 如何从网络摄像头读取流
|
||||
|
||||
以下是使用 Kernel Streaming 从网络摄像头读取视频流的简化工作流程：
|
||||
|
||||
|
||||
1. 打开设备以获取网络摄像头设备的句柄。
|
||||
|
||||
1. 使用此设备句柄在此过滤器上创建 Pin 的实例并获取 Pin 句柄。
|
||||
|
||||
1. 使用 IOCTL_KS_PROPERTY 将 Pin 的状态设置为 RUN
|
||||
。当 Pin 进入 RUN 状态时，网络摄像头的指示灯通常会亮起，表示设备已激活并准备好进行流传输。
|
||||
|
||||
1. 最后，您可以使用 IOCTL_KS_READ_STREAM 从此 Pin 读取数据。在发送 IOCTL 读取流时，我们需要提供一个 KSSTREAM_HEADER 结构体作为输入以指定必要的信息。
|
||||
|
||||
```
|
||||
typedef struct {
|
||||
ULONG Size;
|
||||
ULONG TypeSpecificFlags;
|
||||
KSTIME PresentationTime;
|
||||
LONGLONG Duration;
|
||||
ULONG FrameExtent; //Buffer Size
|
||||
ULONG DataUsed;
|
||||
PVOID Data; // point to image Buffer
|
||||
ULONG OptionsFlags;
|
||||
ULONG Reserved;
|
||||
} KSSTREAM_HEADER, *PKSSTREAM_HEADER;
|
||||
```
|
||||
|
||||
内核将使用此结构将数据从设备复制到内存中。最重要的字段是 Data
|
||||
（指向用户空间缓冲区）和 FrameExtent
|
||||
（指示缓冲区大小）。Kernel Streaming 将基于这些值映射帧缓冲区，并将图像数据写入提供的内存区域。此外，您还可以使用 OptionsFlags
|
||||
字段来描述帧的属性。
|
||||
### Kernel Streaming 中的流读取
|
||||
|
||||
让我们简要介绍 ks 如何实现帧读取。
|
||||
|
||||
|
||||
|
||||
首先，必须在用户空间分配一个缓冲区来存储传入的图像数据。然后，准备一个包含缓冲区地址和大小的 KSSTREAM_HEADER
|
||||
结构，并通过 IOCTL_KS_READ_STREAM
|
||||
传递给内核。当此 IOCTL 发送到网络摄像头设备时，将由 ksthunk.sys
|
||||
和 ks.sys
|
||||
处理。如果请求不是来自 WoW64 进程，它将被传递给 ks.sys
|
||||
进行进一步处理。
|
||||
|
||||
|
||||
|
||||
ks.sys
|
||||
收到请求后，会解 KSSTREAM_HEADER
|
||||
，根据提供的缓冲区和大小创建 MDL（内存描述符列表），并将其插入 IRP（I/O 请求包）。然后通过此 MDL 将用户空间缓冲区映射到内核空间作为帧缓冲区。此时，用户缓冲区和帧缓冲区都指向相同的物理内存，实现了用户空间和内核空间之间的高效零拷贝数据传输。
|
||||
|
||||
|
||||
|
||||
最后，ks.sys
|
||||
在内核中分配一个 KS Frame (_KSPFRAME_HEADER)
|
||||
。此结构包含关联的 MDL、指向帧缓冲区的指针、缓冲区大小以及用于管理流操作的其他元数据。
|
||||
|
||||
|
||||
|
||||
KS FRAME
|
||||
随后被放入内部队列，等待填充数据。接下来，Kernel Streaming 工作线程从队列中取出一个 KS FRAME
|
||||
，并开始将设备中的图像数据捕获到关联的帧缓冲区中。队列中剩余的 KS FRAME
|
||||
结构将按照入队顺序依次处理。
|
||||
|
||||
|
||||
|
||||
顺便说一下，也可以在单个 IOCTL 调用中提交多个 KSSTREAM_HEADER
|
||||
结构以请求多个帧。在这种情况下，ks.sys
|
||||
将根据输入缓冲区中提供的 KSSTREAM_HEADER
|
||||
数组按顺序处理每个帧请求。每个帧都与一个 KSSTREAM_HEADER
|
||||
、一个 MDL 和一个 KS FRAME
|
||||
存在一一对应关系。
|
||||
|
||||
在了解了架构和帧读取的基础知识后，我们现在可以从攻击者的角度来审视这些内容。
|
||||
### 攻击者视角
|
||||
|
||||
那么，我们应该关注哪些方面呢？
|
||||
|
||||
|
||||
|
||||
第一个也是最直观的目标是 ksthunk.sys
|
||||
和 ks.sys
|
||||
之间的转换层。当 32 位请求转换为 64 位时，对用户控制的 KSSTREAM_HEADER
|
||||
结构的处理不当可能导致内存损坏——例如，CVE-2024-38054 就是这样一个案例。此转换层还可能引入一致性问题。
|
||||
|
||||
|
||||
|
||||
另一个有趣的目标是 ks.sys
|
||||
如何管理帧缓冲区。如果在帧缓冲区处理过程中**误用**
|
||||
了 MDL，可能会导致各种形式的内存损坏。我们稍后将研究这些问题的一些示例。
|
||||
|
||||
在我们的 Kernel Streaming 研究中，我们发现了几个值得注意的新漏洞类别。
|
||||
## Kernel Streaming 中的新漏洞类别
|
||||
|
||||
我们发现的第一个漏洞类别是 MDL 不匹配。
|
||||
### MDL 不匹配
|
||||
|
||||
当 ksthunk.sys
|
||||
收到 32 位请求时，它不仅会将请求转换为其 64 位等效项，还会预分配一个 MDL 来描述帧缓冲区。
|
||||
|
||||
|
||||
|
||||
如图所示，当发出 32 位请求时，ksthunk.sys
|
||||
首先处理它。在此步骤中，它会设置 MDL 并执行帧缓冲区的映射。
|
||||
|
||||
|
||||
|
||||
ksthunk.sys
|
||||
完成预处理后，将 IRP 传递给 ks.sys
|
||||
进行进一步处理。由于 MDL 已经由 ksthunk.sys
|
||||
创建，ks.sys
|
||||
将**不会**
|
||||
分配新的 MDL。此时，会分配一个 KS FRAME
|
||||
来表示 Kernel Streaming 框架中的帧。
|
||||
|
||||
|
||||
|
||||
此外，如果在单次调用中请求了多个帧，ksthunk.sys
|
||||
将预分配所有必要的 MDL 并执行相应的帧缓冲区映射。
|
||||
|
||||
但是，如果 OptionsFlags 字段设置为 KSSTREAM_HEADER_OPTIONSF_PERSIST_SAMPLE (0x8000)
|
||||
，ksthunk.sys
|
||||
将跳过正常的 MDL 分配过程。此标志实际上是 Kernel Streaming 的 MDL 缓存机制的一部分。虽然我们不会在此详细介绍，但重要的是要理解启用此标志**会导致 ksthunk 跳过该帧的 MDL 分配**
|
||||
。
|
||||
|
||||
此外，由于每个帧都是独立处理的，因此可以在提交多个帧的单个请求中，通过为特定帧设置 KSSTREAM_HEADER_OPTIONSF_PERSIST_SAMPLE
|
||||
标志，故意将其标记为缓存。
|
||||
|
||||
让我举个例子：
|
||||
|
||||
|
||||
|
||||
假设我们提交了两个帧，第二个帧被标记为缓存。
|
||||
|
||||
|
||||
|
||||
ksthunk.sys
|
||||
将检查每个帧的 OptionsFlags
|
||||
字段。如果未设置缓存标志，它会分配一个 MDL 并相应地映射帧缓冲区。由于第二个帧**设置了**
|
||||
缓存标志，ksthunk.sys
|
||||
将跳过该帧的 MDL 分配。
|
||||
|
||||
|
||||
|
||||
之后，IRP 被传递给 ks.sys
|
||||
，它将再次检查每个帧的 OptionsFlags
|
||||
字段。然而，这里的逻辑与 ksthunk.sys
|
||||
相反。
|
||||
- 对于第一帧——因为它没有缓存标志——ks.sys 假设 MDL 已经由 ksthunk 分配，因此跳过 MDL 分配。
|
||||
|
||||
- 对于第二帧，由于设置了缓存标志，ks.sys
|
||||
将分配一个新的 MDL 并映射帧缓冲区。
|
||||
|
||||
|
||||
|
||||
ks.sys
|
||||
然后根据 **KSSTREAM_HEADER 条目的顺序**
|
||||
创建 KS FRAME
|
||||
。每个 KSFRAME 都与其对应的 MDL 一一配对，帧被放入内部队列，等待工作线程拉取和处理。
|
||||
> 但是...这真的安全吗？
|
||||
|
||||
|
||||
似乎存在一些不一致。**让我们滥用 MDL 链！**
|
||||
|
||||
|
||||
|
||||
假设我们提交了两个帧：
|
||||
- 对于第一帧，我们将缓冲区大小设置为 0x1000
|
||||
并启用缓存标志。
|
||||
|
||||
- 对于第二帧，我们将缓冲区大小设置为 0x20000
|
||||
，但不设置缓存标志。
|
||||
|
||||
|
||||
|
||||
ksthunk.sys
|
||||
像往常一样检查每个流头。对于第一帧，由于**设置了缓存标志**
|
||||
，它**跳过**
|
||||
了 MDL 分配。对于第二帧，由于未设置缓存标志，ksthunk 分配了一个新的 MDL 并相应地映射了帧缓冲区。
|
||||
|
||||
|
||||
|
||||
之后，IRP 被传递给 ks.sys
|
||||
，它将再次检查每个帧的 OptionsFlags
|
||||
字段。
|
||||
- 对于第一帧，由于设置了缓存标志，ks.sys
|
||||
将分配一个新的 MDL，映射帧缓冲区，并将其插入 MDL 链。
|
||||
|
||||
- 对于第二帧，未设置缓存标志，因此 ks.sys
|
||||
假设 MDL 已经由 ksthunk 分配，因此跳过分配。
|
||||
|
||||
|
||||
|
||||
最后，ks.sys
|
||||
根据 MDL 链和相应的 KSSTREAM_HEADER
|
||||
条目创建 KS FRAME
|
||||
。每个头中的 FrameExtent
|
||||
字段被存储到关联的 KS FRAME
|
||||
中，定义了预期的帧大小。
|
||||
|
||||
|
||||
|
||||
如图所示，第一帧将存储大小为 0x1000，而第二帧将存储大小为 0x20000。
|
||||
|
||||
**你注意到问题了吗？**
|
||||
当我们运行它时...
|
||||
|
||||
|
||||
> 为什么？
|
||||
|
||||
|
||||
|
||||
|
||||
此问题的根本原因是每个 KSSTREAM_HEADER
|
||||
与其对应的 MDL 之间的不匹配。例如，第一个 KSSTREAM_HEADER
|
||||
与第二帧的 MDL 配对，而第二个 KSSTREAM_HEADER
|
||||
最终链接到第一帧的 MDL。
|
||||
> 实际影响是什么？
|
||||
|
||||
|
||||
|
||||
|
||||
当工作线程从设备复制数据时，它依赖于每个 KS FRAME
|
||||
中存储的缓冲区地址和大小来执行复制操作。两个帧的处理方式相同——工作线程参考 KS FRAME
|
||||
结构体来确定复制的位置和数据量。然而，问题就出在这里...
|
||||
|
||||
|
||||
|
||||
对于第二个 KS FRAME
|
||||
，实际分配的缓冲区只有 0x1000
|
||||
字节，但结构体中的 FrameExtent
|
||||
字段却指示大小为 0x20000
|
||||
。结果，工作线程尝试将 0x20000
|
||||
字节复制到一个**小得多的缓冲区**
|
||||
中，导致缓冲区溢出。
|
||||
|
||||
事实上，我们发现的几个漏洞都源于这个问题。只要攻击者能够创建 KSSTREAM_HEADER
|
||||
与其对应 MDL 之间的不匹配，就会导致缓冲区溢出。
|
||||
- CVE-2024-38237
|
||||
|
||||
- CVE-2025-21375
|
||||
|
||||
- ...
|
||||
|
||||
我们要讨论的第二个漏洞类别被称为 MDL 中的遗忘锁
|
||||
——一种涉及 MDL 错误处理的漏洞模式。
|
||||
|
||||
这个漏洞类别有些特殊
|
||||
### 遗忘锁
|
||||
|
||||
实际上，这是 MDL 中的一个**未初始化问题**
|
||||
。
|
||||
|
||||
在讨论这个问题之前，让我们先看看开发者在处理 MDL 时常见的一些错误。
|
||||
#### MDL 的安全风险
|
||||
|
||||
第一个是最近常见的问题——我在之前的文章中也提到过。
|
||||
> MmProbeAndLockPages
|
||||
中错误的 access mode
|
||||
标志
|
||||
|
||||
|
||||
|
||||
|
||||
当内核调用 MmProbeAndLockPages
|
||||
锁定用户提供的内存缓冲区时，可能会错误地设置 access mode
|
||||
标志。这个错误导致内核跳过验证目标地址是否属于用户空间的检查。结果，用户模式进程可以提供内核模式地址，导致内核空间中的任意内存写入。
|
||||
|
||||
更多细节，请参考 Synacktiv 在 HITB 2023 HKT 的演讲和 Nicolas Zilio(@Big5_sec) 的博客文章。
|
||||
> I/O 完成中的双重释放
|
||||
|
||||
|
||||
|
||||
|
||||
另一个常见问题是内核驱动程序释放 MDL 时没有清除 IRP 中对应的 MDL 指针。随后，当 IRP 完成时，系统会尝试再次释放 MDL，导致在 IoCompleteRequest 期间发生双重释放漏洞。这种模式也可以在 Kernel Streaming 中找到 (CVE-2025-24046)。
|
||||
|
||||
|
||||
|
||||
当帧分配失败时，ks.sys
|
||||
会释放 MDL 链中的 MDL，但没有清除存储在 IRP 中的 MDL 指针。结果，当 IRP 完成时，MDL 被再次释放——导致双重释放。
|
||||
|
||||
这两种漏洞模式相当常见，还有许多被忽视的问题。
|
||||
|
||||
让我们以 Microsoft 驱动程序安全指南中的一个例子为例。
|
||||
|
||||
在该文档中，Microsoft 警告说，如果开发人员使用 MmMapIoSpace
|
||||
而没有正确验证物理地址，可能会导致任意物理内存被映射到虚拟地址空间——可能引发严重的安全问题。
|
||||
|
||||
为了说明安全用法，Microsoft 提供了以下安全编码示例：
|
||||
```
|
||||
Func ConstrainedMap(PHYSICAL_ADDRESS paAddress)
|
||||
{
|
||||
// expected_Address must be constrained to required usage boundary to prevent abuse
|
||||
if(paAddress == expected_Address && qwSize == valid_Size) //-----[1]
|
||||
{
|
||||
lpAddress = MmMapIoSpace(paAddress, qwSize, ...);
|
||||
pMdl = IoAllocateMdl( lpAddress, ...); //----------[2]
|
||||
MmMapLockedPagesSpecifyCache(pMdl, UserMode, ... ); //-------------[3]
|
||||
}
|
||||
else
|
||||
{
|
||||
return error;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
首先，在 [1] 处验证物理地址。然后，在 [2] 处分配一个 MDL（Memory Descriptor List）来描述映射的内存区域。最后，在 [3] 处调用 MmMapLockedPagesSpecifyCache
|
||||
将物理内存映射到用户空间的虚拟地址。
|
||||
> 现在...你可能会注意到一些奇怪的地方。
|
||||
|
||||
|
||||
正如我们前面提到的，在典型用法中，分配 MDL 后，应该先调用 MmProbeAndLockPages
|
||||
来锁定底层物理页。然而，在这个例子中，代码直接调用了 MmMapLockedPagesSpecifyCache
|
||||
，而没有先锁定页面。这会导致未定义行为，因为 MDL 可能无法正确描述有效或可访问的物理内存。
|
||||
|
||||
|
||||
|
||||
如上图所示，IoAllocateMdl
|
||||
用于分配 MDL 结构并初始化一些基本元数据。然而，如果我们立即调用 MmMapLockedPagesSpecifyCache
|
||||
而没有先锁定页面，该函数仍会尝试访问 MDL 内部的 PFN（Page Frame Number）数组。这可能导致未定义行为，或者更糟，导致可控的内存损坏。在许多情况下，这会直接导致蓝屏死机（BSoD）。
|
||||
|
||||
|
||||
|
||||
然而，这种错误在 Kernel Streaming 中普遍存在。在下一节中，我将分析 CVE-2024-38238，它清楚地展示了这个问题在实际中的表现。
|
||||
#### CVE-2024-38238
|
||||
|
||||
我们再次构建两个 KSSTREAM_HEADER
|
||||
结构——这次两个帧的大小相同。第一个帧设置了缓存标志，而第二个帧没有。
|
||||
|
||||
|
||||
|
||||
如前所述，ksthunk.sys
|
||||
只会为没有设置缓存标志的帧分配并锁定 MDL。完成后，IRP 会被传递给 ks.sys
|
||||
进行进一步处理。
|
||||
|
||||
现在，让我们仔细看看 ks.sys
|
||||
如何处理这个帧。
|
||||
```
|
||||
__int64 CKsMdlcache::MdlCacheHandleThunkBufferIrp(...)
|
||||
{
|
||||
...
|
||||
while(TotalSize >= sizeof(KSSTREAM_HEADER)){ //-------[4]
|
||||
...
|
||||
if(OptionsFlag & 0x8000 == 0) //-------[5]
|
||||
return KsProbeStreamIrp(irp, a3, 0); //-------[8]
|
||||
IoAllocateMdl(header->Data,header->FrameExtent,...,Irp); //-------[6]
|
||||
}
|
||||
...
|
||||
for(i = irp->MdlAddress;i;i = i->Next){
|
||||
MmProbeAndLockPages(i, irp->RequestorMode, IoWriteAccess); //-------[7]
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
观察 ks!CKsMdlcache::MdlCacheHandleThunkBufferIrp
|
||||
函数中的 while 循环 [4]，我们可以看到它会遍历每个 KSSTREAM_HEADER
|
||||
结构，并在 [5] 处检查 OptionsFlag
|
||||
标志以确定是否需要分配 MDL（Memory Descriptor List）。
|
||||
|
||||
如果设置了缓存标志，程序会在 [6] 处分配一个新的 MDL。在 WOW64 环境下，如果 MDL 已经被分配（例如由 ksthunk 分配），KS（Kernel Streaming）随后会在 [7] 处调用 MmProbeAndLockPages
|
||||
来锁定内存页。
|
||||
|
||||
然而，在我们的特定案例中：
|
||||
- 第一个帧设置了缓存标志
|
||||
|
||||
- 第二个帧没有设置缓存标志
|
||||
|
||||
因此，当 KS 开始处理第二个帧时，它会转向 [8] 处的 KsProbeStreamIrp 路径。此时，IRP（I/O Request Packet）中的 MDL 链情况如下：
|
||||
|
||||
|
||||
|
||||
第一个 MDL 已经被正确锁定，但第二个 MDL 完全没有被锁定。
|
||||
|
||||
之后，ks!KsProbeStreamIrp
|
||||
会处理帧缓冲区的映射：
|
||||
```
|
||||
NTSTATUS KsProbeStreamIrp(PIRP Irp, ULONG ProbeFlags, ULONG HeaderSize){
|
||||
...
|
||||
MDL = Irp->MdlAddress;
|
||||
if ( (MDL->MdlFlags & is_locked_and_nonpaged) != 0 ) { //----[9]
|
||||
while ( MDL )
|
||||
{
|
||||
if ( (MdlFlags & 5) != 0 )
|
||||
MappedSystemVa = MDL->MappedSystemVa;
|
||||
else
|
||||
MappedSystemVa = MmMapLockedPagesSpecifyCache(MDL, 0, MmCached, 0LL, 0, 0x40000010u);
|
||||
|
||||
MDL = MDL->Next;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
如上所示，该函数使用 MmMapLockedPagesSpecifyCache
|
||||
通过每个 MDL 映射帧缓冲区。如果 MDL 被标记为已锁定，函数会直接映射它。然而，这里存在一个关键缺陷：它在 [9] 处仅检查 MDL 链中的第一个 MDL，并假设整个链已经被锁定。
|
||||
|
||||
|
||||
|
||||
当在第二个 MDL 上调用 MmMapLockedPagesSpecifyCache
|
||||
时，它会尝试基于未初始化的 PFN（Page Frame Number，页帧号）列表映射内存。
|
||||
> 不可利用？
|
||||
|
||||
|
||||
好消息是 IoAllocateMdl
|
||||
从 NonPagedPoolNx 分配内存时不会进行零初始化。这意味着位于 MDL 结构末尾的 PFN 数组将包含残留的内存数据。
|
||||
|
||||
|
||||
|
||||
如上图所示，当 IoAllocateMdl 分配内存时，它使用了 POOL_FLAG_UNINITIALIZED 标志，并且不会初始化 MDL 中的 PFN 数组。这种行为允许我们应用池喷射（pool spraying）技术来部分或完全控制 MDL 内部的 PFN 值。
|
||||
|
||||
通过计算 MDL 结构的确切大小——包括基于帧大小的 PFN 数量——我们可以使用 Named Pipes 进行池喷射，用精心构造的数据填充 NonPagedPoolNx
|
||||
内存。
|
||||
|
||||
|
||||
|
||||
当 IoAllocateMdl
|
||||
重用这些内存而不进行零初始化时，残留的值将被解释为有效的 PFN，从而使攻击者能够控制物理到虚拟的映射。
|
||||
|
||||
|
||||
|
||||
如上图所示，当随后调用 MmMapLockedPagesSpecifyCache
|
||||
时，它会将攻击者控制的 PFN 视为有效的物理页映射，并使用它们来映射帧缓冲区。
|
||||
|
||||
最后，当工作线程从设备复制图像数据时，它会直接写入攻击者指定的物理地址，从而产生一个强大的任意物理内存写入原语。
|
||||
|
||||
实际上，并非所有 PFN 都可以被映射——它们必须是有效的，例如 ResidentPage
|
||||
。但对于我们的目的来说，这已经足够了。
|
||||
|
||||
下一步是使用任意物理内存写入原语实现权限提升（EoP，Elevation of Privilege）。但这引出了一个问题：
|
||||
> 我们应该写入哪里？
|
||||
|
||||
|
||||
在对多个 Windows 24H2 进行测试时，我们观察到一个一致的行为：ntoskrnl.exe
|
||||
的物理基地址通常固定在 0x100400000。
|
||||
|
||||
|
||||
|
||||
我们在 Hyper-V 和 VMware 上进行了测试。这个值可能在更新的版本中有所变化，但在许多情况下仍然可能保持固定。这种行为也可能取决于设备或硬件配置。
|
||||
> 那么...这是否意味着我们可以直接写入 nt 并接管内核？
|
||||
|
||||
|
||||
这里有一个问题......
|
||||
|
||||
|
||||
|
||||
我们无法控制被写入的数据，因为它直接来自网络摄像头设备。
|
||||
|
||||
最初，我们似乎陷入了困境。但拥有如此强大的原语——稳定且可重复的任意物理内存写入——我们知道一定有办法继续前进。
|
||||
|
||||
于是我们回过头，仔细审查了整个 Kernel Streaming 的工作流程，最终发现了一个新的攻击角度。
|
||||
> 缓冲模式
|
||||
|
||||
|
||||
Kernel Streaming 提供了一个称为缓冲模式（buffered mode）的功能。当使用 **缓冲标志（KSSTREAM_HEADER_OPTIONSF_BUFFEREDTRANSFER）**
|
||||
创建 KS FRAME
|
||||
时，ks.sys
|
||||
会在内核空间分配一个额外的中间缓冲区。
|
||||
|
||||
|
||||
|
||||
|
||||
在流传输过程中，原始图像缓冲区的内容首先被复制到这个中间缓冲区。
|
||||
|
||||
|
||||
|
||||
|
||||
如上图所示，在设备完成数据写入后——或者传输过程中发生错误时——ks.sys
|
||||
会将缓冲内存的内容复制到帧缓冲区。然而，在我们的案例中，这个帧缓冲区已经被映射到 ntoskrnl.exe
|
||||
映像的物理地址。换句话说，我们现在拥有了一个具有完全控制数据的 **任意物理内存写入原语**
|
||||
。这为直接修改内核代码打开了大门。
|
||||
|
||||
|
||||
|
||||
在我们的漏洞利用中，我们选择覆盖 PsOpenProcess 中的一个安全检查。具体来说，我们将 SeDebugPrivilege
|
||||
的检查替换为 SeChangeNotifyPrivilege
|
||||
。结果，任何普通用户都可以打开高权限进程（除了 PPL）。有关用 SeChangeNotifyPrivilege
|
||||
替换检查的技术的更多细节，您可以参考 我的前一篇文章。
|
||||
|
||||
在 Kernel Streaming 中，有多种方式可以导致这个问题：
|
||||
- CVE-2024-38238
|
||||
|
||||
- CVE-2024-38241
|
||||
|
||||
- CVE-2025-24066
|
||||
|
||||
- ...
|
||||
|
||||
只要找到一种方法让它忘记锁定，就可能导致任意物理内存写入。
|
||||
|
||||
我们要分享的最后一个问题是 **帧缓冲区错位**
|
||||
。
|
||||
### 帧缓冲区错位 (CVE-2024-38245)
|
||||
|
||||
在深入探讨之前，我们首先需要介绍 Kernel Streaming 中的一个关键对象：KS Allocator。KS Allocator 负责预分配一组可以在流操作期间重用的帧缓冲区。这显著减少了运行时动态内存分配的开销。通常，一个分配器对象与一个 pin 相关联，第三方驱动程序也可以实现自己的自定义分配器。Kernel Streaming 还提供了一个默认分配器，在没有自定义实现时使用。
|
||||
|
||||
通常，可以使用 KsCreateAllocator API 创建 KS Allocator，并通过称为 KSALLOCATOR_FRAMING 的结构进行配置。该结构允许您指定参数，例如帧缓冲区的数量、每个缓冲区的大小，甚至每个帧缓冲区的对齐要求。
|
||||
```
|
||||
typedef struct {
|
||||
union {
|
||||
ULONG OptionsFlags;
|
||||
ULONG RequirementsFlags;
|
||||
};
|
||||
#if ...
|
||||
POOL_TYPE PoolType;
|
||||
#else
|
||||
ULONG PoolType;
|
||||
#endif
|
||||
ULONG Frames;
|
||||
ULONG FrameSize;
|
||||
union {
|
||||
ULONG FileAlignment;
|
||||
LONG FramePitch;
|
||||
};
|
||||
ULONG Reserved;
|
||||
} KSALLOCATOR_FRAMING, *PKSALLOCATOR_FRAMING;
|
||||
```
|
||||
|
||||
**注意：**
|
||||
要指定帧缓冲区的对齐方式，您必须在分配器配置期间提供对齐掩码。
|
||||
|
||||
创建 KS Allocator 后，我们可以将其附加到 Pin 上。在从 Pin 读取数据之前，需要将其状态设置为 **KSSTATE_RUN**
|
||||
。
|
||||
|
||||
|
||||
|
||||
此时，分配器将根据之前提供的配置预分配帧缓冲区。
|
||||
|
||||
|
||||
|
||||
从这时起，数据将从设备流式传输到预分配的帧缓冲区中。同时也会分配相应的 KS FRAME
|
||||
结构。当我们发送 IOCTL_KS_READ_STREAM
|
||||
来读取数据时，过程将如前所述开始。
|
||||
|
||||
|
||||
|
||||
然而，与每次从设备读取数据不同，工作线程将从分配器管理的预分配帧缓冲区中复制数据。在接下来的部分中，我们将重点讨论默认分配器如何管理这些预分配缓冲区。
|
||||
|
||||
让我们深入了解 **DefaultAllocator**
|
||||
。
|
||||
|
||||
ks!KsCreateDefaultAllocatorEx 
|
||||
|
||||
|
||||
当我们调用 KsCreateAllocator
|
||||
时，Kernel Streaming 会创建一个默认分配器，并使用我们提供的参数对其进行初始化。在内部，ks.sys
|
||||
实现了自己的自定义分配例程 - DefAllocatorAlloc
|
||||
和 DefAllocaorFree
|
||||
，并利用 LookasideList 来高效管理缓冲区的分配和重用。
|
||||
|
||||
分配函数非常简单：
|
||||
```
|
||||
char *__fastcall DefAllocatorAlloc(POOL_TYPE PoolType, SIZE_T NumberOfBytes, ULONG Alignment)
|
||||
{
|
||||
...
|
||||
if ( Alignment >= FILE_OCTA_ALIGNMENT )
|
||||
FileAlignment = Alignment;
|
||||
...
|
||||
buffer = ExAllocatePoolWithTag((PoolType | 0x400), v8, 'adSK');//-----[10]
|
||||
if ( buffer )
|
||||
{
|
||||
padding = (~FileAlignment & (buffer + FileAlignment + 4)) - buffer;
|
||||
buffer += padding;
|
||||
*(buffer - 1) = padding; //-------[11]
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
它直接调用 ExAllocatePoolWithTag 在 [10] 处分配内存。如果指定了对齐方式，ks.sys
|
||||
会在帧缓冲区前记录所需的填充大小，如 [11] 处所示。
|
||||
|
||||
在释放例程中：
|
||||
```
|
||||
void __fastcall DefAllocatorFree(unsigned int *Buffer)
|
||||
{
|
||||
__int64 padding;
|
||||
...
|
||||
if ( (Buffer & 0xFFF) != 0 )
|
||||
padding = *(Buffer - 1); //---------------[12]
|
||||
else
|
||||
padding = 0LL;
|
||||
ExFreePoolWithTag(Buffer - padding, 0);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
KS 使用这个填充大小来计算 ExAllocatePoolWithTag 在 [12] 处返回的原始指针。
|
||||
|
||||
如下图所示，内存池的布局如下：
|
||||
|
||||
|
||||
|
||||
紫色区域代表填充部分，蓝色区域对应帧缓冲区本身。帧缓冲区前面的 4 个字节用于存储填充大小。在正常情况下，对齐掩码应该是 2 的幂减一（例如 0x3F、0xFFF 等）。
|
||||
|
||||
然而，这里存在一个问题：
|
||||
|
||||
|
||||
|
||||
KS 只检查对齐掩码是否大于 0xFFF。如果小于 0xFFF，它会接受任何值，即使这不是一个有效的对齐方式。
|
||||
> 无用的漏洞？
|
||||
|
||||
|
||||
乍一看，这可能像是一个无害的漏洞——只是一个内存对齐的小问题。但是当这个未对齐的缓冲区遇到 LookasideList
|
||||
时会发生什么？
|
||||
#### LookasideList
|
||||
|
||||
LookasideList
|
||||
是针对固定大小内存块优化的每处理器缓存。它们不使用通用的池分配器，而是维护一个简单的单向链表以实现快速分配和释放。**分配和释放操作总是先检查链表，然后再使用通用池，链表按照后进先出（LIFO）的顺序操作。**
|
||||
一个重要的约束是存储在 LookasideList
|
||||
中的条目**需要对齐到 0x10 字节**
|
||||
。可以参考 SLIST_ENTRY
|
||||
。
|
||||
|
||||
正如你在 ExAllocateFromNPagedLookasideList
|
||||
中看到的：
|
||||
```
|
||||
PSLIST_ENTRY ExAllocateFromNPagedLookasideList(...){
|
||||
...
|
||||
ReturnChunk = ListHead->FreeChunk & 0xFFFFFFFFFFFFFFF0;
|
||||
ListHead->FreeChunk = ReturnChunk->Next;
|
||||
ListHead->Depth-- ;
|
||||
...
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
分配逻辑在将内存块返回给调用者之前，会将其地址对齐到 0x10 字节（16 字节对齐）。
|
||||
```
|
||||
PSLIST_ENTRY ExFreeToNPagedLookasideList(...,PSLIST_ENTRY Chunk){
|
||||
...
|
||||
NextChunk = ListHead->FreeChunk & 0xFFFFFFFFFFFFFFF0
|
||||
Chunk->Next = NextChunk;
|
||||
ListHead->FreeChunk = Chunk;
|
||||
ListHead->Depth++;
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
同样地，当内存被释放回 LookasideList
|
||||
时，它也会对齐内存块。如上文代码片段所示，释放例程会对链表中的第一个条目进行对齐。
|
||||
> 非 0x10 字节对齐的帧缓冲区 + LookasideList
|
||||
|
||||
|
||||
那么，如果一个没有 0x10 字节对齐的帧缓冲区被插入到 LookasideList
|
||||
中会发生什么？
|
||||
#### 让我们玩转帧缓冲区
|
||||
|
||||
|
||||
|
||||
我们编写了一个脚本来列出所有可能的对齐掩码和填充大小。在这个案例中，我们使用了一个导致 8 字节填充的对齐掩码。然后，我们配置分配器预先分配 4 个帧缓冲区。结果，每个缓冲区都将遵循相同的布局——由于 8 字节填充，最终的帧缓冲区地址都以 0x08 结尾。
|
||||
|
||||
缓冲区将如下图所示：
|
||||
|
||||
|
||||
之后，分配器返回四个缓冲区——A、B、C 和 D——由于应用的填充，它们的地址都以 0x8 结尾。
|
||||
|
||||
|
||||
|
||||
当这些缓冲区被释放时，ks.sys
|
||||
会逐个释放它们，并按顺序将它们插入 LookasideList
|
||||
。
|
||||
|
||||
|
||||
|
||||
如上图所示，我们首先释放 Frame A
|
||||
，它被顺利插入到 LookasideList
|
||||
中。
|
||||
|
||||
|
||||
|
||||
当 Frame B
|
||||
被释放时，分配器首先对齐当前链表头（Frame A
|
||||
）的地址以满足 0x10 字节对齐要求。**然后将这个对齐后的地址存储在 Frame B 的 next 指针字段中**
|
||||
，并将 Frame B 插入到 LookasideList
|
||||
的头部。
|
||||
|
||||
|
||||
|
||||
我们继续释放 Frame C
|
||||
和 Frame D
|
||||
，它们都遵循与之前相同的模式。最终，LookasideList
|
||||
将如上图所示的布局。
|
||||
> 你发现问题了吗？
|
||||
|
||||
|
||||
问题在于 Frame D
|
||||
的 **next 指针**
|
||||
。由于对齐，**next 指针最终指向了池块的起始位置，而不是实际的帧缓冲区**
|
||||
。
|
||||
|
||||
|
||||
|
||||
如上图所示，你会注意到 Frame C
|
||||
的 next 指针指向了填充区域，该区域包含存储的填充大小，而不是预期的链表条目结构。当被解释为 64 位值时，这个指针变成了类似 0x800000000
|
||||
的值——这属于用户空间地址范围。
|
||||
|
||||
我们的计划是在 0x800000000
|
||||
处分配一个内存页，从而获得对 LookasideList
|
||||
的控制。然后，我们将链表中的最后一个节点配置为指向我们期望的目标地址。之后，当设备执行读取操作时，ks.sys
|
||||
会将传入的数据写入这些帧缓冲区——包括指向我们选择地址的那个缓冲区。
|
||||
|
||||
|
||||
> 理论上，这给了我们一个任意内存写入原语，对吗？
|
||||
|
||||
|
||||
然而，我们仍然面临与之前相同的限制：我们无法控制被写入的内容。
|
||||
|
||||
|
||||
|
||||
此外，我们无法在此场景中使用 buffered flag
|
||||
，这意味着我们只能使用设备发送的任何数据——这使得精确利用变得更加困难。
|
||||
|
||||
此时，我们再次陷入了困境。
|
||||
|
||||
|
||||
|
||||
但在再次思考后，我们找到了另一种前进的方法。
|
||||
#### 让 LookasideList 再次伟大
|
||||
|
||||
|
||||
|
||||
如上图所示，我们首先在用户空间构建一个虚假的链表。地址 0x41410000
|
||||
代表一个用户控制的内存区域，我们用它来构建一个有效的 LookasideList
|
||||
条目。然后，我们继续分配帧缓冲区，这导致分配器遍历我们构建的虚假链表。
|
||||
|
||||
|
||||
|
||||
在 ExAllocateFromNPagedLookasideList
|
||||
中，分配器首先对齐内存块，然后更新链表头。然而，由于未对齐，对齐逻辑错误地**将 Frame D 的起始位置解释为 next 指针**
|
||||
——导致 LookasideList
|
||||
的遍历错误。
|
||||
|
||||
|
||||
|
||||
一旦第一个块从链表中弹出，链表就会转变为上图所示的状态。接下来，我们从 LookasideList
|
||||
中分配所有剩余的块。我们还配置分配器使用较小的帧缓冲区，这导致网络摄像头**进入等待状态——它不再从设备读取数据**
|
||||
。然后，我们触发 STOP 以释放所有帧缓冲区。
|
||||
|
||||
|
||||
|
||||
帧缓冲区将如上图所示。此时，ks.sys
|
||||
开始逐个将缓冲区返回到 LookasideList
|
||||
。首先，它释放 Frame D
|
||||
。然后，它释放位于 0x800000000
|
||||
的恶意块。之后，它释放位于 0x41410000
|
||||
的虚假块。
|
||||
|
||||
|
||||
|
||||
一旦这三个块被释放，LookasideList
|
||||
的结构就会转变为上图所示的布局。最终，分配器将释放我们的目标地址。
|
||||
|
||||
|
||||
|
||||
**这将导致目标地址的 next 指针指向 0x41410000**
|
||||
。这个值可以是攻击者控制的任何用户空间地址。
|
||||
|
||||
|
||||
|
||||
换句话说，我们现在拥有了一个强大的任意内存写入原语。
|
||||
|
||||
在 Windows 23H2 上获得任意内存写入能力后，我们可以使用 NtQuerySystemInformation 来泄露线程对象的地址。有了这个地址，我们翻转 token 结构中的必要位以提升权限。从这里，我们可以应用任何众所周知的 EoP 技术来实现完整的权限提升。顺便说一句，一旦你实现了任意内存写入，**别忘了将 LookasideList 恢复到有效状态**
|
||||
——否则，系统可能会在后续分配期间崩溃。
|
||||
|
||||
我们成功地将一个看似无害的漏洞变成了一个严重的漏洞。
|
||||
## 下一步与总结
|
||||
|
||||
这种漏洞模式可能不仅限于 Kernel Streaming。通过更密切地关注 MDL 相关问题，你可能会在其他驱动程序中发现更多漏洞。Kernel Streaming 仍然是一个引人入胜的研究目标，其表面之下可能还隐藏着许多未被发现的漏洞。
|
||||
|
||||
深入了解 Windows API 的实现——并认识到其误用的风险——对于发现新漏洞和构建有效的利用技术至关重要。
|
||||
> 记住这些模式——它可能是你的下一个漏洞。
|
||||
|
||||
## 参考
|
||||
- 使用 MDLs
|
||||
|
||||
- Windows 内核安全 - Pwn2Own 演示的两个漏洞的深入分析
|
||||
|
||||
- CVE-2023-29360 分析
|
||||
|
||||
- 简单的本地 Windows 内核利用
|
||||
|
||||
## Resources
|
||||
|
||||
<table><thead><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><th style="font-size: 16px;border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-weight: bold;background-color: #f0f0f0;min-width: 85px;"><section><span leaf="">Hyperlink</span></section></th><th style="font-size: 16px;border: 1px solid #ccc;padding: 5px 10px;text-align: left;font-weight: bold;background-color: #f0f0f0;min-width: 85px;"><section><span leaf="">Info</span></section></th></tr></thead><tbody><tr style="border: 0;border-top: 1px solid #ccc;background-color: white;"><td style="font-size: 16px;border: 1px solid #ccc;padding: 5px 10px;text-align: left;min-width: 85px;"><section><span leaf="">https://devco.re/blog/2025/05/17/frame-by-frame-kernel-streaming-keeps-giving-vulnerabilities-en/</span></section></td><td style="font-size: 16px;border: 1px solid #ccc;padding: 5px 10px;text-align: left;min-width: 85px;"><section><span leaf="">Angelboy</span></section></td></tr></tbody></table>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user