Après avoir rétroconçu un certain nombre de gestionnaires de services [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) du pilote « SDDisk2k.sys », il a été découvert qu'un d'entre eux expose des fonctionnalités critiques en mode utilisateur, en ce sens qu'il autorise des opérations de lecture et d'écriture sur les secteurs bruts d'un disque arbitraire - par conception. De plus, en s'interfaçant avec ce code même, il a été remarqué que le pilote ignore tout verrou exclusif qui aurait pu être défini précédemment sur un disque. Par conséquent, des opérations concurrentes de lecture/écriture deviennent possibles, ce qui facilite les conditions de concurrence et risque une perte de données.

Ce qui suit montre le gestionnaire de services IOCTL décompilé du pilote responsable du traitement des requêtes de lecture des secteurs bruts de disque. Il appelle une fonction sub_29CD4() avec un argument "controlled_buf", qui est un pointeur vers un tampon dont le contenu peut être choisi arbitrairement par toute application appelante en mode utilisateur :``` c
if ( ioctlcode == 0x8D1F2824 )   // <--- I/O control code for raw disk reading functionality
{
  controlled_buf = (unsigned __int8 *)controlled_addr;
  mode = 0;
  temp_result = sub_29CD4((char *)controlled_buf, v3, mode);   // <--- call to raw disk read function

// get object pointer of drive
if ( IoGetDeviceObjectPointer(&DestinationString, 0x80u, &FileObject, &DeviceObject) >= 0
  || (v12 = sub_2C5D4(&DestinationString, &DeviceObject), v12 >= 0) )
{
  // extract further fields from structure
  offset = *(_QWORD *)(p + 0x4E);                    // <--- where to start reading from
  length = *(_DWORD *)(p + 0x56);                    // <--- number of bytes to read
  ptr_buf = *(void **)(p + 0x5A);                    // <--- ptr to destination buffer
  devobj = DeviceObject;
  StartingOffset.QuadPart = offset << 9;
  KeInitializeEvent(&Event, NotificationEvent, 0);
  
  // build request
  v17 = IoBuildSynchronousFsdRequest(
          (unsigned int)(mode != 0) + IRP_MJ_READ,   // <--- issue read request
          devobj,
          ptr_buf,
          length << 9,
          &StartingOffset,
          &Event,
          &IoStatusBlock);
  v18 = v17;
  if ( v17 )
  {
    v19 = v17->Tail.Overlay.CurrentStackLocation;
    if ( mode )
      v19[0xFFFFFFFF].Flags |= 0x10u;
    ObfReferenceObject(devobj);

    // send request to respective device object (issue read request)
    v12 = IofCallDriver(devobj, v18);

Tout comme la lecture de secteurs de disque bruts, l'écriture de secteurs de disque depuis le mode utilisateur est rendue possible en appelant le gestionnaire IOCTL 0x8D1F2820, qui traite la même structure de données et est implémenté de manière similaire. Étant donné la compatibilité avec le protocole de ce pilote, rien n'empêche des applications arbitraires en mode utilisateur de compromettre complètement le système d'exploitation. Sauf protection par un mécanisme de démarrage sécurisé, cela inclut même l'installation de logiciels autorisés à s'exécuter dès le processus de démarrage du système (ransomwares, bootkits, implants personnalisés...).

### CVE-2020-11520
Un examen plus approfondi des gestionnaires de service du pilote "SDDisk2k.sys" a révélé que les adresses mémoire provenant d'applications en mode utilisateur sont traitées sans validation préalable. Dans certains cas, la mémoire accédée par ces pointeurs est écrite aveuglément par le pilote, ce qui peut être exploité par des attaquants pour créer des primitives d'écriture noyau. Alors que toutes les primitives d'écriture permettent de contrôler directement **où** écrire les données, aucune n'a malheureusement été trouvée qui permettrait de contrôler directement **quoi** écrire. À l'exception de [CVE-2020-11519](#cve-2020-11519), dont l'exploitation dans ce contexte nécessiterait un détour supplémentaire par des opérations de lecture/écriture de disque, ce que je considère comme une approche sale et que je voulais donc éviter. Cependant, un gestionnaire particulier a été identifié qui, certes, ne permettait pas de contrôler les données elles-mêmes, mais s'est avéré suffisant pour être réutilisé par d'autres moyens.

Le code décompilé ci-dessous montre le gestionnaire de service du pilote pour le code IOCTL 0x8d1f282c. Il prend un nombre entier 16 bits "count" depuis un buffer contrôlé par l'utilisateur, puis s'assure qu'il ne dépasse pas une certaine limite. Enfin, un pointeur "dst" est acquis depuis le même buffer d'entrée contrôlé, mais il n'est jamais vérifié pour sa validité avant d'être passé comme argument à un appel ultérieur à memmove(). À ma déception initiale, le buffer "src" qui est passé comme argument à memmove() n'est pas contrôlé mais pointe plutôt vers une chaîne codée en dur ("FRNSecureDoc v4.1\0"), ce qui limite son utilité pour l'exploitation dans une certaine mesure. Évidemment, ce gestionnaire de service écrit un identifiant de version dans une adresse spécifiable par l'utilisateur, ce qui peut tout aussi bien être abusé pour le fingerprinting de versions vulnérables de Winmagic SecurDoc.``` c
// handler for I/O control code 0x8d1f282c

// get "count" from controlled buffer
count = *((_WORD *)controlled_buf + 5);

// if count is zero, return error
if ( !count )
{
  *((_WORD *)controlled_buf + 5) = 0x13;
  goto leave_dispatcher;
}

// otherwise further sanitize and limit "count"
if ( count >= 0x12u )
  count = 0x11;

// bug! controlled pointer, passed from userland!
dst = *(void **)(controlled_buf + 2);
src = aFrnsecuredocV4;   // <--- 'FRNSecureDoc v4.1',0

// unchecked write!
memmove(dst, src, count);
goto leave_dispatcher;

La structure SEP_TOKEN_PRIVILEGES est un ensemble de bitmasks dont chaque bit individuel représente un indicateur de privilège. Par voie de conséquence logique, demander aimablement au pilote SecureDoc de stocker des parties de sa chaîne de version "FRNSecureDoc v4.1\0" dans la structure SEP_TOKEN_PRIVILEGES d'un jeton de processus devrait faire basculer quelques bits et, espérons-le, activer des privilèges utiles, du moins hypothétiquement. Il s'avère qu'en faisant stocker au pilote les deux premiers caractères de sa chaîne de version dans les offsets 1 et 2 du champ "Present" de la structure SEP_TOKEN_PRIVILEGE, un certain nombre de privilèges de jeton intéressants sont définis. Le caractère '**F**' extrait de "**F**RNSecureDoc v4.1\0" vaut 01000110 et définit donc le bit 9 (SeTakeOwnershipPrivilege), le bit 10 (SeLoadDriverPrivilege) et le bit 14 (SeIncreaseBasePriorityPrivilege) du champ "Present". Le caractère '**R**' vaut 01010010, définissant le bit 17 (SeBackupPrivilege), le bit 20 (SeDebugPrivilege) et le bit 22 (SeSystemEnvironmentPrivilege) :

| N° de bit ("Present") | Caractère | Byte         | Privilège |
| :--------------: | :-------: | ------------ | --------- |
| 8                | 'F'       | 0100011**0** | SeSecurityPrivilege |
| 9                | 'F'       | 010001**1**0 | **SeTakeOwnershipPrivilege** |
| 10               | 'F'       | 01000**1**10 | **SeLoadDriverPrivilege** |
| 11               | 'F'       | 0100**0**110 | SeSystemProfilePrivilege |
| 12               | 'F'       | 010**0**0110 | SeSystemtimePrivilege |
| 13               | 'F'       | 01**0**00110 | SeProfileSingleProcessPrivilege |
| 14               | 'F'       | 0**1**000110 | **SeIncreaseBasePriorityPrivilege** |
| 15               | 'F'       | **0**1000110 | SeCreatePagefilePrivilege |
| 16               | 'R'       | 0101001**0** | SeCreatePermanentPrivilege |
| 17               | 'R'       | 010100**1**0 | **SeBackupPrivilege** |
| 18               | 'R'       | 01010**0**10 | SeRestorePrivilege |
| 19               | 'R'       | 0101**0**010 | SeShutdownPrivilege |
| 20               | 'R'       | 010**1**0010 | **SeDebugPrivilege** |
| 21               | 'R'       | 01**0**10010 | SeAuditPrivilege |
| 22               | 'R'       | 0**1**010010 | **SeSystemEnvironmentPrivilege** |
| 23               | 'R'       | **0**1010010 | SeChangeNotifyPrivilege |

## Exploit de preuve de concept

Un [exploit de preuve de concept](https://github.com/patois/winmagic_sd/blob/master/sd_poc.py) a été développé en Python et débogué à l'aide du [débogueur de noyau WinDbg de Microsoft](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-toolsk), attaché à une machine virtuelle Windows 10 x64.

Cet exploit de preuve de concept acquiert l'adresse noyau du jeton de sécurité du processus en cours et, entre autres, active le privilège SeDebugPrivilege en exploitant les vulnérabilités décrites. Il passe ensuite au lancement d'un shell de commandes qui hérite des privilèges nouvellement élevés du jeton.

Avoir le drapeau SeDebugPrivilege défini permettra d'injecter du shellcode et de l'exécuter dans le contexte d'un processus SYSTEM - je vous laisse cependant cette partie ;)``` python
token_addr = sdi.get_token_obj()
if not token_addr:
    print("[!] Could not get address of token")
    sdi.close()
    return

print("[+] Got token object: %x" % token_addr)
print("[+] Patching token")
sdi.acquire_debug_privs(token_addr)
sdi.close()

os.system("cmd.exe")

Le code de l'exploit PoC peut être trouvé [ici](https://github.com/patois/winmagic_sd/blob/HEAD/sd_poc.py). Il cible la v8.5 de Winmagic SecureDoc x64 mais pourrait fonctionner sur des versions plus anciennes (non testées).

Si vous êtes arrivé jusqu'ici mais que vous vous ennuyez toujours, n'hésitez pas à composer le code IOCTL 0x8D1F2848 ;)``` c
case 0x8D1F2848:
  DbgPrint("SDDEV_IO_BLUE_SCREEN comes in ...");
  if ( *(_WORD *)controlled_buf == 0x55AA
    && *(_QWORD *)(controlled_buf + 2)
    && *((_WORD *)controlled_buf + 5) == 4 )
  {
    StartContext = ExAllocatePoolWithTag(PoolType, 4ui64, 'gaMW');
    if ( !StartContext )
    {
      KeSetPriorityThread(KeGetCurrentThread(), 0x1F);
      KeBugCheckEx(0xE2u, 0x2D8ui64, **(unsigned int **)(controlled_buf + 2), 0i64, 'WM');
    }
    DbgPrint("SDDEV_IO_BLUE_SCREEN preps ...");
    *StartContext = **(_DWORD **)(controlled_buf + 2);
    if ( PsCreateSystemThread(
            &ThreadHandle,
            0x1FFFFFu,
            0i64,
            0i64,
            0i64,
            (PKSTART_ROUTINE)sub_23948,
            StartContext) < 0 )
      ExFreePoolWithTag(StartContext, 0);
    else
      ZwClose(ThreadHandle);
  }

## Solution
Mettez à jour vers Winmagic SecureDoc v8.5 SR2 HF1.

## Sommes de contrôle
| Nom de fichier             | Version | Hash (SHA-256) |
| -------------------- | ------- | -------------- |
| SDDisk2k.sys (64bit) | 8.3.717 | 98D29D28BB9552D20BC78EB0BD12A57B921167565F3E47919EC2D61F24DA9241 |
| SDDisk2k.sys (64bit) | 8.5.445 | 1D9054C4B49267EEF63B2EB11EC563E036F9E6E2AC18D32597FA769934BB7E18 |

## Références
1. [Abuser des privilèges de jeton pour LPE](https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt)
2. [Exploitation de CVE-2014-4113 sur Windows 8.1](http://jodeit.org/research/Exploiting_CVE-2014-4113_on_Windows_8.1.pdf)
3. [Exploitation locale facile du noyau Windows](https://media.blackhat.com/bh-us-12/Briefings/Cerrudo/BH_US_12_Cerrudo_Windows_Kernel_WP.pdf)
4. [J'ai 99 problèmes mais un pointeur noyau n'en est pas un](https://recon.cx/2013/slides/Recon2013-Alex%20Ionescu-I%20got%2099%20problems%20but%20a%20kernel%20pointer%20ain%27t%20one.pdf)
5. [Exploitation des handles de processus et de threads divulgués](http://dronesec.pw/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/)
6. [Discussion Sourceforge sur l'appel de NtQuerySystemInformation à l'aide de ctypes](https://sourceforge.net/p/ctypes/mailman/message/34578496/)
7. [Notes de version de SecureDoc v8.5SR2](https://www.winmagic.com/support/release-notes/securedoc-v8-5-sr2)