Nova pesquisa: descobrimos como contornar o SmartScreen através de um hijacking sem privilégios no COM

A técnica de COM Hijacking é um sequestro do objeto COM e tem uma base teórica muito simples, semelhante à um sequestro de DLL: O que acontece quando um aplicativo procura por um objeto COM inexistente no computador no qual está sendo executado? Ou quando o objeto existe, mas não é encontrado na chave do registro onde foi pesquisado? Um invasor pode criá-lo com informações adulteradas, por exemplo, usando uma rota que em vez de levar à DLL solicitada, leve a vítima a uma criada pelo invasor. Pode-se assim aproveitar o padrão no qual um computador trabalha para encontrar esse objeto, contornando o SmartScreen no Windows. 

Pequena introdução
O COM (Component Object Model) é um modelo de interface binária para componentes de software, ele permite a comunicação entre processos e a criação dinâmica de objetos, independentemente do idioma em que foram programados. O COM oferece um ABI (Application Binary Interface) estável que não muda com as diferentes versões dos compiladores. Esta estabilidade é muito atraente para desenvolvedores C ++, onde o código deve ser compartilhado com diferentes clientes usando diferentes versões de compiladores. 

Normalmente os objetos COM são compilados como uma DLL, mas a maneira de usá-los é diferenciada. Os objetos COM devem ser exclusivamente identificáveis no momento da execução e, para isso, uma identificação conhecida como GUID é usada, como por exemplo: 

{CB4445AC-D88E-4846-A5F3-05DD7F220288}

Cada objeto COM é registrado com seu GUID correspondente, acompanhado por uma ou mais chaves que fornecem informações sobre o próprio objeto como o caminho real de sua DLL. Normalmente os objetos COM são registrados das seguintes formas no Registro: HKLM \ SOFTWARE \ Classes \ CLSID ou HKLU \ SOFTWARE \ Classes \ CLSID. Neste registro sob a chave GUID correspondente, as chaves de Registro InprocServer, InprocServer32, InprocHandler e InprocHandler32 são geralmente usadas para fornecer as rotas para a DLL do objeto. Se o objeto COM estiver sob a raiz HKEY_LOCAL_MACHINE (HLKM), significa que está disponível para todos os usuários do computador e que foi criado com permissões de administrador do sistema. Enquanto aqueles criados sob a raiz HKEY_CURRENT_USER (HCKU) são válidos para o usuário atualmente autenticado e não necessariamente criado por um administrador. 

A ordem de busca natural do sistema é um processo muito interessante. Um cenário comumente usado pelo sistema é o de pesquisar primeiro o ramo do usuário e depois o ramo do computador onde ele é executado. Pense em um aplicativo que, quando iniciado, precisa usar as funções do objeto COM localizado na seguinte chave do Registro: 

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CB4445AC-D88E-4846-A5F3-05DD7F220288}\InprocServer32

Porém antes de pesquisá-lo, o aplicativo primeiro irá procura a seguinte rota: 

HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{CB4445AC-D88E-4846-A5F3-05DD7F220288}\InprocServer32

Supondo que esta última chave não exista estaremos enfrentando um aplicativo vulnerável ao uso de COM Hijacking. Executar a técnica não implica mais do que criar a seguinte estrutura no registro:

HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID {CB4445AC-D88E-4846-A5F3-05DD7F220288} InprocServer32 (Default) = C:\DLLsMaliciosas\miDLL.dll

COM Hijacking como persistencia
A técnica de COM Hijacking com persistência tem várias vantagens em comparação com o resto das técnicas tradicionais que se infiltram na raiz. Pois normalmente é melhor ter um objeto COM nativo chamado toda vez que o sistema for iniciado. O principal problema com isso é que os objetos COM nativos geralmente são encontrados no HKCR (classes raiz) em vez de consultar o registro do usuário, desta forma um usuário por si próprio não deve ser capaz de acessá-lo.

Na verdade, o HKCR é uma visualização virtual do que vemos em HKCU e HKLM. O que significa que se você quiser escrever uma chave… 

HKCR\CLSID\{A47979D2-C419-11D9-A5B4-001185AD2B89

Pode-se cria-la no seguinte caminho

Portanto, para executar o Hijacking para o objeto COM nativo do Windows, você pode criar a esta chave como se mostra na imagem a seguir e assim dissemina-la. 

Devido a forma como se trabalha o HKEY_CURRENT_USER (HKCU), a permissão de administrador não se faz necessária para executar o ataque. Uma vez que a chave de registro é criada, o código contido na DLL introduzida será executado toda vez que o aplicativo vulnerável encontrar o objeto COM sequestrado e carregar a DLL maliciosa. 

Elevar privilégios através do Event Viewer e do Task Scheduler
Para elevar os privilégios por meio de uma técnica como a do Hijacking COM você deve aproveitar um aplicativo vulnerável que é executa-lo com privilégios elevados (admin) e com alta integridade de processo. As aplicações Event Viewer e Task Scheduler invocam um processo de alta integridade e alto nível chamado mmc.exe. Este é usado por várias aplicações do Windows.As funções mencionadas procuram objetos COM na seguinte rota:

HKCU\Software\Classes\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\InprocServer32

O que aconteceria se um sequestro de COM fosse feito para esse objeto? Na linha abaixo mostramos como simular o comando:

powershell.exe -Command {$Path=»HKCU:\Software\Classes\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\InprocServer32″;$Name=»(Default)»;$Value=»C:\\MisDLLs\epp1.dll»;New-Item -Path $Path -Force;New-ItemProperty -Path $Path -Name $Name -Value $Value}

Uma vez invocado o processo vulnerável, ele encontrará o objeto COM (apriore não contaminado) e executará a DLL maliciosa, que nesse caso é um shell meterpreter (que em suma é um payload do tipo staged) localizado em «C: \ MisDLLs \ epp1.dll»

Como o processo vulnerável possui um privilégio alto (admin) e possui alta integridade, o shell fornecido passa a ter privilégios SYSTEM sem problemas. Uma técnica similar foi usada para contornar o UAC. 

Passando despercebido: SmartScreen é vulnerável ao Hijacking de COM
Há algum tempo descobrimos como os “agressores” conseguiram contornar o SmartScreen explorando as técnicas de sequestro de DLL. Essa abordagem de Hijacking alcança efeitos semelhantes, mas de uma forma diferente. Toda vez que um programa é executado no Windows, o SmartScreen é executado para tentar nos proteger.… Não importa qual seja o programa, cada execução passa pelo SmartScreen, que consulta na nuvem se o programa pode representar um risco para o sistema ou não. 

Todavia o SmartScreen é vulnerável ao Hijacking do COM Veja que toda vez que um binário é executado, o SmartScreen também é executado e, toda vez que o SmartScreen é executado, vários objetos COM são pesquisados no registro sem sucesso. Entre eles: 

HKCU\Software\Classes\CLSID\{A463FCB9-6B1C-4E0D-A80B-A2CA7999E25D}\InprocServer32.

Através de uma DLL, você pode executar um sequestro neste objeto através do seguinte comando na console do Powershell:

Após a execução do script acima faz com que qualquer programa que o usuário execute acione juntamente o SmartScreen e, por sua vez, será o mesmo processo que carregará e executará a DLL maliciosa, neste caso, retornando um shell do meterpreter. Na prova de conceito, usamos simplesmente uma DLL que mostrava um Hello World, matando desta forma um processo que deveria nos proteger. 

Embora você também possa simplesmente usá-lo para substituí-lo o SmartScreen.\ e se tronar permanente, como no video abaixo: 

https://youtu.be/JNKgta9IDN8

Nós alertamos a Microsoft sobre essa vulnerabilidade em potencial, que permitiria a persistência e o burlar de uma função de segurança. 

Gostou? Que saber mais? Veja o estudo completo em:

COM Hijacking, a technique still alive from ElevenPaths

Inovação e laboratório na ElevenPaths
www.elevenpaths.com