MÉTODOS PARA DETECÇÃO LOCAL DE ROOTKITS E MÓDULOS DE KERNEL MALICIOSOS EM SISTEMAS UNIX Nelson Murilo Klaus Steding-Jessen Pangéia Informática NIC BR Security Office SRTS 701, 70 cj E, sala 304 Rua Hum, 45 Caixa Postal 6146 70340-902 Brasília-DF 13083-970 Campinas-SP [email protected] [email protected] RESUMO Rootkits são ferramentas utilizadas com freqüência por invasores para ocultar sua presença em máquinas comprometidas, fazendo parte inclusive de alguns Worms e ferramentas de DDoS. Uma invasão pode passar meses sem ser descoberta graças a essas ferramentas. Além das versões tradicionais, rootkits vem sendo imple- mentados também sob a forma de módulos de kernel (LKMs), dificultando a sua detecção. Este artigo descreve o funcionamento desses dois tipos de rootkit, alguns métodos para sua detecção em sistemas Unix e uma ferramenta de código aberto, implementada pelos autores, para detecção automatizada de rootkits. ABSTRACT Rootkits are a very popular technique among intruders to hide themselves in compromised machines. Some rootkits are also used by Worms and DDoS tools. An intrusion can remain undetected for months when such a tool is used by an attacker. Rootkits are also being implemented as Loadable Kernel Modules (LKMs), making them much harder to detect. This paper describes the traditional as well as the LKM-based rootkit and presents some rootkit detection methods for Unix machines. This paper also presents an open source tool, developed by the authors, to detect rootkits. 1 INTRODUÇÃO evolução dos rootkits, seguido da descrição dos com- ponentes e funcionamento dos rootkits tradicionais e Com a popularização de ferramentas de ataque au- também dos implementados sob a forma de LKMs. tomatizado, comprometer máquinas Unix com vulne- São discutidos em seguida alguns métodos de detec- rabilidades conhecidas tornou-se atividade extrema- ção para esses tipos de rootkit. Por fim é mostrada mente simples [1]. uma ferramenta gratuita e de código aberto, desen- Após uma fase inicial de varredura o atacante lo- volvida pelos autores, para detecção automatizada de caliza uma máquina com alguma vulnerabilidade e rootkits. a explora, obtendo assim acesso privilegiado. Nesse momento a preocupação é não ser detectado e garantir 2 HISTÓRICO futuros meios de acesso ao sistema através da instala- ção de backdoors [2,3,4,5]. Este ciclo eventualmente A partir de 1989 começaram a surgir, na revis- recomeça com a utilização da máquina invadida para ta “underground” Phrack Magazine, códigos-fonte de a varredura e invasão de outros sistemas vulneráveis. ferramentas que permitiam editar e remover entradas O procedimento típico de invasão de uma máqui- nos arquivos utmp, wtmp e lastlog1 do sistema. O na Unix pode ser dividido genericamente em 4 passos objetivo dessas ferramentas era ocultar um invasor nu- básicos, como pode ser visto no diagrama da Fig. 1. ma máquina Unix comprometida—desse modo sua presença não era revelada por comandos como w, who, ganhar varredura users e last [8, 9, 10]. acesso Com o tempo foram sendo desenvolvidas várias outras ferramentas com o objetivo de ocultar um in- vasor numa máquina Unix: versões de comandos do sistema que ocultam informações relativas ao invasor, cobrir backdoors programas para não alterar os tempos de acesso, mo- rastros dificação e o CRC de programas alterados, etc. Estas ferramentas reunidas deram origem aos primeiros ro- Figura 1: Fases básicas de uma invasão. otkits. Os primeiros rootkits, originalmente escritos para A instalação de rootkits é uma maneira bastante SunOS e depois para Linux, são citados, em conjunto utilizada pelos invasores para não serem detectados com o uso de sniffers, em advisories do CERT já em no sistema e instalar backdoors. 1994 [11, 12]. O termo rootkit refere-se a um conjunto de ferra- Em 1995 torna-se muito popular na comunidade mentas usadas pelo invasor não para obter privilégios underground um rootkit denominado “RootKit”, usa- de root, mas sim para manter esses privilégios [6]. do num grande número de invasões [13]. A partir daí Embora existam rootkits também para a platafor- 1 ma Windows [3, 7], este artigo concentra-se apenas Em sistemas Unix, o arquivo utmp mantém a lista dos usuários ativos, o wtmp a lista de logins e logouts e o arquivo lastlog o em rootkits para sistemas Unix. último login de cada usuário. O artigo inicialmente apresenta um histórico da muitos outros tipos de rootkits apareceram, para pra- determinada porta e inicia uma shell (por exem- ticamente todas as variantes de Unix. plo o programa bindshell). Uma chamada a A partir de 1997 surgem referências de construção esse tipo de processo é comumente inserida nos de rootkits inseridos diretamente no kernel, sob forma scripts de inicialização da máquina para garan- de módulos de kernel (Loadable Kernel Modules, ou tir seu funcionamento mesmo por ocasião da LKMs) [14, 15, 16]. reinicialização do sistema. Alguns backdoors Nos dias atuais rootkits continuam sendo muito desse tipo implementam autenticação com se- populares entre invasores, fazendo parte inclusive de nha e sessões criptografadas. alguns worms [17, 18] e ferramentas de DDoS [19]. Outro mecanismo que o invasor possui para ga- rantir acesso remoto é a modificação de dae- 3 O ROOTKIT TRADICIONAL mons do sistema, como inetd, e sshd, entre outros. Embora pareça estar funcionando nor- Por rootkit tradicional entende-se o rootkit que malmente, a versão modificada usualmente é não é implementado em kernel space sob a forma de programada para escutar em alguma porta al- LKM. Tipicamente esse tipo de rootkit é composto, ternativa que inicia uma shell ou aceitar alguma pelo menos, de: senha especial que garanta acesso privilegiado. versões modificadas de comandos importantes Ferramentas para o aumento de privilégios de • do sistema como ls, ps, netstat, crontab, • contas locais. tcpd, syslogd, etc. Os comandos substituídos Caso o invasor perca o acesso remoto privile- podem omitir processos, conexões, arquivos e giado através de backdoors ou escolha entrar logs do invasor, de modo que sua presença não usando uma conta do sistema, mecanismos que seja notada pelo administrador e demais usuá- permitam a obtenção de privilégio de root atra- rios do sistema. vés de uma conta comum são geralmente utili- Geralmente contém algumas ferramentas adicio- zados. nais: Para permitir esse aumento de privilégio alguns comandos são alterados e fornecem uma shell Programas para remoção de entradas em arqui- • de root ao serem executados de modo especi- vos de log do sistema bem como nos arquivos al, como por exemplo através de uma senha. utmp, wtmp e lastlog, como por exemplo z2 e Exemplos de comandos normalmente alterados wted. são chfn e chsh. Ferramentas para alterar os tempos de modifi- • Exploits, programas de Denial of Service (DoS) cação, acesso e status (MAC times), o tamanho • e Scanners. e o CRC2 dos arquivos modificados pelo inva- sor, de modo a torná-los iguais aos originais. É muito comum uma máquina invadida estar (por exemplo as ferramentas addlen e fix). sendo usada apenas como base para comprome- ter outras redes—desse modo muitos rootkits Sniffers para a captura de senhas que trafeguem já incluem ferramentas para realizar as fases de • pela rede sem criptografia, como por exemplo varredura e exploração de vulnerabilidades em em protocolos como ftp, telnet, pop2, pop3, outras máquinas, como descrito na Fig. 1. imap2, rlogin, etc. Nesse caso geralmente o Programas relacionados com IRC, como boun- comando ifconfig é modificado para que não • indique que uma determinada interface de rede cers. está em modo promíscuo [6, 20]. Estes programas permitem que o invasor se co- Modificações em clientes ssh também se torna- necte em canais de IRC usando a máquina inva- ram um excelente método usado por invasores dida como “proxy”, desse modo não revelando para obtenção de senhas. o seu ponto de origem real. Backdoors que garantam o acesso remoto futu- 4 O LKM ROOTKIT • ro à máquina, mesmo em caso de mudança de senhas ou correções de vulnerabilidades. Ge- Módulos de kernel (Loadable Kernel Modules ou ralmente permitem acesso privilegiado (root) e LKMs) são componentes que podem ser dinamica- não deixam registro nos logs do sistema. mente carregados no kernel, modificando a funcio- Esse acesso remoto pode ser obtido através da nalidade de um sistema sem a necessidade de uma instalação de um processo que escuta em uma reinicialização. LKMs são implementados em vários 2Para fins de checagem de integridade o uso de CRCs (de 16 sistemas Unix (Linux, BSD, Solaris, HP-UX) e geral- e 32 bits) não é recomendado. Um invasor pode facilmente gerar mente usados para carregar device drivers de maneira versões modificadas de arquivos que possuam os mesmos CRCs dinâmica. dos originais, quando verificados pelo comando sum do Unix. Para um resultado mais confiável, o uso de algum hash criptográfico, como MD5 ou SHA-1, é recomendável. Enquanto os rootkits tradicionais funcionam alte- /* LINUX ROOTKIT DEFINES. */ rando os comandos do sistema para omitir informa- #define PW_LEN 6 ções da presença do invasor, como conexões, arqui- vos, processos, etc, os rootkits implementados sob #define ROOTKIT_PASSWORD "vejeta" forma de LKMs funcionam alterando chamadas do kill getdents read /* Processes to hide */ sistema (syscalls) tais como , e #define ROOTKIT_PROCESS_FILE "/dev/hda01" e atuando diretamente em algumas estruturas do ker- nel [16]. /* Addresses to hide */ Do ponto de vista do administrador a detecção #define ROOTKIT_ADDRESS_FILE "/dev/hda02" desses rootkits implementados como LKMs é mui- /* Files and directories to hide */ to mais difícil, pois todos os comandos do sistema #define ROOTKIT_FILES_FILE "/dev/hda03" continuam inalterados e o próprio kernel responderá às requisições mas ocultando a presença do invasor. /* Log entries to hide */ #define ROOTKIT_LOG_FILE "/dev/hda04" Mesmo uma checagem dos hashes criptográficos de todos os comandos do sistema não apontará nenhuma #define ROOTKIT_IFE_FILE "/dev/hda05" modificação. Normalmente esse tipo de rootkit altera também as chamadas do sistema que permitem listar #define ROOTKIT_TELNET_FILE "/dev/hda06" os módulos de kernel instalados.