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.
