单向链表缺陷与 AuthzBasep SecurityDescriptor 传播攻击
摘要 Windows 安全引用监视器是对象访问的最后仲裁者，其访问检查逻辑沿 AuthzBasep 单向链表回溯安全描述符，为用户态权限评估提供“足够快”的缓存答案。然而，该缓存与内核态真实安全描述符之间存在可被精确操纵的传播延迟。攻击者通过在 NtSetSecurityObject 修改 DACL 与 AuthzAccessCheck 读取缓存之间制造 TOCTOU 窗口，可迫使 SRM 基于过期的权限授予访问令牌，造成“用户态通过、内核态拒绝”的悖论权限提升。 Windows 访问检查的分裂模型 安全引用监视器的两条路径 Windows 对对象（文件、注册表、进程）的访问控制由内核模式安全引用监视器集中裁决。当用户态应用程序请求 CreateFile 时，最终会调用 SeAccessCheck（内核态）进行权限评估。然而，大量的用户态授权框架（如 AuthzAccessCheck、AccessCheckByType）并不直接发起内核调用，而是依赖 AuthzBasep 内部的“安全描述符缓存”来模拟访问判断。 这种设计产生了天然的时间裂隙：内核真实安全描述符（位于 OBJECT_HEADER->SecurityDescriptor）由内核线程在 ObpReferenceSecurityDescriptor 中同步更新，而用户态缓存（AuthzBasepCachedSecurityDescriptor）的刷新是异步、节流的，甚至受制于单向链表遍历效率。 AuthzBasep 的单向链表缓存架构 AuthzBasep 是 Windows authz.dll 的核心引擎，内部维护一个单向链表（AuthzBasepSecurityDescriptorList），每个节点包含对象的引用名称、缓存的安全描述符副本、以及上一次刷新时间戳。当应用程序调用 AuthzAccessCheck 时，它遍历该单向链表，查找同名对象的最新缓存描述符，然后基于缓存执行访问检查，不会实时查询内核状态。 单向链表的天然缺陷在于：查找与刷新操作为 O(n) 复杂度，且没有原子性保证。刷新线程（AuthzBasepUpdateThread）周期性唤醒，逐个节点检查 LastUpdateTime，若超过阈值（默认 15 秒）则重新从内核拉取安全描述符。如果攻击者在刷新线程遍历到目标节点之前修改内核安全描述符并触发用户态访问检查，旧版缓存仍然被信任。 传播延迟 内核 SeAccessCheck 与 SepAccessCheck 的调用链分裂 理解分裂链条对于攻击窗口的精准打击至关重要。 用户态请求 →SeAccessCheck (ntoskrnl.exe)：直接读取对象内核安全描述符，基于调用者 Token 进行即时权限判定。任何修改（如 NtSetSecurityObject）均立即在此路径中体现。 用户态 Authz 请求 →SepAccessCheck (authz.dll)：是 SeAccessCheck 的用户态模拟。它使用缓存的 SecurityDescriptor 副本，并与内核 Token 句柄交互。SepAccessCheck 不与 SeAccessCheck 同步。 分裂意味着：同一对象在同一时刻，SeAccessCheck 可能返回“拒绝”，而 SepAccessCheck 可能返回“允许”。这正是缓存延迟攻击的根基。 AuthzBasepCachedSecurityDescriptor 的刷新触发器 AuthzBasepCachedSecurityDescriptor 结构的关键字段： typedefstruct _AUTHZ_BASEP_CACHED_SD { LIST_ENTRY Link;…