Por Heimdall ISH

Uma nova vulnerabilidade Zero Day (ainda sem patch disponível) foi apresentada ao universo de segurança no dia 22 de novembro. Erroneamente classificada em notícias como um bypass da CVE-2021-41379, essa é na verdade uma variante nova descoberta pelo mesmo autor da vulnerabilidade original, Abdelhamid Naceri.

A PoC (proof of concept) lançada por Naceri, InstallerFileTakeOver.exe, se baseia em um bug do Windows Installer para alterar permissões de arquivos arbitrários. Esse comportamento anômalo é direcionado ao serviço de elevação de privilégios para atualização do Microsoft Edge (MicrosoftEdgeElevationService), resultando na elevação de privilégios para SYSTEM.

Funcionamento do Windows Installer

Tanto a CVE-2021-41379 quanto essa vulnerabilidade 0 day se valem do Windows Installer para elevar privilégios através da mudança de acesso a arquivos restritos do sistema. Para explicar o funcionamento da prova de conceito de Naceri, primeiro é necessário explicar o funcionamento do Windows Installer. O instalador do Windows consome pacotes de instalação (installation packages), que contêm instruções para as etapas do processo de instalação em uma base de dados; esses pacotes possuem a extensão .msi. A documentação da Microsoft categoriza esses dois momentos como aquisição e execução.

Durante a aquisição, o instalador segue as instruções da base de dados do arquivo msi e geram um script com o passo a passo para realizar o processo de instalação. Durante a fase de execução, esse script é fornecido a um processo com privilégios elevados, que o executa para realizar a instalação no sistema.

Em sua documentação para a mitigação temporária dessa vulnerabilidade, o autor demonstra como a instalação orquestrada pelo msi contido em sua PoC deveria funcionar (ou seja, sem o bug por ele descoberto e empregado):

Em suma, a PoC cria um pacote de instalação (arquivo .msi), que será responsável por:

• Criar no diretório alvo os arquivos @AppHelpToast.png, splwow64.exe e a pasta “microsoft
plz”;

• Criar notepad.exe dentro da pasta “microsoft plz”.

A pasta Config.Msi, demonstrada no canto superior esquerdo da imagem, é uma pasta de sistema que existe na raiz de C:\.

Essa pasta mantém backups de arquivos durante um processo de instalação. Caso o processo seja interrompido por qualquer razão, esse local contém todo o necessário para reverter o sistema ao estado anterior à instalação. Uma das ferramentas necessárias para isso é o rollback file, de extensão .rbf. Trata-se de um script que orientará a restauração de todos os arquivos que foram excluídos durante a instalação, cujo backup é mantido em Config.Msi. As imagens a seguir demonstram o processo descrito pelo autor (criação de um msi, seguido pela criação dos arquivos e pastas em questão).

Bug na criação do arquivo de rollback

Uma dúvida pode ter surgido nos leitores mais atentos: se o instalador é responsável pela criação dos arquivos em um diretório, por que o processo InstallerFileTakeOver.exe está mexendo com o notepad.exe? Os pacotes de instalação rodam na sessão 0 (reservada para serviços e outros processos que rodam pelo usuário SYSTEM) por meio do msiexec.exe; logo, esse processo, não a PoC, deveria escrever o conteúdo dos executáveis em questão.

A elevação de privilégios desse 0 day é baseada em um bug que ocorre quando o pacote de instalação tenta acessar um arquivo que está travado para compartilhamento.

Essa situação resulta na criação do arquivo .rbf fora do diretório Config.Msi. Isso é ilustrado pelo pesquisador no seguinte diagrama:

Notem no canto inferior esquerdo a seta com a mensagem “lock notepad.exe”. Essa é uma ação proposital da PoC para causar o bug mencionado e o motivo para seu processo interagir com um arquivo que o pacote de instalação quer ler. Existe uma função específica para isso no código da prova de conceito:

Mas qual o uso desse bug? O arquivo de rollback não é apenas criado onde não deveria; ele é criado sem impersonation. Impersonation é a capacidade de realizar uma ação com credenciais diferentes daquelas mantidas pelo processo. O correto seria que msiexec.exe escrevesse no diretório alvo com as permissões de um usuário comum, mas isso ocorre como SYSTEM.

Alterando as permissões do arquivo alvo

Chegamos à última parte da prova de conceito, uma condição de corrida. Assim que o arquivo .rbf for criado no lugar errado, o processo InstallerFileTakeOver.exe será alertado.

O primeiro destaque é a tentativa de acesso ao arquivo de rollback por msiexec. As entradas seguintes, associadas a InstallerFileTakeOver, são as mudanças de nome e criações de links simbólicos que constituem a condição de corrida. O segundo destaque mostra uma alteração no mesmo arquivo que msiexec tentou acessar.

O efeito prático é a mudança das permissões do arquivo alvo, demonstrada a seguir:

Após a execução de InstallerFileTakeOver.exe (a prova de conceito), as permissões de elevation_service mudaram. O usuário que executou a ação (DESKTOP-RP7H2UN\dodo) passa a ter permissão plena ao arquivo em questão, como demonstrado por (F)5.

Esse novo acesso é aproveitado pelo o autor para sobrescrever tal executável, como demonstrado nas ações a seguir:

Essa alteração é a parte final da prova de conceito. O novo elevation_service será responsável por abrir um prompt de comando elevado, completando a elevação de privilégios:

É interessante observar que o elevation_service alterado possui o mesmo ícone que o executável da PoC. Sua detecção por engines de antivírus também é alta, conforme demonstrado abaixo:

É possível confirmar a eficácia da prova de conceito com um simples comando whoami no prompt gerado:

Limitações

A prova de conceito só pode ser aplicada para arquivos que não estão em uso no momento de sua execução. Caso ela seja executada sem argumentos, o alvo é o serviço de elevação do Microsoft Edge. O código da PoC possui uma rotina que confirma se esse serviço não está em execução:

Note que o código à direita busca pelo retorno ERROR_SERVICE_DOES_NOT_EXIST como confirmação de que o alvo não está em execução. Caso um argumento seja fornecido (na forma de um arquivo para o qual o usuário quer receber permissões completas), o alvo também não pode estar em uso. Em nossos testes, utilizar a prova de conceito com um arquivo arbitrário fornecido como argumento resulta na perda das informações contidas no alvo. Exemplo: quando usada contra o arquivo system.ini, esse passa a conter 0 bytes após a obtenção das permissões. Esse comportamento não significa que essa vulnerabilidade serve apenas para excluir arquivos, como demonstrado pelo seu uso contra o serviço de elevação do Edge.

Detecção e mitigação

Ao noticiar essa vulnerabilidade, muitas fontes associam-na exclusivamente ao serviço de elevação do Microsoft Edge. Isso não é verdade. Embora tal executável tenha sido o alvo escolhido por seu autor, o comportamento errôneo do Windows Installer que permite a elevação de privilégios não depende do alvo escolhido. Assim, não aconselhamos que a detecção deste 0 day seja baseada em interações com elevate_service.exe.

De modo similar, a comunidade produziu regras de detecção YARA baseadas em componentes da PoC, como o arquivo test pkg.msi. Esse modelo de detecção também não é confiável, visto que nomes de componentes são facilmente alterados.

Um indicador mais robusto, apontado também pela Rapid7, é o evento de ID 1033 nos logs de Application. Ele pode ser usado para encontrar momentos em que o MsiInstaller produziu um erro de instalação por SHARING VIOLATION (condição requerida para que a vulnerabilidade funcione). Esse erro é indicado pelo código 1603. De modo similar, o evento de ID 11306 traz a mensagem de erro em si. Um exemplo dela é fornecido abaixo:

Error 1306. Another application has exclusive access to the file
'C:\Users\dodo\AppData\Local\Temp{1391479E-FCA4-4BB0-BA7D-BBE51017C60B}\microsoft
plz\notepad.exe'. Please shut down all other applications, then click "Retry".

Note que a mensagem de erro traz o caminho completo do arquivo envolvido na violação de compartilhamento. Esse tipo de erro do MsiInstaller associado a diretórios incomuns para instalações (como %TEMP%, no caso acima) é um indicador de possível exploração dessa vulnerabilidade.

Lembramos que a prova de conceito possui uma rotina que apaga todos os executáveis e pastas que foram criados durante sua execução. Assim, não encontrar os arquivos delineados no erro não é um indicador de que a falha não foi explorada.

Até o momento não foram liberadas atualizações ou patches que mitiguem essa vulnerabilidade.