509 | 4509 Técnicas de Computaçao Forense
www.4linux.com.br
Conteúdo
i
Capítulo 1 Computação Forense 1.1 Introdução e terminologia A computação forense é a ciência de identificar, preservar, coletar, analisar o e apresentar informações obtidas a partir de computadores e mídias de armazenamento. Ela foi criada para suprir a necessidade da lei de colher evidências de meios digitais, devido à óbvia utilização de meios digitais e índices crescentes de incidentes que utilizam estes meios. As técnicas utilizadas na computação forense são muitas e exigem um profundo conhecimento da tecnologia analisada. Numa linguagem simples, é uma grande análise de acontecimentos passados num ambiente computacional, geralmente envolvendo aspectos jurídicos como crimes, desrespeito às normas corporativas, mal comportamento, dentre outros. Um bom exemplo de necessidade de um especialista em computação forense é o vazamento de dados. Imagine uma situação fictícia em que João, diretor da empresa Dexter, se depara com a planilha de salários de sua empresa divulgada publicamente na internet. Além de tomar as providências para remover a planilha da internet, é preciso descobrir como, quando e quem foi o responsável por esta atitude antiética e passível de punição. Para isso, João pode contratar um especialista em
1
1.2 Estratégias de investigação
4Linux – www.4linux.com.br
computação forense, que vai fazer análises no parque computacional da empresa para chegar à máquina que iniciou o vazamento de dados e, consequentemente, à pessoa responsável por tal ação. Todas as informações serão colocadas em um relatório, que será o objeto fim da investigação.
É importante frizar que nem sempre a necessidade é na esfera crminalística. O exemplo acima não é um crime, mas exige atenção de um especialista.
Infelizmente, por falta de padronização, há vários termos que podem gerar confusão como: perícia forense, forense computação, investigação digital, forense digital, perícia digital, dentre outros usados comumente para descrever a mesma ciência. Normalmente o termo forense digital ou investigação digital é empregado quando o escopo não abrange somente computadores, mas também smartphones, tablets e outros dispositivos digitais. Já o trabalho de perícia, tem a ver com o adjetivo perito , usado para descrever pessoa extremamente hábil e conhecedora de algum assunto.
Acostume-se também com os termos em inglês: computer forensics, computer forensic science, digital research e digital forensic science .
1.2 Estratégias de investigação A estratégia adequada para a investigação vai depender do tipo de caso mas normalmente segue uma sequência lógica que envolve indetificação da evidência, preservação, coleta, análise e apresentação. Alguns autores e investigadores subdividem
Página 2
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
1.2 Estratégias de investigação
estes cinco estágios ou alteram sensivelmente sua ordem. Tudo depende da experiência do especialista, do tipo de caso e de como a situação se apresenta. Estudaremos a seguir as cinco macro etapas da computação forense:
1.2.1 Identificação
Nesta etapa todas as fontes de prováveis evidências devem ser consideradas e registradas. Desde câmeras de vigilância até pen drives soltos sobre a mesa, todos os aparelhos envolvidos no caso devem ser considerados. Segue uma lista parcial de itens a serem considerados: • Drives ópticos e magnéticos • Teclado • Mouse/Touchpad • Scanners • Discos externos • KVMs (switches de video, teclado e mouse) • Documentos impressos Tudo deve ser anotado por você. É essencial fotografar também. Nesta etapa que você define o que será preservado, ou seja, o que é importante para a investigação, além de registrar o estado de todas as evidências antes de você manipulá-las. Isso vai ajudar a provar a integridade das fontes de informação, se necessário.
Técnicas de Computaçao Forense
Página 3
1.2 Estratégias de investigação
4Linux – www.4linux.com.br
1.2.2 Preservação Os dados que estão presentes nas fontes de informações que você enumerou na etapa anterior também precisam ter sua integridade garantida e é exatamente o que acontece nesta etapa. A ideia é que você não cause nenhuma alteração nas evidências quando começar a coletá-las. Um bom exemplo é a descarga elétrica estática (do inglês ESD: Eletrical Static Discharge) que o contato físico com um hardware sensível pode causar e fazer com que os dados tenham sua integridade comprometida. A ocorrência de uma ESD depende de fatores como nível de carga no corpo, umidade relativa do ar no ambiente dentre outros fatores físicos, mas é possível até mesmo danificar uma placa de circuito simplesmente ao enconstar nela. Para evitar esta desagradável surpresa, existem pulseiras antiestáticas como a da foto abaixo.
Nesta etapa você também vai decidir se desliga ou não os aparelhos que contém as evidências. Existe um ditado que diz: Se está ligado, não desligue e se está desligado, não ligue . No entanto, nem sempre ele é válido. Pode haver casos onde o ambiente está sob ataque e desligar (ou desconectá-lo da rede, se for o caso) pode ajudar a minimizar os prejuízos. Você deve estudar as vantagens e desvantagens de cada ação para o seu caso a fim de tomar a medida mais viável. É possível também que você tenha que decidir entre desligar os computadores de maneira tradicional, solicitando ao sistema operacional que inicie o processo de
Página 4
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
1.2 Estratégias de investigação
desligamento, ou se você vai simplesmente desconectar a energia da fonte de alimentação. Esta última ação pode parecer muito bruta, mas evita que o sistema altere arquivos, escreva em logs e mude significativamente o estado dos dados. Inclusive um malware pode se apagar ou tomar outra ação antiforense (estudaremos este assunto no capítulo 7) ao detectar que a máquina está sendo desligada. Em contrapartida, desconectar a energia do computador pode corromper dados. Os especialistas em banco de dados provavelmente ficarão muito preocupados se você disser que vai fazer isso num servidor de banco em produção, portanto avalie sempre! Bloquear dispositivos contra gravação, seja por hardware ou por software também é uma boa ideia nesta etapa. Antes de coletar os dados, é essencial criar um hash das mídias envolvidas no processo, tentando ser o menos intrusivo possível e com bloqueios contra escrita. Após a coleta dos dados (que veremos com detalhes no capítulo 2), estes hashes devem ser checados e precisam ser idênticos, salvas exceções onde não é possível bloquear a mídia contra escrita e haja escrita constante. Neste caso, cada cópia da mídia terá um hash diferente e uma cópia acompanhada deve ser validada individualmente. O hash é utilizado para checagem de integridade. MD5, SHA-1, SHA-256 e SHA-512 são exemplos de algoritmos usados atualmente com este propósito (CRC32 e MD4 estão em desuso).
Algoritmos de hashing são algoritmos matemáticos que realizam operações com todos os dados de uma entrada (um texto, um arquivo etc) e geram um resultado (normalmente um número) de tamanho fixo chamado de hash. São conhecidos por sua característica one-way (numa só direção), ou seja, não é possível obter o dado original a partir do hash, mas se o mesmo algoritmo é aplicado a uma cópia idêntica do dado original, o hash resultante será o mesmo.
Técnicas de Computaçao Forense
Página 5
1.2 Estratégias de investigação
4Linux – www.4linux.com.br
1.2.3 Coleta
A etapa mais importante do processo é realizar a coleta de forma adequada. Nesta etapa o especialista precisa extrair dados do parque de máquinas onde o incidente ocorreu, que pode incluir dados em memórias voláteis ou não voláteis, além de outras informações úteis para a próxima etapa da análise. Todo o trabalho aqui deve ser feito para gerar o menor impacto possível na máquina, ou seja, quanto menos alterações em memória e em disco o especialista causar para coletar os dados, menos dados são perdidos na coleta. A este impacto dá-se o nome de footprint . Instalar um programa para realizar a coleta é uma ação que normalmente gera um footprint considerável uma vez que o programa de instalação precisa ser carregado em memória e vários arquivos são criado e/ou alterados durante a instalação, por isso na coleta recomenda-se utilizar ferramentas existentes em um pen drive ou mídia similar, funcionais para o SO alvo e evitar qualquer alteração no disco rígido das máquinas onde a coleta será realizada. Logicamente não há como evitar alterações na memória RAM das máquinas que farão parte da investigação, uma vez que os softwares utilizados para a coleta precisam ser carregados. No entanto, deve ser dada preferência aos softwars com menor footprint, ou seja, os executáveis otimizados que não utilizam muita RAM para funcionarem. Nesta etapa também se precisa calcular os hashes dos arquivos coletados e imagens geradas, para que sejam incluídos no relatório da etapa de apresentação.
Lembre-se que uma análise em dados coletados pode ser refeita várias vezes, mas a coleta em si normalmente não. Portanto, esta etapa de coleta deve ser minuciosa e muito bem estudada. Qualquer perda de dados pode ser irrecuperável e comprometer a abrangência da análise com consequências diretas na qualidade da investigação como um todo.
Página 6
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
1.2 Estratégias de investigação
1.2.4 Análise Esta é a parte mais engenhosa e demorada do trabalho do especialista em computação forense. Aqui é onde se aplicam as técnicas e o maior conhecimento é exigido. Nesta etapa você vai procurar evidências que tenham a ver com seu caso, em lugares prováveis primeiramente mas sem excluir os locais de menor probabilidade. Por exemplo, se estiver investigando um caso de invasão de um servidor, provavelmente um bom local para começar é o log do firewall ou da aplicação comprometida. O importante é definir o que está sendo procurado. Sem saber o que se procura, a análise pode demorar muito ou mesmo nunca terminar e o trabalho do perito será ineficiente. Normalente o esforço é concentrado em imagens (cópias perfeitas) de mídias de armazenamento e dumps de memória mas pode haver outros itens para serem analisados, como captura de tráfego de dados num firewall. Nesta etapa várias ferramentas podem ser utilizadas, assim como técnicas de análise manual, que aprenderemos mais à frente. Abaixo uma lista de distribuições Linux que agregam várias ferramentas específicas para computação forense. Seu uso não é obrigatório, mas é importante conhecê-las: BackBox Linux distribuição para pen tests e testes de segurança que objetiva ser
rápida e com o mínimo de pacotes possíveis. BackTrack famosa distribuição com uma grande coleção de ferramentas se segu-
rança, incluindo o nacional T50. CAINE (Computer Aided INvestigative Environment) é uma das principais distribuições
de auxílio ao especialista em computação forense, com softwares para todas as etapdas de uma investigação, inclusive geração de relatórios semiautomática. DEFT Linux (Digital Evidence and Forensic Toolkit) distribuição fácil de usar que
Técnicas de Computaçao Forense
Página 7
1.2 Estratégias de investigação
4Linux – www.4linux.com.br
reúne algumas das melhoras aplicações de código aberto para resposta à incidentes e computação forense. FDTK distribuição brasileira para computação forense, com muitos programas e de
fácil utilização. Helix uma das mais antigas distribuições focadas em computação forense, com
muitas aplicações da área. Matriux distribuição para pen test e computação forense baseada em Debian, com
cerca de 300 aplicações da área e até kernel personalizado. NetSecL distro com foco em segurança baseada no OpenSUSE. É instalada com
portas de entrada fechadas, sem serviços (daemons) de rede rodando e com várias outras configurações hardcore de segurança. STD - Security Tools Distribution foco em segurança de rede e informação com
muitas ferramentas. Swift Linux leve distribuição baseada com ferramentas para computação forense e
recuperação de dados.
Não se esptante com o número de distribuições diferentes para o mesmo propósito. Em geral elas são muito similares entre si e você deve escolher a que melhor se adaptar, sendo que o especialista não deve ser limitar à uma distribuição, nem mesmo à um SO. É preciso conhecer variadas tecnologias como Linux (baseados em Debian, em Red Hat, Slackware etc), Windows (versões desktop e família Server), BSDs, Mac OS, embarcados, enfim, a lista é inacabável. A ideia é não se limitar a uma só tecnologia, distribuição ou aplicação. Não devemos depender disto.
Página 8
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
1.2 Estratégias de investigação
1.2.5 Apresentação Após a conclusão da análise, chega a hora de apresentar os resultados ao seu cliente, seu chefe, ao júri ou a qualquer outra pessoa ou grupo de pessoas aplicáveis. Normalmente isto é alcançado com um relatório, mas também pode envolver uma apresentação. É importante não esquecer de documentar: • As evidências que você pode provar. • O que você fez para descobri-las. • Por que você foi atrás delas. • Como você fez para revelá-las. O relatório deve ser bem explicativo, de preferência com uso de imagens para tornar fácil o suficiente para um público não técnico entender, mesmo que sem profundidade. Um modelo de relatório pode ser consultado no Anexo I. Você deve entregar junto ao relatório uma tabela com todos os hashes calculados durante a investigação e uma mídia (um DVD-R por exemplo) com os arquivos encontrados.
Técnicas de Computaçao Forense
Página 9
Capítulo 2 Aquisição de dados
2.1 Memória mapeada por processos Quando um processo entra em execução no sistema, uma região de memória é mapeada (endereçada) para ele. É possível obter, num sistema em execução, somente esta região de memória para análise posterior. Isto é muito útil quando trata-se de um processo suspeito, peça-chave para uma investigação. Por exemplo, no caso de um acesso a sites proibidos, é interessante obter a memória mapeada para o processo do navegador.
2.2 Memória no espaço do usuário Os aplicativos executados pelo usuário, em geral, trabalham no espaço de usuário, também conhecido como ring3 ou usermode. Quando o foco da investigação for processos utilizados pelo usuário, provavelmente a aquisição de memória deste espaço bastará. No entanto, há casos em que a aquisição da memória utilizada por processos essenciais do sistema também é necessária, que veremos adiante.
11
2.3 Memória no espaço do kernel
4Linux – www.4linux.com.br
2.3 Memória no espaço do kernel O kernel, drivers e afins rodam no sistema de forma privilegiada e com sua própria área de memória. Este modo de execução é conhecido como kernelmode, espaço de kernel ou ring0. A memória mapeada neste modo pode também ser obtida através de um dump de memória.
Na verdade, na maioria dos casos, um dump de memória completo é realizado, o que inclui todas as regiões de memória citadas anteriormente. No entanto, saber dividi-las é importante para agilizar a investigação.
2.4 Outras memórias Nem só da memória RAM principal vive um computador. Existem ainda outras memórias que podem fazer parte de um processo de investigação como: • VRAM das placas de vídeo • BIOS ROM • Buffer de periféricos Obter dados destas memórias pode exigir hardware especializado. Com tantas fontes de dados, é importante conhecer um pouco da arquitetura dos sistemas, a fim de filtrar o que é e o que não é importante para a investigação.
Página 12
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
2.5 Mídias USB e ópticas
2.5 Mídias USB e ópticas Mídias ópticas como CD-R, DVD-R e BD-R são simples de serem copiadas e naturalmente já são memórias somente de leitura. Qualquer software capaz de efetuar uma cópia idêntica de um fluxo de dados será suficiente para obter o conteúdo de uma mídia óptica, sem complicações. Já dispositivos USB funcionam, na forma lógica, como discos rígidos e podem conter uma ou várias partições, com diferentes sistemas de arquivos. Neste caso a cópia também pode ser feita um software de cópia bit a bit, porém deve-se prestar a atenção ao que se está copiando, inclusive nas permissões de acesso à mídia (é interessante montar a mídia como somente leitura, assim como as mídias ópticas são montadas). Para dar um exemplo mais claro, um pen drive pode ter duas partições: uma NTFS e uma ext4. Copiar a mídia inteira para um arquivo de imagem pode ser mais complicado de analisar que copiar as partições separadamente para dois arquivos de imagem distinhos.
2.6 Partições As partições são delimitações lógicas em discos e mídias de armazenamento. Normalmente as mídias USB têm uma partição com o tamanho todo o espaço livre disponível, mas isso não é, nem de longe, uma regra. Pode haver várias partições, incluindo algumas ocultas (o sistema operacional não a exibe). A tabela de partições pode estar no MBR (Master Boot Record - Setor Mestre de Inicialização), que é a forma tradicional de particionamento, ou no GPT (GUID Partition Table). Neste último caso, o MBR ainda é usado mas apenas indicará onde está o GPT. O MBR é o primeiro setor do disco rígido e por ser um setor, tem 512 bytes de
Técnicas de Computaçao Forense
Página 13
2.6 Partições
4Linux – www.4linux.com.br
tamanho. Vamos dar uma olhada no dump de um MBR:
Perceba que nos referimos ao MBR no gênero masculino. É importante definir os termos corretamente e se o MBR é um Registro (record ) Mestre de Inicialização, dizemos o MBR e não a MBR. O mesmo acontece com o BIOS, que é o Sistema(system ) Básico de Entrada e Saída.
O MBR é estruturado da seguinte maneira:
Página 14
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
Offset (hexa) 0 1b8 1be 1fe
Tamanho (bytes) 440 4 64 2
2.7 Discos rígidos
Descrição Área de código Identificador/assinatura do disco Tabela de partições Identificador/assinatura do MBR
Sabendo disso, você é capaz de dizer qual é o identificador do disco na imagem do MBR apresentada? Lembre-se que os bytes estão organizados em little-endian (da direita para a esquerda). O anexo 1 da apostila lista os tipos de partições conhecidos e seus respectivos códigos em hexa. Cada entrada de partição na tabela de partições ocupa 16 bytes, por isso o número máximo de partições na tabela é 4.
Você deve estar se perguntando: se o número máximo de partições na tabela é 4, como existem discos com mais de 4 partições? Acontece que existe um tipo especial de partição chamada de extendida (tipo 0x5). Esta partição aponta para uma nova estrutura, fora do MBR, conhecida como EBR (Extended Boot Record) que também contém tabela de partições.
2.7 Discos rígidos Uma outra possibilidade é copiar todo o conteúdo de um disco, do primeiro ao último setor, sem discriminar partições. Esta costuma ser uma boa tática, visto que o MBR e todos os EBR são copiados e é possível analisá-los depois com softwares como fdisk ou cfdisk.
Técnicas de Computaçao Forense
Página 15
Capítulo 3 Investigação em ambientes GNU/Linux 3.1 Características dos kernels atuais É mais que sabido por todos os profissionais da área de tecnologia que ela muda muita. Na computação forense não é diferente. Uma ferramenta ou abordagem pode se tornar ultrapassada em questão de dias, por isso é importante se manter atualizado a todo momento. Em relação ao kernel Linux temos importantes mudanças nas versões recentes que precisam ser levadas em consideração: • Novos filesystems como Btrfs e ext4 • /dev/kmem em desuso • Proteção no /dev/mem As mudanças não param e é importante para o profissional estar em dia com tais atualizações para adaptar suas ferramentas e técnicas às novas configurações. Um
17
3.2 Aquisição de memória RAM
4Linux – www.4linux.com.br
bom site para se manter atualizado sobre isso é o kernelnewbies.org. Quando um novo filesystem começa a ganhar espaço, é bem possível que você se depare com ele numa investigação e por isso é recomendado que você estude suas especificações para não ficar perdido caso precise analisá-lo. O /dev/kmem provia acesso à memória do sistema do ponto de vista do kernel. Se precisar deste recurso, dê uma olhda no /proc/kcore. Este é um arquivo virtual no formato de core file que pode ser aberto num debugger como o gdb. O /dev/mem provê acesso a toda a memória do sistema, no entanto, existe uma proteção contra acesso não autorizado no /dev/mem que impede um dump completo, mesmo com privilégios de root. Uma solução é utilizar um módulo externo, que veremos adiante.
3.2 Aquisição de memória RAM Obter uma cópia da memória é uma parte importante do processo de investigação forense. Claro que para tal feito, a máquina em questão deve estar ainda ligada, do contrário os dados na memória do sistema serão perdidos, visto que ela é uma memória RAM dinâmica (DRAM - Dynamic Random Access Memory ).
As memórias RAM dinâmicas são construídas com base em matrizes capacitivas, que abrigam componentes eletrônicos capazes de armazenar energia por um determinado período de tempo. Para que o dado seja mantido em memória, é preciso que haja um circuito de realimentação, em tempo normalmente constante, que impede que a matriz de se descarregue e perca a engergia armazenada, no nosso caso, nossos bits. Este é o conhecido refresh circuit , ou circuito de realimentação. É graças a ele que os dados na memória não são perdidos a todo momento enquanto a máquina está ligada. No entanto, quando a máquina é desligada, o cirtuito de realimentação pára de funcionar e as matrizes da memória começam a se descarregar.
Página 18
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.2 Aquisição de memória RAM
Sem energia para realimentar a matriz, os dados são perdidos. Existe ainda uma hipótese baseada na recuperação dos dados imediatamente após o desligamento da máquina, quando os capacitores ainda estão se descarregando e que pode envolver até o congelamento por resfriamento dos módulos de memória, mas é algo que ainda não teve sua eficiência comprovada.
3.2.1 Memória mapeadas por processo Para obter uma cópia da memória mapeada por um processo no Linux, primeiro é preciso saber qual a faixa de endereços que o processo está utilizando. Para isto, você pode consultar um arquivo especial em /proc/
/maps onde é o PID (Process IDentifier) do processo em questão. São várias regiões de memória mapeadas para um processo, dentre elas a heap e a stack, também conhecida como pilha. Por isso é importante saber o que se procura e conhecer as regiões de memória onde os dados procurados costumam ser armazenados. Após escolher a região, o gdb (GNU Debugger), pode ser utilizado para dumpar a faixa de memória escolhida. No exemplo abaixo, algumas linhas e colunas foram removidas para facilitar a visualização:
$ cat /proc/178/maps 4-41 r-xp 8:5 764329 6-61 rw-p 8:5 764329 7fe6d5d29-7fe6d5ea6 r-xp glib/x86_64-linux-gnu/libc-2.13.so 7fe6d5ea6-7fe6d6a6 ---p glib/x86_64-linux-gnu/libc-2.13.so 7fe6d6a6-7fe6d6aa r--p glib/x86_64-linux-gnu/libc-2.13.so 7fe6d6aa-7fe6d6ab rw-p glib/x86_64-linux-gnu/libc-2.13.so 7fe6d6b-7fe6d6cf r-xp glib/x86_64-linux-gnu/ld-2.13.so
Técnicas de Computaçao Forense
Página 19
3.2 Aquisição de memória RAM
4Linux – www.4linux.com.br
7fe6d62cf-7fe6d62d r--p glib/x86_64-linux-gnu/ld-2.13.so 7fe6d62d-7fe6d62d1 rw-p glib/x86_64-linux-gnu/ld-2.13.so 7fff9586f-7fff9589 rw-p [stack] 7fff959ff-7fff95a r-xp [vdso] ffffffffff6-ffffffffff61 r-xp [vsyscall]
No mapa de memória do processo de PID 17008 podemos observar várias regiões mapeadas para a libc (o que indica que este processo foi escrito em C) e também a região da stack, dentre outras. Para fazer o dump de uma delas, precisamos attachar o processo ao gdb e informar qual a faixa desejada. Em nosso exemplo, vou dumpar a stack:
$ gdb -q --pid 178 (gdb) dump memory 178.stack x7fff9586f x7fff9589 (gdb) quit
O arquivo 17008.stack será criado em disco, com o conteúdo da pilha do processo. Veremos mais adiante como analisá-lo.
Para facilitar o dump do conteúdo da stack, você pode utilizar o hack-functions, um conjunto de funções úteis para bash que inclui a função dumpstack e você poderia ter feito o dump anterior com uma só linha de comando.
3.2.2 Memória do sistema Também pode ser útil para o investigador colher uma cópia de todo o conteúdo da memória RAM. Apesar de ser mais difícil analisar, alguns softwares tentam compreender a organização dos dados na RAM e provêem uma saída bem interessante.
Página 20
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.2 Aquisição de memória RAM
Em teoria, basta utilizar o dd, parte integrante do binutils do projeto GNU:
dd if=/dev/mem of=ramdump
O arquivo ramdump será criado com todo o conteúdo da memória RAM. No entanto, conforme consta na introdução deste capítulo, pode ser que o /dev/mem esteja protegido e somente o primeiro megabyte de memória esteja acessível. Se esta proteção estiver ativa, o dd não conseguirá copiar mais que 1 MB da memória:
# dd if=/dev/mem of=ramdump dd: lendo "/dev/mem": Operação não permitida 256+ registros de entrada 256+ registros de saída 152672 bytes (1,1 MB) copiados, ,362599 s, 29, MB/s
Você também descrobriria se essa proteção está ativa checando a configuração do kernel em execução:
# grep DEVMEM /boot/config-$(uname -r) CONFIG_STRICT_DEVMEM=y
Se você ficou curioso sobre o fato de apenas o primeiro megabyte de memória estar liberado para acesso, segue comentário do próprio código fonte do kernel: /* * devmem_is_allowed() checks to see if /dev/mem access to a certain address * is valid. The argument is a physical page number. * * * On x86, access has to be given to the first megabyte of ram because that area * contains bios code and data regions used by X and dosemu and similar apps. * Access has to be given to non-kernel-ram
Técnicas de Computaçao Forense
Página 21
3.2 Aquisição de memória RAM
4Linux – www.4linux.com.br
areas as well, these contain the PCI * mmio resources as well as potential bios/acpi data regions. */ Fonte: https://github.com/torvalds/linux/blob/master/arch/x86/mm/init.c#L304
Uma saída é utilizar o módulo fmem, disponível livremente na internet:
$ wget -c http://hysteria.sk/~niekt/foriana/fmem_current.tgz $ tar xf fmem_current.tgz $ cd fmem* $ make $ sudo ./run.sh
Após a instalação do módulo, fica disponível o dispositivo /dev/fmem, com acesso total a memória (para usuários com privilégios de root). No entanto, o fmem exige que você o informe quando parar, ou seja, qual a quantidade de memória total do sistema. Isso pode ser conferido antes com o comando free:
$ free -m total
used
free
shared
buffers
cached
391
3779
122
138
1466
-/+ buffers/cache:
2175
1726
926
Mem: Swap:
926
# dd if=/dev/fmem of=ramdump bs=1M count=391
Como eu usei a opção -m do free para exibir o resultado em megabyes, usei a opção bs (block size) do dd para configurá-lo a copiar 3901 (opção count) blocos, ou seja, o total da RAM, para o arquivo ramdump.
Página 22
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.3 Aquisição de dados de filesystems ext4
3.3 Aquisição de dados de filesystems ext4 Adquirir dados de discos não é muito diferente de adquirir dados da memória, com exceção é claro de sua característica não volátil, então mesmo com a máquina desligada, os dados do disco permanecem (com algumas exceções pois pode haver armadilhas que apagam rastros caso a máquina seja desligada - inclusive-se recomendase desligar a máquina na tomada em alguns casos). O dcfldd é um software baseado no dd, mas com um foco em computação forense, então existem alguns recursos no dcfldd que facilitam a vida e nos fazem digitar menos. Vejamos como seria a cópia do MBR de um disco para um arquivo com o dcfldd:
# dcfldd if=/dev/sda of=mbr.img bs=512 count=1 hash=sha1,md5 Total (md5): d57d9e9521f756b88c1b728cd726a149 Total (sha1): 36331d9f83f364726e55f4337bf36b3689e3 1+ records in 1+ records out
Você deve ter percebido que a sintaxe é muito parecida com a do dd, mas no comando acima usamos a opção hash, que já calcula os hashes desejados da imagem gerada, um dos recursos do dcfldd. Para mais informações, basta consultar o manual da ferramenta, como com qualquer ferramenta Unix-like que se preze. ;) Com o fdisk podemos listar todas as partições de todos os discos conectados:
# fdisk -l Disk /dev/sda: 32.1 GB, 3272933376 bytes 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors Units = sectors of 1 * 512 = 512 bytes
Técnicas de Computaçao Forense
Página 23
3.3 Aquisição de dados de filesystems ext4
4Linux – www.4linux.com.br
Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: x796db3a Device Boot
Start
End
Blocks
Id
System
248
78319615
39158784
83
Linux
/dev/sda3
78321662
625141759
2734149
5
/dev/sda5
78321664
623241215
272459776
83
Linux
/dev/sda6
623243264
625141759
949248
82
Linux swap / Solaris
/dev/sda1
*
Extended
É possível fazer imagens de todo o disco e de cada partição e é recomendável que as duas sejam feitas, para evitar deixar algum dado para trás. Segue um exemplo de cópia da partição sda6 (swap em nosso exemplo):
# dcfldd if=/dev/sda6 of=sda6-swap.img hash=sha1,md5 2944 blocks (92Mb) written.Total (md5): a3b18f299fed1565c167a17b519355 Total (sha1): 99c32b3a6d98af2e18dc5fbf86bcc4ac23b69b 29664+ records in 29664+ records out
3.3.1 Estrutura do ext4 Conhecer o sistema de arquivos a ser analisado é um requisito quando se trata de partições problemáticas ou com técnicas de anti-forense (veremos algumas adiante). Nesta seção abordaremos conceitos sobre o ext4, o sistema de arquivos padrão das distribuições GNU/Linux atuais, mas é importante notar que nem sempre você irá se deparar com ext4. É bem possível que você encontre sistemas ext3, ZFS (Sun/Oracle), JFS (IBM), dentre outros em servidores Linux ou Unix. No entanto, os conceitos expostos aqui servirão como base para estudo dos conceitos de outros filesystems .
Página 24
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.3 Aquisição de dados de filesystems ext4
O ext4 mantém os seguintes registros de data para cada arquivo: mtime data em que o arquivo foi modificado atime data em que o arquivo foi acessado ctime data em que o arquivo teve um atributo modificado dtime data em que o arquivo foi excluído crtime data em que o arquivo foi criado
Em seu antecessor, o ext3, somente os três primeiros atributos estão presentes, algo que a comunidade de segurança já se incomodava. A resolução de tempo passou a ser de nanosegundos , contra segundos do ext3. As seguintes ferramentas presentes na suíte e2fsprogs merecem destaque: http://e2fsprogs.sourceforge.net e2image Gera imagens com metadados críticos de partições para arquivos dumpe2fs Exibe informações sobre uma partição. Pode ser usado com uma im-
agem gerada pelo e2image debugfs Um debugger interativo que também pode ser usado com imagens do
e2image Para cada arquivo existente no filesystem, existe uma estrutura responsável por representá-lo chamada inode. O inode também armazena todas as informações sobre um arquivo, com exceão de seu nome e conteúdo. Para verificar tais informações, podemos usar o comando stat:
# stat mbr.img
Técnicas de Computaçao Forense
Página 25
3.3 Aquisição de dados de filesystems ext4
4Linux – www.4linux.com.br
File: "mbr.img" Size: 512
Blocks: 8
IO Block: 496
Device: 85h/253d Inode: 764329 Access: (644/-rw-r--r--)
arquivo comum
Links: 1
Uid: ( 1/
nandu)
Gid: ( 1/
nandu)
Access: 212-5-22 :6:14.49224942 -3 Modify: 212-5-22 :6:32.56336493 -3 Change: 212-5-22 :6:32.56336493 -3 Birth: -
No entanto, conforme você deve ter percebido, a data de criação do arquivo não apareceu. Acontece que nem todas as ferramentas já estão adaptadas ao ext4, mas por sorte o debugfs resolve: # debugfs -R ’stat <764329>’ /dev/sda5 Inode: 764329
Type: regular
Generation: 3982433542 User:
1
File ACL:
Group:
Mode:
644
Flags: x8
Version: x:1
1
Size: 512
Directory ACL:
Links: 1
Blockcount: 8
Fragment:
Address:
Number:
Size:
ctime: x4fbb2b8:d6e81b4 -- Tue May 22 :6:32 212 atime: x4fbb2a6:755c84e8 -- Tue May 22 :6:14 212 mtime: x4fbb2b8:d6e81b4 -- Tue May 22 :6:32 212 crtime: x4fbb1ac:be7fc6ac -- Tue May 22 :2:4 212 Size of extra inode fields: 28 EXTENTS: ():3154696
Este comando stat passado para o debugfs é um comando interno do debugger e não o stat do coreutils usado anteriormente.
Se o arquivo for excluído, o atributo dtime aparecerá:
Página 26
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.3 Aquisição de dados de filesystems ext4
$ rm mbr.iso # debugfs -R ’stat <764329>’ /dev/sda5 Inode: 764329
Type: regular
Generation: 3982433542 User:
1
File ACL:
Group:
Mode:
644
Flags: x8
Version: x:1
1
Size:
Directory ACL:
Links:
Blockcount:
Fragment:
Address:
Number:
Size:
ctime: x4fbb3ad4:dc6a9c -- Tue May 22 4:5:56 212 atime: x4fbb39fe:dce57df -- Tue May 22 4:2:22 212 mtime: x4fbb3ad4:dc6a9c -- Tue May 22 4:5:56 212 crtime: x4fbb1ac:be7fc6ac -- Tue May 22 :2:4 212 dtime: x4fbb3ad4 -- Tue May 22 4:5:56 212 Size of extra inode fields: 28 EXTENTS:
O debugfs também pode atuar com imagens de disco, como faremos nos exercícios.
3.3.2 Como o ext4 grava os arquivos? O conteúdo dos arquivos é gravado em blocos contínuos de tamanho pré-definido no disco (geralmente 4096 bytes, mas você pode consultar com o comando:
# dumpe2fs -h /dev/sda5 | grep ’Block size’ dumpe2fs 1.42.2 (9-Apr-212) Block size:
496
No exemplo acima consultei o tamanho do bloco de uma partição /dev/sda5, formatada com ext4.
Técnicas de Computaçao Forense
Página 27
3.3 Aquisição de dados de filesystems ext4
4Linux – www.4linux.com.br
É possível ver quais os blocos utilizados por um determinado inode com o comando dessa forma: # debugfs -R ’blocks <764329>’ /dev/sda5 debugfs 1.42.2 (9-Apr-212) 3447449
Um inode pode utilizar mais de um bloco por conta do tamanho do arquivo representado por ele, mas em nosso exemplo ele utiliza apenas um bloco, de número 30447449. Podemos extrair tal bloco do disco com o dd: dd if=/dev/sda5 of=bloco bs=496 count=1 skip=3447449 1+ registros de entrada 1+ registros de saída 496 bytes (4,1 kB) copiados, ,167189 s, 245 kB/s
No exemplo acima trabalhei com um tamanho de bloco de 4096 bytes (consultado previamente dumpe2fs) e o extraí para um arquivo chamado bloco. Se o tamanho do arquivo for menor que o bloco, após o último byte do arquivo, todos os bytes seguintes serão nulos (0x00) e podem ser removidos facilmente. No exemplo o arquivo tem 512 bytes, então vou extrair 512 bytes do bloco capturado: $ dd if=bloco of=mbr.recuperado bs=512 count=1 1+ registros de entrada 1+ registros de saída 512 bytes (512 B) copiados, 4,5397e-5 s, 11,3 MB/s $ md5sum mbr.* d57d9e9521f756b88c1b728cd726a149 mbr.bin d57d9e9521f756b88c1b728cd726a149 mbr.recuperado
O hash MD5 comprova que não há qualquer diferença entre o arquivo original e o recuperado.
Página 28
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.3 Aquisição de dados de filesystems ext4
Recuperações de arquivos excluídos em sistemas ext4 são geralmente baseadas no conteúdo do journal, um log de todas as transações no filesystem. Neste caso, o comando logdump do debugfs pode ser utilizado para checar em que bloco de dados há uma cópia do arquivo representado pelo inode em questão, caso haja.
3.3.3 Outros itens na memória a serem coletados Existem alguns itens que estão em memória e, apesar de permanecerem no dump, pode ser difícil extraí-los, por isso recomenda-se sua extração na própria máquina. A lista abaixo exibe alguns mas o investigador pode avaliar o que é mais importante para cada caso: • Processos em execução • Sockets abertos • Usuários logados • Arquivos abertos • Tabela de rotas • Tabela ARP • Variáveis de ambiente • Dispotivos montados • Itens conectados à USB
Técnicas de Computaçao Forense
Página 29
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
O script pelicano.sh cria um relatório com a maioria dessas informações, com base nos comandos do próprio Linux. Não deixe de checar. ;)
3.4 Análise de dumps de memória e disco Após obter de forma segura dumps de memória e de disco, é preciso começar o trabalho de análise. Veremos agora algumas técnicas para obter informações sobre os dumps que colhemos.
3.4.1 Busca de strings As strings (textos) dentro de um dump pode ajudar bastante a análise, principalmente ao sabermos em que lugar do dump ela está. Para entendermos o que é, efetivamente, uma string, primeiro é preciso saber como os caracteres são de texto são representados. Você provavelmente já ouviu falar na tabela ASCII (American Standard Code for Information Interchange), certo? É uma tabela que relaciona cada caractere com um número, de 0 a 255, totalizando 256 caracteres possíveis. Para visualizá-la, você pode conferir o Anexo II, mas se tiver o hack-functions instalado, basta comandar asciitable no terminal. Através da tablea ASCII é possível perceber que a letra maiúscula F, por exemplo, possui o código 0x46 (70 decimal). Na verdade o número 0x46 é representado como F, quando você pede. Por exemplo:
Página 30
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
$ echo x46 x46 $ echo -e ’\x46’ F $ str2hex -x 4Linux \x34\x4c\x69\x6e\x75\x78
No exemplo acima exibi o texto 0x46, o equivalente em ASCII do número 0x46, com o comando echo. Em seguida, usei a função str2hex das hack-fuctions para exibir o byte correspondente de cada caractere da string 4Linux. Que tal conferir na tabela ASCII se a função está mostrando os bytes corretamente? Sendo assim, devemos concordar que para procurar strings dentro de um arquivo, seja ele qual for, é só procurar uma sequência de bytes (digamos, com no mínimo três) que estejam na faixa de 0x20 até 0x7e, correto? Se olhar na table ASCII, verá que estes são os caracteres imprimíveis. Uma implementação simples, em C, seria: strings.c 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
# include # include i nt m ai n ( i nt a rg c , c ha r * a r gv [ ] ) { / / po n te i ro p a ra o a rq u iv o FILE *arquivo; // b uf fe r d e 1 b yt e ( a 2 55 ) p a ra a rm az en ar o b yt e l i do unsigned char buffer; / / e s ta v ar i á v el v ai c o nt r ol a r q u a nd o v a m os p u la r l i n ha b oo l n ov a _s t ri n g = fa ls e ; / / s e n ã o f o r i nf or ma do n en hu m a rq ui vo , e mi te u m e rr o e s ai if (a rg c != 2)
Técnicas de Computaçao Forense
Página 31
3.4 Análise de dumps de memória e disco 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
4Linux – www.4linux.com.br
{ printf("Uso:\n\t%s \n", argv[]); return 1; } / / te nt a a br ir o a r qu iv o a r qu i vo = f o pe n ( a rg v [ 1] , " r b " ); / / c a so n ã o c o ns ig a , e mi te u m e r ro e s ai i f ( a rq ui vo = = NU LL ) { p ri n tf ( " a r qu i vo % s in e xi s te n te o u il eg í v e l \n " , ar gv [ 1 ]) ; return 1; } / / e n q ua n to a f un ç ã o f r ea d ( ) r e t or n ar 1 , s i gn i fi c a // q ue 1 b yt e f oi l ido no a rq ui vo e o lo op c on ti nu a while(fread(&buffer , sizeof(buffer), 1, arquivo) == 1) { / / se o by te e s ti ve r e nt re a f ai xa d e se ja da if ( bu ff er > = ’ ’ && b uf fe r <= ’~ ’) { / / s e fo r um a no va s tr in g , pu la u ma l in ha i f ( n o v a_ s tr i ng = = t ru e )
putchar(’\n’); / / i mp ri me na te la a r ep re se nt a ç ão AS CI I do by te
putchar(buffer); / / a ss um e q ue a s tr in g a in da n ã o a ca bo u n o va _ st r in g = f al s e ; }
else { / / o b yt e a tu al me nt e l id o n ã o p er te nc e à / / f ai xa , e nt ã o a ss um im os q ue u ma n ov a / / s tr in g v em a í !
Página 32
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
n o va _ st r in g = t ru e ; 54 55 } 56 } 57 putchar(’\n’); 58 f cl o se ( a r q ui v o ) ; // f e c ha o a r q ui v o 59 return ; 60 61 }
O programa acima vai imprimir na tela todos os bytes de um arquivo passado por argumento que possuam representação em ASCII e sejam imprimíveis.
Para desafiar seus conhecimentos em programação, veja se consegue implementar neste programa a impressão na tela do offset (posição no arquivo) onde a string se encontra.
Mas não precisamos escrever nosso próprio programa de busca de strings se estivermos no Linux pois o projeto GNU já fornece um programa chamado strings que faz exatamente isto: $ strings -t x mbr.img 9d ZRr= 116 ‘|f 11f \|f1 18 GRUB 186 Geom 18b Hard Disk 195 Read 19a
Error
O comando strings adimite que, para ser uma string, a sequência precisa ter pelo menos 3 caracteres imprimíveis. A opção -t x faz com que ele imprima o offset da
Técnicas de Computaçao Forense
Página 33
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
string em hexadecimal. Assim, numa análise, você pode copiar todas as strings num dump de memória para um arquivo:
$ strings -t x ramdump > ramdump_strings.txt
3.4.2 Carving É possível também procurar por formatos de arquivo conhecidos dentro de um arquivo binário, técnica conhecida como carving . Para entender como essa extração funciona, primeiro temos que entender o que é um formato de arquivo. Um formato de arquivo normalmente é um padrão, um documento, que define como um determinado arquivo deve ser criado. Por exemplo, para arquivos do tipo PE (Portable Executable), o formato especifica que os dois primeiros bytes do arquivo devem ser 0x4d e 0x5a, além de várias outras obrigações da aplicação que cria tais arquivos, que no caso do executável PE, são os compiladores. Sabendo disso nós podemos procurar dentro de um arquivo binário por um tipo de arquivo específico e se consguirmos saber em qual byte termina o arquivo, podemos extraí-lo por inteiro com o dd, por exemplo.
Buscando a string que identifica um GIF
Neste exemplo vamos buscar por arquivos GIF dentro do dump. Para isso precisamos conhecer a especificação do GIF, como mostra a tabela abaixo (fonte: Wikipedia):
byte#
hexadecimal
(hex) :
text or value
Meaning
GIF89a
Header
47 49 46 38 39 61
Logical Screen Descriptor
Página 34
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
6:
3
3
- logical screen width in pixels
8:
5
5
- logical screen height in pixels
A:
F7
- GCT follows for 256 colors with resolution 3
x 8 bits/primary B:
C:
- background color # - default pixel aspect ratio
R
G
B
Global Color Table
D:
- color # black
1:
8
128
- color #1
: 85:
:
- color #4 black
:
:
3A:
FF FF FF
255
255
255
- color #255 white
3D:
21 F9
3F:
4
31:
1
- there is a transparent background color
311:
- delay for animation: not used
313:
1
314:
315:
2C
316:
(,)
- NW corner position of image in logical screen
31A:
3 5 (3,5)
- image width and height in pixels
31E:
- no local color table
31F:
8
8
32:
B
11
321:
51 FC 1B 28 7 A C1 83 1 1
32C:
32D:
3B
Graphic Control Extension 4
16
- 4 bytes of GCE data follow
- color #16 is transparent - end of GCE block Image Descriptor
Start of image - LZW minimum code size - 11 bytes of LZW encoded image data follow - end of image data GIF file terminator
De cara, vemos o header da última versão do formato, que deve ser composto pelos bytes 0x47 0x49 0x46 0x38 0x39 0x61, que representam em ASCII a string "GIF89a". Se quiser confirmar, pode checar na tabela ASCII. Então vamos ao grep:
Técnicas de Computaçao Forense
Página 35
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
$ strings -t x dump.bin | grep GIF89a 8 GIF89ae
Casamos com a string inteira. Seria muita coincidência esses 6 caracteres casarem se isso não for o início de um GIF? É o que veremos:
$ hd -s x8 -n 64 dump.bin 8
47 49 46 38 39 61 65 1
1a 2 f7 bb 9c 91
|GIF89ae.........|
81
6e 5b 54 d9 ad 9c 6b 69
69 ca a4 94 e3 8c 7d 3f
|n[T...kii.....}?|
82
1e e 33 d 9 f6 cb ba
e1 b4 a3 e3 bb aa eb ca
|..3.............|
83
8a c8 44 39 b 5 4 6b
26 21 44 27 19 fa f2 e4
|..D9...k&!D’....|
A documentação diz que depois do header de 6 bytes, temos 2 bytes identificando a largura (0x165) e mais 2 para a altura (0x21a), o que definiria um GIF de 357x538 pixels e parece aceitável. O próximo byte, segundo o exemplo na documentação, quando é 0xf7, diz que o GIF tem 256 cores, dentre outras informações. Este byte bate com o nosso 0xf7. Não precisamos ir até o final checando todos os campos para chegar ao fim do arquivo. A maioria dos formatos de arquivo definem um ou mais bytes para marcar o fim do arquivo. No caso do GIF, veja na documentação que os últimos bytes são 0x00 (end) e 0x3b (GIF terminator). Lembre-se que isso é específico do formato GIF e não é regra para qualquer tipo de arquivo. Cada um tem seu formato.
Os formatos que não possuem bytes que marcam o fim, geralmente possuem um campo que diz o tamanho completo do arquivo.
Página 36
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
Estratégia para extrair o possível GIF do dump
Podemos usar a estratégia de extrair os bytes desde o ’G’ do "GIF89a"até a primeira sequência 0x00 0x3b. Se for um GIF real, deveria funcionar. Vamos à busca: $ hd -s x8 dump.bin | grep --color " 3b" 82b6
3d 97 87 8 3b 55
d9 6 ab 23 eb 24 ac f1
|=.....;U.‘.#.$..|
ef4e
2b 61 8d 77 3b 7c 58
62 23 4a dc 4c 15 42 da
|+a.w.;|Xb#J.L.B.|
A primeira sequência que "00 3b"que o grep encontrou após o offset 0x80000 (início do GIF) está em 0x82b65. Neste offset está o 0x00 e em 0x82b66 está o 0x3b, portanto o próximo byte (0x55) não faz parte do GIF. Se diminuirmos a posição do último byte + 1 de 0x80000, teremos o tamanho total do suposto GIF: $ echo $((x82b67-x8)) 11111
A resposta é em decimal. Uma maneira mais fácil de fazer esta conta e já ter a resposta em hexadecimal seria usando a função hexcalc: $ hexcalc 82b67 - 8 x2b67
É preciso somar mais um pois o primeiro byte, na posição 0x80000, já conta. Vamos relembrar o que temos: Tipo: GIF Resolução: 357x538 pixels
Técnicas de Computaçao Forense
Página 37
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
Tamanho: 11111 bytes (11 KB)
Extração com o dd
Vamos tentar extrair o suposto GIF do arquivo de dump:
$ dd if=dump.bin of=possivel.gif bs=1 count=11111 skip=$((x8)) 11111+ registros de entrada 11111+ registros de saída 11111 bytes (11 kB) copiados, ,36675 s, 33 kB/s
A opção bs (block size) informa ao dd para assumir blocos de 1 byte. A opção count diz quantos blocos ele vai ler, então vão dar exatamente 11111 bytes. E por fim, a opção skip, que só aceita números em decimal (por isso a conversão com o bash) informa quantos bytes o dd vai pular para começar a ler, assim como a opção -s"do hd. Temos que começar a extração do byte 0x80000, que é onde começa o GIF. Vamos conferir:
$ file possivel.gif possivel.gif: GIF image data, version 89a, 357 x 538 $ wc -c possivel.gif 11111 possivel.gif
3.4.3 Usando o foremost O foremost é uma ferramenta de código aberto que automatiza o trabalho manual de busca de arquivos em arquivos binários ou diretamente em um dispositivo. Ele tam-
Página 38
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
bém se baseia no formato de arquivos para realizar sua busca. Seu uso é bastante simples:
$ foremost -vi dump.bin Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus Audit File Foremost started at Wed May 23 5:57:14 212 Invocation: foremost -vi dump.bin Output directory: output Configuration file: /etc/foremost.conf Processing: dump.bin |-----------------------------------------------------------------File: dump.bin Start: Wed May 23 5:57:14 212 Length: 124 KB (148576 bytes) Num
Name (bs=512)
: 124.gif
Size 1 KB
File Offset 524288
Comment (357 x 538)
*| Finish: Wed May 23 5:57:14 212 1 FILES EXTRACTED gif:= 1 -----------------------------------------------------------------Foremost finished at Wed May 23 5:57:14 212
A opção -v faz o foremost operar em modo verbose (detalhado), enquanto a oção -i especifica um arquivo de entrada, no caso, nosso dump. Conforme pode ser visto, um GIF foi extraído e era exatamente o que esperávamos.
Técnicas de Computaçao Forense
Página 39
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
3.4.4 Trabalhando com imagens de disco Trabalhar com imagens de disco geralmente envolve montá-las como somente leitura e buscar por arquivos de log, configuração e afins.
O primeiro passo antes de iniciar o trabalho de análise numa imagem capturada é checar seus hashes. Para isso é essencial que os hashes tenham sido calculados quando a imagem foi obtida (vimos na seção anterior que o dcfldd já faz isso).
No exemplo abaixo, temos uma imagem de um disco inteiro, chamada sda.img. Como não podemos simplesmente montar um disco inteiro e sim suas partições, precisaremos analisá-la. Para isso, faremos uso do Sleuth Kit, mas antes vamos tomar algumas medidas preventivas para não comprometermos a imagem:
$ chmod -w sda.img $ md5sum sda.img && sha1sum sda.img cebdd715d4ecaafee8f147c2e85e754 sda.img ec3e661d7bc7bfbf5334e7dfad39f947dace5f7 sda.img $ cp sda.img{,.1} $ md5sum sda.img.1 && sha1sum sda.img.1 cebdd715d4ecaafee8f147c2e85e754 sda.img.1 ec3e661d7bc7bfbf5334e7dfad39f947dace5f7 sda.img.1
Usando o Sleuth Kit
O Sleuth Kit é um conjunto de ferramentas para analisar sistemas de arquivos, seja diretamente ou em imagens (cópias perfeitas). As ferramentas disponíveis são: blkcalc
Página 40
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
blkcat exibe o conteúdo de um bloco de uma imagem blkls lista os blocos de uma imagem blkstat exibe detalhes dos blocos de uma imagem ffind busca arquivos por inode fls lista arquivos numa imagem fsstat exibe detalhes do filesystem de uma imagem hfind busca um hash num banco de dados icat exibe o conteúdo de um arquivo por inode ifind ils lista os inodes de uma imagem img_cat exibe os dados de uma imagem não bruta img_stat exibe os detalhes de uma imagem não bruta istat exibe detalhes de um inode jcat exibe o conteúdo de um bloco do journal jls exibe o conteúdo do journal mactime cria uma linha do tempo de atividades mmcat exibe o conteúdo de uma partição dentro de uma imagem mmls exibe a tabela de partições de uma imagem
Técnicas de Computaçao Forense
Página 41
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
mmstat exibe detalhes sobre a tabela de partição de uma imagem sigfind busca um padrão (assinatura) num arquivo sorter cria uma lista ordenada por tipo de arquivo de arquivos numa imagem srch_strings busca strings em arquivos tsk_comparedir compara um diretório com uma imagem tsk_gettimes coleta os MAC times de cada filesystem de uma imagem tsk_loaddb grava os metadados de uma imagem num banco de dados SQLite tsk_recover extrai arquivos de imagens
Basicamente, onde lê-se "imagem"na listagem acima, também se pode ler "dispositivo", para usar as ferramentas em um dispositivo vivo (ex.: /dev/hda). Algumas ferramentas do TSK são redundantes em relação ao Linux, no entanto, sua existência se justifica quando pensamos na característica multiplataforma do projeto. Daremos um foco maior nas ferramentas do TSK daqui em diante e usaremos menos ferramentas nativas como dd, fdisk, debug2fs etc.
Obtendo a tabela de partições
Após checar os hashes, vamos listar a tabela de partições da imagem:
$ mmls -B sda.img DOS Partition Table Offset Sector: Units are in 512-byte sectors
Página 42
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
Slot
Start
End
Length
Size
Description
:
Meta
1
512B
Primary Table (#)
1:
-----
247
248
124K
Unallocated
2:
:
248
15988735
15986688
7G
Linux (x83)
3:
-----
15988736
1599783
248
124K
Unallocated
4:
Meta
1599782
16775167
784386
383M
DOS Extended (x5)
5:
Meta
1599782
1599782
1
512B
Extended Table (#1)
6:
1:
1599784
16775167
784384
383M
Linux Swap / Solaris
16775168
16777215
248
124K
Unallocated
x86 (x82) 7:
-----
A opção -B do mmls adiciona a coluna Size, com os tamanhos das partições encontradas.
Esta listagem também poderia ser feito com outros programas como fdisk ou parted, mas como combinamos anteriormente, vamos dar foco nas ferramentas do TSK.
O mmls mostra a localização de cada item encontrado nas tabelas de partições da imagem. Para exibir mais detalhes sobre um filesystem específico, usamos o fssat, informando o offset de início do filesystem obtido com o mmls para a partiçao desejada. Você deve ter percebido que o mmls mostrou uma partição do tipo "Linux (0x83)"começando no no offset 2048 (decimal). Vamos buscar agora detalhes sobre ela com o fsstat: $ fsstat -o 248 sda.img FILE SYSTEM INFORMATION -------------------------------------------File System Type: Ext3 Volume Name: Volume ID: 78b4e371a6a5439acf4a3c95b7dc3e75
Técnicas de Computaçao Forense
Página 43
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
Last Written at: Wed Mar 14 9:43:53 212 Last Checked at: Wed Mar 14 9:43:53 212 Last Mounted at: Wed May 23 18:24:41 212 Unmounted properly Last mounted on: Source OS: Linux Dynamic Structure Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index InCompat Features: Filetype, Read Only Compat Features: Sparse Super, Has Large Files, Journal ID: Journal Inode: 8 METADATA INFORMATION -------------------------------------------Inode Range: 1 - 499713 Root Directory: 2 Free Inodes: 33871 CONTENT INFORMATION -------------------------------------------Block Range: - 1998335 Block Size: 496 Free Blocks: 64775 BLOCK GROUP INFORMATION --------------------------------------------
Aqui cabe um questionamento: como é possível garantir que as ferramentas do TSK trabalhem em modo somente leitura com as imagens informadas? Esperamos
Página 44
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
que sim, mas é possível verificar? Como você faria?
Buscando arquivos deletados
A ferramenta ils, do TSK, lista informações sobre os inodes de arquivos em uma imagem, no entanto, por padrão ela só exibe os inodes de arquivos removidos já que os arquivos não removidos podem ser obtidos facilmente montando a imagem já que a tabela de partições deste sample não está corrompida.
$ ils -o 248 -m sda.img > deletados
Redirecionamos a saída para um arquivo chamado "deletados". Veja parte dele:
$ head deletados md5|file|st_ino|st_ls|st_uid|st_gid|st_size|st_atime|st_mtime|st_ctime|st_crtime ||8348|-/rrwxr-xr-x||||131488875|131625882|131625882| ||8349|-/rrwxr-xr-x||||131488875|131625882|131625882| ||9398|-/lrwxrwxrwx|||22|1317147975|131472373|131714988| ||9413|-/rrw-r--r--||||131472392|131472392|131472392| ||16562|-/rrw-r--r--|6|||1316191568|1316191568|1316191568| ||3356|-/lrwxrwxrwx|||28|131626597|131472528|13162862| ||33561|-/lrwxrwxrwx|||3|131626597|131472528|13162862| ||33563|-/lrwxrwxrwx|||28|131626597|131472528|13162862| ||33985|-/rrw-r--r--||||1388282|13147254|13147254|
Perceba que vários arquivos estão com os tamanhos (st_size) zerados e não adianta tentar recupera-los pois não há nada dentro deles. Mesmo os que estão com tamanho maior que zero, ainda dependerá se os blocos antigamente utilizados pelo inode já foram reutilizados ou não. Em caso positivo, a recuperação por software se torna muito ineficiente.
Técnicas de Computaçao Forense
Página 45
3.4 Análise de dumps de memória e disco
4Linux – www.4linux.com.br
Para recuperar um arquivo a partir de seu inode, use: $ icat -ro 248 sda.img 16562 > arquivo
No exemplo acima usei a opção -r do icat para usar técnicas de recuperação de arquivos deletados e a opção -o que viemos usando sempre, para setar o offset da partição que estamos trabalhando dentro da imagem sda.img. Após o nome da imagem, vem o número do inode que desejamos. Os nomes dos arquivos excluídos podem ser obtidos com: $ fls -rd -o 248 sda.img > lista_excluidos
A opção -r faz o fls funcionar de maneira recursiva, já a -d pede que só liste arquivos excluídos.
Montando as partições
Todo o trabalho até agora vem sido feito com o arquivo sda.img sem ser montado, no entanto, é extremamente útil montar as partições desta imagem do disco para facilitar a busca por arquivos, caso este recurso esteja disponível. Então mãos à obra: $ mount -o ro,loop sda.img /mnt mount: you must specify the filesystem type
O que houve? Acertou se lembrou que o arquivo sda.img é uma imagem de um disco inteiro e não só de uma partição, por isso é necessário montar somente a partição no offset 2048 (lembra?) do arquivo e não ele inteiro. Você está pensando em extrair a partição de dentro do arquivo de imagem? Bem, isso funcionaria, mas por sorte o mount possui uma opção offset, então basta usála:
Página 46
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.4 Análise de dumps de memória e disco
$ mount -o ro,loop,offset=248 sda.img /mnt mount: you must specify the filesystem type
Ops. O que houve agora? Lembre-se que esse offset diz respeito a um dispositivo em blocos (disco rígido) onde a menor unidade de armazenamento é um setor, de normalmente 512 bytes. Já a opção offset do mount precisa da posição exata do arquivo de onde começar, para chegar nela basta multiplicar o offset apresentado pelo mmls pelo tamanho do setor, que o mmls também nos diz:
$ sudo mount -o ro,loop,offset=$((248*512)) sda.img /mnt $ ls -l /mnt total 18 drwxr-xr-x
2 root
root
496 Ago 3
211 bin
drwxr-xr-x
3 root
root
496 Set 14
211 boot
drwxr-xr-x
5 root
root
496 Ago 3
211 dev
drwxr-xr-x 13 root
root 12288 Mai 23 18:26 etc
drwxr-xr-x
3 root
root
496 Set 14
211 home
drwxr-xr-x
4 www-data root
496 Set 14
211 infra_app
lrwxrwxrwx
1 root
root
28 Ago 3
211 initrd.img ->
boot/initrd.img-2.6.32-5-686 drwxr-xr-x
12 root
root 12288 Ago 3
211 lib
drwx------
2 root
root 16384 Ago 3
211 lost+found
drwxr-xr-x
3 root
root
496 Ago 3
211 media
drwxr-xr-x
2 root
root
496 Jun 19
211 mnt
drwxr-xr-x
3 root
root
496 Set 26
211 opt
drwxr-xr-x
2 root
root
496 Jun 19
211 proc
drwx------
1 root
root
496 Abr
drwxr-xr-x
2 root
root
496 Set 14
211 sbin
drwxr-xr-x
2 root
root
496 Jul 21
21 selinux
drwxr-xr-x
2 root
root
496 Ago 3
211 srv
drwxr-xr-x
2 root
root
496 Jan
211 sys
drwxrwxrwt
4 root
root
496 Mai 23 18:25 tmp
drwxr-xr-x
11 root
root
496 Ago 3
211 usr
drwxr-xr-x
15 root
root
496 Set
211 var
Técnicas de Computaçao Forense
7 1:19 root
1
1
Página 47
3.5 Identificação de binários ELF maliciosos lrwxrwxrwx
1 root
root
25 Ago 3
4Linux – www.4linux.com.br 211 vmlinuz ->
boot/vmlinuz-2.6.32-5-686
Now we’re talking. ;)
E se a tabela de partições estiver corrompida?
É possível que a tabela de partições do disco esteja corrompida, neste caso é bom que você conheça o filesystem utilizado para tentar identificar os dados incosistentes e consertá-los. Se a situação estiver muito ruim, o jeito é utilizar carving , como fizemos com dumps de memória.
3.5 Identificação de binários ELF maliciosos Após recuperar arquivos, deletados ou não, de um filesystem, dump de memória, captura de tráfego de rede ou qualquer outra fonte de dados, pode ser preciso analisá-lo. Cada tipo de arquivo requer uma analise à parte mas em especial os binários executáveis podem conter código malicioso e nesta seção vamos estudar como fazer uma análise básica deles. Supondo que você recuperou um arquivo chamado "suspeito", vamos rodar algumas ferramentas para tentar documentar seu comportamento, começando pela file, que tenta identificar o tipo de arquivo em questão:
$ file suspeito suspeito: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=x341dd4ba97cb5263efd9d1ede68e4a1f633bb7, not stripped
Página 48
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.5 Identificação de binários ELF maliciosos
Já deu pra saber que o arquivo é um ELF (formato de executáveis usado no Unix/Linux) e foi compilado para 64-bits, dentre outras informações.
3.5.1 Enumerando funções O readelf é um software presente no conjunto binutils para leitura de dados em executáveis ELF. Ele tem muitas opções, mas podemos começar pela mais básica que é a de exibir o cabeçalho do arquivo: $ readelf -h suspeito ELF Header: Magic:
7f 45 4c 46 2 1 1
Class:
ELF64
Data:
2’s complement, little endian
Version:
1 (current)
OS/ABI:
UNIX - System V
ABI Version:
Type:
EXEC (Executable file)
Machine:
Advanced Micro Devices X86-64
Version:
x1
Entry point address:
x449
Start of program headers:
64 (bytes into file)
Start of section headers:
7512 (bytes into file)
Flags:
x
Size of this header:
64 (bytes)
Size of program headers:
56 (bytes)
Number of program headers:
8
Size of section headers:
64 (bytes)
Number of section headers:
29
Section header string table index: 28
O readelf apresenta uma série de informações úteis, dentre elas o endereço do entrypoint, que é onde o código do programa começa a ser executado. Neste nosso
Técnicas de Computaçao Forense
Página 49
3.5 Identificação de binários ELF maliciosos
4Linux – www.4linux.com.br
exemplo, é em 0x400490. Já que estamos lidando com um binário dinamicamente linkado (vide saída do file), podemos pedir ao readelf que nos mostre a tabela de símbolos dinâmicos utilizados pelo binário:
$ readelf --dyn-syms suspeito Symbol table ’.dynsym’ contains 6 entries: Num:
Value
Size Type
Bind
Vis
Ndx Name
:
NOTYPE LOCAL DEFAULT
UND
1:
FUNC
GLOBAL DEFAULT
UND write@GLIBC_2.2.5 (2)
2:
FUNC
GLOBAL DEFAULT
UND system@GLIBC_2.2.5
3:
FUNC
GLOBAL DEFAULT
UND
(2) __libc_start_main@GLIBC_2.2.5 (2) 4:
NOTYPE WEAK
5:
FUNC
DEFAULT
GLOBAL DEFAULT
UND __gmon_start__ UND creat@GLIBC_2.2.5 (2)
De fato, trata-se de um binário compilado em C, visto que as funções que ele utiliza estão na glibc (GNU C Library) e ele usa as funções write(), system() e creat(), para checar o que tais funções fazem, basta checar as páginas de manual nas seções 2 e 3:
$ man -s 2,3 write $ man -s 2,3 system $ man -s 2,3 creat
Experimente também usar o comando strings para buscar por texto dentro do binário suspeito. Isto pode adiantar muito trabalho. ;)
Página 50
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.5 Identificação de binários ELF maliciosos
3.5.2 Disassemblando a main() Como trata-se de um binário compilado em C (assim como a maioria dos binários no mundo UNIX/Linux, seria particularmente interessante olhar algum código da função main() e das outras funções que são chamadas por ela. Para isso podemos usar o objdump:
$ objdump -M intel-mnemonics -d suspeito | grep -C 4 ’call.*main’ 449e: 54
push
rsp
449f: 49 c7 c 4 6 4
mov
r8,x464
44a6: 48 c7 c1 5 6 4
mov
rcx,x465
44ad: 48 c7 c7 9c 5 4
mov
rdi,x459c
44b4: e8 b7 ff ff ff
call
447 <__libc_start_main@plt>
44b9: f4
hlt
44ba: 9
nop
44bb: 9
nop
44bc: 48 83 ec 8
sub
rsp,x8
O objdump é capaz de disassemblar as seções de código do ELF muito bem. Usei a opção -M intel-mnemonics para produzir a saída do disassembly na sintaxe Intel, -d para disassemblar as seções de código. Já no grep, a opção -C 4 faz serem exibidas 4 linhas antes e 4 depois do casamento da expressão regular. Eu busquei por ’call.*main’ porque normalmente o endereço da função main() do programa é passado por último para a __libc_start_main(), que é responsável por chamá-la, dentre outras coisas.
Ao contrário do que se aprende na faculdade, a main() não é a primeira função a ser executada num programa feito em C. Muito código rola antes de o código que o programador efetivamente inseriu possa ser executado.
Técnicas de Computaçao Forense
Página 51
3.5 Identificação de binários ELF maliciosos
4Linux – www.4linux.com.br
Percebeu alguns endereços sendo copiado para alguns registrados antes da chamada a __libc_start_main()? Vamos buscar o último (possivelmente a main do programador) com o objdump novamente: $ objdump -M intel-mnemonics -d suspeito | grep -A 4 ’^ 459c’ 459c: 55
push
rbp
459d: 48 89 e5
mov
rbp,rsp
45a: 48 81 ec f 11
sub
rsp,x11f
45a7: 48 8d 95 1 ee ff ff
lea
rdx,[rbp-x11f]
45ae: b8 28 7 4
mov
eax,x4728
45b3: b9 3c 2
mov
ecx,x23c
45b8: 48 89 d7
mov
rdi,rdx
45bb: 48 89 c6
mov
rsi,rax
45be: f3 48 a5
rep movs QWORD PTR es:[rdi],QWORD PTR
ds:[rsi] 45c1: 48 89 f
mov
rax,rsi
45c4: 48 89 fa
mov
rdx,rdi
45c7: f b6 8
movzx ecx,BYTE PTR [rax]
45ca: 88 a
mov
BYTE PTR [rdx],cl
45cc: 48 83 c2 1
add
rdx,x1
45d: 48 83 c 1
add
rax,x1
45d4: be ff 1
mov
esi,x1ff
45d9: bf f 6 4
mov
edi,x46f
45de: e8 9d fe ff ff
call
448
45e3: 89 45 fc
mov
DWORD PTR [rbp-x4],eax
45e6: c7 45 f8
mov
DWORD PTR [rbp-x8],x
45ed: 83 7d fc
cmp
DWORD PTR [rbp-x4],x
45f1: 75 7
jne
45fa
45f3: b8 1
mov
eax,x1
45f8: eb 39
jmp
4633
45fa: 48 8d 8d 1 ee ff ff
lea
rcx,[rbp-x11f]
461: 8b 45 fc
mov
eax,DWORD PTR [rbp-x4]
464: ba e1 11
mov
edx,x11e1
469: 48 89 ce
mov
rsi,rcx
46c: 89 c7
mov
edi,eax
Página 52
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.5 Identificação de binários ELF maliciosos
46e: e8 3d fe ff ff
call
445
4613: 89 45 f8
mov
DWORD PTR [rbp-x8],eax
4616: 81 7d f8 e1 11 cmp
DWORD PTR [rbp-x8],x11e1
461d: 75 f
jne
462e
461f: bf f8 6 4
mov
edi,x46f8
4624: b8
mov
eax,x
4629: e8 32 fe ff ff
call
446
462e: b8
mov
eax,x
4633: c9
leave
4634: c3
ret
4635: 9
nop
4636: 9
nop
Estudar Assembly foge ao nosso foco, mas dá pra ter uma ideia do que o programa faz. Ou não? Se ficar difícil, pode-se partir para uma análise dinâmica, como veremos a seguir.
3.5.3 Rastreando com strace O strace é um programa bastante poderoso, que faz uso da ptrace() - uma chamada de sistema (syscall) para rastrear ações de um determinado processo, para logar todas as chamadas de sistema que um processo faz. Note que o processo faz o que o ele quer fazer, portanto se tratando de um arquivo suspeito, este deve ser executado num ambiente controlado (máquina virtual ou similares). Suas principais opções são: -f rastreia também processos filho -e expr configura um filtros para captura -o arquivo grava a captura num arquivo
Técnicas de Computaçao Forense
Página 53
3.5 Identificação de binários ELF maliciosos
4Linux – www.4linux.com.br
Na seção anterior perguntei como poderíamos ter cer teza de que as ferramentas do TSK abrem uma imagem em modo somente leitura. Uma das possibilidades é rastreando chamadas à syscall open (que abre arquivos e dispositivos) com o strace:
$ strace -o mmls.log -e open mmls sda.img $ grep sda mmls.log open("sda.img", O_RDONLY)
= 3
open("sda.img", O_RDONLY)
= 3
open("sda.img", O_RDONLY)
= 3
open("sda.img", O_RDONLY)
= 3
A syscall open foi chamada com a flag O_RDONLY, que garante que o arquivo será aberto com permissão somente para leitura. ;) Agora vamos olhar o suspeito:
$ strace ./suspeito creat("/tmp/ls", 777)
= 3
write(3, "\177ELF\2\1\1\\\\\\\\\\2\>\\1\\\l\4@\\\\\"..., 4577) = 4577 clone(child_stack=, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=x7ffff575568) = 18172 wait4(18172, [{WIFEXITED(s) && WEXITSTATUS(s) == }], , NULL) = 18172 --- SIGCHLD (Child exited) @ () --exit_group()
= ?
Deixarei como exercício para você dizer o que este suspeito faz. Como dica, use a opção -f do strace para capturar as chamadas também do processo filho criado pela chamada à syscall clone e o man do próprio Linux para consulta. Para finalizar, segue uma lista de características geralmente encontradas em binários suspeitos (mas não é regra):
Página 54
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
3.5 Identificação de binários ELF maliciosos
• Nomes longos ou diferentes do estilo Unix • Tamanho grande (> 1 MB) • Sem símbolos • Sem strings legíveis dentro • Fora dos diretórios bin ou sbin E vale o bom senso. ;)
Técnicas de Computaçao Forense
Página 55
Capítulo 4 Investigação em ambientes Windows Até o momento só utilizamos softwares livres em nossas análises e vamos continuar dando preferências aos softwares de código aberto, por motivos óbvios. A ideia aqui é analisar no GNU/Linux dumps provenientes de sistemas Windows, mas para a captura, pelo menos de memória, vamos precisar rodar ferramentas no Windows e desta vez não vamos optar por ferramentas livres devido à compatibilidade. Ao invés disso, trabalharemos com ferramentas freeware. Este capítulo será menor, visto que várias técnicas de análise já foram apresentadas no capítulo anterior e utilizaremos das mesmas técnicas, com algumas peculiaridades, para análise de dumps Windows, portanto daremos maior foco nas diferenças.
4.1 Características de segurança dos Windows atuais As versões recentes do Windows, como 8 e 2012 (server) possuem algumas diferenças no layout de memória e sistema de arquivos, a começar pelo novo filesystem chamdo ReFS (Resilient File System) que não é de todo compatível com o NTFS, apesar de ser similar na camada mais alta de sua imeplementação.
57
4.2 Aquisição e análise de RAM com win32dd
4Linux – www.4linux.com.br
O NTFS ainda é muito utilizado, portanto daremos um foco especial nele, mas também falaremos do novo ReFS. Os softwares de aquisição de memória que não foram atualizados também encontram algumas dificuldades nas versões mais recentes do Windows, visto que diferentes métodos em kernel-land podem ser utilizados para aquisição de memória. Falaremos mais adiante.
4.2 Aquisição e análise de RAM com win32dd Há poucas alternativas gratuitas para aquisição de memória às suítes pagas como EnCase, WindowsSCOPE e Kntdd. Algumas desatualizadas como o mdd não funcionam mais tão bem. Por sorte temos a suíte MoonSols, que contempla o win32dd.exe e o win64dd.exe, para aquisição em sistemas Windows e 32 e 64-bits, respectivamente. Apesar de também ser proprietária e paga, existe uma versão denominada "Community Edition", que ainda é distribuida gratuitamente, mas sob uma licença proprietária, infelizmente. O win32dd possui muitas opções interessantes, dentre elas: /f file configura o arquivo de saída do dump /s valor já calcula um hash do dump gerado (2 para MD5) /l envia o dump para um servidor de rede
Para capturar um dump de toda a memória mapeada, basta executar um cmd.exe com privilégios administrativos e comandar:
C:\> win64dd.exe /f ramdump win64dd - 1.3.1.21417 - (Community Edition) Kernel land physical memory acquisition
Página 58
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
4.2 Aquisição e análise de RAM com win32dd
Copyright (C) 27 - 21, Matthieu Suiche Copyright (C) 29 - 21, MoonSols Name
Value
----
-----
File type:
Raw memory dump file
Acquisition method:
PFN Mapping
Content:
Memory manager physical memory block
Destination path:
ramdump
O.S. Version:
Microsoft Windows Server 28 Server Standard wi
thout Hyper-V, 64-bit Service Pack 2 (build 62) Computer name: Physical memory in use: Physical memory size:
SRV3 33% 41844 Kb (
486 Mb)
Physical memory available: 2764252 Kb (
2699 Mb)
Paging file size:
8624352 Kb (
8422 Mb)
Paging file available:
7168152 Kb (
7 Mb)
Virtual memory size:
8589934464 Kb (838867 Mb)
Virtual memory available:
8589892868 Kb (8388567 Mb)
Extented memory available:
Kb (
Mb)
Physical page size:
496 bytes
Minimum physical address:
x1C
Maximum physical address:
x13FFFF
Address space size:
53687912 bytes (524288 Kb)
--> Are you sure you want to continue? [y/n] y
Técnicas de Computaçao Forense
Página 59
4.2 Aquisição e análise de RAM com win32dd Acquisition started at:
4Linux – www.4linux.com.br
[25/5/212 (DD/MM/YYYY) 6:9:48 (UTC)]
Processing....Done. Acquisition finished at:
[212-5-25 (YYYY-MM-DD) 6:1:4 (UTC)]
Time elapsed:
:52 minutes:seconds (52 secs)
Created file size:
53687912 bytes (
NtStatus (troubleshooting):
x
Total of written pages:
146332
Total of inacessible pages: Total of accessible pages: Physical memory in use: Physical memory size:
512 Mb)
146332 33% 41844 Kb (
486 Mb)
Physical memory available: 276972 Kb (
274 Mb)
Paging file size:
8624352 Kb (
8422 Mb)
Paging file available:
7175212 Kb (
77 Mb)
Virtual memory size:
8589934464 Kb (838867 Mb)
Virtual memory available:
8589892868 Kb (8388567 Mb)
Extented memory available:
Kb (
Mb)
Physical page size:
496 bytes
Minimum physical address:
x1C
Maximum physical address:
x13FFFF
Address space size:
53687912 bytes (524288 Kb)
O arquivo ramdump será criado no diretório atual com o conteúdo da memória RAM.
Página 60
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
4.3 Aquisição de dados de filesystems NTFS e ReFS
Existe também uma ferramenta chamda DumpIt, do mesmo autor do win32dd e win64dd, que funciona para ambas as arquiteturas e pode ser usada para gerar um dump rápido, apenas com um duplo-clique, já que não aceita nenhuma opção ou argumento. Normalmente é suficiente para gerar um dump padrão e completo, como se fosse o dd, no Linux.
4.3 Aquisição de dados de filesystems NTFS e ReFS O NTFS se estabeleceu como filesystem padrão nas versões do Windows para servidores desde o Windows NT e se mantém até o Windows 2008. Já nas versões para estação de trabalho, sua popularização veio com o Windows XP e desde então vem sido o padrão de instalação até o Windows 7. A última versão da especificação é a 3.1 (não confundir com a versão do driver, que é a 6.1 no Windows 7 e 2008 R2) e basearemos nossos estudos nesta versão. Claro que nosso estudo será válido também para entedimento de versões anteriores à 3.1 ou mesmo posteriores, ou até outros filesystems como o ReFS (Windows 8) que veremos mais adiante. No Windows é possível saber qual a versão de uma partição NTFS com o seguinte comando: > fsutil fsinfo ntfsinfo c:
Você deve substituir c: pela letra associada à partição desejada.
4.3.1 Estrutura do NTFS 3.1 Após localizar a partição NTFS (0x7) depois de ler a tabela de partições no MBR, a primeira estrutura é o setor de boot da partição , de 512 bytes. A existência
Técnicas de Computaçao Forense
Página 61
4.4 Análise de dumps com Volatility
4Linux – www.4linux.com.br
deste setor é uma característica comum nos filesystems populares e nele há várias informações importantes para forense, dentre elas um trecho conhecido como BPB (Bios Parameter Block), que começa no byte 0xb do setor de boot da partição e vai até o byte 0x54, resultando em 0x49 bytes de tamanho. O BPB é uma estrutura com vários campos, sendo o mais importante deles o campo de 8 bytes que começa no byte 0x30 chamado LogicalClusterMFT. Este cara contém o número do cluster onde está armazenada a MFT (Master File Table), a tabela que referencia todos os arquivos presentes na partição. Em uma analogia simples, esta tabela é para o filesystem o que um índice é para um livro. Uma maneira fácil de identificar uma entrada na MFT é a string FILE, no início de cada entrada de 1024 bytes (2 setores). Cada entrada representa um arquivo, mas existem arquivos especiais chamados metafiles que contém informações sobre a partição. Existe até mesmo uma entrada que representa a própria MFT.
Extraindo arquivos de partições NTFS
O Sleuth Kit possui suporte à partições NTFS, logo, é possível utilizá-lo sem problemas. As técnicas de carving apresentadas e ferramentas como foremost e scalpel também possuem suporte e podem ser utilizadas quando a partição estiver corrompida e não puder ser montada.
4.4 Análise de dumps com Volatility Para dumps de memória, a ferramenta livre mais utilizada é o Volatility, um framework em Python para análise de dumps de memória com suporte a várias versões do Windows. É possível realizar de forma rápida tarefas que demorariam horas, por exemplo, listar todos os processos abertos no instante do dump de memória: $ volatility pslist -f Bob.vmem
Página 62
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
4.4 Análise de dumps com Volatility
Volatile Volatile Systems Systems Volatili Volatility ty Framewor Framework k 2. Offset(V)
Name
PID
PPID
Thds
Hnds
Time
------------------- -------------------------------------- ------ ------ ------ ------ -----------------------------------x823c883 System
4
58
573 197-1-1 ::
x81f4228 smss.exe
548
4
3
21 21-2-26 3:34:2
x822eeda csrss.exe
612
548
12
423 21-2-26 3:34:4
x81e5b2e8 winlogon.exe
644
548
21
521 21-2-26 3:34:4
x82256da services.exe
688
644
16
293 21-2-26 3:34:5
x82129da lsass.exe
7
644
22
416 21-2-26 3:34:6
x81d3f2 vmacthlp.exe
852
688
1
35 21-2-26 3:34:6
x8226687 svchost.exe
88
688
28
34 21-2-26 3:34:7
x822e1da svchost.exe
948
688
1
276 21-2-26 3:34:7
x822ea2 svchost.exe
14
688
83
1515 21-2-26 3:34:7
x81dea2 svchost.exe
11
688
6
96 21-2-26 3:34:7
x81de55f svchost.exe
1244
688
19
239 21-2-26 3:34:8
x81dde568 spoolsv.exe
146
688
11
129 21-2-26 3:34:1
x82118b vmtoolsd.exe
1628
688
5
22 21-2-26 3:34:25
x81ddd8d VMUpgradeHelper
1836
688
4
18 21-2-26 3:34:34
x82d6b88 alg.exe
224
688
7
13 21-2-26 3:34:35
x81cdd79 explorer.exe
1756
166
14
345 21-2-26 3:34:38
x81ca96f VMwareTray.exe
118
1756
1
59 21-2-26 3:34:39
x82cd5c8 VMwareUser.exe
1116
1756
4
179 21-2-26 3:34:39
x81cee5f8 wscntfy.exe
1132
14
1
38 21-2-26 3:34:4
x8233362 msiexec.exe
244
688
5
181 21-2-26 3:46:6
x81ce1af8 msiexec.exe
452
244
------ 21-2-26 3:46:7
x81c8c78 wuauclt.exe
44
14
8
188 21-2-27 19:48:49
x8221a2 wuauclt.exe
232
14
4
136 21-2-27 19:49:11
x82682 firefox.exe
888
1756
9
172 21-2-27 2:11:53
x82618c8 AcroRd32.exe
1752
888
8
184 21-2-27 2:12:23
x822964 svchost.exe
1384
688
9
11 21-2-27 2:12:36
Simples assim. O comando pslist faz o trabalho e a opção -f especifica o arquivo de imagem a se trabalhar.
Técnicas de Computaçao Forense
Página 63
4.4 Análise de dumps com Volatility
4Linux – www.4linux.com.br
Há comandos para listar conexões abertas, handles (identificadores de cada objeto no Windows), extrair um processo (executável) inteiro do dump de memóra, extrair o mapa de memória inteiro de um processo e muito mais. Você pode ver uma lista de opções com a opção -h: Supporte Supported d Plugin Plugin Commands Commands: : bioskbd
Reads the keyboard buffer from Real Mode memory
conn connec ecti tion ons s
Prin Print t lis list t of of ope open n con conne nect ctio ions ns [Win [Windo dows ws XP Only Only] ]
conn connsc scan an
Scan Scan Phys Physic ical al memo memory ry for for _TCP _TCPT_ T_OB OBJE JECT CT obje object cts s (tcp (tcp conn connec ecti tion ons) s)
cra crashin hinfo
Dump cra crash-d h-dump ump inf inform ormatio tion
dlldump
Dump DLLs from a process address space
dlllist
Print list of loaded dlls for each process
driv driver ersc scan an
Scan Scan for for driv driver er obje object cts s _DRI _DRIVE VER_ R_OB OBJE JECT CT
file filesc scan an
Scan Scan Phys Physic ical al memo memory ry for for _FIL _FILE_ E_OB OBJE JECT CT pool pool allo alloca cati tion ons s
getsids
Print the SIDs owning each process
handles
Print list of open handles for each process
has hashdum dump
Dumps mps passwo swords rds has hashes hes (LM (LM/NT /NTLM) LM) fro from memor mory
hibinfo
Dump hibernation file information
hivedump
Prints out a hive
hivelist
Print list of registry hives.
hive hivesc scan an
Scan Scan Phys Physic ical al memo memory ry for for _CMH _CMHIV IVE E obje object cts s (reg (regis istr try y hive hives) s)
ima imageco ecopy
Copie pies a phy physic sical add addr ress spa space out as a ra raw DD DD im image age
ima imagein einfo
Ident entify ify inf inform ormatio tion for the ima image
insp inspec ectc tcac ache he
Insp Inspec ect t the the cont conten ents ts of a cac cache he
kdb kdbgsca scan
Searc arch for and dump ump potent ential ial KDBG valu alues
kpc kpcrsca scan
Searc arch for and dump ump potent ential ial KPCR valu alues
lsa lsadump ump
Dump (de (decryp rypted ted) LSA secre crets fro from the regis gistry try
memdump
Dump the addressable memory for a process
memmap
Print the memory map
moddump
Dump a kernel driver to an executable file sample
mods modsca can n
Scan Scan Phys Physic ical al memo memory ry for for _LDR _LDR_D _DAT ATA_ A_TA TABL BLE_ E_EN ENTR TRY Y obje object cts s
modules
Print list of loaded modules
muta mutant ntsc scan an
Scan Scan for for muta mutant nt obje object cts s _KMU _KMUTA TANT NT
net netscan can
Scan a Vista sta, 28 or Wind indows ows 7 imag mage for conn onnecti ctions ons and and socket kets
Página 64
Técnicas de Computaçao Forense
4Lin 4Linux ux – ww www w.4lin .4linux ux.c .com om.b .brr
4.5 4.5 Ide Ident ntific ificaçã açãoo e análi análise se de biná binário rioss PE mali malicio cioso soss
patcher
Patches memory based on page scans
pri printke tkey
Print int a regi egistr stry key, and its its subkey keys and valu alues
proc procex exed edum ump p
Dump Dump a pro proce cess ss to to an exe execu cuta tabl ble e file file sam sampl ple e
proc procme memd mdum ump p
Dump Dump a pro proce cess ss to to an exe execu cuta tabl ble e memo memory ry sam sampl ple e
psl pslist
print int all runni nning proc rocesse sses by follo llowin wing the EPROC ROCESS ESS lis lists
pss psscan
Scan Phy Physica ical memor mory for _EPR EPROCE OCESS pool ool all alloca ocation ions
pstree
Print process list as a tree
sockets
Print list of open sockets
sock socksc scan an
Scan Scan Phys Physic ical al memo memory ry for for _ADD _ADDRE RESS SS_O _OBJ BJEC ECT T obje object cts s (tcp (tcp sock socket ets) s)
ssdt
Display SSDT entries
str strings ngs
Match tch ph physic sical offs ffsets ets to to vi virtua tual ad addre dresses ses (m (may tak take e a whil hile, VER VERY Y ve ver
testsuite
Run unit test suit using the Cache
thr thrdsca scan
Scan phy physica ical memor mory for _ETH ETHREA READ objec jects
user useras assi sist st
Prin Print t user useras assi sist st regi regist stry ry keys keys and and info inform rmat atio ion n
vaddump
Dumps out the vad sections to a file
vadinfo
Dump the VAD info
vadtree
Walk the VAD tree and display in tree format
vadwalk
Walk the VAD tree
volshell
Shell in the memory image
O Volatility é, de longe, a ferramenta livre mais completa para análise de dumps de memória de sistemas Windows. Existe também um esforço, no repositório oficial do projeto, com uma versão para trabalhar com dumps de Linux, mas está em desenvolvimento.
4.5 Identificaç Identificação ão e análise de binários binários PE maliciosos maliciosos Existem milhares de pragas construídas para danificar sistemas e boa parte delas são executáv executáveis eis PE, que tem como sistema alvo alvo os sistemas Windows. Windows. O tipo PE (Portable Executable) é facilmente reconhecido por conta de uma herança do formato MZ do MS-DOS que recebeu este nome de um dos desenvolvedores do MS-DOS chamado Mark Zbikowski. Esta assinatura "MZ"está logo no início do arquivo e faz
Técnicas de Computaçao Forense
Página 65
4.5 Identificação e análise de binários PE maliciosos
4Linux – www.4linux.com.br
parte do cabeçalho do DOS. Em hexadecimal, M e Z são os bytes 0x4d e 0x5a, respectivamente. Qualquer dúvida, consulte a tabela ASCII. Sabendo disso, é possível iniciar um processo de identificação de binários PE (maliciosos ou não) olhando os primeiros bytes do arquivo:
$ hd -n 64 putty.exe
4d 5a 9 3
4 ff ff
|MZ..............|
1
b8
4
|........@.......|
2
|................|
3
1
|................|
4
No exemplo acima pedi que o hexdump mostrasse os primeiros 64 bytes do arquivo (que não por acaso é o tamanho do cabeçalho do DOS, o primeiro dos executáveis PE). Perceba os bytes 0x4d e 0x5a logo no início e sua representação em ASCII à direita. O file também pode ajudar:
$ file putty.exe /home/nandu/winapp/putty.exe: PE32 executable (GUI) Intel 8386, for MS Windows
4.5.1 Obtendo os cabeçalhos do PE Para ver mais informações sobre o PE, pode-se utilizar o pev, um toolkit multiplataforma que fornece uma série de binários para trabalhar com arquivos PE: readpe exibecabeçalhos e seções pesec busca features de segurança
Página 66
Técnicas de Computaçao Forense
4Lin 4Linux ux – ww www w.4lin .4linux ux.c .com om.b .brr
4.5 4.5 Ide Ident ntific ificaçã açãoo e análi análise se de biná binário rioss PE mali malicio cioso soss
pedis disassembla seções inteiras ou endereços específicos pescan busca itens suspeitos pepack detecta de packers por assinatura pehash calcula hashes pestr busca strings strings ASCII e Unicode rva2ofs converte RVA em offset de arquivo ofs2rva converte offset em RVA
O read readpe pe pode pode come começa çarr o proc proces esso so de iden identitific ficaç ação ão exibi xibind ndoo os cabe cabeça çalh lhos os e seçõ seções es.. Vou mostrar duas saídas do readpe. A primeira de um executável putty.exe putty.exe inofensivo inofensivo e a segunda, de um vírus. A opção -S/–sections do readpe exibe as seções de uma PE:
$ readpe -S putty.exe Sections Name:
.text
Virtual Address:
x1
Physical Address:
x53371
Size:
x54 (34464 bytes)
Pointer To Data:
x1
Relocations:
Characteristics:
x62 contains contains executab executable le code is executab executable le is readable readable
Name:
.rdata
Virtual Address:
x55
Técnicas de Computaçao Forense
Página 67
4.5 4.5 Ide Ident ntific ificaçã açãoo e análi análise se de biná binário rioss PE mali malicio cioso soss
4Lin 4Linux ux – ww www w.4lin .4linux ux.c .com om.b .brr
Physical Address:
x1b23e
Size:
x1c (114688 bytes)
Pointer To Data:
x55
Relocations:
Characteristics:
x44 contains contains initiali initialized zed data is readable readable
Name:
.data
Virtual Address:
x71
Physical Address:
x7e4
Size:
x1 (496 bytes)
Pointer To Data:
x71
Relocations:
Characteristics:
xc4 contains contains initiali initialized zed data is readable readable is writable writable
Name:
.rsrc
Virtual Address:
x79
Physical Address:
x3b9
Size:
x4 (16384 bytes)
Pointer To Data:
x72
Relocations:
Characteristics:
x44 contains contains initiali initialized zed data is readable readable
As seções .text, .rdata, .data e .rsrc são todas previstas na documentação do PE e cada uma tem sua função. Não é obrigatório que tenham esses esses nomes mas normalmente é assim em executáveis comuns. E agora um vírus comprimido com um compressor de executáveis chamado MEW:
$ readpe readpe -S mewpacke mewpacker.ex r.exe e
Página 68
Técnicas de Computaçao Forense
4Lin 4Linux ux – ww www w.4lin .4linux ux.c .com om.b .brr
4.5 4.5 Ide Ident ntific ificaçã açãoo e análi análise se de biná binário rioss PE mali malicio cioso soss
Sections Name:
SBL
Virtual Address:
x1
Physical Address:
x23
Size:
( bytes)
Pointer To Data:
Relocations:
Characteristics:
xce contains contains executab executable le code contains contains initiali initialized zed data contains uninitialized uninitialized data is readable readable is writable writable
Name:
?ug?
Virtual Address:
x24
Physical Address:
x19
Size:
x9fa9 (4873 bytes)
Pointer To Data:
x2
Relocations:
Characteristics:
xce contains contains executab executable le code contains contains initiali initialized zed data contains uninitialized uninitialized data is readable readable is writable writable
Perceba uma seção chamada SBL (sem ponto na frente) de tamanho zerado e uma outra com um nome bem estranho. Coisa boa não é. Outro recurso é buscar funções de TLS callbacks (comumente exploradas por programadores de malware) e packers em si:
$ pescan pescan mewpacke mewpacker.ex r.exe e entrypoint:
Técnicas de Computaçao Forense
normal
Página 69
4.5 Identificação e análise de binários PE maliciosos
4Linux – www.4linux.com.br
DOS stub:
suspicious
TLS directory:
not found
Sections:
2 - suspicious
$ pepack mewpacker.exe packer:
Mew 11 SE v1.2 (Eng) -> Northfox
No exemplo acima não havia funções TLS callbacks, mas o pescan acusou que o DOS stub do PE é suspeito (foi modificado) e as seções também. Adicionalmente, o pepack detectou o packer MEW. Vale a atenção!
Packers normalmente comprimem executáveis e acabam por embaralhá-los de forma que um analisador de PE, um debugger ou outro software do gênero pode não conseguir fornecer informações corretas sobre o executável. Apesar de existirem softwares idôneos que são distribuidos packeados (para evitar engenharia reversa), é muito comum encontrarmos malwares com este recurso. Existem vários packers gratuitos, proprietários e até livres como o o UPX. Outros exemplos são Themida, Armadillo, MEW, y0da’s Cryptor e MPRESS.
4.5.2 Disassemblando o entrypoint O entrypoint (EP) de um PE é onde seu código começa a ser executado, assim como nos binários ELF. O EP fica no cabeçalho Optional, então podemos exibi-lo com o readpe e fazer um filtro para achar mais rápido o valor que queremos:
$ readpe --header optional putty_upx.exe | grep point Entrypoint:
x7f2c
E a partir do valor do EP, você pode usar o pedis para obter o disassembly:
Página 70
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
4.5 Identificação e análise de binários PE maliciosos
$ pedis --rva x7f2c putty_upx.exe 1939c86e:
6
pushad
1939c86f:
be 4 44
mov esi, x444
1939c874:
8d be d fb ff
lea edi, [esi+xfff
1939c87a:
57
push edi
1939c87b:
83 cd ff d fb ff
or ebp, xff
1939c87e:
eb 1
jmp x1931d5d
1939c88:
9
nop
1939c881:
9
nop
1939c882:
9
nop
1939c883:
9
nop
1939c884:
9
nop
1939c885:
9
nop
1939c886:
8a 6
mov al, [esi]
1939c888:
46
inc esi
1939c889:
88 7
mov [edi], al
1939c88b:
47
inc edi
1939c88c:
1 db
add ebx, ebx
[cortado...]
Na versão mais recente do kit pev, é possível disassemblar o entrypoint diretamente, sem conhecê-lo:
$ pedis --entrypoint putty_upx.exe
4.5.3 Análise comportamental com Process Explorer Assim como usamos o strace para verificar as syscalls utilizadas por um ELF, podemos usar o Process Explorer para obter as chamadas às funções da API do Windows que o PE faz. O software é gráfico e ao executá-lo, podemos criar filtros pelo nome do processo ou PID para que ele mostre ações apenas de quem queremos. Esta análise deve ser feita em um ambiente controlado, sempre.
Técnicas de Computaçao Forense
Página 71
Capítulo 5 Análise de outros tipos de arquivo Além de executáveis em si, é possível ser infectado com outros tipos de arquivos ou pode ser preciso entender algum formato específico para concluir o trabalho da perícia forense. Neste capítulo vamos analisar arquivos PDF e imagens JPG.
5.1 Documentos PDF com pdfid e pdf-parser Arquivos PDF (Portable Document Format) são verdadieros containers que podem abrigar desde simples textos e imagens a poderosos programas em Flash ou JavaScript. Dentro deles há tanto texto quando dados binários. Basicamente um PDF é uma árvore de objetos. Ao olhar um PDF com um editor de textos, você verá definições de objetos como esta:
$ head -2 pagina.pdf %PDF-1.4 %äüöß 2 obj <> stream
73
5.1 Documentos PDF com pdfid e pdf-parser
4Linux – www.4linux.com.br
[bytes] endstream endobj 3 obj 16 endobj
Os objetos podem ser de vários tipos e existem alguns nomes pré-definidos como /JavaScript, /JS, /OpenAction, /RichMedia e /Launch. Estes particularmente são preocupantes pois podem conter código executável que o leitor de PDF tentará executar ao ser aberto. Objetos também podem referenciar outros objetos, neste caso a palavra "obj"é substituída pela letra maiúscula R. Com isso já dá para traçar uma linha investigativa no sentido de observar os objetos de um documento PDF, principalmente se tiverem esses nomes sugestivos apresentados. Para facilitar o trabalho, a ferramenta pdfid já exibe os objetos interessantes:
$ ./pdfid.py teste.pdf PDFiD ..11 teste.pdf PDF Header: %PDF-1.4 obj
6
endobj
6
stream
1
endstream
1
xref
2
trailer
2
startxref
1
/Page
1
/Encrypt
/ObjStm
/JS
1
Página 74
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
5.1 Documentos PDF com pdfid e pdf-parser
/JavaScript
1
/AA
1
/OpenAction
/AcroForm
/JBIG2Decode
/RichMedia
/Launch
/Colors > 2^24
No exemplo acima, percebemos que há uma entrada de objeto nomeado /JavaScript. Com o pdf-parser, podemos buscar tal objeto:
$ ./pdf-parser.py -s ’/JavaScript’ test.pdf obj 11 Type: Referencing: 54 R [(1, ’\r\n’), (2, ’<<’), (2, ’/S’), (2, ’/JavaScript’), (2, ’/JS’), (1, ’ ’), (3, ’154’), (1, ’ ’), (3, ’’), (1, ’ ’), (3, ’R’), (2, ’>>’), (1, ’\r\n’)] << /S /JavaScript /JS 154 R >> A opção -s do define um texto a ser buscado e faz com que, se encontrado o texto, o objeto ao qual o texto pertence seja exibido. Neste caso, é o objeto 11, que está incluindo (referenciando) o objeto 154. Vamos usar então a opção -o do pdf-parse para exibir este objeto: \begin{verbatim} $ ./pdf-parser.py -o 54 test.pdf obj 154 Type: Referencing:
Técnicas de Computaçao Forense
Página 75
5.1 Documentos PDF com pdfid e pdf-parser
4Linux – www.4linux.com.br
Contains stream [(1, ’\r\n’), (2, ’<<’), (2, ’/Length’), (1, ’ ’), (3, ’’), (2, ’/Filter’), (1, ’ ’), (2, ’[’), (2, ’/F#6c#61#74e#44e#63#6fde’), (2, ’/#41#53#43II#38#35#44#65#63#6fd#65’), (2, ’]’), (2, ’>>’), (1, ’\r\n’)] << /Length /Filter [ /FlateDecode /ASCII85Decode] >>
O objeto contém um stream (fluxo) de dados, ou seja, dados binários. Os dados precisam passar por um filtro para serem revelados, pois ficam encodados no PDF. O pdf-parser é capaz de filtrar esses dados com a opção -f:
$ python ./pdf-parser.py -f -o 54 test.pdf > stream.txt
O arquivo stream.txt conterá todo o fluxo de dados após passar pelos filtros e será possível ver o código JavaScript nele.
Códigos maliciosos normalmente estão escondidos, encodados etc. O atacante tenta ocultar ao máximo aos olhos do investigador um código malicioso, para não ter sua praga inutilizada, incluindo futuros ataques em alguns casos. Por isso é importante que você se acostume com certas técnicas como strings encodadas com base64, uuencode, XOReadas com algum valor ou interpretadas de maneiras diferentes. Se você se deparasse com o texto 4¨ 665726E616E646F¨, seria capaz de ¨ descobrir o que significa? E se fosse RG8gbm90IGJlIGEgbGFtbWVyIQo= ?¨
Página 76
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
5.2 Imagens com jhead
5.2 Imagens com jhead Imagens JPG e PNG podem conter informações valiosas numa estrutura conhecida como EXIF (Exchangeable Image File Format). Nem sempre essas informações são visíveis ao SO. Avalie as capturas de tela abaixo. A primeira foi tirada no Gnome e a segunda no Windows XP. Percebemos que alguns campos existem numa captura e na outra não, mas estamos visualizando os dados da mesma imagem. O jhead é um software de linha de comando capaz de extrair todos os dados EXIF de uma imagem: $ jhead tracking.jpg File name
: tracking.jpg
File size
: 31485 bytes
File date
: 211:3:3 2:13:53
Camera make : SAMSUNG Camera model : GT-I55B Date/Time
: 21-11-18 :46:23
Resolution
: 16 x 12
Focal length :
2.7mm
Exposure time: .125 s Aperture
: f/2.7
ISO equiv.
: 2
(1/8)
Whitebalance : Auto Metering Mode: center weight Exposure
: aperture priority (semi-auto)
GPS Latitude : ? 23d 19m 44.52s GPS Longitude: ? 48d 29m 19.548s
Note que o jhead exibe até mesmo coordenadas GPS presentes na imagem, enquanto nem o Gnome nem o Windows XP o fazem. Essas informações podem ser extremamente úteis numa perícia forense.
Técnicas de Computaçao Forense
Página 77
5.3 Esteganografia
4Linux – www.4linux.com.br
5.3 Esteganografia Esteganografia é a arte de esconder uma mensagem em algum objeto, ou arquivo, em nosso caso. Existem várias técnicas para esteganografar uma mensagem, mas vamos observar aqui apenas que elas existem e podem ser feitas em imagens com softwares como steghide ou outguess:
$ echo mentebinaria > msg $ outguess -d msg chess.jpg out.jpg chess.jpg out.jpg Reading chess.jpg.... JPEG compression quality set to 75 Extracting usable bits:
139977 bits
Correctable message size: -35176 bits, 1317841289332224.% Encoded ’o’: 14 bits, 13 bytes Finding best embedding... :
6(44.4%)[57.7%], bias
29(.48), saved:
-1, total:
.4%
3:
62(45.6%)[59.6%], bias
26(.42), saved:
-1, total:
.4%
13:
62(45.6%)[59.6%], bias
2(.32), saved:
-1, total:
.4%
36:
59(44.%)[56.7%], bias
17(.29), saved:
, total:
.4%
117:
63(46.3%)[6.6%], bias
9(.14), saved:
-1, total:
.5%
117, 72: Embedding data: 14 in 139977 Bits embedded: 136, changed: 63(46.3%)[6.6%], bias: 9, tot: 139913, skip: 139777 Foiling statistics: corrections: 48, failed: , offset: 53.5 +- 58.2916 Total bits changed: 72 (change 63 + bias 9) Storing bitmap into data... Writing out.jpg....
No exemplo acima o conteúdo do arquivo msg.txt foi inserido na imagem chess.jpg e a nova imagem out.jpg foi criada. As imagens não apresentam diferença visual, mas tanto o tamanho quanto o hash do arquivo são diferem entre si:
Página 78
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
5.3 Esteganografia
$ wc -c *.jpg 145338 chess.jpg 16151 out.jpg $ md5sum *.jpg 4c59e2956ba43e342a18ab4e855cbb4 chess.jpg 9e8dc2125a2d8adbab424167f62947fa out.jpg
Também é possível esconder mensagens em arquivos de áudio com ferramentas como o mp3steg. Na realidade, basta estudar o formato do arquivo e descobrir onde você pode colocar sua mensagem.
Técnicas de Computaçao Forense
Página 79
Capítulo 6 Análise tráfego TCP/IP É importante para o pesquisador saber analisar um tráfego de rede (captura de pacotes), principalmente porque é um meio comum de vazamento de dados, infecções por pragas, contém vestígios de ataques, enfim, as possibilidades são muitas.
6.1 Sniffers Normalmente o driver de uma placa de rede descarta os pacotes que não são destinados ao endereço dela. Este é o funcionamento normal, no entanto, é possível alterar este comportamento utilizando softwares conhecidos como sniffers de rede. Além de não descartar nenhum pacote, os sniffers capturam (salvam) os bytes dos pacotes recebidos em disco. O formato mais conhecido para armazenar pacotes é o PCAP, implementado pela libpcap e WinPcap. Exemplos de sniffers populares são o tcpdump e o Wireshark, sendo que este último é também um poderoso analisador de tráfego. O comando abaixo fará uma captura na interface wlan0 por todo pacote que seja destinado ou tenha como origem a porta 80:
81
6.1 Sniffers
4Linux – www.4linux.com.br
# tcpdump -i wlan -w captura.pcap ’port 8’
O último parâmetro é a expressão, uma ou mais condições que devem ser satisfeitas para o tcpdump salvar o pacote no arquivo informado pela opção -w. Caso nenhuma expressão seja informada, todos os pacotes serão salvos. Uma expressão para capturar todos os pacotes ICMP com tamanho maior que zero seria: # tcpdump -i wlan -w captura.pcap ’icmp and len > ’
Para visualizar a documentação completa da criação de filtros (expressões), veja o manual da libpcap: $ man 7 pcap-filter
6.1.1 Entendendo o modelo OSI com o Wireshark O modelo OSI (Open Systems Interconnection) é um modelo teórico de cadamas para comunicação entre dispositivos de rede. Ele especifica as famosas 7 camadas, que mostraremos com uma descrição resumida abaixo: 1 - Física a camada de mais baixo nível, que trata dos meios físicos de conexão. 2 - Enlace correção de erros, endereçamento físico/MAC, PPP. 3 - Rede endereçamento IP, roteamento. 4 - Transporte TCP/UDP. 5 - Sessão estabelecimento de sessões.
Página 82
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br
6.1 Sniffers
6 - Apresentação tradução de dados. 7 - Aplicação protocolos de alto nível (HTTP, DNS, FTP etc).
Não vamos estudar teoria de redes aqui e por isso vamos entender como o Wireshark nos apresenta informações sobre um pacote:
Ao expandir o primeiro item, temos informações básicas sobre a transmissão do pacote como tamanho, hora em que foi transmitido e o número (frame) em relação ao início da captura. Podemos fazer uma analogia com a cada 1 do modelo OSI (física) aqui, mas não bate 100%. Já o item seguinte, comparamos à camada 2 (enlace), que é onde estão os endereços MAC de destino e origem. No terceiro item tem todas as informações sobre o protocolo IP (analóga à camada 3 - rede). Nele temos endereços IP de origem e destino, TTL do pacote, checksum, dentre outros. O próximo item pode ser comparado à camada 4 (transporte), pois possui informações sobre o protocolo de transporte utilizado (TCP/UDP), portas utilizadas, flags TCP. E por último a interpretação do protocolo HTTP (neste caso, que é um pacote HTTP mesmo), que pode ser comparado à soma das camadas 5, 6 e 7. É similar aoModelo TCP/IP de 4 camadas.
Técnicas de Computaçao Forense
Página 83
Capítulo 7 Anti-forense É previsíveil que criadores de pragas, atacantes e criminosos virtuais em geral não queiram ter suas armas descobertas, por isso utilizam alguns artefatos para evitar, comprometer ou dificultar a perícia, por exemplo: • Um programa que se exclui após uma reinicialização da máquina • Binários alterados para enganar o perito • Formatação de mídias • Esteganografia • Criptografia A lista acima contém somente alguns exemplos. Tais ações dependem da criatividade do atacante e dos recursos disponíveis. A técnica de evitar tais técnicas por vezes é chamada de anti-anti-forense e consiste em qualquer meio de ipedir essas ações de atacantes, por exemplo: • Usar seus próprios binários, compilando-os estaticamente
85
7.1 Compilando seus próprios binários para alvos Linux
4Linux – www.4linux.com.br
• Obter um dump de memória rapidamente (de preferência via pen drive ao ser inserido) • Buscar por arquivos escondidos em imagens, músicas etc • Saber detectar a presençã de mensagens estaganografadas e criptografadas
7.1 Compilando seus próprios binários para alvos Linux Compilar seu próprio binário estático para rodar na máquina alvo pode evitar que você rode um binário malicioso na máquina e/ou dependa de versões de bibliotecas específicas que a máquina alvo pode não ter. Para isso, a ideia é baixar o códigofonte do software e, se for escrito em C, adicionar a opção -static ao gcc. Veremos agora um exemplo de compilação do dcfldd. Para softwares escritos em outras linguagens, consulte a documentação do compilador utilizado.
$ apt-get source dcfldd $ cd dcfldd* $ CFLAGS=-static ./configure $ make
O arquivo binário dcfldd será criado e você pode conferir se realmente é um binário estático com o ldd:
$ ldd dcfldd not a dynamic executable
Página 86
Técnicas de Computaçao Forense
Capítulo 8 Anexo I - Códigos de tipos de partições 01 FAT12 02 XENIX root 03 XENIX usr 04 FAT16 <32M 05 Extended 06 FAT16 07 HPFS/NTFS/exFAT 08 AIX 09 AIX bootable 0A OS/2 Boot Manager
87
4Linux – www.4linux.com.br 0B W95 FAT32 0C W95 FAT32 (LBA) 0E W95 FAT16 (LBA) 0F W95 Ext’d (LBA) 10 OPUS 11 Hidden FAT12 12 Compaq diagnostics 14 Hidden FAT16 <32M 16 Hidden FAT16 17 Hidden HPFS/NTFS 18 AST SmartSleep 1B Hidden W95 FAT32 1C Hidden W95 FAT32 (LB 1E Hidden W95 FAT16 (LB 24 NEC DOS 27 Hidden NTFS WinRE 39 Plan 9 3C PartitionMagic recov
Página 88
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br 40 Venix 80286 41 PPC PReP Boot 42 SFS 4D QNX4.x 4E QNX4.x 2nd part 4F QNX4.x 3rd part 50 OnTrack DM 51 OnTrack DM6 Aux1 52 CP/M 53 OnTrack DM6 Aux3 54 OnTrackDM6 55 EZ-Drive 56 Golden Bow 5C Priam Edisk 61 SpeedStor 63 GNU HURD or SysV 64 Novell Netware 286 65 Novell Netware 386
Técnicas de Computaçao Forense
Página 89
4Linux – www.4linux.com.br 70 DiskSecure Multi-Boo 75 PC/IX 80 Old Minix 81 Minix / old Linux 82 Linux swap / Solaris 83 Linux 84 OS/2 hidden C: drive 85 Linux extended 86 NTFS volume set 87 NTFS volume set 88 Linux plaintext 8E Linux LVM 93 Amoeba 94 Amoeba BBT 9F BSD/OS A0 IBM Thinkpad hiberna A5 FreeBSD A6 OpenBSD
Página 90
Técnicas de Computaçao Forense
4Linux – www.4linux.com.br A7 NeXTSTEP A8 Darwin UFS A9 NetBSD AB Darwin boot AF HFS / HFS+ B7 BSDI fs B8 BSDI swap BB Boot Wizard hidden BE Solaris boot BF Solaris C1 DRDOS/sec (FAT-12) C4 DRDOS/sec (FAT-16 < C6 DRDOS/sec (FAT-16) C7 Syrinx DA Non-FS data DB CP/M / CTOS / ... DE Dell Utility DF BootIt
Técnicas de Computaçao Forense
Página 91
4Linux – www.4linux.com.br E1 DOS access E3 DOS R/O E4 SpeedStor EB BeOS fs EE GPT EF EFI (FAT-12/16/32) F0 Linux/PA-RISC boot F1 SpeedStor F2 DOS secondary F4 SpeedStor FB VMware VMFS FC VMware VMKCORE FD Linux raid autodetec FE LANstep FF BBT
Página 92
Técnicas de Computaçao Forense
Capítulo 9 Anexo II - Tabela ASCII Dec Hex
Dec Hex
Dec Hex
NUL
16 1 DLE
32 2
1 1 SOH
17 11 DC1
2 2 STX
Dec Hex 48 3
Dec Hex
Dec Hex
Dec Hex
8 5 P
96 6 ‘
112 7 p
33 21 ! 49 31 1
65 41 A 81 51 Q
97 61 a
113 71 q
18 12 DC2
34 22 " 5 32 2
66 42 B 82 52 R
98 62 b
114 72 r
3 3 ETX
19 13 DC3
35 23 # 51 33 3
67 43 C 83 53 S
99 63 c
115 73 s
4 4 EOT
2 14 DC4
36 24 $ 52 34 4 68 44 D 84 54 T 1 64 d 116 74 t
5 5 ENQ
21 15 NAK
37 25 % 53 35 5 69 45 E 85 55 U 11 65 e 117 75 u
6 6 ACK
22 16 SYN
38 26 & 54 36 6 7 46 F 86 56 V 12 66 f 118 76 v
7 7 BEL
23 17 ETB
39 27 ’ 55 37 7 71 47 G 87 57 W 13 67 g 119 77 w
8 8 BS
24 18 CAN
4 28 ( 56 38 8
72 48 H 88 58 X
14 68 h
12 78 x
9 9 HT
25 19 EM
41 29 )
73 49 I
15 69 i
121 79 y
1 A LF
26 1A SUB
42 2A * 58 3A : 74 4A J 9 5A Z 16 6A j 122 7A z
11 B VT
27 1B ESC
43 2B + 59 3B ; 75 4B K 91 5B [ 17 6B k 123 7B {
12 C FF
28 1C FS
44 2C ,
6 3C <
76 4C L
92 5C \
18 6C l
124 7C |
13 D CR
29 1D GS
45 2D -
61 3D =
77 4D M
93 5D ]
19 6D m
125 7D }
14 E SO
3 1E RS
46 2E .
62 3E >
78 4E N
94 5E ^
11 6E n
126 7E ~
15 F SI
31 1F US
47 2F /
63 3F ?
79 4F O
95 5F _
111 6F o
127 7F DEL
57 39 9
64 4 @
Dec Hex
89 59 Y
93
Capítulo 10 Anexo III - Tabela de caracteres UTF-8 Hex
Hex
Hex
c2 a
c2 ac ¬ c2 b8 ¸
c2 a1 ¡
c2 ad
c2 b9
c2 a2 ¢ c2 ae ® c2 ba º c2 a3 £
c2 af
c2 bb »
Hex
Hex
c3 84 Ä c3 9 Ð c3 85 Å
Hex
c3 93 Ó
Hex
c3 9c Ü c3 a8 è c3 b4 ô
c3 91 Ñ c3 9d Ý c3 a9 é
c3 86 Æ c3 92 Ò c3 87 Ç
Hex
c3 b5 õ
c3 9e Þ c3 aa ê c3 b6 ö c3 9f ß
c3 ab ë
c3 b7 ÷
c2 a4 ¤ c2 b ° c2 bc ¼
c3 88 È c3 94 Ô
c3 a à c3 ac ì c3 b8 ø
c2 a5 ¥ c2 b1 ± c2 bd ½
c3 89 É c3 95 Õ
c3 a1 á c3 ad í c3 b9 ù
c2 a6 ¦ c2 b2 c2 be c2 a7 §
c3 8a Ê
c3 96 Ö
c3 a2 â
c3 ae î
c3 ba ú
c2 b3 c2 bf ¿
c3 8b Ë c3 97 ×
c3 a3 ã c3 af ï c3 bb û
c2 a8 \ c2 b4 \ c3 8 À
c3 8c Ì c3 98 Ø
c3 a4 ä c3 b ð c3 bc ü
c2 a9 © c2 b5 c3 81 Á
c3 8d Í c3 99 Ù
c3 a5 å c3 b1 ñ c3 bd ý
c2 aa ª c2 b6 ¶ c3 82 Â
c3 8e Î c3 9a Ú
c3 a6 æ c3 b2 ò c3 be þ
c2 ab «
c3 8f Ï c3 9b Û
c3 a7 ç c3 b3 ó c3 bf ÿ
c2 b7 · c3 83 Ã
95
Capítulo 11 Anexo IV - Laudo O laudo deve ser escrito em três vias assinadas pelo perito. Segue exemplo: Listing: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Perito responsável: N om e : F e r na n do M er c ê s CPF: 987.21.432-99 Email: [email protected] Telefone Comercial: (21) 8-8 T el ef on e C el ul ar :
( 21 ) 3 - 3
D at a d e i n í c io d a p e r í c ia : 1/4/212 D at a d a e mi ss ã o d o l au do : 1/4/212 Sumário executivo: I n fo r ma ç õ e s s i gi l os a s f or a m c o pi a da s d o s e rv i do r d e d a d os d a empresa Dexter
16
C ou rr ie r
e nv ia da s p o r e - m ai l p a ra t er ce ir os . O o bj et iv o é
d e sc o br i r c om o e ss a
17 informação vazou. 18 19 E s co po d a p er í c i a :
97