PCF-3

Questões comentadas, artigos e notícias

Archive for the ‘Questões Cenário’ Category

Serpro 2008: Análise de Tráfego 76-80

Posted by papacharliefox3 em 30/07/2009

Salve! Mais uma de análise de log de tcpdump! Imagine a emoção de se deparar com a figura abaixo na sua prova – mais de meia página de logs! :)

ser2

ser21

Comentários:

76 O que impede a captura ter sido feita – também – no host 10.10.100.101 ou no segmento no qual ele se encontrava?

77 Percebe-se que o mesmo segmento é requisitado várias vezes pelo host 10.10.100.101, inclusive enquanto segmentos posteriores são recebidos. Sendo que esse segmento requisitado várias vezes é enviado ao final do diálogo apresentado. Logo, houve chegada fora de ordem, entretanto, devido a falta ou perda de tal segmento. O que gerou a perda? Sei lá eu!

78 Eu não vi, você viu? Aliás, na hora da prova todas as linhas parecem iguais, não?

79 Sinceramente, não entendi o gabarito ser C. A opção sack indica exatamente o contrário: segmentos que não foram perdidos, mas armazenados pelo receptor, mesmo se tratando de segmentos posteriores ao último requisitado.

80 Verdade. No trecho 24, identifica-se o segmento 48181, ou a existência dele; este ainda não foi enviado ou processado pelo host 10.10.100.101 (receptor), de acordo com os logs apresentados.

Gabarito Oficial

76-E  77-E  78-E  79-C  80-C

Anúncios

Posted in Questões Cenário, Questões Serpro, Redes | Etiquetado: | 3 Comments »

Serpro 2008: Análise de Tráfego 71-75

Posted by papacharliefox3 em 30/07/2009

Salve, concurseiros de TI! (aka nerds wanna go public service)

Desta vez comentarei mais uma das temíveis questões de análise de tráfego do CESPE. A questão foi retirada da prova de 2008 – Analista de Redes. Quem me enviou esta questão foi o colega Alan Ricardo (demorou, mas foi!). Se tiverem mais alguma aí do mesmo nível ou pior, mandem nos comentários que a gente discute mais!

ser1

Comentários:

71 O que é payload? Neste contexto, basicamente, retirando-se o cabeçalho (header) de um pacote IP, tem-se a carga de dados do pacote – payload. Do host 1 para o host 2, foi enviado apenas um pacote Ping (ICMP Echo Request), o que compreende os pacotes de 1 a 3 do log. Assim, basta identificar o último pacote e somar o offset com o tamanho dos dados contidos naquele, menos o tamanho dos cabeçalhos (IP e ICMP): (2944 + 84) – (20 + 8) = 3000. Existem outra maneiras de ‘enxergar’ a questão, fica aí minha sugestão.

72 Dizem por aí que esta questão poderia ser anulada por não ser possível identificar o pacote 4 no texto da questão (não dá mesmo?). Enfim, o 4 está entre o 3 e o 5 (eu sou um gênio!), e nesse é possível perceber o sinal ‘[ ]’ que o diferencia de alguns outros pacotes. Isso indica que a flag More Fragments não está setada, logo, ele é o último fragmento e não o primeiro.

73 Fragmentos de resposta = pacotes 4-8. Fica aí o desafio: existem duas informações no trecho que indicam que os pacotes – possivelmente – passaram por rotas diferentes, quais são elas? :) Nem adianta apelar pro TTL porque todos contêm o mesmo número… ah, um salve aí pros mano da pizzaria Pôr do Sol!

74 Neste caso, o processo de remontagem (reassembly) procede normalmente. No IP, se um fragmento se perde, o pacote inteiro é descartado, o que leva a perda do buffer recém armazenado. Isso pode ocorrer, por exemplo, após o timer de recepção expirar.

75 Não enxergo uma maneira de determinar esta informação com o trecho mostrado. Se alguém souber esta, manda aí! Eu arriscaria 764.

Gabarito Definitivo

71-C  72-E  73-C  74-E  75-C

Posted in Questões Cenário, Questões Serpro, Redes | Etiquetado: | 3 Comments »

TCU 2009: questões de captura de tráfego 144-147

Posted by papacharliefox3 em 25/07/2009

Um salve pro vardeci da pizzaria pôr do sol…ah um salve pra geral da XURUPITA!

Salve, concurseiros!

A temível prova do TCU deste ano deu o que falar, mais ainda pelas questões de Redes e Segurança. Nível altíssimo de dificuldade, realmente. Tentarei comentar as questões de Redes (análise de logs de tráfego) e Segurança. Começando pela primeira questão desses temas encontrados na prova.

tcu144-147144 Se utilizarem a mesma máscara de rede, qualquer que seja,
então os hosts envolvidos na captura de tráfego estarão na
mesma sub-rede.

145 A chegada fora de ordem dos pacotes de resposta deve-se à
retransmissão de alguns deles ao longo do percurso.

146 É consistente com a captura que há quatro nós intermediários
entre os hosts nela presentes.

147 É consistente com a captura que o processo de fragmentação
tenha sido aplicado mais de uma vez nos pacotes de resposta.

Comentários:

144 Precisa olhar pra figura? Sim! A informação de máscara é carregada nos pacotes e, por conseguinte, nos logs? Não! Dá para saber se estes caras estão no mesmo domínio de broadcast (sem roteadores entre eles) baseado na análise do tráfego? Sei lá eu…então como fazer?

Perceba que, existem apenas 2 endereços distintos, envolvidos no tráfego apresentado: 10.1.1.100 e 10.1.1.200. Agora imagine estes caras com uma mesma máscara (qualquer), digamos a famosa ‘/24’. Imaginamos isso:

Rede => 10.1.1.0 e Máscara =>255.255.255.0

Os IPs .100 e .200 estariam nesta faixa, sem dúvidas. Mas, e se atuarmos da forma contrária, ou seja, encontramos uma situação hipotética de exclusão? Imagine os 2 IPs pertencentes a uma rede ‘/30’. Como poderia ficar?

Rede 1 => 10.1.1.99  Máscara=> 255.255.255.252  Host 1 => 10.1.1.1.100

Rede 2 => 10.1.1.199  Máscara=> 255.255.255.252  Host 2 => 10.1.1.1.200

Teria que haver um roteador entre eles! Logo, não estariam na mesma sub-rede.

Mas, se o leitor estiver atento, basta enxergar o processo de Fragmentação. Como e quando esta ocorre? Em enlaces com diferentes valores de MTU! Se eles não estão no mesmo enlace, devem existir roteadores entre eles, logo, eles não podem estar na mesma (sub) rede! Pegadinha do malandro examinador…

145 Como checar a chegada fora de ordem? Pelo offset! Como identificar retransmissão? Identifique no payload a string ‘Houston, we have a problem!’ Brincadeira…caríssimos leitores, estamos falando de IP (ICMP), onde haverá retransmissão?

146 Ah, um salve pro pessoal do trabalho! Cabeça e Japa! Esta questão é a mais difícil, sem dúvida! Alguns pontos interessantes: ‘há quatro’ é diferente de ‘somente quatro’! O examinador não seria a mãe Diná para afirmar exatamente quantos hops existem entre os 2 hosts, baseado apenas nesses logs!

Pense da seguinte maneira. Se eles estão em redes diferentes (como mostrado acima), existem pelo menos 2 nós (roteadores, hops) entre eles! (Básico, hein?) Mas, é possível identificar 3 MTU’s diferentes (serve para próxima questão)! E agora? Lembre-se que, o MTU é estabelecido entre 2 nós, geralmente roteadores. Assim, dá para imaginar – suficiente para concordar com a afirmação da questão – a seguinte figura (fiz no Paint Visio!):

mtu

147 Sem dúvida, perceba os pacotes 5-8 com tamanhos (length) diferentes: 764 e 756.

Achou difícil? Não entendeu alguma mer explicação? Tem outra questão da prova que achou mais difícil? Mande nos comentários!

Até a próxima!

Gabarito Preliminar Oficial

144-E  145-E  146-C  147-C

Posted in Questões Cenário, Questões TCU, Redes | 6 Comments »

Protegido: Prova de 2002: Cenário TCPdump – Questão 45 (senha está no Desafio de Forense I)

Posted by papacharliefox3 em 11/04/2009

Este conteúdo está protegido por senha. Para vê-lo, digite sua senha abaixo:

Posted in Prova 2002, Questões Cenário, Redes | Etiquetado: , | Digite sua senha para ver os comentários.

Protegido: Prova 2004 Regional: Cenário TCPDump – Questões 118-120

Posted by papacharliefox3 em 01/04/2009

Este conteúdo está protegido por senha. Para vê-lo, digite sua senha abaixo:

Posted in Prova 2004 REG, Questões Cenário, Redes, Segurança | Etiquetado: | Digite sua senha para ver os comentários.

Protegido: Prova de 2004 Regional: Cenário Redes/TCPdump – Questões 82-85

Posted by papacharliefox3 em 24/02/2009

Este conteúdo está protegido por senha. Para vê-lo, digite sua senha abaixo:

Posted in Prova 2004 REG, Questões Cenário, Redes | Etiquetado: | Digite sua senha para ver os comentários.

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 »

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 »

Prova de 2002: Cenário Ethereal – Questão 46

Posted by papacharliefox3 em 09/02/2009

Mais uma questão de cenário, novamente, envolvendo redes e ferramentas analisadoras de tráfego, mais conhecidas como analisadores de protocolo.

A realização de análise de tráfego em uma rede TCP/IP é uma técnica importante para monitoração e auditoria da rede e de seus serviços.
As figuras I e II a seguir, obtidas com o uso da ferramenta Ethereal (www.ethereal.com), apresentam exemplos típicos de informações
extraídas com o uso de ferramentas analisadoras de rede, que são empregadas na realização de análise de tráfego.

Figura I

Figura I

Figura II

Figura II

Acerca das informações contidas nas figuras I e II e de suas interpretações, julgue os itens a seguir, relativos à rede mencionada acima.

  1. Todo o tráfego observado, de acordo com a figura I, utiliza o protocolo IP.
  2. De acordo com a figura I, o protocolo UDP não está implementado nessa rede, sendo o protocolo TCP o único protocolo de transporte disponível.
  3. O pacote de número 42, na figura II, é uma retransmissão do pacote de número 41.
  4. Os pacotes de números 41, 42, 45 e 46, mostrados na figura II, fazem parte de uma mesma conexão TCP no sentido da porta 1024 para a porta ftp. Por outro lado, os pacotes 43 e 44 fazem parte de outra conexão TCP simétrica, no sentido da porta ftp para a porta 1024. As duas conexões formam uma ligação TCP bidirecional.
  5. A primeira opção do pacote TCP de número 41, detalhado na parte inferior da figura II, aparece apenas em mensagens TCP de estabelecimento de conexão, isto é, que possuam o flag de SYN ativo.

Nota: O projeto Ethereal foi descontinuado por seu fundador (Gerald Combs) devido a problemas com o nome (patentes, etc.), todavia um fork do projeto existe e vai bem obrigado! Ele chama-se Wireshark, projeto pelo qual Combs e sua equipe são responsáveis (além de serem funcionários da empresa responsável pela biblioteca Winpcap).

Deixando a história de lado, vamos as questões:

1. Todo o tráfego observado, de acordo com a figura I, utiliza o protocolo IP.

De acordo com a Figura I, somente frames contendo os protocolos TCP e ICMP foram capturados, assim basta sabermos se ambos fazem uso do Internet Protocol – IP. O protocolo ICMP, utilizado para diagnóstico de conexões, utiliza o IP visto que mensagens desse protocolo são carregadas dentro de datagramas IP, conforme visto abaixo:

Datagrama IP com mensagem ICMP

Datagrama IP com mensagem ICMP

No caso do TCP, acontece da mesma forma, ele deve caber na carga útil do datagrama IP:

Datagrama IP contendo um segmento TCP

Datagrama IP contendo um segmento TCP

De maneira mais prática, podemos criticar o seguinte: olhando para o esquema do segmento TCP abaixo, onde estão os endereços IP de origem e destino? A resposta é: no datagrama IP.

Segmento TCP

Segmento TCP

Assim, pode-se concluir que ambos utilizam o protocolo IP. Para mais informações consultar os documentos RFC correspondentes.

2. De acordo com a figura I, o protocolo UDP não está implementado nessa rede, sendo o protocolo TCP o único protocolo de transporte disponível.

Questão típica “pegadinha”, explico. Ao ater-se a informação final “sendo o protocolo TCP o único protocolo de transporte disponível”, o candidato analisa se isto realmente é verdade, ou seja, se o TCP é um protocolo da camada citada – o que é verdade. Entretanto, a sacada é perceber que não obstante a Figura I mostrar 0% de frames detectados contendo o protocolo UDP, não pode-se concluir que a rede examinada (naquele período) não posssui serviços de rede disponíveiss através do protocolo UDP.

3. O pacote de número 42, na figura II, é uma retransmissão do pacote de número 41.

O que é seria uma retransmissão no contexto apresentado? Quando um host envia um segmento TCP, mas o destinatário não o recebe por algum motivo, e assim o remetente deve reenviar o segmento não recebido. Essa situação ocorre quando um timeout de confirmação de recebimento do segmento expira do lado do remetente (basicamente). Além disso, o TCP utiliza-se de algoritmos de retransmissão e temporização baseados em variáveis calculadas envolvendo o tempo de ida e volta de um segmento (round trip time – RTT). Na Figura II percebe-se que há resposta para ambos segmentos citados (41 e 42), suficiente para concluirmos que não houve retransmissão. Ademais, requisição e resposta acontecem no mesmo centésimo de segundo (14.25).

Vale notar que esta questão teve gabarito alterado (C->E), quem tiver acesso a resposta do recurso, mande pra nós. :) Além disso, há uma duplicação de todos os segmentos apresentados, isso pode ocorrer por diversos motivos.

4. Os pacotes de números 41, 42, 45 e 46, mostrados na figura II, fazem parte de uma mesma conexão TCP no sentido da porta 1024 para a porta ftp. Por outro lado, os pacotes 43 e 44 fazem parte de outra conexão TCP simétrica, no sentido da porta ftp para a porta 1024. As duas conexões formam uma ligação TCP bidirecional.

Os pacotes mencionados tratam da mesma conexão. Percebam que todos os segmentos a partir da linha de número 41, tratam do estabelecimento da conexão TCP (para efetuar uma conexão FTP, neste caso): SYN | SYNACK | ACK (duplicados).

5. A primeira opção do pacote TCP de número 41, detalhado na parte inferior da figura II, aparece apenas em mensagens TCP de estabelecimento de conexão, isto é, que possuam o flag de SYN ativo.

Corretíssimo, citando o RFC 793:

Maximum Segment Size Option Data:  16 bits

          If this option is present, then it communicates the maximum
          receive segment size at the TCP which sends this segment.
          This field must only be sent in the initial connection request
          (i.e., in segments with the SYN control bit set).  If this
          option is not used, any segment size is allowed.

Mandem suas dúvidas e sugestões. Até o próximo post!

Gabarito:

Questão 46: 1-C  2-E  3-E  4-E  5-C

Referências:

Redes de Computadores 4ed., Tanenbaum
RFC “Transmission Control Protocol” – http://www.faqs.org/rfcs/rfc793.html
RFC “Computing TCP’s Retransmission Timer” – http://tools.ietf.org/html/rfc2988

Posted in Forense, Prova 2002, Questões Cenário, Redes | 2 Comments »

Prova 2004 Nacional: Cenário Redes – Questões 82-86

Posted by papacharliefox3 em 01/02/2009

cenario_pcap_04nac

A figura acima ilustra parte da janela de um analisador de rede mostrando os dados de uma conexão TCP entre os hosts A (10.0.0.20) e B (164.0.0.130). Considerando que esses hosts tenham apenas os endereços IP mencionados, julgue os itens a seguir.

[82] Os endereços MAC dos hosts A e B são, respectivamente,
00:01:F4:96:50:7F e 00:80:5F:31:D9:7C.

[83] É correto afirmar que existe, pelo menos, um roteador entre
os dois hosts.

[84] A conexão TCP é mostrada desde o seu estabelecimento até
o seu encerramento, sendo que todos os segmentos TCP
transmitidos são ilustrados pelo menos uma vez na figura.

[85] Trata-se de uma sessão FTP de controle, na qual o cliente
realizou três tentativas malsucedidas de se autenticar no
servidor e foi desconectado por este.

[86] Com exceção dos segmentos TCP usados para estabelecer e
fechar a conexão, todos os outros segmentos carregam uma
quantidade não nula de bytes de dados.

Para facilitar a exposição, os comentários (opiniões pessoais, baseadas em pesquisa e testes) ficarão abaixo de cada item. O gabarito está ao final do post. Antes de começar, alguns questionamentos que ajudarão (ou deixarão mais ‘bolado’) o candidato:

  • Em que local ou onde está posicionado o sensor ou host que capturou este tráfego de rede? No segmento de rede do host A? No segmento do host B? Em um ponto comum da rota entre ambos? Ambos estão no mesmo segmento?
  • A qual programa pertence essa tela? Sabemos que é um analisador de protocolo ou simplesmente um sniffer, mas qual?
  • Sabemos que a rede 10.0.0.0/8 ou o range que está contido neste par rede/máscara não é roteável na Internet (vide RFC 1918); o que dizer do IP 164.0.0.130 referente ao endereço do host B?

As respostas podem ser discutidas no canal #pcf-3 @freenode ou mesmo requisitadas em um cenário similar no próximo concurso! ;) Vamos as duas primeiras questões:

[82] Os endereços MAC dos hosts A e B são, respectivamente,
00:01:F4:96:50:7F e 00:80:5F:31:D9:7C.

[83] É correto afirmar que existe, pelo menos, um roteador entre
os dois hosts.

Responder aos primeiros questionamentos mencionados acima, facilita a resposta destes itens. Entretanto, outros também auxiliam:

  • Podem os hosts participarem de uma mesma rede lógica, de forma que não dependam de um roteador para se comunicarem? Assumamos que não, pois, de maneira prática, teríamos que definir um par rede/máscara que englobasse os dois hosts. Logo, deverá haver um roteador entre eles, no mínimo.
  • Em uma rede Ethernet, frames ou pacotes capturados conterão 2 endereços físicos (MACs), um de origem e outro de destino, este pode ser, inclusive, o endereço de broadcast. Sabendo-se que os dados que serão transferidos entre os hosts passarão por um roteador, este ao entregar um pacote ao host B oriundo de A manterá o MAC (endereço físico) de A ao repassar o pacote? O que o roteador fará é substituir os valores contidos nos campos origem e destino, utilizando os valores referentes aos endereços físicos do seu adaptador de rede (sainte) e do próximo destino. O próximo destino pode ser o destino final (B) ou outro roteador, necessário para entregar o pacote ao destino final. Enfim, um pacote/frame qualquer, capturado naquela sessão, não poderá conter endereços físicos de ambos os hosts.

[84] A conexão TCP é mostrada desde o seu estabelecimento até
o seu encerramento, sendo que todos os segmentos TCP
transmitidos são ilustrados pelo menos uma vez na figura.

Uma conexão TCP é estabelecida em 3 etapas (também conhecidas como TCP/IP Handshake). Assim, para validar a afirmação da questão, deveremos encontrar o estabelecimento e o encerramento da conexão. Os segmentos referentes ao estabelecimento, são os seguintes:

  1. Linha 228: Host A (cliente) envia o segmento TCP contendo a flag SYN setada com número de sequência igual a 0 e janela de 5840 bytes;
  2. Linha 229: Host B (servidor) envia segmento aceitando a conexão, nesse estão as informações de sequência igual a 0; ACK iguaal a 1; janela de 5792 bytes e flags SYN e ACK setadas com valor 1;
  3. Linha 230: Cliente confirmaa reconhecimento da disponibilidade da conexão, desta vez com número de sequência igual a 1, e requisitando o próximo segmento de numero 1 (ACK=1). Além disso, a flag SYN possui valor 0 e a ACK tem valor 1, com o mesmo valor de janela inicial.

Como pode-se perceber, o famoso “SYN | SYNACK | ACK” existiu e conforme manda o “figurino”, seguindo o que manda o protocolo. Agora, o encerramento:

  1. Linha 428: Cliente envia um segmento com flags FIN e ACK setadas; o comando quit/exit/bye (depende do software FTP) foi digitado no cliente;
  2. Linha 429: Segmento de ACK do servidor (fechamento passivo);
  3. Linha 457: Segmento FIN/ACK do servidor (3a via do procedimento padrão de fechamento).

As linhas 458 e 459 contém um segmento (RST) enviado pelo cliente, que provavelmente não possuia mais recursos alocados à conexão, em resposta a segmentos anteriores, oriundos do servidor.

As linhas 458 e 459 contém um segmento (RST) enviado pelo servidor, que provavelmente não possuia mais recursos alocados à conexão, em resposta a segmentos anteriores, oriundos do cliente.

Vale aqui uma citação do Tanenbaum[2]: “Apesar das conexões TCP serem full-duplex, fica mais fácil compreender como as conexões são encerradas se as considerarmos um par de conexões simplex. Cada conexão simplex é encerrada de modo independente de sua parceira. Para encerrar uma conexão, qualquer dos lados pode enviar um segmento com o bit FIN ativado, o que significa que não há ma is dados a serem transmitidos.”

Diferentemente do padrão adotado para estabelecer uma conexão TCP, o encerramento desta possui número variável de vias. No entanto, o comportamento padrão utiliza de 4 vias, ou seja, um ACK para cada FIN a paartir de cada lado. (autores podem discordar quanto ao mais comum, mas não quanto ao padrão do protocolo)

[85] Trata-se de uma sessão FTP de controle, na qual o cliente
realizou três tentativas malsucedidas de se autenticar no
servidor e foi desconectado por este.

O protocolo FTP usa duas conexões TCP paralelas para efetuar comandos e transferência de dados: conexão de controle e conexão de dados. Os comandos FTP utilizados na sessão exposta foram: USER, PASS, SYST e QUIT. Esses não exigem uma conexão de dados para serem executados, o que está de acordo com a primeira parte “Trata-se de uma sessão FTP de controle”.

Além disso, ao analisar o cenário proposto, percebe-se que o comando (FTP) PASS é o comando que envia a senha ao servidor para autenticação, logo, para validar o restante da questão, deveremos verificar se existem 3 comandos desse tipo, além de 3 respostas do servidor (host B) com mensagens de falha de autenticação. Estas situações confirmam-se ao percebermos 3 ocorrências da mensagem de retorno 530 “Login Incorrect” (servidor) logo após os respectivos comandos de autenticação USER/PASS (cliente).

Observação: este item teve gabarito alterado, o que nos leva a crer que a última parte pode ter gerado controvérsia, visto que a conexão foi terminada pelo servidor passivamente (o FIN inicial veio do cliente).

[86] Com exceção dos segmentos TCP usados para estabelecer e
fechar a conexão, todos os outros segmentos carregam uma
quantidade não nula de bytes de dados.

As últimas duas linhas do trecho (458 e 459) não mais têm a ver com o encerramento da conexão, além disso, esses pacotes ‘RST’ não possuem dados.

Mandem seus comentários! Até a próxima.

Gabarito: 82-E  83-C  84-C  85-C(definitivo)  86-E

Links / Referências:

[1] Rede de Computadores e a Internet, Kurose
[2] Redes de Computadores, Tanenbaum
[3] TCP/IP Illustrated, Stevens
[4] File Transfer Protocol, RFC 959

Posted in Forense, Prova 2004 NAC, Questões Cenário, Redes | 5 Comments »