l3cr0f/dccwbypassuacBypass de UAC no Windows 8.1 e 10 abusando do WinSxS em "dccw.exe".
Este exploit abusa da forma como o "WinSxS" é gerenciado pelo "dccw.exe" por meio de um método derivado do "Bypass UAC" de Leo Davidson, de modo a obter um shell de administrador sem solicitar consentimento. Ele suporta as arquiteturas "x86" e "x64". Além disso, foi testado com sucesso no Windows 8.1 9600, Windows 10 14393, Windows 10 15031 e Windows 10 15062.
Se você quiser ver como executar o script, dê uma olhada na seção de uso. Você também pode executá-lo no Metasploit e obter uma sessão Meterpreter com direitos de administrador.
Para desenvolver um novo bypass UAC, primeiro temos que encontrar uma vulnerabilidade no sistema e, para ser mais preciso, uma vulnerabilidade em um processo de elevação automática. Para obter uma lista desses processos, usamos a ferramenta Sysinternals chamada Strings. Depois disso, pudemos ver alguns processos de elevação automática como "sysprep.exe", "cliconfig.exe", "inetmgr.exe", "consent.exe" ou "CompMgmtLauncher.exe" que tinham (alguns ainda têm) vulnerabilidades que permitem a execução de um "bypass UAC". Então, começamos a estudar como outros processos de elevação automática funcionavam com o aplicativo Sysinternals chamado Process Monitor (ProcMon), mas com foco no processo "dccw.exe".
No entanto, antes de começar com o ProcMon, primeiro verificamos o manifesto de tais aplicativos com outro aplicativo Sysinternals chamado Sigcheck e, claro, no nosso caso, o "dccw.exe" é um processo de elevação automática.
Então, pudemos começar a seguir o fluxo de execução do "dccw.exe" com o ProcMon para ver se algo estranho ocorre, algo que verificamos imediatamente. Em determinado momento, se executarmos o "dccw.exe" como um processo de 64 bits em uma máquina Windows de 64 bits, ele procura o diretório "C:\Windows\System32\dccw.exe.Local\" para carregar uma DLL específica chamada "GdiPlus.dll", assim como se fosse executado em uma máquina Windows de 32 bits, enquanto que, se o executarmos como 32 bits na mesma máquina, o processo procurará o diretório "C:\Windows\SysWOW64\dccw.exe.Local\". Então, devido ao fato de que ele não existe, o processo sempre procura uma pasta no caminho "C:\Windows\WinSxS\" para obter a DLL desejada; essa pasta tem um nome com a seguinte estrutura:
[architecture]_microsoft.windows.gdiplus_[sequencial_code]_[Windows_version]_none_[sequencial_number]
Se olharmos para o diretório "WinSxS", poderemos ver mais de uma pasta que corresponde a essa estrutura; isso significa que o "dccw.exe" pode carregar a DLL desejada de qualquer uma dessas pastas. A única coisa da qual temos certeza é que, se o aplicativo for invocado como um processo x86, o nome da pasta começará com a string "x86", enquanto que, se o executarmos como um processo x64, o nome começará com a string "amd64".
Essa situação pode ser abusada para realizar um sequestro de DLL e, em seguida, executar código com alta integridade sem solicitar consentimento.
Depois de encontrarmos um erro durante a execução de um processo de elevação automática, precisamos verificar se ele pode ou não ser abusado. Para isso, simplesmente criamos a pasta "dccw.exe.Local" no caminho desejado e, dentro dessa pasta, criamos as pastas localizadas em "WinSxS" que poderiam ser invocadas pelo processo para carregar "GdiPlus.dll", mas sem essa DLL.
Agora, se executarmos o "dccw.exe", veremos que o processo encontrou a pasta "dccw.exe.Local" e uma das pastas "WinSxS", mas não a DLL desejada, algo que gera um erro. Isso é o que esperávamos, porque essa situação pode ser explorada por um atacante, como mencionamos antes.
Neste ponto, já sabemos que podemos realizar um bypass UAC no Windows 10 abusando do "dccw.exe", mas como?
O método mais usado para bypass UAC é o desenvolvido por Leo Davidson. No entanto, ele realiza uma injeção de processo para invocar o objeto COM IFileOperation, o que pode ser detectado por alguns antivírus; portanto, uma abordagem melhor é a chamada Masquerade PEB, usada pelo Cn33liz em seu próprio bypass UAC.
Além disso, temos que modificar a forma como o IFileOperation é invocado nas versões mais recentes do Windows 10, já que o método de Leo Davidson dispara o UAC a partir do build 15002. Portanto, a maneira como temos que invocar essa operação é a mesma da original, mas sem os flags de operação "FOF_SILENT", "FOFX_SHOWELEVATIONPROMPT" e "FOF_NOERRORUI".
Antes de executar o exploit, é importante verificar alguns aspectos para não executá-lo sem sucesso e, portanto, disparar alguns alarmes. A primeira coisa que verificamos é a versão do build do Windows, pois algumas versões não são vulneráveis ao nosso exploit (aquelas com versão de build inferior a 7600). Depois disso, verificamos se ainda não temos direitos de administrador; se for o caso, não há motivo para executar o script. Em seguida, verificamos as configurações de UAC para confirmar que não está definido como "Notificar sempre", pois se estivesse definido para esse valor, nosso exploit seria inútil. Finalmente, verificamos se o usuário pertence ao grupo de administradores, porque, se não pertencer, o exploit não teria sucesso.
Quando um exploit é desenvolvido, é importante que ele funcione no maior número possível de sistemas; isso inclui sistemas Windows de 32 bits. Para conseguir isso, precisamos compilar nosso exploit para tais sistemas, já que também podemos executá-lo em sistemas de 64 bits.
Quando nosso exploit de 32 bits é executado em uma máquina Windows de 64 bits, a forma como o "dccw.exe" opera é um pouco diferente devido à invocação do WOW64 (subsistema do Windows que permite que máquinas de 64 bits executem aplicativos de 32 bits). Isso significa que a pasta "dccw.exe.Local" será procurada no diretório "C:\Windows\SysWOW64\", em vez de "C:\Windows\System32\", mas também a "GdiPlus.dll" alvo será uma DLL de 32 bits, o que implica que ela será procurada em uma pasta que corresponda ao padrão de nome "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*". No entanto, se for executado em um sistema Windows de 32 bits, o exploit funcionará como esperado.
Finalmente, é importante ressaltar que precisamos considerar todos os caminhos que correspondem ao padrão "C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_*" quando o sequestro de DLL é realizado, a fim de garantir 100% de eficácia.
Para executar um processo com alta integridade, precisamos desenvolver uma DLL que será invocada por meio de sequestro de DLL. No entanto, não é tão simples quanto parece, porque, se fizermos apenas isso, nem o "dccw.exe" nem nosso código serão executados. Isso ocorre porque o "dccw.exe" depende de algumas funções da "GdiPlus.dll", então precisamos implementar ou encaminhar a execução dessas funções para a DLL legítima.
A melhor opção é encaminhar a execução para a DLL legítima, porque, dessa forma, o tamanho da nossa DLL será menor. Para isso, usamos o programa ExportsToC++ para portar todos os exports da "GdiPlus.dll" para a linguagem C++. Agora, o problema é o enorme número de exports que a "GdiPlus.dll" possui, 631 para ser preciso. No entanto, o "dccw.exe" não importa todos eles, mas alguns poucos. Para saber quais funções são importadas pelo "dccw.exe" da "GdiPlus.dll", fizemos engenharia reversa com o "IDA Pro". Finalmente, apenas 15 funções são importadas da "GdiPlus.dll", então só precisamos incluir essas em nossa DLL.
Agora, parece que o problema foi resolvido, mas se encaminharmos a execução para uma "GdiPlus.dll" específica em C:\Windows\WinSxS\", a DLL funcionará apenas em alguns sistemas, pois o nome das pastas internas do "WinSxS" muda a cada build do Windows. Para superar esse problema, tivemos a ideia de encaminhar a execução para "C:\Windows\System32\GdiPlus.dll", devido ao fato de que o caminho é o mesmo em todos os sistemas Windows 10
A última coisa que precisamos fazer é interromper a execução do "dccw.exe" após executar nosso código malicioso, para evitar a abertura da janela desse processo.
Agora, depois de desenvolvermos nossa DLL maliciosa, precisamos soltá-la na máquina alvo. Para isso, nossa DLL foi compactada e codificada em "base64" no exploit, para que possa ser decodificada e descompactada em tempo de execução e solta como esperado.
Finalmente, nossa "GdiPlus.dll" personalizada é copiada para o local alvo usando o objeto COM IFileOperation, como mencionado anteriormente.
Quando um atacante compromete um sistema, ele deseja permanecer indetectado pelo maior tempo possível; isso significa remover todos os vestígios das ações que realiza. Por causa disso, todos os arquivos temporários criados durante a execução do exploit são removidos quando não são mais necessários.
Finalmente, precisamos determinar qual processo queremos executar com alta integridade. No nosso caso, escolhemos o aplicativo "cmd.exe" porque ele nos permite realizar quantas operações de alta integridade quisermos, uma vez que teremos direitos de administrador, mas, na verdade, podemos executar qualquer aplicativo que desejarmos.
Para executar o exploit, você deve ter certeza de que a máquina alvo atende aos requisitos. Então, você simplesmente tem que executar o exploit como qualquer outro script de linha de comando:
C:\Users\L3cr0f> DccwBypassUAC.exe
O módulo Metasploit deste PoC usa injeção de DLL em vez de Masquerading PEB e está disponível em:
- Metasploit Framework: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/local/bypassuac_injection_winsxs.rbEste exploit foi desenvolvido para mostrar como um atacante poderia obter privilégios em um sistema, não para usá-lo para fins maliciosos. Isso significa que não assumo qualquer responsabilidade se alguém o usar para realizar atividades criminosas.
User Access Control (UAC) é uma tecnologia introduzida com o Windows Vista que fornece um método de separar privilégios e tarefas de usuário padrão daquelas que exigem acesso de Administrador. Se um Usuário Padrão estiver usando o sistema e tentar executar uma ação para a qual não tem autorização, um prompt do Windows aparece e solicita a senha da conta de Administrador. Se um Administrador estiver usando o sistema e tentar fazer a mesma tarefa, há apenas um prompt de aviso. Esse prompt é conhecido como "Prompt de Consentimento" porque se pede apenas que o administrador concorde com a ação antes de prosseguir. Uma fraqueza que permitiria contornar o "Prompt de Consentimento" não é considerada uma vulnerabilidade de segurança, pois isso não é considerado um limite de segurança.
No entanto, a Microsoft também afirma que "User Account Control (UAC) é um componente fundamental da visão geral de segurança da Microsoft".
Fontes:
- Definição de vulnerabilidade de segurança.
- Como o Controle de Conta de Usuário funciona.