Por Henrique Scocco

/ Em Segurança da Informação /

Postado em

dez 03, 2020

Unquoted Service Path – O Perigo dos Serviços de Terceiros

Meus queridos, como vão?

Hoje iremos sair um pouco do mundo de web e falar sobre uma técnica muito utilizada na pós-exploração para realizar escalação de privilégios no Windows.

Como sabemos, cada serviço do Windows é mapeado para um arquivo executável que será executado quando o serviço for iniciado. Geralmente, quando realizamos o download de softwares terceiros, eles são por padrão instalados em diretórios como “C:\Program Files” e “C:\Program Files (x86)“.

O problema neste cenário todo é que nem todos os softwares utilizam aspas (“”) para referenciar o caminho do executável do serviço. Quando isso ocorre, um serviço pode ser facilmente explorado e resultar em escalação de privilégios na máquina local.

Entendendo o Sistema Operacional

Antes de detalhar de fato a exploração, vamos primeiramente entender o que ocorre com o Windows: conforme citado anteriormente, todos os desenvolvedores, por boas práticas, devem utilizar aspas quando um arquivo ou diretório contém espaço. Quando isso não ocorre, o cenário fica aberto para diversas interpretações.

Vamos supor que queremos executar o serviço “C:\Program Files\Example Service\Example.exe“. Quando o serviço é configurado, caso o seu diretório não esteja utilizando aspas, o Windows irá tentar executar o serviço a partir dos seguintes caminhos:

C:\Program.exe
C:\Program Files\Example.exe
C:\Program Files\Example Service\Example.exe

Isto ocorre pois ele irá testar cada local interpretado a fim de encontrar o executável válido – para cada espaço contido no diretório do serviço, ele tentará executar como se fosse um arquivo executável.

Neste caso, para explorá-lo, um atacante pode por exemplo inserir um arquivo malicioso em um desses diretórios que o windows irá tentar interpretar. Dessa forma, quando o serviço fosse iniciado, o arquivo malicioso irá ser interpretado pelo sistema operacional e executado com os mesmos privilégios do serviço.

Ficou confuso né? Então vamos para a parte prática.

Colocando a Mão na Massa

Inicialmente, no Windows, abra o prompt de comando e execute o comando abaixo:

wmic service get name,pathname | findstr Program

Este comando irá listar todos os serviços e seus respectivos diretórios. No exemplo abaixo, observamos que o serviço de VPN não possui aspas em seu diretório:

Portanto, sabemos então que ao iniciar o serviço, o Windows tentará localizar o executável válido através dos seguintes caminhos:

C:\Program.exe
C:\Program Files\ShrewSoft\VPN.exe
C:\Program Files\ShrewSoft\VPN Client\iked.exe

Vamos então montar um código básico em C para validar a exploração. O executável irá abrir o CMD e salvar a saída do comando “whoami” na minha área de trabalho:

Agora, vamos nomear esse executável para um daqueles arquivos que sabemos que o windows tentará interpretar, nesse caso o VPN.exe, e enviá-lo para o diretório-alvo:

Feito isso, quando o serviço for iniciado, ele irá executar o arquivo com privilégios de LocalSystem na máquina. O privilégio de System é o último nível de privilégios local do Windows (System Mandatory Level).

O serviço-alvo foi então pausado com o comando “sc”:

Dessa forma, ao reiniciar o serviço, o mesmo retornou um erro. Isto ocorre pois ele não encontrou o executável válido e executou o nosso arquivo malicioso no lugar.

Como evidência de execução de código, recebemos a saída do comando “whoami” com privilégios de “NT Authority\ System”:

O serviço poderia ser reiniciado de outras formas também, como por exemplo forçando um reboot da própria máquina, caso o usuário não tenha privilégios para utilizar o comando “sc”.

Conclusão

Isso tudo demonstra o quão vulneráveis podemos estar por falta de um bom desenvolvimento por parte dos softwares terceiros que utilizamos diariamente em nossos ambientes. Espero que tenham gostado e aproveitem o conhecimento 🙂

0

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *