Rootkit: Uma nova ameaça?

Desenvolvimento, evolução, formas de inserção, principais ataques entre outras características dos Rootkits são abordados no artigo referenciado. Trabalho acadêmico realizado sob orientação do prof. Marcelo Riedi - Unipar.

[ Hits: 50.361 ]

Por: cilmar em 14/02/2008


Três gerações



Na primeira geração dos rootkits, foi enfatizada a manipulação de comandos dos sistemas operacionais, mudanças que atribuíam funções diferenciadas ou inadequadas ao comando original. Durante um considerável período essas manipulações foram consideradas eficientes aos olhos dos desenvolvedores dos malwares, porém, uma atitude satisfatória também foi aderida pelos programadores e administradores de sistemas.

Essa atitude implantava sistemas auditores nos comandos e programas que compunham o Kernel, eles procuravam atuar baseado na data de modificações dos comandos e tamanho dos arquivos, o que acabou inibindo e impedindo a atuação desse tipo de rootkit. Um exemplo clássico da atuação desse tipo de malware foi descrito por MARCELO, A. (2003) no livro Segurança em Linux, o qual procurou detalhar a atuação de um Rootkit, este modificava o comando ifconfig, fazendo com que as interfaces de redes atuassem em promiscuidade, captando dessa forma tudo o que circulava na rede. O autor ainda comparou a essa situação com um sniffer, que tem praticamente a mesma função, ou seja, aplica o modo promiscuo a um equipamento que tenha características semelhantes a uma interface de rede.

As System Calls foram os principais alvos dos Rootkits, durante a segunda geração, já que elas compõem partes importantes dos módulos do sistema. Um ataque às System Calls provocava enorme mudança nas funções do Kernel, dentre elas destacava-se: transformações das quais os processos não eram mais visíveis, embora estivessem em processamento, e outros como mudanças no comando mkdir (este é responsável pela criação de diretórios), muito utilizado em ambientes LINUX/UNIX.

Na terceira geração dos Rootkits os endereçamentos de memória foram explorados, e através deles obteve-se mais uma grande evolução dos Rootkits, a que passou a ser chamada de Suckit:

Ele é um rootkit completamente funcional que é carregado via /dev/kmem. Ou seja, ele não precisa de um kernel com suporte a módulos carregáveis do kernel. Ele possui um shell para acesso remoto protegido por senha, iniciado por um pacote com spoof (passando pela maioria das configurações de firewall) e pode esconder processos, arquivos e conexões. (Em: http://www.debian.org/News/2003/20031202.pt.html)

Geralmente o Suckit é rodado na inicialização do sistema como /sbin/init (diretório responsável pela inicialização dos arquivos binários do Linux) adquirindo PID (Identificação de Processo) 1, onde inicia uma backdoor ( também conhecida como porta dos fundos, é na verdade uma porta de comunicação oculta, que pode dar acesso ao invasor, ela pode ser criada por um usuário ou por uma aplicação) e uma cópia do binário init original, execuções posteriores são redirecionadas a partir de então ao original, facilitando sua ocultação no Kernel.

O Linux possui um diretório /dev/kmen e outro /dev/men, ambos com privilégio de gravação fornecido somente ao Root, onde o primeiro tem a função de endereçar a memória virtual mais swap, que posteriormente é transformada em memória real. Esses diretórios se fizeram alvos da terceira geração dos Rootkits, onde a idéia era, através dos arquivos reportados neles, formar uma System Calls própria, onde os arquivos são comparados e reescritos no Kmen. Técnica extremamente funcional e criativa que teoricamente foi vista como irreparável, porem a estratégia de auditoria conseguiu superar mais uma vez este recurso, já que os aplicativos instalados no sistema geram diretórios próprios e com diferentes funções, acessos e links utilizados pelo sistema também passaram a serem monitorados com mais precisão a partir daí.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Desenvolvimento ao longo da História (1)
   3. Desenvolvimento ao longo da História (2)
   4. Três gerações
   5. Evolução e meios de inserção
   6. Alvos dos Rootkits
   7. Aplicação dos Rootkits
   8. Conclusão
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Implementando segurança no SSH

Instalação do Snort + BASE no Debian Etch pelos fontes

Ping - O que há por trás?

Malware, Vírus e Hacking. Estamos seguros usando Linux?

Criando um repositório criptografado de dados com Cryptsetup (dm-crypt) sem (re)particionamento do HD

  
Comentários
[1] Comentário enviado por kalib em 14/02/2008 - 12:18h

Parabéns pelo excelente artigo meu caro....
Uma ótima abordagem dinâmica e completa sobre rootkits...
Realmente são uma preocupação constante para nós que administramos redes e servidores...
Principalmente com a enorme quantidade de scriptkids a solta por aí não é mesmo?! dá raiva.. hauhauha

Obrigado pela ótima contribuição amigo. ;]

[2] Comentário enviado por marcosmiras em 14/02/2008 - 14:52h

Muito show... legal mesmo...
Realmente Kalib, uma grande preocupação mesmo...

[3] Comentário enviado por denis.roschel em 14/02/2008 - 15:19h

Depois de uma extensa leitura, só posso dizer, PARABÉNS!!!
Muito explicativo e didático!

[4] Comentário enviado por Bique em 14/02/2008 - 16:41h

Parabens pelo artigo.

[5] Comentário enviado por alcarrolikis em 14/02/2008 - 17:44h

Ótimo artigo cilmar_oliveira.

Fazendo a diferença...

Vlw.

[6] Comentário enviado por exercitobr em 15/02/2008 - 08:55h

Show! Sem comentários!

[7] Comentário enviado por juliocm em 16/02/2008 - 19:49h

olá Colega você fala que a máfia Russa foi o núcleo, mas posso lembrar que aqui n oBRASIL existem a maioria! Aki no Brasil estão presentes os desenvolvedores de rootkit e os usuários de rootkit, sabe!
Bem, se alguém quiser posso liberar meu CD completinho pra uso! mas não me responsabilizo do uso incorreto!

[8] Comentário enviado por removido em 16/02/2008 - 20:55h

mukto bom esse esclarecimento, principalmente para mim que estou começando a entender de verdade o funcionamento de um SO...
valeu!!!

[9] Comentário enviado por Teixeira em 16/02/2008 - 21:31h

Gostei imensamente do artigo, bastante abrangente e direto.

Agora gostaria de perguntar:

1 - Qual a real possibilidade de conseguirmos essa espécie de malware em ambiente linux desktop?

2 - Há (também em desktop) a possibilidade de modificarmos o kernel sem ter que recompilá-lo?



[10] Comentário enviado por nicolo em 17/02/2008 - 13:02h

Cara , isso é de arrepiar os cabelos. Os caras entraram nos sites de grandes distros e bancos e reduziram a segurança do Linux (do windows também) a pó.

[11] Comentário enviado por engos em 18/02/2008 - 13:30h

cilmar_oliveira:
Trabalho desenvolvendo uma das primeiras soluções no mundo de firewall para aplicações onde o conceito é justamente ajudar que alguns ataques, como os de sniffers reportados, sejam interceptados e tratados sem possibilitar "vazar" as informações, por isso tenho um conhecimento bem interessante sobre o assunto e segurança em geral e mesmo assim devo confessar que fiquei impressionado pela qualidade de seu trabalho, apesar de ser uma visão bem macro do assunto, você soube exatamente como conduzir o trabalho e fez uma pesquisa muito interessante, parabéns!

Teixeira:
1 - Existem vários bugs relatados diariamente com relação a programas, ou até mesmo com o kernel que podem ser facilmente explorados.

Alem disso existem malware que se utilizam de phishing scan, sql injection, crossover script.... E a lista vai longe, isso tudo sem contar os famosos DoS, fazendo o sistema operacional ser indiferente, bastando apenas saber como explorar cada sistema, o que é bem simples dependendo das informações que você tiver.

2 - Somente se você instalar um novo kernel já modificado... É até mais simples do que parece conseguir fazer isso sem deixar rastro algum, uma vez conectado ao sistema, mas o grande problema são os bugs encontrados no Kernel que permitem acesso total para quem sabe explorar as falhas já relatadas, por isso sempre se deve ter um kernel recente e quando se trata de um ambiente que necessita de um monte de homologações (como banco por exemplo) esse processo é lento e pode ficar exposta essa falha dependendo de como é a segurança como um todo.

Claro que isso é bem mais complicado o que torna o linux um sistema muito mais seguro do que uns sisteminhas que tem a "janela" aberta pra qualquer "ladrão" entrar...


nicolo:
Segurança é algo tão complicado que nem precisa "vir de fora", para você ter uma idéia como isso é complicado, fui comprar passagens da TAM nesse sabado a noite, para aproveitar as promoções noturnas, e quando encontrei os preços que queria fui efuar a compra, mas quando estava no processo acabou o horário de verão e de 24h passou para 23h, com isso o site da TAM simplesmente CAIU MAIS RAPIDO QUE OS AVIÕES DELES!

O pior, o erro não era tratado e dava um monte de informações sobre o sistema deles que com um pouquinho de má fé qualquer programador experiente poderia ter acesso a informações que não deveriam.

Infelizmente a política de desenvolvimento ainda é muito infantil com relação a segurança quando se trata principalmente de aplicações.

[12] Comentário enviado por Osirix em 24/10/2008 - 12:07h

Não tenho palavras .. pro seu artigo..^^

ele estar simplesmente otimo !!!!!!! ..



[13] Comentário enviado por manhaes em 17/09/2009 - 01:24h

Excelente, de grande valia para profissionais em diversos setores, parabens!!!!!

Manhaes

[14] Comentário enviado por albfneto em 18/06/2011 - 19:13h

o artigo é ótimo, um especialista no assunto.


Contribuir com comentário