Os sistemas operacionais Windows têm um bom sistema de log de eventos de segurança. Muitas coisas boas foram escritas sobre ela em várias publicações e resenhas, mas este artigo será sobre outra coisa. Aqui falamos sobre problemas e deficiências neste sistema. Alguns dos problemas considerados não serão críticos, complicando apenas os procedimentos de análise de eventos, enquanto outros representam ameaças muito graves à segurança.
Os problemas identificados foram testados no Windows 7 Maximum (versão em russo), Windows 7 Professional (versão em inglês), Windows 10 Pro (versão em russo), Windows Server 2019 Datacenter (versão em russo). Todos os sistemas operacionais foram completamente atualizados.
Problema nº 1. Falha no sistema de gerenciamento de parâmetros de auditoria
O problema foi confirmado no Windows 7/10 / Server 2019.Descrição do problema
Leve o Windows 7 e instale-o com as configurações padrão. Não entraremos no domínio. Vamos ver as configurações de auditoria de eventos de segurança. Para fazer isso, abra o snap-in "Diretivas de segurança local" (secpol.msc ou "Painel de controle -> Ferramentas administrativas -> Diretivas de segurança local") e consulte as configurações básicas de auditoria ("Configurações de segurança -> Diretivas locais -> Diretivas de auditoria" )
Como você pode ver, a auditoria não está configurada. Agora vamos ver as políticas de auditoria avançadas ("Configurações de segurança -> Configuração avançada da política de auditoria -> Políticas de auditoria do sistema - objeto de diretiva de grupo local").
Aqui a auditoria também não está configurada. Nesse caso, teoricamente não deve haver nenhum evento de segurança nos logs. Nós verificamos. Abra o log de segurança (eventvwr.exe ou "Painel de Controle -> Ferramentas Administrativas -> Exibir Eventos").
Pergunta: “De onde vem o evento no log de segurança se a auditoria não está configurada?”Explicação
Para entender o motivo desse comportamento, você precisa "entender" o sistema operacional. Para começar, lidaremos com políticas de auditoria básicas e avançadas.
Antes do Windows Vista, havia apenas uma política de auditoria, que agora é chamada básica. O problema era que a granularidade do gerenciamento de auditoria naquela época era muito baixa. Portanto, se fosse necessário rastrear o acesso aos arquivos, eles incluíam a categoria da política básica “Auditar o acesso a objetos”. Como resultado, além das operações de arquivo, vários outros eventos de "ruído" foram derramados no log de segurança. Isso complicou bastante o processamento de logs e usuários irritados.
A Microsoft ouviu essa "dor" e decidiu ajudar. O problema é que o Windows se baseia no conceito de compatibilidade com versões anteriores, e fazer alterações no mecanismo de gerenciamento de auditoria existente eliminaria essa compatibilidade. Portanto, o fornecedor seguiu o outro caminho. Ele criou uma nova ferramenta e a chamou de Políticas avançadas de auditoria.
A essência da ferramenta é que, a partir das categorias de políticas básicas de auditoria, são feitas categorias de políticas avançadas e essas, por sua vez, são divididas em subcategorias que podem ser ativadas e desativadas separadamente. Agora, se você precisar rastrear o acesso aos arquivos nas políticas de auditoria avançadas, precisará ativar apenas a subcategoria "Sistema de Arquivos", incluída na categoria "Acesso ao Objeto". Ao mesmo tempo, eventos de "ruído" relacionados ao acesso ao registro ou à filtragem do tráfego de rede não serão incluídos no log de segurança.
A enorme confusão em todo esse esquema é causada pelo fato de os nomes das categorias de políticas básicas de auditoria e avançadas não coincidirem e, a princípio, pode parecer que essas são coisas completamente diferentes, mas não é assim.
Aqui está uma tabela de conformidade dos nomes das categorias básicas e avançadas de gerenciamento de auditoria
É importante entender que as categorias básicas e avançadas controlam essencialmente a mesma coisa. A inclusão de uma categoria básica de política de auditoria leva à inclusão da categoria correspondente de política de auditoria estendida e, como conseqüência, de todas as suas subcategorias. Para evitar consequências imprevistas, a
Microsoft não recomenda o uso de políticas de auditoria básicas e avançadas ao mesmo tempo.
Agora é a hora de descobrir onde as configurações de auditoria estão armazenadas. Para começar, apresentamos vários conceitos:
- Políticas de auditoria eficazes - informações armazenadas na RAM que determinam os parâmetros operacionais atuais dos módulos do sistema operacional que implementam funções de auditoria.
- Políticas de auditoria salvas - informações armazenadas no registro em HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv e usadas para determinar políticas de auditoria eficazes após a reinicialização do sistema.
Consideraremos várias ferramentas administrativas e indicamos quais parâmetros de auditoria eles exibem e quais definem. Os dados na tabela são baseados em experimentos.
Vamos explicar a tabela com exemplos.
Exemplo 1Se você executar o auditpol para visualizar as configurações de auditoria:
auditpol /get /category:* , os parâmetros de auditoria salvos serão exibidos, ou seja, aqueles armazenados no registro em HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv.
Exemplo 2Se você executar o mesmo utilitário, mas já definir os parâmetros:
auditpol /set /category:* , as configurações de auditoria efetivas e as configurações de auditoria salvas serão alteradas.
Um comentário separado requer a ordem em que as configurações de auditoria são exibidas no "Diretivas básicas de auditoria" do snap-in "Diretivas de segurança local". A categoria da política de auditoria básica é exibida como definida se todas as subcategorias da política de auditoria estendida correspondente estiverem instaladas. Se pelo menos um deles não estiver instalado, a política será exibida como não instalada.
Exemplo 3Usando o
auditpol /set /category:* , o
auditpol /set /category:* define todas as subcategorias de auditoria como Audit Success Mode. Além disso, se você for para as "Políticas básicas de auditoria" do snap-in "Políticas locais de segurança", uma Auditoria de sucesso será instalada em frente a cada categoria.
Exemplo 4Agora, o administrador
auditpol /clear comando
auditpol /clear e redefiniu todas as configurações de auditoria. Ele então configurou a auditoria do sistema de arquivos executando
auditpol /set /subcategory:" " . Agora, se você for para o "Políticas básicas de auditoria" do snap-in "Políticas de segurança local", todas as categorias serão definidas no estado "Sem auditoria", pois nenhuma categoria da política de auditoria estendida está totalmente definida.
Agora, finalmente, podemos responder à pergunta de onde vêm os logs no sistema operacional recém-instalado. O problema é que, após a instalação, a auditoria no Windows é configurada e definida nas configurações de auditoria salvas. Você pode verificar isso executando o
auditpol /get /category:* .
No snap-in Diretivas Básicas de Auditoria do Diretório de Segurança Local, essas informações de auditoria não são exibidas, pois uma ou mais subcategorias não estão definidas em todas as categorias. No snap-in Diretivas Avançadas de Auditoria do Diretório de Segurança Local, essas informações não são exibidas porque o snap-in funciona apenas com as configurações de auditoria armazenadas no arquivo% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv.
Qual é a essência do problema?
A princípio, pode parecer que tudo isso não é um problema, mas não é. O fato de todas as ferramentas mostrarem os parâmetros de auditoria de maneiras diferentes cria a oportunidade de manipulação maliciosa de políticas e, como resultado, resultados de auditoria.
Considere o cenário provávelDeixe uma estação de trabalho tecnológica baseada no Windows 7 funcionar na rede corporativa.
A máquina não está incluída no domínio e executa as funções de um robô que envia relatórios diariamente às autoridades reguladoras. Os invasores, de uma forma ou de outra, têm acesso remoto a ele com direitos de administrador. Ao mesmo tempo, o principal objetivo dos invasores é a espionagem, e a tarefa é permanecer sem ser detectada no sistema. Os invasores decidiram secretamente que não deveria haver eventos com o código
4719 "Alterações na
política de auditoria" no log de segurança, para desativar a auditoria de acesso a arquivos, mas ao mesmo tempo em que todas as ferramentas administrativas dizem que a auditoria está ativada. Para realizar a tarefa, eles executaram as seguintes ações:
- Na estação de trabalho atacada, eles concederam permissões de gravação à chave de registro HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv e exportaram essa chave para um arquivo chamado "+ fs.reg".
- Importamos esse arquivo em outro computador, reinicializamos e desativamos a auditoria do sistema de arquivos usando o auditpol, após o qual exportamos a chave de registro acima para o arquivo "-fs.reg".
- Na máquina atacada, o arquivo "-fs.reg" foi importado para o registro.
- Fizemos backup do arquivo% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv localizado na máquina atacada e, em seguida, removemos a subcategoria Sistema de Arquivos.
- Eles reinicializaram a estação de trabalho atacada e substituíram o arquivo% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv por uma cópia de backup salva anteriormente e também importaram o arquivo "+ fs.reg"
Como resultado de todas essas manipulações, não há entradas de alteração de política no log de segurança, todas as ferramentas mostram que a auditoria está ativada, mas, na verdade, não funciona.
Problema nº 2. Log de operações malsucedidas para excluir arquivos, diretórios e chaves do Registro
O problema foi confirmado no Windows 7/10 / Server 2019.Descrição do problema
Para uma operação excluir um arquivo, diretório ou chave do registro, o sistema operacional gera uma sequência de eventos com os códigos
4663 e
4660 . O problema é que, em todo o fluxo de eventos, esse casal não é tão fácil de se conectar. Para isso, os eventos analisados devem ter os seguintes parâmetros:
Evento 1. Código 4663 "Foi feita uma tentativa de obter acesso ao objeto." Parâmetros do evento:
"ObjectType" = Arquivo.
"ObjectName" = nome do arquivo ou diretório a ser excluído.
"HandleId" = identificador para o arquivo a ser excluído.
“AcessMask” = 0x10000 (este código corresponde à operação DELETE. Você pode encontrar a descriptografia de todos os códigos de operação
no site da Microsoft ).
Evento 2. Código 4660 "Objeto excluído".Parâmetros do evento:
"HandleId" = "Eventos HandleId 1"
"System \ EventRecordID" = "System \ EventRecordID do evento 1" + 1.
Com a remoção da chave do registro (chave), tudo fica igual, apenas no primeiro evento com o código 4663, o parâmetro "ObjectType" = Chave.
Observe que a remoção de valores no registro é descrita por outro evento (código
4657 ) e não causa esses problemas.
Recursos de exclusão de arquivos no Windows 10 e Server 2019
No Windows 10 / Server 2019, existem duas maneiras de excluir um arquivo.
- Se o arquivo for excluído para a lixeira, então, como antes, a sequência de eventos 4663 e 4660.
- Se o arquivo for excluído permanentemente (após a lixeira), em seguida, com um único evento com o código 4659 .
Aconteceu uma coisa estranha. Se antes, para determinar os arquivos excluídos, era necessário monitorar a totalidade dos eventos 4663 e 4660, agora a Microsoft “foi conhecer usuários” e, em vez de dois eventos, agora precisamos monitorar três. Também é importante notar que o procedimento para excluir diretórios não foi alterado, pois, como antes, consiste em dois eventos 4663 e 4660.
Qual é a essência do problema?
O problema é que descobrir quem excluiu o arquivo ou diretório se torna uma tarefa não trivial. Em vez de procurar banalmente o evento correspondente no log de segurança, é necessário analisar a sequência de eventos, o que é bastante trabalhoso fazer manualmente. No habr, mesmo sobre isso, havia um artigo:
"Auditando a remoção e acesso a arquivos e registrando eventos em um arquivo de log usando o Powershell" .
Problema número 3 (crítico). Registro malsucedido da operação de renomeação de arquivos, diretórios e chaves do Registro
O problema foi confirmado no Windows 7/10 / Server 2019.Descrição do problema
Esse problema possui dois subproblemas:
- Nos eventos gerados pelo sistema durante a renomeação, o novo nome do objeto não é corrigido em nenhum lugar.
- O procedimento de renomeação é muito semelhante à exclusão. Só pode ser distinguido pelo fato de o primeiro evento com o código 4663, com o parâmetro "AcessMask" = 0x10000 (DELETE) , não possuir o evento 4660.
Vale ressaltar que, com relação ao registro, esse problema se aplica apenas a chaves. A renomeação de valores no registro é descrita por uma sequência de eventos 4657 e não causa essas reclamações, embora, é claro, seria muito mais conveniente se houvesse apenas um evento.
Qual é a essência do problema?
Além da dificuldade de procurar operações de renomeação de arquivos, esse recurso do diário não permite rastrear o ciclo de vida completo dos objetos do sistema de arquivos ou chaves do registro. Como resultado, torna-se extremamente difícil determinar o histórico de um arquivo que foi renomeado várias vezes em um servidor de arquivos usado ativamente.
Problema número 4 (crítico). Não foi possível rastrear a criação de diretório e chave de registro
O problema foi confirmado no Windows 7/10 / Server 2019.Descrição do problema
O Windows não controla a criação de um diretório do sistema de arquivos e uma chave do Registro. Isso consiste no fato de o sistema operacional não gerar um evento que contenha o nome do diretório ou da chave do registro criado e cujos parâmetros indicariam que esta é a operação de criação.
Teoricamente, por sinais indiretos, é possível o fato de criar um catálogo. Por exemplo, se ele foi criado através do "Explorer", durante o processo de criação, serão gerados eventos de pesquisa para os atributos do novo diretório. O problema é que, se você criar um diretório por meio do comando
mkdir , nenhum evento será gerado. O mesmo se aplica à criação de chaves no registro.
Qual é a essência do problema?
Esse problema dificulta a investigação de incidentes de segurança da informação. Não há explicação razoável para o fato de que essas informações não são registradas nos periódicos.
Problema número 5 (crítico). Configurações de auditoria incorretas nas versões russas do Windows
A presença do problema é confirmada nas edições russas do Windows 7/10 / Server 2019.Descrição do problema
Há um erro nas versões russas do Windows que torna o sistema de gerenciamento de auditoria de segurança inoperante.
Sintomas
A alteração das políticas de segurança avançadas não afeta as configurações efetivas de auditoria ou, em outras palavras, as políticas não são aplicadas. Por exemplo, o administrador ativou a subcategoria "Logon", reinicializou o sistema, executa o
auditpol /get /category:* e essa subcategoria permanece
auditpol /get /category:* . O problema é relevante para computadores de domínio gerenciados por meio de políticas de grupo e computadores não pertencentes a domínio gerenciados usando um GPO local configurado por meio do snap-in Políticas de Segurança Local.
Razões
O problema surge se o administrador tiver ativado pelo menos uma das subcategorias "com falha" das políticas de auditoria avançadas. Tais categorias com falha, em particular, incluem:
- Uso de direitos -> Audite o uso de direitos que afetam dados confidenciais. GUID: {0cce9228-69ae-11d9-bed3-505054503030}.
- Uso de direitos -> Audite o uso de direitos que não afetam dados confidenciais. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
- Acesso a objetos -> Auditar eventos criados por aplicativos. GUID: {0cce9222-69ae-11d9-bed3-505054503030}.
Recomendações para resolver o problema
Se o problema ainda não ocorreu, não ative as subcategorias indicadas "com falha". Se os eventos dessas subcategorias forem muito necessários, use o utilitário auditpol para ativá-los ou gerenciar a auditoria usando políticas básicas.
Se ocorrer um problema, você deve:
- No diretório de diretivas de grupo de domínio, exclua o arquivo \ Machine \ microsoft \ windows nt \ Audit \ audit.csv
- Em todos os computadores com problemas de auditoria, exclua os arquivos:% SystemRoot% \ security \ audit \ audit.csv,% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv
Qual é a essência do problema?
A presença desse problema reduz o número de eventos de segurança que podem ser monitorados regularmente por meio de políticas de auditoria avançadas e também cria ameaças para desconectar, bloquear e desestabilizar o gerenciamento do sistema de auditoria na rede corporativa.
Problema número 6 (crítico). Droga "Novo texto document.txt ... e também Novo bitmap.bmp"
O problema foi confirmado no Windows 7. O problema está ausente no Windows 10 / Server 2019.Descrição do problema
Este é um problema muito estranho que foi descoberto por acidente. A essência do problema é que o sistema operacional possui uma brecha que permite ignorar a auditoria de criação de arquivos.
Parte preparatória:- Faça um Windows 7 instalado recentemente.
- Redefina todas as configurações de auditoria usando o comando
auditpol /clear . Este item é opcional e serve apenas para a conveniência de analisar revistas. - Configuramos a auditoria do sistema de arquivos executando
auditpol /set /subcategory:" " . - Vamos criar o diretório C: \ TEST e atribuir parâmetros de auditoria para a conta "Tudo": "Criar arquivos / gravar dados", "Criar pastas / gravar dados", "Escrever atributos", "Escrever atributos", "Escrever atributos adicionais", "Excluir subpastas e arquivos ”,“ Excluir ”,“ Alteração de permissões ”,“ Alteração de propriedade ”, ou seja, tudo relacionado à gravação de dados no sistema de arquivos.
Para maior clareza, antes de cada experimento, limparemos o log de segurança do sistema operacional.
Experiência 1.Nós fazemos:Na linha de comando, execute o comando:
echo > "c:\test\ .txt"Observamos:Após a criação do arquivo, um evento com o código 4663 apareceu no log de segurança, contendo o nome do arquivo sendo criado no campo "ObjectName" e 0x2 no campo "AccessMask" ("Gravando dados ou adicionando um arquivo").
Para executar as seguintes experiências, limpamos a pasta e o log de eventos.
Experiência 2.Nós fazemos:Abra a pasta C: \ TEST através do Explorer e use o menu de contexto "Criar -> Documento de Texto", chamado clicando com o botão direito do mouse, crie o arquivo "New Text Document.txt".
Observamos:Esta ação não foi refletida no log de eventos !!! Além disso, não haverá entradas se você usar o mesmo menu de contexto para criar um "Bitmap".
Experiência 3.Nós fazemos:Usando o Explorer, abra a pasta C: \ TEST e, no menu de contexto "Criar -> Documento no formato RTF", chamado clicando com o botão direito do mouse, crie o arquivo "Novo documento no formato RTF.rtf".
Observamos:Como no caso da criação do arquivo por meio da linha de comando, um evento com o código 4663 e o conteúdo correspondente apareceu no log.
Qual é a essência do problema?
Obviamente, criar documentos de texto ou imagens não é particularmente prejudicial. No entanto, se o "Explorer" puder ignorar o log de operações de arquivo, o malware poderá fazer isso.
Esse problema é talvez o mais significativo de todos os considerados, pois prejudica seriamente a credibilidade dos resultados da auditoria das operações de arquivo.
Conclusão
A lista de problemas acima não é exaustiva. No processo, conseguimos encontrar um número ainda bastante grande de várias falhas menores, que incluem o uso de constantes localizadas como valores de parâmetros para vários eventos, o que nos obriga a escrever nossos scripts de análise para cada localização do sistema operacional, a divisão ilógica dos códigos de eventos em operações com significado próximo. por exemplo, excluir uma chave do registro é uma sequência de eventos 4663 e 4660 e excluir um valor no registro é 4657, bem, e até as pequenas coisas ...
Para ser sincero, observamos que, apesar de todas as deficiências, o sistema de registro de eventos de segurança no Windows tem um grande número de aspectos positivos. Corrigir os problemas críticos listados aqui pode devolver a coroa a uma solução melhor para registrar eventos de segurança imediatamente.
FAÇA O LOGIN DE EVENTOS DE SEGURANÇA DO WINDOWS NOVAMENTE!