O especialista em segurança da informação David Wells publicou uma maneira de ignorar os controles de conta de usuário do UAC no Windows 10
Olá pessoal!
Ao pesquisar algumas novas soluções alternativas para o Controle de Conta de Usuário (UAC), eu descobri uma solução completamente nova para o UAC no momento da redação deste artigo. Vale ressaltar que a Microsoft não considera o UAC um limite de segurança; no entanto, ainda relatamos vários bugs na Microsoft e quero compartilhar os detalhes da vulnerabilidade encontrada aqui. Este método foi testado com sucesso no Windows 10 Build 17134. Antes de me aprofundar nos detalhes da minha descoberta, primeiro darei uma pequena explicação sobre como o serviço UAC funciona.
Uac primerQuando um usuário que é membro do grupo Administradores deseja executar um aplicativo que requer privilégios elevados, o UAC exibe uma solicitação correspondente e um usuário que é membro do grupo Administradores precisa confirmar a ação.No entanto, essa solicitação do UAC não ocorre para TODOS os arquivos executáveis administrativamente no Windows . Existem algumas exceções que elevam “automaticamente” os privilégios de um arquivo executável sem causar uma solicitação de UAC, ignorando o UAC (para sua surpresa!). Esse grupo específico de executáveis confiáveis selecionados passa por verificações de segurança adicionais pelo sistema para garantir que esses arquivos sejam realmente confiáveis; portanto, os invasores de informações geralmente não abusam desse recurso. Essa abordagem foi usada nos métodos anteriores de desvio do UAC e será a base do meu novo método de desvio. No entanto, existem algumas brechas que precisamos tomar para que nosso ataque seja bem-sucedido. Vejamos os requisitos que devem ser atendidos se queremos que nosso executável seja "automaticamente elevado a privilégios". Para fazer isso, mostrarei algumas fotos da biblioteca desmontada appinfo.dll (o serviço AIS que processa solicitações de escalonamento de privilégios é um dos principais componentes do UAC).
Requisito 1: arquivo configurado para elevar privilégios automaticamente
Quando surge uma solicitação de escalação de privilégios para um programa, o serviço AIS (appinfo.dll) faz uma chamada RPC com o caminho executável de destino passado como argumento. Esse serviço mapeará o conteúdo executável de destino do arquivo para leitura. No manifesto do arquivo executável, é feita uma tentativa de ler o valor para obter a chave "autoElevate" (se existir).
Figura 1 - Lendo o manifesto do arquivo executável para obter o valor da chave "autoElevate".
Se o valor for recebido e for True, o arquivo será considerado como um arquivo executável de privilégio elevado "automático", que será executado com elevação de privilégio e não invocará a caixa de diálogo do serviço UAC (desde que cumpra os seguintes requisitos mencionados abaixo).
Figura 2 - chamando “bsearch” para verificar o nome do arquivo executável na lista de executáveis “auto elevating”
Alguns desses arquivos programados no sistema estão na lista de permissões:
'cttunesvr.exe', 'inetmgr.exe', 'migsetup.exe', 'mmc.exe', 'oobe.exe', 'pkgmgr.exe', 'provisionharehare', 'provisionstorage.exe', 'spinstall .exe ',' winsat.exe '
Requisito 2: Assinado corretamente
Supõe-se que a segunda condição para o aumento "automático" de privilégios após o envio de uma solicitação ao UAC seja executar uma verificação de assinatura usando "wintrust! WTGetSignatureInfo ".
Isso significa que o invasor não poderá simplesmente criar seu próprio arquivo de manifesto ou executável necessário para a elevação "automática" de privilégios e obter êxito, pois o arquivo binário do invasor provavelmente será assinado incorretamente e o último requisito, execução, também falhará. de um diretório confiável.
Requisito 3: Execução de um diretório confiável
O requisito final para obter uma elevação "automática" de privilégios é que o executável de destino esteja em um "diretório confiável", por exemplo, "C: \ Windows \ System32". A Figura 3 mostra que o AIS executa essa verificação do caminho com a solicitação de atualização. Nesse caso, um dos caminhos considerados “confiáveis” é “C: \ Windows \ System32”.
Figura 3
O título deste artigo é "Ignorar controle de conta de usuário (UAC) imitando diretórios confiáveis", para que você possa adivinhar facilmente o que acontecerá a seguir.
Bypass do UACComo mencionado anteriormente na seção UAC Primer, o privilégio automático (desvio do UAC) será executado para arquivos executáveis que:
- Configurado para receber escalonamento de privilégios "automático"
- Assinado corretamente
- Executar a partir de um diretório confiável ("C: \ Windows \ System32")
Appinfo.dll (AIS) usa a API RtlPrefixUnicodeString para verificar se o caminho do arquivo executável corresponde a “C: \ Windows \ System32 \” para verificar um dos diretórios confiáveis. Este é um teste de concreto bastante reforçado, dada a comparação com a localização do arquivo canônico.
Portanto, para organizar um desvio dessa verificação, eu crio um diretório chamado "C: \ Windows \" (observe o espaço após "Windows"). Obviamente, usando essa ação, você ainda não pode passar na verificação RtlPrefixUnicodeString, e também mencionarei que esse é um nome de diretório um tanto inválido (ou pelo menos "hostil"), pois o Windows não permite que espaços sejam adicionados ao final do nome ao criar o diretório (tente )
No entanto, usando a API CreateDirectory e adicionando "\\? \ "Para o nome do diretório que quero criar, podemos ignorar algumas dessas regras de filtragem de nomes e enviar uma solicitação para criar o diretório diretamente no sistema de arquivos.
Isso leva à criação de um diretório inconveniente que felizmente coexiste no sistema de arquivos junto com o real "C: \ Windows \" (exceto quando você está tentando fazer algo com ele no Windows Explorer).
Agora que temos o diretório "C: \ Windows \", podemos criar o diretório "System32" e copiar um dos arquivos executáveis assinados (que são permitidos pelo sistema para "automaticamente" elevar privilégios) do diretório real "C: \ Windows \ System32 ".
Para fazer isso, copiei o “winSAT.exe” (um dos arquivos da lista branca de arquivos executáveis do Windows com a elevação “automática” de privilégios permitidos pelo sistema).
Quando tentamos executar esse arquivo em nosso novo diretório “C: \ Windows \ System32 \ winSAT.exe”, ele percorre as seguintes APIs (consulte a Figura 6) em appinfo.dll antes de executar uma verificação de diretório confiável. Isso é importante e o fundamento do porquê essa solução alternativa funciona.
Figura 6
Quando esse caminho inconveniente com um espaço é enviado ao AIS para solicitar a escalação de privilégios, o caminho é passado para GetLongPathNameW, que o converte novamente em "C: \ Windows \ System32 \ winSAT.exe" (espaço removido).
Ótimo!
Agora, esta é a linha na qual a verificação de diretório válida foi aprovada (usando RtlPrefixUnicodeString) pelo restante da verificação.
A beleza da minha solução é que, depois de verificar o diretório confiável, esse caminho convertido é executado, que é liberado e o restante das verificações (e a solicitação final de escalação de privilégios) são realizadas com o nome original do diretório executável (com um espaço extra).
Isso me permite passar por todas as outras verificações e faz com que o appinfo.dll aceite minha cópia do winSAT.exe como tendo uma elevação "automática" de privilégios (uma vez que foi corretamente assinada e adicionada à lista branca de elevação "automática" de privilégios).
Para realmente usar o código malicioso, copiei o WINMM.dll falso (winSAT.exe importado) no meu diretório atual “C: \ Windows \ System32 \” para falsificar a dll local. O conceito completo pode ser visto na figura abaixo.
Figura 7
→
Link para o Github