Windows 安全描述符审计方法探究：审查事件日志安全性

在获得对系统的访问权限后，对于尚未提升特权的攻击者，系统会授予什么级别的访问权限呢？

与其在主机上进行试验，最终被系统提示拒绝访问，并在测试过程中会产生嘈杂的日志，不如选择一个更好的策略，那就是首先了解 Windows 授予非特权用户的权限。

在 Windows 中，几乎所有的访问权限都由安全描述符控制。 本文的目标就是建立一种审计方法，用于暴露由安全描述符错误配置的潜在风险。 在建立方法之后，我们将把它应用到一个实际的用例中: 在Windows 事件日志中，哪些潜在的可滥用访问权限被授予给了无特权组？ 为了回答这些问题，我们应该定义如下两点:

· 什么是错误配置？

· 什么是“可滥用的”访问权限？

在回答这些问题之前，让我们首先建立获取安全描述符的方法。

本博文的目标受众: 任何已经熟悉安全描述符、访问控制列表和 SACL 的人都希望形式化他们的自动化审计方法。 对于那些不熟悉这些概念的读者可以阅读下文中的参考资料章节中的资源。

获取安全描述符

众所周知，像文件、目录和注册表项这样的东西可以通过安全描述符进行安全保护，但是我们如何确定所有的安全保护项呢？ 对于初学者来说，内核认为许多东西是“可保护的” ，我们将这些东西称为可保护对象。 KTV有几种方法可以枚举安全对象类型，但我个人认为最简单的方法是使用 James Forshaw 的 NtObjectManager PowerShell 模块中的 Get-NtType cmdlet。 在没有任何参数的情况下运行 Get-NtType 会在我的 Windows 10主机上返回以下安全对象:

ActivationObject, ActivityReference, Adapter, ALPC Port, Callback, Composition, Controller, CoreMessaging, CoverageSampler, DebugObject, Desktop, Device, Directory, DmaAdapter, Driver, DxgkCompositionObject, DxgkCurrentDxgProcessObject, DxgkDisplayManagerObject, DxgkSharedBundleObject, DxgkSharedKeyedMutexObject, DxgkSharedProtectedSessionObject, DxgkSharedResource, DxgkSharedSwapChainObject, DxgkSharedSyncObject, EnergyTracker, EtwConsumer, EtwRegistration, EtwSessionDemuxEntry, Event, File, FilterCommunicationPort, FilterConnectionPort, IoCompletion, IoCompletionReserve, IRTimer, Job, Key, KeyedEvent, Mutant, NdisCmState, Partition, PcwObject, PowerRequest, Process, Profile, PsSiloContextNonPaged, PsSiloContextPaged, RawInputManager, RegistryTransaction, Section, Semaphore, Session, SymbolicLink, Thread, Timer, TmEn, TmRm, TmTm, TmTx, Token, TpWorkerFactory, Type, UserApcReserve, VRegConfigurationContext, WaitCompletionPacket, WindowStation, WmiGuid

然而，返回的安全对象似乎都与我们的特定用例（事件日志）无关。 因此，问题依然存在，事件日志安全吗？ 直观来说，微软必须考虑这方面的安全性，例如，无特权的用户无法查看或清除 安全事件日志。 此时此刻，开始谷歌搜索可能是明智之举。 在搜索“事件日志安全描述符”时，出现了以下与之相关的文章:

· Eventlog Key

在这篇文章中，作者引用了通过“ CustomSD”注册表值设置自定义安全描述符的功能。并且作者还引用了“Isolation”注册表值文档中的默认安全权限。

既然我们知道可以将安全描述符应用于事件日志，那么我们如何检索它们呢？ 幸运的是，当你在 PowerShell 调用 Get-WinEvent -ListLog 时，它将为每个事件日志返回一个 EventLogConfiguration 对象，该对象包含 SecurityDescriptor  属性。

> Get-WinEvent -ListLog Security | Select -ExpandProperty SecurityDescriptor

O:BAG:SYD:(A;;CCLCSDRCWDWO;;;SY)(A;;CCLC;;;BA)(A;;CC;;;ER)

作为参考，上面的字符串是一个 SDDL 字符串，这是一种方便表示安全描述符的方法。 像 ConvertFrom-SddlString 这样的工具对于理解它们非常有用。

作为一个喜欢了解底层 Win32 API 的人，我选择使用 dnSpy  追踪 SecurityDescriptor 属性的实现，可以发现系统在 wevtapi.dll 中调用了 EvtGetChannelConfigProperty 函数并指定 EvtChannelConfigAccess 枚举值。 了解调用相关 Win32 API 函数的 DLL 也是有价值的，因为它指向了 Windows SDK 中的各个头文件(在本例中为 winevt.h) ，这些头文件通常会提供 MSDN 文档以外的有价值的信息。

现在，如果我们要审计事件日志安全描述符，我们需要知道系统对它们应用了什么访问权限。

确定相关的访问权限

对于事件日志访问控制条目，我们需要理解访问权限掩码的四个部分:

· 特定于对象的访问权限——特定于安全对象的权限，在本例中为事件日志。

· 标准访问权限 ——适用于安全描述符本身的权限。

· 通用访问权限 ——与标准的和特定的对象权限相对应的权限。

· SACL 访问权限 —— 控制日志记录和对对象授予或拒绝访问的权限。

至于特定对象的访问权限，这里有说明文档。 不过，有时候访问权限会被添加或删除，但文档并不会更新。 这就是为什么我更喜欢了解相应的 Windows SDK 头文件—— winevt.h，奇热它有最新的对象特定的访问权限定义:

 

#define EVT_READ_ACCESS    0x1
#define EVT_WRITE_ACCESS   0x2
#define EVT_CLEAR_ACCESS   0x4
#define EVT_ALL_ACCESS     0x7

 

对于那些不熟悉按位操作的用户， EVT_ALL_ACCESS 是二进制“或”操作EVT_READ_ACCESS | EVT_WRITE_ACCESS | EVT_CLEAR_ACCESS的结果。

现在，映射通用访问权限通常有点棘手。 通用访问权限用于映射一个或多个标准和特定于对象的访问权限。 对于“鲜为人知”的安全对象，要么缺乏通用权限的映射说明文档，要么根本不存在，对于事件日志，这也不例外。 因此，在没有文档或头文件提供这些信息的情况下，我们只能在代码中寻找答案。 不过你可能要问的第一个问题是，“在什么代码里找答案? ” 我们必须用一些猜测和直觉来回答这个问题。 我采取的方法是使用前面解释过的“ CustomSD”关键词，我们在 dll 中搜索一下这个关键词，因为它与事件日志安全强相关。 一旦我找到了这个引用，那么与通用访问权限相关的代码可能就位于搜索结果的附近。 我使用下面的 PowerShell 代码来识别候选的 DLL 文件：

 

$EventLogAccess = ls C:\Windows\System32\*.dll | sls 'CustomSD' -Encoding unicode
$EventLogAccess.Path | Sort -Unique

 

运行结果如下：

 

C:\Windows\System32\acmigration.dll
C:\Windows\System32\aeinv.dll
C:\Windows\System32\apphelp.dll
C:\Windows\System32\appraiser.dll
C:\Windows\System32\d3d9.dll
C:\Windows\System32\drvstore.dll
C:\Windows\System32\dxdiagn.dll
C:\Windows\System32\dxgi.dll
C:\Windows\System32\generaltel.dll
C:\Windows\System32\kernel32.dll
C:\Windows\System32\opengl32.dll
C:\Windows\System32\setupapi.dll
C:\Windows\System32\vbsapi.dll
C:\Windows\System32\vfluapriv.dll
C:\Windows\System32\wevtsvc.dll

在我看来，最相关的 DLL 是 wevtsvc.DLL，即与事件日志服务相关联的 DLL。

在用符号将 wetsvc.dll 加载到 IDA 中时，对“ CustomSD”的一个交叉引用将我带入到“ channelconfidgreader::GetChannelAccessSddl”函数。

虽然这个函数和它的交叉引用没有产生任何与通用访问权限相关的东西，但是 GetDefaultSDDL 函数非常有趣，在稍微进行逆向之后，我可以看到事件日志服务在没有应用自定义安全描述符的情况下定义了以下安全描述符：

 

安全日志
O:BAG:SYD:(A;;CCLCSDRCWDWO;;;SY)(A;;CCLC;;;BA)(A;;CC;;;ER)
系统日志
O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x3;;;BO)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x3;;;SU)(A;;0x1;;;S-1-5-3)(A;;0x2;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)
应用程序日志
O:BAG:SYD:(A;;0x2;;;S-1-15-2-1)(A;;0x2;;;S-1-15-3-1024-3153509613-960666767-3724611135-2725662640-12138253-543910227-1950414635-4190290187)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)

这些与“Isolation”注册表值的文档有些对应，但不完全相同。 这是另一个不能依赖相关说明文档的例子，即使你想要一个精确的结果。 现在我们已经有了围绕默认事件日志安全描述符的上下文，这将很快成为解释为什么这么多事件日志应用了相同的安全描述符的相关内容。 回到通用访问权限，尽管问题很复杂。

在查找 wevtsvc.dll 二进制文件时，我偶然发现了对内部函数 EvtCheckAccess 中的 AccessCheck  函数的调用:

在看到这个调用并参考文档后，我可以看到这个函数是用于检查任何可以支持应用安全描述符的对象的访问。 它还需要一个 GenericMapping 参数。 在这种情况下，wevtsvc.dll 提供了一个由 GENERIC_MAPPING  结构组成的必须需要的全局变量 AccessCheck。 在 IDA 中，显示的内容如下:

 

现将其翻译如下：

· GENERIC_READ 映射到EVT_READ_ACCESS

· GENERIC_WRITE 映射到EVT_WRITE_ACCESS

· GENERIC_EXECUTE 没有映射到任何特定于对象的访问权限

· GENERIC_ALL 映射到EVT_ALL_ACCESS

这就对了，现在你就可以在网上找到相关的文档了。

现在，我们就已经拥有了围绕审计事件日志安全描述符构建自动化所需的所有组件。

滥用访问权限的考虑

枚举目标安全对象所支持的所有访问权限的工作完成后，你就可以开始考虑每个访问权限对没有执行特权升级的攻击者有哪些好处。 经过考虑后，我提出了对每个事件日志访问权限的影响，如下:

特定对象访问权限的含义:

· EVT_READ_ACCESS: 授予用户或组读取特定事件日志中的事件的能力。 如果事件日志有可能存储敏感信息，那么就有可能被滥用。 此外，大多数事件日志都有从任何进程的上下文中写入的事件，因此，xise攻击者就有机会从非特权用户的上下文中读取特权进程写入的事件日志。

· EVT_WRITE_ACCESS: 授予用户或组将事件写入特定事件日志的能力。 通过使用事件日志的写操作 API，攻击者就可以生成假的事件日志记录，这可能会给人一种“良好的”假象。 它们还可能考虑在恶意的执行操作之后向事件日志中注入正常的日志记录，导致攻击者实际执行的恶意操作的上下文日志滚动并丢失。 攻击者还可能选择将数据写入事件日志，作为一种不受安全产品隔离查杀的原始数据存储机制。

· EV