3

I have been scripting a procedure in powershell to pull security event logs from my windows 2012r2 server. Investigating a bug in my procedure to parse the event into xml I discovered a very strange problem in the 'Access Reasons' property of the 4656 event:

%%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蹂ᢻ翼

Eventlog clipping

Notice that at the end of the event parse of the DACL's final ACE it for some reason has converted the trailing 10 characters into chinese unicode characters. In eventvwr it even changes the font of the rest of the event. This occurs for random files on the server, and random trustee SID's

I will be identifying the files this afternoon without parsing into XML to try to detect any patterns, anyone have advise on this weird one? I am assuming its a bug with microsoft security event logging, but the thing is the same unicode character string replacing different ansi string values, and at different positions of the ACE. The connecting factor is that it is always the last ACE, but that's all I got so far.

EPJK1337
  • 61
  • 7

1 Answers1

0

So apparently I have discovered the "IsTextUnicode"/"Bush Hid The Facts" bug that has existed in windows since my birth... The SDDL language that defines the ACE is a null terminated string. The way that nulls are handled in different encodings is causing the ConvertSecurityDescriptorToStringSecurityDescriptor function to do this funky magic. Note that the IsTextUnicode function and the ConvertSecurityDescriptorToStringSecurityDescriptor function share the same library: Advapi32.

The above assumes that the record is being corrupted at audit write time. I also assume that it not a bug in the AuthzReportSecurityEvent function parsing the outputs of the above functions. All the documentation I have read on MSDN relate to server 2003 enumerations, structures and functions. So all of these functions and structures could be different from what I have been reading on MSDN.

This issue could also be at readtime of the logs; The functions in question being ReadEventLog (Also shares Advapi32) and FormatMessage.

I am certain that the 'Access Reasons' property has been added to the file audit structure in 2012 as part of "dynamic access control". There it is. Any of the above functional issues can apply to the now increased size of the event message.

https://en.wikipedia.org/wiki/Bush_hid_the_facts https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4656

EDIT: Microsoft claims to have fixed this bug in vista, but as you can see there is a unicode conversion problem occurring here. The bug is the same. I will expand to say that the function IsTextUnicode is a statistical analysis of the string being passed to the function. Though it will never be exactly perfect, this issue is about the termination of a line contained within a subsection of the event message. Each section of the event message also contains a terminator byte, so I assume that the two terminating bytes are causing a parsing issue within a unicode/ansi conversion function's logic, either at read or write.

EPJK1337
  • 61
  • 7
  • Except for the detail that the Unicode issue was fixed in vista (as your link points out), this would be a good answer. – Jim B Dec 18 '15 at 15:40
  • The page does state that. But the observed behavior is there. I will edit my post to make that clear. – EPJK1337 Dec 18 '15 at 16:00