Navegando por alguns sites, acabei achando uma certificação sobre Forense Computacional bastante interessante. É de graça, ainda por cima.
As questões são bem montadas, o assunto é coberto adequadamente, e o processo não chega a ser demorado. São 40 questões que cobrem diversos aspectos de Forense Computacional e ainda entra nos detalhes da lei americana.
Quer tentar ? Lá vai: http://www.brainbench.com/xml/bb/common/testcenter/taketest.xml?testId=2516
Clique no GET TEST, faça o cadastro e siga para as questões. Pode ser um bom termômetro de como você está indo em relação aos conhecimentos.
Boa prova, e até o próximo post !
segunda-feira, 31 de dezembro de 2007
domingo, 30 de dezembro de 2007
Sem fio ...
Desde que conseguiram descobrir formas de burlar a lei e cometer crimes usando o computador, cada vez fica mais comum a situação onde investigadores e policiais são envolvidos em operações com mandados de busca e apreensão. Um dos objetivos é apreender os equipamentos que podem estar sendo usados nas atividades ilegais, e dessa forma obter mais informações e evidências para o processo.
Para fechar o ano contribuindo com os amigos invetigadores das forças policiais, vou tratar nesse post de alguns detalhes a observar quando da realização da busca. Parte desse artigo é baseado no artigo Examining Wireless Access Points and Associated Devices, do Sgt Christopher Then.
O objetivo da busca é apreender o máximo, senão todos os equipamentos que podem conter informações sobre o que está sendo investigado. Em épocas de computação móvel barata e redes sem fio, podemos alguns problemas nessa operação:
1) Será que estamos realmente apreendendo todos os equipamentos usados ?
2) E se for um carona ?
3) E se o suspeito estiver pegando carona ?
Vamos tratar de cada um deles separadamente.
Varredura nos equipamentos - Será que estamos realmente apreendendo todos os equipamentos usados ?
Nosso problema é garantir que estamos apreendendo todos os equipamentos. No caso de uma rede local, os pontos de rede e algumas configurações do servidor já darão mostra de quais equipamentos estão sendo usados. Porém, o perfil mais encontrado nesta situação ainda é o de um ambiente pequeno, e normalmente fazendo uso de um roteador com wireless e algumas portas para LAN. Abaixo, enumero alguns pontos importantes para considerar. Monte um check-list com as tarefas, para facilitar no momento da operação:
a) Localize e fotografe o que seria a topologia dos equipamentos.
Em geral, nesses casos temos um modem (cable modem ou ADSL), conectado ao roteador com interfaces para wireless e algumas portas LAN.
b) Determine a quantidade dos equipamentos.
Verifique se o modem é o único existente, se o roteador WiFi é o único existente, se todos os cabos ligados nele levam às estações.
c) De posse de uma estação forense com interface wireless (ou um notebook de investigação), faça uma verificação do roteador WiFi.
Essa etapa pode ser feita de algumas formas, e seria interessante que fosse feita de mais de uma forma, para termos resultados que se confirmam. Outro ponto importantíssimo: Todas as operações devem fazer parte de um procedimento, que deve ser seguido a risca. Os resultados obtidos precisam necessariamente poder ser reproduzidos por terceiros, seguindo os procedimentos, caso contrário o resultado poderá ser contestado quanto a sua integridade, já que não é reprodutível.
Forma i - Através da interface de rede
a) Reinicialize o notebook forense com o BackTrack. Esse é o melhor Live CD para testes de invasão existente, e um acessório fundamental para o Investigador Digital.
b) Conecte o cabo de rede no notebook e no roteador.
c) Verifique se o mesmo irá receber um IP, via DHCP. Se não receber, consiga as configurações de IP em uma máquina já conectada.
d) O IP do roteador WiFi deverá ser o indicado para default gateway da rede. Outra possibilidade é usar a suposição de que o IP do roteador está na mesma sub-rede que o IP recebido, mas com o último octeto igual a 1. Por exemplo, se o seu notebook forense recebeu o IP 192.168.1.103, então provavelmente o IP do roteador será 192.168.1.1
e) Abra um browser e informe o IP do roteador. Vamos acessar a console de gerenciamento dele. Esse acesso será bastante valioso, já que no roteador poderemos verificar diretamente várias informações importantes, como o seu MAC address, o MAC address de todas as máquinas conectadas a ele, seja atualmente, seja no passado, consultando os seus logs.
f) Ao ser acessado, precisaremos informar ao roteador o usuário e a senha. A melhor opção aqui é tentar usar a identificação padrão. Não é incomum que os usuários mantenham a autenticação com os valores de fábrica. Verifique no corpo do próprio roteador sua marca e modelo, e acesse http://www.governmentsecurity.org/articles/DefaultsLoginsandPasswordsforNetworkedDevices.php
g) Tendo sucesso na autenticação, prepare-se para armazenar o máximo de informações disponíveis. O principal aqui é determinar quantos equipamentos estão ou já estiveram conectados, para que sejam averiguados.
h) Na impossibilidade de autenticar-se no roteador, podemos realizar uma varredura na rede para tentar detectar os equipamentos conectados usando o nmap, disponível no BackTrack:
nmap -sP -v
Ex: nmap -sP -v 192.168.1.0/24 para verificar a subrede de 192.168.1.1 a 192.168.1.254
Esse método tem um problema: firewalls podem bloquear a resposta do nmap ...
Forma ii - Através da interface Wireless
a) Reinicialize o notebook forense com o BackTrack.
b) Confira se o sinal de WiFi está ligado.
c) Vamos observar o tráfego entre todas as máquinas associadas ao roteador-Access Point (AP). Para isso, usaremos o pacote AirCrack-ng, que está no BackTrack.
d) Execute o programa airmon-ng. Ele vai informar qual o nome da interface WiFi do seu notebook.
e) Execute o programa airodump-ng, passando o nome da interface obtido no passo anterior. Ex: airodump eth0
Dessa forma, o programa estará verificando todas as comunicações que estão ao alcance do seu notebook forense.
f) Veja a tela do airodump abaixo:
BSSID - é o MAC Address do roteador-AP. Você poderá pegar mais de um sinal disponível na área.
ESSID - é o SSID da conexão wireless. Dependendo da forma de criptografia utilizada (campo ENC), essa informação pode não estar acessível. O roteador também pode estar configurado para omitir o SSID no broadcast.
STATION - É o MAC Address de cada estação wireless conectada/associada ao roteador-AP indicado na coluna BSSID. No exemplo da figura, há apenas um AP identificado e apenas uma máquina conectada ao mesmo. Em geral, a lista acima fica bem maior.
Para fechar o ano contribuindo com os amigos invetigadores das forças policiais, vou tratar nesse post de alguns detalhes a observar quando da realização da busca. Parte desse artigo é baseado no artigo Examining Wireless Access Points and Associated Devices, do Sgt Christopher Then.
O objetivo da busca é apreender o máximo, senão todos os equipamentos que podem conter informações sobre o que está sendo investigado. Em épocas de computação móvel barata e redes sem fio, podemos alguns problemas nessa operação:
1) Será que estamos realmente apreendendo todos os equipamentos usados ?
2) E se for um carona ?
3) E se o suspeito estiver pegando carona ?
Vamos tratar de cada um deles separadamente.
Varredura nos equipamentos - Será que estamos realmente apreendendo todos os equipamentos usados ?
Nosso problema é garantir que estamos apreendendo todos os equipamentos. No caso de uma rede local, os pontos de rede e algumas configurações do servidor já darão mostra de quais equipamentos estão sendo usados. Porém, o perfil mais encontrado nesta situação ainda é o de um ambiente pequeno, e normalmente fazendo uso de um roteador com wireless e algumas portas para LAN. Abaixo, enumero alguns pontos importantes para considerar. Monte um check-list com as tarefas, para facilitar no momento da operação:
a) Localize e fotografe o que seria a topologia dos equipamentos.
Em geral, nesses casos temos um modem (cable modem ou ADSL), conectado ao roteador com interfaces para wireless e algumas portas LAN.
b) Determine a quantidade dos equipamentos.
Verifique se o modem é o único existente, se o roteador WiFi é o único existente, se todos os cabos ligados nele levam às estações.
c) De posse de uma estação forense com interface wireless (ou um notebook de investigação), faça uma verificação do roteador WiFi.
Essa etapa pode ser feita de algumas formas, e seria interessante que fosse feita de mais de uma forma, para termos resultados que se confirmam. Outro ponto importantíssimo: Todas as operações devem fazer parte de um procedimento, que deve ser seguido a risca. Os resultados obtidos precisam necessariamente poder ser reproduzidos por terceiros, seguindo os procedimentos, caso contrário o resultado poderá ser contestado quanto a sua integridade, já que não é reprodutível.
Forma i - Através da interface de rede
a) Reinicialize o notebook forense com o BackTrack. Esse é o melhor Live CD para testes de invasão existente, e um acessório fundamental para o Investigador Digital.
b) Conecte o cabo de rede no notebook e no roteador.
c) Verifique se o mesmo irá receber um IP, via DHCP. Se não receber, consiga as configurações de IP em uma máquina já conectada.
d) O IP do roteador WiFi deverá ser o indicado para default gateway da rede. Outra possibilidade é usar a suposição de que o IP do roteador está na mesma sub-rede que o IP recebido, mas com o último octeto igual a 1. Por exemplo, se o seu notebook forense recebeu o IP 192.168.1.103, então provavelmente o IP do roteador será 192.168.1.1
e) Abra um browser e informe o IP do roteador. Vamos acessar a console de gerenciamento dele. Esse acesso será bastante valioso, já que no roteador poderemos verificar diretamente várias informações importantes, como o seu MAC address, o MAC address de todas as máquinas conectadas a ele, seja atualmente, seja no passado, consultando os seus logs.
f) Ao ser acessado, precisaremos informar ao roteador o usuário e a senha. A melhor opção aqui é tentar usar a identificação padrão. Não é incomum que os usuários mantenham a autenticação com os valores de fábrica. Verifique no corpo do próprio roteador sua marca e modelo, e acesse http://www.governmentsecurity.org/articles/DefaultsLoginsandPasswordsforNetworkedDevices.php
g) Tendo sucesso na autenticação, prepare-se para armazenar o máximo de informações disponíveis. O principal aqui é determinar quantos equipamentos estão ou já estiveram conectados, para que sejam averiguados.
h) Na impossibilidade de autenticar-se no roteador, podemos realizar uma varredura na rede para tentar detectar os equipamentos conectados usando o nmap, disponível no BackTrack:
nmap -sP -v
Ex: nmap -sP -v 192.168.1.0/24 para verificar a subrede de 192.168.1.1 a 192.168.1.254
Esse método tem um problema: firewalls podem bloquear a resposta do nmap ...
Forma ii - Através da interface Wireless
a) Reinicialize o notebook forense com o BackTrack.
b) Confira se o sinal de WiFi está ligado.
c) Vamos observar o tráfego entre todas as máquinas associadas ao roteador-Access Point (AP). Para isso, usaremos o pacote AirCrack-ng, que está no BackTrack.
d) Execute o programa airmon-ng. Ele vai informar qual o nome da interface WiFi do seu notebook.
e) Execute o programa airodump-ng, passando o nome da interface obtido no passo anterior. Ex: airodump eth0
Dessa forma, o programa estará verificando todas as comunicações que estão ao alcance do seu notebook forense.
f) Veja a tela do airodump abaixo:
BSSID - é o MAC Address do roteador-AP. Você poderá pegar mais de um sinal disponível na área.
ESSID - é o SSID da conexão wireless. Dependendo da forma de criptografia utilizada (campo ENC), essa informação pode não estar acessível. O roteador também pode estar configurado para omitir o SSID no broadcast.
STATION - É o MAC Address de cada estação wireless conectada/associada ao roteador-AP indicado na coluna BSSID. No exemplo da figura, há apenas um AP identificado e apenas uma máquina conectada ao mesmo. Em geral, a lista acima fica bem maior.
Na busca, todas as STATIONs identificadas precisarão estar apreendidas.
E se for um carona ?
Uma das possibilidades que devemos levar em conta em algumas situações é a de que o maior suspeito não é realmente quem está cometendo o delito. Se, no endereço do suspeito, for encontrado um roteador WiFi aberto, é bem possível que essa informação mude completamente os rumos da situação. Para evitar expor a investigação, recomendo uma pré-operação em sigilo, usando o airodump nas redondezas para captar o sinal WiFi e determinar se ele é aberto (sem criptografia) ou não.
É possível, inclusive, ter a localização do roteador-AP através de uma placa de GPS adaptada ao notebook. Ele registra as coordenadas do AP com a possibilidade de repassá-las a programas que indicam em mapas a sua localização exata.
E se o suspeito estiver pegando carona ?
Em tempos onde muitos usam roteadores WiFi simplesmente tirando-o da caixa e usando-o com todas as configurações padrão, algo que devemos nos preocupar é que o verdadeiro autor do delito tenha condições de esconder as evidências do que está fazendo. Uma possibilidade é que o mesmo se associe a redes WiFi abertas na redondeza, e use as máquinas desprotegidas como passagem para disfarçar sua identidade ou até mesmo guardar informações comprometedoras lá. Um exemplo seria alguém que pratica a pedofilia associar-se a uma rede que está aberta na vizinhança, e sem conhecimento do dono, armazenar fotos ou figuras comprometedoras na máquina da pessoa. Existem diversas técnicas de obfuscação que podem ser usadas e com isso o material dificilmente seria notado.
Por conta disso, redes abertas com sinal acessível no ponto onde a busca está sendo realizada devem também ser averiguadas, para eliminar a possibilidade descrita acima.
Outros pontos importantes:
- Muitos equipamentos hoje podem disparar ataques e outras formas de fraude, e alguns deles possuem interface wireless. Por conta disso, não esqueça de verificar os PDAs (Palm, iPaq, SmartPhones, etc).
- Redes protegidas por criptografia com esquemas WEP ou WPA podem ter a sua chave quebrada, e a associação efetivada. Programas como o Airodump/Airocrack oferecem essas funcionalidades.
Alguém gostaria de compartilhar alguma história envolvendo buscas em rede sem fio ?
Até o próximo post !
quinta-feira, 27 de dezembro de 2007
Contra-argumentação
Enquanto espero pacientemente minha filha enjoar da Barbie e liberar meu notebook, para que eu possa fazer os testes finais do próximo post sobre wireless, vou adiantar algo sobre um artigo não tão novo, mas interessante.
O artigo, escrito por Jesse Kornblum para o International Journal of Digital Evidence de 2004, comenta e testa um problema do Linux, kernel 2.4.xxx, em ler o último setor de um HD, quando o mesmo é ímpar.
O artigo faz um estudo detalhado, compara resultados em vários HDs diferentes e conclui que o problema é realmente do Kernel e não das ferramentas do Linux. Tal problema foi resolvido no Kernel 2.6.xxx.
Como tenho acompanhado várias listas por aí sobre Forense Computacional e visto uma onda de criação de novos live-cds para forense, vale a pena reforçar através desse micro-post o seguinte:
1) Verifique, antes da aquisição da imagem do HD, qual a versão do Kernel do seu Linux. Se for inferior a 2.6, é roubada.
2) Preste bastante atenção quando você for avaliar o trabalho de um Assistente Técnico. Se a aquisição da imagem usou um Linux baseado no Kernel 2.4.xxx e o número de setores do HD é ímpar, é muito provável que o último setor do disco não tenha sido transferido para a imagem, e isso sem nenhuma msg de erro ...
Nas duas situações, é bom ficar bastante atento. Um detalhe desses e você pode invalidar a imagem como evidência.
Até o próximo post !
O artigo, escrito por Jesse Kornblum para o International Journal of Digital Evidence de 2004, comenta e testa um problema do Linux, kernel 2.4.xxx, em ler o último setor de um HD, quando o mesmo é ímpar.
O artigo faz um estudo detalhado, compara resultados em vários HDs diferentes e conclui que o problema é realmente do Kernel e não das ferramentas do Linux. Tal problema foi resolvido no Kernel 2.6.xxx.
Como tenho acompanhado várias listas por aí sobre Forense Computacional e visto uma onda de criação de novos live-cds para forense, vale a pena reforçar através desse micro-post o seguinte:
1) Verifique, antes da aquisição da imagem do HD, qual a versão do Kernel do seu Linux. Se for inferior a 2.6, é roubada.
2) Preste bastante atenção quando você for avaliar o trabalho de um Assistente Técnico. Se a aquisição da imagem usou um Linux baseado no Kernel 2.4.xxx e o número de setores do HD é ímpar, é muito provável que o último setor do disco não tenha sido transferido para a imagem, e isso sem nenhuma msg de erro ...
Nas duas situações, é bom ficar bastante atento. Um detalhe desses e você pode invalidar a imagem como evidência.
Até o próximo post !
terça-feira, 25 de dezembro de 2007
Ho Ho Ho
Se você foi um bom menino esse ano, não aguenta mais aquele amigo-oculto de Natal (sempre aquele presentinho básico... ), está pensando em alguma coisa nova mas nem que a vaca tussa você irá ao shopping, então esse artigo foi feito pensando em você !
5 lugares bem bacanas para mandar o Papai Noel providenciar o seu presente !
http://www.logicube.com/
A Logicube é uma das líderes em hardware de duplicação forense. Pense quanto tempo você vai economicar fazendo a duplicação daquele HD de 500Gb !
http://www.voomtech.com/
A Voom Technologies oferece, além de duplicadores de HD, um drive wiper excelente ! Um deles oferece a taxa de 8 Gb por minuto.
http://www.crimescene.com/
Mande o Bom Velhinho passar por esse site e reabastecer o seu estoque de sacos de evidências, um item fundamental para selar e guardar o HD, depois de duplicado. Ah, já vem com espaço para a cadeia de custódia !!!
http://www.forensicpc.com
A Forensic PC é uma espécie de loja virtual multimarcas. Lá você achará várias opções interessantes, desde as mais modernas estações forenses até produtos Tableau e ICS.
http://www.digitalintelligence.com/
Aqui temos sistemas forenses completos. São estações especializadas em captura e análise forense, com máquinas totalmente dedicadas e otimizadas para essas tarefas. Acho que aqui Noel vai ter que vender o trenó e as renas para levar seu presente. Aprecie com moderação ...
Boas compras e até o próximo post !
Em tempo: Costumamos dizer que nosso trabalho é trazer a verdade à luz. Que nosso Senhor possa fazer exatamente isso, trazer luz para você e todos os seus ! Brasil, olha prá cima !!
Paz !
5 lugares bem bacanas para mandar o Papai Noel providenciar o seu presente !
http://www.logicube.com/
A Logicube é uma das líderes em hardware de duplicação forense. Pense quanto tempo você vai economicar fazendo a duplicação daquele HD de 500Gb !
http://www.voomtech.com/
A Voom Technologies oferece, além de duplicadores de HD, um drive wiper excelente ! Um deles oferece a taxa de 8 Gb por minuto.
http://www.crimescene.com/
Mande o Bom Velhinho passar por esse site e reabastecer o seu estoque de sacos de evidências, um item fundamental para selar e guardar o HD, depois de duplicado. Ah, já vem com espaço para a cadeia de custódia !!!
http://www.forensicpc.com
A Forensic PC é uma espécie de loja virtual multimarcas. Lá você achará várias opções interessantes, desde as mais modernas estações forenses até produtos Tableau e ICS.
http://www.digitalintelligence.com/
Aqui temos sistemas forenses completos. São estações especializadas em captura e análise forense, com máquinas totalmente dedicadas e otimizadas para essas tarefas. Acho que aqui Noel vai ter que vender o trenó e as renas para levar seu presente. Aprecie com moderação ...
Boas compras e até o próximo post !
Em tempo: Costumamos dizer que nosso trabalho é trazer a verdade à luz. Que nosso Senhor possa fazer exatamente isso, trazer luz para você e todos os seus ! Brasil, olha prá cima !!
Paz !
quinta-feira, 20 de dezembro de 2007
Processo do Clã MacLeod
Estava lendo um artigo do Andreas Schuster, um dos Papas no assunto de Forense da Memória de sistemas Windows.
O artigo apresenta vários conceitos básicos não apenas a respeito da importância de se fazer forense da memória, mas também indicando que em alguns casos a memória será a única a conter o artefato que pode trazer luz ao caso sendo investigado.
Lá pelas tantas do artigo, Schuster abre um tópico sobre a persistência dos dados na memória principal. Ele mostra estudos e estatísticas de máquinas que ficaram com informações disponíveis até 14 dias após o processo ter terminado !
Sendo mais claro: Em muita situações, você poderá executar comandos e utilitários que farão um instantâneo da máquina. Esses comandos, muito comentados em operações de Resposta a Incidentes, falam da situação atual da máquina. Em geral, eles não estão preparados para dar informações sobre um processo que já foi finalizado, por exemplo. Imagine que o tal era exatamente o elo que você buscava e, descobrindo-o, todas as dúvidas a respeito do caso seriam resolvidas. Mas o problema continua, porque você só tem na mão a foto do sistema, que foi tirada no momento em que o processo vilão já tinha saído de cena.
O que o Schuster apurou é que, devido a forma como as memórias Windows são gerenciadas, ele conseguiu obter informações de processos depois de muito tempo que foram terminados. Na situação-exemplo acima, uma análise forense da imagem da memória iria revelar o processo vilão.
Não pense que o ilustre pesquisador ficou satisfeito. Ele sacou algo inicialmente dito pela dupla de também gurus da Forense Computacional Farmer e Venema, que nem todos os computadores zeram a memória principal quando estão reiniciando. Isso depende mais da codificação da BIOS do que do sistema operacional, mas não há especificação que obrigue a isso, embora a maioria o faça. Consequências ??? Simplesmente, em suas pesquisas, ele descobriu processos com datas anteriores ao reboot da máquina ! No artigo ele mostra um deles, que resistiu bravamente a três reinicializações.
Estamos frente a um processo Highlander !!! 8-))
Brincadeiras a parte, as informações sobre o processo ultrapassaram as reinicializações, o que aumenta o valor da investigação em imagens da memória, não ?
Gostaria de ver comentários a respeito disso. Você já pesquisou algo parecido ? Já encontrou resultados que apontassem isso em investigações ?
Até o próximo post !
O artigo apresenta vários conceitos básicos não apenas a respeito da importância de se fazer forense da memória, mas também indicando que em alguns casos a memória será a única a conter o artefato que pode trazer luz ao caso sendo investigado.
Lá pelas tantas do artigo, Schuster abre um tópico sobre a persistência dos dados na memória principal. Ele mostra estudos e estatísticas de máquinas que ficaram com informações disponíveis até 14 dias após o processo ter terminado !
Sendo mais claro: Em muita situações, você poderá executar comandos e utilitários que farão um instantâneo da máquina. Esses comandos, muito comentados em operações de Resposta a Incidentes, falam da situação atual da máquina. Em geral, eles não estão preparados para dar informações sobre um processo que já foi finalizado, por exemplo. Imagine que o tal era exatamente o elo que você buscava e, descobrindo-o, todas as dúvidas a respeito do caso seriam resolvidas. Mas o problema continua, porque você só tem na mão a foto do sistema, que foi tirada no momento em que o processo vilão já tinha saído de cena.
O que o Schuster apurou é que, devido a forma como as memórias Windows são gerenciadas, ele conseguiu obter informações de processos depois de muito tempo que foram terminados. Na situação-exemplo acima, uma análise forense da imagem da memória iria revelar o processo vilão.
Não pense que o ilustre pesquisador ficou satisfeito. Ele sacou algo inicialmente dito pela dupla de também gurus da Forense Computacional Farmer e Venema, que nem todos os computadores zeram a memória principal quando estão reiniciando. Isso depende mais da codificação da BIOS do que do sistema operacional, mas não há especificação que obrigue a isso, embora a maioria o faça. Consequências ??? Simplesmente, em suas pesquisas, ele descobriu processos com datas anteriores ao reboot da máquina ! No artigo ele mostra um deles, que resistiu bravamente a três reinicializações.
Estamos frente a um processo Highlander !!! 8-))
Brincadeiras a parte, as informações sobre o processo ultrapassaram as reinicializações, o que aumenta o valor da investigação em imagens da memória, não ?
Gostaria de ver comentários a respeito disso. Você já pesquisou algo parecido ? Já encontrou resultados que apontassem isso em investigações ?
Até o próximo post !
Sparse Files
Li recentemente um artigo interessante, relacionando arquivos esparsos com possíveis problemas para Forense Computacional. Antes de comentar, vou explicar alguns detalhes do artigo.
Arquivos Esparsos
Presente em alguns sistemas de arquivos, tais como o NTFS, arquivos esparsos seriam arquivos muito grandes, mas com pouca informação. Ao marcar um arquivo com essas características como esparso, a parte do arquivo sem informação fica desalocada no sistema de arquivos.
Vamos usar como exemplo um grande arquivo criado com 500 Gb para servir de disco virtual. Logo nos primeiros momentos de uso desse arquivo, vamos supor que acrescentamos informações da ordem de 10Mb. Apesar do arquivo ter apenas essa quantidade de informação real, ele continuará alocando e gastando os 500 Gb. As partes não utilizadas deverão estar cheias de zeros.
No entando, se esse arquivo estiver marcado como esparso, a parte não utilizada será liberada para ser alocada. O espaço consumido real do arquivo será de 10Mb. Na prática, quando o sistema operacional lê um arquivo esparso na parte não utilizada (comumente chamada de "buraco"), ele retorna como se estivesse lendo zeros.
Os arquivos esparsos são comuns para implementação de discos virtuais, bancos de dados, logs e qualquer outro tipo de arquivo que pré-aloca uma grande quantidade de disco, mas não a usa imediatamente.
Problemas com Forense Computacional
O problema apresentado por essa funcionalidade, em relação a Forense Computacional, está ligado diretamente à comprovação de integridade. Explico: imagine dois arquivos de 500Gb, ambos com 10Mb idênticos criados, um deles normal e o outro criado como esparso.
Se extrairmos ambos os arquivos a partir do seu volume, montando-os setor a setor, os hashes que iremos obter a partir disso indicarão que os conteúdos são diferentes. Enquanto que a parte que não contém informação real de um arquivo normal contém zeros, essa mesma parte de um arquivo esparso contem informação que na verdade pode pertencer a outros arquivos.
Porém, se ao invés de extrairmos esses arquivos, nós aplicarmos algoritmos de hash diretamente pelo sistema de arquivos (acessando-os com a imagem montada), os hashes de ambos serão idênticos pelo que já mencionei acima: a parte que não contém informação real de um arquivo esparso é tratada como se estivesse zerada. Conclusão: os arquivos são diferentes, mas o hash de ambos, feito pelo sistema de arquivos, diz que eles são iguais.
Agora sim, as considerações
Após explicado os detalhes do artigo, o autor destaca dois possíveis problemas:
1) Perda de informações sigilosas: Alguém mal intencionado rouba informações sigilosas e cria dois arquivos grandes com elas, um esparso e outro não. Ele copia o arquivo esparso para um pen-drive e logo em seguida troca, na origem, o arquivo esparso pelo normal. Se, por algum motivo, a operação for descoberta, pode ser alegado que o arquivo jamais caberia em mídias transportadas, como um pendrive.
2) Denial-of-Service: Alguém pode criar um grande arquivo normal, e colocá-lo no servidor, consumindo seus recursos de disco e causando a parada do sistema. Logo depois, o atacante substitui o arquivo normal por uma versão esparsa e alega que criou um arquivo esparso.
Nas duas situações, o hash como verificador de integridade vai corroborar com as alegações.
Você consegue imaginar outras situações onde poderíamos ter problemas ?
Um outro ponto que me prendeu a atenção foi que esse é mais um dos problemas de Forense Computacional criados por novas funcionalidades dos sistemas de arquivo. Há muito já vem se falando das Alternate Data Streams, e agora mais essa. Gostaria de saber o que você acha que pode ser feito para ter mais arquitetos e engenheiros de software comprometidos não apenas com as funcionalidades e versatilidades milagrosas, mas também com a Segurança das Informações.
Aguardo comentários. Até o próximo post !
Arquivos Esparsos
Presente em alguns sistemas de arquivos, tais como o NTFS, arquivos esparsos seriam arquivos muito grandes, mas com pouca informação. Ao marcar um arquivo com essas características como esparso, a parte do arquivo sem informação fica desalocada no sistema de arquivos.
Vamos usar como exemplo um grande arquivo criado com 500 Gb para servir de disco virtual. Logo nos primeiros momentos de uso desse arquivo, vamos supor que acrescentamos informações da ordem de 10Mb. Apesar do arquivo ter apenas essa quantidade de informação real, ele continuará alocando e gastando os 500 Gb. As partes não utilizadas deverão estar cheias de zeros.
No entando, se esse arquivo estiver marcado como esparso, a parte não utilizada será liberada para ser alocada. O espaço consumido real do arquivo será de 10Mb. Na prática, quando o sistema operacional lê um arquivo esparso na parte não utilizada (comumente chamada de "buraco"), ele retorna como se estivesse lendo zeros.
Os arquivos esparsos são comuns para implementação de discos virtuais, bancos de dados, logs e qualquer outro tipo de arquivo que pré-aloca uma grande quantidade de disco, mas não a usa imediatamente.
Problemas com Forense Computacional
O problema apresentado por essa funcionalidade, em relação a Forense Computacional, está ligado diretamente à comprovação de integridade. Explico: imagine dois arquivos de 500Gb, ambos com 10Mb idênticos criados, um deles normal e o outro criado como esparso.
Se extrairmos ambos os arquivos a partir do seu volume, montando-os setor a setor, os hashes que iremos obter a partir disso indicarão que os conteúdos são diferentes. Enquanto que a parte que não contém informação real de um arquivo normal contém zeros, essa mesma parte de um arquivo esparso contem informação que na verdade pode pertencer a outros arquivos.
Porém, se ao invés de extrairmos esses arquivos, nós aplicarmos algoritmos de hash diretamente pelo sistema de arquivos (acessando-os com a imagem montada), os hashes de ambos serão idênticos pelo que já mencionei acima: a parte que não contém informação real de um arquivo esparso é tratada como se estivesse zerada. Conclusão: os arquivos são diferentes, mas o hash de ambos, feito pelo sistema de arquivos, diz que eles são iguais.
Agora sim, as considerações
Após explicado os detalhes do artigo, o autor destaca dois possíveis problemas:
1) Perda de informações sigilosas: Alguém mal intencionado rouba informações sigilosas e cria dois arquivos grandes com elas, um esparso e outro não. Ele copia o arquivo esparso para um pen-drive e logo em seguida troca, na origem, o arquivo esparso pelo normal. Se, por algum motivo, a operação for descoberta, pode ser alegado que o arquivo jamais caberia em mídias transportadas, como um pendrive.
2) Denial-of-Service: Alguém pode criar um grande arquivo normal, e colocá-lo no servidor, consumindo seus recursos de disco e causando a parada do sistema. Logo depois, o atacante substitui o arquivo normal por uma versão esparsa e alega que criou um arquivo esparso.
Nas duas situações, o hash como verificador de integridade vai corroborar com as alegações.
Você consegue imaginar outras situações onde poderíamos ter problemas ?
Um outro ponto que me prendeu a atenção foi que esse é mais um dos problemas de Forense Computacional criados por novas funcionalidades dos sistemas de arquivo. Há muito já vem se falando das Alternate Data Streams, e agora mais essa. Gostaria de saber o que você acha que pode ser feito para ter mais arquitetos e engenheiros de software comprometidos não apenas com as funcionalidades e versatilidades milagrosas, mas também com a Segurança das Informações.
Aguardo comentários. Até o próximo post !
terça-feira, 18 de dezembro de 2007
Até injeção na testa ...
Como diz o ditado, "de graça, até injeção na testa !", o software livre vem apresentando considerável contribuição na área de Forense Computacional. Não é somente o conforto na carteira ou na conta bancária. Há aplicações disponíveis livremente com funcionalidades que não encontramos nas mais poderosas aplicações comerciais.
Seguindo essa linha, de manter tudo disponível livremente, preciso realizar a migração dos códigos e procedimentos que postei por ocasião dos artigos sobre hash. Eles são baseados em banco de dados para fornecer soluções de filtragem de arquivos usando hashsets. Os códigos e procedimentos funcionam no SQL Server, mas gostaria de manter a linha de usar software livre sempre que for possível, e portá-los para o MySQL seria uma ótima estratégia.
Problema: Ainda não entendo uma vírgula de MySQL. Alguém poderia ajudar e portar os códigos e procedimentos ? Eu publicarei aqui os novos códigos, com os créditos do autor, logicamente.
Quem se habilita ??
Até o próximo post !
Seguindo essa linha, de manter tudo disponível livremente, preciso realizar a migração dos códigos e procedimentos que postei por ocasião dos artigos sobre hash. Eles são baseados em banco de dados para fornecer soluções de filtragem de arquivos usando hashsets. Os códigos e procedimentos funcionam no SQL Server, mas gostaria de manter a linha de usar software livre sempre que for possível, e portá-los para o MySQL seria uma ótima estratégia.
Problema: Ainda não entendo uma vírgula de MySQL. Alguém poderia ajudar e portar os códigos e procedimentos ? Eu publicarei aqui os novos códigos, com os créditos do autor, logicamente.
Quem se habilita ??
Até o próximo post !
sábado, 15 de dezembro de 2007
Spybot
Bem, estou de volta depois de uma longa série de viagens. Acredito que vou conseguir escrever com mais regularidade a partir de agora.
Por enquanto, estou pegando ainda alguns pequenos assuntos para postar, mas também estou me preparando para alguns artigos mais práticos, na linha do que fiz falando de hash.
Quem nunca ouviu falar do software acima ? O Spybot é um utilitário de busca de malwares sem custo. Quando ele começou, o projeto oferecia exatamente isso, a máquina de busca de malwares. Hoje, na versão 1.5, ele conta com tradução para várias línguas, incluindo o Português do Brasil e tem outros apetrechos muito interessantes.
Neste ponto, você deve estar se perguntando o que isso tem a ver com Forense Computacional. Bom, além de obviamente ser uma boa ferramenta para busca de malware nas imagens, achei uma opção bem interessante nele, que o faz buscar por logs e outros elementos sobre privacidade na máquina. Já percebeu, né ? Esse grande utilitário pode varrer nossos artefatos de maneira rápida e eficiente. Além do mecanismo de busca que permite localizar vários logs diferentes no sistema (fora o tradicional - cookies, temp, etc), ele tem um "triturador", que faz remoções seguras dos arquivos indicados.
Isto posto, acrescente os seguintes pontos importantes nos seus procedimentos de busca:
1) Localizar qualquer instalação do Spybot.
2) Na total inexistência de logs, vale o corolário do HC, que já citei antes: "Ausência de evidências é uma evidência". O usuário pode ter usado as tais funcionalidades do triturador.
3) Os dados que ele registra ficam em Documents and Settings\All Users\Application Data\Spybot - Search & Destroy.
4) Verifique o arquivo Statististics.ini. Localize a chave [Log] e veja a data da última busca na chave LastFound. A chave LastRemoved indica a data da última vez que o usuário apagou os logs.
5) A string Tracks.uti=1 na chave [FileSets] do arquivo Configuration.ini indica que as trilhas de logs, cache, temp, cookies, etc estava selecionada para serem localizadas.
6) No arquivo Overview.ini do diretório Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Recovery você poderá localizar identificações de arquivos e dados que foram sanitizados, com datas e localizações originais. É uma boa informação para cruzar com as citadas anteriormente.
7) No diretorio Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Logs você achará grupos de logs das operações realizadas, com detalhes. Os arquivos tem nome
Interessante seria escrever um script que automatizasse a busca desses itens na imagem e nos arquivos removidos. Alguém se habilita ?
Até o próximo post !
Por enquanto, estou pegando ainda alguns pequenos assuntos para postar, mas também estou me preparando para alguns artigos mais práticos, na linha do que fiz falando de hash.
Quem nunca ouviu falar do software acima ? O Spybot é um utilitário de busca de malwares sem custo. Quando ele começou, o projeto oferecia exatamente isso, a máquina de busca de malwares. Hoje, na versão 1.5, ele conta com tradução para várias línguas, incluindo o Português do Brasil e tem outros apetrechos muito interessantes.
Neste ponto, você deve estar se perguntando o que isso tem a ver com Forense Computacional. Bom, além de obviamente ser uma boa ferramenta para busca de malware nas imagens, achei uma opção bem interessante nele, que o faz buscar por logs e outros elementos sobre privacidade na máquina. Já percebeu, né ? Esse grande utilitário pode varrer nossos artefatos de maneira rápida e eficiente. Além do mecanismo de busca que permite localizar vários logs diferentes no sistema (fora o tradicional - cookies, temp, etc), ele tem um "triturador", que faz remoções seguras dos arquivos indicados.
Isto posto, acrescente os seguintes pontos importantes nos seus procedimentos de busca:
1) Localizar qualquer instalação do Spybot.
2) Na total inexistência de logs, vale o corolário do HC, que já citei antes: "Ausência de evidências é uma evidência". O usuário pode ter usado as tais funcionalidades do triturador.
3) Os dados que ele registra ficam em Documents and Settings\All Users\Application Data\Spybot - Search & Destroy.
4) Verifique o arquivo Statististics.ini. Localize a chave [Log] e veja a data da última busca na chave LastFound. A chave LastRemoved indica a data da última vez que o usuário apagou os logs.
5) A string Tracks.uti=1 na chave [FileSets] do arquivo Configuration.ini indica que as trilhas de logs, cache, temp, cookies, etc estava selecionada para serem localizadas.
6) No arquivo Overview.ini do diretório Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Recovery você poderá localizar identificações de arquivos e dados que foram sanitizados, com datas e localizações originais. É uma boa informação para cruzar com as citadas anteriormente.
7) No diretorio Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Logs você achará grupos de logs das operações realizadas, com detalhes. Os arquivos tem nome
- Checks.aammdd-hhnn.txt, onde as letras são ano,mês, dia-hora,minutos
- Fixes.aammdd-hhnn.txt, onde as letras são ano,mês, dia-hora,minutos
Interessante seria escrever um script que automatizasse a busca desses itens na imagem e nos arquivos removidos. Alguém se habilita ?
Até o próximo post !
Assinar:
Postagens (Atom)