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.331 ]

Por: cilmar em 14/02/2008


Evolução e meios de inserção



Observa-se, na evolução dos Rootkits, constantes comentários referenciando System Calls, pois pode-se afirmar que a mesma representa chamadas de sistema, ou seja, é o mecanismo usado por um programa para requisitar um serviço do sistema operacional, para ser mais especifico pode-se ainda dizer que ela faz requisições ao núcleo ou Kernel do sistema operacional.

A partir de então, com conhecimento eminente sobre níveis de memória, execução de processos e Kernel, códigos extremamente capciosos passaram a ser projetados ou elaborados e junto a eles, também ataques a servidores webs, até então conceituados, passaram a ser rotina comum a conhecedores deste tipo de software. Dentre os vários códigos desenvolvidos alguns tiveram seu conceito elevado pela forma com que se tornavam eficientes após integrarem-se ao Kernel dos sistemas.

A McAfee, uma das maiores produtoras de software antivírus do mundo, expõe uma explicação um pouco diferenciada sobre os Rootkits, dividindo-os em dois grupos: os Rootkits de modo usuário, e os Rootkits de modo Kernel, ambos com grandes particularidades em sua execução quando no sistema, todavia o Rootkit modo usuário não tem permissões no mesmo nível do Rootkit de Kernel, mas pode-se dizer que:

[...] sua eficácia depende de sua capacidade de ocultar-se de programas de varredura antivírus e outras ferramentas de segurança. O cavalo de Tróia Adclicker-BA3, com maior capacidade de ocultação, intercepta todos os processos em execução para essa finalidade. Essa tática, porém, pode não funcionar sempre. [...]

(Em: http://www.mcafee.com/us/local_content/white_papers/whitesheet_r4_br.pdf)

Alguns Rootkits em modo usuário se utilizam de APIs (Interface de programação de aplicativo) para carregar uma DLL (Biblioteca de ligação dinâmica) no espaço de memória, que em seguida será executada junto ao processo Porém ele não necessita ser executado dentro deste mesmo espaço alocado. Na sua maioria os Rootkits em modo usuário também se utilizam de ferramentas de desenvolvimento e depuradores o que o torna ainda mais eficiente em sua tarefa, já que o simples fato de identificar mudanças em DLLs ou espaços de memória pode não significar a presença de um Rootkit.

Já os Rootkits de modo Kernel por sua vez, se utilizam de aplicativos que trabalham a baixo nível para alocar-se no núcleo do sistema, estes dispositivos podem ser Drivers de dispositivos do sistema operacional ou programas antivírus, isso faz com que muitas chamadas APIs sejam interceptadas, tornando-os muito semelhantes aos de modo usuário, contudo seus privilégios de execução são bem mais elevados.

A simples presença de vulnerabilidades nos sistemas de informação faz com que Rootkits evoluam a fim de atingir os objetivos expressados em forma de códigos por um programador, sucessivamente sua ascensão fica grifada a cada geração e a cada forma pelo qual ele age no Kernel dos sistemas. Notadamente alguém e por algum motivo coloca um Rootkit em ação, mas como ele pode ser anexado ao Kernel? Uma das formas, e com certeza também a mais explorada para inclusão, é a técnica que estuda a vulnerabilidade dos aplicativos.

No Windows, por exemplo, os processos se utilizam de diferentes meios para a comunicação. Além de muitos liberarem portas para comunicação com o meio externo, seja para comunicação com uma base de dados, seja para um simples update, nesse meio não se sabe até que ponto a codificação de um software é confiável e muito menos se a porta liberada continuará aberta ou sendo visada externamente. Nesse caso, Threads (linhas de processamento) podem entrar em ação e provocar o acionamento de diferentes softwares na tentativa de provocar o temido Overflow ou estouro de buffer como também é conhecido, isso ocorre após a memória secundaria receber informações além de sua capacidade.

Outro meio para a infiltração de Rootkits, e este não menos importante, é realizado através da mudança de endereços de tabelas durante a importação de dados ou sincronismo de sistemas, durante a execução de um programa, chamadas de APIs são realizadas podendo fazer requisições a bibliotecas externas pela edição da tabela IAT (tabela importada do endereço) que gera ponteiros em linguagem Assembly. O Rootkit pode entrar em modo operacional sempre que a API relacionada for interceptada ameaçando qualquer núcleo operacional.

Uma interceptação por funções em linhas também foi apontada pela McAfee, esta também é conhecida como função desvio e descrita da seguinte forma pela empresa:

[...] difere da IAT por redirecionar a chamada para o código do hacker modificando-o quando o código real se encontra nas principais DLLs de sistema. O rootkit modifica somente os primeiros bytes da função dentro as principais DLLs de sistema (kernel32.dll e ntdll.dll) colocando uma instrução para que quaisquer chamadas de processos passem primeiro pelo rootkit. o código do rootkit verifica se os parâmetros indicam a necessidade de falsificar resultados e, em seguida, responde de maneira apropriada. [...]

(Em: http://www.mcafee.com/us/local_content/white_papers/whitesheet_r4_br.pdf)

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

Mudança de hábito: autenticando usuários em base de dados MySQL

Race condition - vulnerabilidades em suids

Entendendo o ataque ARP spoofing + SSLStrip

IPtables e seus módulos

Como saber se houve uma invasão

  
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