Informazioni

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

Escalation dei privilegi tramite corruzione del pool del kernel Windows (clfs.sys). (CVE-2023-36424)

Questo repository contiene l'analisi tecnica e l'exploit funzionante.

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

Vulnerabilità

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

Nel driver mini-filter clfs.sys è presente un overflow del pool. Le informazioni a riguardo si possono leggere su:

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

Il motivo è che il driver non verifica sufficientemente i dati che provengono da un reparse point NTFS.

Prenderemo in considerazione la versione di clfs.sys 10.0.22621.2134 (Windows 11 22H2 22621.2215)

La funzione HsmFltProcessHSMControl è responsabile dell'elaborazione degli FSCTL del cloud filter. Per un'operazione con codice 0xC0000003, chiama infine HsmFltProcessUpdatePlaceholder.

Dopo alcune elaborazioni, il flusso di esecuzione raggiunge HsmiOpUpdatePlaceholderDirectory e infine 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 i dati del reparse point. Questi dati contengono un valore di dimensione WORD, *((_WORD *)v8 + 7), che specifica un conteggio degli elementi strutturati. Ogni elemento ha un campo Type, Size e Offset verso i campi dati.

Quale tipo di elemento debba trovarsi in quale posizione è strettamente predeterminato. Ma solo per i primi 10. Ad esempio, il campo type del primo elemento deve avere un valore pari a 0x7.

Il driver esegue HsmpRpValidateBuffer [2*] per verificare i dati acquisiti. Quindi [3*] viene allocato un pool paginato con dimensione fissa di 0x4000 byte. E se i dati del reparse point hanno un valore Count maggiore di 10, i dati degli elementi successivi al decimo vengono copiati in questo pool a dimensione fissa [4*] senza ulteriori controlli.

La validazione all'interno di HsmpRpValidateBuffer è insufficiente, perché controlla solo i primi 10 record.

__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;
}

Come possiamo vedere [1*], il codice verifica solo i primi 10 elementi e ignora il caso in cui ci siano più record.

Sfruttamento

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

La dimensione del pool vulnerabile è 0x4000. La dimensione è un multiplo della pagina e pertanto verrà utilizzata la segment allocation [3].

Per lo sfruttamento è stata utilizzata la tecnica descritta qui[4]. La chiamata a NtAlpcCreateResourceReserve crea un gran numero di handle; sovrascrivere uno di essi con il puntatore a un oggetto _KALPC_RESERVE falso costruito ad hoc ci dà la capacità di scrivere a un indirizzo kernel arbitrario.

Per preparare la memoria, allochiamo sequenzialmente pool di dimensione 0x4000 usando pipe[5]. Quindi libereremo ogni secondo pool, fornendo un posto per il buffer vulnerabile.

Per leggere un indirizzo kernel arbitrario, l'exploit utilizza le pipe. A questo scopo sovrascriviamo il puntatore AttributeValue della struttura PipeAttribute.

E successivamente, possiamo rubare il token di sistema per sovrascrivere il token nel processo target.

Grazie per la lettura.