Informação

==============

Corrupção do Pool do Kernel do Windows (clfs.sys) para Elevação de Privilégio. (CVE-2023-36424)

Este repositório contém análise técnica & exploit funcional.

Autor: Nassim Asrir (@p1k4l4) || https://www.linkedin.com/in/nassim-asrir-b73a57122/

Vulnerabilidade

================

Há um estouro de pool no driver de mini filtro clfs.sys. Informações sobre isso podem ser lidas em:

1 - https://googleprojectzero.blogspot.com/2021/01/hunting-for-bugs-in-windows-mini-filter.html

2 - https://www.zerodayinitiative.com/blog/2021/7/19/cve-2021-31969-underflowing-in-the-clouds

O motivo é que o driver não verifica suficientemente os dados provenientes de um ponto de reanálise NTFS.

Consideraremos a versão 10.0.22621.2134 do clfs.sys (Windows 11 22H2 22621.2215)

A função HsmFltProcessHSMControl é responsável pelo processamento de FSCTLs de filtro de nuvem. Para uma operação com código 0xC0000003, ela acabará chamando HsmFltProcessUpdatePlaceholder.

Após algum processamento, o fluxo de execução chegará a HsmiOpUpdatePlaceholderDirectory e, finalmente, a HsmpRpCommitNoLock:

__int64 __fastcall HsmpRpCommitNoLock(__int64 a1, __int64 a2, struct _FILE_OBJECT *a3, char a4, char a5)

{ .....

v26 = FileObject; LODWORD(v9) = HsmpRpReadBuffer(*(PFLT_INSTANCE *)(v164 + 32), FileObject, (unsigned __int16 **)&P); // [1*]

HsmDbgBreakOnStatus((unsigned int)v9);

if ( (_DWORD)v9 == -1073741195 ) .....

goto LABEL_55; }

if ( (v9 & 0x80000000) != 0i64 )

goto LABEL_9;}
 

if ( (*(_DWORD *)P & 0xFFFF0FFF) != dword_1C0027650 )// Is
Cloud Reparse Tag?
{
LODWORD(v9) = 0xC000CF0B;
.....
goto LABEL_54;
}
v32 = *((unsigned __int16 *)P + 2);
v9 = (unsigned int)HsmpRpValidateBuffer((__int64)P + 8, v32); [2*]
.....
Pool2 = ExAllocatePool2(0x100i64, 0x4000i64, 'pRsH'); // [3*]
v146 = (_DWORD *)Pool2;
v13 = (void *)Pool2;
if ( Pool2 )
{
v64 = v159_10;
v65 = Pool2 + 4;
if ( v8 && *((_WORD *)v8 + 7) > 0xAu )
v64 = *((_WORD *)v8 + 7);
v9 = Pool2 + 20;
v66 = (unsigned int *)(Pool2 + 12);
*(_OWORD *)v65 = 0i64;
*(_WORD *)(Pool2 + 16) = 0;
*(_WORD *)(Pool2 + 18) = v64;
*(_DWORD *)(Pool2 + 12) = 8 * v64 + 16;
*(_DWORD *)v65 = 'pReF';
memset((void *)(Pool2 + 20), 0, 8i64 * v64);
.....
if ( v8 )
{
v127 = 10;
if ( *((_WORD *)v8 + 7) > 0xAu ) // [4*]
{
if ( WPP_GLOBAL_Control !=
(PDEVICE_OBJECT)&WPP_GLOBAL_Control
&& (HIDWORD(WPP_GLOBAL_Control->Timer) & 1) != 0

&& BYTE1(WPP_GLOBAL_Control->Timer) >= 4u )
{
WPP_SF_qiq(WPP_GLOBAL_Control->AttachedDevice, v86,
v87, a2, *(_QWORD *)(v156 + 32), FileObject);
}
while ( v127 < *((_WORD *)v8 + 7) )
{
*(_QWORD *)(v65 + 8i64 * v127 + 16) = *(_QWORD
*)&v8[8 * v127 + 16];
memmove(
(void *)(v65 + *v66),
&v8[*(unsigned int *)&v8[8 * v127 + 20]],
*(unsigned __int16 *)&v8[8 * v127 + 18]); //
[5*]
*(_DWORD *)(v65 + 8i64 * v127 + 20) = *v66;
*v66 += *(unsigned __int16 *)(v65 + 8i64 * v127++ +
18);
}
}
}
.....
}

HsmpRpReadBuffer [1*] recupera dados de ponto de reanálise. Esses dados contêm um valor do tamanho WORD *((_WORD *)v8 + 7), especificando uma contagem dos itens estruturados. Cada item possui um campo Tipo, Tamanho e Deslocamento para campos de dados.

Qual tipo de item em qual lugar é estritamente predeterminado. Mas apenas para os primeiros 10. Por exemplo, o campo de tipo do primeiro item deve ter um valor igual a 0x7.

O driver executará HsmpRpValidateBuffer [2*] para verificar os dados adquiridos. Em seguida, [3*] será alocado um pool paginado com tamanho fixo de 0x4000 bytes. E se os dados do ponto de reanálise tiverem um valor de Contagem maior que 10, então os dados dos itens após o décimo serão copiados para este pool de tamanho fixo [4*] sem quaisquer verificações adicionais.

A validação dentro de HsmpRpValidateBuffer é insuficiente, pois verifica apenas os primeiros 10 registros.

__int64 __fastcall HsmpRpValidateBuffer(__int64 pBuf, unsigned int a2)
{
.....
v2 = a2 - 4;
pBuf2 = pBuf + 4;
LOBYTE(v5) = 0;
v6 = 0i64;
if ( a2 <= 4 )
v2 = 0;
v7 = 0;
v8 = *(_DWORD *)pBuf & 0xF;
if ( !v8 )
{
.....
return IsReparseBufferSupported;
}
if ( v8 > 1 )
{
....
}
v9 = 0;
v66 = 0;
if ( v2 < 0x18 )
goto ERROR_EXIT;
v9 = 1;
if ( *(_DWORD *)pBuf2 != 'pReF' )
goto ERROR_EXIT;
v9 = 2;
v10 = (unsigned int *)(pBuf + 0xC);
if ( (*(_BYTE *)(pBuf + 16) & 2) != 0 && *(_DWORD *)(pBuf +
8) != RtlComputeCrc32(0, (PUCHAR)(pBuf + 0xC), v2 - 8) )
goto ERROR_EXIT;
v11 = *v10;
v9 = 3;
if ( v2 < (unsigned int)v11 )
goto ERROR_EXIT;
v12 = *(unsigned __int16 *)(pBuf2 + 0xE);
v9 = 4;
if ( !(_WORD)v12 )
goto ERROR_EXIT;
v13 = 8 * v12 + 16;

v9 = 5;
if ( v13 >= v11 )
goto ERROR_EXIT;
v9 = 0x10000;
for ( i = 0; ; ++i )
{
v15 = *(unsigned __int16 *)(pBuf2 + 0xE);
if ( (unsigned int)v12 >= 0xA ) // [1*]
v15 = 10;
if ( i >= v15 )
break;
}

Como podemos ver [1*], o código verifica apenas os primeiros 10 itens e ignora o caso de haver mais registros.

Exploração

================

O tamanho do pool vulnerável é 0x4000. O tamanho é um múltiplo de página e, portanto, a alocação de segmento será usada [3].

Para a exploração, foi usada a técnica descrita aqui[4]. Chamar NtAlpcCreateResourceReserve criará muitos manipuladores e sobrescrever um deles com o ponteiro para um objeto _KALPC_RESERVE falso construído nos dará a capacidade de escrever em um endereço arbitrário do kernel.

Para preparar a memória, alocamos sequencialmente pools de tamanho 0x4000, usando pipes[5]. Em seguida, liberamos a cada segundo pool, fornecendo um lugar para o buffer vulnerável.

Para ler um endereço arbitrário do kernel, o exploit utilizou pipes. Para isso, sobrescreveremos o ponteiro AttributeValue da estrutura PipeAttribute.

E depois, podemos roubar o token do sistema para sobrescrever o token no processo alvo.

Obrigado pela leitura.