Meu log de eventos corrompeu DACL 'Write Attributes' em eventos de auditoria de arquivos 4656

Question

Eu tenho roteirizado um procedimento no powershell para extrair logs de eventos de segurança do meu servidor windowsr 2012r2. Investigando um bug no meu procedimento para analisar o evento em xml, descobri um problema muito estranho na propriedade 'Access Reasons' do evento 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蹂ᢻ翼

Recorte do log de eventos

Observe que, no final da análise de evento da ACE final da DACL, por algum motivo, ela converteu os 10 caracteres finais em caracteres unicode chineses. Em eventvwr, até altera a fonte do resto do evento. Isso ocorre para arquivos aleatórios no servidor e SIDs de trustee aleatórios

Eu identificarei os arquivos esta tarde sem analisar em XML para tentar detectar qualquer padrão, alguém tem algum conselho sobre esse estranho? Eu estou supondo que é um bug com o log de eventos de segurança da Microsoft, mas a coisa é a mesma cadeia de caracteres unicode substituindo diferentes valores de seqüência de caracteres ansi e em diferentes posições da ACE. O fator de conexão é que é sempre o último ACE, mas foi tudo o que consegui até agora.

    

Answer 1

Então, aparentemente eu descobri o bug "IsTextUnicode" / "Bush Hid The Facts" que existe no Windows desde meu nascimento ... A linguagem SDDL que define a ACE é uma string terminada null . A forma como os nulos são manipulados em diferentes codificações está causando a função ConvertSecurityDescriptorToStringSecurityDescriptor para fazer essa mágica funky. Note que a função IsTextUnicode e a função ConvertSecurityDescriptorToStringSecurityDescriptor compartilham a mesma biblioteca: Advapi32.

O acima assume que o registro está sendo corrompido no tempo de gravação da auditoria. Eu também assumo que não é um bug na função AuthzReportSecurityEvent analisando as saídas das funções acima. Toda a documentação que li no MSDN está relacionada a enumerações, estruturas e funções do servidor 2003. Então, todas essas funções e estruturas podem ser diferentes das que eu tenho lido no MSDN.

Esse problema também pode estar no tempo de leitura dos registros; As funções em questão são ReadEventLog (também compartilha Advapi32) e FormatMessage .

Tenho certeza de que a propriedade "Razões de acesso" foi adicionada à estrutura de auditoria de arquivos em 2012 como parte do "controle de acesso dinâmico". Aí está. Qualquer um dos problemas funcionais acima pode se aplicar ao tamanho agora aumentado da mensagem do evento.

link link

EDITAR: A Microsoft alega ter corrigido esse bug no vista, mas como você pode ver, há um problema de conversão unicode ocorrendo aqui. O bug é o mesmo. Eu vou expandir para dizer que a função IsTextUnicode é uma análise estatística da string sendo passada para a função. Embora nunca seja exatamente perfeito, esse problema é sobre o término de uma linha contida em uma subseção da mensagem do evento. Cada seção da mensagem de evento também contém um byte de terminação, portanto, presumo que os dois bytes de terminação estejam causando um problema de análise dentro de uma lógica da função de conversão unicode / ansi, seja em leitura ou gravação.