我一直在用 powershell 编写一个程序,从我的 windows 2012r2 服务器中提取安全事件日志。在调查将事件解析为 xml 的过程中的一个错误时,我发现 4656 事件的“访问原因”属性中有一个非常奇怪的问题:
%%4423: %%1801 D:(A;ID;FA;;;S-1-5-21-527573203-644103923-227697207-2229)
%%4424: %%1801 D:(A;ID;FA;;;S-1-5-21-527573203-644103923-22769蹂ᢻ翼
请注意,在 DACL 的最终 ACE 的事件解析结束时,它出于某种原因将尾随的 10 个字符转换为中文 unicode 字符。在 eventvwr 中,它甚至更改了事件其余部分的字体。服务器上的随机文件和随机受托人 SID 都会发生这种情况
今天下午我将识别文件,但不解析为 XML,以尝试检测任何模式,有人对这个奇怪的问题有什么建议吗?我假设它是微软安全事件日志的一个错误,但问题是相同的 unicode 字符串替换了不同的 ansi 字符串值,并且位于 ACE 的不同位置。连接因素是它始终是最后一个 ACE,但这就是我目前得到的全部信息。
答案1
所以显然我发现了“IsTextUnicode”/“布什隐瞒了事实”的错误,自从我出生以来它就存在于 Windows 中……定义 ACE 的 SDDL 语言是一个无效的终止字符串。不同编码中处理空值的方式导致将安全描述符转换为字符串安全描述符函数来实现这个神奇的魔法。请注意文本Unicode功能和将安全描述符转换为字符串安全描述符函数共享同一个库:Advapi32。
以上假设记录在审计写入时被破坏。我还假设这不是AuthzReportSecurityEvent函数解析上述函数的输出。我在 MSDN 上读到的所有文档都与服务器 2003 枚举、结构和函数有关。因此,所有这些函数和结构可能与我在 MSDN 上读到的不同。
此问题也可能发生在日志的读取时;有问题的功能是读取事件日志(也共享 Advapi32)和格式信息。
我确信“访问原因”属性已于 2012 年作为“动态访问控制”的一部分添加到文件审计结构中。就是这样。上述任何功能问题都可能适用于现在增加的事件消息大小。
https://en.wikipedia.org/wiki/Bush_hid_the_facts https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4656
编辑:微软声称已在 Vista 中修复了此错误,但如您所见,这里出现了 unicode 转换问题。错误是一样的。我将进一步说明该函数文本Unicode是对传递给函数的字符串的统计分析。虽然它永远不会完全完美,但这个问题与事件消息子部分中包含的行的终止有关。事件消息的每个部分还包含一个终止符字节,因此我假设这两个终止字节导致 unicode/ansi 转换函数逻辑中的解析问题,无论是在读取还是写入时。