Passou e nem eu percebi. Esse blog acabou de completar 1 ano no último 17 de junho.
Um marco bacana para se avaliar o resultado do trabalho.
Temos pouco mais de 60 artigos, alguns leitores assíduos e a impressão de estar, pelos feedbacks recebidos, contribuindo de alguma forma, ainda que pequena, para o crescimento da nossa área no Brasil.
Agradeço a todos os comentários, e desejo que, no aniversário do Blog, quem receba o presente sejamos todos nós: Conhecimento.
Um grande abraço a todos,
Até o próximo post !
terça-feira, 24 de junho de 2008
Hash Parcial
Estive hoje em uma apresentação do novo produto de DLP (Data Loss Prevention) da TrendMicro. O produto é bastante interessante, mas a grata surpresa foi perceber que o mecanismo chamado pela Trend de fingerprint do arquivo é o hash parcial (pelo menos tem todas as características), lançado há algum tempo pelo Jesse Kornblum no utilitário ssdeep, e comentado aqui no blog.
A constatação é boa porque, de certa forma, isso mostra que a indústria de software se realimenta. Algoritmos usados para Forense Computacional, ou pelo menos criados inicialmente para tal, podem encontrar uso em outras áreas, e podem acabar sendo optimizados e melhorados. Por outro lado, softwares criados para outras áreas podem acabar achando espaço por aqui, como o utilitário dd.
O software é o LeakProof 3, e pode ser encontrado no site da TrendMicro.
Até o próximo post !
A constatação é boa porque, de certa forma, isso mostra que a indústria de software se realimenta. Algoritmos usados para Forense Computacional, ou pelo menos criados inicialmente para tal, podem encontrar uso em outras áreas, e podem acabar sendo optimizados e melhorados. Por outro lado, softwares criados para outras áreas podem acabar achando espaço por aqui, como o utilitário dd.
O software é o LeakProof 3, e pode ser encontrado no site da TrendMicro.
Até o próximo post !
sábado, 21 de junho de 2008
Resposta a Incidentes
Esse é um dos principais temas do nosso blog, e é tão amplo quanto controverso.
Resposta a Incidentes compreende Detectar, tratar e gerenciar aspectos envolvendo incidentes em Segurança de Informações. Tais incidentes podem ser desde uma invasão até uma mega infecção por vírus na empresa, incluindo também roubo de identidades, uso indevido, empréstimo de senha e por aí vai ... Dentro desse universo, há uma parte em especial muito ligada a Forense Computacional. O First Responder é o nome dado aos que tem a responsabilidade de chegar primeiro no local do incidente (datacenter, sala de telecom, mesa do usuário), coletar o máximo de informações sobre o incidente e em seguida tomar ações que possam contê-lo.
No ato de coletar o máximo de informações, a tarefa é um tanto árdua. Basta você parar para pensar na quantidade de coisas que precisam ser checadas para se chegar a uma conclusão (ou pelo menos perto disso) a respeito de um incidente.
Uma pequena lista do que seria interessante coletar seria:
Resposta a Incidentes compreende Detectar, tratar e gerenciar aspectos envolvendo incidentes em Segurança de Informações. Tais incidentes podem ser desde uma invasão até uma mega infecção por vírus na empresa, incluindo também roubo de identidades, uso indevido, empréstimo de senha e por aí vai ... Dentro desse universo, há uma parte em especial muito ligada a Forense Computacional. O First Responder é o nome dado aos que tem a responsabilidade de chegar primeiro no local do incidente (datacenter, sala de telecom, mesa do usuário), coletar o máximo de informações sobre o incidente e em seguida tomar ações que possam contê-lo.
No ato de coletar o máximo de informações, a tarefa é um tanto árdua. Basta você parar para pensar na quantidade de coisas que precisam ser checadas para se chegar a uma conclusão (ou pelo menos perto disso) a respeito de um incidente.
Uma pequena lista do que seria interessante coletar seria:
- A hora do sistema
- Usuários logados
- Arquivos abertos
- Informações de rede e conexões
- Informações de processos
- Mapeamento de processos com outros recursos, como portas e conexões
- O status da placa de rede
- Conteúdo do clipboard
- Últimos comandos digitados
- Informações sobre serviços ativos
- Drives mapeados e compartilhamentos
- etc, etc e etc ...
Veja que a lista é longa, não é completa e há várias formas diferentes de se obter o mesmo dado. Alguns podem ser comandos do DOS, outros são utilitários conhecidos, como os da SysInternals, da Foundstone, etc. O que importa é que:
1) A tendência dessa lista é crescer ainda mais;
2) A probabilidade de se esquecer um dos comandos durante um incidente é enorme;
3) O tempo gasto para rodar cada um desses comandos, esperando o resultado, é enorme.
Mas .... Seus problemas acabaram !
Por causa disso, algumas almas iluminadas em Forense Computacional (e em programação também, lógico) perceberam que o trabalho do First Responder seria muito mais simples se os comandos fossem agrupados e rodados de uma só vez. Com isso, surgiram os utilitários de Resposta a Incidentes. Os mais usados são:
1) Windows Forensics Toolchest (WFT);
2) Forensic Server Project (FSP);
3) Incident Response Collection Report (IRCR2);
Eu gostaria de acrescentar o COFEE, pen drive que a Microsoft está distribuindo para as Polícias, mas como eu não o tenho, não vou poder analisá-lo ...
Os três utilitários tem características semelhantes:
- Operacionalizam e serializam comandos de coleta de dados
- Os dados coletados podem ser voláteis ou não
- Permitem customizar e acrescentar novas ferramentas
- Fazem parte do Helix
Algumas diferenças:
- O WFT sempre manda os dados coletados para um drive local (pode ser um pen drive)
- O FSP sempre manda para um drive remoto, assim como o IRCR2. Entretanto, ambos podem ser configurados para mandar para um pen drive local
- O FSP tem arquitetura Cliente-Servidor, com módulo servidor FSPC e módulo cliente FRU
- O FSP e o WFT permite customização pelo arquivo .ini ou .cfg; Já o IRCR2 é um script DOS, e a customização requer esse conhecimento.
O nosso próximo artigo vai ser uma comparação entre as três ferramentas, indicando quais comandos cada uma tem. Entretanto, antes disso gostaria de comentar por que disse, no começo do artigo, sobre esse tema ser controverso.
1) Na maioria das vezes, o First Responder acaba sendo o "Last Responder"
Pois é, ainda temos equipes tão mal treinadas que o First Responder passa a ser igual marido traído. É o último a saber do incidente, quando alguns já chegaram ao local e, literalmente, lambuzaram a máquina e todas as informações. Algumas vezes, resta muito pouco de útil, e em vários casos já até reinicializaram a máquina.
2) As ferramentas, na grande maioria, alteram as evidências
Como a coleta é feita acessando os arquivos ainda montados em seu sistema de arquivos, a primeira coisa que muda é a data/hora do LastAccess. Esse é um dos atributos conhecidos como MAC times, e são essenciais para criar uma linha do tempo sobre o incidente. Ao executar as ferramentas, pelo menos o LastAccess vai indicar a data/hora em que os arquivos foram acessados pelas ferramentas.
3) Servidores 100% up
Em muitos casos, servidores não podem sair do ar de forma alguma. Há empresas que 1 minuto de downtime custa uma fortuna, e ninguém consegue bancar uma investigação que pare um servidor desses.
4) Sem necessidade
Com o avanço da Forense de Memória, cresce o número de profissionais que dispensa a metodologia de coleta dessas informações em prol de se vasculhar a memória e achar lá tudo que é necessário.
Minhas argumentações para cada um desses itens são:
1) É necessário treinar a turma. Quando se está em uma equipe de resposta a incidentes interna a uma companhia, é fundamental que haja treinamento adequado para que todos saibam o que deve ser feito, e na ordem exata. Como consultor externo, convém planejar como etapa de preparação e conscientização, alguns trabalhos envolvendo palestras e workshops para os envolvidos
2) Estude bem as ferramentas e documente as alterações esperadas. Em alguns casos, é só o que pode ser feito. Na prática, é semelhante a você encontrar digitais na cena do crime da pessoa que socorreu a vítima ... Desde que se tenha isso documentado, não é problema.
3) Imagino que o bom profissional vai precisar estar preparado para realizar essas coletas e outras metodologias conhecidas como Live Response, pois cresce o número de empresas que dependem de rendimentos vindos de aplicações e sistemas que precisam estar 100% no ar. Algumas empresas só existem na internet ...
4) Não concordo. Análise Forense depende, sem dúvida, de vários artefatos. Fazendo a aquisição da memória e sua posterior análise deverá corroborar com todas as informações obtidas aqui. Além disso, a correlação de informações pode ajudar a encontrar códigos maliciosos mais bem elaborados, como rootkits.
Quais seriam suas considerações sobre essas controvérsias ? Que outras controvérsias você poderia destacar ?
Até o próximo post !
quinta-feira, 19 de junho de 2008
Trabalhando na área
Recebi um feedback bacana do Fellipe Henrique, que veio também com uma pergunta bastante comum. Como fazer para trabalhar na área ? A pergunta está na cabeça de 7 de 10 pessoas que acompanham Forense Computacional no Brasil, e de certa forma, nem todas as opções são fáceis de serem encontradas. Vamos a elas, de forma resumida:
- Perito Forense
Depende de ser indicado por um Juiz para atuar como Perito em um processo, em geral Cível ou de Trabalho. Exige apenas nível superior e experiência/expertise comprovada.
- Perito Criminal
É concursado. O Perito Criminal em Forense Computacional atuará em processos criminais. Em geral, é um policial.
- Assistente Técnico
Trabalha para uma das partes em um processo, assessorando o advogado na parte técnica ligada à Forense Computacional.
- Investigador Digital/Forense Computacional
É um consultor da área de Segurança de Informações, especializado em Forense Computacional, que pode atender empresas ou pessoas físicas investigando situação ligada à Forense Computacional.
- First Responder
É um Analista de Segurança de Informações ou Analista de Suporte, com conhecimentos em Forense Computacional e conceitos de Resposta a Incidentes. Geralmente, é funcionário em uma organização e está ligado ao CSIRT (Computer Security Incident Response Team) da empresa.
O que deve vir por aí ?
Acredito que nossa área vai se consolidar cada vez mais, e irá gerar algumas novas posições:
- Detetives: O trabalho de investigadores e detetives vai passar por Forense Computacional. Até casos de infidelidade conjugal poderão ser tratados no âmbito de Forense Computacional.
- Especializações: Com a consolidação da área e das profissões, sub-divisões surgirão naturalmente. Teremos profissionais ligados apenas à Forense de Celulares, Forense de Devices, Especialistas em Análise de SOs específicos.
Brincar de prever o futuro costuma ser complicado. Quer tentar ? Mande seus comentários ...
Até o próximo post !
- Perito Forense
Depende de ser indicado por um Juiz para atuar como Perito em um processo, em geral Cível ou de Trabalho. Exige apenas nível superior e experiência/expertise comprovada.
- Perito Criminal
É concursado. O Perito Criminal em Forense Computacional atuará em processos criminais. Em geral, é um policial.
- Assistente Técnico
Trabalha para uma das partes em um processo, assessorando o advogado na parte técnica ligada à Forense Computacional.
- Investigador Digital/Forense Computacional
É um consultor da área de Segurança de Informações, especializado em Forense Computacional, que pode atender empresas ou pessoas físicas investigando situação ligada à Forense Computacional.
- First Responder
É um Analista de Segurança de Informações ou Analista de Suporte, com conhecimentos em Forense Computacional e conceitos de Resposta a Incidentes. Geralmente, é funcionário em uma organização e está ligado ao CSIRT (Computer Security Incident Response Team) da empresa.
O que deve vir por aí ?
Acredito que nossa área vai se consolidar cada vez mais, e irá gerar algumas novas posições:
- Detetives: O trabalho de investigadores e detetives vai passar por Forense Computacional. Até casos de infidelidade conjugal poderão ser tratados no âmbito de Forense Computacional.
- Especializações: Com a consolidação da área e das profissões, sub-divisões surgirão naturalmente. Teremos profissionais ligados apenas à Forense de Celulares, Forense de Devices, Especialistas em Análise de SOs específicos.
Brincar de prever o futuro costuma ser complicado. Quer tentar ? Mande seus comentários ...
Até o próximo post !
sábado, 7 de junho de 2008
Helix x ReiserFS
Está acontecendo um debate muito interessante em uma lista de discussão internacional sobre Forense Computacional.
A controvérsia é se o Helix altera ou não o journal do ReiserFS. Um dos participantes levantou a questão, trazida por um de seus alunos, e o criador e mantenedor do Helix, Drew Fahey, inicialmente negou de forma veemente que o Helix fizesse qualquer atualização ou alteração indevida em qualquer sistema de arquivos, mesmo os que mantêm estruturas de journaling.
Depois de uma briga boa, Drew finalizou os testes e acabou de postar os resultados. A versão 1.9a do Helix realmente permite a alteração do journaling, mesmo que montado como read-only. Ele identificou a raiz do problema e se comprometeu a incluir a correção na próxima release, que segundo ele estará liberada em 60 dias. Tendo dito isso, gostaria de deixar dois dedim de prosa:
1) Tomem cuidado quando estiverem manipulando imagens forenses. Digo isso porque esse problema não acontece quando se está fazendo a aquisição da imagem, pois ela não é montada nessa hora. O problema acontece quando o perito monta a imagem para iniciar sua análise. Não importa indicar o parâmetro de read-only, pois com esse problema, o hash da imagem nunca mais vai conferir com o hash da mídia original, o que pode comprometer todo o laudo pericial.
Solução de contorno 1: sempre faça suas análises em uma cópia da imagem, incluindo nos seus procedimentos um hash/conferência antes e outro no final da análise. Caso eles não sejam o mesmo, e a causa seja essa discutida aqui, envolvendo journaling, simplesmente descarte o arquivo no final. Logicamente, documente o que aconteceu no laudo ou relatório.
2) Esse assunto me despertou para uma reflexão. Estamos ainda fazendo verificação da integridade usando hashs sobre a imagem inteira, mas esse método ficará inválido em pouco tempo. Estamos cada vez mais caminhando para novos rumos em termos de Forense Computacional. Entre eles, a Forense de Memória e o Live Forensics, onde a análise é feita em uma máquina em operação. Ambos os métodos são aplicáveis e úteis, quando a situação os requer. No entanto, em ambos não temos como comprovar a integridade usando os métodos atuais.
Gostaria de receber comentários a respeito disso, e de quais rumos a verificação de integridade vai acabar tomando. Vamos debater !
Até o próximo post !
A controvérsia é se o Helix altera ou não o journal do ReiserFS. Um dos participantes levantou a questão, trazida por um de seus alunos, e o criador e mantenedor do Helix, Drew Fahey, inicialmente negou de forma veemente que o Helix fizesse qualquer atualização ou alteração indevida em qualquer sistema de arquivos, mesmo os que mantêm estruturas de journaling.
Depois de uma briga boa, Drew finalizou os testes e acabou de postar os resultados. A versão 1.9a do Helix realmente permite a alteração do journaling, mesmo que montado como read-only. Ele identificou a raiz do problema e se comprometeu a incluir a correção na próxima release, que segundo ele estará liberada em 60 dias. Tendo dito isso, gostaria de deixar dois dedim de prosa:
1) Tomem cuidado quando estiverem manipulando imagens forenses. Digo isso porque esse problema não acontece quando se está fazendo a aquisição da imagem, pois ela não é montada nessa hora. O problema acontece quando o perito monta a imagem para iniciar sua análise. Não importa indicar o parâmetro de read-only, pois com esse problema, o hash da imagem nunca mais vai conferir com o hash da mídia original, o que pode comprometer todo o laudo pericial.
Solução de contorno 1: sempre faça suas análises em uma cópia da imagem, incluindo nos seus procedimentos um hash/conferência antes e outro no final da análise. Caso eles não sejam o mesmo, e a causa seja essa discutida aqui, envolvendo journaling, simplesmente descarte o arquivo no final. Logicamente, documente o que aconteceu no laudo ou relatório.
2) Esse assunto me despertou para uma reflexão. Estamos ainda fazendo verificação da integridade usando hashs sobre a imagem inteira, mas esse método ficará inválido em pouco tempo. Estamos cada vez mais caminhando para novos rumos em termos de Forense Computacional. Entre eles, a Forense de Memória e o Live Forensics, onde a análise é feita em uma máquina em operação. Ambos os métodos são aplicáveis e úteis, quando a situação os requer. No entanto, em ambos não temos como comprovar a integridade usando os métodos atuais.
Gostaria de receber comentários a respeito disso, e de quais rumos a verificação de integridade vai acabar tomando. Vamos debater !
Até o próximo post !
segunda-feira, 2 de junho de 2008
Autopsy ganha irmãozinho
Tem novidade na área
O Autopsy, conhecido browser para o TSK (SleuthKit), está ganhando um irmão. A turma da DFLabs, empresa italiana focada em Segurança de Informações, fez agora no finalzinho de maio o release da versão beta do PTK, indicando que o produto tem as mesmas funcionalidades do Autopsy, mas foi redesenhado, feito do zero (e não com pedaços de código do Autopsy) e prometem algumas funcionalidades inexistentes no Autopsy.
Algumas novidades que esse produto vai trazer:
- Suporte a imagens repartidas (split)
- Indexação de keywords ascii presentes na imagem
- Localiza e exibe imagens em uma imagem, mesmo que estejam obfuscadas.
- Módulo de análise de dumps de memória
Para baixar a versão beta, visite o site do PTK no SourceForge ou na DFLabs.
Há uma apresentação muito boa (em inglês) aqui.
Para fazer parte da equipe de desenvolvimento do produto, mande um e-mail para ptk@dflabs.com
Alguém já está testando, e gostaria de comentar ?
Até o próximo post !
O Autopsy, conhecido browser para o TSK (SleuthKit), está ganhando um irmão. A turma da DFLabs, empresa italiana focada em Segurança de Informações, fez agora no finalzinho de maio o release da versão beta do PTK, indicando que o produto tem as mesmas funcionalidades do Autopsy, mas foi redesenhado, feito do zero (e não com pedaços de código do Autopsy) e prometem algumas funcionalidades inexistentes no Autopsy.
Algumas novidades que esse produto vai trazer:
- Suporte a imagens repartidas (split)
- Indexação de keywords ascii presentes na imagem
- Localiza e exibe imagens em uma imagem, mesmo que estejam obfuscadas.
- Módulo de análise de dumps de memória
Para baixar a versão beta, visite o site do PTK no SourceForge ou na DFLabs.
Há uma apresentação muito boa (em inglês) aqui.
Para fazer parte da equipe de desenvolvimento do produto, mande um e-mail para ptk@dflabs.com
Alguém já está testando, e gostaria de comentar ?
Até o próximo post !
domingo, 1 de junho de 2008
Imagens Forenses VI
Segue mais um capítulo da nossa emocionante novela a respeito das imagens forenses. Neste emocionante episódio, nosso protagonista, o formato .AFF (Advanced Forensic Format) vai ser testado em relação ao tamanho final de arquivo gerado e ao tempo total de geração da imagem.
Como já comentei em artigos anteriores, o formato aff permite compressão dos dados, e é possível indicar, durante a aquisição pelo aimage, o nível de compressão (através do parâmetro compression) e o algoritmo de compressão (ZLIB ou LZMA).
A idéia desse estudo é achar combinações ideais para esses dois parâmetros, através da aquisição de uma imagem forense do mesmo pen drive de 876 Mb (837 Mb reais), variando apenas esses dois parâmetros. Vamos aos resultados:
Usando ZLIB (default)
Usando LZMA
Conclusões
- Se tamanho não é problema, o jeito mais rápido de capturar uma imagem usando o aimage (ou o Adepto do Helix) é pedindo a opção de não-compactação.
- Se o tempo não é problema, o menor arquivo de imagem gerado é obtido usando-se o aimage com a opção -L (algoritmo LZMA). Como as opções de compress geram arquivos praticamente de mesmo tamanho, a melhor opção para usar com o -L seria o --compression=1 (ou =5).
- Se o principal é ter compactação, mas levando o tempo em consideração, então os algoritmos LZMA são proibitivos. O mais rápido nesse algoritmo foi quase 6 vezes mais demorado que o mais lento das opções do ZLIB.
- Indo nessa linha, de ter boa compactação, mas com tempos razoáveis, a melhor opção seria o algoritmo ZLIB (default) com a opção compression=5. Essa opção oferece a melhor taxa de compactação, e dentro dessa taxa, o melhor tempo, tudo isso levando-se em consideração os valores absolutos.
- Os que apresentaram maior/melhor taxa de transferência foram as opções compression=1 ou =2, com o algoritmo ZLIB (default). Esses são os que apresentaram a melhor relação custo x benefício, e são as indicadas para situações genéricas onde compactação é desejada e o tempo de aquisição deve ser optimizado.
- O algoritmo LZMA não pode ser setado pelo Adepto.
Comentários ?
Até o próximo post !
Como já comentei em artigos anteriores, o formato aff permite compressão dos dados, e é possível indicar, durante a aquisição pelo aimage, o nível de compressão (através do parâmetro compression) e o algoritmo de compressão (ZLIB ou LZMA).
A idéia desse estudo é achar combinações ideais para esses dois parâmetros, através da aquisição de uma imagem forense do mesmo pen drive de 876 Mb (837 Mb reais), variando apenas esses dois parâmetros. Vamos aos resultados:
| Compression | Tamanho da imagem | Tempo de aquisição |
| Sem compressão | 837 Mb | 1m36s |
Usando ZLIB (default)
| Compression | Tamanho da imagem | Tempo de aquisição |
| -1 (default) | 762 Mb = 8,96% menor | 3m24s = 112,5% mais demorado |
| 0 | 837 Mb = idêntico | 1m51s = 15,63% mais demorado |
| 1 | 764 Mb = 8,72% menor | 3m11s = 98,96% mais demorado |
| 2 | 764 Mb = 8,72% menor | 3m11s = 98,96% mais demorado |
| 3 | 763 Mb = 8,84% menor | 3m12s = 100% mais demorado |
| 4 | 763 Mb = 8,84% menor | 3m20s = 108,33% mais demorado |
| 5 | 762 Mb = 8,96% menor | 3m22s = 110,42% mais demorado |
| 6 | 762 Mb = 8,96% menor | 3m24s = 112,5% mais demorado |
| 7 | 762 Mb = 8,96% menor | 3m24s = 112,5% mais demorado |
| 8 | 762 Mb = 8,96% menor | 3m34s = 122,92% mais demorado |
| 9 | 762 Mb = 8,96% menor | 3m48s = 137,5% mais demorado |
Usando LZMA
| Compression | Tamanho da imagem | Tempo de aquisição |
| -1 (default) | 721 Mb = 13,86% menor | 14m13s = 788,54% mais demorado |
| 0 | 721 Mb = 13,86% menor | 13m55s = 769,79% mais demorado |
| 1 | 721 Mb = 13,86% menor | 13m53s = 767,71% mais demorado |
| 4 | 721 Mb = 13,86% menor | 14m = 775% mais demorado |
| 5 | 721 Mb = 13,86% menor | 13m53s = 767,71% mais demorado |
Conclusões
- Se tamanho não é problema, o jeito mais rápido de capturar uma imagem usando o aimage (ou o Adepto do Helix) é pedindo a opção de não-compactação.
- Se o tempo não é problema, o menor arquivo de imagem gerado é obtido usando-se o aimage com a opção -L (algoritmo LZMA). Como as opções de compress geram arquivos praticamente de mesmo tamanho, a melhor opção para usar com o -L seria o --compression=1 (ou =5).
- Se o principal é ter compactação, mas levando o tempo em consideração, então os algoritmos LZMA são proibitivos. O mais rápido nesse algoritmo foi quase 6 vezes mais demorado que o mais lento das opções do ZLIB.
- Indo nessa linha, de ter boa compactação, mas com tempos razoáveis, a melhor opção seria o algoritmo ZLIB (default) com a opção compression=5. Essa opção oferece a melhor taxa de compactação, e dentro dessa taxa, o melhor tempo, tudo isso levando-se em consideração os valores absolutos.
- Os que apresentaram maior/melhor taxa de transferência foram as opções compression=1 ou =2, com o algoritmo ZLIB (default). Esses são os que apresentaram a melhor relação custo x benefício, e são as indicadas para situações genéricas onde compactação é desejada e o tempo de aquisição deve ser optimizado.
- O algoritmo LZMA não pode ser setado pelo Adepto.
Comentários ?
Até o próximo post !
Assinar:
Postagens (Atom)