MODULE 09 - Investigating Web Attacks

Machine Translated by Google
MT
CE-Conselho
D FE
Digital Princípios Forenses
Fundamentos de Perícia Forense Digital Exame 112-53

Investigando ataques na Web
Objetivos do Módulo
1 Compreendendo a análise forense de aplicativos da Web
2 Noções básicas sobre os logs do Internet Information Services (IIS)
3 Compreendendo os logs do servidor Web Apache
4 Visão geral dos ataques da Web em servidores baseados em Windows
Compreendendo como detectar e investigar vários ataques em aplicativos da Web

5
Copyright © por EC-Council. Todos os direitos reservados. A reprodução é estritamente proibida.
Objetivos do Módulo
Os aplicativos da Web permitem que os usuários acessem seus recursos por meio de programas do lado do cliente, como
navegadores da Web. Alguns aplicativos da Web podem conter vulnerabilidades que permitem que criminosos cibernéticos
lancem ataques específicos de aplicativos, como SQL Injection, script entre sites, inclusão de arquivo local (LFI), injeção de
comando, etc., que causam danos parciais ou completos do subjacente
servidores.
Além disso, esses ataques contra aplicativos da Web podem levar a grandes danos financeiros e de reputação para as
organizações. Na maioria dos casos, as organizações não conseguem rastrear a causa raiz de um ataque, o que deixa brechas
de segurança para os invasores explorarem. É aqui que a análise forense de aplicativos da Web assume importância.
Este módulo discute o procedimento forense de aplicativos da web, vários tipos de ataques a servidores e aplicativos da web e
onde procurar evidências durante uma investigação.
Além disso, explica como detectar e investigar vários tipos de ataques baseados na web.
Ao final deste módulo, você será capaz de:
ÿ Compreender a análise forense de aplicativos da web
ÿ Compreender os Logs dos Serviços de Informações da Internet (IIS)
ÿ Entenda os logs do servidor web Apache
ÿ Investigar ataques da web em servidores baseados em Windows
ÿ Detectar e investigar vários ataques em aplicativos da web
Módulo 09 Página 504 Digital Forensics Essentials Copyright © por EC-Council

Todos os direitos reservados. A reprodução é estritamente proibida.

Fluxo do módulo
Entenda o IIS e o Apache Investigando ataques na Web em

Registros do Servidor Web
02 03 Servidores baseados em Windows
Detectar e Investigar
Entender Web
Análise forense de aplicativos
01 04 Vários ataques na Web
Formulários
Entenda a análise forense de aplicativos da Web

Os aplicativos da Web tornaram-se uma fonte primária de troca e gerenciamento de informações em várias
empresas e agências governamentais. Devido ao seu amplo uso, os aplicativos da Web estão se tornando os
principais alvos dos invasores.
Os profissionais de segurança da informação implementam medidas de segurança específicas para detectar ou

prevenir ataques a aplicativos da web. No entanto, eles não podem rastrear esses ataques, permitindo que os
invasores tentem novos ataques ao alvo. É aqui que a análise forense de aplicativos da Web ajuda a mitigar os
ataques que ocorrem nos aplicativos.
Um ramo da análise forense digital, a análise forense de aplicativos da Web envolve a investigação de um incidente
de segurança baseado na Web para localizar sua origem, como ocorreu e quais sistemas/dispositivos de computação
estavam envolvidos.
Esta seção define a análise forense de aplicativos da web e descreve a metodologia padrão que os investigadores
devem seguir ao investigar ataques de aplicativos da web. Ele também discute vários tipos de ameaças de
aplicativos da web e os sinais que indicam ataques a aplicativos da web.


Introdução à análise forense de aplicativos da Web
ÿ A análise forense de aplicativos da Web envolve o rastreamento de um ataque de segurança que ocorreu em qualquer aplicativo da Web
identificar sua origem, e como foi penetrado
ÿ Inclui a coleta e análise de log e arquivos de configuração associados ao servidor web,

servidor de aplicativos, servidor de banco de dados, eventos do sistema, etc. para determinar a causa, natureza e perpetrador de uma
exploração da web
Introdução à análise forense de aplicativos da Web
Aplicativos da Web são programas existentes em um servidor central que permitem que um usuário, que
visita um site pela Internet, envie e recupere dados de e para um banco de dados. Um cliente faz uma
solicitação a um servidor da Web por meio de um aplicativo da Web. Quando o servidor responde à requisição,
a aplicação web gera documentos da resposta para melhor atendimento ao cliente/usuário.
Os documentos da web gerados por aplicativos da web estão em um formato padrão, como Hypertext Markup
Language (HTML) e Extensible Markup Language (XML), que é suportado por todos os tipos de navegadores.
Os aplicativos da Web realizam a tarefa solicitada, independentemente do sistema operacional e do navegador
implantados pelo usuário. Apesar das vantagens dos aplicativos da Web, eles tendem a ser vulneráveis a
ataques devido a práticas inadequadas de codificação ou monitoramento de segurança. Os invasores tentam
explorar vulnerabilidades no código e obter acesso ao conteúdo do banco de dados, obtendo acesso a
informações confidenciais, como credenciais de usuário e detalhes de contas bancárias. Alguns tipos de
ataques executados em aplicativos da Web incluem injeção de SQL, XSS, sequestro de sessão, inclusões de
arquivos locais e remotos e execução remota de código.
A análise forense de aplicativos da Web assume proeminência quando esses tipos de ataques ocorrem em
aplicativos da Web. Envolve o exame forense de aplicativos da web e seu conteúdo (como logs, diretório www
e arquivos de configuração) para rastrear e identificar a origem do ataque, determinar como o ataque foi
propagado, juntamente com os dispositivos usados (dispositivos móveis e computadores ) e pessoas
envolvidas no ataque. Os investigadores examinam os logs e os arquivos de configuração associados ao
servidor, à rede e à máquina host para obter informações sobre o ataque.


Desafios na análise forense de aplicativos da Web
Devido à natureza distribuída dos aplicativos da Web, os rastros

de atividades são registrados em vários componentes de hardware
01
e software
Muito limitado ou nenhum tempo de inatividade é

permitido para investigação
02
A análise forense de aplicativos da Web requer a análise e a

correlação de grandes volumes de logs
03
Também requer conhecimento completo de diferentes servidores web,

servidores de aplicativos, bancos de dados e aplicativos 04
subjacentes
O rastreamento é difícil no caso de proxies reversos e

anonimizadores
05
Desafios na análise forense de aplicativos da Web
Devido à natureza distribuída dos aplicativos da Web, os rastros de atividades são registrados em vários
componentes de hardware e software. Os aplicativos da Web atendem a uma ampla variedade de serviços e
podem oferecer suporte a vários tipos de servidores, como IIS e Apache. Portanto, os investigadores forenses
devem ter um bom conhecimento de vários servidores para examinar os logs e entendê-los quando ocorrer um
incidente.
Os aplicativos da Web geralmente são críticos para os negócios. Portanto, é difícil para os investigadores criar
sua imagem forense, o que exige que o site fique fora do ar por algum tempo. Isso torna um desafio para os
investigadores capturar dados voláteis, incluindo processos, conexões de porta/rede, logs de dumps de memória
e logs de usuário no momento da análise do incidente. Por outro lado, à medida que o tráfego de sites aumenta,
os arquivos de log registrados no banco de dados continuam aumentando. Portanto, torna-se difícil para os
investigadores coletar e analisar esses logs.
Os investigadores devem ter uma boa compreensão de todos os tipos de servidores da Web e de aplicativos
para entender, analisar e correlacionar vários formatos de logs coletados de suas respectivas fontes. Quando
ocorre um ataque a um site, os investigadores devem coletar as impressões digitais deixadas pelo invasor. No
entanto, rastrear de volta se torna uma tarefa difícil, pois os invasores costumam usar proxies reversos e
anonimizadores. Os investigadores também precisam coletar os seguintes campos de dados associados a cada
solicitação HTTP feita ao site para entender como o ataque foi realizado:
ÿ Data e hora em que o pedido foi enviado

ÿ
Endereço IP a partir do qual a solicitação foi iniciada
ÿ Método HTTP usado (GET/POST)
ÿ Identificador Uniforme de Recursos (URI)


ÿ Consulta enviada via HTTP
ÿ Cabeçalhos HTTP
ÿ Corpo da solicitação HTTP
ÿ Logs de eventos (dados não voláteis)
ÿ
Listagens de arquivos e carimbos de data/hora (dados não voláteis)
A maioria dos aplicativos da Web restringe o acesso às informações HTTP. Sem isso, as informações registradas nos logs seriam bastante
semelhantes, o que poderia impossibilitar os investigadores de diferenciar as solicitações HTTP válidas das maliciosas.


Indicadores de um ataque na Web
Clientes impossibilitados de acessar

desfigurações de páginas da web
os serviços
Atividades suspeitas em contas Desempenho de rede

de usuário excepcionalmente lento
Vazamento de dados Reinicialização frequente

confidenciais do servidor
URLs redirecionando para sites incorretos
Indicadores de um ataque na Web
Existem diferentes componentes que indicam um ataque na web. Por exemplo, em um ataque DoS, é negado aos clientes
o acesso às informações ou serviços disponíveis no servidor web de destino. Nesses casos, os clientes relatam a
indisponibilidade de serviços online porque o invasor impede que usuários legítimos acessem sites e outros serviços que
dependem do servidor da Web visado.
Redirecionar um usuário em uma página da Web para um site desconhecido que hospeda um kit de exploração é outra
indicação de um ataque na Web. Quando um usuário insere a URL do site na barra de endereço, o servidor o redireciona
para um site desconhecido (muitas vezes malicioso), que instala spyware/malware na máquina do usuário.
O desempenho de rede excepcionalmente lento e a reinicialização frequente do servidor também podem indicar um
ataque na web. Anomalias encontradas nos arquivos de log também são uma indicação de ataques na web. A alteração
de uma senha e a criação de uma nova conta de usuário podem revelar as tentativas de ataque em sites.
Outros indicadores de ataques na web incluem vazamento de dados confidenciais e desfigurações de páginas da web.
Pode haver outros indicadores, como o retorno de mensagens de erro. Por exemplo, uma página de mensagem de erro
HTTP 500 pode indicar a ocorrência de um ataque de injeção SQL. Além disso, existem outras mensagens de erro, como
“um erro interno do servidor” e “problema ao processar sua solicitação”, que indicam um ataque na web.


Ameaças de aplicativos da Web

Script entre sites
01 Biscoito Envenenado 07 13 Vazamento de informações
(XSS)
Dados sensíveis Erro impróprio

02 Injeção SQL 08 14
Exposição Manuseio
Parâmetro/Forma
03 Falhas de Injeção 09 15 estouro de buffer
adulteração
Solicitação entre sites Registro e monitoramento

04 10 Negação de Serviço (DoS) 16
Falsificação insuficientes
05 Passagem de diretório 11 Controle de acesso quebrado 17 Autenticação quebrada
Segurança
06 Entrada não validada 12 18 Registro de adulteração
Configuração incorreta
Ameaças de aplicativos da Web
A maioria das violações de segurança ocorre em aplicativos da Web, e não em servidores da Web, pois os aplicativos
da Web podem conter bugs devido a problemas de codificação na fase de desenvolvimento. Consequentemente, os
aplicativos da Web estão sujeitos a vários tipos de ameaças, algumas das quais são descritas abaixo:
ÿ Intoxicação por Cookies
O envenenamento de cookies refere-se à modificação de um cookie para contornar medidas de segurança

ou obter acesso não autorizado a informações. Nesse tipo de ataque, os invasores contornam o processo
de autenticação alterando as informações presentes em um cookie. Depois que os invasores obtêm o
controle de uma rede, eles podem modificar seu conteúdo, usar o sistema para um ataque mal-intencionado
ou roubar informações dos sistemas dos usuários.
ÿ Injeção de SQL
Nesse tipo de ataque, o invasor injeta comandos SQL maliciosos ou consultas como dados de entrada. Isso
os ajuda a ignorar as medidas de segurança do aplicativo da web e recuperar conteúdo confidencial do
servidor de banco de dados.
ÿ Falhas de Injeção
As falhas de injeção são as vulnerabilidades de aplicativos mais comuns que permitem que dados não
confiáveis fornecidos pelo usuário sejam interpretados e executados como um comando ou consulta. Os
invasores injetam códigos, comandos ou scripts maliciosos nos portões de entrada de aplicativos da Web
defeituosos de forma que os aplicativos interpretem e executem com a entrada maliciosa recém-fornecida, o
que, por sua vez, permite que os invasores extraiam informações confidenciais.


Essas falhas de injeção são comumente encontradas em consultas SQL, NoSQL e LDAP, bem como em comandos
do sistema operacional. Falhas de injeção foram consideradas como a principal vulnerabilidade de segurança em
aplicativos da Web em 2017 pelo Open Web Application Security Project (OWASP).
ÿ Falsificação de Solicitação Cross Site
Nesse método de ataque, um usuário autenticado é obrigado a executar determinadas tarefas no aplicativo da Web
escolhido por um invasor. Por exemplo, um invasor pode fazer um usuário clicar em um determinado link enviado por
e-mail ou chat.
ÿ Passagem de caminho/diretório
Quando os invasores exploram o HTTP usando passagem de diretório, eles obtêm acesso não autorizado aos
diretórios, após o que podem executar comandos fora do diretório raiz do servidor da web.
ÿ Entrada Não Validada
Nesse tipo de ataque, os invasores adulteram a URL, solicitações HTTP, cabeçalhos, campos ocultos, campos de
formulário, strings de consulta etc. para contornar as medidas de segurança em um sistema. IDs de login do usuário
e outros dados relacionados são armazenados em cookies, que se tornam uma fonte de ataques.
Exemplos de ataques que causam entrada não validada incluem injeção de SQL, script entre sites (XSS) e estouros
de buffer.
ÿ Cross Site Scripting (XSS)
Nesse tipo de ataque, os invasores contornam os mecanismos de segurança do ID do cliente e obtêm privilégios de
acesso. Posteriormente, eles injetam os scripts maliciosos em campos específicos nas páginas da web. Esses scripts
XSS maliciosos podem reescrever o conteúdo HTML de um site, sequestrar sessões de usuários ou redirecionar
usuários para sites maliciosos e desfigurar sites. O XSS é uma das 10 principais vulnerabilidades de segurança de
aplicativos da web do OWASP para 2017.
ÿ Exposição de Dados Sensíveis
Informações confidenciais, como registros de contas, números de cartão de crédito, senhas ou outras informações
autenticadas geralmente são armazenadas por aplicativos da Web em um banco de dados ou em um sistema de
arquivos.
Se os desenvolvedores cometerem algum erro ao aplicar técnicas de criptografia em um aplicativo da Web ou

ignorarem os aspectos de segurança de algumas partes do aplicativo, os invasores podem facilmente explorar essas
falhas para obter acesso não autorizado a informações confidenciais.
Os dados confidenciais podem ser explorados e mal utilizados por pessoas de dentro e de fora para realizar roubo
de identidade, fraude de cartão de crédito e outros crimes cibernéticos. Essa ameaça está incluída nas 10 principais
vulnerabilidades de segurança do OWASP para 2017.
ÿ Tamperação de Parâmetros/Formas
Esse tipo de ataque de adulteração visa manipular os parâmetros de comunicação trocados entre um cliente e um
servidor para fazer alterações nos dados do aplicativo, como IDs de usuários e senhas com logs de eventos ou custo
e quantidade de produtos.


Para melhorar a funcionalidade e o controle do aplicativo, o sistema coleta essas informações e as armazena em
campos de formulário ocultos, cookies ou strings de consulta de URL.
Os hackers usam ferramentas como o proxy WebScarab e Paros para lançar esse tipo de ataque.
A exploração bem-sucedida pode levar a outros ataques, como inclusão de arquivo e XSS.
ÿ Negação de Serviço (DoS)
Um ataque de negação de serviço (DoS) visa encerrar as operações de um site ou servidor, tornando seus recursos
indisponíveis para os clientes.
Por exemplo, um ataque DoS pode interromper o funcionamento de um site relacionado a serviços bancários ou de
e-mail por algumas horas ou mesmo dias, resultando na perda de tempo e
dinheiro.
ÿ Controle de Acesso Quebrado
Este é um método no qual um invasor identifica uma falha nas políticas de controle de acesso e a explora para
contornar o mecanismo de autenticação. Isso permite que o invasor obtenha acesso a dados confidenciais, modifique
direitos de acesso ou opere contas de outros usuários. Esta é uma parte das 10 principais vulnerabilidades de
segurança do OWASP de 2017.
ÿ Má configuração de segurança
A falta de um processo de proteção de segurança repetível em qualquer camada da pilha de aplicativos, que inclui
servidores Web, bancos de dados, estruturas, sistemas operacionais host, servidores de aplicativos e dispositivos
de armazenamento, pode levar a uma vulnerabilidade de configuração incorreta de segurança.
O uso de configurações padrão, senhas ou software desatualizado pode aumentar o risco de um ataque. Isso está
incluído nas 10 principais vulnerabilidades de segurança do OWASP 2017.
ÿ Vazamento de Informações
O vazamento de informações refere-se a uma desvantagem em um aplicativo da Web em que o aplicativo revela
involuntariamente informações confidenciais a um usuário não autorizado. Tal vazamento de informações pode
trazer grandes prejuízos para uma empresa.
Portanto, a empresa precisa empregar mecanismos adequados de filtragem de conteúdo para proteger todas as
suas informações ou fontes de dados, como sistemas ou outros recursos de rede, contra vazamento de informações.
ÿ Tratamento Inadequado de Erros
Essa ameaça surge quando um aplicativo da Web não consegue lidar com erros internos adequadamente. Nesses
casos, o site retorna informações, como despejos de banco de dados, rastreamentos de pilha e códigos de erro, na
forma de erros.
ÿ Estouro de Buffer
O estouro de buffer de um aplicativo da Web ocorre quando ele falha em proteger seu buffer adequadamente e
permite a gravação além de seu tamanho máximo. Assim, ele sobrescreve os locais de memória adjacentes. Existem
várias formas de estouro de buffer, incluindo estouros de buffer de heap


e formatar ataques de string. O objetivo desses ataques é corromper a pilha de execução do aplicativo da web.
ÿ Registro e monitoramento insuficientes
Os arquivos de log mantêm registros das ações e eventos que ocorrem durante a execução de um aplicativo/
serviço. Essa vulnerabilidade ocorre quando os logs não registram eventos críticos de segurança ou fornecem
avisos ou mensagens de erro pouco claros.
A falta de monitoramento de log ou a manutenção de logs em locais inseguros aumenta muito a chance de um
grande incidente de segurança.
Além disso, práticas insuficientes de registro e monitoramento não deixam rastros de auditoria para análise
forense, tornando a detecção de qualquer comportamento malicioso extremamente difícil para os investigadores
forenses. É uma das 10 principais vulnerabilidades de segurança de aplicativos da Web do OWASP de 2017.
ÿ Autenticação quebrada
Os invasores exploram falhas de implementação nas funções de autenticação e gerenciamento de sessão de

um aplicativo da Web para obter privilégios administrativos ou representar outros usuários. Áreas vulneráveis
comuns incluem tempo limite, perguntas secretas e gerenciamento de senhas. A autenticação quebrada é uma
das 10 principais vulnerabilidades de segurança de aplicativos da web do OWASP para 2017.
ÿ Adulteração de Registros
Os aplicativos da Web mantêm logs para rastrear os padrões de uso, como credenciais de login do
administrador e credenciais de login do usuário. Os invasores geralmente injetam, excluem ou adulteram os
logs de aplicativos da web para se envolver em atividades maliciosas ou ocultar suas identidades.
ÿ Referências inseguras de objetos diretos
Uma referência de objeto direta insegura ocorre quando os desenvolvedores expõem vários objetos de
implementação interna, como arquivos, diretórios, registros de banco de dados e referências de chave. Por
exemplo, se o número de uma conta bancária for uma chave primária, existe a possibilidade de invasores
comprometerem o aplicativo e se aproveitarem dessas referências.
ÿ Proteção insuficiente da camada de transporte
Os desenvolvedores precisam aplicar a tecnologia Secure Sockets Layer (SSL)/Transport Layer Security (TLS)
para autenticação de sites. Deixar de implementar essa tecnologia permite que invasores acessem cookies de
sessão monitorando o fluxo da rede. Vários ataques, como ataques de phishing, roubo de conta e
escalonamento de privilégios, podem ocorrer depois que os invasores obtêm acesso aos cookies.
ÿ Falha em Restringir o Acesso à URL
Um aplicativo geralmente protege ou protege funcionalidades confidenciais e impede a exibição de links ou

URLs para proteção. A falha em restringir o acesso à URL refere-se a uma vulnerabilidade na qual um
aplicativo da Web não consegue impedir que um hacker acesse uma determinada URL.


Aqui, um invasor tenta contornar a segurança do site usando técnicas como navegação forçada e obtém acesso não
autorizado a páginas da Web específicas ou outros arquivos de dados que contêm informações confidenciais.
ÿ Armazenamento criptográfico inseguro ou impróprio
Os dados confidenciais armazenados em um banco de dados devem ser criptografados adequadamente usando criptografia.
No entanto, alguns métodos de criptografia criptográfica contêm vulnerabilidades inerentes.
Portanto, os desenvolvedores devem usar métodos de criptografia fortes para desenvolver aplicativos seguros.
Além disso, eles devem armazenar com segurança as chaves criptográficas para que os invasores não possam obtê-las
facilmente e descriptografar os dados confidenciais.
ÿ Desserialização Insegura
A serialização e a desserialização são processos eficazes que permitem que as estruturas de dados sejam armazenadas ou
transmitidas para outros locais, como redes ou sistemas, preservando o estado do objeto.
A vulnerabilidade de desserialização insegura surge quando aplicativos e interfaces de programação de aplicativos (APIs)
permitem a desserialização de entrada de usuário não confiável.
Os invasores injetam código malicioso em uma forma serializada de dados e, após a desserialização, os dados manipulados,
bem como o código malicioso, são executados, permitindo que os invasores obtenham acesso remoto a qualquer sistema e
executem outras atividades maliciosas. Este ataque é uma das 10 principais vulnerabilidades de segurança de aplicativos da
Web de 2017 da OWASP.
ÿ Bisbilhotice de Cookies
Ao usar um proxy local, um invasor pode decodificar ou quebrar as credenciais do usuário. Depois que o invasor obtém
essas credenciais de texto sem formatação, ele faz login no sistema como um usuário legítimo e obtém acesso a informações
não autorizadas.
ÿ Entidades Externas XML
Nesse ataque, o invasor fornece uma entrada XML maliciosa, incluindo uma referência de entidade externa ao aplicativo da
Web de destino. Quando essa entrada maliciosa é processada por um analisador XML mal configurado, os invasores podem
acessar arquivos de dados confidenciais e recursos de rede de servidores Web de destino e redes conectadas. Este ataque
é uma das 10 principais vulnerabilidades de segurança de aplicativos da web do OWASP para 2017.
ÿ Explorações de gerenciamento de segurança
Alguns invasores têm como alvo os sistemas de gerenciamento de segurança, seja em redes ou na camada de aplicativos,
para modificar ou desabilitar a aplicação da segurança. Um invasor que explora o gerenciamento de segurança pode
modificar diretamente as políticas de proteção, excluir políticas existentes, adicionar novas políticas e modificar aplicativos,
dados do sistema e recursos.
ÿ Sequestro de Autenticação
Todos os aplicativos da web dependem de informações como senhas e IDs de usuário para identificação do usuário. Nesse
tipo de ataque, os invasores tentam sequestrar essas credenciais usando


várias técnicas de ataque, como sniffing e engenharia social. Ao obter essas credenciais, eles executam vários atos
maliciosos, incluindo sequestro de sessão, roubo de serviço e representação de usuário.
ÿ Redirecionamentos e Encaminhamentos Não Validados
Nesse tipo de ataque, os invasores atraem a vítima e a fazem clicar em links não validados que parecem legítimos. Esses
redirecionamentos podem levar à instalação de malware ou induzir as vítimas a compartilhar suas senhas ou outras
informações confidenciais.
Esses links inseguros podem levar ao desvio do controle de acesso, o que resulta ainda no seguinte:
o Ataques de fixação de sessão
o Explorações de gerenciamento de segurança
o Falha ao restringir o acesso à URL
o Execução de arquivo malicioso
ÿ Ataque de Fixação de Sessão
Esse tipo de ataque auxilia o invasor a sequestrar uma sessão válida do usuário. O invasor sequestra a sessão validada
pelo usuário, com conhecimento prévio do ID do usuário para a sessão, autenticando com um ID de sessão conhecido.
Nesse tipo de ataque, o invasor engana o usuário para que ele acesse um servidor Web genuíno usando um valor de ID de
sessão explícito. Posteriormente, o invasor assume a identidade da vítima e explora essas credenciais no servidor.
As etapas envolvidas são as seguintes:
1. O invasor visita o site do banco e faz login usando suas credenciais
2. O servidor web define um ID de sessão na máquina do invasor
3. O invasor envia um e-mail para a vítima contendo um link com um ID de sessão fixo
4. A vítima clica no link e é redirecionada para o site do banco
5. A vítima faz login no servidor usando suas credenciais e ID de sessão fixa
6. O invasor faz login no servidor usando as credenciais da vítima com a mesma sessão
EU IA
ÿ Ataques CAPTCHA
A implementação de CAPTCHAs evita que softwares automatizados executem ações que degradem a qualidade do serviço
de um determinado sistema por meio de abuso ou gasto excessivo de recursos. Os CAPTCHAs visam garantir que os
usuários dos aplicativos sejam humanos e, em última análise, ajudam a prevenir o acesso não autorizado e o abuso.
Cada implementação CAPTCHA obtém sua força aumentando a complexidade do sistema para realizar segmentação, pré-
processamento de imagem e classificação.


Metodologia de Investigação de Ataques na Web
Realizar entrevistas individuais para obter Use criptografia e soma de verificação para
1 informações
5
verificar e proteger a integridade dos arquivos de log
Localize os servidores ou outros dispositivos envolvidos Analise as cópias de trabalho dos logs coletados
no ataque de segurança, coloque-os offline e execute para procurar entradas suspeitas e correlacionar
2 6 os dados para criar uma cadeia de eventos que
a apreensão de maneira forense
revela todo o cenário de ataque
Acompanhe o processo de aquisição e Rastreie o IP do ataque para identificar

3 7
duplicação de imagens forenses o autor do ataque
Colete logs do servidor da web, servidor de aplicativos,

servidor de banco de dados, firewall de aplicativos da web,
4 8 Documente cada etapa da investigação
eventos do sistema local, ferramenta SIEM e IDS, junto com
arquivos de configuração do aplicativo e do servidor
Metodologia de investigação de ataques na Web A
adesão a uma metodologia de investigação completa e padrão desempenha um papel crucial na análise forense de
aplicativos da Web. Quando houver suspeita da ocorrência de um incidente de segurança em qualquer aplicativo da
web, os investigadores devem tentar coletar todos os arquivos de log disponíveis, como logs do servidor da web, logs
coletados pelo SIEM, logs do firewall de aplicativo da web (WAF) e logs de eventos, e analisá-los para rastrear as
assinaturas de ataque. Isso pode ajudar os investigadores a reconstruir a cadeia de eventos que levou ao ataque.
As etapas envolvidas na investigação de ataques na web estão listadas abaixo:
ÿ Realizar entrevistas individuais para obter informações sobre um ataque de segurança visando qualquer
aplicação web
ÿ Localize os servidores ou outros dispositivos que estão envolvidos no ataque de segurança, leve-os
offline e realizar a apreensão de maneira forense
ÿ Acompanhar o processo de aquisição e duplicação de imagens forenses ÿ Coletar
logs do servidor web, servidor de aplicativos, servidor de banco de dados, firewall de aplicativos web, eventos do
sistema local, ferramenta SIEM e IDS, juntamente com arquivos de configuração de aplicativos e servidores
ÿ Use criptografia e soma de verificação para verificar e proteger a integridade dos arquivos de log
ÿ Analisar as cópias de trabalho dos logs coletados para procurar entradas suspeitas e correlacionar
os dados para construir uma cadeia de eventos desdobrando todo o cenário de ataque
ÿ Rastreie o IP do ataque para identificar o perpetrador do ataque. Essa tarefa geralmente é muito difícil, pois os
invasores costumam usar proxies e anonimizadores para ocultar sua identidade.
ÿ Documentar todas as etapas da investigação; tal documentação é essencial para qualquer

procedimentos


Fluxo do módulo

Entender Web
Formulários
Entenda os logs do IIS e Apache Web Server

Os administradores podem ativar o logon em um servidor da Web IIS para registrar informações sobre
solicitações/erros HTTP para seus aplicativos/sites. No caso de uma violação de segurança, coletar e analisar
logs do IIS pode fornecer informações sobre como e de onde ocorreu o ataque.
Os logs do servidor web Apache, quando ativados, registram informações sobre cada solicitação HTTP (GET/
POST), bem como quaisquer erros/problemas encontrados pelo servidor web Apache.
Esta seção discute a arquitetura do servidor web IIS, o formato de log IIS e como analisar esses logs durante a
investigação. Esta seção também discute a arquitetura do servidor web Apache, tipos de logs Apache e como
os investigadores podem analisá-los no momento da investigação.


Arquitetura do Servidor Web IIS
Informações da Internet
Cliente Pilha
Serviços (IIS) para Windows
Server é um servidor web flexível,
Pilha de
seguro e fácil de gerenciar para
Internet protocolo HTTP (HTTP.SYS)hospedar qualquer coisa na web
svchost.exe Pool de aplicativos
Serviço de ativação do Windows

(ERA)
Núcleo do Servidor Web Módulos nativos Domínio do aplicativo
Serviço WWW
Iniciar processamento de solicitação, Autenticação
Gerenciou
autenticação, autorização, resolução anônima,
Módulos
de cache, mapeamento do mecanismo gerenciado,
manipulador, pré-execução do mapeamento de
Aplicativos externos manipulador, estado de liberação, certificado IIS , arquivo Forma
atualização do cache, atualização
estático, documento padrão, cache HTTP, Autenticação
do log e finalização do processamento Erros de HTTP e registro
Aplicativo da solicitação
de HTTP
Host.config
Arquitetura do Servidor Web IIS
Figura 9.1: Arquitetura do servidor web IIS
O Internet Information Services (IIS), um aplicativo desenvolvido pela Microsoft baseado no Visual Basic, é executado
em um servidor Web e responde a solicitações de um navegador. Ele suporta HTTP, HTTP Secure (HTTPS), File
Transfer Protocol (FTP), FTP Secure (FTPS), Simple Mail Transfer Protocol (SMTP) e Network News Transfer
Protocol (NNTP). Um aplicativo IIS usa HTML para apresentar sua interface de usuário e usa código Visual Basic
compilado para processar solicitações e responder a eventos no navegador. O servidor IIS para Windows é um
servidor da Web flexível e fácil de gerenciar para hospedagem na Web.


O IIS inclui os seguintes componentes:
ÿ Ouvintes de protocolo (conhecidos como HTTP.sys)
ÿ World Wide Web Publishing Service (conhecido como serviço WWW)
ÿ Serviço de Ativação de Processos do Windows (WAS)
As responsabilidades dos componentes do IIS incluem o seguinte:
ÿ Escuta dos pedidos vindos do servidor
ÿ Gerenciamento de processos
ÿ Leitura de arquivos de configuração
Como funcionam os componentes do servidor IIS 10.0
ÿ Quando uma solicitação HTTP para um recurso é enviada do navegador do cliente para o servidor web, ela é interceptada
por HTTP.sys
ÿ HTTP.sys se comunica com WAS para coletar dados de ApplicationHost.config, a raiz

arquivo no sistema de configuração no servidor web IIS
ÿ O WAS gera uma solicitação de informações de configuração, como as do site e do pool de aplicativos, para
ApplicationHost.config, que é então passado para o Serviço WWW.
ÿ WWW Service utiliza as informações de configuração obtidas para configurar HTTP.sys
ÿ Um processo de trabalho é iniciado pelo WAS para o pool de aplicativos no qual a solicitação é
destinado a
ÿ O pedido é então processado pelo processo do trabalhador, e a resposta é devolvida ao

HTTP.sys
ÿ O navegador do cliente recebe uma resposta
O IIS depende principalmente de um grupo de bibliotecas de vínculo dinâmico (DLLs) que trabalham coletivamente com o
processo principal do servidor (inetinfo.exe) capturando diferentes funções, como indexação de conteúdo, scripts do lado do
servidor e impressão baseada na web.
A arquitetura aberta do IIS permite que um invasor explore a Web com conteúdo malicioso.
Sem service packs ou hot fixes no servidor da Web IIS, há várias maneiras pelas quais um invasor pode fazer com que o
inetinfo.exe, o processo do IIS, chame o shell de comando. Isso deve levantar suspeitas, pois não há necessidade inerente de
inetinfo.exe invocar o prompt de comando.


Registros do IIS
ÿ O IIS registra todas as visitas do servidor em arquivos

de log
ÿ Os logs do IIS fornecem

informações sobre a atividade de vários
aplicativos da web, como o cliente
Endereço IP, nome de usuário, data e hora, tipo
de solicitação e destino da operação
ÿ O servidor IIS gera arquivos de log baseados em
texto ASCII
ÿ Em sistemas operacionais Windows Server, o

arquivos de log são armazenados por padrão em
%SystemDrive%
\inetpub\logs\LogFiles
Registros do IIS
O IIS registra todas as visitas do servidor em arquivos de log. Os logs do IIS fornecem informações úteis sobre a
atividade de vários aplicativos da Web, como endereço IP do cliente, nome de usuário, data e hora, tipo de solicitação e
destino da operação. O servidor IIS gera arquivos de log baseados em texto ASCII. O servidor IIS pode se tornar
vulnerável se houver algum problema de codificação ou configuração, o que pode permitir que invasores explorem o
servidor se não forem resolvidos a tempo. Na ocorrência de tais ataques, os investigadores forenses examinam os logs
do IIS para rastrear as tentativas feitas pelo invasor de explorar o servidor. Em sistemas operacionais Windows Server,
os arquivos de log são armazenados por padrão em %SystemDrive%\inetpub\logs\LogFiles.
Nota: O local de armazenamento dos logs pode variar caso o administrador tenha feito uma configuração para gravar e
armazenar os logs em outro local.
Figura 9.2: entradas de log do IIS visualizadas no Notepad++


Analisando logs do IIS

Exemplo de uma entrada de arquivo de log do IIS conforme exibido em um editor de texto:
Número Campo aparecer como Descrição

Data e hora 12/12/2019 06:11:41 A entrada do arquivo de log foi registrada às 6h11 em 12 de dezembro de 2019
1
2 IP do servidor 192.168.0.10 Endereço IP do servidor
3 método cs PEGAR O usuário emitiu um comando GET ou download
4 cs-uri-stem /images/content/bg_body_1.jpg O usuário queria baixar o arquivo bg_body_1.jpg da pasta Imagens
5 cs-uri-query - A consulta de URI não ocorreu
6 esporte 80 A porta do servidor
7 cs-username - O usuário era anônimo
8 Endereço IP do cliente 192.168.0.27 O endereço IP do cliente
9 Mozilla/5.0+(Windows+NT+6.3;+WOW64)+AppleWebKit/537.3 6+(KHTML,
cs(User-Agent) O tipo de navegador que o cliente usou, conforme representado pelo navegador
+like+Gecko)+Chrome/48.0.2564.103+Safari/537.36
10 cs(Referenciador) http://www.moviescope.com/css/style.css A página da Web que forneceu o link para o site
11 sc-status 200 A solicitação foi atendida sem erro
12 demorado 365 A ação foi concluída em 365 milissegundos
Analisando logs do IIS
Localizando logs do IIS na máquina baseada no Windows
Para localizar os arquivos de log do IIS em uma máquina Windows Server 2016, vá para Ferramentas Administrativas no
menu Iniciar do Windows e clique em Gerenciador de Serviços de Informações da Internet (IIS).
Figura 9.3: Navegando para o Gerenciador de Serviços de Informações da Internet (IIS)
Expanda a pasta correspondente ao nome do servidor. Selecione Logging no painel Features View para carregar as
configurações de Logging.


Figura 9.4: Selecionando o ícone Logging no Internet Information Services Manager
No campo Diretório, você encontrará o caminho no qual residem seus logs.
Figura 9.5: O caminho para os logs do IIS mostrado no campo Diretório


Navegue até a pasta LogFiles seguindo o caminho mostrado no campo Diretório. Para cada site configurado, a pasta
LogFiles contém uma subpasta com um nome, como W3SVC1 ou W3SVC2.
Figura 9.6: Subpastas na pasta LogFiles
O último número no nome da pasta corresponde ao ID do site. Encontre a pasta que corresponde ao ID do site. Cada
site hospedado no IIS possui seu próprio subdiretório para arquivos de log, denominado W3SVCn, onde “n” representa
o número do site.
Os subdiretórios W3SVCn armazenam arquivos de log denominados u_exyymmdd.log, onde “yy” refere-se ao ano, “mm”
refere-se ao mês e “dd” refere-se ao dia.
Quando o IIS registra os logs no W3C Extended Log Format, o IIS armazena todos os eventos registrados no formato
GMT, em vez do formato do fuso horário local do sistema. Este ponto deve ser considerado durante o exame dos logs
porque o IIS cria um novo arquivo de log para o dia seguinte à meia-noite no GMT.
Tempo Universal Coordenado (UTC)
O IIS registra logs usando o Tempo Universal Coordenado (UTC), que ajuda na sincronização de servidores em vários
fusos horários. Para calcular o UTC, o Windows compensa o valor do relógio do sistema com o fuso horário do sistema.
Uma configuração precisa do fuso horário local deve ser assegurada pelo administrador da rede para validar o UTC.
Além disso, o administrador deve verificar o processo definido para o IIS rolar logs usando a hora local.
A configuração de fuso horário do servidor pode ser verificada visualizando as primeiras entradas no arquivo de log. Se
o fuso horário do servidor estiver definido como UTC -06:00, as primeiras entradas de log devem aparecer por volta das
18:00 (00:00 - 06:00 = 18:00).
Como o UTC não segue o horário de verão, o administrador também deve considerar a data. Por exemplo, UTC -6:00
será -5:00 durante metade do ano em fusos horários que seguem o horário de verão.


Exemplo de uma entrada de log do IIS
12/12/2019 06:11:41 192.168.0.10 GET / images/ content/ bg_body_1.jpg - 80 - 192.168.0.27 Mozilla/ 5.0+(Windows+NT+6.3;+WOW64)+AppleWebKit/ 537.36+
(KHTML, +like+Gecko)+Chrome / 48.0.2564.103+Safari/ 537.36 http:// www.moviescope.com/ css/ style.css 200 0 0 365
Na entrada acima:
ÿ 2019-12-12 06:11:41: Isso mostra a data e a hora em que a entrada do arquivo de log foi gravada
ÿ 192.168.0.10: Isso mostra o endereço IP do servidor
ÿ GET: Este é o campo cs-method indicando que o usuário emitiu uma solicitação GET ou download
comando
ÿ /images/content/bg_body_1.jpg: Este é o campo cs-uri-stem indicando que o usuário

queria baixar o arquivo bg_body_1.jpg da pasta Imagens
ÿ
-: Isso denota o campo cs-uri-query. Um "hífen" aqui indica que a consulta de URI não
não ocorre
ÿ 80: Isso mostra a porta do servidor

ÿ
-: Este é o campo cs-username. Um "hífen" aqui indica que o usuário era anônimo
ÿ 192.168.0.27: Isso mostra o endereço IP do cliente
ÿ Mozilla/5.0+(Windows+NT+6.3;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko )+Chrome/
48.0.2564.103+Safari/537.36: Este é o campo cs(User-Agent) mostrando os detalhes do navegador usado
pelo cliente
ÿ http://www.moviescope.com/css/style.css: Este é o campo cs(Referer) mostrando

página da web que forneceu o link para o site
ÿ 200: Isso denota o campo sc-status. O código de status 200 indica que a solicitação foi
cumprido sem erro
ÿ 365: Isso indica o campo de tomada de tempo. Na entrada de log de exemplo, a ação foi
concluído em 365 milissegundos


Arquitetura do Servidor Web Apache
Componente /
Subcomponente
Núcleo Apache
Módulo Dados
Chamadas/Usos
interage
HTTP_MAIN Controle de retorno/dados
(loop do servidor)
UM MÓDULO APACHE
para/de despachar para

HTTP_PROTOCOL HTTP_REQUEST Manipulador 1
(implementação) (fases do pedido)

Cliente HTTP módulos
Apache
Core
para
De/
Manipulador 2
HTTP_CORE
(funcionalidade principal)
Manipulador 3
ALOC
SERVIÇOS DE UTILIDADE PÚBLICA
encontro privado
(res. piscinas)
Arquitetura do Servidor Web Apache

O servidor web Apache segue uma abordagem modular. Ele consiste em dois componentes principais,
o núcleo do Apache e os módulos do Apache. O núcleo do Apache aborda as funcionalidades básicas
do servidor, como a alocação de solicitações e a manutenção e agrupamento de conexões, enquanto
os módulos do Apache, que são simplesmente complementos usados para estender a funcionalidade
do núcleo do servidor, lidam com outras funções, como obter o ID do usuário da solicitação HTTP,
validar o usuário e autorizar o usuário. A figura abaixo descreve a arquitetura do servidor web Apache.
O núcleo do Apache consiste em vários componentes que possuem atividades específicas a serem executadas.
Figura 9.7: Arquitetura do servidor web Apache


Os elementos do núcleo do Apache são http_protocol, http_main, http_request, http_core, alloc e http_config.
ÿ http_protocol: Este elemento é responsável por gerenciar as rotinas. Ele interage com o cliente e lida com toda a
troca de dados e conexões de soquete entre o cliente e
servidor.
ÿ http_main: Este elemento lida com inicializações e tempos limite do servidor. Também é composto pelos principais
loop do servidor que espera pelas conexões e as aceita.
ÿ http_request: Este elemento controla o procedimento passo a passo seguido entre os módulos para concluir uma
solicitação do cliente e é responsável pelo tratamento de erros
ÿ http_core: Este elemento inclui um arquivo de cabeçalho que não é exigido pelo aplicativo
módulo
ÿ Alloc.c: Este elemento lida com a alocação de pools de recursos
ÿ http_config: Este elemento é responsável por ler e manipular arquivos de configuração. Uma das principais
tarefas do http_config é organizar todos os módulos, que o servidor chamará durante as várias fases do
tratamento da solicitação.
Conforme discutido, a arquitetura do servidor web Apache inclui vários módulos que se conectam ao núcleo Apache e
auxiliam no processamento de solicitações pelo núcleo. Para alterar ou estender a funcionalidade do servidor Apache e
atender ao propósito desejado, os desenvolvedores podem escrever novos módulos.
De acordo com o requisito de uma solicitação, determinados módulos serão chamados. Os módulos implementam a
funcionalidade desejada e encaminham a saída para o núcleo, que monta a saída usando o componente HTTP_REQUEST
para enviá-la a outro módulo para processamento ou devolvê-la ao cliente. Os módulos consistem em manipuladores,
que denotam funções específicas a serem executadas pelos módulos. Os módulos criam manipuladores específicos
sempre que uma solicitação é processada.


Registros do Servidor Web Apache
Servidor HTTP Apache Tipos de log do Apache Informações de registro do Apache
ÿ Apache HTTP Server é um ÿ O servidor Apache gera dois ÿ Os logs do Apache fornecem
servidor web que suporta muitos tipos de logs informações sobre atividades de
SOs, como Unix, GNU, aplicativos da web, como as seguintes:
FreeBSD, Linux, Solaris, ÿ Registro de acesso
ÿ Endereço IP do cliente
Novell NetWare, AmigaOS,
ÿ Log de erros
macOS, Microsoft ÿ Identificação da máquina cliente
Windows, OS/2 e TPF
ÿ ID do usuário do cliente
ÿ Tempo
ÿ Linha de solicitação do cliente
ÿ Código de estado
ÿ Tamanho do objeto devolvido ao

cliente
Registros do Servidor Web Apache
Servidor HTTP Apache
Apache HTTP Server é um servidor web que suporta muitos sistemas operacionais, como Unix, GNU, FreeBSD, Linux,
Solaris, Novell NetWare, AmigaOS, macOS, Microsoft Windows, OS/2 e TPF. Atualmente, ele pode funcionar em diferentes
sistemas operacionais, como Mac e Windows. Como é uma web multi-threaded
servidor, ele pode executar várias funções solicitadas pelos navegadores da Web do cliente e implementar várias tarefas
simultaneamente. Apache HTTP Server utiliza módulos e extensões para suportar vários ambientes.
Tipos de log do Apache
O servidor Apache gera os dois tipos de logs a seguir:
1. Log de acesso: geralmente registra todas as solicitações processadas pelo servidor web Apache
2. Log de erros: contém informações de diagnóstico e erros que o servidor enfrentou durante o processamento de
solicitações
A localização exata desses logs do Apache varia de acordo com o sistema operacional em uso. Os investigadores podem
verificar os seguintes locais para o arquivo de configuração do Apache para encontrar a localização exata dos arquivos de log:
ÿ RHEL/Red Hat/CentOS/Fedora Linux: /usr/local/etc/apache22/httpd.conf
ÿ Debian/Ubuntu Linux: /etc/apache2/apache2.conf
ÿ FreeBSD: /etc/httpd/conf/httpd.conf


Informações de registro do Apache
Durante auditorias e investigações forenses, os logs do Apache fornecem informações muito importantes sobre todas as operações
realizadas no servidor web. Essas informações incluem endereços IP do cliente, a identidade de uma máquina cliente, hora, ID do
usuário cliente, linha de solicitação de um cliente, código de status e o tamanho do objeto retornado ao cliente. Todas as informações
fornecidas pelos logs podem levar o investigador ao atacante.


Registros de acesso do Apache
Log de
Acesso ÿ Contém as requisições
processadas pelo servidor Apache
ÿ Os locais padrão dos logs de acesso
são os seguintes:
RHEL/Red Hat/CentOS/Fedora
Linux:
/var/log/httpd/access_log
Debian/Ubuntu Linux: /
var/log/apache2/access.log
FreeBSD Linux: /
var/log/httpd-access.log
Registros de acesso do Apache
Todas as requisições HTTP processadas pelo servidor Apache são registradas no log de acesso. Possui
um registro de cada requisição que passa pelo servidor. A diretiva LogFormat ajuda a selecionar o
conteúdo do log necessário.
A diretiva CustomLog define o local e o conteúdo do log de acesso. A diretiva CustomLog também
contém informações para configurar o servidor de forma que o servidor possa manter registros de log de
acesso. Os logs de acesso são armazenados no Common Log Format por padrão e são altamente
configuráveis.
Os locais padrão dos logs de acesso são os seguintes:
ÿ RHEL/Red Hat/CentOS/Fedora Linux: /var/log/httpd/access_log

ÿ Debian/Ubuntu Linux: /var/log/apache2/access.log
ÿ FreeBSD Linux: /var/log/httpd-access.log


Figura 9.8: Arquivo access.log do Apache


Analisando logs de acesso do Apache
Registro de acesso: formato de registro comum
"%h %l %u %t \"%r\" %>s %b"

Exemplo de uma entrada de arquivo de log de acesso do Apache conforme visualizado em um editor de texto:
Corda
Número aparecer como Descrição
Percentagem
(%h) 10.10.10.10 Endereço IP do host/cliente remoto

1
2 (%eu) – A informação solicitada não está disponível
(%em) jasão O ID do usuário

3
A hora e a data em que o servidor
4 (%t) [17/ago/2019:00:12:34 +0300]
recebeu a solicitação
"GET /images/content/bg_body_1.jpg HTTP/ A linha de solicitação do cliente, o método de

5 (\"%r\")
1.0" solicitação e o protocolo usado
(%>s) 500 O código de status HTTP

6
1458
Tamanho do objeto devolvido ao cliente em bytes
7 (%b)
Analisando logs de acesso do Apache (continuação)
Registro de acesso: Formato de registro
combinado "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
Exemplo de uma entrada de arquivo de log de acesso do Apache no formato de log combinado conforme visualizado em um editor de texto:
Número aparece como Descrição

Porcentagem de sequência
"%h %l %u %t 10.10.10.10 – Jason [17/ago/2019:00:12:34

1 \"%r\" %>s %b"
+0300] "GET /images/content/bg_body_1.jpg Este formato se assemelha ao formato de log comum
HTTP/1.0" 500 1458
É o cabeçalho da requisição HTTP referenciador, que apresenta

(\"%{Refer}em\") http://www.abc.com/login.php o endereço da página anterior visitada pelo cliente que o
2
redirecionou para a página atual
é o cabeçalho de solicitação HTTP do agente do usuário que

"Mozilla/5.0 (x11; Ubuntu; Linux x86_64;
(\"%{User-agent}i\") fornece detalhes da plataforma, sistema e navegador sendo
3 rv:73.0) Gecko/20100101 Firefox/73.0”
usado pelo cliente
Analisando logs do Apache Access

Apache Access Log: formato de log comum
"%h %l %u %t \"%r\" %>s %b" é o formato de log de diretiva de porcentagem comum


Parâmetros
ÿ %h representa o endereço IP do cliente.
ÿ %l representa o nome do log remoto. O último retorna um traço, a menos que mod_ident esteja presente
e o IdentityCheck está ativado.
ÿ %u é o ID do usuário cliente.
ÿ %t representa a hora em que o servidor recebeu a requisição no seguinte formato:

[dia/mês/ano:hora:minuto:segunda zona].
ÿ \"%r\" indica os métodos usados para uma solicitação-resposta entre um cliente e um servidor, o recurso solicitado por
um cliente (apache_pb.gif) e o protocolo usado (HTTP/1.0).
ÿ %>s representa o código de status enviado pelo servidor ao cliente.
ÿ %b representa o tamanho do objeto transferido do servidor para o cliente.
Exemplo de uma entrada de log de acesso do Apache no formato de log comum:
10.10.10.10 - Jason [17/ ago/ 2019:00:12:34 +0300] "GET/ images/ content/ bg_body_1.jpg HTTP/ 1.0" 500 1458
Uma diretiva percent representa cada campo no log. Essas diretivas percentuais permitem que o servidor entenda quais
informações ele precisa registrar. Vamos mapear as diretivas percentuais com o formato de log real:
ÿ 10.10.10.10 (%h): Endereço IP do cliente/host remoto

ÿ
- (%l): O "hífen" aqui significa que a informação não está disponível. No exemplo apresentado acima, a identidade
do cliente não está disponível, o que é determinado por identd.
O Apache não tenta confirmar essas informações se o IdentityCheck não estiver ativado na máquina.
ÿ Jason (%u): ID de usuário da pessoa que enviou a solicitação
ÿ [17/ago/2019:00:12:34 +0300] (%t): A hora em que o servidor terminou de processar o

solicitar. +03 UTC representa o fuso horário da África Oriental
ÿ "GET /images/content/bg_body_1.jpg HTTP/1.0" (\"%r\"): O cliente usou o método de solicitação GET e solicitou o
recurso /images/content/bg_body_1.jpg. O cliente usou o protocolo HTTP/1.0
ÿ 500 (%>s): O código de status indica que a resposta foi bem-sucedida
ÿ 1458 (%b): O servidor retornou o objeto de tamanho 1458 bytes para o cliente
Existem muitos campos de log em um log de acesso do Apache, conforme indicado na tabela abaixo:
Campos de registro do Apache
%a – RemoteIPOrHost %r – Pedido %X - Status da Conexão
%A - LocalIPOrHost %>s - HttpStatusCode %(Refer)i - Refer

%b ou %B - Tamanho %t – hora do evento %(User-agent)i - UserAgent


%D – RequestTimeUs
%T – RequestTimeSeconds %(UNIQUE_ID)e - UniqueId
(microssegundos)
%(X-Encaminhado-Para)i -
%h - RemoteIPOrHost %u – RemoteUser
XForwardedFor
%k - KeepAliveRequests %U - URLPath %l - %(Host)i - Host
RemoteLogname %v - VirtualHost
Tabela 9.1: Campos de log disponíveis nos logs de acesso do Apache
Log de acesso do Apache: formato de log combinado
Outra string de formato é comumente usada nos logs de acesso do Apache. É chamado de Formato de Log Combinado
e sua sintaxe é a seguinte:
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
Exemplo de uma entrada de log de acesso do Apache no formato de log combinado
10.10.10.10 - Jason [17/ ago/ 2019:00:12:34 +0300] “GET / images/ content/ bg_body_1.jpg HTTP/ 1.0” 500 1458 http://
www.abc.com/ login.php " Mozilla/ 5.0 (x11; Ubuntu; Linux x86_64; rv:73.0) Gecko/ 20100101 Firefox/ 73.0”
Este formato se assemelha exatamente ao Common Log Format de acesso Apache, exceto por dois campos adicionais:
(\"%{Referer}i\") e (\"%{User-agent}i\")
ÿ http://www.abc.com/login.php(\"%{Referer}i\"): É o cabeçalho de requisição HTTP referenciador, que apresenta

o endereço da página web anterior visitada pelo cliente; esta página da web redirecionou o cliente para a página
da web atual. Essas informações ajudam o servidor Apache a identificar as páginas da Web que os clientes
estão visitando, que podem ser usadas posteriormente para fins de armazenamento em cache e registro.
ÿ "Mozilla/5.0 (x11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0”

(\"%{User-agent}i\"): É o cabeçalho da requisição HTTP user-agent, que apresenta detalhes sobre a plataforma,
sistema e navegador que está sendo utilizado pelo cliente.
Aqui, no exemplo, “Mozilla/5.0” indica que o navegador é compatível com Mozilla. "x11; Ubuntu; Linux x86_64" indica que
a plataforma utilizada é o Ubuntu Linux e "rv:73.0" indica a versão do Firefox. "Gecko/20100101" indica que o navegador
é baseado em Gecko e "Firefox/73.0" indica o navegador e a versão.


Apache
Registros de erros
Registro de erros
ÿ O servidor Apache salva informações de diagnóstico e

mensagens de erro encontradas durante o
processamento de solicitações nos logs de erro
ÿ Os locais padrão dos logs de erro são os seguintes: RHEL/

Red Hat/CentOS/Fedora Linux: /var/log/httpd/error_log
Debian/Ubuntu Linux: /var/log/apache2/error.log
FreeBSD: /var/log/httpd-error.log
Registros de erros do Apache
O log de erros do Apache é o local onde o servidor registra todos os erros ocorridos durante o processamento da solicitação do
cliente. O arquivo de log de erros é denominado error.log em sistemas operacionais Windows e error_log em sistemas
operacionais baseados em Unix.
A diretiva ErrorLog define a localização do log de erros. O arquivo de log contém dados pertencentes aos
problemas na inicialização e operação do servidor. Ele também armazena informações relacionadas ao
motivo do problema e as etapas envolvidas para resolvê-lo. Os investigadores devem usar comandos
Linux como grep, cat, gedit e vi para ler esses arquivos de log.
Os locais padrão dos logs de erros são os seguintes:
ÿ RHEL/Red Hat/CentOS/Fedora Linux: /var/log/httpd/error_log

ÿ Debian/Ubuntu Linux: /var/log/apache2/error.log
ÿ FreeBSD: /var/log/httpd-error.log


Figura 9.9: Arquivo error.log do Apache


Analisando logs de erro do Apache

Exemplo de entrada de log de erros do Apache conforme visualizado em um editor de texto
Data e hora do log 01 04 Endereço IP do cliente
Mensagem informando “Arquivo

Gravidade do erro 02 ` 05 não encontrado”
O objeto solicitado pelo cliente

ID do processo e ID do encadeamento 03 06
Analisando logs de erro do Apache
Exemplo de uma entrada de log de erros do Apache
[Qua 28 de agosto 13:35:38.878945 2020] [core:error] [pid 12356:tid 8689896234] [client 10.0.0.8] Arquivo não
encontrado: / images/ folder/ pic.jpg
A anatomia do log de erros do Apache acima é descrita abaixo:
ÿ Qua, 28 de agosto 13:35:38.878945 2020: Este é o primeiro elemento na entrada do log. Contém
o timestamp (dia, mês, data, hora e ano) do log.
ÿ core:error: O segundo elemento no log descreve o módulo que produz a mensagem.

Nesse caso, o núcleo do Apache está produzindo uma mensagem descrevendo o nível de segurança (erro).
ÿ pid 12356:tid 8689896234: O próximo elemento no log contém o ID do processo e seu

ID do tópico correspondente
ÿ cliente 10.0.0.8: O quarto elemento no log é o endereço do cliente a partir do qual o pedido
foi feito
ÿ Arquivo não encontrado: O quinto elemento do log mostra o estado do arquivo solicitado pelo cliente. Nesse
caso, o arquivo não foi encontrado. Portanto, o servidor exibiu uma mensagem de erro informando que o
arquivo não existe no servidor.
ÿ /images/folder/pic.jpg: O elemento final mostra o nome do arquivo e o caminho para o arquivo que
o cliente solicitou


Também pode haver outras mensagens geradas nos logs de erro do Apache, dependendo da gravidade dos erros,
conforme listado na tabela abaixo:
Gravidade Descrição Exemplo
emergir Emergências – o sistema está inutilizável “A criança não consegue abrir o arquivo de bloqueio. Saindo”
“getpwuid: não foi possível determinar o

alerta Ação imediata necessária
nome de usuário do uid”
“socket: Falha ao obter um socket, saindo do filho”

crítico Condições críticas
erro Condições de erro "Inicio prematuro dos cabeçalhos de script"
“processo filho 1234 não saiu, enviando outro SIGHUP”

avisar Condições de aviso
“httpd: pegou SIGBUS, tentando despejar núcleo em

perceber Condição normal, mas significativa
….”
informação Informativo “O servidor parece ocupado…”
depurar Mensagens de nível de depuração “abrindo arquivo de configuração…”
trace1-8 Rastrear mensagens “proxy: FTP:…”
Tabela 9.2: Mensagens de gravidade diferente geradas nos logs de erro do Apache
Deve-se notar aqui que o formato do arquivo de log de erros mostrado acima destina-se a servir como exemplo. Os
administradores podem alterar o formato dos arquivos de log de erros do Apache na configuração e especificar
quaisquer informações/valores adicionais a serem registrados.
Além disso, no caso de logs de erro, alguns itens de string de formato podem não gerar nenhuma saída.
Nesses casos, o log de erros do Apache omitiria todo o campo por padrão. Portanto, os investigadores devem examinar
cuidadosamente o arquivo de log de erros do Apache enquanto tentam entender qual conexão ou solicitação levou à
gravação de uma entrada de log de erro específica, qual campo ou campos foram omitidos e determinar os possíveis
motivos para tal omissão.


Fluxo do módulo

Entender Web
Formulários
Investigando ataques na Web em

Servidores baseados em Windows
Execute o Visualizador de eventos para visualizar os logs:
C:\> eventvwr.msc
Verifique se os seguintes eventos suspeitos ocorreram: ÿ O serviço
de log de eventos foi encerrado ÿ A proteção de arquivos do Windows

está inativa no sistema ÿ O serviço MS Telnet está em execução
Descubra se o sistema falhou em tentativas de login ou contas

bloqueadas


Investigando ataques da Web em Windows

Servidores (continuação)
Revise os compartilhamentos de arquivos para garantir sua finalidade:
C:\> net view <Endereço IP>
Verifique os usuários usando sessões abertas:
C:\> sessão de rede
Verifique se as sessões foram abertas com outros sistemas:
C:\> uso da rede
Analise no NetBIOS sobre a atividade TCP/IP:

C:\> nbtstat -S
Descubra se as portas TCP e UDP têm escuta incomum:
C:\> netstat –na
Investigando ataques da Web em Windows

Servidores (continuação)
Encontre tarefas agendadas e não agendadas no host local:
C:\> schtasks.exe
Verifique a criação de novas contas no grupo de administradores:
Iniciar -> Executar -> lusrmgr.msc -> OK
Verifique se algum processo inesperado está sendo executado em Tarefa

Gerente:
Iniciar -> Executar -> taskmgr -> OK
Verifique se há serviços de rede incomuns:
C:\> net start
Verifique o uso do espaço de arquivo para encontrar qualquer diminuição repentina no espaço livre:
C:\> você
Investigando ataques da Web em servidores baseados em Windows

Os invasores podem explorar vulnerabilidades nos sites hospedados em servidores baseados no Windows e realizar
ataques direcionados ao servidor da Web, como travessia de diretório, injeção de comando e ataques DoS.
Esta seção discute quais arquivos de log e outros componentes do sistema os investigadores podem verificar enquanto
procuram por ataques em servidores baseados no Windows.


Os sistemas operacionais Microsoft Windows têm 77,64% da participação no mercado global, de acordo com https:// www.statista.com.
Consequentemente, os desenvolvedores podem preferir usar servidores baseados no Windows para implantar aplicativos da web.
Devido ao seu amplo uso, esses sistemas operacionais e os aplicativos da Web hospedados em alguns desses sistemas operacionais
são o principal alvo dos invasores. Os invasores podem tentar explorar as vulnerabilidades em servidores baseados no Windows ou
aplicativos da Web e obter acesso não autorizado aos recursos.
Quando ocorre um ataque em um aplicativo da web, os investigadores examinam o ataque no servidor que hospeda o aplicativo da
web usando algumas das ferramentas e aplicativos embutidos de máquinas baseadas no Windows.
Os investigadores podem executar as seguintes etapas para procurar sinais de ataques da Web em sistemas baseados no Windows
servidores:
ÿ Execute o Visualizador de Eventos para visualizar os logs:
C:\> eventvwr.msc
ÿ Verifique se ocorreram os seguintes eventos suspeitos:
o O serviço de log de eventos terminou
o A proteção de arquivos do Windows está inativa no sistema
o O serviço MS Telnet está em execução
ÿ Descubra se o sistema falhou em tentativas de login ou contas bloqueadas
ÿ Revise os compartilhamentos de arquivos para garantir sua finalidade:
C:\> net view <Endereço IP>
ÿ Verifique os usuários usando sessões abertas:
C:\> sessão de rede
Figura 9.10: Executando o comando net session
ÿ Verifique se as sessões foram abertas com outros sistemas:
C:\> uso da rede


ÿ Analisar no NetBIOS sobre atividade TCP/IP:
C:\> nbtstat -S
ÿ Descubra se as portas TCP e UDP têm escuta incomum:
C:\> netstat –na
Figura 9.11: Executando o comando netstat -na
ÿ Encontre tarefas agendadas e não agendadas no host local:
C:\> schtasks.exe
ÿ Verifique a criação de novas contas no grupo administrador:
Iniciar -> Executar -> lusrmgr.msc -> OK

ÿ Verifique se algum processo inesperado está sendo executado no Gerenciador de Tarefas:
Iniciar -> Executar -> taskmgr -> OK

ÿ Verifique se há serviços de rede incomuns:
C:\> net start


Figura 9.12: Executando o comando net start
ÿ Verifique o uso do espaço de arquivo para encontrar qualquer diminuição repentina no espaço livre
C:\> você


Fluxo do módulo

Entender Web
Formulários
Detecte e investigue vários ataques em aplicativos da Web

Alguns aplicativos da web têm a vulnerabilidade de processar a entrada do usuário sem validação adequada ou
métodos de sanitização, que os invasores podem explorar para lançar vários ataques. No caso de uma violação de
segurança, os investigadores devem examinar os arquivos de log gerados pelos servidores da Web, ferramentas
IDS e WAFs e procurar assinaturas de ataque. A análise de arquivos de log também pode ajudar os investigadores
a construir a cadeia de eventos que levaram ao ataque.
Esta seção discute como os investigadores podem detectar e analisar vários ataques a aplicativos da web.


Investigando o ataque Cross-Site Scripting (XSS)

ÿ Ataques XSS comuns usam tags HTML, como <script></script>, <IMG>, <INPUT> e <BODY>
codificação hexadecimal
ÿ Os invasores usam várias técnicas de Alternância entre maiúsculas e minúsculas
ofuscação para evitar a detecção por Comentário em linha Palavras-chave substituídas
firewalls de aplicativos e sistemas IDS/IPS

Codificação de caracteres Manipulação de espaço em branco
ÿ Por exemplo, todos os scripts abaixo têm o mesmo significado:

<script>alert(“XSS”)</script> <sCRipT>alert(“XSS”)</
ScRiPt>…..................... .............................(Alternar entre maiúsculas e minúsculas) %3cscript%3ealert(”XSS”)%3c/script%3e
>…..................................( codificação hexadecimal) %253cscript%253ealert(1)% 253c/script%253e…...............( Codificação dupla)
ÿ Os investigadores podem usar a pesquisa regex para encontrar tags HTML, outras palavras de assinatura XSS e seus equivalentes hexadecimais
em logs do servidor web, logs IDS, alertas de ferramentas SIEM, etc. para verificar ataques XSS
Investigando o ataque Cross-Site Scripting (XSS)
Nos ataques XSS, o invasor explora a vulnerabilidade em aplicativos da Web injetando scripts maliciosos, que são principalmente
JavaScript, HTML ou marcação CSS, nas páginas da Web exibidas no navegador do usuário. Ataques XSS comuns usam tags
HTML, como <script></script>, <IMG>, <INPUT> e <BODY>.
A implementação de firewalls, IDSs, IPSs, software antivírus etc. adequados dificulta a execução de ataques XSS pelos invasores,
pois eles precisam contornar esses mecanismos de segurança. Os invasores usam várias técnicas de ofuscação, conforme
indicado abaixo, para contornar esses mecanismos de segurança e realizar atividades maliciosas:
ÿ Codificação hexadecimal ÿ Alternar caso
ÿ Comentário em linha ÿ Palavras-chave substituídas
ÿ Codificação de caracteres ÿ Manipulação de espaço em branco
Por exemplo, todos os scripts abaixo têm o mesmo significado:
ÿ Script normal: <script>alert(“XSS”)</script>
ÿ Script com alternância entre maiúsculas e minúsculas: <sCRipT>alert(“XSS”)</ScRiPt>
ÿ Script codificado em hexadecimal: %3cscript%3ealert(”XSS”)%3c/script%3e>
ÿ Script duplamente codificado: %253cscript%253ealert(1)%253c/script%253e
Para detectar sinais de ataques XSS, os investigadores podem procurar tags HTML, outras palavras de assinatura XSS ou seus
equivalentes hexadecimais; como alternativa, eles podem usar a pesquisa regex para encontrá-los em logs do servidor da web,
alertas de IDS, informações de segurança e alertas de ferramentas de gerenciamento de eventos (SIEM), etc.


Investigando XSS: usando Regex para pesquisar strings XSS
A expressão regular abaixo verifica se há ataques que possam conter tags HTML de abertura e
fechamento (<>) com qualquer texto dentro, junto com seus equivalentes hexadecimais e duplos
Detecção de tentativa simples de XSS ÿ /

/((\%3C)|(\%253C)|<)((\%2F)|(\%252F)|\/)*[a
((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/ix
zA-Z0-9\%]+((\%3E ) |(\%253E)|>)/ix
ÿ ((\%3C)|(\%253C)|<) - Verifica o colchete angular de abertura, ou seu equivalente
Detecção de tentativa XSS baseada em <img src=
hexadecimal ou hexadecimal duplamente codificado ÿ ((\%2F)|(\%252F)|\/) * -
ÿ /((\%3C)|<)((\%69)|i|(\%49))((\%6D)|m|(\%4D))(( \
Verifica a barra em uma tag de fechamento, ou seu equivalente hexadecimal ou
%67)|g| (\%47))[^\n]+((\%3E)|>)/I
hexadecimal codificado duplamente ÿ [a-zA-Z0-9\%]+ - Verifica strings
alfanuméricas maiúsculas e minúsculas dentro da tag representação hexadecimal
Detecção de tentativa de XSS baseada em tag HTML
ÿ /(javascript|vbscript|script|embed|object|iframe|fra
meset)/i
ÿ ((\%3E)|(\%253E)|>) - Verifica o colchete angular de fechamento ou seu equivalente

Detecção de todas as tentativas de XSS
hexadecimal ou hexadecimal com codificação dupla
ÿ /((\%3C)|<)[^\n]+((\%3E)|>)/I
Investigando XSS: usando Regex para pesquisar strings XSS
Quando um invasor executa um ataque XSS em uma página da Web dinâmica, ele pode criar um script que inclua tags
de formatação HTML, como <b> para negrito, <i> para itálico ou <u> para sublinhado.
Eles também podem usar tags de script, como <script>alert("OK")</script>.
Alguns invasores também podem usar mecanismos avançados para realizar um ataque XSS. Eles podem ocultar toda a
string emitindo seus equivalentes hexadecimais. Por exemplo, o equivalente hexadecimal de <script> é
%3C%73%63%72%69%70%74%3E.
ÿ Regex para detecção de ataque XSS simples
A expressão regular a seguir pode ser usada para detectar ataques XSS simples. Ele verifica os
colchetes angulares de abertura e fechamento de tags HTML contendo texto para que possa
capturar facilmente tags como <b>, <i> e <script>:
/((\%3C)|<)((\%2F)|\/)*[a-ZA-Z0-9\%]+((\%3E)|(\%253E)|>)/ix
Nesta assinatura:
o ((\%3C)|<): Procura por parênteses angulares de abertura ou seu equivalente hexadecimal
o ((\%2F)|\/)*: Procura a barra para uma tag de fechamento ou seu equivalente hexadecimal
o [a-zA-Z0-9\%]+: Procura por strings alfanuméricas maiúsculas e minúsculas dentro

a tag ou seu equivalente hexadecimal
o ((\%3E)|(\%253E)|>): Procura por parênteses angulares de fechamento ou seu equivalente hexadecimal
ÿ Regex para detectar ataque XSS "<img src"
/((\%3C)|<)((\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|( \%47))[^\ n]+((\%3E)|>)/I


Essa assinatura procura por tentativa de XSS baseada em "<img src". Nesta assinatura:
o (\%3C)|<): Procura o colchete angular de abertura ou seu equivalente hexadecimal
o (\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47): Procura o
letras "img" por meio de vários caracteres ASCII ou seus equivalentes hexadecimais
o [^\n]+: Procura qualquer caractere que não seja uma nova linha após o <img
o (\%3E)|>): Procura colchetes angulares de fechamento ou seu equivalente hexadecimal
ÿ Regex para tentativa de XSS baseada em tags HTML
/(javascript|vbscript|script|embed|object|iframe|frameset)/i
A assinatura acima procura por tags HTML, ataque XSS. Nessa assinatura, cada palavra-chave dentro dos
colchetes é separada por uma barra vertical ("|") representada por um OU.
ÿ Regex paranóico para ataques CSS
/((\%3C)|<)[^\n]+((\%3E)|>)/I
Essa assinatura procura os colchetes angulares de abertura, ou seu equivalente hexadecimal, seguidos por um
ou mais caracteres (exceto qualquer nova linha) e seguidos pelo colchete angular de fechamento ou seu
equivalente hexadecimal.


Examinando logs do Apache para ataque XSS

ÿ A entrada de log realçada no arquivo Apache access.log
mostra uma solicitação GET seguida por alguns valores codificados em
hexadecimal na string de consulta
ÿ Decodifique a string de consulta para determinar se ela contém tags

HTML maliciosas
Valor codificado em hexadecimal Caractere Decodificado
%3C <
%3E >
% 28 (
% 29 )
%2F /
ÿ A decodificação dos valores revela que o log está associado a

um ataque XSS
ÿ A análise detalhada do log forneceu as seguintes conclusões:
ÿ O ataque originou-se do IP 10.0.0.1 (1) 16 de junho de 2020 (2)
ÿ O script XSS malicioso %3Cscript%3Ealert%28XSS%29%3C%2Fscript%3E (4), que converte para <script>alert(XSS)</script> após a decodificação, foi injetado na página /
wordpress/wp- admin/admin.php?page=newsletters-subscribers (3) pelo invasor
ÿ Um código de status HTTP 200 (5) pode ser observado, indicando que o servidor de aplicativos da web processou a solicitação
ÿ A partir do exame de log, pode-se inferir que ocorreu um ataque XSS no aplicativo da web. Se este for um ataque XSS armazenado, este script obterá
armazenado no banco de dados de back-end e acionaria um pop-up de alerta com a mensagem “XSS” sempre que um usuário visitasse essa página da web.
Examinando logs do Apache para ataque XSS
Ao examinar as entradas do Apache access.log em busca de ataques XSS, os investigadores devem procurar tags
HTML maliciosas ou seus equivalentes hexadecimais em solicitações HTTP. É provável que o log de acesso do
Apache contenha várias solicitações registradas. Os investigadores, portanto, podem usar o comando grep para
filtrar logs de interesse. Depois que o ataque for confirmado, o investigador pode examinar outras partes do log para
coletar informações valiosas, como como e quando o ataque foi tentado, o site que foi alvo e se o ataque foi bem-
sucedido.
A entrada de log realçada no arquivo Apache access.log na figura abaixo mostra uma solicitação GET seguida por
alguns valores codificados em hexadecimal na string de consulta. Decodifique a string de consulta para determinar
se ela contém tags HTML maliciosas.


Figura 9.13: Examinando as entradas do log de acesso do Apache em busca de indicadores de ataque XSS
Valor codificado em hexadecimal Caractere Decodificado
%3C <
%3E >
% 28 (
% 29 )
%2F /
Tabela 9.3: Tabela de decodificação de scripts
Encontramos alguns valores codificados na string de consulta %3Cscript%3Ealert%28XSS%29%3C%2Fscript%3E,

que converte para <script>alert(XSS)</script> após a decodificação. A partir da análise, pode-se inferir que a entrada
de log está realmente associada a um ataque XSS.
A partir de uma análise detalhada da entrada de log mostrada acima, os seguintes detalhes podem ser obtidos:
ÿ O ataque teve origem no IP 10.0.0.1 (1) 16 de junho de 2020 (2)
ÿ O script XSS malicioso %3Cscript%3Ealert%28XSS%29%3C%2Fscript%3E (4) foi injetado na página /wordpress/

wp-admin/admin.php?page=newsletters-subscribers (3) pelo invasor
ÿ Um código de status HTTP 200 (5) pode ser observado, implicando que o servidor de aplicativos da web
processou o pedido
O exame da entrada de log sugere que esta foi uma tentativa de ataque XSS armazenada. Isso implica que o script XSS
malicioso é salvo no banco de dados de back-end e acionaria um pop-up informando “XSS” se algum usuário visitasse
essa página da web.


Examinando logs de alerta do Snort para ataque XSS
Histórico
Aqui, o Snort IDS gerou um alerta para uma tentativa de ataque XSS com os seguintes detalhes:
Endereço IP de origem/atacante: 192.168.0.233 Endereço IP de destino/alvo: 192.168.0.115
Porta de origem: 64580 Porta de destino: 80
Examinando logs de alerta do Snort para ataque XSS
O modo IDS do Snort usa métodos de inspeção baseados em regras para a detecção de ataques baseados na web.
Essas regras podem ser personalizadas de acordo com o ambiente operacional de qualquer empresa.
Os investigadores podem obter os seguintes detalhes de um alerta gerado pelo ataque Snort IDS para XSS:
ÿ Endereço IP do atacante/cliente
ÿ Porta de origem
ÿ Endereço IP do servidor
ÿ Porto de destino
Figura 9.14: Detectando uma tentativa de ataque XSS através do Snort IDS


Na figura acima, o Snort IDS gerou um alerta para uma tentativa de ataque XSS com os seguintes detalhes:
ÿ IP de Origem/Atacante: 192.168.0.233
ÿ Porta de Origem: 64580
ÿ IP de Destino/Alvo: 192.168.0.115
ÿ Porta de Destino: 80


Examinando logs SIEM para ataque XSS

ÿ Aqui, um alerta disparado pelo Splunk coletado do Snort IDS mostra um ataque XSS com as seguintes informações:
o A data do ataque é 12 de dezembro de 2018 e a hora é 4h12
o O endereço IP do invasor é 10.10.10.2 usando a porta 1593
o O IP do servidor de destino é 10.10.10.20 usando a porta HTTP 80
XSSName
Histórico
Examinando logs SIEM para ataque XSS
Ao investigar ataques baseados na Web, como XSS, uma ferramenta SIEM como Splunk geralmente oferece um
bom começo para os investigadores, pois pode extrair quaisquer dados de log gerados por aplicativos, firewalls e
host para um local central.
As ferramentas SIEM também geram alertas se houver um problema de segurança ou qualquer atividade detectada
que vá contra os conjuntos de regras definidos. Isso facilita a tarefa de análise e coleta de evidências para os
investigadores. Ao usar uma ferramenta SIEM, os investigadores podem coletar dados de várias fontes de log, como
IDS, IIS, Apache e WAF, e analisá-los para detectar sinais de qualquer invasão em aplicativos da web.
Figura 9.15: Examinando um alerta acionado pelo Splunk em busca de sinais de ataque XSS


Na figura acima, um alerta disparado pelo Splunk coletado do Snort IDS mostra uma tentativa de ataque XSS com
as seguintes informações:
ÿ A data do ataque é 12 de Dezembro de 2018, e a hora são 4h12
ÿ O endereço IP do invasor é 10.10.10.2 usando a porta 1593
ÿ O IP do servidor de destino é 10.10.10.20 usando a porta HTTP 80


Investigando ataque de injeção de SQL

ÿ Procure por incidentes de ataque de injeção SQL em ÿ A assinatura do ataque de injeção SQL nos arquivos
os seguintes locais: de log do servidor Web pode ter a seguinte aparência:
ÿ Arquivos de log IDS ÿ 10:23:45 10.0.0.7 CABEÇA OBTER

/login.asp?username=blah' ou 1=1 –
ÿ Arquivos de log do servidor Web
ÿ Alertas acionados pelo SIEM ÿ 10:23:45 10.0.0.7 CABEÇA OBTER

/login.asp?username=blah' ou )1=1 (--
ÿ 10:23:45 10.0.0.7 CABEÇA OBTER

/login.asp?username=blah' or exec
master..xp_cmdshell 'net user test testpass --
Investigando ataque de injeção de SQL
Um investigador deve procurar incidentes de ataque de injeção de SQL nas seguintes fontes:
ÿ Arquivos de log IDS
Os logs IDS permitem que os administradores do sistema identifiquem quaisquer invasões bem-sucedidas. Os
logs gerados podem ajudar a identificar tendências e padrões de ataque. A análise desses padrões pode
permitir que os investigadores encontrem vulnerabilidades de segurança e preparem um plano para mitigá-las.
Além disso, o exame dos logs de IDS fornece informações relacionadas a qualquer possível vulnerabilidade de
segurança, descuidos de política ou qualquer sistema host ou rede em que os controles de segurança
adequados não tenham sido implementados.
ÿ Arquivos de log do servidor Web
Os logs do servidor Web fornecem informações sobre como, por quem e quando as páginas e aplicativos de
um site estão sendo acessados. Cada servidor web gera arquivos de log que mantêm um registro de acesso a
uma página ou gráfico HTML específico.
Uma assinatura de ataque específica de injeção de SQL em um arquivo de log pode ter a seguinte aparência:
ÿ 10:23:45 10.0.0.7 HEAD GET / login.asp?username=blah' ou 1=1 –
ÿ 10:23:45 10.0.0.7 HEAD GET / login.asp?username=blah' ou )1=1 (--
ÿ 10:23:45 10.0.0.7 HEAD GET / login.asp?username=blah' ou exec

master..xp_cmdshell 'net user test testpass --


Métodos de ofuscação usados no ataque de injeção SQL
Os invasores usam vários métodos de ofuscação para contornar os mecanismos de segurança nos sites. Algumas das técnicas
são discutidas abaixo:
ÿ Comentário em linha: os invasores usam comentários em linha no meio das sequências de ataque para ignorar
mecanismos de segurança.
Código com comentário embutido:
http:// www.bank.com/ accounts.php?id=/ *!union*/ +/ *!select*/ +1,2,concat(/ *!table_na me*/)+FrOm/ *!information_schema

*/.tables/ *!WhErE*/ +/ *!TaBlE_sChEMa*/ +like+dat abase()--
ÿ Codificação de caracteres/codificação dupla: Alguns WAFs decodificam entradas codificadas em hexadecimal e as

filtram, evitando um ataque. Para contorná-los, os invasores podem codificar duas vezes a entrada.
Código com codificação de caracteres:
http:// www.bank.com/ accounts.php?id=1%252f%252a*/ union%252f%252a/ select%252 f%252a*/ 1,2,3%252f%252a*/

from% 252f%252a*/ usuários--
ÿ Alternância entre maiúsculas e minúsculas: alguns aplicativos bloqueiam palavras-chave SQL em minúsculas. Nesse caso, os atacantes
use o código escrito em maiúsculas e minúsculas alternadas para ignorar esse mecanismo de segurança.
Alguns firewalls contêm o filtro de expressão regular (regex) /union\select/g. Portanto, eles podem filtrar códigos
suspeitos escritos em letras minúsculas.
Código com caixa alternada:
http:// www.bank.com/ accounts.php?id=1+UnioN/ **/ SeLecT/ **/ 1,2,3--
ÿ Palavras-chave substituídas: alguns aplicativos e WAFs usam preg_replace para remover todas as palavras-chave SQL.
Portanto, os invasores usam a seguinte técnica de codificação para ignorar os WAFs.
Código com palavras-chave substituídas:
http:// www.bank.com/ accounts.php?id=1+UNunionION+SEselectLECT+1,2,3--
ÿ Manipulação de espaço em branco: Conforme explicado acima, quando os invasores substituem palavras-chave, alguns
WAFs podem substituir as palavras-chave por espaço em branco. Nesses casos, os invasores usam "%0b" para eliminar
o espaço e contornar os firewalls.
Código com manipulação de espaço em branco:
http:// www.bank.com/ accounts.php?id=1+uni%0bon+se%0blect+1,2,3--


Investigando o ataque de injeção de SQL: usando Regex

ÿ Os investigadores devem realizar a pesquisa regex nos arquivos de log para procurar a presença de metacaracteres específicos do SQL, como aspas simples
('), o traço duplo (--), o sinal de igual (=) e o ponto e vírgula (;) bem como seus equivalentes hexadecimais na tentativa de identificar ataques de injeção de SQL
Expressão regular para detectar metacaracteres SQL:
/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
Expressão regular modificada para detectar metacaracteres SQL:
/((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|(;))/i
Expressão regular para detectar um ataque típico de injeção de SQL:
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
Expressão regular para detecção de injeção SQL com a palavra-chave UNION:
/((\%27)|(\'))união/ix
Expressão regular para detectar ataque de injeção SQL em um servidor MSSQL:
/exec(\s|\+)+(s|x)p\w+/ix
Investigando o ataque de injeção de SQL: usando Regex
Os investigadores podem usar expressões regulares específicas para detectar ataques de injeção de SQL. Para
examinar com êxito um ataque de injeção de SQL, eles devem identificar todos os tipos de metacaracteres usados
em uma consulta SQL, como ponto-e-vírgula, traço duplo, aspas simples e sinal de menos duplo, bem como seus
equivalentes hexadecimais. Portanto, é necessário avaliar esses metacaracteres específicos do SQL ao compor
expressões regulares. Essas expressões regulares devem ser usadas para enquadrar as regras de assinatura do
Snort e definir alertas SIEM para a detecção de ataques de injeção de SQL.
As seguintes expressões regulares podem ser usadas para pesquisar metacaracteres específicos do SQL e seus
equivalentes hexadecimais:
ÿ Regex para detectar metacaracteres SQL

/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
Essa assinatura procura por metacaracteres SQL. Ele primeiro procura as aspas simples ('), seu equivalente
hexadecimal ou o traço duplo (--). Ele não procurará o equivalente hexadecimal do traço duplo, pois não
pertence ao metacaractere HTML e não pode ser codificado pelo navegador. No caso de bancos de dados
MySQL, esta assinatura também procura pelo caractere “#” ou seu equivalente hexadecimal.
ÿ Regex (modificado) para detecção de metacaracteres SQL

/((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-)|(\%3B)|(;))/i
Essa assinatura procura tentativas de injeção de SQL baseadas em erro. Ele primeiro procura o caractere
“=” ou seu equivalente hexadecimal (%3D). Posteriormente, ele procura por zero ou mais caracteres que
não sejam de nova linha e, finalmente, procura por aspas simples, hífens duplos ou ponto-e-vírgula.


ÿ Regex para Ataque Típico de Injeção de SQL
/\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
Essa assinatura procura uma string que comece com um valor alfanumérico constante, seguido por aspas simples e,
em seguida, a palavra “ou”. Por exemplo, ele detecta a string “1'or2>1--.”.
Os componentes da assinatura acima são explicados abaixo:
o \w*: Busca por zero ou mais caracteres alfanuméricos ou sublinhado.
o (\%27)|\': Procura pelo caractere (') ou aspas simples ou seu valor hexadecimal.
o (\%6F)|o|(\%4F))((\%72)|r|(\%52): Busca a palavra “ou” com várias combinações de seus valores hexadecimais
(ambos maiúsculos e combinações de letras minúsculas).
ÿ Regex para detecção de SQL Injection com a palavra-chave UNION
/((\%27)|(\'))união/ix
Esta assinatura procura por uma tentativa de injeção de SQL baseada em união onde:
o (\%27)|(\'): Pesquisa as aspas simples e seu equivalente hexadecimal.
o união: Busca pela palavra-chave “união”. Outras palavras-chave SQL, como “selecionar”, “inserir”, “atualizar” e
“excluir”, também podem ser usadas além de “união”: /((\%27)|(\'))(selecionar | união|inserir|atualizar|excluir|
substituir|truncar/dr op)/ix
ÿ Regex para detectar ataques de injeção de SQL em um MS SQL Server
/exec(\s|\+)+(s|x)p\w+/ix
Esta assinatura procura uma tentativa de injeção de SQL em um servidor MS SQL. Seus componentes são explicados
a seguir:
o exec: Procura a palavra-chave para executar um procedimento armazenado ou estendido.
o (\s|\+)+: Pesquisa espaços em branco ou seus valores codificados em HTTP.
o (s|x)p: Pesquisa as letras “sp” ou “xp” (representando procedimentos armazenados ou estendidos,

respectivamente).
o \w+: Pesquisa por pelo menos um caractere alfanumérico ou sublinhado


Examinando logs do IIS para SQL

Ataque de Injeção
A solicitação GET na entrada de log do IIS destacada contém
alguns metacaracteres SQL, alguns dos quais são codificados
Com os caracteres decodificados, a consulta Id=ORD

'
001%27%20or%201=1;-- traduz para Id=ORD-001 indica ou 1=1;-- qual
um ataque de injeção SQL
Uma análise detalhada do log do IIS forneceu as seguintes informações:
O ataque foi realizado a partir de uma máquina Linux (5) usando

o IP 10.10.10.55 (4) em 13 de dezembro de 2019 (1)
O invasor fez login no site www.luxurytreats.com hospedado no servidor IP

10.10.10.12 (2) com o nome de usuário bob e inseriu a consulta SQL
'
maliciosa ou 1=1;-- na página de detalhes do pedido (3)
Um código de status HTTP 200 (6) significa que o servidor de aplicativos da

Web processou essa solicitação, permitindo que o invasor ignore a autenticação
e acesse dados confidenciais relacionados a pedidos do banco de dados
Examinando logs do IIS para ataque de injeção de SQL
Durante a investigação de ataques de injeção de SQL em sites hospedados em servidores baseados no

Windows, os investigadores podem examinar as entradas armazenadas nos logs do IIS e procurar
metacaracteres específicos do SQL. Se uma entrada de log mostrar a injeção de qualquer comando SQL
malicioso na linha de solicitação HTTP, os investigadores forenses devem restringir a pesquisa para obter
o endereço IP do qual o ataque foi tentado, o IP do host e outras informações associadas ao ataque para
obter mais informações. análise.
A solicitação GET na entrada de log do IIS destacada na figura abaixo contém alguns metacaracteres
SQL, alguns dos quais são codificados.
Figura 9.16: Examinando uma entrada de log do IIS em busca de indicadores de ataque de injeção de SQL
Com os caracteres decodificados, a consulta Id=ORD-001%27%20or%201=1;-- traduz para Id=ORD 001

'
ou 1=1;-- que indica um ataque de injeção de SQL.


Uma análise detalhada do log do IIS forneceu as seguintes informações:
ÿ O ataque foi realizado a partir de uma máquina Linux (5) usando o IP 10.10.10.55 (4) em 13 de dezembro
de 2019 (1)
ÿ O invasor fez login no site www.luxurytreats.com hospedado no servidor IP 10.10.10.12 (2) com o nome
' (3)
de usuário bob e inseriu a consulta SQL maliciosa ou 1=1;-- na página de detalhes do pedido
ÿ Um código de status HTTP 200 (6) significa que o servidor de aplicativos da web processou essa
solicitação, permitindo que o invasor ignore a autenticação e acesse dados confidenciais relacionados
a pedidos do banco de dados


Examinando logs de alerta do Snort para ataque de injeção de SQL
ÿ Na captura de tela acima, você

pode ver que o Snort Endereço IP do atacante: 192.168.0.233 Endereço IP do servidor: 192.168.0.115
gerou um alerta para uma

tentativa de ataque de injeção
de SQL com os seguintes detalhes:
Porta de origem: 64580 Porta de destino: 80
Examinando logs de alerta do Snort para ataque de injeção de SQL
Definir regras no Snort IDS específicas para a vulnerabilidade de injeção de SQL geraria um alerta sempre que um ataque
fosse detectado. Uma vez localizado o IP de origem/ataque, os investigadores podem verificar outros arquivos de log e
ferramentas de segurança para reunir mais evidências sobre o ataque.
Figura 9.17: Examinando os logs de alerta do Snort em busca de indicadores de ataque de injeção de SQL
As entradas de log do Snort IDS na figura acima mostram três tentativas de injeção SQL do IP 192.168.0.233. Também inclui
outras informações, como as seguintes:
ÿ Endereço IP do atacante: 192.168.0.233
ÿ Porta de Origem: 64580
ÿ Endereço IP do servidor: 192.168.0.115
ÿ Porta de Destino: 80


Examinando logs SIEM para SQL

Ataque de Injeção
ÿ Aqui, um alerta acionado pelo Splunk proveniente do log do IIS mostra uma tentativa de ataque de injeção de SQL como
resultado da consulta de pesquisa (1) com os seguintes detalhes:
ÿ O ataque ocorreu em 11 de dezembro de 2019 (2) do IP 10.10.10.55 (5)

ÿ O invasor usou o navegador Firebox em uma máquina Linux (4) e enviou a consulta SQL maliciosa '
ou 1=1-- (3) para realizar o ataque
Examinando logs SIEM para ataque de injeção de SQL
As ferramentas SIEM, como o Splunk, podem ajudar os investigadores a coletar e examinar dados que indicam
um ataque de injeção SQL de várias fontes de log, como logs IDS, IIS, WAF e Apache, e protegê-los como
evidência para usá-los posteriormente para análise posterior.
Figura 9.18: Examinando uma consulta de pesquisa SIEM e alerta para indicadores de ataque de injeção SQL
A figura acima mostra um evento acionado pelo Splunk que indica uma tentativa de injeção de SQL. A fonte de
log usada aqui é um log do IIS. Este resultado foi extraído em resposta a uma consulta de pesquisa que
especifica o tipo de origem, bem como a expressão regex para a detecção de ataques de injeção de SQL (1).


Outros detalhes coletados do exame do evento Splunk são os seguintes
ÿ Data e hora do ataque: 11 de Dezembro de 2019 às 18:37:31 (2)

'
ÿ Consulta SQL maliciosa executada:ou 1=1;-- (3)
ÿ SO e navegador do atacante: Linux, Firefox (4)
ÿ Endereço IP do atacante: 10.10.10.55 (5)


Resumo do módulo
Este módulo discutiu os fundamentos forenses de aplicativos da web
Ele discutiu os Logs do Internet Information Services (IIS) e

Registros do servidor web Apache
Ele também discutiu em detalhes a investigação de ataques da Web

em servidores baseados no Windows
Este módulo também discutiu a identificação de indicadores de

comprometimento (IoCs) de logs de rede
Finalmente, este módulo terminou com uma discussão detalhada sobre detecção e
investigação de vários ataques em aplicativos da web
No próximo módulo, discutiremos em detalhes a análise forense da dark web
Resumo do módulo
Este módulo discutiu os fundamentos da análise forense de aplicativos da web. Ele discutiu logs do Internet Information
Services (IIS) e logs do servidor web Apache. Além disso, discutiu em detalhes a investigação de ataques na web em
servidores baseados em Windows. Este módulo também detalhou a identificação de indicadores de comprometimento
(IoCs) de logs de rede. Finalmente, este módulo apresentou uma discussão detalhada sobre a detecção e investigação de
vários ataques em aplicativos da web.
No próximo módulo, discutiremos detalhadamente a análise forense da dark web.


MODULE 09 - Investigating Web Attacks

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MODULE 09 - Investigating Web Attacks

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Fundamentos de Perícia Forense Digital Exame 112-53

1 Compreendendo a análise forense de aplicativos da Web

2 Noções básicas sobre os logs do Internet Information Services (IIS)

3 Compreendendo os logs do servidor Web Apache

4 Visão geral dos ataques da Web em servidores baseados em Windows

Compreendendo como detectar e investigar vários ataques em aplicativos da Web

Copyright © por EC-Council. Todos os direitos reservados. A reprodução é estritamente proibida.

Ao final deste módulo, você será capaz de:

ÿ Compreender a análise forense de aplicativos da web

ÿ Compreender os Logs dos Serviços de Informações da Internet (IIS)

ÿ Entenda os logs do servidor web Apache

ÿ Investigar ataques da web em servidores baseados em Windows

ÿ Detectar e investigar vários ataques em aplicativos da web

Módulo 09 Página 504 Digital Forensics Essentials Copyright © por EC-Council

Fundamentos de Perícia Forense Digital Exame 112-53

Entenda o IIS e o Apache Investigando ataques na Web em

Copyright © por EC-Council. Todos os direitos reservados. A reprodução é estritamente proibida.

Entenda a análise forense de aplicativos da Web

Os profissionais de segurança da informação implementam medidas de segurança específicas para detectar ou

Módulo 09 Página 505 Digital Forensics Essentials Copyright © por EC-Council

Fundamentos de Perícia Forense Digital Exame 112-53

Introdução à análise forense de aplicativos da Web

ÿ Inclui a coleta e análise de log e arquivos de configuração associados ao servidor web,

Copyright © por EC-Council. Todos os direitos reservados. A reprodução é estritamente proibida.

Introdução à análise forense de aplicativos da Web

Módulo 09 Página 506 Digital Forensics Essentials Copyright © por EC-Council

Fundamentos de Perícia Forense Digital Exame 112-53

Desafios na análise forense de aplicativos da Web

Devido à natureza distribuída dos aplicativos da Web, os rastros

Muito limitado ou nenhum tempo de inatividade é

A análise forense de aplicativos da Web requer a análise e a

Também requer conhecimento completo de diferentes servidores web,

O rastreamento é difícil no caso de proxies reversos e

Copyright © por EC-Council. Todos os direitos reservados. A reprodução é estritamente proibida.

Desafios na análise forense de aplicativos da Web

ÿ Data e hora em que o pedido foi enviado

ÿ Método HTTP usado (GET/POST)

ÿ Identificador Uniforme de Recursos (URI)

Módulo 09 Página 507 Digital Forensics Essentials Copyright © por EC-Council

Fundamentos de Perícia Forense Digital Exame 112-53

ÿ Consulta enviada via HTTP

ÿ Corpo da solicitação HTTP

ÿ Logs de eventos (dados não voláteis)

Módulo 09 Página 508 Digital Forensics Essentials Copyright © por EC-Council

Fundamentos de Perícia Forense Digital Exame 112-53

Indicadores de um ataque na Web

Clientes impossibilitados de acessar

Atividades suspeitas em contas Desempenho de rede

Vazamento de dados Reinicialização frequente

URLs redirecionando para sites incorretos

Copyright © por EC-Council. Todos os direitos reservados. A reprodução é estritamente proibida.

Indicadores de um ataque na Web

Módulo 09 Página 509 Digital Forensics Essentials Copyright © por EC-Council

Fundamentos de Perícia Forense Digital Exame 112-53

Ameaças de aplicativos da Web

Dados sensíveis Erro impróprio

Solicitação entre sites Registro e monitoramento

05 Passagem de diretório 11 Controle de acesso quebrado 17 Autenticação quebrada

Copyright © por EC-Council. Todos os direitos reservados. A reprodução é estritamente proibida.

Ameaças de aplicativos da Web

ÿ Intoxicação por Cookies

O envenenamento de cookies refere-se à modificação de um cookie para contornar medidas de segurança

Módulo 09 Página 510 Digital Forensics Essentials Copyright © por EC-Council