vu-ls/crassusFerramenta de descoberta de escalonamento de privilégios do Windows que analisa logs de inicialização do Process Monitor para identificar sequestro de DLL, ACLs fracas e outros caminhos de elevação, gerando automaticamente código-fonte de DLL proxy.
Enable Boot Logging.
raw.PML.Ctrl-R.boot.PML.Crassus.exe boot.PML.results.csv.A Accenture criou uma ferramenta chamada Spartacus, que encontra oportunidades de sequestro de DLL no Windows. Usando o Spartacus como ponto de partida, criamos o Crassus para estender as capacidades de descoberta de escalonamento de privilégios no Windows além da simples busca por arquivos ausentes. As ACLs usadas por arquivos e diretórios de processos privilegiados podem encontrar mais do que apenas procurar por arquivos ausentes para atingir o objetivo.
...mas com uma diferença, pois o Crassus utiliza o SysInternals Process Monitor e analisa arquivos de log PML brutos. O uso típico é gerar um log de inicialização usando o Process Monitor e depois analisá-lo com o Crassus. Ele também gerará automaticamente código-fonte para DLLs proxy com todas as exportações relevantes para DLLs vulneráveis.
version.dll, o Crassus criará arquivos version.cpp e version.def para você com todas as exportações incluídas. Por padrão, as DLLs proxy iniciarão calc.exe. Scripts de compilação estão incluídos para compilar as DLLs no Visual Studio ou MinGW.A ideia geral de como o Crassus funciona pode ser resumida neste fluxograma:
O Crassus foi desenvolvido como um projeto do Visual Studio 2019. Para compilar Crassus.exe:
Crassus.slnCtrl+Shift+B no tecladoSe você confia em executar o código de outras pessoas sem saber o que ele faz, o Crassus.exe está fornecido neste repositório.
Enable Boot Logging.
Ctrl-R.boot.PML. O motivo para salvar novamente o arquivo de log é duplo:
| Argumento | Descrição |
|---|---|
<PMLFILE> | Localização (arquivo) do arquivo de log de eventos do ProcMon existente. |
--verbose | Ativar saída detalhada. |
--debug | Ativar saída de depuração. |
Analisar o log de inicialização do Process Monitor salvo em boot.PML. Todos os caminhos vulneráveis serão salvos como results.csv e todos os arquivos de origem da DLL proxy estarão no subdiretório stubs.
C:\tmp> Crassus.exe boot.PML
Abaixo está o modelo usado ao gerar DLLs proxy. Para DLLs encontradas pelo Crassus, a DLL proxy conterá os mesmos nomes de exportação especificados em %_EXPORTS_%, bem como os mesmos ordinais especificados no arquivo .def. O Crassus detectará se a DLL precisa ser compilada como uma biblioteca de 32 bits ou 64 bits observando a arquitetura do processo pai e marcando o código-fonte no campo %_BUILD_AS_% de acordo.
Se a DLL real não puder ser encontrada usando o log do Process Monitor, ou se o nome da exportação for problemático, os scripts de compilação recorrerão à criação de uma DLL sem exportações especificadas.
#pragma once
//%_BUILD_AS%
#include <windows.h>;
extern "C" {
VOID Payload() {
// Execute seu payload aqui.
WinExec("calc.exe", 1);
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
Payload();
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
#ifdef ADD_EXPORTS
%_EXPORTS_%
#endif
}
Para aplicativos que usam inseguramente o valor da variável OPENSSLDIR, um arquivo openssl.cnf personalizado pode ser colocado no local informado. Para este exemplo, o software carregará C:\tmp\calc.dll. Certifique-se de usar uma biblioteca de 32 bits para segmentar processos de 32 bits e uma biblioteca de 64 bits para segmentar processos de 64 bits.
[openssl_init]
# Isto tentará carregar o arquivo c:\tmp\calc.dll como parte da inicialização do OpenSSL
# Os scripts de compilação devem detectar se a biblioteca calc.dll precisa ser compilada como 32 bits ou 64 bits
/tmp/calc = asdf
A compilação é possível usando o binário cl.exe incluído no Visual Studio. Especificamente:
cl.exe /DADD_EXPORTS /D_USRDLL /D_WINDLL <target>.cpp /LD /Fe<target>.dll /link /DEF:<target>.def
Para automatizar o processo de compilação, incluindo especificar se a biblioteca deve ser de 64 ou 32 bits:
build.bat..dll.Observação: Devido a um comportamento infeliz do vcvarsall.bat, que definitivamente não é um bug, você pode encontrar problemas ao tentar executar build.bat mais de uma vez na mesma sessão do Prompt de Comando do Desenvolvedor do Visual Studio. Se encontrar um erro, simplesmente feche a janela e abra-a novamente.
Se o Visual Studio não estiver prontamente disponível, as DLLs proxy podem ser compiladas com MinGW-w64. Em uma plataforma Ubuntu, por exemplo, o MinGW pode ser instalado via: sudo apt install g++-mingw-w64-x86-64-win32 g++-mingw-w64-i686-win32
# Criar uma DLL de 32 bits
i686-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
i686-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows
# Criar uma DLL de 64 bits
x86_64-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
x86_64-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows
Para automatizar o processo de compilação, incluindo especificar se a biblioteca deve ser de 64 ou 32 bits:
bash ./build.sh.dll.Conforme descrito em VU#114757, versões mais antigas do software Acronis contêm múltiplas vulnerabilidades de escalonamento de privilégios.
openssl.cnf em um local criável por usuário não privilegiado.C:\ProgramData\Acronis.O Crassus encontra automaticamente esses dois problemas.
Ao plantar nosso arquivo curl.dll compilado no diretório C:\ProgramData\Acronis\Agent\var\atp-downloader\ e reiniciar com um novo log de inicialização do Process Monitor, podemos ver que nosso payload que executa calc.exe é executado com privilégios de SISTEMA.
O software Acronis vulnerável tenta carregar openssl.cnf de dois locais diferentes. Colocaremos nosso arquivo openssl.cnf modelo em c:\jenkins_agent\workspace\tp-openssl-win-vs2013\17\product\out\standard\vs_2013_release\openssl\ssl, e um payload calc.dll de 32 bits em c:\tmp.
Conforme descrito em VU#240785, versões mais antigas do software Atlassian Bitbucket são vulneráveis a escalonamento de privilégios devido a ACLs fracas do diretório de instalação. Como qualquer software Windows instalado em um local fora de C:\Program Files\ ou outros locais restritos por ACL, cabe ao instalador do software definir explicitamente ACLs no diretório de destino.
O Crassus encontra muitas maneiras de alcançar o escalonamento de privilégios com este software, incluindo:
Na saída do Crassus, podemos ver que c:\atlassian\bitbucket\7.9.1\elasticsearch\bin\elasticsearch-service-x64.exe é privilegiado, mas como está em execução, não podemos simplesmente substituí-lo. No entanto, podemos usar outro truque para sequestrá-lo. Podemos simplesmente renomear o diretório onde ele reside, criar um novo diretório com o mesmo nome e plantar nosso payload com o mesmo nome.
Assim que reiniciarmos com um log de inicialização do Process Monitor, podemos ver que nosso arquivo elasticsearch-service-x64.exe plantado está sendo executado em vez do real, com base no ícone da Calculadora do Windows.
Conforme descrito em VU#287178, versões mais antigas do software McAfee são vulneráveis a escalonamento de privilégios via openssl.cnf. Vamos dar uma olhada:
Para ver por que existem duas referências diferentes a openssl.cnf neste log de inicialização, podemos consultar o arquivo results.csv:
Observe que o carregamento do arquivo openssl.cnf do caminho D:\ exigirá investigação manual adicional, pois a viabilidade de carregar tal caminho depende da plataforma em questão e de qual acesso ao sistema está disponível. Pode ser possível criar um disco óptico que forneça um arquivo openssl.cnf que também se refira a um caminho que resolva para a unidade óptica.
O SQL Server 2022 não é obviamente vulnerável a escalonamento de privilégios devido a ACLs fracas, a menos que seja instalado em um local não padrão. Se for instalado em um local fora de C:\Program Files, o Crassus descobrirá várias possibilidades de escalonamento de privilégios. A maioria dos aplicativos Windows que incluem um componente privilegiado parece ser explorável dessa forma se for instalada em um diretório que já não tenha ACLs inerentemente seguras.
Se o Crassus relatar o carregamento privilegiado de um arquivo que um usuário pode plantar ou modificar, isso não significa necessariamente que seja um cenário explorável. Embora o Crassus procure por tipos de arquivo potencialmente interessantes, um arquivo de log do Process Monitor não indicará diretamente o que o processo associado faria com o arquivo se ele estivesse lá. Pode ser algo tão simples quanto extrair um ícone de programa. Investigar a pilha de chamadas da operação de arquivo no Process Monitor pode dar uma dica do que teria sido feito. Ou simplesmente coloque o arquivo e investigue o comportamento com um novo log de inicialização do Process Monitor, se preferir o caminho mais fácil da força bruta. Você também pode encontrar uma biblioteca ausente onde o Crassus não consegue encontrar a biblioteca para saber quais exportações devem estar presentes, ou as exportações que o Crassus encontram entram em conflito de uma forma que impede a compilação adequada da DLL. Nesses casos, o Crassus recorrerá à criação de uma DLL que não exporta nenhum nome de função. Dependendo de como o aplicativo de destino carrega a biblioteca, a ausência de nomes de função esperados e/ou números ordinais pode impedir que o aplicativo de destino carregue a biblioteca com sucesso. Este cenário exigirá esforço manual para determinar como a DLL proxy deve ser.
O Crassus procurará por operações de arquivo privilegiadas para descobrir caminhos de interesse. Você pode encontrar um cenário onde tanto um processo privilegiado quanto um não privilegiado acessam um caminho, mas apenas o processo não privilegiado é o que executa o que pode estar presente. Alternativamente, você pode encontrar um cenário onde um processo pai é executado com privilégios, mas pode explicitamente gerar processos filho com privilégios mais baixos.
Especialmente ao instalar software pela primeira vez, ou ao instalar atualizações, o Process Monitor pode registrar uma operação de arquivo que parece explorável, mas não ocorre toda vez que o sistema é inicializado. Explorar essas operações pode ser possível na primeira reinicialização após esse evento acontecer. Para evitar tais casos extremos, confirme que logs de inicialização subsequentes contêm as mesmas operações de arquivo relatadas em reinicializações subsequentes.
Seja um erro de digitação, um bug ou um novo recurso, o Crassus está muito aberto a contribuições, desde que concordemos com o seguinte: