PCF-3

Questões comentadas, artigos e notícias

Archive for the ‘Forense’ Category

Livros sobre Computação Forense

Posted by papacharliefox3 em 02/03/2010

Fala, caboco!

Ainda estou vivo! Férias, carnaval, sem previsão de concurso este ano, enfim, ainda estou neste ritmo…aproveito para compartilhar uma lista de livros sobre forense computacional a qual mantenho em outro blog:

http://foren6.wordpress.com/livros/

A lista será constantemente atualizada, sugestões são bem vindas! Se alguém souber onde manter uma whishlist pública em sites nacionais me avise!

Bons estudos!

Posted in Forense, Motivacional, News & Clipping | Etiquetado: , , | 1 Comment »

Forense e Certificação

Posted by papacharliefox3 em 18/12/2009

Salve, concurseiros!

Estive meio “away” devido aos estudos direcionados a uma prova de certificação (GCIA). Agora que a missão foi cumprida retornamos aos estudos pró-PCF. Aproveito aqui para divulgar outro blog no qual escrevo: http://foren6.wordpress.com. Lá tento focar no tema de Segurança da Informação e Forense Computacional, este um tema muito provável na próxima prova.

Posted in Forense | Etiquetado: , , | 2 Comments »

Prova de 2002: Sistemas Operacionais Q.43

Posted by papacharliefox3 em 22/09/2009

Salve, cabocos!

De acordo com os garranchos que fiz na minha prova, acredito ter feito 60 pontos na prova pra Escriba. Será que rola o TAF? Dia 29 nós saberemos…

Para não perder o costume e cumprir a promessa, segue abaixo mais uma questão de provas anteriores para PCF3.

43Comentários

1 Questão de forensics hein? :) O comando dd faz a famosa cópia bit-a-bit, desta forma, não altera as datas/horários contidos nos metadados do sistema de arquivos, o que preserva a estrutura lógica.

2 Exatamente o contrário da anterior. O comando tar acessa a estrutura lógica do sistema de arquivos e, consequentemente, altera os mac times.

3 Questão de computação forense e Linux (comando md5sum não existe, por padrão, na instalação do Windows). O comando dd sem o parâmetro ‘of‘ (output file) irá jogar a sua saída no STDOUT. Dessa forma, ao se utilizar o prâmetro ‘-b’ com o comando md5sum, cujo propósito é a geração de hash md5 de um arquivo, a entrada de dados será a saída do primeiro comando (pipe), tratada em binário. O resultado será o valor hash da partição.

4 Sem dúvida.

5 Sem dúvida (essa vale explicar!). Sem muitas palavras, é isso: ssh user@host “cat /etc/passwd” > /home/pcf-3/copia_passwd.

Gabarito Oficial

1-E  2-E  3-C  4-C  5-C

Posted in Forense, Prova 2002, Sist. Operacionais | 2 Comments »

Prova 2009 FINEP: Questão 53

Posted by fuchoa em 25/08/2009

Salve concurseiros!

Aí vai uma questão saída direto do forno do CESPE abordando o tema de forense computacional. Acredito que o tema em questão será figura certa na próxima prova de períto da PF.

2009_FINEP53

2009_FINEP53_2

Comentários

I – Mereceria um dez se não fosse pela afirmativa: “cópia lógica dos arquivos  contidos nesses dispositivos”.  A cópia DEVE ser feita fisicamente para que não haja interatividade com os mecanismos logicos do sistema de arquivos. Não alterando, assim, o hashing gerado do dispositivo original.

II – Perfeita. Diferentes problemas exigem diferentes abordagens. Não poderia ser de outra forma  na computação forense, onde encontramos diversas técnicas para análise, exame e coleta de diversos sistemas, dispositivos e mídias.

III– Podemos dizer que chega a ser um “pecado mortal” afirmar que é princípio básico da criação da cadeia de custódia o acesso frequente aos dispositivos originalmente mantidos sob custódia. Todo o acesso e análise é executado em uma cópia do original.

IV – Correta. Questão conceito.

V– RSA é um algoritmo de criptografia de chave pública e não um algoritmo de hashing.

Gabarito Oficial Preliminar

53 – B

Posted in Forense, Segurança | Etiquetado: , , , | Leave a Comment »

Desafio de Forense I: colher de chá

Posted by papacharliefox3 em 17/04/2009

Salve, caboco!

A fim de facilitar (ou não) a vida dos leitores que ainda continuam tentando resolver o primeiro Desafio Forense, publico abaixo duas imagens. A primeira é a imagem original e a segunda a imagem alterada, que contém a senha para acesso ao post que comenta mais uma das questões-cenário (sobre fragmentação IP) da prova para perito.

O próprio tamanho dos arquivos entrega uma grande ‘pista’. E só para lembrar: não é um BMP! Não acredite em tudo que seu browser faz. Boa sorte!

Imagem original: 35709 bytes

Imagem original: 35709 bytes

Imagem alterada: 120812 bytes

Imagem alterada: 120812 bytes

Posted in Forense | 1 Comment »

Desafio de Forense I: CSI

Posted by papacharliefox3 em 11/04/2009

home_forensics3Salve!

Nosso colega Mr. Cometa já se declarou fã do Grissom e da turma do CSI. Em homenagem a ele publico agora uma imagem contendo as famosas faixas de isolamento utilizadas na cena do crime.

O problema é que dentro desta imagem existe uma senha, esta protege o post anterior, que possui acesso protegido, contendo comentários da questão 45 da prova de 2002. Quem sabe não passamos a fazer isso (desafios) mais vezes, o que pode servir como incentivo à busca de conhecimento e elevação do nível técnico dos candidatos ao concurso e dos leitores do blog. Autores ativos do blog terão acesso irrestrito.

Conselho aos que irão tentar, excetuando-se os profissionais de Forense Computacional que estão lendo o blog (sei que existem!): não causem DoS no WordPress, não há necessidade de brute-forcers na autenticação do post. Como dica, lembrem-se do caso do traficante Abadia. Mais detalhes abaixo:

O que Abadía e Hello Kitty têm em comum ?

Em alta, perícia digital vira negócio

Na questão, cobra-se conhecimento de redes e análise de logs da ferramenta tcpdump. Segue abaixo a questão:

45

Posted in Forense | Etiquetado: , | 2 Comments »

Prova de 2002: Cenário Ataque Unicode – Questões 36-38

Posted by papacharliefox3 em 22/02/2009

Mais um cenário da prova de 2002. Desta vez trata-se de um ataque a um servidor web utilizando uma técnica que ficou bastante conhecida na comunidade de Segurança em meados de 2001: Unicode Attack. Neste, o atacante utiliza-se de falhas de tradução do endereço (URI) de modo que recursos (arquivos, diretórios, comandos) antes inalcansáveis, tornam-se ferramentas para o ataque.

O hacker – pra quem ainda não sabe o que significa a palavra, veja aqui – conhecido como Rain Forest Puppy (RFP), explica de maneira bem simples o problema:

As cadeias de caracteres %c0%af e %c1%9c são as representações UNICODE para os caracteres ‘/’ e ‘\’. O servidor web da Microsoft (IIS) decodifica essas representações após a verificação do caminho (path checking), o que possibilita a execução arbitrária de comandos no servidor web. (RFP)

Um pouco de história (motivação). Naquela época, após a publicação da falha, muitos grupos de defacers e script-kiddies lançaram mão de ferramentas ou exploits públicos para realizarem o que ficou conhecido como mass hack ou mass defacement, nestes vários websites eram pichados em curto intervalo de tempo, utilizando-se de simples scripts que automatizam o disparo do ataque. Até este que vos fala, divertiu-se um pouco, veja aqui.

Obs.: a imagem (cenário) da questão é uma adaptação da qual consta na prova. Fiz isso a fim de facilitar a visualização e entendimento dos comentários. As únicas mudanças realizadas no conteúdo foram a troca do texto, onde estava  ‘atacker.nowhere.com’ (sic) tornou-se ‘evil’; e a adição de letras, para facilitar a apontamentos. Clique na imagem para visualizá-la em tamanho original (abrirá em nova janela).

Texto CE – questões de 36 a 38

Os trechos abaixo foram retirados de um arquivo de log referente a acessos a um servidor http.

Cenário - Logs do servidor web

Cenário - Logs do servidor web

QUESTÃO 36
Com base no texto CE, julgue os itens abaixo, referentes aos ataques ao servidor http mencionado nesse texto.

1 As tentativas exploratórias começaram a ter sucesso a partir de 23/1/2001.
2 Verifica-se ataque de defacement (pichação) a página Web.
3 A vulnerabilidade explorada nos ataques é a do parsing das requisições de arquivo em servidores Web, também conhecida como ataque de unicode, presente no MS IIS versão 5.0.
4 Os logs foram gerados pelo MS IIS.
5 O atacante fez uma cópia de backup da página original.

QUESTÃO 37
Novamente com base no texto CE e acerca dos ataques ao servidor http referido, julgue os itens a seguir.

1 Nos probes exploratórios, o atacante vasculhou diversos diretórios, procurando o arquivo “cmd.exe”, que é um interpretador de comandos.
2 “Atacker” copiou “cmd.exe” em outro arquivo, que posteriormente foi usado no ataque.
3 A página inicial do servidor Web atacado residia em “Default.htm”.
4 O servidor utiliza uma forma elementar de defesa, mantendo a página de index em “myweb.dll”.
5 “Atacker6” teve sucesso no ataque.

QUESTÃO 38
Ainda com base no texto CE, julgue os itens subseqüentes, relativos ao servidor http e aos ataques ocorridos.

1 A página vulnerada se apresentou em branco com os dizeres “H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R”.
2 Os ataques não poderiam ser evitados utilizando-se um proxy que restringisse os acessos à página inicial.
3 Não há patch disponível, atualmente, para corrigir a vulnerabilidade em questão, que seja fornecido pelo autor/fornecedor do servidor Web.
4 Um dos elementos dos ataques está no fato de o diretório “system32” ter seu acesso liberado, na configuração default do sistema operacional.
5 Os ataques poderiam ter sido evitados por meio de filtragem de pacotes em um firewall convencional.

Vamos aos (humildes) comentários:

36.1 As tentativas exploratórias começaram a ter sucesso a partir de 23/1/2001.

Aqui cabe o questionamento: o sucesso ocorre quando ocorre o evento (ataque) ou quando ocorre a exploração? Apostei na segunda opção. Para identificar o sucesso, utilizando-se apenas do que foi exposto (logs), não resta dúvida que a informação que precisamos está no código de resposta do servidor HTTP, ou seja, temos que verificar o valor do penúltimo campo do log. Encontra-se 4 tipos distintos nos logs, a saber:

200 -> OK

404 -> Not Found

500 -> Internal Server Error

502 -> Bad Gateway

Para mais detalhes sobre os códigos de erro, deve-se acessar o link para o documento RFC específico (ver em referências ao final do post).

Após verificar os logs, percebe-se que até a linha ‘i’, todas as requisições receberam código 404, diferentemente da linha posterior (j), na qual se encontra o código 200. Dessa forma, a sentença está ERRADA visto que a data constante na linha ‘j’ é “22/Jan/2001:21:19:27”, data em que os ataques começaram a ter sucesso.

36.2 Verifica-se ataque de defacement (pichação) a página Web.

Esse fato pode ser comprovado ao analisar-se as linhas ‘t’ e ‘u’, cujo conteúdo é idêntico. O comando executado por tais linhas é o seguinte:

echo H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R >c:\inetpub\wwwroot\Default.htm

Cabe aqui algumas observações:

  • Para efetuar um defacement, não há necessidade de alterar a página inicial do website, mas conteúdo qualquer, acessível publicamente;
  • O caminho c:\inetpub\wwwroot\ existe, conforme visto na linha ‘p’ dos logs;
  • O arquivo Default.htm tem seu conteúdo alterado para ‘H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R’. Apesar de o código HTTP ser 500 (erro interno), o comando foi executado com sucesso. Tal comportamento acontece em razão do servidor web não entender o valor do código de retorno da shell (cmd.exe); ‘1’ neste caso.

Assim, a sentença está CERTA.

36.3 A vulnerabilidade explorada nos ataques é a do parsing das requisições de arquivo em servidores Web, também conhecida como ataque de unicode, presente no MS IIS versão 5.0.

Não há o que se comentar em face do que já foi exposto. Sentença CERTA.

36.4 Os logs foram gerados pelo MS IIS.

Nesta sentença o candidato pára e pensa: “É óbvio que o log é da Microsoft, afinal o ataque é contra o servidor IIS! Mas, o CESPE não faria assim!”. É isto mesmo, o examinador não só ‘mata’ os mais afoitos como também deixa ‘em cima do muro’ os mais atentos e conservadores.  Existem dois pontos-chave para responder esta sentença:

Código HTTP 502: o código de nome “Bad Gateway” significa servidor mau uma maneira simples para se referir ao comportamento do servidor web, quando este age como um gateway ou proxy da requisição feita pelo cliente (browser). Para facilitar o entendimento, o cenário preparado pelo examinador deve ser o seguinte:

Apache servindo como proxy para IIS

Apache servindo como proxy para IIS

Formato do Log: o formato de log do servidor IIS obedece ao padrão estendido do W3C, este difere bastante do que foi mostrado (quem lida com Apache deve ter reconhecido). Segue abaixo um exemplo (ver referências):

#Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-bytes cs-bytes time-taken cs(User-Agent) cs(Referrer)
2002-05-24 20:18:01 172.224.24.114 - 206.73.118.24 80 GET /Default.htm - 200 7930 248 31 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+2000+Server) http://64.224.24.114/

Assim, a sentença está ERRADA visto que o log não foi gerado pelo MS IIS, mas por outro servidor web como o Apache ou outro cujo log possua o mesmo formato.

36.5 O atacante fez uma cópia de backup da página original.

Para fazer uma cópia, o comando copy ou procedimento similar (comando type com pipes, etc.) deve estar explícito nos logs. Não obstante a existência desses comandos nas linhas ‘q’, ‘r’ e ‘s’, nenhum desses realiza cópia da página original (supõe-se que seja default.htm). Sentença ERRADA.

37.1 Nos probes exploratórios, o atacante vasculhou diversos diretórios, procurando o arquivo “cmd.exe”, que é um interpretador de comandos.

Considerando as 9 primeiras requisições, excluindo-se o primeiro código 200(linha ‘j’), realmente verifica-se a tentativa de acesso a vários diretórios, todas com destino ao arquivo cmd.exe (que acaba agindo como um CGI). Questão CERTA.

37.2 “Atacker” copiou “cmd.exe” em outro arquivo, que posteriormente foi usado no ataque.

Novamente, para haver cópia, o comando copy deverá ser usado. Assim, as 3 linhas que contém este comando são: q, r e s. Nesta ocorre a cópia com sucesso:

copy+c:\winnt\system32\cmd.exe+c:\winnt\s3.exe (símbolo ‘+’ significa espaço)

Assim, a primeira parte da sentença está certa. Resta verificarmos se o arquivo copiado foi executado durante o ataque, fato que se confirma ao verificarmos as linhas ‘w’, ‘x’, ‘y’ e ‘aa’. Assim, a sentença está CERTA. Mas, espere! A questão foi anulada pela banca! :) Acredito que um dos argumentos utilizados para prova do contrário foi a inexistência de códigos HTTP com valor 200 em requisições ao comando “s3.exe”, diferentemente do que ocorreu com o requisições ao comando “cmd.exe” (linha ‘j’).

37.3 A página inicial do servidor Web atacado residia em “Default.htm”.

No IIS, por padrão, realmente o arquivo Default.htm abriga a página inicial do servidor web, entretanto, não há como se afirmar isso sem [1] acessar a página inicial do site, [2] sem verificar a configuração atual do IIS, [3] sem ter certeza de que trata-se de uma instalação padrão. Sentença ERRADA.

37.4 O servidor utiliza uma forma elementar de defesa, mantendo a página de index em “myweb.dll”.

Baseando-se nas explicações da sentença anterior faz-se suficiente para afimar que a sentença está errada, no entanto o gabarito consta como CERTA. Se você possui uma justificativa – plausível – dessa, manda por e-mail ou deixa um comentário no blog. Eu realmente não consegui identificar uma maneira de afirmar isso, baseando-se apenas nos logs.

37.5 “Atacker6” teve sucesso no ataque.

A sentença está CERTA, a justificativa encontra-se nos comentários da sentença 36.2.

38.1 A página vulnerada se apresentou em branco com os dizeres “H4ck3d by Gund3R0th thanks Gund3R1th Grup WebQu33R”.

A sentença está CERTA, a justificativa encontra-se nos comentários da sentença 36.2.

38.2 Os ataques não poderiam ser evitados utilizando-se um proxy que restringisse os acessos à página inicial.

Tornando os acessos limitados (restritos) à página inicial, ataques realizados a diretórios ou caminhos diferentes da página inicial se tornariam inócuos. Essas restrições podem ser feitas em um proxy (no cenário suposto, seria feito no servidor Apache). Sentença ERRADA.

38.3 Não há patch disponível, atualmente, para corrigir a vulnerabilidade em questão, que seja fornecido pelo autor/fornecedor do servidor Web.

A vulnerabilidade fora exposta – ao público – em 2001; à época da prova, a Microsoft já havia disponibilizado correções de segurança as quais corrigiam tal falha. Clique aqui para mais detalhes.

38.4 Um dos elementos dos ataques está no fato de o diretório “system32” ter seu acesso liberado, na configuração default do sistema operacional.

Sem dúvida. Dentre outras ações (aplicação de controles, hardening), o administrador pode restringir o acesso do usuário que executa o serviço do servidor web (contexto), o que não é aplicado por padrão. Sentença CERTA.

38.5 Os ataques poderiam ter sido evitados por meio de filtragem de pacotes em um firewall convencional.

Por meio da filtragem convencional, haveria apenas a possibilidade de bloqueio da porta em que o serviço web ‘escuta’, neste caso, o bloqueio de acesso à porta 80 simplementa faria com que nenhuma aplicação web pudesse ser acessada. Sentença ERRADA.

Gabarito definitivo:

36: 1-E  2-C  3-C  4-E  5-E
37: 1-C  2-X  3-E  4-C  5-C
38: 1-C  2-E  3-E  4-C  5-E

Referências:

– Hyper Text Protocol 1.1  RFC, http://www.ietf.org/rfc/rfc2616.txt
– Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes, http://support.microsoft.com/kb/318380
W3C Extended Log File Examples
– Microsoft IIS 4.0 / 5.0 vulnerable to directory traversal via extended unicode in url (MS00-078), US-CERT

Posted in Forense, Prova 2002, Questões Cenário, Redes, Segurança, Sist. Operacionais | 1 Comment »

Questão 38, Forense Computacional CPC/PA

Posted by papacharliefox3 em 20/02/2009

Questão 38 da prova para perito formulada pela CESPE. O PDF pode ser baixado aqui.

f1

Essa figura apresenta um exemplo de interface com o usuário de um software de apoio à forense computacional para a plataforma Windows. Sabe-se que, para a análise forense adequada de sistemas Windows, são importantes a compreensão dos sistemas de arquivo NTFS e FAT e a compreensão dos artefatos do Windows, incluindo-se o modo de encontrá-los e de interpretar suas propriedades. No caso do sistema Linux, destaca-se a necessidade de se compreender uma ampla gama de sistemas de arquivos distintos.

Considerando as informações acima, assinale a opção correta no que se refere a conceitos de sistemas operacionais e browsers, especialmente os relacionados com a análise forense.

A) Sistemas Linux apresentam um maior número de artefatos que sistemas Windows.
B) O sistema FAT32 suporta metadados que indicam as datas de criação, última modificação e último acesso de cada arquivo.
C) No sistema operacional Windows 98, o registro do Windows encontra-se parcialmente armazenado em um arquivo de nome system.dat.
D) O arquivo pagefile.sys é usado para suportar a hibernação de memória virtual em sistemas Windows XP.

Apesar de a questão mostrar uma figura, para resolução das sentenças não há necessidade de consultá-la. Apenas a título de curiosidade, a figura apresentada é um screenshot de uma das ferramentas desenvolvidas pela empresa X-Ways Software.

A) Sistemas Linux apresentam um maior número de artefatos que sistemas Windows.

O que são artefatos? Procurei no dicionário:

artefato1
ar.te.fa.to1
sm (lat arte factu) Designação dada a qualquer objeto produzido pelas artes mecânicas. Var: artefacto.

artefato2
ar.te.fa.to2
adj (de artefato1) V artificial.

Aplicando-se o conceito no contexto de forense computacional, um artefato nada mais é que qualquer dado gerado por um usuário (invasor) utilizando-se de sistemas computacionais. Nas perícias forenses realizadas em computadores, imagens, documentos, logs; enfim, qualquer conjunto de bits persistentes na memória, seja ela primária ou secundária, é considerado um artefato. Assim, torna-se uma tarefa bastante complicada a de quantificá-los. Sentença ERRADA.

B) O sistema FAT32 suporta metadados que indicam as datas de criação, última modificação e último acesso de cada arquivo.

O FAT32 asssim como o NTFS, é um sistema de arquivos que armazena metadados no diretório pai imediato ao arquivo, nesses estão informações como permissões, tamanho, etc. No gabarito preliminar consta como ERRADA esta sentença, no entanto, veja o conteúdo da tabela abaixo (em Inglês):

untitled1

Esta tabela foi extraída do documento da Microsoft entitulado “FAT32 File System Specification” de Dezembro de 2002. O link para o arquivo está aqui.

Note que o texto em negrito destaca exatamente as informações que constam na sentença. Daí a dúvida, será que o examinador quis referir-se ao dado inexistente, referente ao horário do último acesso (observação destacada em azul)? Desta forma, a sentença está CERTA.

C) No sistema operacional Windows 98, o registro do Windows encontra-se parcialmente armazenado em um arquivo de nome system.dat.

Perfeito. O Windows armazena as informações do registro basicamente em dois arquivos binários: system.dat e user.dat. A sentença está CERTA (somente esta, de acordo com o gabarito preliminar).

D) O arquivo pagefile.sys é usado para suportar a hibernação de memória virtual em sistemas Windows XP.

Ao colocar um computador em hibernação ou em espera, o Windows salva o estado corrente no arquivo hiberfil.sys, localizado na raiz da unidade do sistema. Já o arquivo pagefile.sys armazena as páginas de memória, utilizadas pela memória virtual. Sentença ERRADA.

Achou útil? Se encontrar alguma questão de forense ou que envolva cenários (Segurança, Redes, etc.) pertinentes ao concurso da PF, mande-nos! Até o próximo post!

Gabarito (preliminar):

http://www.cespe.unb.br/concursos/CPC2007/arquivos/CPCPA_Gab%20Preliminar_020_20.pdf

Referências:

– Microsoft, http://technet.microsoft.com

Posted in Forense, Sist. Operacionais | Comentários desativados em Questão 38, Forense Computacional CPC/PA

Forense Computacional! Justiça Suíça processa brasileira por falso testemunho

Posted by papacharliefox3 em 18/02/2009

ZURIQUE – A Justiça de Zurique, na Suíça, abriu processo penal contra a brasileira Paula Oliveira por suspeita de falso testemunho à polícia local. Ela alega ter perdido os bebês após ter sido supostamente agredida por neonazistas na semana passada. Segundo o Ministério Público local, a denúncia ocorre por ela ter alegado estar grávida, quando exames provaram o contrário.

A Justiça vai intimar Paula e deverá liberá-la depois do depoimento, para que retorne ao Brasil. Segundo a Procuradoria-Geral de Zurique, um advogado já foi indicado para defender Paula e ela aceitou a oferta. De acordo a BBC, a utilização de seu passaporte também foi suspensa. “Esta medida garante que a mulher permaneça na Suíça o tempo que sua presença for necessária para o inquérito e todas as providências da investigação tiverem sido tomadas”, afirma o comunicado.

Paralelamente à suspeita de falso testemunho, o caso ainda segue por um outro caminho. A polícia ainda investiga se de fato Paula foi vítima de uma agressão na segunda-feira da semana passada. Ontem, a brasileira recebeu alta do hospital e voltou para casa. Ela deixou o centro médico pela porta dos fundos.

Fonte: JAMIL CHADE – Agencia Estado

Beleza, o que isso tem de interessante? Sabe o que os policiais suiços utilizaram de base para esta denúncia?

Além da hipótese de autolesão (ou foi o parceiro dela?), eles descobriram um e-mail enviado pela brasileira a amigos, que consta uma imagem da suposta ultrasonografia da gravidez. O mais interessante é que após uma busca no Google, descobriram que a imagem que está no e-mail é a mesma que retorna na consulta, inclusive, com legenda em Inglês! Na Suiça fala-se Alemão, Francês e Italiano. Quer arrumar uma dessas imagens, utilize este link!

A polícia deve ter utilizado nosso famoso “hash” (MD5, SHA) para comparar as imagens. Se isto se confirmar, é uma vergonha para nós brasileiros e um ótimo caso de perícia para a polícia daquele país.

Posted in Forense, News & Clipping | 1 Comment »

Prova de 2002: Cenário Linux – Questão 39

Posted by papacharliefox3 em 15/02/2009

Mais um ‘cenário’ da prova de 2002, agora envolvendo a interpretação da saída de comandos assim como tópicos de segurança do SO Linux. Eis a questão 39 da prova:

O administrador da rede Alfa recebeu diversas reclamações, de administradores de outras redes, de que uma de suas máquinas
estaria gerando tráfego suspeito. A máquina em questão é um servidor Unix, servidor03 (endereço IP 192.168.11.1). Abaixo, são
mostradas as porções relevantes dos resultados da execução, no referido servidor, de alguns comandos.

untitled1

Além das informações acima, em uma inspeção dos módulos carregados no kernel, não foi apontada nenhuma anormalidade. Nesse caso,
é correto concluir que o servidor03 sofreu um comprometimento de root e que

1 não se trata de um rootkit na forma de um LKM.
2 um telnet na porta 12345 do servidor03 chamará o programa suspeito, sendo a melhor forma de avaliar o que ele faz.
3 o programa suspeito executa um unlink antes de se tornar daemon, evitando aparecer no sistema de arquivos.
4 é carregado no boot, acarretando, assim, o comprometimento de algum arquivo de inicialização.
5 as cadeias de caracteres podem ser inspecionadas, caso a imagem executável do programa suspeito possa ser localizada no sistema de
arquivos /proc.

A primeira questão envolve conhecimento de Loadable Kernel ModuleLKM e rootkits. Para que nunca ouviu falar no primeiro, trata-se de módulos (software) que extendem funções geralmente implementadas no próprio kernel (cerne, núcleo) do SO, possibilitando o carregamento dinâmico, ou seja, separado da própria imagem do SO que é carregada durante a inicialização da máquina. Drivers de placas são usualmente implementados desta forma.

Já os rootkits são softwares utilizados usualmente para garantir o acesso ao “hacker” logo após uma intrusão, o mesmo conceito aplicado as backdoors, sendo que nestas nem sempre há a preocupação em torná-las escondidas, além de carregarem seu payload em arquivos próprios. Os rootkits nada mais são que um conjunto (kit) de programas com a finalidade de garantir acesso futuro, sem levantar suspeitas, alterando binários comuns em qualquer distribuição Linux e podendo ainda eliminar qualquer possibilidade de rastreabilidade.

Há casos, inclusive, que após detecção a única ou melhor alternativa é refazer a instância ou instalação do SO danificado, a fim de minimizar a possibilidade de manter o acesso não autorizado ao responsável pela instalação do roootkit. Vamos ao texto da questão:

1 não se trata de um rootkit na forma de um LKM.

Uma das maneiras – básicas – de inspecionar LKMs é através do comando disponível no Linux, chamado lsmod, o qual é utilizado para listas os módulos carregados no sistema. No entanto, o examinador não expõe a saída do comando que precisamos a fim de dificultar a avaliação do cenário, lógico. Porém, uma caracterísitica importante, pouco comum em rootkits, é notada: o comando responsável pela abertura da suposta backdoor na porta 12345 chama-se “laden”. Informação encontrada na saída do comando ps, após interpretação de todas as informações apresentadas.

Eu abordei a questão da seguinte maneira. Há indícios suficientes para afirmarmos que trata-se de um rootkit que utiliza LKM para estabelecer a backdoor? Minha resposta é não. Veja, rootkits utilizam-se de binários comuns e conhecidos – incluindo o ps – para ocultar a atividade maliciosa. No cenário apresentado, facilmente percebe-se que o processo “laden” abre uma porta “estranha” (12345). Assim, conclui-se que a questão é CERTA.

2 um telnet na porta 12345 do servidor03 chamará o programa suspeito, sendo a melhor forma de avaliar o que ele faz.

Pode até ser considerada uma das formas de avaliação, mas definitivamente não é a melhor. A engenharia reversa do comando sem dúvida não resume-se àquela ação.

3 o programa suspeito executa um unlink antes de se tornar daemon, evitando aparecer no sistema de arquivos.

Não obstante a presença na saída do comando ps, o comando “laden” não é apresentado em forma de arquivo na saída do comando find, utilizado para encontrar arquivos. Este comportamento é explicado justamente pelo motivo exposto na questão. Para ficar mais claro, nada como ler direto no manual (man 2 unlink):

unlink() deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open the file is deleted and the space it was using is made available for reuse. If the name was the last link to a file but any processes still have the file open the file will remain in existence until the last file descriptor referring to it is closed.

Ainda não convenceu? Desiste! Veja só que exemplo bolei (screenshot mesmo porque não aprendi a copiar/colar da VM):

Exemplo de comportamento após o "unlink"

Exemplo de comportamento após o "unlink"

Percebam que o daemon do servidor HTTP é removido do sistema de arquivos (unlinked), entretanto o processo e seus recursos continuam alocados; mesmo caso do cenário exposto na prova.

4 é carregado no boot, acarretando, assim, o comprometimento de algum arquivo de inicialização.

Essa é mais fácil de explicar. Percebam o campo processo pai – PPID – na saída do comando ps referente ao comando “laden”. O valor dele é 1. Sabe quem é o processo 1 no Linux? O init, responsável, dentre outras coisas, pela inicialização de serviços no SO Linux. Assim, podemos concluir que realmente o comando “laden” carregou-se na inicialização, o que indica alteração (comprometimento) de algum arquivo dessa etapa.

Epa! A banca pensava assim e mudou. Era C e virou E. Explicação? Existem várias… uma bem prática pra finalizar esta. Algum concurseiro, louco para entrar na PF formulou o seguinite recurso:

Venho através desta (“alguém aí assistiu “O Destino de Miguel?!”) bibibi bobobo dizer que se eu editar o arquivo /etc/inittab, de modo que determinada linha de comando seja executada, mesmo com o SO já carregado; e em seguida, digitar o comando init q, meu comando será executado e terá como processo pai o init (PID = 1). Portanto, quero meu ponto!

E assim a banca aprendeu mais uma (quem sabe quem lê este blog talvez aproveite algo também)…

5 as cadeias de caracteres podem ser inspecionadas, caso a imagem executável do programa suspeito possa ser localizada no sistema de
arquivos /proc.

Sim, basta saber que todos os recursos alocados aos processos estão no diretório mencionado.

Até a próxima!

Gabarito:

Questão 39: 1-C  2-E  3-C  4-E(alterado)  5-C

Referências:

– Manual do comando “unlink”, http://linux.die.net/man/2/unlink
– LKMs, http://en.wikipedia.org/wiki/Loadable_kernel_module

Posted in Forense, Prova 2002, Questões Cenário, Segurança, Sist. Operacionais | Leave a Comment »