macOS xpc_connection_get_audit_token Attack
学习和实践 AWS 黑客技术：
HackTricks 培训 AWS 红队专家 (ARTE)
学习和实践 GCP 黑客技术：
HackTricks 培训 GCP 红队专家 (GRTE)
有关更多信息，请查看原始帖子： https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/。以下是摘要：
Mach 消息基本信息
如果你不知道 Mach 消息是什么，请开始查看此页面：
macOS IPC - Inter Process Communication目前请记住（此处定义）： Mach 消息通过 mach 端口 发送，这是一个内置于 mach 内核的 单接收者，多发送者通信 通道。多个进程可以向 mach 端口发送消息，但在任何时候 只有一个进程可以从中读取。就像文件描述符和套接字一样，mach 端口由内核分配和管理，进程只看到一个整数，可以用来指示内核它们想使用哪个 mach 端口。
XPC 连接
如果你不知道如何建立 XPC 连接，请查看：
macOS XPC漏洞摘要
你需要知道的有趣信息是 XPC 的抽象是一个一对一连接，但它是基于一种 可以有多个发送者的技术，因此：
Mach 端口是单接收者，多个发送者。
XPC 连接的审计令牌是 从最近接收到的消息复制的审计令牌。
获取 XPC 连接的 审计令牌 对许多 安全检查 至关重要。
尽管前面的情况听起来很有前景，但在某些场景中这不会导致问题（来自这里）：
审计令牌通常用于授权检查，以决定是否接受连接。由于这是通过向服务端口发送消息进行的，因此 尚未建立连接。在此端口上的更多消息将被视为额外的连接请求。因此，在接受连接之前的任何 检查都不易受攻击（这也意味着在
-listener:shouldAcceptNewConnection:中审计令牌是安全的）。因此，我们 正在寻找验证特定操作的 XPC 连接。XPC 事件处理程序是同步处理的。这意味着一个消息的事件处理程序必须在调用下一个之前完成，即使在并发调度队列中。因此，在 XPC 事件处理程序内部，审计令牌不能被其他正常（非回复！）消息覆盖。
这可能被利用的两种不同方法：
变体1：
利用 连接 到服务 A 和服务 B
服务 B 可以调用服务 A 中用户无法调用的 特权功能
服务 A 在
dispatch_async中的连接 事件处理程序 外部 调用xpc_connection_get_audit_token。因此，不同的 消息可能会 覆盖审计令牌，因为它在事件处理程序外部异步调度。
利用将 发送权 传递给 服务 B 的服务 A。
因此，服务 B 实际上将 发送 消息到服务 A。
利用 尝试 调用 特权操作。在 RC 服务 A 检查 此 操作 的授权，而 服务 B 覆盖了审计令牌（使利用能够调用特权操作）。
变体 2：
服务 B 可以调用服务 A 中用户无法调用的 特权功能
利用与 服务 A 连接，服务 A 向利用发送一条 期望回复 的消息。
利用向 服务 B 发送一条消息，传递 该回复端口。
当服务 B 回复 时，它 将消息发送到服务 A，同时 利用向服务 A 发送一条不同的 消息，试图 达到特权功能，并期望服务 B 的回复会在完美的时刻覆盖审计令牌（竞争条件）。
变体 1：在事件处理程序外部调用 xpc_connection_get_audit_token
场景：
两个 mach 服务
A和B，我们都可以连接（基于沙箱配置文件和接受连接之前的授权检查）。A 必须对
B可以传递的特定操作进行 授权检查（但我们的应用程序不能）。例如，如果 B 拥有某些 权限 或以 root 身份运行，它可能允许他请求 A 执行特权操作。
对于此授权检查，
A异步获取审计令牌，例如通过从dispatch_async调用xpc_connection_get_audit_token。
在这种情况下，攻击者可以触发 竞争条件，使 利用 多次请求 A 执行操作，同时使 B 向 A 发送消息。当 RC 成功 时，B 的 审计令牌 将在 利用 的请求被 处理 时复制到内存中，从而使其 访问只有 B 可以请求的特权操作。
这发生在 A 作为 smd 和 B 作为 diagnosticd。函数 SMJobBless 可以用于安装新的特权辅助工具（作为 root）。如果 以 root 身份运行的进程联系 smd，将不会执行其他检查。
因此，服务 B 是 diagnosticd，因为它以 root 身份运行并可用于 监控 进程，因此一旦开始监控，它将 每秒发送多条消息。
进行攻击的步骤：
使用标准 XPC 协议发起与名为
smd的服务的 连接。形成与
diagnosticd的二次 连接。与正常程序相反，而不是创建并发送两个新的 mach 端口，客户端端口发送权被替换为与smd连接相关联的 发送权 的副本。结果，XPC 消息可以调度到
diagnosticd，但来自diagnosticd的响应被重定向到smd。对于smd来说，来自用户和diagnosticd的消息似乎都来自同一连接。
下一步是指示
diagnosticd启动对所选进程（可能是用户自己的进程）的监控。同时，向smd发送大量常规 1004 消息。此操作的目的是安装具有提升权限的工具。此操作触发
handle_bless函数中的竞争条件。时机至关重要：xpc_connection_get_pid函数调用必须返回用户进程的 PID（因为特权工具位于用户的应用程序包中）。然而，xpc_connection_get_audit_token函数，特别是在connection_is_authorized子例程中，必须引用属于diagnosticd的审计令牌。
变体 2：回复转发
在 XPC（跨进程通信）环境中，尽管事件处理程序不会并发执行，但回复消息的处理具有独特的行为。具体而言，存在两种不同的方法来发送期望回复的消息：
xpc_connection_send_message_with_reply：在这里，XPC 消息在指定队列上接收和处理。xpc_connection_send_message_with_reply_sync：相反，在此方法中，XPC 消息在当前调度队列上接收和处理。
这种区别至关重要，因为它允许 回复数据包在执行 XPC 事件处理程序时并发解析。值得注意的是，虽然 _xpc_connection_set_creds 确实实现了锁定以防止审计令牌的部分覆盖，但它并未将此保护扩展到整个连接对象。因此，这造成了一个漏洞，在解析数据包和执行其事件处理程序之间的间隔中，审计令牌可能会被替换。
要利用此漏洞，需要以下设置：
两个 mach 服务，称为
A和B，都可以建立连接。服务
A应包含对只有B可以执行的特定操作的授权检查（用户的应用程序无法）。服务
A应发送一条期望回复的消息。用户可以向
B发送一条消息，B 将对此进行回复。
利用过程涉及以下步骤：
等待服务
A发送一条期望回复的消息。不直接回复
A，而是劫持回复端口并用于向服务B发送消息。随后，发送一条涉及禁止操作的消息，期望它与来自
B的回复并发处理。
以下是所描述攻击场景的可视化表示：
 (1) (1) (1) (1) (1) (1).png)
发现问题
定位实例的困难：静态和动态搜索
xpc_connection_get_audit_token使用实例都很具挑战性。方法论：使用 Frida 钩住
xpc_connection_get_audit_token函数，过滤不来自事件处理程序的调用。然而，此方法仅限于被钩住的进程，并需要主动使用。分析工具：使用 IDA/Ghidra 等工具检查可达的 mach 服务，但该过程耗时，且涉及 dyld 共享缓存的调用使其复杂。
脚本限制：尝试为从
dispatch_async块调用xpc_connection_get_audit_token的分析编写脚本时，由于解析块和与 dyld 共享缓存的交互的复杂性而受到阻碍。
修复
报告问题：向 Apple 提交了一份报告，详细说明了在
smd中发现的一般和特定问题。Apple 的回应：Apple 通过将
xpc_connection_get_audit_token替换为xpc_dictionary_get_audit_token解决了smd中的问题。修复的性质：
xpc_dictionary_get_audit_token函数被认为是安全的，因为它直接从与接收的 XPC 消息相关的 mach 消息中检索审计令牌。然而，它不是公共 API 的一部分，类似于xpc_connection_get_audit_token。缺乏更广泛的修复：尚不清楚为什么 Apple 没有实施更全面的修复，例如丢弃与连接的保存审计令牌不一致的消息。某些情况下（例如，使用
setuid）合法审计令牌更改的可能性可能是一个因素。当前状态：该问题在 iOS 17 和 macOS 14 中仍然存在，给那些寻求识别和理解它的人带来了挑战。
学习和实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE)
学习和实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
Last updated