Я написал сценарий процедуры в PowerShell для извлечения журналов событий безопасности с моего сервера Windows 2012r2. Исследуя ошибку в моей процедуре синтаксического анализа события в xml, я обнаружил очень странную проблему в свойстве Access Reasons события 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蹂ᢻ翼
Обратите внимание, что в конце синтаксического анализа события последнего ACE DACL он по какой-то причине преобразовал последние 10 символов в китайские символы Unicode. В случае eventvwr он даже меняет шрифт остальной части события. Это происходит для случайных файлов на сервере и случайных SID доверенных лиц.
Я буду идентифицировать файлы сегодня днем, не анализируя XML, чтобы попытаться обнаружить какие-либо закономерности, кто-нибудь посоветовал бы по этому странному? Я предполагаю, что это ошибка с журналированием событий безопасности microsoft, но дело в том, что одна и та же строка символов Unicode заменяет разные строковые значения ansi и в разных позициях ACE. Связующим фактором является то, что это всегда последний ACE, но это все, что у меня есть.
Очевидно, я обнаружил ошибку "IsTextUnicode" / "Bush Hid The Facts", которая существовала в Windows с момента моего рождения ... Язык SDDL, который определяет ACE, является ноль завершенная строка. Способ обработки нулей в разных кодировках вызывает ConvertSecurityDescriptorToStringSecurityDescriptor функция, чтобы творить эту напуганную магию. Обратите внимание, что IsTextUnicode функция и ConvertSecurityDescriptorToStringSecurityDescriptor функции используют ту же библиотеку: Advapi32.
Вышесказанное предполагает, что запись была повреждена во время записи аудита. Я также предполагаю, что это не ошибка в AuthzReportSecurityEvent функция, анализирующая выходные данные вышеуказанных функций. Вся документация, которую я прочитал на MSDN, относится к перечислениям, структурам и функциям сервера 2003. Таким образом, все эти функции и структуры могут отличаться от того, что я читал в MSDN.
Эта проблема также могла быть во время чтения журналов; Рассматриваемые функции ReadEventLog (Также использует Advapi32) и FormatMessage.
Я уверен, что свойство «Причины доступа» было добавлено в структуру аудита файлов в 2012 году как часть «динамического контроля доступа». Вот оно. Любая из вышеперечисленных функциональных проблем может относиться к теперь увеличенному размеру сообщения о событии.
https://en.wikipedia.org/wiki/Bush_hid_the_facts https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4656
EDIT: Microsoft утверждает, что исправила эту ошибку в Vista, но, как вы можете видеть, здесь возникает проблема преобразования Unicode. Баг тот же. Я расширю, чтобы сказать, что функция IsTextUnicode статистический анализ строки, передаваемой функции. Хотя это никогда не будет идеально, эта проблема связана с завершением строки, содержащейся в подразделе сообщения о событии. Каждый раздел сообщения о событии также содержит байт-терминатор, поэтому я предполагаю, что два завершающих байта вызывают проблему синтаксического анализа в логике функции преобразования Unicode / ansi при чтении или записи.
