• Olá Visitante, se gosta do forum e pretende contribuir com um donativo para auxiliar nos encargos financeiros inerentes ao alojamento desta plataforma, pode encontrar mais informações sobre os várias formas disponíveis para o fazer no seguinte tópico: leia mais... O seu contributo é importante! Obrigado.

Técnicas forenses para identificação da invasão e do invasor em sistemas Unix/Linux 2

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Veremos neste artigo uma pequena contribuição sobre algumas das ferramentas e sua utilização na perícia forense em sistemas UNIX/Linux para comprovação da autoria de ataques e/ou invasão através do serviço de Secure Shell - SSH.

Por: Matuzalém Guimarães


Indícios da invasão
Segundo Murilo; Steding-Jessen (2001), basicamente os ataques a sistemas computacionais seguem uma seqüência padrão, o que permite que sejam implantadas barreiras de proteção visando inibir ou dificultar a ação do atacante.

Murilo; Steding-Jessen (2001) enfatizam que o ciclo de ataque é iniciado com a varredura do sistema em busca de alguma vulnerabilidade a ser explorada com o intuito de obter acesso ao sistema. Uma vez invadido o sistema, o atacante busca meios de não ser detectado e a garantia da continuidade, para isso são utilizadas normalmente ferramentas de backdoors. A figura 1 mostra um ciclo básico das ações de um atacante.



1230522760.figura_1.jpg


Figura 1 - Ciclo básico de uma invasão / fonte: Steding-Jessen (2001)

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Ainda segundo os autores, o uso de ferramentas de rootkit é normalmente usado pelo invasor a fim de não ser identificado e garantir seu acesso através da instalação de backdoors no sistema atacado.

Ainda segundo os autores, os rootkits são essencialmente coleções dessas ferramentas, utilizadas por invasores após o comprometimento de um sistema. Em conjunto, costumam incluir executáveis para monitorar o teclado (keyloggers), registrar tráfego de rede (sniffers), permitir acesso irrestrito ao sistema mesmo sem uma conta válida e, principalmente, esconder tudo que foi feito.

Segundo Borchardt (2002), os rootkits que usam módulos de kernel são conhecidos por rootkit de LKM (loadable kernel modules), estes são carregados dinamicamente no kernel, alterando assim a sua funcionalidade original, sem a necessidade de uma reinicialização. Outras implementações de rootkits funcionam alterando comandos do sistema para esconder informações referentes à presença do atacante, como conexões de rede, arquivos, processos etc.

Ainda segundo o autor, a detecção de rootkits de LKM torna-se difícil, pois os comandos do sistema não são alterados, sendo que o kernel do sistema continuará a responder às requisições de forma normal, ocultando assim a presença do atacante.

Nemeth; Snyder; Seebass; Hein (2001) afirmam que algumas ferramentas automatizadas podem auxiliar na tarefa de identificação de alterações no sistema após uma falha de segurança, o uso da ferramenta tripwire. Segundo os autores esta ferramenta monitora as permissões e realiza cheksum de arquivos de sistemas importantes para que seja possível detectar arquivos que foram substituídos, corrompidos ou manipulados.

O tripwire verifica arquivos em comparação com um bando de dados que registra suas características e checksums no momento em que o banco de dados foi criado. Ele trabalha com uso da ferramenta diff para diferenciar o sistema de arquivos em relação a essa base de referência.

Murilo; Steding-Jessen (2001) esclarecem que além dos processos, conexões de rede também podem revelar pistas de uma invasão, tais como o endereço IP usado pelo atacante para se conectar ao sistema. Um dos comandos usados em sistemas Unix que permite listar todos os sockets IP locais e o protocolo utilizado é o netstat. Além deste outros comandos como o whois e o traceroute podem revelar mais informações sobre endereços IP, essas informações dificilmente podem ser corroboradas pelo atacante.

Os autores ainda afirmam que com o uso do comando dmesg poderá ser revelada uma interface de rede trabalhando em modo promíscuo o que vem a revelar uma possível captura de dados na rede.

Uma técnica simples, mas efetiva, é analisar o próprio arquivo binário de algum programa suspeito, com a finalidade de encontrar caracteres imprimíveis no arquivo. Os autores enfatizam que utilizando o comando strings com o argumento "-a" mais o "binário". Caso algum programa suspeito se conecte a um serviço, pode ser possível encontrar a senha no código do programa, porém, se faz necessária certa expertise para diferir entre informações pertinentes nos caracteres listados na saída exibida do programa.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Ferramentas para coleta de dados
Heiser; Kruse (2001) alertam que a coleta de dados é uma das etapas mais sensíveis de uma investigação forense computacional, pois nesta fase qualquer descuido por parte do investigador poderá interferir diretamente na validação das evidências coletadas.

Cagnani; Santos (2008) defendem que o tipo de dado envolvido no incidente que está sendo investigado, também é importante na determinação do tipo de análise e ferramentas que serão utilizadas na perícia. Os autores sugerem dois tipos de dados a serem investigados, os dados voláteis e os não-voláteis, estes podem ser observados na tabela 1.



tabela_1.jpg


Tabela 1 - Dados Voláteis e Não-Voláteis / adaptado Cagnani; Santos (2008)

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
São considerados voláteis segundo os autores todos os dados não gravados em algum tipo de mídia permanente, ou seja, os dados que são gerados em tempo de execução, que serão perdidos se a máquina envolvida for desligada. E são considerados como dados não-voláteis, todos os dados gravados de forma permanente ou não em algum tipo de mídia, ou seja, os dados que mesmo que sejam considerados temporários pelo Sistema que ainda estejam gravados em disco, podendo ser recuperados depois que a máquina seja desligada.

Para a coleta de dados voláteis Junior; Saúde; Cansian (2005) sugerem o uso das ferramentas listadas na tabela 2.

thumb_tabela_2.jpg

Tabela 2 - Ferramentas para coleta de dados voláteis / adaptado de Cagnani; Santos (2008)

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
E para coleta de dados não voláteis Junior; Saúde; Cansian (2005) sugerem o uso das ferramentas listadas na tabela 3.

tabela_3.jpg




 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Análise dos dados
Este trabalho dá ênfase apenas às ferramentas necessárias para análise de dados relativos a ataques e a invasão consumada em sistemas Unix, a fim de comprovar a autoria do atacante. Sendo, portanto a análise de log, gerados no sistema por ataques ao serviço de SSH e por ferramentas que visam proteger este sistema o foco desta análise.

A análise dos dados coletados envolve selecionar quais as informações terão relevância para o caso em questão. Para o levantamento de informações sobre tentativas de ataques e invasão a sistemas Unix através do serviço de SSH deverão ser analisados os logs gerados pelo sistema e por outras ferramentas usadas para proteção do serviço no sistema atacado a fim de reconstituir as ações do atacante/invasor.

Para esta atividade o grupo Security Incident Response Team (CSIRT) da Rede Nacional de Pesquisa (RNP) recomenda o uso de analisadores de log que são ferramentas que verificam logs gerados por um sistema e os organiza para facilitar a interpretação. Eles geram sumários com os logs que realmente importam para o investigador. Geralmente a edição de regras ocorre através de expressões regulares, que definem quais mensagens deverão ser retornadas e quais deverão ser descartadas pelo investigador. Dentre as ferramentas utilizadas para analisar atividades desta natureza um dos destaques, segundo o CSIRT é o Logwatch.

Esta ferramenta, segundo o CSIRT é um software escrito em Perl que utiliza scripts e configurações específicas para cada arquivo de log. Sendo capaz de definir quais mensagens são importantes, de acordo com o nível de detalhes (0 a 10) definido pelo investigador. A figura 2 mostra o relatório sobre o serviço de SSH, onde pode ser observado o registro das quantidades de tentativas de login efetuados por cada usuário e os endereços de IP de cada requisição.


1230522760.figura2.jpg


Figura 2 - Relatório gerado pela ferramenta logwatch
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Farmer; Venema (2007) afirmam que em uma análise forense, o dado bruto não fornece nenhuma informação sobre o fato ocorrido no sistema. Todavia com a esquematização dos dados em uma linha cronológica, poderá revelar alguma informação útil para a investigação. O uso da ferramenta mactime auxilia o investigador neste processo.

MACtime segundo os autores também é um conjunto de abreviações referentes aos atributos que compõe um arquivo em sistemas Unix:
a.mtime, sendo este uma referência ao tempo de modificação e revela o ultimo momento de acesso ao arquivo;
b.atime, referencia o último momento em que ocorreram modificações no conteúdo e no meta-dados do arquivo;
c.ctime, revela o último momento em que ocorreu alguma modificação no conteúdo do arquivo.

De acordo com Junior; Saúde; Cansian (2005) a ferramenta mactime faz parte de conjunto de ferramentas forense Sleuthkit que visa tornar essa fase pericial mais clara de ser analisada, uma vez que ela constrói automaticamente uma linha de tempo de acordo com uma base de dados gerada pela ferramenta forense mac-robber. Sendo desta forma possível tentar uma reconstituição de fatos ocorridos no sistema co-relacionando eventos isolados de forma a identificar as ações do invasor no sistema.

A figura 3 mostra um relatório gerado pela ferramenta mactime.

1230522760.figura3.jpg


Figura 3 - Relatório gerado pelo software mactime / Fonte: Farmer; Venema (2007)

Pode-se observar que em 19 de julho, às 16:47, um usuário identificado como root criou e descompactou um arquivo de formato de compactação tar. O nome do arquivo sugere que este seja um substituto para o serviço de SSH. Esta operação foi executada em um diretório incomum para operações desta natureza. Logo após foi criado um usuário denominado "sue" e desconectou-se do sistema as 16:57.

Farmer; Venema (2007) afirmam que posse destas informações o investigador será capaz de inferir com precisão alguma das atividades realizadas durante o tempo em que o atacante permaneceu logado no sistema, como por exemplo, a instalação de backdoors, criação de arquivos ou diretórios ocultos, execução de programas, download de outros softwares, alteração nas bibliotecas do sistema etc.
 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
Identificação do invasor


A identificação do atacante em um sistema Unix perpassa por uma série de possíveis análises, sendo a análise de logs a que permite uma comprovação mais eficiente em se tratando de invasões de sistemas Unix com quaisquer outros objetivos.

Segundo Soalha (1999) sistemas configurados de forma correta podem colaborar na identificação do invasor. Durante a análise de logs são identificados os endereços de origem das tentativas de ataques, bem como conexões usadas durante a invasão propriamente dita. Os sistemas Unix normalmente armazenam seus arquivos de log no diretório "/var/log".

A seguir são apresentados alguns dos arquivos de log encontrados neste diretório, sua descrição e será evidenciado de forma mais profunda os arquivos mais significativos para identificação de um invasor, segundo a autora.


a) utmp e utmpx


Aqui são registradas as informações referentes aos usuários locais que estão conectados atualmente no sistema. Os dados contidos nestes arquivos são armazenados em formato binário, sendo necessário o uso de outros comandos, como: who, whodo, write, finger e ps, os quais exibem as informações contidas neste arquivo.


b) wtmp e wtmpx


Aqui são registrados dados detalhados sobre uma determinada sessão aberta pelo usuário. Da mesma forma que os arquivos mostrados anteriormente, os dados contidos nestes arquivos são armazenados em formato binário e legíveis unicamente através de comandos do tipo: last, acctcom etc.


c) lastlog


Esta ferramenta registra ao horário da última vez em que o usuário tentou acessar o sistema, tenha efetuado o login com sucesso ou não.

 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
d) messages
Neste arquivo serão registradas quaisquer mensagens enviadas ao console, tendo sido gerada pelo kernel do sistema ou por algum mecanismo de log.

Soalha (1999) esclarece que a maior dificuldade de identificação de informações relevantes na análise de logs é o grande volume de dados gerados diariamente por eventos relacionados ao sistema.

A figura 4 mostra diversas tentativas de invasão usando o método de brute force abordado anteriormente, as informações referentes a este ataque foram listadas no arquivo de log messages.

figura4.jpg

Figura 4 - Registro de tentativas no arquivo de log messages

No arquivo foi possível identificar a data do ataque (20 de Novembro), o horário (16:40), o usuário utilizado para tentativa de acesso ao sistema (admin) e o endereço IP de onde partiu o ataque (164.41.55.5).


 

helldanger1

GForum VIP
Entrou
Ago 1, 2007
Mensagens
29,631
Gostos Recebidos
1
De posse destas informações, pode-se encontrar através da ferramenta whois, disponível no órgão responsável pelo registro de endereços IPs utilizados na América Latina e Caribe, através do site lacnic.net, a quem está concedida a utilização dessa faixa de endereçamento IP.

A consulta do endereço ip 164.41.55.5 através da ferramenta whois irá localizar as informações dos responsáveis pela utilização deste endereço, estes dados podem ser vistos na figura 5.

figura5.jpg

Figura 5 - A ferramenta Whois exibe informações sobre o responsável pelo endereço IP



As informações relatadas pela ferramenta whois mostram que a Universidade de Brasília detém a licença de uso para a faixa de endereçamento IP 164.41/16 de onde partiram os ataques, permitindo assim através das informações do responsável, uma ação conjunta para a identificação do atacante.

Um ponto que aqui deve ser considerado é que a comprovação da origem do ataque não quer dizer que a identidade do atacante/invasor foi revelada. Isso dependerá de outro tipo de análise pericial na máquina de onde partiram os ataques ou invasões.






 
Topo