O que é um Rootkit?

O termo rootkit existe há mais de 10 anos. Um rootkit é um "kit" que consiste em programas pequenos e úteis que permitem que um invasor mantenha acesso a "root", o usuário mais poderoso em um computador. Em outras palavras, um rootkit é um conjunto de programas e códigos que permitem uma presença permanente ou consistente e indetectável em um computador.

Em nossa definição de "rootkit", a palavra-chave é "indetectável". A maioria das tecnologias e truques empregados por um rootkit são projetados para ocultar código e dados em um sistema. Por exemplo, muitos rootkits podem ocultar arquivos e diretórios. Outros recursos em um rootkit geralmente são para acesso remoto e espionagem, por exemplo, para cheirar pacotes da rede. Quando combinados, esses recursos fornecem um soco nocaute para segurança.

Os rootkits não são inerentemente "ruins", e nem sempre são usados ​​pelos "bandidos". É importante entender que um rootkit é apenas uma tecnologia. A intenção boa ou ruim deriva dos humanos que os usam. Existem muitos programas comerciais legítimos que oferecem gerenciamento remoto e até mesmo recursos de espionagem. Alguns desses programas usam sigilo. Em muitos aspectos, esses programas podem ser chamados de rootkits. A aplicação da lei pode usar o termo "rootkit" para se referir a um programa de back-door sancionado - algo instalado em um alvo com permissão legal do estado, talvez por ordem judicial. (Nós abordamos esses usos na seção Usos Legítimos de Rootkits mais adiante neste capítulo.) As grandes corporações também usam a tecnologia do rootkit para monitorar e fazer cumprir seus regulamentos de uso do computador.

Ao assumir a perspectiva do atacante, nós o orientamos através das habilidades e técnicas de seus inimigos. Isso aumentará suas habilidades na defesa contra a ameaça do rootkit. Se você é um desenvolvedor legítimo da tecnologia de rootkit, este livro irá ajudá-lo a construir uma base de habilidades que você possa expandir.

Por que existem rootkits?

Os Rootkits são uma invenção relativamente recente, mas os espiões são tão antigos quanto a guerra. Os rootkits existem pelos mesmos motivos que existem erros de áudio. As pessoas querem ver ou controlar o que outras pessoas estão fazendo. Com a enorme e crescente dependência do processamento de dados, os computadores são objetivos naturais.

Os rootkits são úteis somente se desejar manter o acesso a um sistema. Se tudo o que você quer fazer é roubar algo e sair, não há motivo para deixar um rootkit para trás. De fato, deixar um rootkit para trás sempre abre o risco de detecção. Se você roubar algo e limpar o sistema, você não pode deixar nenhum traço de sua operação.

Os Rootkits fornecem duas funções primárias: controle remoto e controle, e espionagem de software.

Comando e controle remoto

O comando e controle remoto (ou simplesmente "controle remoto") podem incluir controle sobre arquivos, causando reinicializações ou "Blue Screens of Death", e acessando o shell do comando (ou seja, cmd.exe ou / bin / sh). A Figura 1-1 mostra um exemplo de um menu de comando do rootkit. Este menu de comando irá dar uma idéia dos tipos de recursos que um rootkit pode incluir.

Efeituação de software

O espionagem de software é tudo sobre ver o que as pessoas fazem. Isso significa cheirar pacotes, interceptar batidas de teclas e ler e-mails. Um invasor pode usar essas técnicas para capturar senhas e arquivos descriptografados, ou mesmo chaves criptográficas.

Cyberwarfare

Embora os rootkits tenham aplicações na guerra digital, eles não são a primeira aplicação do conceito.

As guerras são travadas em muitas frentes, e não menos importante é a economia. Desde o final da Segunda Guerra Mundial até a Guerra Fria, a URSS montou uma grande operação de coleta de informações contra os EUA para obter tecnologia. [7]

Tendo detectado algumas dessas operações, os Estados Unidos criaram planos, software e materiais falsos no canal de coleta. Em um incidente relatado, modificações maliciosas no software (os chamados "ingredientes extras") foram creditadas para uma explosão de gasoduto siberiano. [8] A explosão foi fotografada por satélites e foi descrita como "a mais monumental explosão não-nuclear e o fogo já visto do espaço". [9]

Usos legítimos de rootkits

Como já mencionamos, os rootkits podem ser usados ​​para fins legítimos. Por exemplo, eles podem ser usados ​​por agências de aplicação da lei para coletar provas, em uma operação avançada de erro. Isso se aplicaria a qualquer crime em que um computador seja usado, como transgressão de computadores, criando ou distribuindo pornografia infantil, software ou pirataria de música e violações de DMCA [10].

Rootkits também pode ser usado para combater as guerras. As nações e seus militares dependem fortemente de máquinas de computação. Se esses computadores falharem, o ciclo de decisão e as operações do inimigo podem ser afetados. Os benefícios do uso de um ataque de computador (versus convencional) incluem que ele custa menos, mantém os soldados fora de perigo, causa pequenos danos colaterais e, na maioria dos casos, não causa danos permanentes. Por exemplo, se uma nação bombardeia todas as usinas de energia em um país, então essas usinas de energia precisarão ser reconstruídas a grande despesa. Mas se um verme de software infecta a rede de controle de energia e desabilita-o, o país alvo ainda perde o uso da produção das usinas, mas o dano não é permanente nem caro.

Há quanto tempo os Rootkits foram?

Como observamos anteriormente, os rootkits não são um novo conceito. Na verdade, muitos dos métodos usados ​​nos rootkits modernos são os mesmos métodos utilizados nos vírus na década de 1980, por exemplo, modificando as principais tabelas do sistema, a memória e a lógica do programa. No final da década de 1980, um vírus poderia ter usado essas técnicas para se esconder de um scanner de vírus. Os vírus durante esta época usaram disquetes e BBS (sistemas de quadro de avisos) para espalhar programas infectados.

Quando a Microsoft introduziu o Windows NT, o modelo de memória foi alterado para que os programas de usuário normais não pudessem modificar as principais tabelas do sistema. Um lapso na tecnologia de vírus rígido seguiu, porque nenhum autor de vírus estava usando o novo kernel do Windows.

Quando a Internet começou a atrapalhar, dominou os sistemas operacionais UNIX. A maioria dos computadores usava variantes do UNIX e os vírus eram incomuns. No entanto, isso é também quando as redes de worms nasceram. Com o famoso Morris Worm, o mundo da informática despertou a possibilidade de explorações de software. [11] Durante o início da década de 1990, muitos hackers descobriram como encontrar e explorar os transbordamentos de buffer, a "bomba nuclear" de todas as façanhas. No entanto, a comunidade de escrita de vírus não alcançou quase uma década.

Durante o início da década de 1990, um hacker penetraria em um sistema, montaria o campo e depois usaria o computador recém-comprometido para lançar novos ataques. Uma vez que um hacker penetrou um computador, ela precisava manter o acesso. Assim, os primeiros rootkits nasceram. Esses rootkits originais eram meramente programas de backdoor, e eles usavam muito pouco stealth. Em alguns casos, eles substituíram binários do sistema chave com versões modificadas que esconderiam arquivos e processos. Por exemplo, considere um programa chamado ls que lista arquivos e diretórios. Um rootkit de primeira geração pode substituir o programa ls por uma versão de Trojan que esconde qualquer arquivo chamado hacker_stuff. Então, o hacker simplesmente armazenaria todos os seus dados suspeitos em um arquivo chamado hacker_stuff. O programa ls modificado manteria os dados a serem revelados.

Os administradores do sistema naquele momento responderam escrevendo programas como Tripwire [12] que poderiam detectar se os arquivos foram alterados. Usando nosso exemplo anterior, um utilitário de segurança como Tripwire poderia examinar o programa ls e determinar que ele havia sido alterado, e o Trojan seria desmascarado.

A resposta natural foi para os atacantes se moverem para o kernel do computador. Os primeiros rootkits do kernel foram escritos para máquinas UNIX. Uma vez que eles infectaram o kernel, eles poderiam subverter qualquer utilitário de segurança no computador naquele momento. Em outras palavras, os arquivos de Trojan não eram mais necessários: todo o sigilo pode ser aplicado modificando o kernel. Esta técnica não foi diferente das técnicas utilizadas pelos vírus no final da década de 1980 para se esconder do software anti-vírus.

Como funcionam os rootkits?

Os rootkits funcionam usando um conceito simples chamado modificação. Em geral, o software é projetado para tomar decisões específicas com base em dados muito específicos. Um rootkit localiza e modifica o software para que ele tome decisões incorretas.

Existem muitos locais onde as modificações podem ser feitas no software. Alguns deles são discutidos nos seguintes parágrafos.

Patching

O código executável (às vezes chamado de binário) consiste em uma série de instruções codificadas como bytes de dados. Esses bytes vêm em uma ordem muito específica, e cada um significa algo para o computador. A lógica do software pode ser modificada se esses bytes forem modificados. Essa técnica às vezes é chamada de patch, como colocar um patch de uma cor diferente em uma colcha. O software não é inteligente; faz apenas e exatamente o que é dito fazer e nada mais. É por isso que a modificação funciona tão bem. Na verdade, sob o capô, não é tão complicado. O patamar de bytes é uma das principais técnicas usadas por "crackers" para remover proteções de software. Outros tipos de patches de bytes foram usados ​​para trapacear em jogos de vídeo (por exemplo, para oferecer ouro ilimitado, saúde ou outras vantagens).

Ovos de Páscoa

As modificações da lógica do software podem ser "incorporadas". Um programador pode colocar uma porta traseira em um programa que ela escreveu. Esta porta traseira não está no design documentado, então o software possui uma característica oculta. Isso às vezes é chamado de ovo de Páscoa, e pode ser usado como uma assinatura: o programador deixa algo para mostrar que ela escreveu o programa. Versões anteriores do programa amplamente utilizado o Microsoft Excel continham um ovo de páscoa que permitia que um usuário achasse que ele jogasse um jogo de tiro em 3D em primeira pessoa, semelhante ao Doom [13] incorporado dentro de uma célula de planilha.

Modificações de Spyware

Às vezes, um programa irá modificar outro programa para infectá-lo com "spyware". Alguns tipos de trilha de spyware que os sites da Web são visitados pelos usuários do computador infectado. Como os rootkits, o spyware pode ser difícil de detectar. Alguns tipos de spyware se encaixam em navegadores da Web ou shells de programas, tornando-os difíceis de remover. Eles então tornam a vida do usuário infeliz, colocando links para novas hipotecas e Viagra em seus desktops e, em geral, lembrando-lhes que seus navegadores são totalmente inseguros. [14]

Modificação do código-fonte

Às vezes, o software é modificado na fonte - literalmente. Um programador pode inserir linhas maliciosas de código-fonte em um programa que ela autoriza. Essa ameaça causou algumas aplicações militares para evitar pacotes de código aberto como o Linux. Esses projetos de código aberto permitem que quase qualquer um ("qualquer um" seja "alguém que você não conhece") para adicionar código às fontes. Concedido, há uma certa quantidade de revisão por pares em código importante, como BIND, Apache e Sendmail. Mas, por outro lado, alguém realmente passa pelo código linha por linha? (Se o fizerem, eles não parecem fazer isso muito bem ao tentar encontrar buracos de segurança!) Imagine uma porta traseira que seja implementada como um erro no software. Por exemplo, um programador malicioso pode expor um programa a um estouro de buffer de propósito. Este tipo de porta traseira pode ser colocado de propósito. Uma vez que está disfarçado de bug, torna-se difícil de detectar. Além disso, oferece uma negação plausível por parte do programador!

Ok, podemos ouvir você dizendo "Bah! Eu confio plenamente em todas as pessoas desconhecidas que criaram meu software porque obviamente são apenas três graus de separação de Linus Torvalds [15] e eu confio em Linus com minha vida! "Tudo bem, mas você confia nas habilidades do sistema administradores que executam os servidores de controle de origem e os sites de distribuição de código-fonte? Existem vários exemplos de invasores que obtêm acesso ao código-fonte. Um grande exemplo desse tipo de compromisso ocorreu quando os servidores FTP raiz para o GNU Project (gnu.org), fonte do sistema operacional GNU baseado em Linux, foram comprometidos em 2003. [16] As modificações no código-fonte podem acabar em centenas de distribuições de programas e são extremamente difíceis de localizar. Até mesmo as fontes das ferramentas utilizadas pelos profissionais de segurança foram roubadas desta maneira. [17]

A legalidade da modificação de software

Algumas formas de modificação de software são ilegais. Por exemplo, se você usar um programa para modificar outro programa de forma a remover mecanismos de direitos autorais, você pode violar a lei (dependendo da sua jurisdição). Isso se aplica a qualquer software de "cracking" que possa ser encontrado na Internet. Por exemplo, você pode baixar uma cópia de avaliação de um programa que "expira" e pára de funcionar após 15 dias, depois baixe e aplique um "crack", após o qual o software será executado como se tivesse sido registrado. Essa modificação direta do código e da lógica de um programa seria ilegal.

O que um Rootkit não é

Ok, então descrevemos em detalhes o que é um rootkit e abordamos a tecnologia subjacente que torna possível um rootkit. Nós descrevemos como um rootkit é uma poderosa ferramenta de hackers. Mas, há muitos tipos de ferramentas de hackers: um rootkit é apenas uma parte de uma coleção maior. Agora é hora de explicar o que um rootkit não é.

Um Rootkit não é uma exploração

Rootkits pode ser usado em conjunto com um exploit, mas o próprio rootkit é um conjunto bastante simples de programas de utilidade. Esses programas podem usar funções e métodos indocumentados, mas geralmente não dependem de erros de software (como os desbordamentos de buffer).

Um rootkit geralmente será implantado após uma explicação de software bem-sucedida. Muitos hackers têm um tesouro de explorações disponíveis, mas eles podem ter apenas um ou dois programas de rootkit. Independentemente de qual exploração de um invasor usa, uma vez que ela está no sistema, ela implanta o rootkit apropriado.

Embora um rootkit não seja um exploit, ele pode incorporar uma explicação de software. Um rootkit geralmente requer acesso ao kernel e contém um ou mais programas que começam quando o sistema é inicializado. Há apenas um número limitado de maneiras de obter o código no kernel (por exemplo, como um driver de dispositivo). Muitos desses métodos podem ser detectados forensicamente.

] Uma nova maneira de instalar um rootkit é usar uma explicação de software. Muitas explorações de software permitem que o código arbitrário ou programas de terceiros sejam instalados. Imagine que existe um estouro de buffer no kernel (existem erros documentados dessa natureza) que permitem a execução de código arbitrário. Os desbordamentos do buffer do Kernel podem existir em quase qualquer driver de dispositivo (por exemplo, um driver de impressora). Após a inicialização do sistema, um programa de carregador pode usar o estouro do buffer para carregar um rootkit. O programa do carregador não emprega métodos documentados para carregar ou registrar um driver de dispositivo ou, de outra forma, instalar um rootkit. Em vez disso, o carregador explora o estouro do buffer para instalar as partes do modo kernel de um rootkit.

A exploração do buffer-overflow é um mecanismo para carregar o código no kernel. Embora a maioria das pessoas pense nisso como um bug, um desenvolvedor de rootkit pode tratá-lo como um recurso indocumentado para carregar o código no kernel. Como não está documentado, esse "caminho para o kernel" provavelmente não será incluído como parte de uma investigação forense. Ainda mais importante, não será protegido por um programa de firewall baseado em host. Somente alguém especializado em engenharia inversa avançada provavelmente descobrirá.

Um Rootkit não é um vírus

Um programa de vírus é um autômato de auto-propagação. Em contraste, um rootkit não faz cópias de si mesmo, e não tem uma mente própria. Um rootkit está sob o controle total de um invasor humano, enquanto um vírus não é.

Na maioria dos casos, seria perigoso e tolo que um invasor use um vírus quando ela exige sigilo e subversão. Além do fato de que a criação e distribuição de programas de vírus podem ser ilegais, a maioria dos programas de vírus e vermes são ruidosos e fora de controle. Um rootkit permite que um invasor permaneça no controle total. No caso de uma penetração sancionada (por exemplo, por aplicação da lei), o invasor precisa garantir que apenas determinados alvos sejam penetrados, ou então ela pode violar uma lei ou exceder o escopo da operação. Esse tipo de operação requer controles muito rígidos, e o uso de um vírus seria simplesmente fora de questão.

É possível projetar um programa de vírus ou sem-fim que se espalha através de explorações de software que não são detectadas por sistemas de detecção de intrusão (por exemplo, exploits de dia zero [18]). Tal sem-fim poderia se espalhar muito devagar e ser muito difícil de detectar. Pode ter sido testado em um ambiente de laboratório bem abastecido com um modelo do ambiente alvo. Pode incluir uma restrição de "área de efeito" para evitar que se espalhe para fora de um limite controlado. E, finalmente, pode ter um "temporizador de minas terrestres" que faz com que ele seja desativado após uma certa quantidade de tempo - garantindo que isso não cause problemas após a missão acabar. Discutiremos os sistemas de detecção de intrusão mais adiante neste capítulo.

O problema do vírus

Mesmo que um rootkit não seja um vírus, as técnicas usadas por um rootkit podem ser facilmente empregadas por um vírus. Quando um rootkit é combinado com um vírus, nasce uma tecnologia muito perigosa.

O mundo viu o que os vírus podem fazer. Alguns programas de vírus se espalharam por milhões de computadores em apenas algumas horas.

O sistema operacional mais comum, o Microsoft Windows, tem historicamente sido atormentado por erros de software que permitem que vírus infectem computadores pela Internet. A maioria dos hackers maliciosos não revelará erros de software para o fornecedor. Em outras palavras, se um hacker mal-intencionado encontrar um bug explorável no Microsoft Windows, ela não revelaria isso à Microsoft. Um bug explorável que afeta a instalação padrão da maioria dos computadores com Windows é como uma "chave para o reino"; Informar o vendedor sobre isso seria dar a chave.

Compreender a tecnologia do rootkit é muito importante para defender contra vírus. Os programadores de vírus têm usado a tecnologia do rootkit por muitos anos para "aquecer" seus vírus. Esta é uma tendência perigosa. Algoritmos foram publicados para propagação de vírus [19] que podem penetrar centenas de milhares de máquinas em uma hora. Existem técnicas para destruir sistemas informáticos e hardware. E, os furos remotamente exploráveis ​​no Microsoft Windows não estão indo embora. Os vírus que usam a tecnologia do rootkit serão mais difíceis de detectar e prevenir.

Rootkits e Exploits de Software

A exploração de software é um assunto importante relacionado aos rootkits. (Como o software pode quebrar e ser explorado não está coberto neste livro. Se você estiver interessado em exploração de software, recomendamos o livro Exploiting Software. [20])

Embora um rootkit não seja um exploit, ele pode ser empregado como parte de uma ferramenta de exploração (por exemplo, em um vírus ou spyware).

A ameaça dos rootkits é forte devido ao fato de que as explorações de software estão em grande oferta. Por exemplo, uma conjectura razoável é que, em qualquer momento, existem mais de uma centena de buracos exploráveis ​​trabalhando conhecidos na última versão do Microsoft Windows. [21] Na maior parte, esses buracos exploráveis ​​são conhecidos pela Microsoft e estão sendo gerenciados lentamente através de um sistema de garantia de qualidade e rastreamento de bugs. [22] Eventualmente, esses erros são corrigidos e silenciosamente corrigidos. [23]

Alguns pesquisadores independentes descobrem alguns erros de software exploráveis ​​e nunca foram informados ao fornecedor do software. Eles são mortais porque ninguém sabe sobre eles aceitar o atacante. Isso significa que há pouca ou nenhuma defesa contra eles (nenhum patch está disponível).

Muitas explorações conhecidas publicamente por mais de um ano ainda estão sendo amplamente exploradas hoje. Mesmo que haja um patch disponível, a maioria dos administradores de sistema não aplica os patches em tempo hábil. Isto é especialmente perigoso, pois, mesmo que não exista um programa de exploração, quando uma falha de segurança é descoberta, um programa de exploração é geralmente publicado dentro de alguns dias após a liberação de um aviso público ou um patch de software.

Embora a Microsoft leve os erros de software a sério, integrar as mudanças por qualquer grande fornecedor de sistemas operacionais pode demorar uma quantidade excessiva de tempo.

Quando um pesquisador relata um novo erro para a Microsoft, ela geralmente é convidada a não divulgar informações públicas sobre a exploração até que um patch possa ser lançado. A correção de erros é cara e leva muito tempo. Alguns erros não são corrigidos até vários meses depois de serem relatados.

Pode-se argumentar que manter os erros secretos incentiva a Microsoft a levar muito tempo para liberar reparações de segurança. Enquanto o público não sabe sobre um bug, há pouco incentivo para liberar rapidamente um patch. Para resolver esta tendência, a empresa de segurança eEye desenvolveu um método inteligente para tornar público o fato de que uma grave vulnerabilidade foi encontrada, mas sem liberar os detalhes.

Figura 1-2, que vem do site da eEye, [24] mostra um aviso típico. Ele detalha quando o bug foi relatado para um fornecedor e, por quantos dias o patch do fornecedor está "atrasado", com base no julgamento de que uma resposta atempada seria a liberação de um patch dentro de 60 dias. Como vimos no mundo real, os grandes fornecedores de software levam mais de 60 dias. Historicamente, parece que a única vez que um patch é lançado dentro de dias é quando um worm de Internet real é lançado que usa o exploit.

Figura 1-2 Método usado pelo eEye para "pré-lançar" um aviso de segurança.

Idiomas seguros por tipo

Os idiomas de programação que são tipo-seguros são mais seguros de determinadas explorações, como os desbordamentos de buffer.

Sem segurança de tipo, os dados do programa são apenas um grande oceano de bits. O programa pode pegar qualquer punhado arbitrário de bits e interpretá-lo de maneiras ilimitadas, independentemente da finalidade original dos dados. Por exemplo, se a seqüência "GARY" fosse colocada na memória, ela poderia mais tarde ser usada não como texto, mas como um inteiro de 32 bits, 0x47415259 (ou, em decimal, 1,195,463,257 - um número bastante grande de fato!). Quando os dados fornecidos por um usuário externo podem ser mal interpretados, as explorações de software podem ser empregadas.

Por outro lado, os programas escritos em uma linguagem tipo seguro (como Java ou C # [25]) nunca converteriam "GARY" em um número; A corda sempre seria tratada como texto e nada mais.

Por que as explorações ainda são um problema

A necessidade de segurança de software é conhecida há muito tempo, e as explorações de software continuam a ser um problema. A raiz do problema está no próprio software. Contudo, a maioria dos programas não é segura. Empresas como a Microsoft estão fazendo grandes avanços ao projetar uma melhor segurança para o futuro, mas o código atual do sistema operacional está escrito em linguagens C ou C ++, que, por sua própria natureza, criam graves obstáculos de segurança. Essas linguagens dão origem a um problema conhecido como explorações de buffer-overflow. O bug de buffer-overflow é a fraqueza mais significativa no software hoje. Foi o facilitador de milhares de explorações de software. E, é um bug - um acidente que pode ser consertado. [26]

As explorações do buffer-overflow irão eventualmente embora, mas não no futuro próximo. Embora um programador disciplinado possa escrever código que não tenha erros de buffer-overflow (isto é, independentemente do idioma, mesmo um programa escrito manualmente pode ser seguro), a maioria dos programadores não é tão diligente. A tendência atual é impor práticas de codificação seguras e acompanhar isso com ferramentas automatizadas de digitalização de códigos para cometer erros. A Microsoft usa um conjunto de ferramentas internas para esse fim. [27]

As ferramentas automatizadas de digitalização de códigos podem capturar alguns erros, mas não todos eles. A maioria dos programas de computador é muito complexa e pode ser difícil testá-los de forma automatizada. Alguns programas podem ter muitos estados para avaliar possivelmente. [28] Na verdade, é possível que um programa de computador tenha mais estados potenciais do que partículas no universo. [29] Dada essa potencial complexidade, pode ser muito difícil fazer qualquer determinação sobre a segurança de um programa de computador.

A adoção de linguagens tipo-safe (como Java e C #) quase eliminaria o risco de transbordamentos de buffer. Embora um idioma de tipo seguro não seja garantido para ser seguro, reduz significativamente os riscos de transbordamentos de buffer, erros de conversão de signos e excessos de números inteiros (veja a barra lateral na página 15). Infelizmente, esses idiomas não podem corresponder ao desempenho de C ou C ++, e a maioria do Microsoft Windows, mesmo a versão mais recente e melhor, ainda executa códigos C e C ++ antigos. Os desenvolvedores de sistemas embarcados começaram a adotar linguagens de tipo seguro, mas mesmo essa aceitação é lenta - e os milhões de sistemas legados lá fora não serão substituídos em breve. O que isso significa é que explorações de software antiquadas estarão por um tempo.

Tecnologias ofensivas de Rootkit

Um bom rootkit deve poder ignorar quaisquer medidas de segurança, como firewalls ou sistemas de detecção de intrusão (IDSes). Existem dois tipos principais de IDSes: baseado na rede (NIDS) e baseado em host (HIDS). Às vezes, os HIDS são projetados para tentar parar os ataques antes que eles tenham sucesso. Esses sistemas de "defesa ativa" às vezes são chamados de sistemas de prevenção de intrusão baseados em host (HIPSes). Para simplificar a discussão, nos referimos a estes sistemas como HIPS a partir de agora.

ANCAS

A tecnologia HIPS pode ser cultivada em casa ou comprada fora da prateleira.

Para o rootkit, a maior ameaça é a tecnologia HIPS. Um HIPS às vezes pode detectar um rootkit à medida que ele se instala e também pode interceptar um rootkit à medida que ele se comunica com a rede. Muitos HIPSes utilizarão a tecnologia kernel e podem monitorar sistemas operacionais. Em poucas palavras, HIPS é um anti-rootkit. Isso significa que tudo o que um rootkit faz no sistema provavelmente será detectado e interrompido. Ao usar um rootkit contra um sistema protegido por HIPS, existem duas opções: ignore o HIPS ou escolha um alvo mais fácil.

O capítulo 10 deste livro aborda o desenvolvimento da tecnologia HIPS. O capítulo também inclui exemplos de código anti-rootkit. O código pode ajudá-lo a entender como ignorar um HIPS e também pode ajudá-lo na construção de seu próprio sistema de proteção de rootkits.

NIDS

O IDS baseado em rede (NIDS) também é uma preocupação para os desenvolvedores de rootkit, mas um rootkit bem projetado pode evadir uma NIDS de produção. Embora, em teoria, a análise estatística possa detectar canais de comunicação secretos, na realidade isso raramente é feito. Conexões de rede para um rootkit provavelmente usarão um canal secreto escondido em pacotes de aparência inocente. Qualquer transferência de dados importante será criptografada. A maioria das implementações de NIDS lidam com grandes fluxos de dados (acima de 300 MB / segundo), e o pequeno gotejamento de dados que vai para um rootkit passará despercebido. TheNIDS representa uma ameaça de detecção maior quando uma exploração pública conhecida é usada em conjunto com um rootkit

Ignorando o IDS / IPS

Para ignorar firewalls e o software IDS / IPS, existem duas abordagens: ativas e passivas. Ambas as abordagens devem ser combinadas para criar um rootkit robusto. As infracções ativas operam em tempo de execução e são projetadas para evitar a detecção. Apenas no caso de alguém suspeitar, as ofensas passivas são aplicadas "nos bastidores" para tornar o forense tão difícil quanto possível.

As ofensas ativas são modificações no hardware e kernel do sistema projetados para subverter e confundir o software de detecção de intrusão. Medidas ativas geralmente são necessárias para desabilitar o software HIPS (como Okena e Entercept). Em geral, a ofensa ativa é usada contra o software que é executado na memória e tenta detectar rootkits. As ofensas ativas também podem ser usadas para tornar as ferramentas de administração do sistema inúteis para detectar um ataque. Uma infração complexa poderia tornar qualquer ferramenta de software de segurança ineficaz. Por exemplo, uma ofensa ativa pode localizar um scanner de vírus e desativá-lo.

As ofensas passivas são obstruções no armazenamento e transferência de dados. Por exemplo, criptografar dados antes de armazená-lo no sistema de arquivos é uma ofensa passiva. Uma ofensa mais avançada seria armazenar a chave de descriptografia na memória de hardware não volátil (como RAM flash ou EEPROM) em vez de no sistema de arquivos. Outra forma de ofensa passiva é o uso de canais secretos para a exfiltração de dados fora da rede.

Finalmente, um rootkit não deve ser detectado por um scanner de vírus. Os scanners de vírus não só operam em tempo de execução, mas também podem ser usados ​​para escanear um sistema de arquivos "off-line". Por exemplo, um disco rígido em um banco de laboratório pode ser analisado forense quanto a vírus. Para evitar a detecção em tais casos, um rootkit deve ocultar-se no sistema de arquivos para que ele não possa ser detectado pelo scanner.

Ignorando ferramentas forenses

Idealmente, um rootkit nunca deve ser detectado por varredura forense. Mas o problema é difícil de resolver. Existem ferramentas poderosas para digitalizar discos rígidos. Algumas ferramentas, como o Encase, [31] "procuram o mal" e são usadas quando um sistema é suspeito de uma infecção. Outras ferramentas, como Tripwire, "procuram o bem" e são usadas para garantir que um sistema permaneça não infectado.

Um praticante que usa uma ferramenta como o Encase digitalizará a unidade para padrões de bytes. Esta ferramenta pode olhar para toda a unidade, não apenas arquivos regulares. Espaço vazio e arquivos excluídos serão digitalizados. Para evitar a detecção neste caso, o rootkit não deve ter padrões facilmente identificáveis. O uso de esteganografia pode ser poderoso nesta área. A criptografia também pode ser usada, mas as ferramentas usadas para medir a aleatoriedade dos dados podem localizar blocos de dados criptografados. Se a criptografia for usada, a parte do rootkit responsável pelo decodificação precisaria ficar sem criptografia (claro). As técnicas polimórficas podem ser usadas para mutar o código do decodificador para proteção adicional. Lembre-se de que a ferramenta é tão boa quanto os técnicos forenses que o conduzem. Se você pensa em alguma maneira de esconder que eles não, você pode escapar à detecção.

As ferramentas que realizam o hash criptográfico contra o sistema de arquivos, como Tripwire, exigem um banco de dados de hashes a ser feito a partir de um sistema limpo. Em teoria, se uma cópia de um sistema limpo (ou seja, uma cópia do disco rígido) é feita antes da ocorrência da infecção do rootkit, pode-se realizar uma análise offline que compara a nova imagem da unidade com a antiga. Qualquer diferença na imagem da unidade será anotada. O rootkit certamente será uma diferença, mas também haverá outros. Qualquer sistema em execução mudará ao longo do tempo. Para evitar a detecção, um rootkit pode ocultar o ruído regular do sistema de arquivos. Além disso, essas ferramentas apenas olham os arquivos e, eles só podem olhar para alguns arquivos - talvez apenas arquivos considerados importantes. Eles não abordam dados armazenados de maneiras não convencionais (por exemplo, em setores defeituosos em uma unidade). Além disso, os arquivos de dados temporários provavelmente serão ignorados. Isso deixa muitos lugares potenciais para ocultar que não serão verificados.

Se um atacante está realmente preocupado com o fato de o administrador do sistema ter todas as coisas hash e o rootkit será detectado, ela poderia evitar o sistema de arquivos, talvez instalando um rootkit na memória e nunca usando a unidade. Uma desvantagem, é claro, é que um rootkit armazenado em memória volátil desaparecerá se o sistema for reiniciado.

Para levar as coisas ao extremo, talvez um rootkit possa instalar-se no firmware presente no BIOS ou no chip RAM instantâneo em algum lugar.

Conclusão

Os rootkits de primeira geração eram apenas programas normais. Atualmente, os rootkits geralmente são empacotados como drivers de dispositivo. Nos próximos anos, os rootkits avançados podem modificar ou instalar no microcódigo de um processador, ou existem principalmente nos microchips de um computador. Por exemplo, não é inconcebível que o bitmap de um FPGA (matriz de porta programável de campo) possa ser modificado para incluir uma porta traseira. [32] Claro, este tipo de rootkit seria criado para um alvo muito específico. Os rootkits que usam serviços de sistemas operacionais mais genéricos são mais prováveis ​​de serem amplamente utilizados.

O tipo de tecnologia de rootkit que poderia se esconder dentro de um FPGA não é adequado para uso por um worm de rede. Os ataques específicos de hardware não funcionam bem para worms. A estratégia de rede-verme é facilitada por computação homogênea em grande escala. Em outras palavras, os worms de rede funcionam melhor quando todo o software segmentado é o mesmo. No mundo dos rootkits específicos de hardware, existem muitas pequenas diferenças que dificultam os ataques de múltiplos destinos. É muito mais provável que os ataques baseados em hardware sejam usados ​​contra um alvo específico que o invasor possa analisar para criar um rootkit especificamente para esse alvo.

Enquanto existirem explorações de software, os rootkits usarão essas explorações. Eles trabalham juntos de forma natural. No entanto, mesmo que tais façanhas não fossem possíveis, os rootkits ainda existiriam.

Nas próximas décadas, o estouro do buffer, atualmente, o "rei de todas as explorações de software" estará morto e enterrado. Avanços em linguagens de tipo seguro, compiladores e tecnologias de máquinas virtuais tornarão o estouro de buffer ineficaz, dando um enorme golpe contra aqueles que dependem de exploração remota. Isso não significa que as façanhas desaparecerão. O novo mundo da exploração será baseado em erros de lógica em programas e não na falha de arquitetura do estouro de buffer.

Com ou sem exploração remota, no entanto, os rootkits persistirão. Os Rootkits podem ser colocados em sistemas em vários estágios, desde o desenvolvimento até a entrega. Enquanto houver pessoas, as pessoas vão querer espionar outras pessoas. Isso significa que os rootkits sempre terão um lugar em nossa tecnologia. Programas Backdoor e subversões de tecnologia são intemporais!