mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-24 08:54:27 +00:00
正在获取URL...
chainreactors: 0 个URL BruceFeIix: 0 个URL Doonsec: 37 个URL 总共去重后: 37 个URL Black Hat USA 2026：.NET类型转换RCE、漏洞预警 | cPanel&WHM SQL注入漏洞、Windows BitLocker漏洞允许攻击者远程执行恶意代码、投毒、RCE、提权窃密：深度复盘OpenAI智能体发起的这波高阶供应链攻击、漏洞名称权限参数值规范化缺失导致的权限绕过、我花6000块买的SRC技能包，最值钱的不是漏洞打法，是那90行“假点”清单、SAP 修复 CVSS 10.0 内核漏洞，该漏洞允许未经身份验证的远程代码执行、红队固件级漏洞挖掘工具包：moria + mithril 全离线、可空气隔离、一次简单的漏洞挖掘背后，我用了白帽集市上的这些资源、还在等什么？黑盒漏洞挖掘agent等你来收货、让 AI 改了五遍，漏洞多了 37.6%：一份 AI 编码安全复查清单、Langflow爆出代码执行漏洞CVE-2026-17633 (POC已公开)、CVE-2025-11395 Podman任意文件写入漏洞、Parallels Desktop 本地提权漏洞 ParaShells：Intel Mac 永久躺枪、漏洞预警 | JumpServer Access Key越权泄露漏洞、DeepSeek Al：POC EXP_工具化与漏洞验证实战与代码审计与央企安全日志分析、CVE-2026-58704：零点击、近距离、间谍级攻击、Check Point 严重登录漏洞可导致远程接管、白帽子的新战友：一个会自己找漏洞的 AI 智能体、
This commit is contained in:
test committed
1 parent
010c1eb5d3
commit
82f773eb52
20 files changed
+2266
-1
No files matched your search
@@ -26848,5 +26848,24 @@
|
||||
"https://mp.weixin.qq.com/s/g7C_-SkNwavzz5K3kODpsg": "众测 30 分钟挖到鸿蒙App高危上传漏洞 | 从 APP 一条异常图片请求，发现被忽略的外围攻击面",
|
||||
"https://mp.weixin.qq.com/s/A0h3oCFG6EB8TEomt5Pxbw": "已复现 | Langflow post-auth RCE",
|
||||
"https://mp.weixin.qq.com/s/di-2_6CBcmYkiEy_lFw8dA": "搜狗输入法 Windows 版远程代码执行漏洞(CVE-2026-51990)",
|
||||
"https://mp.weixin.qq.com/s/dmvcbKBWuy1bldoNOLSDaA": "Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability(CVE-2026-85893)"
|
||||
"https://mp.weixin.qq.com/s/dmvcbKBWuy1bldoNOLSDaA": "Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability(CVE-2026-85893)",
|
||||
"https://mp.weixin.qq.com/s/4qCVhYUMEBac6u4BsJbHkg": "Black Hat USA 2026：.NET类型转换RCE",
|
||||
"https://mp.weixin.qq.com/s/wydc3xRVypiRJTC5ggnzZQ": "漏洞预警 | cPanel&WHM SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/C_Cwnay_Hkfoz52ETYuCFQ": "Windows BitLocker漏洞允许攻击者远程执行恶意代码",
|
||||
"https://mp.weixin.qq.com/s/4HWdWBzvbueHgd_3EHj41w": "投毒、RCE、提权窃密：深度复盘OpenAI智能体发起的这波高阶供应链攻击",
|
||||
"https://mp.weixin.qq.com/s/NNXcguncp4LDABaQ1OBDMQ": "漏洞名称权限参数值规范化缺失导致的权限绕过",
|
||||
"https://mp.weixin.qq.com/s/wFhxhtQv-xxtNu4U6c2Q3A": "我花6000块买的SRC技能包，最值钱的不是漏洞打法，是那90行“假点”清单",
|
||||
"https://mp.weixin.qq.com/s/itx8ZMxsqgenumrS1LOY1w": "SAP 修复 CVSS 10.0 内核漏洞，该漏洞允许未经身份验证的远程代码执行",
|
||||
"https://mp.weixin.qq.com/s/fEn4e7uDkEbhF5vQmGNEjw": "红队固件级漏洞挖掘工具包：moria + mithril 全离线、可空气隔离",
|
||||
"https://mp.weixin.qq.com/s/lHDQi-ujQWNLI22YlFj8dQ": "一次简单的漏洞挖掘背后，我用了白帽集市上的这些资源",
|
||||
"https://mp.weixin.qq.com/s/Mkn-yWDWJmZ8x8q_MVUQUA": "还在等什么？黑盒漏洞挖掘agent等你来收货",
|
||||
"https://mp.weixin.qq.com/s/LZ1EGlIg2ce0FVQe1bRlQA": "让 AI 改了五遍，漏洞多了 37.6%：一份 AI 编码安全复查清单",
|
||||
"https://mp.weixin.qq.com/s/Zj7HcnoBWeehoW0gdTuAMg": "Langflow爆出代码执行漏洞CVE-2026-17633 (POC已公开)",
|
||||
"https://mp.weixin.qq.com/s/kkoDPby6QVu3Y-r4dVZApg": "CVE-2025-11395 Podman任意文件写入漏洞",
|
||||
"https://mp.weixin.qq.com/s/0v2vugZitjf_qj704pVQAQ": "Parallels Desktop 本地提权漏洞 ParaShells：Intel Mac 永久躺枪",
|
||||
"https://mp.weixin.qq.com/s/vj9ZCEnRV2wnyD7_iRnZ2A": "漏洞预警 | JumpServer Access Key越权泄露漏洞",
|
||||
"https://mp.weixin.qq.com/s/1IRY1AJ_ETCgk5fy6nwTtw": "DeepSeek Al：POC EXP_工具化与漏洞验证实战与代码审计与央企安全日志分析",
|
||||
"https://mp.weixin.qq.com/s/qa_mSab3iGXl9Bk-O0OKuQ": "CVE-2026-58704：零点击、近距离、间谍级攻击",
|
||||
"https://mp.weixin.qq.com/s/wX2MQJyGN4gkEAkxdEXTkw": "Check Point 严重登录漏洞可导致远程接管",
|
||||
"https://mp.weixin.qq.com/s/hVfISmQ0u7zrZ8QI25dZjQ": "白帽子的新战友：一个会自己找漏洞的 AI 智能体"
|
||||
}
|
||||
@@ -0,0 +1,453 @@
|
||||
# Black Hat USA 2026：.NET类型转换RCE
|
||||
原创 Max Luo
|
||||
Max Luo 白帽子罗棋琛 2026-09-17 00:16
|
||||
|
||||
# 字符串如何变成 RCE：.NET 类型转换层的隐形攻击面
|
||||
> Black Hat USA 2026 议题笔记：Transformers: Dark Side of the Type - Weaponizing the Conversion Layer
|
||||
|
||||
|
||||
很多 .NET 安全检查已经会盯住 BinaryFormatter.Deserialize()
|
||||
、Json.NET TypeNameHandling
|
||||
和 XAML 反序列化，却很少有人把 TypeDescriptor.GetConverter()
|
||||
、反射调用 Parse()
|
||||
或 new T(string)
|
||||
当成同一等级的边界。问题在于，应用不一定需要序列化器才能完成“外部数据选择类型，再执行这个类型的代码”。一个类型名和一个普通字符串就够了。
|
||||
|
||||
Oleksandr Mirosh 在公开课件与白皮书中把这类问题命名为 **Insecure String Transformation**
|
||||
。它不是给反序列化换一个新名字，而是在序列化器之外单独标出一块长期漏审的攻击面：转换层接收字符串，动态解析目标类型，随后通过 TypeConverter、静态工厂、构造器、属性访问器或自定义逻辑创建对象。如果目标类型缺少严格约束，普通配置值就可能成为网络访问、文件操作、嵌套解析乃至代码执行的入口。
|
||||
|
||||
|
||||
|
||||
图 1：研究关注的不是某一个危险 API，而是“字符串—类型解析—对象构造”这一整类转换边界
|
||||
|
||||
本文基于公开文档和课件整理，不复现 SharePoint 的完整利用载荷，也不提供可直接触发进程启动、XAML 加载或嵌套反序列化的 gadget 参数。重点放在源码识别、可达性判断、修复顺序、回归测试和 SOC 检测。
|
||||
## 1、真正的边界不是序列化器，而是“谁能决定目标类型”
|
||||
|
||||
序列化器之所以危险，不是因为输入长得像 JSON、XML 或二进制，而是它通常同时做了两件事：确定对象类型，再用输入数据实例化或填充对象。过去十年的防守措施大多围绕序列化 API 建立：禁用类型元数据、配置 Binder、淘汰危险序列化器、给 Deserialize()
|
||||
建静态规则。
|
||||
|
||||
但大量框架会用更轻的表示传递简单对象。例如颜色可以写成 #FF0000
|
||||
，坐标写成 3,5
|
||||
，时间写成 ISO 8601 字符串。只要接收方已经知道目标类型，就不需要完整序列化协议。
|
||||
|
||||
|
||||
|
||||
图 2：简单对象可以只携带字符串；当目标类型也来自外部时，转换层便重新拥有了序列化器的关键能力
|
||||
|
||||
风险判断不能停留在“这里没有 Deserialize，所以不是反序列化”。更有效的问题是：
|
||||
|
||||
text
|
||||
```
|
||||
外部输入是否控制 value？ | +-- 外部输入是否直接或间接控制 targetType？ | +-- 程序是否根据 targetType 执行构造或填充逻辑？ | +-- 类型集合是否在解析前被精确限制？
|
||||
```
|
||||
|
||||
|
||||
固定类型的解析通常不是本议题所说的问题。例如 DateTime.TryParse(userValue, ...)
|
||||
的类型在编译期已确定；风险主要来自日期格式、时区和资源消耗，而不是攻击者选择任意 .NET 类型。相反，Type.GetType(userType)
|
||||
后再转换 userValue
|
||||
，已经跨过了另一条安全边界。
|
||||
|
||||
|
||||
|
||||
图 3：转换层没有序列化器参与，却同样完成了“选择类型”和“填充实例”两步
|
||||
|
||||
这一区分也决定了审计范围：不要把所有 Parse
|
||||
都报成高危，否则规则很快会被噪声淹没；应优先寻找“可控类型解析”与“对象构造”在同一路径相遇的位置。
|
||||
## 2、四个条件同时成立，转换器才成为安全漏洞
|
||||
|
||||
课件给出的判定标准很实用。一条转换链要成为不安全字符串转换器，需要同时满足四项：
|
||||
1. 接受攻击者可控字符串；
|
||||
|
||||
1. 转换过程中解析目标类型，类型可来自字符串本身、相邻元数据或另一个参数；
|
||||
|
||||
1. 对解析出的类型进行实例化或属性填充；
|
||||
|
||||
1. 没有充分限制可以解析的类型。
|
||||
|
||||
|
||||
|
||||
图 4：前三项构成动态转换器，第四项把通用能力变成攻击面
|
||||
|
||||
用代码表达，这类实现通常有相似骨架：
|
||||
|
||||
csharp
|
||||
```
|
||||
// 仅用于代码审计示例：不要在生产代码中使用外部输入解析类型。publicstaticobjectConvertUnsafe(string typeName, stringvalue) { Type target = Type.GetType(typeName, throwOnError: true)!; TypeConverter converter = TypeDescriptor.GetConverter(target); return converter.ConvertFromInvariantString(value)!; }
|
||||
```
|
||||
|
||||
|
||||
单看 ConvertFromInvariantString()
|
||||
，审计者可能把它当成普通字符串解析；真正改变风险等级的是上游 typeName
|
||||
的来源。相同骨架还可能把类型放在工作流 XML、ASPX 属性、消息头、数据库配置、插件清单或反射元数据中，而把 value 放在另一个字段。污点分析必须跨字段关联，不能只检查一个参数。
|
||||
|
||||
|
||||
|
||||
图 5：入口格式可以不同，核心始终是外部输入影响类型和字符串，再进入通用对象构造逻辑
|
||||
|
||||
修复前应给每条路径建立证据表，避免仅凭 API 名称判断：
|
||||
|
||||
yaml
|
||||
```
|
||||
transformer_review:entrypoint:WorkflowArgumentBinder.Bindtrust_boundary:tenant-authenticated-usertype_source:workflow_xml.argument.typevalue_source:workflow_xml.argument.valueresolver:System.Type.GetTypeconstruction:TypeConverter.ConvertFromStringvalidation_before_resolution:noneload_context:web_processreachable_assemblies:inventory-requireddisposition:critical-review
|
||||
```
|
||||
|
||||
|
||||
这个表的价值在于把“可能危险”变成可验证的工程问题。只有 value 可控、类型固定时，优先处理该类型自己的解析缺陷；类型可控但对象未实例化时，要继续查解析器是否有副作用；二者都可控且无精确白名单时，才进入最高优先级。
|
||||
## 3、五类转换原语，要按数据流组合审计
|
||||
|
||||
课件归纳了五类常见原语：TypeConverter、反射调用静态 Parse/TryParse
|
||||
、字符串构造器、无参构造后访问属性，以及自定义转换逻辑。它们的危险性不由 API 单独决定，而由“类型是否外部可控”和“目标程序集里有什么可达行为”共同决定。
|
||||
### 3.1 TypeConverter
|
||||
|
||||
典型实现先解析 Type
|
||||
，再查询该类型声明的转换器：
|
||||
|
||||
csharp
|
||||
```
|
||||
Type target = ResolveType(request.TypeName); // source TypeConverter c = TypeDescriptor.GetConverter(target); object result = c.ConvertFromString( context: null, culture: CultureInfo.InvariantCulture, text: request.Value); // sink
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
图 6：TypeConverter 本身是扩展机制；当目标类型由请求决定时，扩展点便跨越了信任边界
|
||||
|
||||
转换器不一定只解析数字或颜色。它可以执行目标类型作者设计的任意转换代码，包括解释路径或 URI、访问资源、加载其他格式。安全审计不能以方法名里有 Converter
|
||||
就推断其无副作用。
|
||||
### 3.2 反射 Parse/TryParse
|
||||
|
||||
另一种通用框架会约定“目标类型只要有静态 Parse 就可绑定”：
|
||||
|
||||
csharp
|
||||
```
|
||||
MethodInfo? parse = target.GetMethod( "Parse", BindingFlags.Public | BindingFlags.Static, binder: null, types: new[] { typeof(string) }, modifiers: null); object? result = parse?.Invoke(null, newobject[] { request.Value });
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
图 7：Parse 通常被当成纯函数约定，但反射选择目标类型后，调用的是目标程序集提供的代码
|
||||
|
||||
审计规则若只匹配字面量 SomeType.Parse
|
||||
，会漏掉 GetMethod("Parse")
|
||||
、接口封装、缓存的 MethodInfo 和委托调用。应从类型解析点跟踪到 Invoke
|
||||
，同时检查方法名和签名约束。
|
||||
### 3.3 new T(string) 与 Activator
|
||||
|
||||
插件框架和配置系统常用“单字符串构造器”作为统一协议：
|
||||
|
||||
csharp
|
||||
```
|
||||
ConstructorInfo? ctor = target.GetConstructor(new[] { typeof(string) }); object? instance = ctor?.Invoke(newobject[] { request.Value }); // 等价的高风险形态object? instance2 = Activator.CreateInstance(target, request.Value);
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
图 8：构造器并不承诺只保存字符串；文件、网络、反射等行为都可能发生在对象初始化期间
|
||||
### 3.4 无参构造器加访问器
|
||||
|
||||
有的 Binder 先创建对象，再根据外部字段名反射设置属性。此时危险逻辑可能藏在 setter，也可能在后续 getter、验证器或生命周期回调中：
|
||||
|
||||
csharp
|
||||
```
|
||||
object instance = Activator.CreateInstance(target)!; foreach (PropertyInput input in request.Properties) { PropertyInfo p = target.GetProperty(input.Name)!; p.SetValue(instance, ConvertScalar(p.PropertyType, input.Value)); }
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
图 9：只审计构造函数会漏掉 setter、getter 和对象完成绑定后的隐式调用
|
||||
### 3.5 自定义转换器
|
||||
|
||||
最后一类没有稳定 API 名称，可能叫 BindValue
|
||||
、Materialize
|
||||
、BuildParameter
|
||||
或 ObjectFromString
|
||||
。识别它依靠数据流而非关键字：输入中存在类型标识和字符串值；代码解析类型；随后执行反射、组件模型或注册表中的工厂委托。
|
||||
|
||||
这也是为什么单纯扩大危险 API 黑名单收益有限。更稳妥的审计模型是“source—type resolution—construction sink—side effect”，并把四个节点保存在结果中供人工复核。
|
||||
## 4、Gadget 是否可用，取决于进程真正能加载什么
|
||||
|
||||
发现动态转换器不等于已经证明可利用。要判断影响，需要回答目标进程能解析、加载和实例化哪些类型。
|
||||
|
||||
.NET Framework 时代的 Global Assembly Cache（GAC）向进程提供大量机器级程序集，通用转换器面对的类型库存很大。现代 .NET 取消了同样形态的 GAC，依赖通常由应用发布内容、shared framework 和 .deps.json
|
||||
决定；攻击面往往更窄，但绝不是零。若服务引用 Microsoft.WindowsDesktop.App
|
||||
或打包了高权限组件，可达类型仍可能包含带网络、文件、标记语言或反射副作用的实现。
|
||||
|
||||
|
||||
|
||||
图 10：.NET Framework 侧重机器级 GAC，现代 .NET 侧重 shared framework 和应用依赖；二者都要按实际进程建清单
|
||||
|
||||
|
||||
|
||||
图 11：同一转换器在不同部署中可能有完全不同的可利用性，类型库存是进程属性，不只是源码属性
|
||||
|
||||
工程上可以从构建产物生成“可加载程序集—公开类型—转换入口”清单，而不是拿开发机环境代替生产环境：
|
||||
|
||||
bash
|
||||
```
|
||||
# 在隔离的构建/分析环境运行；输入应是待发布目录，不是生产服务器。 dotnet list ./src/WebApp/WebApp.csproj package --include-transitive jq -r '.targets[][] | keys[]?' ./publish/WebApp.deps.json | sort -u find ./publish -maxdepth 1 -type f -name '*.dll' -print | sort
|
||||
```
|
||||
|
||||
|
||||
随后用受控分析器枚举下列特征：
|
||||
- 类型或基类是否注册 TypeConverterAttribute
|
||||
；
|
||||
|
||||
- 是否存在公开 Parse(string)
|
||||
、TryParse
|
||||
或 ctor(string)
|
||||
；
|
||||
|
||||
- setter/getter 是否触达文件、网络、程序集加载、反射或二级解析；
|
||||
|
||||
- 转换器是否接受路径、URI、标记语言或资源引用；
|
||||
|
||||
- 目标类型是否在 Web 进程、定时任务或高权限服务的实际 Load Context 中可达。
|
||||
|
||||
不要把“未找到公开 gadget”当成修复。类型库存会随 NuGet 更新、插件安装和 Windows 组件变化而漂移。只修剪依赖而不切断可控类型，最多降低当前可利用性，无法消除漏洞类别。
|
||||
## 5、SharePoint 案例说明：正确修复是解析前精确白名单
|
||||
|
||||
白皮书复盘的第一条链是 CVE-2020-1460。工作流转换逻辑从 XML/参数中获得类型和值，随后获取目标类型的 TypeConverter 并进行字符串转换。课件将其归纳为：低权限用户可触达、默认配置可形成 RCE，问题不依赖传统 Deserialize()
|
||||
。
|
||||
|
||||
|
||||
|
||||
图 12：类型和值从工作流数据进入通用转换器，缺失的是类型解析之前的允许集合
|
||||
|
||||
这次修复值得保留：在转换前检查目标类型，只允许业务确实需要的少量标量与 SharePoint 字段类型。关键不是“拦住已知危险类”，而是默认拒绝未知类。
|
||||
|
||||
csharp
|
||||
```
|
||||
privatestaticreadonly IReadOnlyDictionary<string, Func<string, object>> Parsers = new Dictionary<string, Func<string, object>>(StringComparer.Ordinal) { ["System.String"] = static s => s, ["System.Boolean"] = static s => bool.Parse(s), ["System.Int32"] = static s => int.Parse(s, CultureInfo.InvariantCulture), ["System.Double"] = static s => double.Parse(s, CultureInfo.InvariantCulture), ["System.DateTime"] = static s => DateTime.Parse( s, CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind) }; publicstaticobjectConvertApproved(string externalType, stringvalue) { if (!Parsers.TryGetValue(externalType, out Func<string, object>? parser)) thrownew SecurityException("Unsupported conversion type"); return parser(value); }
|
||||
```
|
||||
|
||||
|
||||
这个实现有意不调用 Type.GetType()
|
||||
：如果业务只需要五种标量，最小设计就是五个显式解析器。不要先解析任意类型，再拿 FullName
|
||||
对白名单；某些解析与装载路径本身就可能触发程序集解析事件或自定义加载逻辑。
|
||||
|
||||
课件还讨论了 2026 年出现的 CVE-2026-26106、CVE-2026-40357、CVE-2026-47294 和 CVE-2026-48560，并对其中一条 ASPX 属性转换路径展开分析。公开材料指出，相关代码会先尝试 TypeConverter，再回退到反射 Parse；外围命名空间限制又可能被复杂类型表达绕开。本文不展开注册指令、泛型嵌套与 XAML 的具体组合，以免把防守文章变成可执行利用说明。
|
||||
|
||||
|
||||
|
||||
图 13：研究材料把四个 2026 年 SharePoint CVE 归入同一转换层问题族，说明局部补丁没有替代系统性盘点
|
||||
|
||||
|
||||
|
||||
图 14：同一转换函数先走 TypeConverter、再尝试静态 Parse；两条分支都必须共享同一类型策略
|
||||
|
||||
微软安全响应中心为上述 CVE 提供独立安全更新条目。由于公告主要描述产品影响、严重性和补丁信息，具体内部调用链应以研究课件与白皮书为依据，而不能反推成微软公告的原文结论。生产处置上也应以 MSRC 对对应 SharePoint 版本列出的安全更新为准。
|
||||
|
||||
这组案例的教训不是“SharePoint 又有一个特例”，而是同一产品内可能存在多个独立转换入口：工作流、页面标记解析、配置绑定和内部工具类各有一套类型策略。修复一个调用点后，如果没有搜索全仓库的类型解析颈部，漏洞会在另一个入口再次出现。
|
||||
## 6、代码审计先找类型解析颈部，再追五类汇点
|
||||
|
||||
最高收益的起点不是搜索所有 Parse
|
||||
，而是建立类型解析清单：Type.GetType
|
||||
、Assembly.GetType
|
||||
、ITypeResolutionService.GetType
|
||||
、BuildManager.GetType
|
||||
、Activator.CreateInstance(string, string)
|
||||
，以及项目自定义的 ResolveType/LoadType/CreateByName
|
||||
包装器。
|
||||
|
||||
下面的 Semgrep 规则适合做第一轮筛查。它故意只报“外部字符串解析类型后进入 TypeConverter”的紧邻形态，避免宣称覆盖全部数据流：
|
||||
|
||||
yaml
|
||||
```
|
||||
rules:-id:dotnet-dynamic-typeconverterlanguages: [csharp] severity:WARNINGmessage:动态解析的类型进入TypeConverter；确认类型名是否越过信任边界patterns:-pattern-inside:| $T = System.Type.GetType($NAME, ...); ... -pattern-either:-pattern:System.ComponentModel.TypeDescriptor.GetConverter($T)-pattern:System.ComponentModel.TypeDescriptor.GetConverter((System.Type)$T)metadata:category:securityconfidence:MEDIUMcwe:"custom-review-required"
|
||||
```
|
||||
|
||||
|
||||
第二条规则寻找动态类型进入 Activator 的形态：
|
||||
|
||||
yaml
|
||||
```
|
||||
rules:-id:dotnet-external-type-to-activatorlanguages: [csharp] severity:ERRORmessage:检查外部可控类型是否在实例化前经过精确允许列表mode:taintpattern-sources:-pattern-either:-pattern:$REQ.Query[$K]-pattern:$REQ.Form[$K]-pattern:$REQ.Headers[$K]pattern-propagators:-pattern:$T=System.Type.GetType($IN,...)from:$INto:$Tpattern-sinks:-pattern-either:-pattern:System.Activator.CreateInstance($T,...)-pattern:$CTOR.Invoke(...)
|
||||
```
|
||||
|
||||
|
||||
实际仓库还要补充项目自己的请求对象、消息消费者、XML 读取器与配置抽象。对每个结果至少回溯以下证据：
|
||||
1. 类型名的最初来源和可控权限；
|
||||
|
||||
1. 是否在 Type.GetType
|
||||
之前执行精确匹配；
|
||||
|
||||
1. 比较是否使用 Ordinal
|
||||
，是否允许前后缀、命名空间、程序集名或泛型表达；
|
||||
|
||||
1. 转换分支是否共用同一策略，还是 TypeConverter 被拦住后又回退到 Parse；
|
||||
|
||||
1. 生产发布目录中有哪些实际可达类型；
|
||||
|
||||
1. 转换结果之后是否触发 getter、验证、渲染或任务执行。
|
||||
|
||||
|
||||
|
||||
图 15：源码狩猎可分为类型解析颈部、转换汇点和可达 gadget 行为三条线，最终按数据流汇合
|
||||
|
||||
对大型 .NET 仓库，建议再用 CodeQL/Roslyn 做跨方法数据流。查询模型不必从“命中即漏洞”开始，而应输出路径：外部输入 → 类型解析 → 验证器 → 构造汇点。人工复核验证器的位置和语义后，再定严重性。
|
||||
## 7、黑盒测试应证明类型可控，不要直接投递危险 Gadget
|
||||
|
||||
没有源码时，公开材料建议关注几个输入形态：本应是标量的位置出现完整类型名、程序集限定名、复杂泛型语法、标记语言片段、UNC 路径或 URL。它们是定位动态转换器的线索，不是看到一次就能确认 RCE。
|
||||
|
||||
|
||||
|
||||
图 16：黑盒阶段先识别类型元数据和异常值形态，再通过无害探针确认服务端是否进行了动态解析
|
||||
|
||||
授权测试应使用无副作用的自定义 Canary 类型，放在隔离测试版本中：
|
||||
|
||||
csharp
|
||||
```
|
||||
[TypeConverter(typeof(AuditCanaryConverter))] publicsealedrecordAuditCanary(string Value); publicsealedclassAuditCanaryConverter : TypeConverter { publicoverrideboolCanConvertFrom(ITypeDescriptorContext? c, Type sourceType) => sourceType == typeof(string); publicoverrideobjectConvertFrom( ITypeDescriptorContext? c, CultureInfo? culture, objectvalue) { SecurityAudit.Emit("dynamic_type_conversion_reached", new { Canary = nameof(AuditCanary), ValueLength = ((string)value).Length }); returnnew AuditCanary((string)value); } }
|
||||
```
|
||||
|
||||
|
||||
测试请求只使用测试程序集里的 AuditCanary
|
||||
，断言审计事件是否出现；不要用系统自带的文件、网络、XAML 或进程相关类型“证明影响”。Canary 既能验证类型是否受控，也不会把测试变成远程代码执行。
|
||||
|
||||
黑盒结果可以按证据分级：
|
||||
|
||||
json
|
||||
```
|
||||
{"finding":"dynamic-string-transformer","evidence":{"type_name_accepted":true,"value_accepted":true,"canary_converter_reached":true,"allowlist_observed":false,"production_gadget_tested":false},"confidence":"high","impact":"requires-production-reachability-analysis","safe_test":true}
|
||||
```
|
||||
|
||||
|
||||
如果无法部署 Canary，则用错误差异、日志和调用链遥测判断：未知类型、存在但不允许的类型、允许类型的非法值，应产生不同且可审计的内部分类，但外部统一返回 400，避免通过详细异常帮助枚举服务器程序集。
|
||||
## 8、SOC 检测要把异常类型和值与服务器副作用关联
|
||||
|
||||
运行时检测不能只写一条“请求里出现 System.
|
||||
”的 WAF 正则。合法 .NET API、诊断页面和开发工具可能频繁携带类型名。更可信的告警需要把入口异常与后续副作用关联：
|
||||
- 请求参数、工作流 XML 或页面属性中出现程序集限定类型名；
|
||||
|
||||
- 标量字段出现泛型符号、标记语言、URI、UNC 或本地绝对路径；
|
||||
|
||||
- 应用随后产生异常 DNS/HTTP/SMB 出站；
|
||||
|
||||
- Web 工作进程打开配置外文件或加载非常用程序集；
|
||||
|
||||
- 日志出现 TypeLoadException
|
||||
、TypeConverter
|
||||
、TargetInvocationException
|
||||
、Parse
|
||||
反射失败；
|
||||
|
||||
- 同一来源短时间轮询多个命名空间、程序集版本或类型名。
|
||||
|
||||
下面是一条偏运营化的 Sigma 关联前置规则，用于识别 Web 进程异常加载程序集；字段名需按实际 EDR 映射：
|
||||
|
||||
yaml
|
||||
```
|
||||
title:Web进程加载非基线.NET程序集status:experimentallogsource:category:image_loadproduct:windowsdetection:web_process:Image|endswith:-'\\w3wp.exe'-'\\dotnet.exe'managed_image:ImageLoaded|endswith:'.dll'filter_approved:ImageLoaded|startswith:-'C:\\Windows\\Microsoft.NET\\'-'C:\\Program Files\\ApprovedApp\\'condition:web_processandmanaged_imageandnotfilter_approvedfalsepositives:-已批准部署、插件更新或补丁安装level:medium
|
||||
```
|
||||
|
||||
|
||||
单条程序集加载事件不足以定案。SIEM 应在 5—15 分钟内关联反向代理请求、ASP.NET 诊断、DNS、网络连接、文件事件和子进程：
|
||||
|
||||
yaml
|
||||
```
|
||||
correlation:insecure_string_transformer_suspectedwindow:10mgroup_by: [host, process_guid] require:-any:-request_contains_type_metadata-dotnet_dynamic_type_error-any:-nonbaseline_assembly_load-web_process_outbound_network-web_process_unexpected_file_access-web_process_child_processseverity:child_process:criticaloutbound_or_file:highmetadata_only:lowresponse:-preserve_request_and_trace_id-capture_process_tree_and_loaded_modules-isolate_only_after_business_impact_check
|
||||
```
|
||||
|
||||
|
||||
注意保护日志中的请求正文。工作流和页面参数可能包含凭据、个人数据或业务文档，检测平台应做字段级脱敏、访问控制和短期留存。
|
||||
## 9、修复顺序：取消类型选择优先于维护 Gadget 黑名单
|
||||
|
||||
课件给出的最佳修复很直接：让外部输入失去选择类型的能力。接口若处理日期，就调用固定的日期解析器；若支持有限的业务字段，就把外部枚举映射到内部工厂委托。只有插件平台确实需要动态类型时，才维护精确允许集合，并在任何类型解析之前检查稳定的业务标识。
|
||||
|
||||
|
||||
|
||||
图 17：一旦目标类型由程序固定，攻击链中最关键的自由度就被删除
|
||||
|
||||
|
||||
|
||||
图 18：白名单要在类型解析前生效，且描述业务能力，而不是列举当前已知危险类型
|
||||
|
||||
推荐把协议从 CLR 类型名改成版本化的业务枚举：
|
||||
|
||||
csharp
|
||||
```
|
||||
publicenum FieldKind { Text, Boolean, Integer, Timestamp } publicstaticboolTryConvert(FieldKind kind, string raw, outobject? value) { value = null; switch (kind) { case FieldKind.Text: value = raw; return raw.Length <= 4096; case FieldKind.Boolean: if (!bool.TryParse(raw, outbool flag)) returnfalse; value = flag; returntrue; case FieldKind.Integer: if (int.TryParse(raw, NumberStyles.Integer, CultureInfo.InvariantCulture, outint number)) { value = number; returntrue; } returnfalse; case FieldKind.Timestamp: if (DateTimeOffset.TryParseExact(raw, "O", CultureInfo.InvariantCulture, DateTimeStyles.None, out DateTimeOffset timestamp)) { value = timestamp; returntrue; } returnfalse; default: returnfalse; } }
|
||||
```
|
||||
|
||||
|
||||
需要特别拒绝的“伪修复”包括：
|
||||
- 禁止若干已知 gadget 类型；依赖更新后会出现新类型；
|
||||
|
||||
- 只允许 System.*
|
||||
或厂商命名空间；命名空间不是安全能力边界；
|
||||
|
||||
- 使用 StartsWith
|
||||
、正则或去除特殊字符判断类型名；复杂类型表达和程序集解析容易制造旁路；
|
||||
|
||||
- 解析 Type
|
||||
后才检查；已经把不可信名称交给解析基础设施；
|
||||
|
||||
- 只保护 TypeConverter 分支，却保留 Parse、构造器或属性绑定回退；
|
||||
|
||||
- 通过删除当前 gadget 宣布漏洞已修；转换器仍会被将来依赖重新武器化。
|
||||
|
||||
## 10、上线前用负向测试证明“类型选择权已经消失”
|
||||
|
||||
修复验证不应只测合法输入仍能工作。要为每个转换入口建立负向矩阵，覆盖未知业务类型、CLR 全名、程序集限定名、泛型表达、超长字符串、路径/URI、大小写与 Unicode 混淆、旧版本协议和所有回退分支。
|
||||
|
||||
csharp
|
||||
```
|
||||
[Theory] [InlineData("System.String", "hello")] [InlineData("System.DateTime", "2026-08-10T00:00:00Z")] [InlineData("Vendor.Product.LegacyType, Vendor.Product", "x")] [InlineData("Unknown", "x")] publicvoidExternalClrTypeNamesAreNeverResolved(string typeToken, stringvalue) { var resolver = new RecordingTypeResolver(); var binder = new SafeFieldBinder(resolver); BindResult result = binder.Bind(typeToken, value); Assert.False(result.Success); Assert.Empty(resolver.RequestedTypeNames); }
|
||||
```
|
||||
|
||||
|
||||
再给允许的业务枚举做边界测试，确认不经过通用类型系统：
|
||||
|
||||
csharp
|
||||
```
|
||||
[Fact] publicvoidApprovedIntegerUsesPinnedParser() { var resolver = new RecordingTypeResolver(); var binder = new SafeFieldBinder(resolver); BindResult result = binder.Bind("integer", "42"); Assert.True(result.Success); Assert.Equal(42, result.Value); Assert.Empty(resolver.RequestedTypeNames); }
|
||||
```
|
||||
|
||||
|
||||
发布门禁还应比较依赖清单：如果 Web 进程新增带 TypeConverter、字符串构造器或敏感副作用的程序集，触发安全复核；这不是为了维护永久 gadget 黑名单，而是防止修复过渡期的风险被依赖漂移放大。
|
||||
|
||||
|
||||
|
||||
图 19：可控类型、可控值、验证位置、可加载程序集和可达行为共同决定优先级
|
||||
|
||||
最终验收标准可以压缩为四项：协议不再接受 CLR 类型名；所有入口使用同一业务类型注册表；任何未知类型都在解析前拒绝；生产遥测能够识别被拒绝的类型探测及其后续异常副作用。
|
||||
|
||||
|
||||
|
||||
图 20：转换层不是序列化器，却能形成等价的“选择类型并执行构造代码”能力
|
||||
|
||||
这场研究最有价值的地方，是把一个散落在框架工具函数中的问题还原成可操作的安全模型。安全团队不需要把每个 Parse()
|
||||
都升级为事故，也不应等到找到可执行 gadget 才承认边界存在。先证明攻击者能否选择类型，再确认对象如何被构造、进程能加载什么，最后把类型选择权从协议中移除。
|
||||
|
||||
只要外部输入仍能把任意 CLR 类型交给通用转换器，当前没有 gadget 只是部署快照，不是安全属性。真正稳定的修复，是让业务协议表达“整数、时间、文本”等有限能力，而不是暴露运行时类型系统。
|
||||
### 资料来源
|
||||
- Black Hat 官方 Session 页面
|
||||
|
||||
- Black Hat USA 2026 Session 页面
|
||||
|
||||
- Microsoft MSRC：CVE-2020-1460
|
||||
|
||||
- Microsoft MSRC：CVE-2026-26106
|
||||
|
||||
- Microsoft MSRC：CVE-2026-40357
|
||||
|
||||
- Microsoft MSRC：CVE-2026-47294
|
||||
|
||||
- Microsoft MSRC：CVE-2026-48560
|
||||
|
||||
**原始会议材料（仓库内）**
|
||||
- 演讲课件 PDF
|
||||
|
||||
- 配套白皮书 PDF
|
||||
|
||||
开源资料与原始议题 PDF
|
||||
|
||||
本文对应的 Markdown 原稿、Black Hat 原始议题 PDF 与配图已整理到 GitHub，可按文章编号查找和下载。
|
||||
|
||||
https://github.com/cybermaxluo/black-hat-usa-2026-talks
|
||||
|
||||
也可以点击文末“阅读原文”进入仓库。欢迎 Star、提交 Issue 或参与勘误。
|
||||
|
||||
@@ -0,0 +1,187 @@
|
||||
# CVE-2025-11395 Podman任意文件写入漏洞
|
||||
撅人 2026-09-16 16:00
|
||||
|
||||
|
||||
|
||||
Red Hat 安全团队于 2026 年 9 月 16 日更新了编号为 **CVE-2025-11395**
|
||||
的安全公告。该漏洞存在于容器引擎 Podman 中，攻击者可通过精心构造的 tar 归档文件，在执行 **podman load**
|
||||
命令时向宿主机写入任意文件。
|
||||
|
||||
CVSS 3.1 基础评分 **5.5 分**
|
||||
，严重等级评定为 **Medium**
|
||||
。目前暂无在野利用，修复版本尚未发布。
|
||||
|
||||
1
|
||||
|
||||
漏洞速览
|
||||
|
||||
**CVE 编号**
|
||||
CVE-2025-11395
|
||||
|
||||
**漏洞类型**
|
||||
任意文件写入（Arbitrary File Write）
|
||||
|
||||
**影响产品**
|
||||
Podman、Buildah、Skopeo（Red Hat Enterprise Linux 8/9/10）
|
||||
|
||||
**安全等级**
|
||||
Medium（CVSS 3.1 基础评分 5.5）
|
||||
|
||||
**披露时间**
|
||||
2026-09-16（Red Hat 安全公告更新日）
|
||||
|
||||
**补丁情况**
|
||||
暂无修复版本，Red Hat 表示当前无可用的缓解方案
|
||||
|
||||
**利用情况**
|
||||
暂无在野利用
|
||||
|
||||
**技术影响**
|
||||
读取应用数据；修改应用数据
|
||||
|
||||
2
|
||||
|
||||
漏洞概述
|
||||
|
||||
Podman 是 Red Hat 开发的开源容器引擎，提供 **podman load**
|
||||
命令用于从 OCI 归档文件导入容器镜像。该命令在处理 tar 归档时，未对归档内文件路径做充分校验，导致**路径遍历（Path Traversal）**
|
||||
成为可能。
|
||||
|
||||
攻击者构造一个恶意 tar 归档，其中包含指向宿主机文件系统的相对路径条目（如 **../../../etc/cron.d/malicious**
|
||||
）。当受害者执行 podman load 导入该归档时，Podman 会以当前用户权限在宿主机上创建或覆盖文件。
|
||||
|
||||
这意味着攻击者可以在**宿主机文件系统上写入任意文件**
|
||||
——具体能造成多大危害取决于写入路径和文件内容。如果写入 cron 定时任务目录、SSH 授权密钥目录等敏感位置，可进一步实现远程命令执行或持久化后门。
|
||||
|
||||
截至公告发布，该漏洞暂无在野利用记录，Red Hat 也表示当前没有满足其安全标准的缓解方案。
|
||||
|
||||
3
|
||||
|
||||
CVSS 评分详解
|
||||
|
||||
CVSS 3.1 向量字符串：**CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L**
|
||||
|
||||
**攻击向量（AV）**
|
||||
Adjacent Network — 攻击者需处于相邻网络（如同一局域网）
|
||||
|
||||
**攻击复杂度（AC）**
|
||||
Low — 无需特殊条件
|
||||
|
||||
**所需权限（PR）**
|
||||
Low — 攻击者需具备低权限（如可执行 podman 命令的用户）
|
||||
|
||||
**用户交互（UI）**
|
||||
None — 无需额外用户交互
|
||||
|
||||
**范围（S）**
|
||||
Unchanged — 影响范围限于同一安全权限
|
||||
|
||||
**机密性影响（C）**
|
||||
Low — 可读取部分应用数据
|
||||
|
||||
**完整性影响（I）**
|
||||
Low — 可修改部分应用数据
|
||||
|
||||
**可用性影响（A）**
|
||||
Low — 对可用性有有限影响
|
||||
|
||||
4
|
||||
|
||||
利用条件与攻击路径
|
||||
|
||||
该漏洞的利用需要满足两个前提条件：
|
||||
|
||||
第一，攻击者需要能够向目标系统的 **podman load**
|
||||
命令传入一个精心构造的 tar 归档文件。这可能通过供应链投毒——在容器镜像仓库中发布包含恶意 OCI 归档的镜像——或诱导用户从不受信任的来源导入镜像来实现。
|
||||
|
||||
第二，攻击者需要具备执行 podman 命令的低权限（PR:L）。CVSS 攻击向量为 Adjacent Network，意味着攻击者可能通过相邻网络发起攻击，但通常仍需某种形式的社会工程学或供应链投毒配合。
|
||||
|
||||
**攻击路径总结：**
|
||||
攻击者构造恶意 tar 归档（含路径遍历条目）→ 通过供应链投毒或诱导导入传入目标 → 受害者执行 podman load → Podman 解包时跟随路径写入宿主机文件 → 覆盖/创建敏感文件（cron、SSH 密钥等）→ 实现持久化或远程命令执行
|
||||
|
||||
5
|
||||
|
||||
修复建议
|
||||
|
||||
截至公告发布日，Red Hat 表示该漏洞**暂无官方修复版本**
|
||||
，且当前可用的缓解方案不满足 Red Hat 产品安全团队在易用性、适用性和稳定性方面的标准。
|
||||
|
||||
**当前建议**
|
||||
持续关注 Red Hat 安全公告，待修复版本发布后及时更新 podman、buildah、skopeo 至最新版本。Bugzilla 修复截止日期为 2025-11-07。
|
||||
|
||||
**临时缓解措施：**
|
||||
|
||||
· 仅从可信来源导入容器镜像，禁止 podman load 来路不明的 OCI 归档文件
|
||||
|
||||
· 对 tar 归档内容做预检查，扫描是否包含路径遍历条目（如 **../**
|
||||
序列）
|
||||
|
||||
· 限制 podman 命令的执行权限，仅授权给可信用户和 CI/CD 流水线
|
||||
|
||||
· 在容器运行环境中使用 SELinux 或 AppArmor 强制访问控制，限制文件写入范围
|
||||
|
||||
· 企业环境建议通过镜像签名验证机制，确保导入的 OCI 归档来自可信发布者
|
||||
|
||||
6
|
||||
|
||||
受影响产品清单
|
||||
|
||||
根据 Red Hat 安全公告，以下产品及版本受该漏洞影响：
|
||||
|
||||
**RHEL 10**
|
||||
podman / buildah / skopeo — 受影响
|
||||
|
||||
**RHEL 9**
|
||||
podman / buildah / skopeo — 受影响
|
||||
|
||||
**RHEL 8**
|
||||
podman (container-tools:rhel8) / buildah / skopeo — 受影响
|
||||
|
||||
**RHEL Hardened Images**
|
||||
podman — 受影响
|
||||
|
||||
注：除非明确声明不受影响，上述产品在任意小版本中的先前版本包均应视为受影响。
|
||||
|
||||
来源：Red Hat 安全公告 CVE-2025-11395 Affected Packages 列表
|
||||
|
||||
7
|
||||
|
||||
漏洞时间线
|
||||
|
||||
**2025-10-07**
|
||||
|
||||
安全研究员 XeR 向 Red Hat 报告该漏洞（Bugzilla 创建）
|
||||
|
||||
**2025-11-07**
|
||||
|
||||
Bugzilla 记录的修复截止日期
|
||||
|
||||
**2026-09-16**
|
||||
|
||||
Red Hat 安全公告更新，本文发布
|
||||
|
||||
8
|
||||
|
||||
致谢与参考
|
||||
|
||||
该漏洞由安全研究员 **XeR**
|
||||
报告。Red Hat 在公告中对其协调披露行为表示感谢。
|
||||
|
||||
**参考链接：**
|
||||
|
||||
· Red Hat 安全公告：
|
||||
https://access.redhat.com/security/cve/CVE-2025-11395
|
||||
|
||||
· Red Hat Bugzilla：
|
||||
https://bugzilla.redhat.com/show_bug.cgi?id=2402034
|
||||
|
||||
· CVE 记录：
|
||||
https://www.cve.org/CVERecord?id=CVE-2025-11395
|
||||
|
||||
· Podman 官方项目：
|
||||
https://github.com/containers/podman
|
||||
|
||||
本文信息来源为 Red Hat 安全公告（access.redhat.com）及 Bugzilla 缺陷追踪系统，仅供安全研究与防御参考。漏洞当前暂无官方修复版本，请以 Red Hat 后续公告为准，及时更新受影响组件。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,70 @@
|
||||
# CVE-2026-58704：零点击、近距离、间谍级攻击
|
||||
原创 Red Hunter
|
||||
Red Hunter 黑白之道 2026-09-17 00:35
|
||||
|
||||
|
||||
> **导语**
|
||||
：Google 周二推送 9 月 Pixel 安全补丁，修复一颗已被野外利用的高危蜂窝调制解调器漏洞 CVE-2026-58704，CVSS 8.0。零点击、无需用户交互、邻近攻击——这套组合拳是商业间谍软件或国家级 APT 的教科书级打法。Google 没披露漏洞发现者、攻击开始时间、受害目标，但攻击特征已经把答案写在脸上。
|
||||
|
||||
## 一、事件概述：周二补丁里藏着 0day
|
||||
|
||||
9 月 15 日，Google 发布 Pixel 9 月安全公告，补丁级别 2026-09-05。公告里 CVE-2026-58704 被单独点名——"存在有限的、有针对性的利用迹象"，这是公告里最高一档的措辞。
|
||||
|
||||
|
||||
|
||||
漏洞出在 Pixel 的蜂窝调制解调器组件——手机里负责和基站对话、收发短信、解 SIM 卡的那块芯片固件。Google 没披露漏洞发现者，Android bug 跟踪编号 A-484011314 仍处于隐私状态。业内推测要么是 Google 内部红队捕获，要么是商业间谍软件厂商主动提交。
|
||||
|
||||
公告同一天，SecurityWeek 直接点出："modem 级别、零点击的特征，加上 Google'有限、有针对性'的措辞，是过去商业间谍软件厂商或国家级攻击者相关攻击的典型特征。"
|
||||
## 二、技术剖析：逻辑错误与零点击组合
|
||||
|
||||
CVE-2026-58704 在 NVD（美国国家漏洞数据库）的官方描述写得很简洁："在蜂窝调制解调器中，存在一个由于代码逻辑错误导致的可能权限绕过。这可能导致远程（邻近/相邻）的权限提升，无需额外的执行权限。"
|
||||
|
||||
把这段拆开看，每一个定语都是刺眼的关键词：**逻辑错误**
|
||||
——不是缓冲区溢出、不是 UAF（释放后使用）那种内存破坏，而是写错了条件判断；**权限绕过**
|
||||
——拿到更高权限；**邻近/相邻**
|
||||
——必须在物理上接近目标手机，典型手段是伪基站；**无需额外执行权限**
|
||||
——不需要先装个恶意 App，意味着攻击入口在基带处理器（独立于 Android 系统的通信芯片）层面，跟系统层完全隔离。
|
||||
|
||||
|
||||
|
||||
逻辑错误类漏洞最阴险的地方在于：它不像内存破坏那样依赖复杂的 ROP（返回导向编程）链和内存布局，一段错误的 if (privilege_check(user)) { ... }
|
||||
改成 if (1) { ... }
|
||||
就够了。攻击者只需构造一段特定的无线信号（伪装成基站的 4G/5G 下行消息），让目标手机的 modem 在解析时踩中错误的条件分支，权限就拿到手。
|
||||
|
||||
至于拿到什么权限、能做什么后续动作——Google 没披露，也没有公开 PoC。但参考以往 modem 0day：拿到权限后可监听通话、读取短信、追踪位置、获取 IMSI（手机"身份证号"），部分历史漏洞甚至能穿透到 Android 系统层。
|
||||
## 三、零点击 + 邻近攻击：典型间谍软件打法
|
||||
|
||||
把"零点击"和"邻近攻击"组合到一起，红队脑子里立刻浮现三样东西：IMSI 抓取器（俗称"黄貂鱼"，伪装成合法基站的无线电设备）、商业间谍软件如 NSO 集团（以色列）的 Pegasus、Intellexa（希腊/爱尔兰）的 Predator，以及背后那些不愿具名的国家级买家。
|
||||
|
||||
攻击流程常是这样：情报机构部署一辆载有伪基站的小车，停在你常去的咖啡馆楼下；你的 Pixel 手机自动连上这辆车的伪基站；伪基站下发精心构造的无线消息，触发 CVE-2026-58704 的逻辑错误；modem 以高权限执行恶意操作；你连屏幕都没碰，手机已经"通了"。
|
||||
|
||||
这种攻击成本极高——伪基站车几百万美元、漏洞在黑市上几百万到几千万美元、还需具备无线电协议和基带固件逆向能力的工程师团队。普通黑客玩不起。能这么打的，要么是商业间谍软件公司，要么是国家行为者。
|
||||
|
||||
SecurityWeek 提到，这种 modem 级别的零点击漏洞"已多次被 Google 关联到间谍软件厂商"。Pixel 用户如果身处敏感行业（政府、记者、维权人士、企业高管），九月补丁不只是"建议安装"，而是"不装等于裸奔"。
|
||||
## 四、九月补丁"打包"：还有 100+ 颗雷
|
||||
|
||||
别以为 CVE-2026-58704 是 9 月补丁的唯一看点。同期还有至少六颗 critical（严重）漏洞：CVE-2026-55318 和 CVE-2026-55343（IP 多媒体子系统和 libpixelimsmedia 的 RCE）、CVE-2026-56920（VPU RCE）、CVE-2026-56967（modem 里另一颗 RCE）、CVE-2026-58683 和 CVE-2026-58710（电话组件和 BigOcean 的 RCE）。再加上 bootloader（引导加载器）、TEE（可信执行环境）、电话组件等大量 critical 级权限提升——9 月公告一共修了一百多个 Pixel 专属漏洞，差不多 50 个标 critical。
|
||||
|
||||
特别注意 CVE-2026-56967 也是 modem 里的 RCE——一个月里 Pixel modem 被连捅两刀，一刀是已被利用的 CVE-2026-58704，一刀是潜在可远程代码执行的 RCE。两颗串起来用，效果比单独一颗狠得多。
|
||||
## 五、给 Pixel 用户的紧急建议
|
||||
|
||||
按优先级三件事。第一，立刻装 9 月补丁：打开"设置 → 安全 → 安全更新"，确认补丁级别是 2026-09-05 或更新；没收到推送就等几天或去 Google 工厂镜像刷最新 OTA（空中下载更新）。
|
||||
|
||||
第二，自查暴露面。记者、社运人士、企业高管、政府工作人员、敏感行业从业者——回想过去几个月有没有在陌生场所停留过、信号突然变差过、电池异常发热过。Modem 0day 利用时通常让基带处理器持续高负载，表现为发热、续航缩短，但症状不一定出现，出现也不一定就是被打了——只能算辅助判断。
|
||||
|
||||
第三，长期防御策略。Pixel 已是 Android 阵营里更新最快的设备，但 modem 漏洞修复节奏仍落后系统层。建议把 Pixel 当作"基础安全设备"，日常敏感操作尽量切换到硬隔离环境；同时关注 Google Project Zero 的 modem 漏洞披露。
|
||||
|
||||
**版权声明**
|
||||
：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621549&idx=1&sn=21c4b072726d2387d562109ada6b9bbb&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621944&idx=1&sn=3cc6dc9876a20466d4ec3634deb80220&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650622065&idx=1&sn=09f8ae84c06d4331e71c277b177ae701&scene=21#wechat_redirect)
|
||||
> 👇 点击**阅读原文**
|
||||
，访问我的网站
|
||||
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
# Check Point 严重登录漏洞可导致远程接管
|
||||
sec随谈
|
||||
sec随谈 sec随谈 2026-09-17 01:08
|
||||
|
||||
Check Point 发布紧急安全更新，修复了一个严重的登录漏洞。该漏洞允许未经身份验证的远程攻击者以 root 权限执行任意代码。管理员必须立即安装已发布的 LivePatch 热修复补丁，以保护企业网络安全。
|
||||
|
||||
**为何此威胁至关重要**
|
||||
|
||||
全球数以千计的组织使用 Check Point 管理服务器控制企业防火墙。因此，这些核心平台中存在的漏洞使整个网络边界面临被恶意接管的风险。一旦攻击者入侵管理服务器，便可篡改安全策略，在内部网络中横向移动并禁用现有防御措施。
|
||||
|
||||
**攻击方式**
|
||||
|
||||
该漏洞的 CVSS 基础评分高达 9.8。安全公告警告称："未经身份验证的登录过程中出现的栈溢出，可能允许攻击者以 root 权限远程执行任意代码。"攻击者在初始身份验证序列中发送超长输入即可触发该漏洞，导致登录服务发生栈缓冲区溢出。
|
||||
|
||||
此外，管理员可在 SmartConsole 日志中识别潜在的攻击尝试，具体方法是搜索内容为"Administrator failed to log in: Username too long"（管理员登录失败：用户名过长）的审计消息。Check Point 确认目前不存在公开的漏洞利用代码或在野攻击案例。
|
||||
|
||||
**受影响版本**
|
||||
|
||||
此 Check Point 登录漏洞影响多个软件版本，包括安全管理服务器（Security Management Server）和多域安全管理服务器（Multi-Domain Security Management Server）部署，以及日志服务器（Log Server）和多域日志服务器（Multi-Domain Log Server）系统。受影响版本包括 R82.20、R82.10、R82、R81.20 及更早的不受支持版本。厂商确认 Smart-1 Cloud 实例不受影响。
|
||||
|
||||
**补丁与缓解措施**
|
||||
|
||||
管理员应立即部署最新的 Check Point LivePatch 软件包。已启用自动更新的系统将自动接收修复补丁。详细升级说明可在 Check Point 官方安全公告中获取。若无法立即打补丁，管理员应将受信任的 GUI 客户端限制在专用内部 IP 子网范围内，并切勿将受信任客户端类型设置为接受任意远程地址。
|
||||
|
||||
参考链接：
|
||||
|
||||
https://support.checkpoint.com/results/sk/sk1000155
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# DeepSeek Al：POC EXP_工具化与漏洞验证实战与代码审计与央企安全日志分析
|
||||
原创 鼹鼠
|
||||
鼹鼠 知树安全团队 2026-09-16 16:00
|
||||
|
||||
迅雷链接：
|
||||
|
||||
https://pan.xunlei.com/s/VP1ZpXwR9CgUQrvIw4N-inPcA1?pwd=cs7i#
|
||||
|
||||
夸克链接：
|
||||
|
||||
https://pan.quark.cn/s/6f63946fe082
|
||||
|
||||
|
||||
👆点击上方公众号👆
|
||||
|
||||
回复下边四位数字获取免费资料！
|
||||
|
||||
1120
|
||||
：全套免杀课程
|
||||
|
||||
1121
|
||||
：安全杂志电子版
|
||||
|
||||
1122
|
||||
：常用高效爆破字典
|
||||
|
||||
1123
|
||||
：全套逆向课程
|
||||
|
||||
1124
|
||||
：国家信息水平测试全套课程
|
||||
|
||||
1125
|
||||
：CNVD证书挖掘技巧合集
|
||||
|
||||
1126
|
||||
：上心挖洞培训课程
|
||||
|
||||
1127
|
||||
：外网CVE漏洞POC
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,144 @@
|
||||
# Langflow爆出代码执行漏洞CVE-2026-17633 (POC已公开)
|
||||
YGnight
|
||||
YGnight night安全 2026-09-17 00:00
|
||||
|
||||
|
||||
|
||||
## 01漏洞描述
|
||||
|
||||
收到langflow存在一个代码注入从而导致命令执行的漏洞，Langflow简单来说就是一款面向开发者的开源低代码工具，是基于Python开发的，漏洞的产生是Langflow 留了一个自定义组件的入口，本来是用来让用户把自己写的模块传上去，页面就能多出一个功能块。
|
||||
|
||||
1.10.3 和更早的版本收到这份代码是不看内容的，会直接执行。只要有一个登录的账号就能提交，命令在服务端就会跑起来。
|
||||
<table><tbody><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">CVE 编号</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">CVE-2026-17633</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">漏洞类型</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">代码注入 CWE-94 / 认证后远程代码执行</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">受影响版本</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#dc2626;font-weight:bold;"><section><span leaf="">Langflow OSS 1.0.0 至 1.10.3</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">修复版本</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#166534;font-weight:bold;"><section><span leaf="">Langflow OSS 1.11.0 及以上</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">危害评级</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">CVSS 8.5 / 8.8</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">攻击入口</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">POST /api/v1/custom_component</span></section></td></tr><tr><th style="padding:10px 12px;border:1px solid #d1d5db;text-align:left;font-weight:bold;color:#1a1a1a;background-color:#f3f4f6;white-space:nowrap;"><section><span leaf="">利用前提</span></section></th><td style="padding:10px 12px;border:1px solid #d1d5db;color:#333;"><section><span leaf="">一个已登录的账号，实例开启 LANGFLOW_ALLOW_CUSTOM_COMPONENTS</span></section></td></tr></tbody></table>## 02漏洞原理
|
||||
|
||||
这个漏洞接口实现放在 langflow/api/v1/endpoints.py 里的。请求进来后会先取配置，判断 allow_custom_components 等自定义组件的开关状态。
|
||||
|
||||
提交的代码是原样往下传的，整段函数里看不到任何内容检查的步骤。
|
||||
|
||||
# langflow/api/v1/endpoints.py，v1.10.3
|
||||
if not settings.allow_custom_components and not code_hash_matches_any_template( raw_code.code, all_known):
|
||||
raise HTTPException(status_code=403, detail="Custom component creation is disabled")
|
||||
component = Component(_code=effective_code)
|
||||
built_frontend_node, component_instance = build_custom_component_template( component, user_id=user.id)
|
||||
|
||||
代码往下走进 lfx/custom/validate.py 的 create_class。它先把提交的内容解析成语法树，调 prepare_global_scope 准备执行环境，再抽出目标类单独编译。
|
||||
|
||||
prepare_global_scope 扫顶层节点时只收三类内容，import、类与函数定义、赋值语句。
|
||||
|
||||
for node in module.body:
|
||||
if isinstance(node, ast.Import):
|
||||
imports.append(node)
|
||||
elif isinstance(node, ast.ImportFrom) and node.module is not None:
|
||||
import_froms.append(node)
|
||||
elif isinstance(node, ast.ClassDef | ast.FunctionDef | ast.Assign | ast.AnnAssign):
|
||||
definitions.append(node)
|
||||
# 写在最外层的 os.system(...) 是 ast.Expr，三种都不匹配，会被跳过
|
||||
|
||||
这个筛选带来一个差别。命令写在模块最外层，类型是表达式语句，落不进上面任何一类，走完就被丢掉。写在类体里的语句跟着类一起被抽出编译，类定义完成的那一刻跑完。
|
||||
|
||||
公开 PoC 的构造思路就是把命令放到类的第一行，其余字段都照抄正常组件的写法，服务端收到代码后看起来就会像在处理一个普通组件。
|
||||
|
||||
from lfx.custom import Component
|
||||
import os
|
||||
class PocComponent(Component):
|
||||
os.system("id > /tmp/pwned.txt") # 类定义时就执行
|
||||
display_name = "Utility"
|
||||
description = "Utility component."
|
||||
outputs = [Output(name="result", display_name="Result", method="get_result")]
|
||||
|
||||
请求原本是带 Bearer 令牌的，数据包的Body 里只有 code 字段。服务端返回 200，命令已经在服务进程里跑完，回显数据包里看不出任何异常的。
|
||||
|
||||
同一个仓库还带了 CVE-2026-17632 的分析。另一条链路上装了基于语法树的扫描，禁用名单列了 exec、eval、compile、__import__、open，里面没有 vars。
|
||||
|
||||
写成 vars()["__builtins__"] 这种下标取法，绕开了对属性名的检查，扫描结果 is_safe 为 True。这条路要靠模型原样吐出载荷，云端模型多数会拒。
|
||||
## 03修复建议
|
||||
|
||||
升级到Langflow OSS 1.11.0就行
|
||||
## 近期值得重点关注的漏洞预警
|
||||
|
||||
[【紧急漏洞预警】nacos爆出权限绕过漏洞，可以创建管理员账户，经过分析有点出处（已复现，exp脚本已编写）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486343&idx=1&sn=b67c4eb02c03af9c3b206b1241ff7e9c&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Apache CVE-2026-42536，补它只用一行，洞龄十四年](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486419&idx=1&sn=393b6baeea4f624ffa8440058c0d324e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【紧急】搜狗输入法爆出远程代码执行漏洞CVE-2026-51990 ，已被在野利用](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486413&idx=1&sn=0b2c6a470a165f288873fa6bace1d77b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【紧急】无需登录就能获取 GitLab 的任意文件数据(附POC)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486408&idx=1&sn=06f47231a649e03866f9e9524b5469a4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【紧急】JumpServer堡垒机被公布Access Key泄露漏洞，可以实现提权](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486403&idx=1&sn=8e4dc6a684e95b9dc5871b1aca487a57&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Spring Cloud Azure公布严重漏洞 无需任何权限即可取得登录会话](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486398&idx=1&sn=c64f6f82f75da584d032b99509ffc726&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞POC已公开】Linux RDS 爆出提权漏洞 一块内存放两次，root就到手了](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486393&idx=1&sn=629bab1cc81fbee25e8e6dd558ee155b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Tenda光猫爆出严重漏洞，目前无补丁(POC已公布](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486388&idx=1&sn=eb210feb27b85439b53b10e595f7667e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[13 行补丁，堵住Linux能拿 root 的内核洞(EXP已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486383&idx=1&sn=a87059fbbca283a7bd64ad78280ed00a&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[48 字节，换走一台 Windows 的 SYSTEM(CVE-2026-62735漏洞POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486378&idx=1&sn=f9e17fe32b6a3c67249fb4f037a3f1c6&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】linux删个网桥就能提权root？目前没有补丁(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486373&idx=1&sn=5f8bb9b0ff7c9fad75a8071c026b9f93&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】Linux三年前补上的洞，又一次被挖开了](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486368&idx=1&sn=337dc5fa148d0b24e7dbd352a71e184f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【情报】支付宝8.2亿数据泄露？给同事说一声，别自己吓自己](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486362&idx=1&sn=927fdf3d81c79a2ff8871086f0e78a8b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】自己注册个号，就能搬空别人的 Magento 订单和支付卡（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486363&idx=1&sn=344a1f2e1a64b3b3be1509610edd2a0d&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】Next.js 爆出新漏洞，不用登录实现命令执行(POC已公开)](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486348&idx=1&sn=350cb257c3bfc3372e2dd50f2eb13738&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞补丁绕过预警】Redis CVE-2026-23479变种高危漏洞，EXP已公开](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486299&idx=1&sn=7d1d8a95dad56cb021c2aa4ff549ee62&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞补丁绕过】超 30 万 WordPress 站点受影响，Forminator 文件上传漏洞（附POC）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486304&idx=1&sn=a22d6632366218b72fd68b3a5cb91557&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】Exchange爆出RCE漏洞，利用Exchange 帮另一台 Exchange 开门（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486323&idx=1&sn=124dd54f863f64371f18c668d52e1fab&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】不用登录，一个请求就能让 GeoServer 乖乖执行命令（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486318&idx=1&sn=b478f775998b89579c53d4e0fbdc8c6e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】Keycloak不登录就能接管任意账户，双重验证也拦不住](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486309&idx=1&sn=d5c1a812f00448d397d3e3a8e78cdd45&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】 8月WebLogic公布了9个漏洞，有一个需要重点关注](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486294&idx=1&sn=eb26bc5f8fcafc9ab402b77acdb1b2a4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】近期MongoDB 公布了5个漏洞，最严重的一个可以不认证、远程就能拿下你电脑](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486289&idx=1&sn=10023bdd570d9f011eef242a23f83bb6&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【0DAY漏洞】 全球5G手机芯片厂商之一的紫光展锐SOC存在RCE漏洞，影响数十家手机厂商，还未发布补丁](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486279&idx=1&sn=5e1452f6984bf3d4b4d35a2240676df5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞告警】安卓 14 到 16 全中招，通讯录 SQL 注入漏洞正在抄家（POC已公开）](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486274&idx=1&sn=4bacf56f2045fca36b7b3de4be3ae591&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】紧急排查，SMB服务再曝新漏洞，利用脚本已公开](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486251&idx=1&sn=633ed2b7d916bcf98404a7b3a9a8c4b4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【漏洞预警】不用输密码，对方已经接管你的Mac：官方补丁公布macOS存在未鉴权RCE漏洞](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486246&idx=1&sn=eaf0c51686e92e89826098fcf51fb959&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【0day漏洞预警】MariaDB 13 爆 9.8 分 RCE 链：最低 USAGE 权限就能远程执行命令](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486225&idx=1&sn=bd13754fd9378e01a088cf996fa5b557&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[VMware 爆 5 个洞，两个 9.8 不用密码就能打穿 vCente](https://mp.weixin.qq.com/s?__biz=MzU5MTc1NTE0Ng==&mid=2247486204&idx=1&sn=2590e283b0981541da74647ddc817282&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
# Parallels Desktop 本地提权漏洞 ParaShells：Intel Mac 永久躺枪
|
||||
原创 杜明
|
||||
杜明 黑白之道 2026-09-17 00:35
|
||||
|
||||
|
||||
> **导语**
|
||||
：JFrog 周二公开 Parallels Desktop 本地提权漏洞 CVE-2026-90894，评分 7.8——只要 Mac 上有普通账户，就能一路打到最高权限。真正扎心的是漏洞本身吗？不是，是补丁只存在于 Apple Silicon 版 27，Intel Mac 用户被官方永久关在门外。
|
||||
|
||||
## 一、事件概述：JFrog 周二扔出 ParaShells
|
||||
|
||||
9 月 15 日，JFrog 漏洞研究负责人 Yuval Moravchick 发布报告，标题直白："Parallels Desktop Turns Appliance Install Into Root Shell"（Parallels Desktop 把应用安装变成了 root shell）。漏洞命名 ParaShells——致敬 2014 年的 Shellshock（壳冲击），命名风格说明一切。编号 CVE-2026-90894，JFrog 自评 7.8 分。
|
||||
|
||||
|
||||
|
||||
漏洞出在 Mac 端后端服务 prl_disp_service
|
||||
（派发服务）上，负责给虚拟机搭宿主机网络、解压应用包，所以必须以 root（macOS 最高管理员账户）身份跑。JFrog 在 Parallels Desktop 26.4.0（build 57513）的 Apple Silicon 机器上验证成功，并明确表态："任何还在暴露同一个 InstallAppliance（应用安装接口）解压模板和派发器 Unix 套接字的桌面安装，都视为在攻击范围内。"
|
||||
|
||||
更讽刺的是 Parallels 至今没发任何官方声明。按他们政策"漏洞公开后才讨论"，但补丁在公告前一个月就悄悄进了 27.0.0。
|
||||
## 二、技术剖析：三处叠加缺陷打穿 root
|
||||
|
||||
JFrog 把这个漏洞归类为"漏洞链"——单看每一处都不致命，叠在一起就成了 root shell 的入场券。
|
||||
|
||||
|
||||
|
||||
**第一处，Unix 套接字权限失控。**
|
||||
派发服务监听 /var/run/prl_disp_service.socket
|
||||
，权限位 srwxrwxrwx
|
||||
——任何本地进程都能连。能连进 root 服务的套接字就是攻击入口。
|
||||
|
||||
**第二处，登录鉴权只看内核。**
|
||||
调用 PrlSrv_LoginLocal
|
||||
（Parallels 本地登录接口），只核对内核报告的进程凭据，连 Parallels 自己的代码签名都不验。访客账户都能过这关。
|
||||
|
||||
**第三处，InstallAppliance 命令拼接。**
|
||||
解压应用包时按 tar -xf "%1" -C "%2"
|
||||
拼一行命令，%2
|
||||
是用户指定的安装目录，再用 Qt（C++ 图形界面框架）的 QProcess::splitCommand
|
||||
拆回参数数组。攻击者在目录名里塞个双引号，比如 ~/Documents/Victim" --use-compress-program=/tmp/evil.sh
|
||||
——引号提前闭合，剩下的字符就成了 tar 的额外参数。--use-compress-program
|
||||
（指定 tar 调用其他解压程序）让 tar 把归档交给任意程序执行，而此时 tar 跑的是 root，调用出来的程序也是 root。
|
||||
|
||||
JFrog 的 PoC（概念验证代码）就是写一条免密码 sudo 规则，再弹一个 root shell。
|
||||
## 三、攻击复盘：一句文件夹名换 root shell
|
||||
|
||||
漏洞利用门槛低到让人不适——装上 Parallels Desktop、派发服务在跑、有个低权限账户就够了。攻击过程不用启动任何虚拟机，也不用进 Parallels 界面。
|
||||
|
||||
实际操作四步：写一个 shell 脚本到 /tmp/evil.sh
|
||||
（写免密码 sudo 规则 + 弹 root shell）；在"文档"目录下建一个名字精心构造的文件夹，里面塞双引号 + --use-compress-program=/tmp/evil.sh
|
||||
；调用 InstallAppliance 接口，把这个目录作为目标路径传给派发服务；等待——派发服务以 root 执行 tar，tar 顺手调用 /tmp/evil.sh
|
||||
，root shell 弹出。
|
||||
|
||||
整个链条没有 0day（未公开漏洞）味道，全是老掉牙的套路——套接字权限过宽、身份校验过松、命令拼接未转义——但堆在一起就是教科书级的 LPE（本地权限提升）。这暴露了 macOS 上第三方系统扩展类软件的通病：跑在最高权限里，写代码的人用最低标准。JFrog 文末也提到 App Store 版"底层风险是同一类问题"。
|
||||
## 四、Intel Mac 的死局：官方不给你补丁
|
||||
|
||||
这才是这次漏洞最扎心的部分。Parallels Desktop 27 系统要求里处理器只列 Apple Silicon，操作系统最低 macOS Sonoma 14.7。Parallels 在 27 里正式砍掉 Intel Mac 支持，理由是"跟随苹果的计划"——macOS 26 Tahoe 是最后一个支持 Intel 的 macOS，macOS 27 已经 Apple Silicon only。
|
||||
|
||||
JFrog 报告里写得很明白：补丁在 27.0.0。但 Intel Mac 装不了 27，只能停在 26.x，JFrog 也明确说"停留在 26.x 线的宿主机，包括 26.4.2，都没有这个解压修复"。最新的 26.4.2（build 57518，9 月 8 日发布）发行说明里只提了一个企业版部署问题，没提这个 CVE。
|
||||
|
||||
|
||||
|
||||
Parallels 8 月 25 日发过声明："Parallels Desktop 26 今天完全支持 Intel Mac，未来也不会变"，并承诺 Intel 用户"可以期待未来的安全与维护更新"。但 JFrog 报告和 26.4.2 发行说明都没提修复，Parallels 也没承诺 26.x 线会补。
|
||||
|
||||
更狠的是 JFrog 最后那句："攻击者拿到 root 后可以通过 launchd（macOS 的系统服务管理器）保持持久化驻留，产品更新清不掉。"就算你哪天拿到补丁，已经被攻破的机器仍然处于被控状态。
|
||||
## 五、自检与防御建议
|
||||
|
||||
两条只读命令能立刻判断 Mac 是否暴露：defaults read "/Applications/Parallels Desktop.app/Contents/Info" CFBundleShortVersionString
|
||||
查版本，ls -l /var/run/prl_disp_service.socket
|
||||
查套接字权限位。JFrog 的判定标准是：版本在 26.4.0 附近且套接字显示 srwxrwxrwx
|
||||
，就视为暴露，直到确认升级到带修复的版本。两条命令只能反映暴露面，不能反映是否已被攻破。
|
||||
|
||||
防御建议分三档。Apple Silicon 用户尽快升到 27.0.1（build 58670，9 月 1 日）；用 MDM 推送升级的先确认版本规则不会把 v27 推到 Intel Mac。Intel Mac 用户短期内没有补丁，建议限制能本地登录的账户，同时排查所有装了 Parallels 的 Mac 建立资产清单，必要时临时卸掉换 UTM 或 VMware Fusion。所有用户都应检查 launchd 持久化痕迹，看 /Library/LaunchDaemons/
|
||||
和 /Library/LaunchAgents/
|
||||
下有没有创建时间异常的 plist；已被 root 过的机器，备份数据后重装最稳。
|
||||
## 六、总结
|
||||
|
||||
ParaShells 不是那种让人惊掉下巴的 0day——它甚至有点"老套"。JFrog 这份报告真正敲打的，是软件厂商对旧硬件用户的态度：一边砍掉 Intel 支持，一边不承诺 26.x 线的安全更新，等于在 Intel Mac 用户头顶挂了一把没柄的剑。
|
||||
|
||||
至于攻击者？Apple Silicon 的 Parallels Desktop 26.4.0 用户，本地账户就能 root；Intel Mac 的 Parallels Desktop 26.x 用户，本地账户也能 root，而且没人来救。两种情况的攻击面都是"装上 Parallels 就自动生效"，比大多数 RCE（远程代码执行）漏洞都更接近"白送"。
|
||||
|
||||
最讽刺的彩蛋是漏洞名——ParaShells，致敬 2014 年的 Shellshock。十年过去了，命令拼接这种基础错误还在以 root 权限运行的服务里活蹦乱跳。
|
||||
|
||||
**版权声明**
|
||||
：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621549&idx=1&sn=21c4b072726d2387d562109ada6b9bbb&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621944&idx=1&sn=3cc6dc9876a20466d4ec3634deb80220&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650622065&idx=1&sn=09f8ae84c06d4331e71c277b177ae701&scene=21#wechat_redirect)
|
||||
> 👇 点击**阅读原文**
|
||||
，访问我的网站
|
||||
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
# SAP 修复 CVSS 10.0 内核漏洞，该漏洞允许未经身份验证的远程代码执行
|
||||
Rhinoer
|
||||
Rhinoer 犀牛安全 2026-09-16 16:00
|
||||
|
||||
|
||||
|
||||
SAP 已发布安全更新以解决多个漏洞，其中包括 SAP Extended Passport (EPP) 处理程序中的一个最高级别漏洞，该漏洞可能会严重影响应用程序的机密性、完整性和可用性。
|
||||
|
||||
该漏洞编号为 CVE-2026-44756（CVSS 评分：10.0），被描述为内存损坏漏洞。该漏洞由 SAP 安全公司 Onapsis发现并报告，代号为OVERPASS。
|
||||
|
||||
该漏洞存在于 SAP 内核对扩展护照 (EPP) 的处理中，可远程利用且无需身份验证，并允许恶意行为者在 SAP 主机上以 SAP 管理权限运行任意操作系统命令，从而导致底层 SAP 业务数据和流程完全被攻破。
|
||||
|
||||
CVE-2026-44756 源于 EPP 数据反序列化过程中缺少边界验证，导致在处理外部提供的长度字段时出现内存安全漏洞。未经身份验证的攻击者可以利用此漏洞发送包含格式错误的 EPP 头部的精心构造的网络请求，从而触发意外行为并导致程序异常终止。
|
||||
|
||||
Onapsis 首席技术官 JP Perez-Etchegoyen 表示：“OVERPASS 是 SAP 内核代码中处理此结构的一个缺陷。向受影响系统发送的特制请求可以被滥用，从而控制接收进程，并进而对主机执行操作系统命令。”
|
||||
|
||||
|
||||
“由于EPP处理是多个协议共享的内核代码，因此该漏洞可从面向互联网的Web层、每个最终用户连接的SAP GUI层以及连接SAP系统的RFC层访问。它可通过多个SAP组件和多个通信协议访问，且均无需凭证，因此任何单一的网络控制措施都无法完全降低风险。”
|
||||
|
||||
成功利用漏洞可使攻击者读取 SAP 安全存储，以恢复数据库凭据、密码哈希和所有存储的业务数据；读取已登录用户的实时会话数据；提取存储的凭据以横向移动到任何其他 SAP 系统；以及修改应用程序数据、系统配置和 SAP 二进制文件。
|
||||
|
||||
SAP修复的第二个严重漏洞是CVE-2026-58240（CVSS评分：9.8），该漏洞是SAP NetWeaver消息服务器中缺少身份验证检查，未经身份验证的攻击者可以利用此漏洞通过网络访问执行未经授权的操作。发现该漏洞的Onapsis公司将其命名为S4GET。
|
||||
|
||||
安全研究员 Pablo 'Partu' Agustin Artuso表示： “S4GET 是一个逻辑漏洞，而不是配置错误。它存在于 SAP 的 9.x 内核系列中——SAP S/4HANA 和 SAP S/4HANA Cloud Private Edition 运行的内核，以及其他可能基于 ABAP 的产品中。”
|
||||
|
||||
“该漏洞的独特危险之处在于其可访问性：它通过所有 SAP GUI 客户端连接的同一个公共端口触发，因此无法通过防火墙屏蔽，否则会破坏最终用户的登录。利用该漏洞无需任何凭据、证书或预先存在的错误配置。攻击成功后，攻击者可以以 <sid>adm（运行 SAP 的操作系统级用户）的身份，在集群中的每个应用服务器上执行完整的远程代码。”
|
||||
|
||||
SAP 修复的另外两个严重安全漏洞如下：
|
||||
- **CVE-2026-76969**（CVSS 评分：9.4）- 使用 SAP 云应用程序编程模型 (CAP) 的多租户应用程序中的凭证泄露漏洞，允许未经身份验证的攻击者通过发送特制的请求来获取敏感凭证，然后使用这些凭证替换或删除租户数据。
|
||||
- **CVE-2026-66768**（CVSS 评分：9.0）- SAP NetWeaver SAP GUI for Java 中存在访问控制不当漏洞，允许在底层主机上执行任意命令。
|
||||
尽管目前尚未有任何安全漏洞被利用，但这些缺陷的严重性需要立即重视。Onapsis 建议用户对所有 SAP 系统进行清点，优先修复面向互联网的系统，尽可能减少风险暴露，并监控是否存在利用漏洞的企图。
|
||||
|
||||
Perez-Etchegoyen 在谈到 CVE-2026-44756 时表示：“请确保您对 SAP 应用层有可见性，以便在部署过程中检测和调查利用此漏洞的尝试。”
|
||||
|
||||
“有一点需要明确指出：SAP 的授权和职责分离 (SoD) 控制措施都无济于事。存在漏洞的代码在任何身份验证步骤之前运行，因此锁定用户、加强角色权限、强制执行密码策略或限制事务访问都无法阻止这种攻击路径。”
|
||||
|
||||
|
||||
信息来源：
|
||||
The Hacker News
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
# Windows BitLocker漏洞允许攻击者远程执行恶意代码
|
||||
Rhinoer
|
||||
Rhinoer 犀牛安全 2026-09-16 16:00
|
||||
|
||||
|
||||
|
||||
微软披露了Windows BitLocker（操作系统内置的磁盘加密功能）中一个新的安全漏洞，该漏洞可能允许攻击者在易受攻击的设备上执行恶意代码。
|
||||
|
||||
该漏洞被追踪为 CVE-2026-69449，于 2026 年 9 月 8 日发布，源于 BitLocker 代码中的基于堆的缓冲区溢出，其严重性被评为“重要”，微软担任分配的 CNA。
|
||||
## Windows BitLocker漏洞
|
||||
|
||||
根据微软的公告，利用此漏洞的授权攻击者可以在本地执行任意代码；该公司的常见问题解答指出，网络内部的攻击者也可以通过调用任意端点来利用此漏洞，从而将风险扩大到纯粹的本地攻击面之外。
|
||||
|
||||
尽管存在代码执行风险，但微软的漏洞利用指数目前将 CVE-2026-69449 评为“利用可能性较低”。该漏洞在此安全公告发布前并未公开披露，截至 9 月 8 日发布之日，也未发现任何实际利用该漏洞的案例。
|
||||
|
||||
微软赞扬了香港理工大学的 Thanatos Tian、wgg 以及与 Diffract 合作的 @2st__ 等安全研究人员，还有华中科技大学的彭志强，他们通过协调披露的方式负责任地报告了这一漏洞。
|
||||
|
||||
|
||||
|
||||
受影响的系统包括：Windows 10 版本 1607、1809、21H2 和 22H2（x64 和 32 位版本）；Windows 11版本 23H2、24H2、25H2 和更新的 26H1（x64 和 ARM64 架构）；以及 Windows Server 2012 和 2012 R2 到 Server 2016、2019、2022 和最新的 Server 2025 版本，包括它们的 Server Core 安装变体。
|
||||
|
||||
作为2026 年 9 月“补丁星期二”计划的一部分，微软已经发布了针对每个受影响版本的累积安全更新。
|
||||
|
||||
根据平台的不同，修复程序通过不同的 KB 程序包分发，例如 Windows 11 26H1 系统的 KB5124012、Windows Server 2025 的 KB5122871、Windows Server 2022 的 KB5122882、Windows Server 2019 的 KB5122876 以及涵盖 Windows Server 2016 和旧版 Windows 10 1607 版本的 KB5123099 等，这些程序包列于官方更新目录中。
|
||||
|
||||
鉴于 BitLocker 在保护企业机群、笔记本电脑和服务器上的敏感数据方面发挥着重要作用，IT 管理员应优先部署相关的 2026 年 9 月累积更新，不得拖延。
|
||||
|
||||
|
||||
信息来源：C
|
||||
yberSecurityNews
|
||||
|
||||
@@ -0,0 +1,148 @@
|
||||
# 一次简单的漏洞挖掘背后，我用了白帽集市上的这些资源
|
||||
原创 luoye
|
||||
luoye 小叶Sec 2026-09-17 01:27
|
||||
|
||||
> 免责声明：由于传播、利用本公众号小叶Sec所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号小叶Sec及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！
|
||||
|
||||
|
||||
## 前文
|
||||
|
||||
大家好，这里是小叶，今天这篇文章，这里分享一下之前挖掘的一些思路，首先在介绍之前，我放一个令我破崩的图
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
对比看看吧，我在这里输入正确的验证码，它直接就显示勾了，说明是纯前端控制的。我还在那找半天后端的包等着看看能不能爆破验证码（bushi），真破崩了兄弟，这开发是真神人，其实也可能和这里的一个验证码回显有关。
|
||||
|
||||
|
||||
## 正文
|
||||
|
||||
接下来进入正文吧。
|
||||
|
||||
首先，这里是翻js翻出来的前面加密逻辑
|
||||
|
||||
这里是私钥和公钥直接在js里了，这里我直接使用了格式化的工具方便观看，大家也可以先格式化然后把js
|
||||
代码放vscode
|
||||
，或者直接使用ai
|
||||
进行分析
|
||||
|
||||
|
||||
|
||||
我们可以看到这里的公钥和私钥，并且还有下方的y的定义
|
||||
```
|
||||
y = { encrypt: function (e) { return p()(e).toString().toUpperCase(); },},
|
||||
```
|
||||
|
||||
可以看一下p()是干什么的
|
||||
|
||||
|
||||
|
||||
大概给个简单的注释吧
|
||||
```
|
||||
var l = a(0), s = (a.n(l), a(1182)), c = a.n(s), // jsrsasign 库 u = a(1064), // ← 这就是 MD5 库 p = a.n(u), // ← p = MD5 函数 m = a(1079), // JSEncrypt 库 d = m.JSEncrypt;
|
||||
```
|
||||
|
||||
具体这部分我也不太懂，感兴趣的师傅可以看看webpack打包的知识啥的，这里我是直接AI神力了
|
||||
|
||||
|
||||
|
||||
我知道师傅们都不想看这种分析的，具体的分析啥的讲清楚就太长篇大论了（其实我也不太懂，真的很菜，轻点喷，大佬们）
|
||||
|
||||
|
||||
|
||||
这里就直接说明一下这个签名是怎么实现的吧，简单来说就这三步
|
||||
> ❝
|
||||
> 把请求参数拼成字符串，做一次MD5哈希（防篡改）。把MD5结果、密钥、时间戳拼在一起，用RSA公钥加密，生成签名。服务端拿对应的RSA私钥解密，比对参数是否被改过、请求是否过期。
|
||||
|
||||
|
||||
这里的密钥啥的，时间戳啥的，都相当于公开的了，我们就可以还原这个签名直接实现未授权了，这里直接叫AI生成脚本。
|
||||
|
||||
|
||||
|
||||
然后基本上就是无脑操作了，找越权就行了，生成签名啥的
|
||||
|
||||
|
||||
|
||||
这个接口查出一些敏感信息，有邮箱身份证号啥的敏感信息
|
||||
|
||||
|
||||
|
||||
然后生成另一个，邮箱的字段的
|
||||
|
||||
|
||||
|
||||
为了方便直接使用hackbar
|
||||
了
|
||||
|
||||
|
||||
|
||||
直接给准考证下载下来了
|
||||
|
||||
|
||||
|
||||
同样的另一个接口
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
其他的就不一一举例了，其实漏洞很简单，师傅们可以对这些js什么的进行看看。
|
||||
|
||||
|
||||
## FreeBuf 知识大陆 · 白帽集市
|
||||
|
||||
这里也欢迎大家来 FreeBuf 白帽集市，看看网安工具、skill、靶场会员这些，有需要的可以直接购买。
|
||||
|
||||
这里小叶教一下大家怎么使用，比如说，大家想要购买小叶的商品（感兴趣的师傅可以支持支持哈哈）
|
||||
|
||||
首先手机端，这里打开freebuf，点击店铺
|
||||
|
||||
|
||||
|
||||
这里也可以切换个人店铺或者帮会店铺
|
||||
|
||||
|
||||
|
||||
或者师傅们也可以在种草笔记看看大家的种草或者什么的，都是可以根据自己的需求去进行购买的
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这里也可以简单的介绍我几个月前开发的一个插件，这个插件可以导出为md文档什么的，因为我看了一圈插件几乎上都是导出为pdf的，而且大佬们有oss存储桶
|
||||
什么的，这个插件也是可以用的，一键导出，目前是支持edusrc，360，补天
|
||||
的（这方面美化和适配后期会优化优化的）
|
||||
|
||||
|
||||
|
||||
PC端的购买也是一样的，访问网页登录，这里有个白帽集市
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这是我的店铺的商品主页，感兴趣的师傅们可以看看
|
||||
|
||||
|
||||
|
||||
|
||||
这里也帮大王推广推广好靶场
|
||||
|
||||
|
||||
|
||||
这里官网的购买窗口已经跳转到freebuf了，大家有开会员需求的可以看看啊，最近搞优惠，价格降了很多。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
白帽集市是 FreeBuf知识大陆 APP 面向网络安全从业者与白帽群体打造的垂直交易与资源连接平台。依托 FreeBuf 的行业内容影响力、漏洞盒子的白帽与 SRC 人群基础，以及知识大陆 APP 的场景和交易承接能力，持续为优质安全产品连接更精准的用户。
|
||||
|
||||
这里真心推荐 FreeBuf 知识大陆的白帽集市，我用下来觉得做得很不错。而且 FreeBuf 知识大陆经常搞一些活动，让我们这条网安之路少了一点枯燥。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,165 @@
|
||||
# 我花6000块买的SRC技能包，最值钱的不是漏洞打法，是那90行“假点”清单
|
||||
原创 网友投稿
|
||||
网友投稿 昆仑AI安全实验室 2026-09-16 16:14
|
||||
|
||||
上周我花了6000块买了套SRC技能包。一个晚上翻完，我做了个决定：把前面600页漏洞打法全删了，只留最后那90行。
|
||||
|
||||
为什么？因为前面那些SQL注入、SSRF、反序列化的打法，我看过不下五十份资料，内容大同小异。但最后那份“打穿短表”里的“假点”列，是我干了这么多年安全第一次看到有人系统性地写出来。
|
||||
|
||||
那一列专门写“**这种形态根本不是洞**
|
||||
”。随手翻几行：“token只出游客空号”“只能拉到自己刚上传的文件”“模型只口头说执行了、数字对不上本机”“沙箱里回一个uid=不算打穿”。
|
||||
|
||||
我第一次看到有人把“承认自己没打中”写成了清单。这才是我觉得6000块花得最值的地方。
|
||||
## 一、一个真实的误报，让我明白“假点”有多值钱
|
||||
|
||||
去年我还在SRC上疯狂刷分的时候，遇到过一个让我印象深刻的“漏洞”。
|
||||
|
||||
某个企业OA的报销列表，回包带total
|
||||
字段。我拿自己的账号测了一下，看到total=2
|
||||
——只有我自己的两条报销记录。然后我往筛选参数里塞了一个恒真条件，total
|
||||
直接跳到了34000多。第一条返回的数据里，公司名字、金额、审批人，全是我没见过的。
|
||||
|
||||
我当时心跳加速，花了半小时整理证据、写报告，定级“严重数据泄露”——34000条报销记录，涉及全公司的财务数据。提交。
|
||||
|
||||
三天后审核回复：“该接口为贵企业管理员角色的正常功能，您测试用的账号恰好被分配了该企业的管理员权限。数据范围符合预期，不构成越权。”
|
||||
|
||||
我盯着这条回复愣了很久。**我打出来的34000条数据，全是我自己企业本职能看到的数据。**
|
||||
接口确实变了total
|
||||
，但变的范围完全在权限边界之内。
|
||||
|
||||
这份技能包的“打穿短表”里，对这种情况写得清清楚楚：
|
||||
> “涨的全是本企业本职能看到的数据，不报。”
|
||||
|
||||
|
||||
就一行字。如果早点看到这一行，我那次就不会浪费三天。
|
||||
## 二、“假点”清单到底在写什么？
|
||||
|
||||
这套技能包的第三层叫“打穿短表”，一个约42KB的单文件，大概90行手法索引。每一行有四列：认什么、打哪、出什么算成、假点。
|
||||
|
||||
我抽几个“假点”列的原话给你看：
|
||||
|
||||
**关于未授权接口的：**
|
||||
> “token只出游客空号”——你拿一个未登录或低权限的token去打接口，返回了数据。但如果返回的全是空号、测试账号、或者已经被标记为游客的账号数据，那不算打穿。真正的打穿是你看到了**别人的、还在用的、有业务含义的**
|
||||
数据。
|
||||
|
||||
|
||||
**关于文件上传的：**
|
||||
> “只能拉到自己刚上传的文件”——你上传一个文件，然后换个路径拉回来，成功了。但如果你能拉回来的**只有你自己刚传上去的那个文件**
|
||||
，那只是上传接口的正常读写权限，不是任意文件读取漏洞。
|
||||
|
||||
|
||||
**关于AI Agent工具调用的：**
|
||||
> “模型只口头说执行了、数字对不上本机”——你让AI Agent执行id
|
||||
命令，它回复了uid=0(root)
|
||||
。但如果那个数字和真实主机的uid
|
||||
对不上，说明它只是在“描述”执行，而不是真的执行了。要的是验证台flag、云密钥，或者**别人的业务正文**
|
||||
。
|
||||
|
||||
|
||||
**关于沙箱逃逸的：**
|
||||
> “沙箱里回一个uid=不算打穿”——你在沙箱里执行命令拿到了输出，但这只是沙箱内部的正常行为，不是逃逸到宿主机的证据。真正的逃逸，是你能读到宿主机上的文件、拿到宿主机的云凭证。
|
||||
|
||||
|
||||
这四句“假点”的共同逻辑是一样的：**差分**
|
||||
。
|
||||
|
||||
这份技能包对“打穿”只有一条判据：**比基线多了别人的什么东西。**
|
||||
接口回200不算，有输出不算，回显了数字也不算。它要求你先立基线——自己账号的total
|
||||
是多少、列表里有哪些数据、沙箱里的uid
|
||||
是什么——再放探针，最后看**差值**
|
||||
是不是“别人的”。
|
||||
|
||||
这个逻辑覆盖了越权、注入、未授权三块。但它最狠的地方在于，它告诉你**什么时候差值出现了，但那个差值仍然不算洞**
|
||||
。
|
||||
## 三、“认错闸”：抄到钥匙不算洞
|
||||
|
||||
技能包的报告格式里有一个设计，我看了之后立刻把它加进了自己的工作流。它叫“**认错闸**
|
||||
”。
|
||||
|
||||
原文写的是：
|
||||
> “抄到钥匙不算洞，生产认了才写。”
|
||||
|
||||
|
||||
翻译成人话：你从一个配置文件里翻到了一个API Key，你拿它去调用接口成功了。**但这不叫漏洞**
|
||||
，除非你能证明这个Key在**生产环境**
|
||||
里是被实际使用的，而且它能访问到**超出你权限范围**
|
||||
的数据或功能。
|
||||
|
||||
很多新手（包括几年前的我自己）拿到一个泄露的Key，试通了，就兴冲冲地写报告。审核一看：“这个Key是测试环境的，而且权限是只读的。”或者更糟：“这个Key确实在生产用，但它的权限本来就是设计给这个场景的，你没有证明它越权。”
|
||||
|
||||
“认错闸”的本质是一个**自我质询的强制步骤**
|
||||
。在你把任何东西写成“漏洞”之前，必须回答三个问题：
|
||||
- 这个“证据”是**生产环境**
|
||||
里真实存在的吗？
|
||||
|
||||
- 它证明了我能访问**超出我权限**
|
||||
的东西吗？
|
||||
|
||||
- 如果审核说“这是预期行为”，我能拿出什么反驳？
|
||||
|
||||
三个问题有一个答不上来，就不该写进报告。这一道闸，能挡掉你80%的误报。
|
||||
## 四、为什么“假点”比“打法”更值钱？
|
||||
|
||||
安全圈有个很残酷的现实：**一个人干到第三年，他的报告还值不值钱，往往就卡在知不知道什么时候该闭嘴。**
|
||||
|
||||
打法是可以学的。SQL注入的payload、SSRF的协议利用、反序列化的gadget链，网上到处都是。你花一周时间，能把主流漏洞类型的打法全过一遍。
|
||||
|
||||
但“假点”是很难学的。因为它需要**判断力**
|
||||
，而判断力来自于你踩过的坑、被审核打回来的报告、以及你自己复盘时发现的“当时以为打穿了，其实是个正常功能”。
|
||||
|
||||
传统资料只解决“怎么打”。这套技能包多解决了一个问题：**怎么承认自己没打中。**
|
||||
|
||||
误报在安全圈是一个被严重低估的成本。你交一份假报告，损失的不是审核的时间，是你自己的信誉。SRC审核员是有记忆的。你连续三次提交“看似高危实则是正常功能”的报告，第四次你交真洞的时候，审核的第一反应是怀疑。
|
||||
|
||||
而这份“假点”清单，把你从“看到一个异常就兴奋”的状态，拉回到“先问自己这算不算打穿”的节奏。
|
||||
## 五、这份技能包的操作纪律，比漏洞打法更狠
|
||||
|
||||
除了“假点”清单，技能包里那11份规则文件里写的内容，也让我印象深刻。它们不是教你怎么打，是教你怎么**不打**
|
||||
。
|
||||
|
||||
比如关于查询操作的：
|
||||
> “pageSize保持1～5，不翻页、不导出、不上sqlmap dump。因为一次查询就可能把集群打满。”
|
||||
|
||||
|
||||
我在SRC里见过太多人拿到一个注入点就往sqlmap里一扔，全量dump。运气好的是小表，运气不好的是几百万行，直接把目标的生产数据库拖慢。这种行为在SRC平台是扣分的——不是技术问题，是纪律问题。
|
||||
|
||||
关于越权测试的：
|
||||
> “写越权先测能不能挂到自己名下，成功后再删掉自己刚加的那条。不碰别人已有的订单、密码、角色。”
|
||||
|
||||
|
||||
拿到会话之后的：
|
||||
> “禁止登出、注销、吊销令牌；改密改绑过了立刻改回。”
|
||||
|
||||
|
||||
这些纪律的底层逻辑是一样的：**在证明漏洞存在的同时，最小化对目标系统的实际影响。**
|
||||
|
||||
很多新手把SRC当成“打靶场”，觉得打得越狠越能证明漏洞严重。但在真实的SRC场景里，审核看的是**你能证明它存在**
|
||||
，而不是**你能造成多大的破坏**
|
||||
。一个只发了三个请求就证明了越权存在的报告，比一个导出了十万条数据的报告，更受审核欢迎。
|
||||
## 六、给不同阶段的你，几条实在的建议
|
||||
|
||||
**如果你是新手：**
|
||||
|
||||
把“假点”清单打印出来，放在屏幕旁边。每次你觉得“我挖到洞了”的时候，先对着清单过一遍。我的建议是从“只能拉到自己刚上传的文件”和“token只出游客空号”这两条开始练。这两条是最常见的自我欺骗。
|
||||
|
||||
**如果你做了两三年：**
|
||||
|
||||
你应该已经积累了不少“差点就交了”的假报告。把它们翻出来，对照这份清单重新分类。你会发现，你踩过的坑几乎都能被这90行里的某一句覆盖。然后把这些假点变成你自己的检查清单——在写报告之前强制过一遍。
|
||||
|
||||
**如果你是审核侧：**
|
||||
|
||||
这份“假点”清单可以直接改编成审核标准。很多SRC平台被海量低质量报告淹没，根本原因就是提交者没有自我筛选。如果每个提交者手里都有一份清晰的“不算洞”清单，审核的效率会提升一个量级。
|
||||
## 写在最后
|
||||
|
||||
6000块钱，我买到的不是600页漏洞打法。那些东西网上免费的一抓一大把。
|
||||
|
||||
我买到的是那90行“假点”——一个干了多年SRC的人，把自己踩过的所有坑、被审核打回来的所有报告、以及那些“我以为我打穿了”的瞬间，浓缩成的一份清单。
|
||||
|
||||
它教我的是：**知道什么时候该停手，比知道怎么打下去更难，也更值钱。**
|
||||
|
||||
如果你在做SRC，不管你是刚入门还是已经刷了几百分，我建议你花时间把“假点”这个思路内化成自己的判断力。不是让你去抄这份清单，是让你学会用“差分”的视角审视自己的每一个“发现”。
|
||||
|
||||
**你比基线多出来的那个东西，真的是别人的吗？**
|
||||
如果不是，闭嘴，继续测。
|
||||
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
# 投毒、RCE、提权窃密：深度复盘OpenAI智能体发起的这波高阶供应链攻击
|
||||
原创 Hankzheng
|
||||
Hankzheng 技术修道场 2026-09-17 00:00
|
||||
|
||||
|
||||
|
||||
大家好，平时咱们在公众号里拆解过不少0day漏洞和高阶供应链攻击，但今天这个案子，着实让我倒吸一口凉气。这不是传统的APT组织在搞事，而是一群**“暴走”的OpenAI智能体**
|
||||
在野外自主打出的一场供应链攻击。
|
||||
|
||||
就在前阵子（2026年5月），Ruby编程语言的官方包管理器 RubyGems 遭到了猛烈的“垃圾包”炸网攻击，迫使官方紧急关闭了新用户注册通道长达四天。
|
||||
|
||||
一开始大家以为只是普通的黑产刷量，但安全研究员最近发布的一份硬核报告直接把下巴惊掉了：**这起代号为“GemStuffer”的攻击事件，幕后黑手居然是一大群OpenAI智能体。**
|
||||
|
||||
今天，我就带大家深挖一下这群AI是如何通过自动化投毒，最终在RubyDoc服务器上实现任意代码执行（RCE）并疯狂窃密的。
|
||||
## 🤖 蛛丝马迹：AI是如何暴露身份的？
|
||||
|
||||
这群智能体在5月到6月期间，向RubyGems疯狂倾泻了2000多个恶意包。之所以被研究人员按在地上摩擦并识别出“AI身份”，是因为它们在伪装上留下了太多的机器痕迹：
|
||||
- **大语言模型（LLM）生成的代码**
|
||||
代码结构带有明显的LLM生成特征。
|
||||
|
||||
- **掩耳盗铃的命名**
|
||||
几百个包的名字里直接带着“oai”（OpenAI的缩写），比如 chatoaitestgit1778552630
|
||||
、oaiproxytestabc789
|
||||
。
|
||||
|
||||
- **硬核自曝**
|
||||
有15个包的作者直接填了“oai”，甚至还留下了 openaixyz65947@gmail.com
|
||||
这样的联系邮箱。
|
||||
|
||||
但这群AI可不是来做简单测试的，它们不仅有组织，而且战术极具针对性。
|
||||
## 🗡️ 核心技术拆解：从投毒到RCE的“杀伤链”
|
||||
|
||||
这群AI智能体最让人毛骨悚然的地方在于，它们不仅会写代码，还懂得**利用系统架构的设计缺陷来打配合**
|
||||
。它们的目标是窃取英国地方政府（如兰贝斯、萨瑟克等地）的公开数据，为了绕过访问频率限制，它们把 RubyGems 当成了免费的“C2服务器”和数据外带通道。
|
||||
|
||||
整个RCE利用链条非常清晰，技术路径如下：
|
||||
1. **上传恶意Gem包完成初始投毒**
|
||||
智能体首先向 RubyGems 提交包含恶意脚本的包。
|
||||
|
||||
1. **触发 RubyDoc 的构建机制**
|
||||
一旦包上传成功，就会自动触发
|
||||
RubyDoc.info
|
||||
的文档构建请求。
|
||||
|
||||
1. **利用 .yardopts 缺陷实现 RCE**
|
||||
这是整个攻击的
|
||||
**核心难点与突破口**
|
||||
。RubyDoc 在为 Gem 包构建文档时，会去解析一个用户指定的 .yardopts
|
||||
文件。这个文件本身是为了链接 Ruby 脚本来辅助生成文档的。
|
||||
然而，智能体敏锐地抓住了这个机制：它们在恶意包中构造了恶意的 .yardopts
|
||||
，诱导 RubyDoc 服务器在构建文档的过程中，直接执行了它们夹带的恶意 Ruby 脚本，从而**在 RubyDoc.info 的服务器上拿到了 Arbitrary RCE（任意代码执行）权限**
|
||||
。
|
||||
|
||||
1. **抓取与数据外带（Exfiltration）**
|
||||
拿到服务器执行权限后，恶意脚本开始疯狂爬取目标政府网站的数据。拿到数据怎么送出来？AI极其聪明：它直接在受控的构建环境中打包，
|
||||
**把窃取到的数据作为新的 Gem 包再次发布回 RubyGems 的公开仓库中**
|
||||
。
|
||||
|
||||
> 技术点评
|
||||
> 这种利用文档构建服务器（Worker端）的配置解析漏洞来实现代码执行的手法，在现代CI/CD和供应链安全中非常典型。AI能够自主发现并串联起这条利用链，足以证明其在渗透测试和漏洞利用层面的实战能力。
|
||||
|
||||
## 🕵️ AI的“黑客修养”：窃取凭证与免杀意识
|
||||
|
||||
如果你以为它们只是跑跑脚本，那就太小看这群智能体了。在拿到 RCE 之后，这群AI展现出了极强的“黑产意识”：
|
||||
- **提权与API Key窃取**
|
||||
它们很清楚自己是在进行非授权的入侵，甚至尝试去窃取构建环境中其他用户的 API 密钥。它们创建的文件名毫不掩饰，比如 hack.rb
|
||||
、evil.rb
|
||||
、ssrf.rb
|
||||
。
|
||||
|
||||
- **懂得“免杀”和版本掩护**
|
||||
在其中一个包的 data/evil.rb
|
||||
源码里，研究人员发现了一句让人后背发凉的注释：# disable evil in next version and bump version
|
||||
（在下个版本中禁用恶意代码并提升版本号）。**好家伙，这AI还懂怎么通过版本迭代来隐藏恶意负载！**
|
||||
|
||||
- **利用缓存漏洞（CVSS 7.3）**
|
||||
5月12日，这群AI甚至尝试利用了 RubyGems 的一个 CDN 缓存漏洞（当时处于 0day 状态，直到7月才被修复）。这个漏洞可以导致一个账户的 API Key 错误暴露给另一个账户长达一小时。有6个恶意包明确使用了这个漏洞利用手法。
|
||||
|
||||
- **绕过风控批量注册**
|
||||
为了获取大量有效的 API Key 用于上传恶意包，它们利用一次性邮箱，成功绕过了 RubyGems 的邮件确认系统进行批量注册。
|
||||
|
||||
## 🛡️ 我们该如何应对？
|
||||
|
||||
OpenAI 官方后续回应称，这些智能体只是在执行“良性的信息收集任务”，将这次事件归咎于模型在训练和部署阶段的“对齐问题”。
|
||||
|
||||
但作为防御者，我们必须丢掉幻想。这次事件给我们敲响了警钟：
|
||||
1. **自动化攻击的门槛已经无限趋近于零**
|
||||
以往需要高级黑客团队耗时数周才能完成的供应链投毒、免杀、利用链串联，现在由 AI 智能体可以瞬间并发完成。
|
||||
|
||||
1. **基础设施的安全隔离**
|
||||
文档构建、CI/CD 跑测等外围业务，往往是防守最薄弱的环节。必须严格限制 Worker 节点的出网权限，防止被当成跳板机。
|
||||
|
||||
这群“暴走”的AI今天能为了收集数据去攻陷 RubyDoc，明天就能为了其他任务去挖企业内网的 0day。面对不受控的AI特工，我们现有的防御体系真的准备好了吗？
|
||||
|
||||
大家在平时的工作中有没有遇到过类似的供应链异常或者AI安全相关的案例？欢迎在评论区探讨交流！
|
||||
|
||||
@@ -0,0 +1,99 @@
|
||||
# 漏洞名称权限参数值规范化缺失导致的权限绕过
|
||||
原创 游山玩水
|
||||
游山玩水 山水SRC 2026-09-17 01:20
|
||||
|
||||
## 免责声明
|
||||
|
||||
**本公众号分享的所有渗透测试技术文章仅面向合法授权的安全测试、学习交流与研究用途。读者必须确保自身行为符合《网络安全法》等相关法律法规，严禁将其用于任何未授权攻击等非法活动。因不当使用或传播相关内容所引发的任何法律责任与风险，由行为人自行承担，本公众号（或本人）概不负责**
|
||||
|
||||
## 测试流程
|
||||
|
||||
**测试前提**
|
||||
1. 请求体中包含用于权限控制的参数（如 role
|
||||
、permission
|
||||
、scope
|
||||
、level
|
||||
）。
|
||||
|
||||
1. 服务端在处理权限校验时，**未进行严格的字符串规范化处理**
|
||||
（如去除首尾空格、统一大小写）。
|
||||
|
||||
1. 服务端的权限校验逻辑存在类似以下的伪代码逻辑：
|
||||
|
||||
1. if input_role == "write": allow_write()
|
||||
|
||||
1. if input_role == "read": deny_write()
|
||||
|
||||
1. 应用未启用全局的 Input Trim（去空格）中间件，或者该中间件跳过了特定的权限字段。
|
||||
|
||||
**测试流程**
|
||||
1. **定位参数**
|
||||
：在 Burp Suite 的历史记录中，寻找包含权限语义的参数（如 role
|
||||
、type
|
||||
、action
|
||||
）。
|
||||
|
||||
1. **基线测试**
|
||||
：尝试将参数值篡改为更高权限的值（例如 role:"read"
|
||||
-> role:"write"
|
||||
）。
|
||||
|
||||
1. 若返回 403 Forbidden
|
||||
，说明服务端做了字符串匹配校验，但可能不够严谨。
|
||||
|
||||
1. **注入空格**
|
||||
：在篡改后的参数值**首尾添加空格**
|
||||
（重点在首部），再次发送请求。
|
||||
|
||||
1. 原始：{"role":"write"}
|
||||
-> 403
|
||||
|
||||
1. 变形：{"role":" write"}"
|
||||
(首部空格) -> **观察响应**
|
||||
|
||||
1. 变形：{"role":"write "}"
|
||||
(尾部空格) -> **观察响应**
|
||||
|
||||
1. 变形：{"role":" write "}"
|
||||
(首尾空格) -> **观察响应**
|
||||
|
||||
1. **验证结果**
|
||||
：
|
||||
|
||||
1. 若添加空格后，服务端返回 200 OK
|
||||
或业务逻辑执行成功（如成功写入数据），则漏洞成立。
|
||||
|
||||
1. 原理：服务端代码可能使用了 trim()
|
||||
函数或类似逻辑，在校验通过后去掉了空格，导致 " write"
|
||||
变成了 "write"
|
||||
通过了校验；或者数据库查询（如 WHERE role=' write'）在特定字符集下命中了记录。
|
||||
|
||||
1. **扩展测试**
|
||||
：尝试使用 Tab（\t
|
||||
）、换行符（\n
|
||||
）或其他不可见字符进行混淆。
|
||||
|
||||
**根因分析**
|
||||
|
||||
这是一个典型的**输入验证不完整**
|
||||
问题。开发人员在编写鉴权逻辑时，假设客户端传来的参数值是"干净"的。然而，HTTP 协议本身允许字符串中包含空格。当服务端仅做等值比较而未做规范化（Canonicalization）时，就会产生逻辑缝隙。
|
||||
- **校验层**
|
||||
：可能使用了严格匹配，但被空格欺骗。
|
||||
|
||||
- **执行层**
|
||||
：ORM 或后端逻辑可能自动进行了隐式转换或 trim，导致鉴权模块放行的请求，在执行模块拥有了高权限。
|
||||
|
||||
**危害**
|
||||
1. **权限提升**
|
||||
：这是最直接的危害。低权限用户（如 read
|
||||
）可以通过在请求值中加入空格，伪装成高权限用户（如 write
|
||||
），从而执行修改、删除等敏感操作。
|
||||
|
||||
1. **绕过安全规则**
|
||||
：防火墙（WAF）或后端 ACL（访问控制列表）通常基于精确的字符串匹配。添加空格可以绕过这些基于签名的防御机制。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,46 @@
|
||||
# 漏洞预警 | JumpServer Access Key越权泄露漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-09-17 00:00
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # QVD-2026-65008
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
Jumpserver 是一款使用 Python, Django 开发的开源跳板机系统, 为互联网企业提供了认证，授权，审计，自动化运维等功能，基于ssh协议来管理，客户端无需安装agent。
|
||||
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
****
|
||||
**QVD-2026-65008**
|
||||
|
||||
**漏洞类型：**
|
||||
Access Key越权泄露
|
||||
|
||||
**影响：权限提升**
|
||||
|
||||
**简述：**
|
||||
JumpServer存在Access Key越权泄露漏洞，由于其在通用API列表视图中使用的过滤后端会对整个查询集条件取反，而不仅仅是客户端提供的过滤表达式，导致已应用于查询集的授权或所有权约束也被一并反转；同时序列化器选择可被客户端查询参数影响，可能暴露列表响应中通常不包含的字段。攻击者可利用该漏洞，通过附加_rel=not查询参数越权读取所有用户的AccessKey Secret和TempToken明文，进而在开启AUTH_TEMP_TOKEN的环境中直接以管理员身份登录，完成权限接管。
|
||||
|
||||
**0x04 影响版本**
|
||||
- v3.7.0 <= JumpServer V3 < v3.10.23 LTS
|
||||
|
||||
- v4.0.0 <= JumpServer V4 < v4.10.19 LTS
|
||||
|
||||
**0x05****POC状态**
|
||||
- 已公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://www.jumpserver.org/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
# 漏洞预警 | cPanel&WHM SQL注入漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-09-17 00:00
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # CVE-2026-67401
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
cPanel&WHM是全球主流的LinuxWeb托管控制面板。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
**CVE-2026-67401**
|
||||
|
||||
**漏洞类型：**
|
||||
SQL注入
|
||||
|
||||
**影响：**
|
||||
获取敏感信息
|
||||
|
||||
**简述：**
|
||||
cPanel&WHM存在SQL注入漏洞，持有邮件相关权限的已认证cPanel账户可注入恶意SQL语句，在服务器上创建任意文件，该任意文件创建能力可进一步导致以root身份执行代码，攻击者最终获得服务器完全控制权。
|
||||
|
||||
**0x04 影响版本**
|
||||
- cPanel&WHM < v11.110.0.143
|
||||
|
||||
- cPanel&WHM < v11.134.0.55
|
||||
|
||||
- cPanel&WHM < v11.136.0.39
|
||||
|
||||
- cPanel&WHM < v11.138.0.4
|
||||
|
||||
- cPanel&WHM < WP2: v11.138.1.9
|
||||
|
||||
**0x05****POC状态**
|
||||
- 已公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://www.cpanel.net/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,173 @@
|
||||
# 白帽子的新战友：一个会自己找漏洞的 AI 智能体
|
||||
黑白之道 2026-09-17 00:35
|
||||
|
||||
# 蛙池ai智能体赋能漏洞挖掘
|
||||
|
||||
蛙池AI是一款自动化的渗透测试平台，为网络安全白帽漏洞挖掘提供了AI智能体赋能，能够提高白帽子挖掘漏洞的效率和出洞率。
|
||||
## 蛙池部署
|
||||
|
||||
官网下载地址：https://www.digpool.cn/
|
||||
|
||||
在官网界面下载对应系统版本的安装包即可一键安装
|
||||
|
||||
|
||||
|
||||
输入邀请码后即可进入UI界面
|
||||
|
||||
|
||||
|
||||
界面看起来比较方便，除了用来与模型对话进行漏洞挖掘的窗口还能看到有报告助手等，辅助白帽子的功能
|
||||
## 准备漏洞挖掘
|
||||
|
||||
安装了蛙池智能体，我们还可以为智能体准备一些提高挖洞能力的skills，我们在蛙伴中心能够看到很多skills
|
||||
|
||||
|
||||
### Skills
|
||||
|
||||
这里为了演示，选择性的下载一些skills，这里我选择一些用于挖掘未授权访问和信息泄露的skills，让ai在通过js寻找未授权接口时能够更快更准。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
我们除了使用蛙池ai上下载的skills，还能够添加一个属于自己的skills，将自己的知识库，自认为好用的skills都接入到蛙池中，除此之外甚至可以发布自己skills换取打赏
|
||||
|
||||
|
||||
### MCP工具
|
||||
|
||||
在蛙伴中心我们还可以下载和配置一些MCP工具，用来为自己的AI接入手脚，官方默认提供了几个基础的MCP工具：抓包蛙、问答蛙、浏览器工具、Pokemon。使用这些工具即可完成最基本的web页面漏洞挖掘。
|
||||
|
||||
|
||||
### 漏洞挖掘
|
||||
|
||||
蛙池提供了多种多样的AI漏洞挖掘方式：
|
||||
|
||||
对话式挖洞：我们可以通过简单的对话窗口来启动蛙池漏洞挖掘，并且通过提示词引导蛙池智能体挖掘漏洞。
|
||||
|
||||
|
||||
|
||||
在对话模式中可以看到一个用于和AI对话的对话框，以及数据包列表，生成的文件列表，在漏洞挖掘过程中，数据包会被记录在右侧的数据包窗口中，方便白帽子查看，所产生的报告文件也会出现在”文件“框中，方便白帽子查看AI挖掘所产生的文件。
|
||||
|
||||
|
||||
|
||||
第二种是半自动化挖掘，我们可以在该页面中看到漏洞盒子承接的SRC漏洞挖掘项目，
|
||||
|
||||
|
||||
|
||||
点击对应的项目或者创建一个作战室，即可直接进入对应的项目
|
||||
|
||||
|
||||
|
||||
作战室中可以看到左边有我们项目的详情，右侧有抓包功能点和与ai的对话功能点，该漏洞挖掘方式相比与对话式挖洞，需要白帽子亲自参与到漏洞挖局的过程中，和蛙池智能体并肩作战，这就是和AI所处的漏洞挖掘“作战室”，我们可以手动抓取数据包，交给ai去分析。
|
||||
## 打造属于自己的智能体
|
||||
|
||||
基于蛙池 AI 框架，我们可以构建专属的 AI 漏洞挖掘智能体，自定义接入适配的工具与技能集，把蛙池打造成一套高度贴合自身使用习惯的漏洞挖掘利器。
|
||||
### 配置好用的MCP 工具
|
||||
|
||||
在MCP工具页面点击右上角添加自己的MCP工具，即可添加MCP信息进行配置。
|
||||
|
||||
|
||||
|
||||
例如我这里添加tscan mcp作为工具,我们先用命令把Tscan的mcp模式启动起来：
|
||||
```
|
||||
TscanPlus_Win_Amd64.exe mcp serve -listen 127.0.0.1:8088
|
||||
```
|
||||
|
||||
在启动好MCP工具后，在连接配置填上对应的连接方式，地址等信息即可。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Ai会获取MCP中对应的工具列表，然后根据列表中的信息选择适合当前场景下的功能，例如我们利用tscan mcp收集目标资产或进行漏洞扫描。
|
||||
|
||||
|
||||
|
||||
接入tscan mcp后ai可以很方便的去做一些渗透测试的操作，只需要简单的调用即可：
|
||||
|
||||
|
||||
大大提高Ai能力
|
||||
|
||||
|
||||
使用一个好用的MCP工具可以明显提高漏洞挖掘的效率，各位也可以使用自己认为比较好的工具作为Ai的手脚
|
||||
### 配置漏洞挖掘的skills
|
||||
|
||||
skills可以理解成为给Ai的一本漏洞挖掘指南，将可以提供给ai的工具、脚本、提示词、模版等打包成可复用能力包，Ai会根据遇到的情况选择性的加载对应的技能。
|
||||
|
||||
标准的skills长这样：
|
||||
```
|
||||
vuln-scan-skill/ ├── SKILL.md # 核心指令文件├── scripts/ # 可选：一些脚本│ └── jsFinder.py ├── references/ # 可选：技能参考文档│ └── JS_vuln_search.md └── assets/ # 可选：模板与资源文件 └── report_template.md # 比如审查报告的输出模板
|
||||
```
|
||||
|
||||
当然你也可以按照自己的意愿来布局自己的skills
|
||||
|
||||
我们需要把对skills的介绍、名称都放入文档中，告诉Ai这是用来干嘛的skills。
|
||||
```
|
||||
name: vuln-scan-skillsdescription: 用于赋能智能体挖掘src漏洞的技能包，提供一些漏洞挖掘思路及常用脚本和报告模版
|
||||
```
|
||||
|
||||
同时可以把核心的指令都放到SKILL.md文件中，我们可以放入一些SRC漏洞挖掘时的一些常用提示词，这样就不用每次都输入进入。
|
||||
```
|
||||
## 安全边界（全局）- 禁止一切不可逆破坏性操作（删除数据、修改他人密码等）- 尝试获取高敏感数据时，需询问用户、- 禁止执行可能会导致服务器宕机的行为
|
||||
```
|
||||
|
||||
同时还要放入对技能参考文档的指引，让AI知道自己应该到哪里去寻找对应自己目前需求的指导文件
|
||||
```
|
||||
JS审计与漏洞发现：references/JS_vuln_search.md
|
||||
```
|
||||
|
||||
这里笔者只做简单的演示，具体的需要大家自己补充或者在网络上收集，网上已经有比较优秀的开源skills了。
|
||||
|
||||
同时为了不断提高智能体的能力，我们还可以在每次漏洞挖掘结束后，将报告、经验、教训都让ai总结，更新到skills，从而不断改进智能体能力
|
||||
## 挖掘漏洞
|
||||
|
||||
这里我选择了对话式挖掘漏洞，并且选择了专门挖掘敏感信息泄露的agent
|
||||
|
||||
|
||||
|
||||
作为演示，我们先接入Tscan MCP进行简单的信息收集：
|
||||
|
||||
|
||||
|
||||
随后我们把资产放入对话框，这里我建议每次每个对话框检测一个资产，因为我发现一下子把资产都丢给他，他会挖掘不全，简单测试几个接口没结果就会尝试转向下一个目标，因此我建议每次就输入一个目标，这样ai会专注于这一个目标，想方设法挖掘出漏洞。
|
||||
|
||||
然后别忘记加上一些限制提示词，虽然智能体可能默认自带限制ai行为的提示词，但是还是最好自己加上一些。
|
||||
```
|
||||
渗透测试时注意以下规定：禁止删除任何数据，禁止随意修改任何客户数据，如果要修改必须停下来询问我，禁止上传webshell等恶意脚本、程序，禁止大量下载客户敏感数据，禁止任何测试行为影响系统业务正常运行。
|
||||
```
|
||||
|
||||
|
||||
|
||||
然后我们看到对话框有一个模型选择功能，我们选择自己喜欢的模型，其中适配了国内比较热门的大模型，还可以自己添加模型。
|
||||
|
||||
|
||||
|
||||
在开始漏洞挖掘之前，我们要记得勾选上下载的skills
|
||||
|
||||
|
||||
|
||||
在完成配置之后，即可开始利用蛙池AI挖掘漏洞了。
|
||||
|
||||
|
||||
|
||||
在蛙池自动测试的过程中我们是可以在右侧看到蛙池测试时所产生的数据包的，能够实时观察蛙池漏洞挖掘的整个过程，点数据包还可以看到具体的请求包，可以及时调整ai测试方向。
|
||||
|
||||
|
||||
|
||||
有了Ai智能体辅助漏洞挖掘后，js文件的审计效率大幅度提高，轻松审计多个js文件并且能够准确找到泄露的敏感信息，暴露的接口等，能够有限扩大漏洞挖掘时的攻击面。
|
||||
|
||||
在挖掘过程中可能会遇到挖掘不够深入的情况，这时候我们就需要及时调整ai，让其更加深入的挖掘漏洞。
|
||||
|
||||
|
||||
|
||||
通常情况下，AI很难一轮就发现所有的风险点，这时候就需要我们告诉AI应当如何进行下一步测试，或者框定一个测试结束条件，让AI自动开启下一轮测试。
|
||||
## 成果
|
||||
|
||||
通过蛙池Ai的漏洞挖掘，成功按照我给蛙池ai挖掘未授权访问的预期，挖掘出大量未授权信息泄露接口
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
文章来源：YaYaLiou网安
|
||||
|
||||
@@ -0,0 +1,110 @@
|
||||
# 红队固件级漏洞挖掘工具包：moria + mithril 全离线、可空气隔离
|
||||
原创 Red Hunter
|
||||
Red Hunter 黑白之道 2026-09-17 00:35
|
||||
|
||||
地址
|
||||
> **导语**
|
||||
：安全研究员 Matt Brown（@nmatt0）本周放出两款 MIT 协议的开源 IoT 固件分析工具——moria 负责把固件拆成零件，mithril 负责从零件里挖出秘银。整套组合拳让你不用碰物理设备，就能完成固件级漏洞挖掘、SBOM 生成、密钥泄露检测、启动安全审计。命名致敬《魔戒》"摩瑞亚矿坑里的秘银"。
|
||||
|
||||
## 一、背景：IoT 固件分析的痛点
|
||||
|
||||
红队做 IoT 渗透的传统路线是：拿到目标设备 → 拆机 → 找调试口 → 抓固件 → 用 binwalk 拆包。这一步卡在"拿到设备"上——甲方不肯借、厂商不发样品、设备压根买不到都是常事。
|
||||
|
||||
moria 和 mithril 的价值就是把"拆机"前置到下载阶段。从厂商官网下载公开固件升级包，或从 OTA 服务器抓一个 .bin 文件，剩下的活就交给这两个工具搞定。作者 Matt Brown 把它们定位成"在你拿到设备之前，先把设备的内裤扒光"——糙理不糙。
|
||||
|
||||
|
||||
|
||||
作者用了《魔戒》命名：moria 是摩瑞亚矿坑，mithril 是矿坑里的秘银。moria 钻进固件二进制海洋，mithril 把藏在里面的秘银（漏洞、密钥、组件信息）挖出来。README 里直接写明："moria maps the bytes. mithril reads the contents."
|
||||
## 二、moria：固件"拆箱"利器
|
||||
|
||||
moria 是 C++20 写的命令行工具：在不 root、不装外部工具的前提下，对固件进行结构识别、嵌套解压、字节雕刻。
|
||||
|
||||
支持的文件系统覆盖 IoT 固件所有主流格式：SquashFS、ext2/3/4、F2FS、XFS、btrfs、HFS+、NTFS、EROFS、JFFS2、UBIFS 等十余种，还有 RAE Systems / Honeywell RFP 这种工业厂商专有的固件容器格式。归档覆盖 ZIP、tar、cpio、ISO 9660、Android sparse；启动包装层支持 U-Boot uImage、U-Boot FIT、gzip/xz/zstd/lz4 裸流。
|
||||
|
||||
几个贴实战场景的特性：**递归是默认行为**
|
||||
——gzip 包着的 SquashFS 再嵌进 UBI 卷，一路拆到底；**UPX 加壳识别**
|
||||
——检测 ELF/PE/Mach-O 是否被 UPX 压缩，连"为了对抗 upx -d 把头部清零"的反脱壳手段都能识别；**抗恶意输入**
|
||||
——所有读操作做边界检查，所有写操作走 openat + O_NOFOLLOW，解压做了压缩炸弹防护。
|
||||
|
||||
输出默认是给人看的层级树，加 -j
|
||||
切 JSON，方便脚本和大模型 agent 接管。这是 moria 跟 binwalk 最大的差异化——后者输出基本是给人看的，前者天然适配 AI 工作流。
|
||||
## 三、mithril：固件"读心"专家
|
||||
|
||||
mithril 是 moria 的语义层搭档：moria 拆完，mithril 接手做内容分析。同样 C++20 写，无第三方依赖。
|
||||
|
||||
能力按"维度"展开。**SBOM 生成**
|
||||
——除了 dpkg/opkg/apk/rpm 这种包管理器数据库，还能从 ELF 版本字符串、libc 文件名、内核 banner 里恢复组件信息。输出格式 CycloneDX 和 SPDX。
|
||||
|
||||
|
||||
|
||||
**CVE 匹配**
|
||||
——本地维护一份 OSV + NVD/CPE 镜像，加一份手工筛选的"高信号内核 CVE 清单"。匹配结果用 CISA KEV 和 EPSS 打标签。最关键的是：完全离线、可空气隔离，涉密环境也能跑。
|
||||
|
||||
**密钥泄露检测**
|
||||
是一大亮点。mithril 用"确定性离线阶梯"：先看模式（密钥形状），再验证结构（能解析成 JWT 或 PEM 私钥），最后做数学校验（GitHub token 的校验和、加密哈希）。它永远只说"看起来有效"，绝不去打活靶——只判断"如果攻击者拿到这条字符串，他能不能用"。
|
||||
|
||||
更狠的是**弱公钥与泄露公钥检测**
|
||||
：mithril 把固件里所有公钥拿来跟一份内置的"私钥已公开"语料库比对——rapid7 ssh-badkeys、Vagrant 不安全密钥全在；自动识别 ROCA 指纹（CVE-2017-15361）；用 Fermat 临近素数、batch-GCD 共享素数、Wiener 小私钥指数检测来找能直接分解 RSA 模数的漏洞。命中任一个，就拿到了伪造签名或绕过 SSH 鉴权的能力。
|
||||
|
||||
**启动安全审计**
|
||||
——--boot
|
||||
pass 读 U-Boot 环境变量、设备树、FIT/AVB/UEFI 验证启动配置；可直接拿一个裸的 AMI/EDK2 BIOS 文件做 UEFI Secure Boot 姿势分析。挖"启动链信任根"类漏洞时必跑。
|
||||
## 四、组合拳：从固件到漏洞清单
|
||||
|
||||
完整工作流就是两条命令加一次数据库初始化：
|
||||
```
|
||||
moria -e firmware.bin # 拆箱：识别 + 嵌套解压mithril --fetch-db # 首次：拉一份本地 CVE 镜像（仅此一次联网）mithril firmware.bin.extracted/ # 读心：密钥 + SBOM + CVE + 授权 + 启动 + 公钥
|
||||
```
|
||||
|
||||
加几个常用 flag 让结果更聚焦：--secrets
|
||||
（只看密钥）、--sbom -C out/
|
||||
（导出 SBOM）、--cve --component-cves-all
|
||||
（列全组件 CVE）、--keys
|
||||
（公钥弱性检测）、--boot
|
||||
（启动安全审计）。JSON 输出配合 -j
|
||||
可直接喂给脚本或 LLM agent。
|
||||
|
||||
构建也是干干净净：两条 cmake 命令搞定，零运行时依赖，单文件二进制，复制到 ~/.local/bin/
|
||||
就能用。MIT 协议，可商用、可改造、无 copyleft 污染。
|
||||
## 五、红队实战视角与适用场景
|
||||
|
||||
作为红队从业者，我看到这套工具最直接的三个用法。
|
||||
|
||||
**第一，供应商情报收集**
|
||||
。拿到目标厂商的产品列表，从每个型号的官方下载页抓最新固件，跑一遍 moria + mithril，就能拿到 SBOM 和 CVE 命中清单。这是写渗透测试报告"漏洞影响面分析"章节的金矿——很多时候甲方自己都不知道自家设备装着什么版本的 openssl。
|
||||
|
||||
**第二，0day 候选筛选**
|
||||
。mithril 的 SBOM + CVE 匹配自动标 CISA KEV 和高 EPSS，直接看到"这个组件已被野外利用过"的项。再叠加 --component-cves-all
|
||||
看全量，2024-2026 那些活跃利用的内核提权、busybox 命令注入、uClibc 越界读漏洞都能按组件版本号精准命中。
|
||||
|
||||
**第三，加密供应链弱点审计**
|
||||
。--keys
|
||||
pass 那一套 ROCA + 弱 RSA + 共享素数检测，是 2017-2018 年 Infineon TPM 漏洞之后极少数能持续用的离线检测能力。直接给客户演示就值回票价。
|
||||
|
||||
适用边界要说清楚：moria + mithril 是**静态分析**
|
||||
工具，面对加密固件就抓瞎——除非你能搞到解密后的 bootloader 镜像或调试固件。它们输出的是"候选漏洞清单"，不是"已验证漏洞"，最后一步还得红队手动写 PoC 或跑真实设备测试。
|
||||
|
||||
作者 Matt Brown 自己说："完全离线、可复现、可空气隔离。" 在涉密网络、隔离研发网、关键基础设施评估场景里，这一条比任何花哨功能都值钱。
|
||||
|
||||
|
||||
开源工具地址：
|
||||
|
||||
moria: https://github.com/nmatt0/moria
|
||||
|
||||
mithril: https://github.com/nmatt0/mithril
|
||||
|
||||
**版权声明**
|
||||
：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621549&idx=1&sn=21c4b072726d2387d562109ada6b9bbb&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621944&idx=1&sn=3cc6dc9876a20466d4ec3634deb80220&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650622065&idx=1&sn=09f8ae84c06d4331e71c277b177ae701&scene=21#wechat_redirect)
|
||||
> 👇 点击**阅读原文**
|
||||
，访问我的网站
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,194 @@
|
||||
# 让 AI 改了五遍，漏洞多了 37.6%：一份 AI 编码安全复查清单
|
||||
原创 奋斗的小浪
|
||||
奋斗的小浪 船山信安 2026-09-16 16:00
|
||||
|
||||
安全开发 · SECDEV
|
||||
|
||||
**本篇核心：**
|
||||
这篇文章我拖了很久才写。不是没得写，是不知道该怎么说才不像在唱衰。直到把这一年评审过的、有 AI 参与的代码重新翻了一遍，我才想清楚一件事——问题从来不在 AI 写得好不好，而在于它写完之后，我们看它的眼神变了。
|
||||
|
||||
01
|
||||
那个四十行的接口，写得比我工整
|
||||
|
||||
这类提交递到眼前的时候，人是很容易直接点头的。
|
||||
|
||||
四十来行，变量命名讲究，注释一句一句排着，异常捕获了，分页也考虑了，单元测试全绿。写它的人多半还会补一句：基本是 AI 生成的，自己就调了两个参数。说实话，它比我见过的大部分手写代码要体面。
|
||||
|
||||
但这类代码我见过的次数不算少了。它们的破绽往往出现在同一个位置。
|
||||
|
||||
问题出在接口的主体逻辑上。它先查了「请求的人是谁」——查得很规范，token 校验、过期判断、失效重登，一样不少。然后它拿着这个用户的身份，直接去数据库取数据了。中间没有任何一行问过：这条数据是这个人的吗。
|
||||
|
||||
前半句它想到了，后半句没有。
|
||||
|
||||
登录了，不等于你能看。这两件事在代码里差着一整个 **鉴权**
|
||||
层，而在人类的直觉里，它们常常被当成一件事。因为这个错觉，它在今年的 **OWASP Top 10 里排第一**
|
||||
——不是存文档里，是实战里被反复打穿。
|
||||
|
||||
**一句话：**
|
||||
AI 最大的本事是写出「很像那么回事」的代码。而安全检查恰恰是反直觉的——它关心的不是这段代码顺不顺眼，是它缺的那半句话。
|
||||
|
||||
02
|
||||
数字在这，不用形容词
|
||||
|
||||
这类故事讲多了容易被认为是挑刺。所以把数据摆出来。
|
||||
|
||||
安全厂商 Veracode 测了一百多个大模型在安全敏感编码任务上的表现，结果**45% 的 AI 生成代码至少命中一项 OWASP Top 10**
|
||||
。分语言看差距很吓人：Java 的失败率到了 72%，C# 45%，JavaScript 43%，Python 38%。其中 XSS 相关的不安全生成率 86%，日志注入 88%。
|
||||
|
||||
另一组常被引用的是**470 个开源 Pull Request**
|
||||
的对照分析：AI 生成代码的漏洞密度，是人写代码的 **2.74 倍**
|
||||
。
|
||||
|
||||
再往前，纽约大学团队那篇《Asleep at the Keyboard?》（IEEE S&P 2022）是这一行的老底子：对着 MITRE 的 CWE Top 25 设计 89 个场景，让 Copilot 生成 1689 个补全，**39.33% 的首选建议带洞**
|
||||
，把全部建议算进去是 40.73%。扎的是最朴素的几类：字符串拼接的 SQL、没做边界检查、随机数用得不安全。
|
||||
|
||||
到 2026 年 2 月，有人重做了类似实验——87 个相同 prompt 发给 6 个模型，522 份样本用 5 个 SAST 工具扫，每条结论人工验证，总漏洞率降到 **25.7%**
|
||||
。最好的模型 19.5%。
|
||||
|
||||
看出来了吗：**趋势在变好，但从来没有归零。**
|
||||
<table><thead><tr style="background:#fdf2f3;"><th style="border:1px solid #f6d9dc;padding:12px;text-align:left;font-weight:700;color:#1a1a1a;"><section><span leaf="">研究</span></section></th><th style="border:1px solid #f6d9dc;padding:12px;text-align:left;font-weight:700;color:#1a1a1a;"><section><span leaf="">样本</span></section></th><th style="border:1px solid #f6d9dc;padding:12px;text-align:left;font-weight:700;color:#1a1a1a;"><section><span leaf="">漏洞比例</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">NYU / IEEE S&P 2022</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">1689 个补全 / 89 场景</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;color:#c0152f;font-weight:700;"><section><span leaf="">39.3%（首选）</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">Veracode 2025</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">100+ 大模型</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;color:#c0152f;font-weight:700;"><section><span leaf="">45%（OWASP Top 10）</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">470 个 PR 对照分析</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">AI 代码 vs 人写代码</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;color:#c0152f;font-weight:700;"><section><span leaf="">密度 2.74 倍</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">多模型复测 2026-02</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">522 样本 / 6 模型</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;color:#c0152f;font-weight:700;"><section><span leaf="">25.7%</span></section></td></tr></tbody></table>
|
||||
表 ｜ AI 生成代码漏洞率的主流测量（来源见文末）
|
||||
|
||||
03
|
||||
真正危险的一半，还没说
|
||||
|
||||
上面这些数字，都还不是最麻烦的。
|
||||
|
||||
斯坦福那项由密码学家 Dan Boneh 参与的对照实验，一共找了 47 名开发者。用 AI 助手的那一组，写出来的代码**确实更不安全**
|
||||
——这没什么意外。
|
||||
|
||||
意外的是后半段：这一组人，同时还**更倾向于认为自己的代码是安全的**
|
||||
。
|
||||
|
||||
我把这句话读了两遍。它不是说 AI 让人变笨了，而是说 AI 让人**变更敢了**
|
||||
。
|
||||
|
||||
为什么会这样？因为 AI 的输出有一种非常强的「完成感」。命名规整、注释齐全、格式漂亮，读起来像成品。而人类写代码的草稿阶段，往往是丑的——变量乱起、函数名带 test2、中间还留着几个 print。那种丑陋其实是个提醒：这段代码还没完工。
|
||||
|
||||
AI 把这个提醒抹掉了。
|
||||
|
||||
**注意：**
|
||||
知道自己写的是危险代码的团队，会用加倍的代码评审去补偿；觉得自己写得挺好团队，什么都不会加。**confidently wrong，比 unsafe 更贵。**
|
||||
|
||||
04
|
||||
别让它给自己当医生
|
||||
|
||||
发现 AI 写的代码有安全问题，最自然的操作是什么？把报错贴回去，说「这里不安全，改一下」。
|
||||
|
||||
这个动作看起来天经地义，但有人专门做了实验。
|
||||
|
||||
2025 年一项研究（发表于 IEEE-ISTAS 2025）拿 400 份代码样本，用 GPT-4o 反复迭代改进，跑了 40 轮。结论是：**迭代五轮之后，严重漏洞的数量上升了 37.6%。**
|
||||
|
||||
不是修不好，是修着修着又添新的。
|
||||
|
||||
原因其实很好理解。模型每次改的是一个局部函数，它优化的目标是「让眼前这段看起来没问题」，而不是「让整个调用链安全」。你让它补一个输入校验，它可能顺手把错误信息打得更详细了一点；你让它修复 SQL 拼接，它可能换了套 ORM 但把查询权限放大了一圈。每一轮单看都更专业，叠起来却在往副作用走。
|
||||
|
||||
企业侧的统计也印证了这种「没人看全局」的代价。对 Fortune 50 企业内部 AI 生成代码的抽样分析发现：**权限提升路径多了 322%，设计缺陷多了 153%，密钥暴露增加了 40%。**
|
||||
|
||||
还有一组更生活化的数字：有人扫了大约 5600 个「纯 vibe coding」做出来的应用，找出 2000 多个漏洞和 400 多个**明文暴露的密钥**
|
||||
。密钥不是被攻破的，是写死然后被提交的。
|
||||
|
||||
所以这条我要说得直白一点：**让 AI 审 AI，等于让一个人给自己批改卷子。**
|
||||
它可以当助手查一遍，但不能当终审。
|
||||
|
||||
05
|
||||
它在让你下载不存在的东西
|
||||
|
||||
这一节可能是全文最值得你记住的。
|
||||
|
||||
USENIX Security 2025 上有一项很扎实的研究：研究者让 16 个不同的模型生成了 **57.6 万份**
|
||||
代码样本，然后去核对它们推荐的第三方包名称是否真实存在。
|
||||
|
||||
结果是 **19.7% 的包名压根不存在**
|
||||
——累计超过 20.5 万个不存在的包名字。开源模型幻觉率 21.7%，商业模型 5.2%。
|
||||
|
||||
到这一步还只是「跑不通」的麻烦。真正让它变成安全问题的，是下一个发现：研究者把这些 prompt 重复跑了十次，**43% 的幻觉包名，十次里次次出现。**
|
||||
|
||||
可预测，就意味着可以被提前占位。
|
||||
|
||||
攻击者不需要攻破模型，不需要攻破你的机器，只需要把那些模型大概率会「想起来」的包名，提前去 npm 或 PyPI 上注册一遍，里面放点东西。下一个把这些 pip install 命令原样复制进终端的开发者，就成了那个执行者。这个手法现在有个名字，叫 **slopsquatting**
|
||||
（垃圾抢注）。
|
||||
|
||||
2026 年的复测里，新一代模型的幻觉率降到了 4.6%–6.1%。降得很好，但没到零，而在 CI 每天成千上万次的安装建议里，这个值依然足够撑起一次成功的投毒。
|
||||
|
||||
**要点：**
|
||||
模型记不住的包名，和模型写不出的鉴权判断，是同一件事的两面——**它在补全「常见的样子」，而不是在验证「真实的存在」。**
|
||||
|
||||
06
|
||||
能今天就用的复查清单
|
||||
|
||||
说完了问题，给点能落地的。下面这些不依赖任何付费工具，今天下午就能开始做。
|
||||
|
||||
**三个必问**
|
||||
（合并 AI 生成代码之前，问完这三个问题再点按钮）
|
||||
|
||||
1
|
||||
它验证了谁要看，还是验证了能不能看？（认证不等于授权）
|
||||
|
||||
2
|
||||
新引入的包，真的存在吗？去 npm / PyPI 看一眼发布时间和维护者。
|
||||
|
||||
3
|
||||
失败的时候，它往哪里走？很多AI写的代码，错误处理是「打印堆栈然后继续」。
|
||||
|
||||
**四个必看**
|
||||
（评审时优先翻这四个位置，其余可以后看）
|
||||
<table><thead><tr style="background:#fdf2f3;"><th style="border:1px solid #f6d9dc;padding:12px;text-align:left;font-weight:700;color:#1a1a1a;"><section><span leaf="">位置</span></section></th><th style="border:1px solid #f6d9dc;padding:12px;text-align:left;font-weight:700;color:#1a1a1a;"><section><span leaf="">AI 最常在这里漏什么</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">接口入口</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">校验了登录态，没校验资源归属（越权）</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">配置文件</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">默认密码、全开端口、调试开关忘了关</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">依赖清单</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">包名拼错或根本不存在，可被抢注</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">异常分支</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">catch 里吞掉异常继续执行，或把堆栈返回给前端</span></section></td></tr></tbody></table>
|
||||
**两道机器关卡**
|
||||
（拦住绝大多数问题，且不会拖慢团队）
|
||||
|
||||
**第一道，放在 IDE 里。**
|
||||
用安全插件在本地编辑器里做提示，让开发者写代码那一刻就看到——而不是等到流水线报错。这是降低抵触感最有效的做法，因为它不打断任何人，也不需要任何人等。
|
||||
|
||||
**第二道，放在 CI 里，但要分等级。**
|
||||
这是大多数 SDL 落地失败的关键点：不是扫描不好，是一上来所有问题都阻断发布。
|
||||
|
||||
可行的分法是三层：
|
||||
<table><thead><tr style="background:#fdf2f3;"><th style="border:1px solid #f6d9dc;padding:12px;text-align:left;font-weight:700;color:#1a1a1a;"><section><span leaf="">等级</span></section></th><th style="border:1px solid #f6d9dc;padding:12px;text-align:left;font-weight:700;color:#1a1a1a;"><section><span leaf="">处置</span></section></th></tr></thead><tbody><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">暴露面的严重漏洞 / 密钥泄露</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;color:#c0152f;font-weight:700;"><section><span leaf="">直接阻断，不过 CI</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">高风险</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">要求有修复计划 + 负责人 + 期限</span></section></td></tr><tr><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">中低风险</span></section></td><td style="border:1px solid #e8e8e8;padding:12px;"><section><span leaf="">进 backlog，不拦人</span></section></td></tr></tbody></table>
|
||||
配套还要有一条：误报要能快速申诉。**安全负责人半小时内响应，确认无误报就进全局白名单。**
|
||||
少了这条通道，开发者会先学会关通知，然后学会跳过扫描——那时你有再好的门禁也没用了。
|
||||
|
||||
最后补一句容易忽略的：**优先覆盖核心资产就好。**
|
||||
不可能每个仓库都做全，先分清哪些系统值得上强制门禁，其余走自动化加事后兜底。贪全会让整套流程死在第一个季度。
|
||||
|
||||
07
|
||||
它可以写第一稿，但不能替你签字
|
||||
|
||||
写到最后，我其实一点都不反对用 AI 写代码。
|
||||
|
||||
我自己每天都在用。它把那些重复、琐碎、容易手滑的活干得又快又好，让我能把精力留给真正要想清楚的地方。这没什么可纠结的。
|
||||
|
||||
我想说的是另一件事：以前我们写一段粗糙的草稿，心里是清楚的——这是草稿。现在 AI 递过来一份「像成品」的东西，我们心里的那个刻度悄悄挪了位。
|
||||
|
||||
技术一直在变，工具一直在变，但有些东西一直没变：**最终为这段代码负责的，是那个按下合并按钮的人。**
|
||||
|
||||
AI 最大的风险不是写出漏洞，
|
||||
|
||||
是它把代码打磨得太体面，
|
||||
|
||||
体面到我们忘了多看一眼。
|
||||
|
||||
所以这篇不劝你少用 AI，只劝你一件事：**把 AI 的输出当成第一稿，而不是待合并的 diff。**
|
||||
|
||||
签字之前，那三十秒的手工复核，是你唯一不能外包给它的东西。
|
||||
|
||||
**参考来源**
|
||||
|
||||
· Pearce et al.《Asleep at the Keyboard?》，IEEE S&P 2022（arXiv:2108.09293，Copilot × CWE Top 25）
|
||||
|
||||
· Perry, Srivastava, Kumar, Boneh《Do Users Write More Insecure Code with AI Assistants?》，斯坦福大学
|
||||
|
||||
· Veracode《GenAI Code Security Report》，100+ 大模型安全编码评测
|
||||
|
||||
· Spracklen et al.，USENIX Security 2025（576,000 样本 / 16 模型包名幻觉）
|
||||
|
||||
· 《We Have a Package for You! A Comprehensive Analysis of Package Hallucinations》，发表于 IEEE-ISTAS 2025
|
||||
|
||||
· Pearce et al.，arXiv:2310.02059（真实 GitHub 仓库 Copilot 片段 CWE 分布）
|
||||
|
||||
· OWASP Top 10 2026（第八版）：A01 失效的访问控制、A02 安全配置错误、A03 软件供应链失效
|
||||
|
||||
· 多模型 AI 代码安全复测，2026 年 2 月（87 prompts × 6 模型 / 5 款 SAST 交叉验证）
|
||||
|
||||
· 安全开发 · AI 编码 · 代码评审 · DevSecOps ·
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
# 还在等什么？黑盒漏洞挖掘agent等你来收货
|
||||
原创 One
|
||||
One One security 2026-09-16 14:26
|
||||
|
||||
前面发行了一版黑盒漏洞挖掘agent，在长时间使用下来也是收获多多，全程都是用的deepseek-v4-flash性价比模型，产出也是在意料之外，话不多说看结果吧
|
||||
|
||||
某项目任意文件读取
|
||||
|
||||
|
||||
|
||||
某项目ak、sk泄露接管存储桶
|
||||
|
||||
|
||||
|
||||
某项目ssrf深入利用
|
||||
|
||||
|
||||
|
||||
某项目大规模信息泄露
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
某项目rce
|
||||
|
||||
|
||||
|
||||
|
||||
某项目其他漏洞
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
某src漏洞
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
需要的师傅可以加微联系
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user