06-analise

26
Análise forense Sessão de aprendizagem 6 Recuperação e análise de evidências (parte 2)

description

Análise forense Sessão de aprendizagem 6 Recuperação e análise de evidências (parte 2) Recuperação e análise de evidências Análise de executáveis Análise do código Análise de core dump Slack space Sumário Recuperação e análise de evidências Regras durante uma análise de executáveis: Análise de executáveis Vamos usar como exemplo um arquivo que foi encontrado em uma sessão anterior: Análise de executáveis Arquivo suspeito criado no período da invasão: Comece a procurar pelas informações mais fáceis:

Transcript of 06-analise

Page 1: 06-analise

Análise forense

Sessão de aprendizagem 6

Recuperação e análise de evidências (parte 2)

Page 2: 06-analise

Sumário

Recuperação e análise de evidências

Análise de executáveis

Análise do código

Análise de core dump

Slack space

Page 3: 06-analise

Recuperação e análise de evidências

Arquivos, partes de logs, timestamps ou ferramentas

podem comprovar atividades realizadas pelo invasor.

Muitas vezes estas evidências não são suficientes para

obter uma imagem completa das atividades do invasor.

Outras vezes, a quantidade reduzida de evidências

coletadas impede a montagem de uma seqüência lógica de

eventos.

Aprenderemos a analisar evidências em arquivos de core

dump e a examinar arquivos binários.

Descobriremos como os invasores utilizam os espaços

desperdiçados no fim dos blocos de dados para ocultar

evidências.

Page 4: 06-analise

Análise de executáveis

Regras durante uma análise de executáveis:

Jamais execute o programa em sua estação forense; utilize uma máquina separada e isolada exclusivamente para isso

A máquina de análise não deve estar conectada na internet

Inicie a análise com ferramentas mais simples, como file,

strings e ldd

Somente após coletar todas as informações possíveis com estas ferramentas é que deve ser feita uma engenharia reversa do código

Em último caso deve-se executar o programa em um ambiente controlado e isolado da rede

Jamais confie em um programa suspeito

Page 5: 06-analise

Análise de executáveis

Vamos usar como exemplo um arquivo que foi

encontrado em uma sessão anterior:

# find /mnt/image/ -anewer /mnt/image/dev/hdx1 -ls�

...

92030 664 -rwxr-xr-x 1 root root 672527 Sep 4 2002 /mnt/image/usr/bin/smbd\ -D

Page 6: 06-analise

Análise de executáveis

Arquivo suspeito criado no período da invasão:# istat /data/compromised/compromised_hda1.img 92030����

inode: 92030

uid / gid: 0 / 0

mode: -rwxr-xr-x

size: 672527

Accessed: Sun Aug 10 16:54:18 2003

File Modified: Wed Sep 4 00:54:10 2002

Inode Modified: Sun Aug 10 14:33:33 2003

Page 7: 06-analise

Análise de executáveis

Comece a procurar pelas informações mais fáceis:# file /mnt/image/usr/bin/smbd\ -D�

/mnt/image/usr/bin/smbd -D: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped

# cp /mnt/image/usr/bin/smbd\ -D ‘/data/compromised/smbd –D’�

# ldd /data/compromised/smbd\ -D�

linux-gate.so.1 => (0xffffe000)

libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7f42000)

libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb7f14000)

libutil.so.1 => /lib/tls/libutil.so.1 (0xb7f0f000)

libc.so.6 => /lib/tls/libc.so.6 (0xb7ddd000)

Page 8: 06-analise

Análise de executáveis

Uma procura por strings dentro do executável pode fornecer informações

muito úteis:

# strings -a ‘/data/compromised/smbd –D’�

/lib/ld-linux.so.2

libcrypt.so.1

/usr/include//iceconf.h

By-ICE_4_All ( Hackers Not Allowed! )

sshd version %.100s [%.100s]

Bind to port %d failed: %.200s.

Server listening on port %d.

Connection from %.100s port %d

SSH-%d.%d-%.50s

Your ssh version is too old and is no longer supported. Please install a newer version.

+-[ User Login Incoming ]----------- --- --- - -

| username: %s password: %s%s hostname: %s

ROOT LOGIN as '%.100s' from %.100s

/usr/include//icekey.h

/usr/include//iceseed.h

Page 9: 06-analise

Análise de executáveis

Podemos ver indicações de possíveis arquivos para procurar

no disco:# ls -li /mnt/image/usr/include/ice*�

92015 -rw-r--r-- 1 root root 692 May 16 2003 /mnt/image/usr/include/iceconf.h

91850 -rw------- 1 root root 539 May 24 2002 /mnt/image/usr/include/icekey.h

3176 -rw-r--r-- 1 root root 5 Aug 10 2003 /mnt/image/usr/include/icepid.h

92007 -rw------- 1 root root 512 Aug 10 2003 /mnt/image/usr/include/iceseed.h

# file /mnt/image/usr/include/ice*�

/mnt/image/usr/include/iceconf.h: ASCII text

/mnt/image/usr/include/icekey.h: data

/mnt/image/usr/include/icepid.h: ASCII text

/mnt/image/usr/include/iceseed.h: data

Page 10: 06-analise

Análise de executáveis

Arquivo de configuração de servidor SSH:

# cat /mnt/image/usr/include/iceconf.h �# This is ssh server systemwide configuration file.

Port 2003

ListenAddress 0.0.0.0

HostKey /usr/include//icekey.h

RandomSeed /usr/include//iceseed.h

ServerKeyBits 768

LoginGraceTime 600

KeyRegenerationInterval 1

PermitRootLogin yes

Page 11: 06-analise

Análise de executáveis

Chave privada do servidor com identificação do

usuário que a gerou:

# strings -a /mnt/image/usr/include/icekey.h�

SSH PRIVATE KEY FILE FORMAT 1.1

"0w:

RXqU_C

[email protected]}

z>'|E

b9jH2

\=?0

;d-)

L=7~=

(e8

Page 12: 06-analise

Análise do código

Após conseguir o máximo de informações sobre o

programa, o analista realiza a engenharia reversa do

programa.

Realizar a engenharia reversa significa transformar o

código de máquina novamente em código-fonte, para

analisar as funções do programa.

Pode revelar funções obscuras do programa.

Este conhecimento pode ser útil para evitar novas invasões ou para eliminar as que ainda existem.

Page 13: 06-analise

Análise do código

Diversas ferramentas fazem engenharia reversa de

código:

OllyDBG

IDA Pro

Entre outras

LDasm:

Ferramenta escrita em Perl, com interface gráfica para Linux

Não faz parte do CD do Helix# /data/tools/LDasm0.04.53/bin/ldasm

Page 14: 06-analise

Análise do código

Page 15: 06-analise

Análise do código

O investigador pode executar o programa em um

ambiente controlado e isolado.

O primeiro passo é encontrar o ponto de início do

programa:

# nm /data/compromised/smbd\ -D�

08054ccc T MD5Final

08054be0 T MD5Init

...

08049b84 ? _init

Page 16: 06-analise

Análise do código

Executando o programa com o depurador:# /data/tools/gdb/bin/gdb /data/compromised/smbd\ -D�

(gdb) b * 0x08049b84Breakpoint 1 at 0x8049b84

(gdb) runStarting program: /data/compromised/smbd -D Breakpoint 1, 0x08049b84 in _init ()

(gdb) stepi0x08049b85 in _init ()

(gdb) bt#0 0x08049b85 in _init ()#1 0xb7df3e5d in __libc_start_main () from /lib/tls/libc.so.6#2 0x0804a501 in _start ()

(gdb) disassemble 0x08049b85 0x08049baaDump of assembler code from 0x8049b85 to 0x8049baa:0x08049b85 <_init+1>: mov %esp,%ebp

Page 17: 06-analise

Análise de core dump

Arquivos de core dump podem fornecer boas pistas

sobre o invasor

Gerados quando algum programa executa uma operação ilegal e é encerrado pelo sistema

Gerados quando algum programa executado não foi terminado corretamente

Armazenam uma cópia da memória do programa no momento em que ocorreu a falha

Guardam todas as informações sobre o arquivo que o gerou, para que o programador possa descobrir o que causou o erro.

Page 18: 06-analise

Análise de core dump

Examinando o arquivo /data/compromised/smbd-D.core, podemos

encontrar informações interessantes sobre o programa:

# strings -a /data/compromised/smbd-D.core ����smbd -D

/data/compromised/smbd -D

Linux

Helix

/data/compromised/smbd –D

SSH_CLIENT=192.168.47.1 4062 22

USER=root

PWD=/root

LOGNAME=root

SSH_CONNECTION=192.168.47.1 4062 192.168.47.129 22

Page 19: 06-analise

Análise de core dump

Um arquivo core dump tem algumas informações importantes

sobre a ferramenta que o gerou:

Nome original do executável

Nome do usuário que executou o programa

Cópia das variáveis de ambiente no momento da execução

Possivelmente informações sobre a conexão SSH do invasor (variável $SSH_CLIENT)

Informações sobre o que causou o fim prematuro do programa e a geração do core dump

Se tivermos o binário original, podemos utilizar o gdb para examinar o arquivo de core dump juntamente com o binário e descobrir o que aconteceu no momento da falha

Page 20: 06-analise

Slack space

A busca por arquivos deixados pelo invasor pode ser

demorada, exigindo paciência e dedicação.

O que acontece quando a evidência que procuramos

foi escondida intencionalmente, de forma que não seja

possível encontrá-la com as ferramentas que vimos

até agora?

Existem técnicas para esconder a informação, através

das quais o dado escondido não pode ser identificado

mesmo que se tenha acesso ao arquivo onde está

armazenado.

Um exemplo é a técnica chamada de Esteganografia.

Page 21: 06-analise

Slack space

Vimos que quando um arquivo tem um tamanho menor que o

tamanho do bloco, o espaço restante é desperdiçado. Este

espaço é conhecido como slack space.

O slack space é usado como técnica para esconder

informação.

Os blocos de dados são as menores estruturas possíveis em

um sistema de arquivos.

Isto acontece porque cada bloco pode estar alocado por

apenas um inode de cada vez, e cada inode está associado a

um único arquivo.

slack space dados do arquivo

Bloco de dados

Page 22: 06-analise

Slack space

Exemplo:

# du -sb /data/dirt_list.txt�

60 /data/dirt_list.txt

# du -sk /data/dirt_list.txt�

4 /data/dirt_list.txt

Mas o que isso tem a ver com esconder informação?

Contando que este espaço desperdiçado sempre vai existir, foram desenvolvidas ferramentas para esconder informações nele.

O bmap é uma ferramenta para esconder dados no slack space

de qualquer arquivo, ou até mesmo em um diretório inteiro, e

depois recuperar essas informações quando for necessário.

Page 23: 06-analise

Slack space

Exemplos:

# bmap --mode slackbytes /data/dirt_list.txt�

4036

# cat /data/badfiles_hashs.sha1 | bmap --mode putslack /data/dirt_list.txt�

stuffing block 1540604

file size was: 60

slack size: 4036

block size: 4096

# bmap --mode slack /data/dirt_list.txt�

getting from block 1540604

8bc99cf58caca6e4c1c5d8eca5c59ecc01d4cc9f /bin/chmod

44bb98736c677c1c86d4fc984e66002fff9fccf5 /bin/echo

Page 24: 06-analise

Slack space

Vejamos alguns exemplos:

# dcat /dev/sda5 1540604 | hexdump -C�

00000000 74 74 79 6f 70 0a 74 74 79 6f 61 0a 74 74 79 6f |ttyop.ttyoa.ttyo|

00000010 66 0a 68 64 78 31 0a 68 64 78 32 0a 73 73 68 64 |f.hdx1.hdx2.sshd|

00000020 20 76 65 72 73 69 6f 6e 0a 42 61 73 68 20 76 65 | version.Bash ve|

00000020 20 76 65 72 73 69 6f 6e 0a 42 61 73 68 20 76 65 | version.Bash ve|

00000030 72 73 69 6f 6e 0a 5c 77 40 5c 77 0a 38 62 63 39 |rsion.\w@\w.8bc9|

# ls -l /data/dirt_list.txt�

-rw-r--r-- 1 root root 60 Jan 6 17:24 /data/dirt_list.txt

# cat /data/compromised/smbd-D.core | slacker --mode fill /data/tools�

# slacker --mode pour /data/tools > /tmp/test.dat�

Page 25: 06-analise

Slack space

Nenhuma ferramenta que verifique a integridade do

sistema vai acusar a presença destes dados.

Se o arquivo for apagado o bloco de dados pode ser

alocado em outro arquivo e a informação no slack

space pode ser sobrescrita.

O mesmo acontece se o arquivo que utilizamos para

armazenar a informação aumentar de tamanho.

Por isso, esta informação é considerada volátil.

Existem ferramentas que permitem criar um sistema

de arquivos completo dentro do slack space de um

diretório.

Page 26: 06-analise

Conclusões

Apenas recuperar arquivos apagados pode não ser suficiente

Em alguns casos, precisamos nos aprofundar nas provas, e

descobrir as funcionalidades de um executável desconhecido

Podemos descobrir informações sobre o programa com

ferramentas básicas ou realizar uma análise avançada, fazendo

a engenharia reversa do código ou executando o programa em

ambiente controlado

A análise do conteúdo de arquivos core dump pode fornecer

informações sobre o invasor e a ferramenta

Precisamos procurar até mesmo onde nem imaginamos haver

informação, como no slack space dos blocos de disco