Não passou muito tempo desde que a Microsoft lançou uma actualização de segurança alterando a forma como os sistemas operativos Windows verificam a integridade dos módulos carregados. Aliás no documento, The Evolution o TDL4, descrevemos um método que era utilizado pelo TDL4 bootkit para carregar controladores não assinados e maliciosos em sistemas 64-bit, mesmo quando os mesmos tinham um modo de verificação de assinaturas reforçado.

A nova actualização de segurança tem como principal objectivo resolver esta vulnerabilidade em sistemas operativos x64 (nomeadamente Windows Vista e posteriores) explorados pelo TDL4.

Nos sistemas que não estão protegidos (ou actualizados) existem três opções BCD (Boot Configuration Data) que determinam ao modo como o sistema operativo verifica a integridade dos módulos ao nível do Kernel:

BcdLibraryBoolean_DisableIntegrityCheck – instrui o sistema a desactivar as verificações de integridade em modo Kernel, para debug, por exemplo.

BcdOSLoaderBoolean_WinPEMode – instrui o sistema a desactivar as verificações de integridade em modo Kernel e que são activadas quando o sistema operativo é carregado em modo de pré-instalação) – explorada pelo TDL4

BcdLibraryBoolean_AllowPrereleaseSignatures – Instrui o sistema a usar certificados especiais pré-instalados que permitem verificar as assinaturas digitais dos módulos ao nível do Kernel.

Num sistema devidamente actualizado apenas duas são deixadas activas:

BcdLibraryBoolean_DisableIntegrityCheck BcdLibraryBoolean_AllowPrereleaseSignatures.

Isto significa que a opção BcdOSLoaderBoolean_WinPEMode BCD já não é usada na inicialização das politicas de verificação da integridade do código. A rotina BlImgQueryCodeIntegrityBootOptions no ficheiro winload.exe devolve o valor que determina a política de integridade do código.

Vejam a imagem abaixo.

Aqui verificamos que o BcdOSLoaderBoolean_WinPEMode já não é utilizado e como tal o truque levado a cabo pelo TDL4 para substituir o kdcom.dll deixa de funcionar.

Existe um módulo actualizado nesta correcção da Microsoft: kdcom.dll.  Como já sabemos, o TDL4 substitui a biblioteca kdcom.dll com o seu componente malicioso aquando do arranque. O bootkit identifica o ficheiro kdcom.dll pelo tamanho da pasta exportada (é comparado com o 0xFA).

Na versão actualizada do kdcom.dll, a dimensão da pasta exportada foi modificada. Se olharmos para a mesma (figura abaixo) verificamos que um símbolo exportado KdReserved foi adicionado já que não se encontrava presente na biblioteca não actualizada.

Esta função é adicionada apenas com um propósito: aumentar a dimensão da pasta exportada e como tal prevenir que o bootkit TDL4 o substitua.

A actualização de segurança não vai ajudar necessariamente os utilizadores que já tenham sido infectados com o bootkit, já que o TDL4 bloqueia o serviço de actualizações do Windows Update nas máquina x86. Como resultado disto, as máquinas x86 infectadas não poderão descarregar e instalar as actualizações automaticamente. Num sistema operativo X64 tudo se processa de um modo diferente e o serviço de actualizações não é bloqueado pelo bootkit, sendo que assim a atualização de segurança pode ser descarregada e instalada.

Apesar da actualização ajudar com este caso em particular não resolve o problema na generalidade, já que continuam a existir outras formas de entrar em modo Kernel. Por exemplo, no caso do bootkit chinês que é detectado por NSIS/TrojanClicker.Agent.BJ é utilizada uma abordagem diferente para o carregamento do controlador não assinado.

Eugene Rodionov, Malpare Researcher
Aleksandr Matrosov, Senior Malware Researcher
David Harley ESET

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

*