Rootkit: Uma nova ameaça?

[helldanger1]

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.

Por: cilmar


Introdução
No desenvolvimento deste trabalho, serão abordadas informações sobre o funcionamento dos Rootkits, a sua história de desenvolvimento, componentes do Kernel modificados por um Rootkit, além de suas diferentes visões e atuações durante suas gerações.

Atualmente eles ainda perturbam muitos administradores de sistemas, ou mesmo qualquer profissional que possa atuar na área de segurança da informação, levando em consideração que, na sua maioria, os Rootkits são Malwares que comprometem ou o núcleo dos sistemas, ou simplesmente determinados comandos. Um Rootkit geralmente atua de forma invisível, ocultando, na maioria das vezes, um usuário com perfil e privilégios administrativos.

Este artigo também aborda a forma pela qual o Rootkit se integra no kernel do sistema, e, posteriormente, apresenta exemplos de códigos e os responsáveis por sua elaboração.

Um Rootkit pode causar ou não danos ao sistema operacional, sejam eles sistemas de distribuição livre, ou com direitos autorais reservados aos fabricantes, porém algumas formas de prevenção são fáceis de serem adotadas, e junto a elas um considerável aumento nas regras de segurança da organização ou corporação na qual um profissional de informática e tecnologia da informação atua.

No entanto é necessário conhecer de que forma age um Suckit ou Rootkit, para que se saiba utilizar um Chkrootkit ou ferramenta semelhante, desta forma o profissional vai estar apto a trabalhar e defender-se, mesmo depois de identificar um Rootkit em seu sistema.

Os termos descritos na estrutura do trabalho, por vezes, designam um assunto pouco explorado por acadêmicos e até mesmo por profissionais de segurança da informação, todavia o conhecimento destes equivale ao nível de segurança aos quais se deseja implantar em uma organização informatizada.

 

[helldanger1]

Desenvolvimento ao longo da História (1)


Primeiramente, um Rootkit é um software alocado no núcleo ou kernel do sistema operacional, ocultando-se de softwares antivírus e liberando portas de comunicação do sistema operacional, podendo também, de forma menos freqüente, alterar comandos e funções do sistema. Isso o classifica como maléfico aos sistemas de informação e também faz com que termos como malware e trojan tenham de alguma forma ligação com Rootkits.

O termo rootkit é usado para descrever os mecanismos e as técnicas por meio dos quais o malware, inclusive vírus, spywares e cavalos de Tróia, tentam ocultar sua presença dos anti-spywares, antivírus e utilitários de gerenciamento do sistema. Há várias classificações de rootkit que dependem da sobrevivência do malware à reinicialização e de sua execução nos modos usuário ou kernel.

Uma abordagem mais detalhada sobre sistemas operacionais e Kernel, contribui relevantemente para a compreensão e funcionamento de um Rootkit. Um conjunto de programas e rotinas forma um sistema operacional, e este, por sua vez, é responsável pela interação do usuário com o hardware; sistemas operacionais são aperfeiçoados, implementados e são classificados de três maneiras: a) pelo Kernel; b) pelo método o qual adotam para gerenciar programas e, c) pelo número de usuários que podem operá-lo de forma simultânea.

No início da era da informatização, ainda quando o os sistemas operacionais enfrentavam muitos processos de estruturação e constantes mudanças, até mesmo pela insatisfação e dificuldade de aceitação que causavam aos usuários, o termo Kernel foi visto como jargão da informática e era conhecido somente por estudantes de grandes universidades ou programadores da época. Com o surgimento do sistema operacional LINUX, o Kernel tornou-se comum, principalmente para usuários de LINUX/UNIX:

Ele pode ser visto como uma interface entre os programas e todo o hardware. Cabe ao Kernel a tarefa de permitir que todos os processo sejam executados pela CPU e permitir que estes consigam compartilhar a memória do computador.

A partir da criação do ambiente LINUX, elaborado por Linus Torvalds, finlandês, estudante de Ciência da Computação, que implementou uma versão projetada por Andy Tannenbaum, conhecida como Minix, originou-se a primeira versão do Kernel do LINUX, e junto à mesma. Outros termos como Root, Módulos, Multiprocessamento, entre outros utilizados constantemente na área de tecnologia e informática deixaram de ser novidades ou dedicados apenas a especialistas.

O nome Rootkit teve sua origem fundamentada na junção das palavras Root e Kit, sendo Root o usuário administrador do sistema, em ambiente LINUX e UNIX e Kit um componente de ferramentas utilizadas para atuarem como backdoor, comprometendo dessa forma a arquitetura do ambiente operacional.

As primeiras ferramentas Rootkits objetivavam disfarçar programas e fazer com que estes atuassem como arquivos do sistema, dando possibilidade ao roubo de informações além de acesso não autorizados, as quais também permitiam que tudo fosse desabilitado quando uma possível detecção da sua existência fosse observada.

 

[helldanger1]

Desenvolvimento ao longo da História (2)


Os Rootkits tiveram um avanço considerável em 2001, com a publicação de um artigo pela revista Phack. O mesmo descreve como modificar funções do kernel sem levantamento dos módulos; eles eram alterados na raiz sem a possibilidade de detecção, onde Marcelo (2003) postula que:

Esta ferramenta se tornou o estado da arte, já que não havia como detectá-la mediante os processos já utilizados por programas de segurança, que localizavam e neutralizavam seus antecessores. Uma das medidas que foram tomadas para desenvolver uma maneira de detectar essa ferramenta foi a tentativa de auditar qualquer modificação em arquivos/diretórios do sistema, já que, ao criar os programas de execução do rootkit, o mesmo necessita colocar seus arquivos no sistema. (MARCELO, A. 2003, p. 46).

A partir do ocorrido, auditar o Kernel dos sistemas foi uma solução quase que obrigatória para todos os administradores de sistemas informatizados. Durante esse período, os problemas relacionados à tecnologia e segurança voltada para os Rootkits ainda não haviam sido totalmente controlados, vitimando ainda assim vários sistemas, haja vista que na maior parte dos documentários que discorrem a respeito de qualquer explicação sobre Rootkits, geralmente atribui-se o termo Malware aos mesmos. O termo em citação faz referencias a softwares com intuito de prejudicar e danificar o sistema operacional, embora esse termo relacione-se melhor com Vírus e Trojans.

Para uma melhor compreensão dos Rootkits, uma apresentação adequada sobre o seu funcionamento em diferentes gerações traz grandes contribuições para os profissionais da área de Tecnologia de Informação. Suas principais características foram descritas basicamente em três gerações, conforme discorre Marcelo (2003, pp. 45-50) onde se caracterizavam as diferentes formas de atuação dos Rootkits no Kernel do sistema, com ênfase nesse período ao ambiente LINUX/UNIX.

 

[helldanger1]

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.
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í.

 

[helldanger1]

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)

 

[helldanger1]

Alvos dos Rootkits



Com performance de códigos ainda melhores e mais eficientes depois dos últimos avanços descritos pela McAfee os Rootkis não necessitavam optar por alvos menos protegidos, bastavam algumas técnicas que de alguma forma levassem o seu desenvolvedor até o kernel do sistema, um sniffer, por exemplo, utilizado para capturar senhas em uma rede. A capacidade de um sniffer de agir em diferentes protocolos e interceptar diferentes pacotes torna o Hacker ou na maioria das vezes um Cracker apto a ter acesso a senhas de servidores e desktops depois que sua implantação for executada com êxito em uma organização computacional.

Desta forma servidores da organização Debian.org, responsável pela manutenção do sistema operacional Debian foram invadidos, neles foram implantados o Rootkit SucKIT como documentado e relatado pela própria empresa:

Na madrugada (GMT) de quinta-feira, 20 de novembro, a equipe de administração notou vários oopses do kernel no master. Uma vez que o sistema estivera rodando sem problemas por um longo tempo, a máquina estava próxima de ser levada para manutenção e para investigação aprofundada sobre possíveis problemas de hardware. No entanto, ao mesmo tempo, um segundo computador, murphy, estava passando por exatamente os mesmos problemas, o que levantou suspeitas dos administradores.

Investigações posteriores revelaram que a causa de ambos os problemas era o root-kit SucKIT (1.3b). Ele inclui sniffing de senhas e capacidade de evasão de detecção (ferramentas para esconder processos e arquivos) que são instalados diretamente no kernel, o que causou os oopses que foram notados.

O Ataque ao servidor Debian serviu de inspiração a usuários de Rootkits, já que uma vulnerabilidade identificada podia demorar alguns dias para estar presente em todos os servidores, além disso, algumas empresas não realizam todas as atualizações as quais o sistema operacional necessita. Dias depois do incidente com a Debian.org um novo ataque foi realizado aos servidores da Gentoo, uma importante organização de software livres, o mesmo foi noticiado da seguinte forma:

A notícia do comprometimento do servidor Gentoo foi dada logo após a retirada do ar do site do Savannah, um servidor da Free Software Foundation usado para desenvolvimento de projetos da fundação. O sistema foi atacado no dia 2 de novembro deste ano, mas o comprometimento só foi descoberto nesta semana. Segundo o anúncio oficial divulgado, o ataque é semelhante ao sofrido pelos servidores do Projeto Debian em novembro.

O atacante usou o rootkit (ferramenta que, instalada na primeira invasão, permite que o atacante volte a entrar na máquina sem ser detectado) "SucKIT" para obter acesso às máquinas como "root. A extensão dos danos do ataque ainda não foi divulgada, nem mesmo se sabe se os arquivos do Savannah foram alterados ou danificados durante o período.



Porém, ataques maliciosos com Rootkits não se restringiu apenas a distribuições de código aberto como Linux, importantes servidores da Microsoft também são alvos de Rootkits, e estes ainda mais precisos por parte dos atacantes, o Rootkit designado a ambiente Windows foi ainda mais eficiente quanto a sua função, tanto que ataques chegavam a levar mais de um ano para serem descobertos, causando dessa forma inúmeros problemas à administradores de sistema e consequentemente comprometendo as empresas:

Os atacantes, supostamente membros da máfia russa, usaram para infectar os clientes do banco o trojan/rootkit Haxdoor.KI. O Haxdoor instala um driver em modo kernel (xdpptp.sys), que é chamado mesmo se o sistema for iniciado em safe mode, que esconde o backdoor executado em modo usuário (xopptp.dll). Este backdoor realmente toma conta da máquina infectada:
Captura senhas de usuário e informação pessoal manipulada pelos mais diversos programas - MSN Messenger, Opera, Outlook, IE, Firefox, ICQ e outros - bem como qualquer senha enviada via POP3 ou IMAP. As senhas são enviadas para uma página no domínio skynet.info, usando um POST HTTP.
Escuta a porta TCP 16661 e executa comandos remotos. A funcionalidade implementada pelo backdoor é bem extensa, e vai desde fazer o upload de um arquivo para o hacker até iniciar um proxy HTTP na porta TCP 8008. Permite também comandar o rootkit para esconder arquivos adicionais, e abrir e fechar a porta do drive de CD.
Abre um shell remoto na porta TCP 16016.
Bloqueia sites de antivírus, desabilita serviços de proteção da máquina, etc. (...) [...] o banco somente descobriu o ataque 15 meses depois deles terem sido iniciados, quando os atacantes perderam a vergonha e começaram a fazer grandes transações usando as informações roubadas. Antes disso os atacantes faziam uma série de pequenas transações, e provavelmente poderiam continuar fazendo até hoje sem serem descobertos.


Mesmo após a identificação e correção dos sistemas operacionais incidentes como esses não deixavam de acontecer, entretanto medidas drásticas passaram a serem tomadas pelos profissionais de TI, algumas delas restringiam até o acesso à Internet, outras optaram por liberarem apenas domínios tidos como seguros e necessários à política da empresa.

 

[helldanger1]

Aplicação dos Rootkits


Ataques desse porte causaram prejuízos imensos a diferentes corporações, além de tornarem domínios por vezes vistos como impenetráveis em alvos fáceis à Rootkits. Com base nestes fatos, não ouve outra forma a não ser conhecer o código do mesmo a ponto de saber a função de cada linha descrita no Rootkit.

Contudo, o que não se esperava é que empresas adotassem os Rootkits como meio de defesa, o que provocou imensa instabilidade no mercado de sistemas operacionais, já que o sistema não podia ser preparado para defender-se ou ao menos identificar um possível Malware. Pior ainda era não saber descrever se o software poderia ser considerado um Malware, haja vista que, nesse caso, o Rootkit poderia ate ser benéfico.

Não foi o caso do Rootkit produzido pela multinacional Sony BMG. A mesma objetivava produzir um código que impedisse a cópia pirata ou reprodução indevida dos seus CDs. O fato ficou conhecido internacionalmente e o que o levou a conquistar o nono lugar no site Associação Software Livre Paraná - ASL-PR - Notícias, que classifica os 10 maiores escândalos da Web:

O Dia das Bruxas de 2005 foi especialmente assustador para a Sony BMG Music. Na data, o técnico da Microsoft Mark Eussinovich colocou um post curioso em seu blog relatando que enquanto fazia uma varredura em seu HD, havia descoberto um rootkit - ferramenta utilizada por hackers para mascarar a presença de malware - advindo de um CD da gravadora.

O escândalo tornou-se uma bola de neve conforme outros blogueiros entravam na onda e a grande mídia explorava a história. Primeiro, a Sony negou que seu software de proteção anti-cópia havia transformado meio milhão de PCs em um parque de diversões para hackers. Depois, lançou uma "correção" que, obviamente, não funcionou. Por fim, cedeu à pressão publica e propôs aos usuários desinstalar o kit e substituir os CDs - mas era tarde e a reputação da empresa já estava tão mal ou pior do que os discos-rígidos dos usuários.



O problema de repercussão mundial por sua vez não inibiu a outras organizações, as quais dedicaram profissionais com total exclusividade para estudar os Rootkits, mais uma vez o estudo foi até sua implantação como meio de devesa, ocasionando opiniões diversas sobre o assunto, já que desta vez empresas voltadas a área de segurança estavam aderindo aos códigos considerados maliciosos:

O mesmo especialista de segurança que, durante o final do ano passado, trouxe a público o uso de rootkits pela gravadora Sony BMG em seus CDs de música critica agora as empresas de segurança Symantec e Kaspersky por produzirem softwares que utilizam a mesma técnica escusa.

Mark Russinovich, arquiteto chefe de softwares na Winternals, diz que os métodos empregados pelo Norton SystemWorks, da Symantec, e Kaspersky Antivírus são idênticos aos de rootkits, um termo usualmente reservado a técnicas utilizadas por softwares maliciosos para impedir a sua detecção em um computador infectado.



Uma imagem negativa originou-se depois das ultimas noticiais, levantando duvidas sobre a verdadeira utilidade dos Rootkits e sobre seus criadores, por sua vez softwares com códigos totalmente analisados por programadores especializados na área de segurança da informação foram descritos como benéficos e classificados como seguros e Anti-Rootkit.

Criadores destes softwares foram incentivados a continuarem o trabalho levando posteriormente a área de segurança da informação a recuperar sua estabilidade. O ambiente Linux foi o primeiro a ser protegido. Neste caso, o software projetado foi o chkrootkit. Ele é implementado em ambientes Linux/Unix objetivando através das suas descrições sobre os comandos identificar pelas estruturas condicionais se o sistema esta ou não comprometido, o chkrootkit foi tão bem aceito que em pouco tempo uma Home Page foi construída e através dela muitos profissionais que utilizavam sistemas compatíveis puderam identificar a presença do Rootkit no kernel.

Sua construção se desencadeou por volta de 1997 a qual já dispunha de métodos de investigação forenses para investigação no kernel. Um exemplo a ser citado é a produção do script que avalia possíveis modificações no comando su, presente em todos os ambientes Linux/Unix:

 

[helldanger1]

chk_su () {
STATUS=${NOT_INFECTED}
SU_INFECTED_LABEL="satori|vejeta"
CMD=`loc su su $pth`
if [ "${EXPERT}" = "t" ]; then
expertmode_output "${strings} -a ${CMD}"
return 5
fi
if ${strings} -a ${CMD} | ${egrep} \
"${SU_INFECTED_LABEL}" > /dev/null 2>&1
then
STATUS=${INFECTED}
fi
return ${STATUS}
}

O script, segundo a produtora do Anti-rootkit, é muito funcional, porém pode sofrer problemas com relações às distribuições que diferem umas das outras. Neste código teste de cadeias modificadas por Rootkits é realizado, a _www.chkrootikit.org ainda explica sobre outros comandos que passam por verificação e auditoria, no entanto todos com o intuito de se identificar mudanças na função original e desta forma procurando-se identificar a presença de um possível malware. Ressalta-se ainda a criação de um repositório on-line com informações sobre Rootkits. Estes, serão usados pelo chkrootkit para melhorar ainda mais suas técnicas auditoras implantadas no kernel dos sistemas operacionais.

Atualmente, diversas empresas como Microsoft, Kaspersky, Symantec, McAfae entre outras, possuem mecanismos eficientes contra Rootkits, todavia isso não torna os Rootkits menos eficientes. Situações pertinentes a infiltrações dos Rootkits no kernel ainda são comuns, e algumas vezes elas por levarem o nome de Spyware, usuários pensam ser um simples vírus, isso contribui ainda mais para manifestações dos malwares, já que não há muita preocupação com relações a desktops.

Pesquisas avançadas sobre mecanismos de infecção de desktops estão sendo elaboradas:

A pesquisadora de segurança Joanna Rutkowska, conhecida por desfazer os mecanismos de segurança do Windows, promete demonstrar novas possibilidades de hackers invadirem o sistema operacional Windows Vista.

O treinamento promete demonstrar novos rootkits desenvolvidos para o Vista, além de debater sobre maneiras de derrubar sistemas e técnicas que a Microsoft provavelmente preferiria que o mundo não conhecesse.



Outras declarações observadas no site apontam também para Rootkits modernos, os quais se utilizam de recursos muito avançados provenientes de técnicas associadas ao uso de memória combinado com hardware.

 

[helldanger1]

Conclusão


Obtem-se na concretização do mesmo, um resultado positivo e relevante, com relação ao conhecimento aderido durante o estudo sobre os Rootkits, podendo assim expressar que: se a ferramenta for usada com intuito maléfico, pode por muitas vezes causar danos irreversíveis a qualquer sistema, ou simplesmente fornecer a um invasor dados e informações particulares da empresas ou qualquer outro usuário que esteja sofrendo a ação do mesmo.

Também se comprova a enorme eficiência dos Rootkits no desempenho da tarefa que lhe é confiada, os quais estão aptos a dominar ou ao menos prejudicar até mesmo sistemas operacionais utilizados na atualidade. E diante da pesquisa, é possível afirmar que a necessidade de constantes atualizações, não só de sistemas, mas principalmente de conhecimento e de informação pertinentes a Malwares, está aumentando gradativamente, à medida que novos codificados surgem. Tais fatos permitem afirmar que Rootkits não são simplesmente uma nova ameaça, e sim uma antiga ameaça por muitas vezes ignorada pela ausência de conhecimento em relação ao mesmo e na maioria das vezes desconhecida. É também notória a evolução dos Rootkits desde a sua criação até os dias de hoje, o que nos deixa um campo em aberto para novas pesquisas e descobertas em relação ao tema.