Infra - Segurança
Perícia Computacional: Análise e Integridade de Logs em Sistemas Windows
Neste documento, abordamos como sistemas Microsoft podem funcionar com autênticas testemunhas, delatando atividades de usuários envolvendo sistema, acesso a objetos e manipulação de aplicativos.
por José Antonio MilagreI – INTRODUÇÃO (ACTIVE DIRECTORY E EXCHANGE SERVER)
Neste documento, abordamos como sistemas Microsoft podem funcionar com autênticas testemunhas, delatando atividades de usuários envolvendo sistema, acesso a objetos e manipulação de aplicativos. Evidentemente que não esgotamos o assunto, e nos limitamos a apresentar o funcionamento dos logs em sistemas Home Edition. Pela lógica, Servers serão capazes de processar e armazenar uma infinidade de logs, como Active Directory, Microsoft Exchange, etc.
O Active Directory é uma implementação de serviços de diretório Microsoft, concorrente do Samba, cujos arquivos de logs, por padrão, ficam armazenados em C:\Windows\NTDS, sendo eles
- [1]
Arquivos de logs do Exchange Server 2007: Extraída do Site do Consultor Anderson Patrício
O Exchange 2003, permite a visualização de seus logs no “Event Viewer” onde é possível filtrar, dentre logs de Aplicação e Logs de Sistema, por atos específicos, como por exemplo, a gravação de todas a atividade SMTP (porta 25).[2]
Em síntese, não é objetivo deste artigo analisar os logs de serviços específicos, como de Servidores Exchange ou Active Directory, mas demonstrar como se dá a habilitação, monitoramento e preservação de logs em ambientes Windows convencionais.
II – HABILITANDO OS LOGS NO WINDOWS.
No nosso exemplo, selecionamos somente a Auditoria a objetos, que registra os acessos e modificações realizadas pelo usuário em um objeto como por exemplo, uma impressora, uma pasta, arquivo, chave.reg, etc.
Tal informação pode ser determinante em uma perícia, quando o escopo é saber quem criou ou excluiu arquivos em um disco rígido, quem obteve acesso, ou até mesmo quem utilizou determinado dispositivo de armazenamento e impressora..
III – ESCOLHENDO O QUE SERÁ AUDITADO
Na Etapa anterior, apenas informamos ao sistema que desejamos a Auditoria de Acesso a Objetos. Porém ainda, nossas atuações no sistema não estão sendo fiscalizadas, é preciso que especifiquemos qual unidade ou dispositivo desejamos auditar.
Podemos então clicar com o botão direito em qualquer dispositivo ou pasta. Na janela que surgir, clicamos da guia Segurança e após em Avançado. Na janela que aparecer, clicamos na aba Auditoria e lá iremos definir as configurações sobre “quem” e “quais atividades deste alguém” queremos auditar:
Deve-se destacar que se existir algum registro em “Entradas de Auditoria”, isto significa que algum objeto pai está sendo auditado, como por exemplo um disco rígido, no qual a pasta que queremos definir auditoria foi criada. Isso não impede porém que criemos uma modalidade de autoria específica para o objeto filho, basta desmarcarmos a opção da herança, “Herdar do pai as entradas de auditoria aplicáveis a objeto filho. Incluí-las nas entradas explicitamente definidas aqui”.
No nosso exemplo, criamos uma pasta “Arquivos” na raiz, e pretendemos auditar as alterações e exclusões de arquivos desta pasta, realizadas pelos usuários com poderes de Administração:
Clicando em “Ok” na aba “Auditoria”, finalizamos o processo de criação registros para atividades consideradas sensíveis na Política de Segurança da Empresa.
Em tal configuração, nos interessa conhecer arquivos criados, desviados ou excluídos pelos administradores.
IV – RASTRO DAS ATIVIDADES: CRIAÇÃO E EXCLUSÃO DE AQUIVO
Nesta etapa, efetivamente vamos praticar ações dentro da pasta “Arquivos”, que está sendo auditada pelo sistema. Neste cenário poderemos verificar como a auditoria se comporta diante destas ações. Para esta análise vamos utilizar o utilitário “Visualizar Eventos”, disponível em “Ferramentas Administrativas” no Painel de Controles.
Em nosso exemplo, apenas os Eventos de Segurança serão loggados. Antes de iniciarmos, iremos nos certificar de que não existem registros de logs lançados no sistema. Ao clicar com o botão direito sobre a opção “Segurança” podemos limpar os logs existentes.
Eventos de Segurança antes da Prática de Atividades na pasta Arquivos.
Agora na pasta “Arquivos”, existente na raiz do computador, vamos criar um arquivo (.doc), denominado milagre.doc. Após vamos observar o Visualizar Eventos:
Logs registrados quando da criação de um arquivo.
Como pudemos constatar, no mínimo 9 (nove) registros de logs são criados pelo sistema no simples ato de se criar um arquivo e o renomeá-lo para “milagre.doc”. Interessante notar que a função DELETE é interna ao Windows até mesmo quando o comando disparado é o simples “renomear”. Percebe-se também logs onde há chamada ao arquivo explorer.exe, responsável por processar os comandos emitidos pelo usuário.
Agora simulamos uma outra situação, onde por exemplo o fraudador poderia sobrescrever o arquivo real por um arquivo com “wipe” ou com um rootkit. Nesta simulação, copiamos o arquivo falso “milagre.doc” de um outro local do sistema, para a pasta “Arquivos”, e o seguinte Log de Sistema é gerado:
Log nos mostra de onde o arquivo falso se originou, o que pode ser útil na análise de tentativas de “queima de arquivo” ou técnicas anti-forensics.
Nos resta, então, analisar as hipóteses onde o usuário exclui definitivamente um arquivo. Ao executarmos o a exclusão do arquivo “milagre.doc”, na pasta “Arquivos”, previamente configurada para ser auditada, visualizamos a geração dos seguintes registros de logs:
Logs gerados quando da exclusão de um arquivo definitivamente
Interessante é que quando teclamos SHIFT+DEL sobre um arquivo e confirmamos a exclusão, efetivamente não temos noção do processo instaurado junto ao sistema operacional para que o arquivo realmente, desapareça do sistema de arquivos.
São 4 (quatro) passos para a exclusão de um arquivo, passos estes que ocorrem no mesmo segundo (01:06:36 hs), sendo:
· Evento 560: O objeto milagre.doc é aberto com a instrução “delete” que é processada pelo Windows
· Evento 567: A instrução “delete” é passada ao Explorer.exe, fazendo gerar um log de acesso ao arquivo “kernel” do Windows.
· Evento 564: O Explorer então exclui o objeto “milagre.doc”, gerando um ID identificador da tarefa e um ID identificador do processo de exclusão.
· Evento 562: O Explorer finaliza a tarefa acionada pelo evento 560.
Tudo isso na mesma fração de segundo!
Em síntese pudemos, com o presente trabalho, identificar as ações de um usuário determinado, inclusive a ação de exclusão de um arquivo, que nos gerou o seguinte registro, válido e registrado:
Tipo de evento: Auditoria com êxito
Fonte de evento: Security
Categoria do evento: Acesso a objetos
Id. do evento: 560
Data: 1/9/2008
Hora: 01:06:36
Usuário: OK\José Antonio
Computador: OK
Descrição:
Objeto aberto:
Servidor de objetos: Security
Tipo de objeto: File
Nome do objeto: C:\Arquivos\milagre.doc
Identificação do identificador: 3016
Identificação da operação: {0,5133200}
Identificação do processo: 1920
Nome do arquivo de imagem: C:\WINDOWS\explorer.exe
Nome de usuário primário: José Antonio
Domínio primário: OK
Identificação do logon primário: (0x0,0x1D9DB)
Nome de usuário cliente: -
Domínio do cliente: -
Identificação do logon do cliente: -
Acessos: DELETE
ReadAttributes
Privilégios: -
Contagem Sid restrita: 0
Para obter mais informações, visite o Centro de ajuda e suporte em http://go.microsoft.com/fwlink/events.asp.
V – OCULTANDO AS TESTEMUNHAS: SERVIDOR REMOTO DE LOGS
A máxima valoração da prova é um dos escopos do Perito Computacional, e neste cenário, deve-se ter em mente que o “evidential value” de logs computacionais podem ser máximos ou mínimos, sendo que tudo dependerá da forma em que eram custodiados, bem como da capacidade de se averiguar procedimentos de gestão que garantam autenticidade e integridade dos registros eletrônicos.
Neste contexto, instalações “default” de sistemas de logs ou livre acesso aos arquivos por outros usuários, são quesitos que são observados pelo judiciário e empresas, estes, pesando para que as provas obtidas pela análise dos logs se fragilizem.
Assim, a criação de um “servidor de logs remoto” é boa prática que atende os quesitos da IS0-IEC 27002, bem como favorece a atividade pericial. Todos os registros de logs da ferramenta “Event Viwer”, são salvos em 3 (três) arquivos: SysEvent.evt, AppEvent.evt, SecEvent.evt.
Por padrão, não existe opção “amigável” para alterar os locais onde estes arquivos são armazenados, o que favorece aos crackers a queima de evidências, na maioria dos sistemas existentes. A solução é alterar via Registro do Windows: Iniciar – Executar – Regedit.
Em System\CurrentControlSet\Services\EventLog\, é possível verificar os Diretórios envolvendo os logs de Aplicação, Segurança e Sistema. Ao Acessar os diretórios, basta alterar no painel da direita o valor File, como o endereço ou nome de rede para onde deseja armazenar os arquivos de log:
Valor “File” do Application Log, indicando onde os arquivos de log eram armazenados: %SystemRoot%\system32|config\AppEvent.Evt.
VI – CONCLUSÕES
Destaca-se que ambientes Windows também são capazes de gerar registro de atividades, no entanto, o perito deve atentar para indícios de finalização de auditoria e principalmente, observar os detalhes da máquina que está sob sua análise:
Registro de Evento de Segurança que informa que os serviços de Logging foram desativados
Em conclusão, a prática demonstra que servidores de Logs remotos e com autenticação controlada proporcionam provas robustas e com maior susceptibilidade de serem aceitas e consideradas em um processo cível ou criminal.
[1] http://www.linhadecodigo.com.br/Artigo.aspx?id=1926
