fortra/cve-2023-28252Análise técnica e exploit de prova de conceito para CVE-2023-28252, uma vulnerabilidade de escalonamento de privilégio no driver do sistema de arquivos de log comum (CLFS) do Windows, usada em ataques de ransomware Nokoyawa.
Desde fevereiro de 2022 foi relatado um novo ransomware que parece estar usando uma vulnerabilidade de dia zero no Windows, de acordo com a pesquisa conduzida pela Trend Micro.
Mais informações sobre este ransomware podem ser encontradas neste link.
De acordo com a análise da Kaspersky, o grupo de ransomware Nokoyawa usou outras explorações direcionadas ao driver do Common Log File System (CLFS) desde junho de 2022, com características semelhantes, mas distintas, todas ligadas a um único desenvolvedor de explorações.
Em abril de 2023, quando a Microsoft lançou a correção, a CVE-2023-28252 foi atribuída.
Anteriormente, em 2022, um bug semelhante no mesmo componente foi pesquisado por nós e documentado neste artigo de blog
Para enfrentar a análise, é necessário conhecer o formato de arquivo .blf, que é manipulado pelo driver vulnerável Common Log File System chamado CLFS.sys e que está na pasta de drivers dentro de system32.
Mais informações sobre este tipo de arquivo podem ser encontradas nos links abaixo:
https://github.com/ionescu007/clfs-docs/blob/main/README.md
https://www.coresecurity.com/core-labs/articles/understanding-cve-2022-37969-windows-clfs-lpe
Esta análise é feita para Windows 11 21H2, clfs.sys versão 10.0.22000.1574, embora também funcione em Windows 10 21H2, Windows 10 22H2, Windows 11 22H2 e Windows Server 2022.
Em versões anteriores do Windows, é necessário ajustar alguns valores, caso contrário, produziríamos um BSOD.
Microsoft Patch Tuesday de abril de 2023.
Você pode verificar a versão do driver conforme mostrado
Quando a vulnerabilidade foi publicada, em abril de 2023, comecei com Esteban Kazimirow a realizar a engenharia reversa do driver CLFS.sys, embora neste caso, apenas analisar o patch foi muito difícil de deduzir onde estava o bug e como acioná-lo, já que a exploração é muito complexa.
Mais tarde, saiu um artigo de blog cujo autor, a partir de uma amostra de um malware, mostrou algumas partes do código descompilado pelo HexRays e algumas informações que orientaram onde a exploração deveria ser enfrentada.
Obviamente, as informações fornecidas não estavam completas, mas sem essa ajuda teria sido improvável ter conseguido construir o PoC e posteriormente um exploit funcional.
Para facilitar a compreensão, primeiro explicaremos como construir o PoC e depois faremos a análise da vulnerabilidade.
Este artigo de blog contém duas seções:
Construindo o PoC:
1- Obter os endereços do kernel que precisamos para a exploração
2- Preparando o caminho para criar os arquivos .blf:
3- Criar o arquivo "trigger blf" usando a função CreateLogFile()
4- Criar o arquivo "trigger blf"
5- Obter o endereço do kernel do BASE BLOCK do trigger blf
6- Chamar AddLogContainer com o handle do trigger blf
7- Preparando os arquivos spray blf
8- Preparando a memória para realizar o spray
9- Acionando o bug
Depuração:
1- Verificando o spray de memória
2- Observando o RecordOffset[12] do trigger blf
3- Observando o valor iFlushBlock no arquivo spray blf
4- Por que ele lê do BLOCK 1 SHADOW em vez do BLOCK 0 CONTROL?
5- Por que o checksum é igual a zero nos arquivos spray blf?
6- Finalizando a exploração.
7- O patch real
Vou criar uma função chamada InitEnvironment para obter alguns endereços necessários do kernel.
Obter o endereço EPROCESS do meu processo e armazená-lo na variável g_EProcessAddress, depois o endereço EPROCESS do processo SYSTEM e armazená-lo em system_EPROCESS, depois o endereço EHTREAD da thread principal do meu processo e armazená-lo em g_EThreadAddress e finalmente o endereço do PREVIOUS MODE que nesta versão do PoC não será usado.
Este método é bem conhecido, a função GetObjectKernelAddress chama NtQuerySystemInformation duas vezes com o primeiro argumento SystemExtendedHandleInformation, a primeira chamada é passada com um tamanho incorreto e retorna erro, mas também retorna o tamanho correto que é usado na segunda chamada e obtém as informações de todos os handles, então percorrendo em um loop as informações de cada handle e no campo Object do handleinfo correto obtém o endereço pesquisado no kernel.
Também preciso dos endereços do kernel das seguintes funções exportadas por CLFS.sys:
• ClfsEarlierLsn
• ClfsMgmtDeregisterManagedClient
E as funções exportadas de NTOSKRNL.exe
• RtlClearBit/PoFxProcessorNotification
• SeSetAccessStateGenericMapping
Para obter esses endereços, usa um método semelhante ao usado para obter a base do kernel de ambos os módulos, chamando NtQuerySystemInformation duas vezes, mas neste caso o primeiro argumento será SYSTEM_INFORMATION_CLASS (no PoC usamos a função FindKernelModulesBase para esse propósito).
Em seguida, carrega CLFS.sys e NTOSKRNL.exe como módulos normais no modo de usuário chamando LoadLibrary, obtém os endereços no modo de usuário com GetProcAddress e então subtrai a imagebase de cada um, o que obtém o offset da função e finalmente adiciona cada offset às bases do kernel correspondentes e, com isso, obtém os endereços do kernel de todas as funções necessárias.
Crio uma função chamada createInitialTriggerBlfFile que irá gerar e escrever um arquivo .blf.
O caminho que é usado como argumento no CreateLogFile é diferente de um caminho normal, por exemplo, para abrir o arquivo 1280.blf localizado na pasta C:\Users\Public, devemos definir o caminho LOG:C:\Users\Public\1280. Isso será salvo na variável stored_name_CreateLog.
Faço isso usando wsprintfW() já que stored_env armazena o caminho C:\Users\Public, obtido anteriormente das variáveis de ambiente. A esta string vou preceder a string LOG: e um nome aleatório no final, sem a extensão .blf.
