mirror of
https://github.com/gelusus/wxvl.git
synced 2025-08-13 11:28:20 +00:00
利用空字节写入攻击Synology DiskStation在 DS1823xs+ NAS 上以 root 身份实现代码执行、可蠕虫化AirPlay漏洞：公共WiFi环境下可零点击远程控制苹果设备、Craft CMS generate-transform接口存在远程命令执行漏洞CVE-2025-32432 附POC、CVE-2017-9769 RZPNK.sys漏洞复现、【AI风险通告】vLLM存在远程代码执行漏洞（CVE-2025-32444）、
This commit is contained in:
test
parent
4ab4ef265b
commit
1e98e05e90
@ -13660,5 +13660,10 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxMjg3NzU0Mg==&mid=2247485528&idx=1&sn=be29d63f30cca17dc28989aedb0ef043": "支付漏洞实战",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI0NzE4ODk1Mw==&mid=2652096211&idx=2&sn=439ab06d63daa827f1cb7e56be548b51": "Windows 部署服务中发现新漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3OTUxNTU2NQ==&mid=2247490830&idx=1&sn=77539c110a925cecffdceeaaf4bccf96": "基于 LNK 快捷方式获取Windows NTLM的 漏洞（无需运行，已复现！）",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzk0MzY3MDE5Mg==&mid=2247484222&idx=1&sn=513666d7126d02a4b8bdeb0e966ddf3c": "基于 LNK 快捷方式获取Windows NTLM的 漏洞（无需运行，已复现！）"
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzk0MzY3MDE5Mg==&mid=2247484222&idx=1&sn=513666d7126d02a4b8bdeb0e966ddf3c": "基于 LNK 快捷方式获取Windows NTLM的 漏洞（无需运行，已复现！）",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjYyMzkwOA==&mid=2247529549&idx=1&sn=f36a6eef31d4ae6c387ae63ffaf720b6": "利用空字节写入攻击Synology DiskStation在 DS1823xs+ NAS 上以 root 身份实现代码执行",
|
||||
"https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651320142&idx=4&sn=ed93c0ee495ef976ddc919bd65eef508": "可蠕虫化AirPlay漏洞：公共WiFi环境下可零点击远程控制苹果设备",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIxMjEzMDkyMA==&mid=2247488445&idx=1&sn=e9e238c8521aec39f247c6cfbfaf041f": "Craft CMS generate-transform接口存在远程命令执行漏洞CVE-2025-32432 附POC",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzNTA0NzgyMA==&mid=2247484263&idx=1&sn=0a6168400765119305f334a310f02c78": "CVE-2017-9769 RZPNK.sys漏洞复现",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzUzOTE2OTM5Mg==&mid=2247490382&idx=1&sn=d16811990ed28de75af79d72d819dae7": "【AI风险通告】vLLM存在远程代码执行漏洞（CVE-2025-32444）"
|
||||
}
|
||||
5
doc/2025-05/CVE-2017-9769 RZPNK.sys漏洞复现.md
Normal file
5
doc/2025-05/CVE-2017-9769 RZPNK.sys漏洞复现.md
Normal file
@ -0,0 +1,5 @@
|
||||
# CVE-2017-9769 RZPNK.sys漏洞复现
|
||||
12138 我吃你家米了 2025-05-06 10:40
|
||||
|
||||
点击阅读原文 卡的话就挂代理
|
||||
|
||||
@ -0,0 +1,69 @@
|
||||
# Craft CMS generate-transform接口存在远程命令执行漏洞CVE-2025-32432 附POC
|
||||
2025-5-6更新 南风漏洞复现文库 2025-05-06 15:30
|
||||
|
||||
|
||||
|
||||
免责声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失，均由使用者本人负责，所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用。
|
||||
## 1. Craft CMS 简介
|
||||
|
||||
微信公众号搜索：南风漏洞复现文库
|
||||
该文章 南风漏洞复现文库 公众号首发
|
||||
|
||||
Craft CMS
|
||||
## 2.漏洞描述
|
||||
|
||||
Craft CMS 是一个灵活、用户友好的内容管理系统，用于创建自定义的数字网络体验和其他体验。CVE-2025-32432 中，攻击者可构造恶意请求利用generate-transform端点触发反序列化，执行任意代码，控制服务器。官方已发布安全更新，建议升级至最新版本。
|
||||
|
||||
CVE编号:CVE-2025-32432
|
||||
|
||||
CNNVD编号:
|
||||
|
||||
CNVD编号:
|
||||
## 3.影响版本
|
||||
|
||||
3.0.0-RC1 <= Craft <= 3.9.15 4.0.0-RC1 <= Craft <= 4.14.15 5.0.0-RC1 <= Craft <= 5.6.17
|
||||
|
||||
|
||||
Craft CMS generate-transform接口存在远程命令执行漏洞
|
||||
## 4.fofa查询语句
|
||||
|
||||
header="X-Powered-By: Craft CMS"|| banner="X-Powered-By: Craft CMS"
|
||||
## 5.漏洞复现
|
||||
|
||||
漏洞链接：https://xx.xx.xx.xxx/index.php?p=admin/actions/assets/generate-transform
|
||||
|
||||
|
||||
|
||||
|
||||
## 6.POC&EXP
|
||||
|
||||
本期漏洞及往期漏洞的批量扫描POC及POC工具箱已经上传知识星球：南风网络安全
|
||||
1: 更新poc批量扫描软件，承诺，一周更新8-14个插件吧，我会优先写使用量比较大程序漏洞。
|
||||
2: 免登录，免费fofa查询。
|
||||
3: 更新其他实用网络安全工具项目。
|
||||
4: 免费指纹识别，持续更新指纹库。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 7.整改意见
|
||||
|
||||
官方已发布安全更新，建议升级至最新版本
|
||||
## 8.往期回顾
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
96
doc/2025-05/【AI风险通告】vLLM存在远程代码执行漏洞（CVE-2025-32444）.md
Normal file
96
doc/2025-05/【AI风险通告】vLLM存在远程代码执行漏洞（CVE-2025-32444）.md
Normal file
File diff suppressed because one or more lines are too long
@ -0,0 +1,312 @@
|
||||
# 利用空字节写入攻击Synology DiskStation在 DS1823xs+ NAS 上以 root 身份实现代码执行
|
||||
Ots安全 2025-05-06 12:31
|
||||
|
||||
|
||||
|
||||
10月，我们参加了2024年Pwn2Own爱尔兰站，并成功利用Synology DiskStation DS1823xs+以root身份远程执行代码。此漏洞已修复，编号为CVE-2024-10442。
|
||||
|
||||
DiskStation 是 Synology 旗下广受欢迎的 NAS（网络附加存储）产品线。它曾在过去的 Pwn2Own 大赛中被成功利用过几次，但在前一年的大赛（2023 年多伦多 Pwn2Own 大赛）中却毫发无损。之后，在 2024 年爱尔兰大赛中，又有三台 DiskStation 成功参赛，它们都使用了独特的漏洞。
|
||||
|
||||
这篇文章将详细介绍我们研究 Synology DiskStation 以及为该事件编写漏洞利用程序的经验。
|
||||
|
||||
|
||||
|
||||
准备在 Pwn2Own Ireland 2024 上利用 Synology DiskStation 漏洞
|
||||
|
||||
查看 Synology 套件
|
||||
|
||||
如上所述，过去一两年的 Pwn2Own 大赛中，没有出现任何与 Synology DiskStation 竞争的案例。2024 年，ZDI 选择将一些非默认但由 Synology 编写的第一方软件包纳入比赛范围：
|
||||
|
||||
对于 Synology DiskStation 目标，将安装以下软件包并纳入竞赛范围：
|
||||
- MailPlus
|
||||
|
||||
- Drive
|
||||
|
||||
- Virtual Machine Manager
|
||||
|
||||
- Snapshot Replication
|
||||
|
||||
- Surveillance Station
|
||||
|
||||
- Photos
|
||||
|
||||
“
|
||||
Packages”是可选的附加应用程序/服务（等），可以通过 DiskStation 管理器中的 Synology 套件中心轻松安装在设备上。
|
||||
|
||||
对我们来说，这意味着更多的攻击面，而且由于这些软件包是第一年纳入范围的，我们认为这是一个很好的机会来发现一些相对较浅的漏洞，因为这些软件包可能还没有经过太多的安全审查。事实证明，这完全是事实。
|
||||
|
||||
我们查看的第一个软件包是虚拟机管理器，它是直接从物理 DiskStation 上的内置软件包中心安装的。
|
||||
|
||||
|
||||
|
||||
然后，我们可以通过测试设备上的 SSH shell 枚举所有新的网络监听器netstat。这揭示了一些仅在本地主机上运行的服务，除了一个绑定到所有接口的服务，运行以下命令（以 root 身份）：
|
||||
|
||||
```
|
||||
/var/packages/ReplicationService/target/sbin/synobtrfsreplicad --port 5566
|
||||
```
|
||||
|
||||
|
||||
这个监听器实际上是复制服务的一部分，而复制服务是一个独立的包，依赖虚拟机管理器（同时也依赖快照复制）。由于该服务拥有较高的权限级别，并且易于通信，我们对此很感兴趣。
|
||||
|
||||
|
||||
|
||||
下一步是检查二进制文件。由于我们已经在真实设备上安装了该服务，因此我们能够通过 SSH 提取文件。
|
||||
|
||||
或者，您也可以直接从 Synology 下载 DSM（核心操作系统）和软件包。然后可以使用提取工具解析自定义 Synology 存档，并提取软件包、固件映像或更新的内容。请注意，此特定工具是针对原生第一方 Synology 共享库的 FFI 包装器，可以从真实设备中拉取，也可以使用单独的工具从 DSM 存档中提取。
|
||||
|
||||
查找 Bug
|
||||
|
||||
有了相关的二进制文件，我们就可以开始查看监听端口 5566 的 TCP 服务的代码。主二进制文件synobtrfsreplicad只是一个驱动程序垫片，用于调用中的功能libsynobtrfsreplicacore.so.7，从而启动 TCP 监听器。
|
||||
|
||||
该服务是一个基于 Linux 的极简派生服务器，主进程不断调用accept()并派生出一个子进程来处理每个新的远程客户端。反过来，子进程会运行一个基本的命令循环来解析发送到该服务的传入消息。
|
||||
|
||||
每个命令都有一个简单的二进制格式，带有一个操作码（可选），后面跟着一个大小可变的数据有效载荷：
|
||||
|
||||
```
|
||||
unsigned cmd // command opcodeunsigned seq // sequence numberunsigned lenchar data[len]
|
||||
```
|
||||
|
||||
|
||||
为了方便解析这些命令消息，定义了两个全局变量。一个用于命令本身，另一个是一个环形缓冲区结构，用于保存最多 3 个大小可变的命令有效载荷。
|
||||
|
||||
```
|
||||
struct{ unsigned char sector; // ring buffer index char bufs[3][65536]; // ring buffer of 3 payloads unsigned buf_lens[3]; // populated lengths of 3 payloads} g_recvbuf;struct{ ReplicaCmdHeader header; // opcode, seq, len char *data; // will point into one of the 3 g_recvbuf bufs} g_cmd;
|
||||
```
|
||||
|
||||
读取消息的命令循环如下所示：
|
||||
|
||||
```
|
||||
voidrunCmdLoop(){ while(1) { g_cmd.data = g_recvbuf.bufs[g_recvbuf.sector]; int err = recvCmd(&g_cmd); if (err) bail; g_cmd.data[g_cmd.header.len] = 0; // ... handle cmd ... }}// function to read both the header and payload of a messageintrecvCmd(ReplicaCmd* cmd){ int err = raw_tcp_recv(cmd->header, 12); if (err) return err; if (cmd->header.len > 0x10000) return err; // read actual payload data err = raw_tcp_recv(cmd->data, cmd->header.len); // ...}
|
||||
```
|
||||
|
||||
如果攻击者提供的长度过大，recvCmd则跳过不读取任何有效载荷的环节。然而，它的返回值为零，表示没有错误，考虑到标头长度无效，这有点奇怪……回到调用方，它并不知道有任何错误，一切正常进行，命令有效载荷以空值终止，并使用任意大的标头长度。
|
||||
|
||||
这个漏洞很简单，对于我们最初的 POC，我们可以使用 netcat 以经典的可破解方式发送仅由 A（至少 12 个）组成的消息：
|
||||
|
||||
|
||||
|
||||
除非您使用 gdb 连接到该服务，否则设备上没有任何迹象表明出现了任何问题。该故障似乎没有记录到 syslog 或任何其他 DSM 日志记录工具中，而且由于分叉服务器的特性，它不会立即导致功能丧失。
|
||||
|
||||
此漏洞提供的原语允许我们将空字节重复写入共享库 BSS（数据段）的任意偏移量。非常类似 CTF 题。虽然漏洞本身相当简单，但利用起来却更加有趣。
|
||||
|
||||
无论如何，由于所有缓解措施都已启用，我们首先必须以某种方式将其转变为信息泄露。
|
||||
|
||||
分叉服务器
|
||||
|
||||
在继续之前，请记住，我们正在处理一个 fork 服务器，这对于破坏 ASLR 非常有用。每个 fork 出来的子进程都将拥有与父进程完全相同的地址空间，因此即使它们崩溃也不会造成任何后果：我们只需重新连接到该服务，即可获得一个新的子进程，重新开始。这有点像时间循环，每次连接都是一个以累积方式收集有关地址空间新信息的机会。
|
||||
|
||||
从高层次来看，每次迭代都具有以下结构：
|
||||
1. 猜一些事情（例如地址）
|
||||
|
||||
1. 让二进制文件使用猜测的值，这样它的行为就会有所不同，无论它是否正确（例如，错误的地址将崩溃）
|
||||
|
||||
1. 观察二进制的行为以确定值是否正确
|
||||
|
||||
1. 如果正确，则我们找到了正确的值。否则，重复下一个猜测
|
||||
|
||||
接下来，我们将看到如何将其应用于这个特定的二进制文件。
|
||||
|
||||
功能概述
|
||||
|
||||
由于所讨论的错误发生在输入解析期间，我们尚未探索该程序的大部分功能，稍后我们需要利用这些功能来构建漏洞。
|
||||
|
||||
从网络读取命令后，命令循环会对提供的操作码进行 switch-case 处理。需要输入的操作码会从可变长度的命令有效负载中解析出来。我们查看了所有可用的操作码，以大致了解它们的功能：
|
||||
- CMD_DSM_VER：无输入
|
||||
|
||||
- 返回 DSM 版本号
|
||||
|
||||
- CMD_SSL：初始化 SSL 连接
|
||||
|
||||
- CMD_TEST_CONNECT
|
||||
|
||||
- CMD_NOP
|
||||
|
||||
- CMD_VERSION：输入整数
|
||||
|
||||
- 设置连接的“版本”以适应兼容性差异
|
||||
|
||||
- CMD_TOKEN：输入字符串“token” ，它必须作为键存在于磁盘上的 JSON 文件中
|
||||
|
||||
- 执行初始化并设置全局std::string g_token
|
||||
|
||||
- CMD_NAME：输入字符串“name”
|
||||
|
||||
- 可以执行与 btrfs 相关的操作，和/或用于g_token修改 JSON 文件
|
||||
|
||||
- CMD_SEND：输入原始数据
|
||||
|
||||
- 代理输入到文件描述符，似乎在其他地方设置为btrfs命令的管道
|
||||
|
||||
- CMD_UPDATE
|
||||
|
||||
- CMD_STOP：输入标记字符串
|
||||
|
||||
- 从 JSON 中删除令牌
|
||||
|
||||
- CMD_COUNT
|
||||
|
||||
- CMD_CLR_BKP
|
||||
|
||||
- CMD_SYNCSIZE
|
||||
|
||||
- CMD_END
|
||||
|
||||
很快我们就发现，许多代码路径都依赖于提供有效的“token”，而这个“token”应该已经存在于一个 JSON 文件中/usr/syno/etc/synobtrfsreplica/btrfs_snap_replica_recv_token。JSON 被用作属性的简单键值存储，其中 token 就是键：
|
||||
|
||||
```
|
||||
{ "<token>": {"<attribute>":value, ... other attributes ...}, ... other tokens ...}
|
||||
```
|
||||
|
||||
|
||||
据推测，一些外部服务分发了这些令牌并写入文件，但我们不清楚这是在哪里发生的。
|
||||
|
||||
但是，有一条代码路径允许以非预期的方式向 JSON 文件添加标记。该CMD_NAME操作码使用当前的g_token，并将属性写入文件，但有两个重要的细微差别：
|
||||
- 它不检查是否g_token曾经初始化（即使用CMD_TOKEN）
|
||||
|
||||
- 如果令牌尚未作为 JSON 对象中的键存在，则设置属性将其添加
|
||||
|
||||
通常情况下，未初始化的g_token只是一个空字符串，但由于内存损坏，所有的猜测都将被取消，我们将在稍后看到这如何证明是有用的。
|
||||
|
||||
ASLR Oracle #1：释放伪堆块
|
||||
|
||||
我们的原语是写入空字节，即向命令有效载荷缓冲区中提供任意偏移量。该偏移量是无符号的，因此我们只能将空值写入有效载荷缓冲区后面的内存。
|
||||
|
||||
这就带来了一个问题：有效载荷缓冲区之后是什么？有效载荷缓冲区是共享库 BSS 中全局变量中三个 0x10000 大小的缓冲区之一。除了少数几个具有以下结构的实例外，g_recvbuf全局变量并不多：std::string
|
||||
|
||||
```
|
||||
structstd::string { char* ptr; // for short strings, points into inline_buffer unsignedlong length; char inline_buffer[16];}
|
||||
```
|
||||
|
||||
|
||||
默认构造函数将长度设置为 0，并指向char*内联缓冲区。换句话说，我们将std::string在 BSS 中拥有一堆实例，其指针指向它们自己的 BSS 地址，加上偏移量 16。
|
||||
|
||||
现在，考虑一下如果我们使用空写入将其中一个指针的最低两个字节清零。它前面的有效载荷缓冲区大小为 0x10000 字节，这个大小足以保证部分为空的 BSS 指针指向该缓冲区内的某个位置，尽管我们不知道确切的偏移量。
|
||||
|
||||
|
||||
|
||||
由于 ASLR 具有页面粒度（12 位），因此该偏移量中会有 4 位（一个半字节）的熵（即它可以是 0、0x1000、0x2000、... 0xf000）。
|
||||
|
||||
我们可以破坏的全局字符串之一是_gSnapRecvPath，它可以被重新分配为命令执行的操作之一CMD_NAME。
|
||||
|
||||
重新赋值时std::string，如果char*未指向内联缓冲区，delete则会在赋值新值之前对旧值（现已损坏）调用 。 这让我们可以 free 在有效载荷缓冲区中调用一个伪块。我们自然可以使用命令有效载荷来控制此缓冲区的内容。
|
||||
|
||||
当free被调用时，如果伪造的块足够小，它将被放入 glibc tcache 中。相反，如果大小无效（例如零），free则会调用abort，导致进程崩溃。这将创建我们的第一个 oracle，我们可以将它与 forking-server 的行为结合起来，以确定伪造的块位于 16 个可能的偏移量（0、0x1000、…、0xf000）中的哪一个。
|
||||
|
||||
对于 16 个可能的偏移量中的每一个：
|
||||
1. 将有效载荷缓冲区填充到猜测的偏移量，然后是假块的元数据（这只是一个假的大小值）
|
||||
|
||||
1. 触发漏洞两次，将char*for的两个低字节清零_gSnapRecvPath
|
||||
|
||||
1. 用于CMD_NAME释放损坏的char*，它可能指向也可能不指向放置在猜测偏移量的假块
|
||||
|
||||
- 如果套接字保持连接并且发送了响应，则猜测的偏移量是正确的
|
||||
|
||||
- 如果套接字已关闭（即被abort调用），则猜测不正确；请使用下一个偏移量重试
|
||||
|
||||
现在，我们已经解决了 ASLR 熵的一小部分，并且可以可靠地释放有效载荷缓冲区中的假块，该假块将被放入 tcache 中。
|
||||
|
||||
ASLR 预言机 #2：泄露令牌
|
||||
|
||||
tcache 是一个由空闲块组成的单链表，每个空闲块都有一个 next 指针。由于 glibc 中的一些强化措施，next 指针的填充方式如下：
|
||||
|
||||
```
|
||||
chunk->next = (&chunk->next>> 12) ^ next
|
||||
```
|
||||
|
||||
|
||||
在我们的例子中，tcache 列表之前为空（next = 0），因此写入的值将是&chunk->next >> 12。换句话说，我们将一个移位后的 BSS 指针放入了有效载荷缓冲区。现在我们需要找到某种方法来泄露这个值。
|
||||
|
||||
一旦伪造的块被释放，并且移位后的 BSS 指针被写入，我们就会将char*第二个全局变量的低 2 个字节置空std::string。g_token这种破坏会导致g_token指向与 完全相同的位置_gSnapRecvPath，也就是移位后的 BSS 指针。
|
||||
|
||||
回想一下我们之前讨论的功能CMD_NAME，它可以将一个未初始化的值添加g_token到磁盘上的 JSON 文件中。这正是这个功能非常有用的地方，因为它不再g_token指向空字符串，而是指向移位后的 BSS 指针。触发此代码路径后，JSON 文件现在包含了我们想要泄漏的值。
|
||||
|
||||
另请注意，在写入g_token磁盘之前，我们可以额外触发一次空字节写入，以截断移位后的 BSS 指针。这样，我们就可以写出指针的每个部分。例如，如果移位后的指针为0x766554433，我们可以写出从33、3344、…… 到完整的 的每个部分3344556607。
|
||||
|
||||
|
||||
|
||||
一旦 JSON 文件包含泄漏信息，我们就可以CMD_TOKEN按预期使用，它需要一个字符串参数来指示要使用的令牌。该令牌将在 JSON 文件中查找，并根据是否找到返回不同的错误代码。这将创建我们的第二个 oracle，我们可以使用它来实现逐字节的暴力破解：
|
||||
|
||||
b对移位后的 BSS 指针的 5 个字节中的每一个字节从 0 循环到 4：
|
||||
1. 将指针截断为 length b+1，然后将截断的段写入 JSON 文件
|
||||
|
||||
1. 循环遍历可能的字节0 - 0xff：
|
||||
|
||||
- 发送CMD_TOKEN猜测的字节（前面加上前几次迭代中已知的字节，长度为b）
|
||||
|
||||
- 返回的错误代码将指示提供的字节是否正确
|
||||
|
||||
- b如果正确，我们就找到了移位指针索引处的字节
|
||||
|
||||
- 否则，继续尝试下一个可能的字节
|
||||
|
||||
一旦逐字节暴力破解完成，我们就泄露了移位后的 BSS 指针，从而得到了共享库的基址。由于mmap映射在虚拟内存中是连续的，因此这也给了我们所有共享库的地址，尤其是 libc 的地址。
|
||||
|
||||
劫持控制流
|
||||
|
||||
有了泄漏，我们就可以准备制作最终的有效载荷来劫持控制流。
|
||||
|
||||
我们已经有能力在有效载荷缓冲区中释放一个伪块，并且通过发送其他命令，我们可以任意破坏这个空闲的块。此时，我们可以以标准方式滥用 tcache 链表：
|
||||
1. 使用任意地址破坏伪块的下一个指针
|
||||
|
||||
1. 分配与假块大小相同的内容
|
||||
|
||||
1. malloc将返回假块，然后将 tcache 列表的新头部设置为任意地址
|
||||
|
||||
1. 再次分配相同的大小以malloc返回任意地址
|
||||
|
||||
我们只需要找到一些符合这种连续两次分配模式的代码。幸运的是，CMD_TOKEN处理程序符合这种模式，并且在执行两次分配之后，std::string临时包含我们输入参数的函数会被析构，并调用delete一个char*带有我们输入的函数。
|
||||
|
||||
这给我们带来了以下策略：
|
||||
1. 破坏伪 tcache 块的下一个指针，使其指向共享库的 GOT 条目附近delete
|
||||
|
||||
1. 发送CMD_TOKEN命令
|
||||
|
||||
1. 处理程序将从损坏的 tcache 中分配两次，并delete用以下方式覆盖 GOT 条目：system
|
||||
|
||||
1. 后续的析构函数调用delete，而是system使用受控的输入字符串调用
|
||||
|
||||
从这里开始，游戏就结束了。我们可以简单地执行/bin/sh并将 stdio 重定向到已经连接的客户端套接字（避免了回连）。
|
||||
|
||||
|
||||
我们提交的完整漏洞代码已在此处提供-
|
||||
https://github.com/ret2/Pwn2Own-Ireland2024-DiskStation。
|
||||
|
||||
修复
|
||||
|
||||
该漏洞的编号为 CVE-2024-10442。Synology 于 2024 年 11 月 5 日（Pwn2Own Ireland 于 10 月 22 日举行）相对较快地发布了针对复制服务的补丁，您可以在此处找到该补丁的公告。ZDI 的公告可在此处找到。该补丁修改了函数recvCmd，如果提供的标头长度过长，则返回错误而不是零。
|
||||
|
||||
```
|
||||
if (cmd->header.len > 0x10000) return1; // instead of previous return 0
|
||||
```
|
||||
|
||||
|
||||
然后，调用者检测到此错误并放弃，而不是继续处理无效命令。
|
||||
|
||||
结论
|
||||
|
||||
虽然很容易找到，但这个漏洞的利用过程却非常有趣，因为空字节写入的攻击原语相对较弱。它感觉就像你在 CTF 挑战中会遇到的那种漏洞，而且 tcache 操作和暴力破解预言机也符合 CTF 的风格。
|
||||
|
||||
更严重的是，尽管它不在默认包中，但在远程可访问服务（以 root 身份运行）中存在如此简单的漏洞还是有点令人担忧，尤其是考虑到 Synology 是一款相当流行的面向消费者和企业的 NAS，这些设备暴露在互联网上的情况并不少见。
|
||||
|
||||
|
||||
|
||||
|
||||
感谢您抽出
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
来阅读本文
|
||||
|
||||
|
||||
|
||||
**点它，分享点赞在看都在这里**
|
||||
|
||||
|
||||
154
doc/2025-05/可蠕虫化AirPlay漏洞：公共WiFi环境下可零点击远程控制苹果设备.md
Normal file
154
doc/2025-05/可蠕虫化AirPlay漏洞：公共WiFi环境下可零点击远程控制苹果设备.md
Normal file
@ -0,0 +1,154 @@
|
||||
# 可蠕虫化AirPlay漏洞：公共WiFi环境下可零点击远程控制苹果设备
|
||||
FreeBuf 2025-05-06 10:29
|
||||
|
||||
|
||||
|
||||
|
||||
网络安全研究人员近日披露了苹果AirPlay协议中一系列现已修复的安全漏洞，攻击者成功利用这些漏洞可控制支持该专有无线技术的设备。以色列网络安全公司Oligo将这些漏洞统称为AirBorne。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**01**
|
||||
|
||||
|
||||
## 漏洞组合可形成蠕虫式攻击
|
||||
|
||||
##
|
||||
|
||||
|
||||
|
||||
|
||||
研究人员Uri Katz、Avi Lumelsky和Gal Elbaz指出："攻击者可串联利用这些漏洞，控制支持AirPlay的设备——包括苹果设备和采用AirPlay SDK（软件开发工具包）的第三方设备。"其中CVE-2025-24252与CVE-2025-24132等漏洞组合后，可形成无需用户交互的蠕虫化远程代码执行（RCE，Remote Code Execution）攻击链，使恶意软件能在受感染设备连接的任何本地网络中传播。
|
||||
|
||||
|
||||
这种攻击方式可能为部署后门和勒索软件等复杂攻击创造条件，构成严重安全威胁。整体而言，这些漏洞可实现：
|
||||
|
||||
- 零点击或单点击远程代码执行
|
||||
|
||||
- 绕过访问控制列表（ACL）和用户交互验证
|
||||
|
||||
- 本地任意文件读取
|
||||
|
||||
- 信息泄露
|
||||
|
||||
- 中间人（AitM）攻击
|
||||
|
||||
- 拒绝服务（DoS）攻击
|
||||
|
||||
**02**
|
||||
|
||||
|
||||
|
||||
## 具体攻击场景分析
|
||||
|
||||
|
||||
|
||||
通过串联CVE-2025-24252和CVE-2025-24206漏洞，攻击者可对与其处于同一网络的macOS设备实施零点击RCE攻击。但此攻击需要目标设备的AirPlay接收器处于开启状态，且设置为"同一网络上的任何人"或"所有人"模式。
|
||||
|
||||
|
||||
典型攻击场景中，受害设备连接公共Wi-Fi时即被入侵。若该设备后续接入企业网络，攻击者将获得入侵同一网络其他设备的通道。
|
||||
|
||||
|
||||
**03**
|
||||
|
||||
|
||||
|
||||
## 关键漏洞清单
|
||||
|
||||
|
||||
- CVE-2025-24271：访问控制漏洞，允许同一网络中的攻击者绕过配对验证向已登录Mac发送AirPlay指令
|
||||
|
||||
- CVE-2025-24137：可导致任意代码执行或应用终止的漏洞
|
||||
|
||||
- CVE-2025-24132：基于栈的缓冲区溢出漏洞，可在采用AirPlay SDK的扬声器和接收器上实现零点击RCE
|
||||
|
||||
- CVE-2025-24206：认证漏洞，允许本地网络攻击者绕过认证策略
|
||||
|
||||
- CVE-2025-24270：可导致敏感用户信息泄露的漏洞
|
||||
|
||||
- CVE-2025-24251：可导致应用异常终止的漏洞
|
||||
|
||||
- CVE-2025-31197：可导致应用异常终止的漏洞
|
||||
|
||||
- CVE-2025-30445：类型混淆漏洞，可导致应用异常终止
|
||||
|
||||
- CVE-2025-31203：整数溢出漏洞，可造成拒绝服务状态
|
||||
|
||||
**04**
|
||||
|
||||
|
||||
|
||||
## 补丁发布情况
|
||||
|
||||
|
||||
|
||||
苹果已在以下版本中修复这些漏洞：
|
||||
- iOS 18.4与iPadOS 18.4
|
||||
|
||||
- iPadOS 17.7.6
|
||||
|
||||
- macOS Sequoia 15.4
|
||||
|
||||
- macOS Sonoma 14.7.5
|
||||
|
||||
- macOS Ventura 13.7.5
|
||||
|
||||
- tvOS 18.4
|
||||
|
||||
- visionOS 2.4
|
||||
|
||||
部分漏洞（CVE-2025-24132和CVE-2025-30422）还在以下组件中修复：
|
||||
- AirPlay音频SDK 2.7.1
|
||||
|
||||
- AirPlay视频SDK 3.6.0.126
|
||||
|
||||
- CarPlay通信插件R18.1
|
||||
|
||||
Oligo强调："企业必须立即将所有支持AirPlay的苹果设备及其他终端升级至最新版本。安全负责人还需明确告知员工，其所有支持AirPlay的个人设备也需立即更新。"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651319938&idx=1&sn=8b4f45b0d0c45643793a84ad8bca2a13&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651319699&idx=1&sn=127e9ca1a8d55931beae293a68e3b706&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651319086&idx=1&sn=e2ff862babd7662c4fa06b0e069c03f2&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user