Microsoft Windows Kernel Hardening
O sistema operacional Windows x64, como o Windows Vista ou versões posteriores, possui muitos mecanismos de segurança para "endurecer" o kernel relação aos seus antecessores x86. E beste cenário, existem duas técnicas que são particularmente muito interessantes para a análise do Turla: Driver-signature e PatchGuard. A partir do Windows Vista (64-bit), o kernel do sistema operacional permite que apenas drivers assinados possam ser carregados por default. Isso aumentou significativamente a carga para injeção de código malicioso no kernel, mas não resolve o problema de malware, como será possível acompanhar mais adiante nesta publicação. Apesar de driver-signing estar sendo aplicada por padrão, a Microsoft suporta uma opção para inicializar seu sistema operacional, em um modo onde a verificação de assinaturas está inativa. Este modo é destinado principalmente para suporte a test-drivers. Assim, enquanto o sistema de driver de assinatura aumenta a carga de um atacante, ele ainda permite que o malware possa carregar um novo código no kernel, caso este malware é seja capaz de reiniciar o sistema sem esse mecanismo de proteção habilitado, ou colocando um bootkit-path para ser executado antes, e com privilégios superiores, o próprio kernel. Ainda assim, a exigência de reiniciar a máquina da vítima incorre em um payload significativo para o atacante, devido a reboots que inevitavelmente, podem levantar suspeitas indesejadas.
A segunda melhoria de segurança do kernel que pode ser considerada significativa, PatchGuard, é um componente do sistema voltado principalmente para a detecção de alterações de estruturas de dados críticos para o sistema, como SSDT, IDT, ou as páginas de código carregadas na memória. PatchGuard funciona calculando periodicamente uma soma de verificação dessas regiões críticas, e alertando assim que forem detectadas quaisquer tipos de alterações inesperadas. Uma vez que a maioria dos rootkits modifica pelo menos uma das regiões monitorados para implementar a sua funcionalidade maliciosa, esta abordagem de verificação disponibiliza um mecanismo genérico para detectar a presença do código indesejado.
Por exemplo, muitos rootkits tradicionais modificam as entradas SSDT para NtQuerySystemInformation ou NtQueryProcessInformation, com a finalidade chave de esconder seus processos em relação ao modo do usuário ou componentes do driver, como descrito em um post anterior. Qualquer tentativa de alterar o SSDT seria detectada por uma verificação a fundo, permitindo que PatchGuard possa detectar o comprometimento do kernel, e travar o sistema comprometido para evitar maiores danos.
Turla APT Versus Windows Kernel
O Turla APT é um malware altamente sofisticado e suspeito de ser patrocinado pelo estado. O que torna esta família APT particularmente interessante é o seu design: a grande maioria das funcionalidades do Turla é implementada em um driver de kernel, que é capaz de executar suas atividades - completamente desapercebido - em sistemas de 64-bit do Windows (exatamente envolvendo o kernel do sistema operacional da Microsoft), apesar de várias camadas de proteção projetadas para bloquear essas ações maliciosas. Ainda mais, os atacantes por trás do Turla são capazes de infectar uma vítima sem que haja a necessidade de reinicialização do sistema, tornando-o ainda mais furtivo do que muitos outros ataques anteriormente visto no kernel.
Além do supra mencionado, vários grupos de pesquisa têm gasto uma quantidade significativa de tempo para descobrir e analisar a funcionalidade do Turla. Portanto, nesta publicação, queremos nos concentrar em como Turla consegue ignorar completamente os recursos de segurança descritos acima - ignorando PatchGuard, bem como a execução de verificação de assinatura do driver, mesmo sem a necessidade de uma reinicialização do sistema. Além disso, está sendo possível mostrar como a próxima geração de sandbox do Lastline pode dissecar a funcionalidade do Turla APT completamente, de maneira automática e fornecer uma avaliação da ameaça precisa para os analistas e peritos da área da segurança, em especial os pesquisadores de malware.
Bypassing em Verificação de Assinaturas para Drivers
Primeiro, é necessário observar como Turla consegue carregar código não confiável para o contexto do kernel. Para executar o novo código no kernel, os autores usam um truque interessante, usando uma versão vulnerável de um driver VirtualBox assinado como um stepping stone: Carregando este primeiro driver, ele não levantará suspeitas - afinal de contas, o código é assinado por uma entidade confiável. No entanto, por carregar esse driver, uma nova vulnerabilidade é introduzida no kernel, permitindo que um aplicativo no modo de usuário consiga gravar em locais de memória arbitrárias dentro do kernel. Além do mais, com a capacidade de modificar o kernel-memory, o atacante agora pode mexer com qualquer configuração existente no kernel.
Com a capacidade de modificar kernel-memory, o atacante agora pode mexer com qualquer configuração no kernel. Ele localiza a variável g_CiEnabled dentro do kernel-memory, que é usado para indicar se o kernel está sendo executado em um modo a partir da qual a verificação do driver de assinaturas está habilitada ou não. Mais precisamente, a localização da variável é calculada através do carregamento da imagem ntoskrnl.exe para a memória do componente de modo de utilizador, o que permite calcular o deslocamento da variável dentro da imagem. Isso é feito através da procura de instruções específicas com referência a ela. Ressaltando que este deslocamento é então adicionado à base-address do ntoskrnl que é carregado no kernel, que pode ser calculada através do SystemModuleInformation como argumento para NtQuerySystemInformation. Além do mais, fazer um patching no value g_CiEnabled para 0, caracteriza um "defeat" no primeiro mecanismo de segurança, mesmo sem que haja a necessidade de reinicialização do sistema. Isso permite que o malware possa carregar (em modo "unsigned") componentes arbitrários de modo de usuário, bastando escrever a funcionalidade de carga útil para um arquivo e chamando NtLoadDriver.
Defeating PatchGuard
Apesar da capacidade de executar código "unsigned" no kernel do sistema operacional, o APT ainda não é capaz de desempenhar as suas funcionalidades de rootkit, porque PatchGuard impede injetar código malicioso para o controle de fluxo de funcionalidade no sistema crítico. Esta questão é abordada no segundo passo do ataque: Os criminosos começam fazendo um hooking de funções RtlCaptureContext, KiRetireDpcList e RtlLookupFunctionEntry, além das funções de rootkit-activity relacionadas, que, como descrito acima, irão disparar um alerta de PatchGuard da próxima vez que a integridade de páginas da memória do sistema passar por um processo de verificação. Assim que isso acontecer, PatchGuard chamará KeBugCheckEx, que, por sua vez, forçará um desligamento do sistema, mostrando a infame tela azul da morte (BSOD).
No entanto, Turla é capaz de ignorar o BSOD usando uma das duas técnicas possíveis: em uma versão anterior do APT, o código faz um hook no KeBugCheckEx e força a função para retornar sem executar a funcionalidade BSOD. Em seguida, a Microsoft atualiza o PatchGuard para utilizar uma cópia da função KeBugCheckEx (clonada durante a inicialização do sistema) e ao invés da função global no kernel, uma nova versão do Turla aparecerá; esta nova versão começará fazendo um hooking com RtlCaptureContext ao invés do KeBugCheckEx. A former function é conhecida internamente por KeBugCheckEx (e, portanto, também como parte da versão copiada), permitindo que Turla possa interceptar a execução antes de um raising de BSOD (Blue-Screen-of-Death, a "tela azul da morte").
Funcionalidade do Turla
Uma vez que PatchGuard foi contornado, o malware tem acesso total ao kernel. Desta maneira, ele executa a funcionalidade de um rootkit clássico: conectando um número de chamadas do sistema, principalmente para esconder/proteger seus componentes de modo de usuário. Ele consegue isso modificando ntoskrnl.exe e Ndis.sys na memória, seguido pela criação de uma nova entrada de IDT (pelo índice 0xC3) e redirecionando todas as funções em forma de hooking para um único manipulador de interrupção (ISR). Cada função em modo "hooking" está associada com um identificador único, que passa a ser utilizado na ISR para despachar a função em conformidade.
Saiba Mais:
[1] Lastline Labs http://labs.lastline.com/dissecting-...namic-analysis