Praça João Lisboa Gestão de Reclamação ANALISE São Luis, 06/09/2011.
06-analise
-
Upload
clayton-santos -
Category
Documents
-
view
220 -
download
3
description
Transcript of 06-analise
Análise forense
Sessão de aprendizagem 6
Recuperação e análise de evidências (parte 2)
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
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.
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
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
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
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)
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
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
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
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
z>'|E
b9jH2
\=?0
;d-)
L=7~=
(e8
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.
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
Análise do código
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
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
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.
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
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
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.
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
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.
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
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�
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.
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