PCF-3

Questões comentadas, artigos e notícias

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

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

 
%d blogueiros gostam disto: