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
